From report at bugs.python.org  Wed Apr  1 04:56:05 2020
From: report at bugs.python.org (ChrisRands)
Date: Wed, 01 Apr 2020 08:56:05 +0000
Subject: [New-bugs-announce] [issue40132] Mechanism to control who owns
 package names on PyPI?
Message-ID: <1585731365.14.0.524521872477.issue40132@roundup.psfhosted.org>


New submission from ChrisRands <chrisrands0 at gmail.com>:

Not sure if this is the right place to mention this (apologies if not). Naturally, package names are unique so when you run `pip install package-name` there is no ambiguity. However, this means that package names are limited and potentially valuable. Already there were some malicious users typo squatting famous package names (https://www.nbu.gov.sk/skcsirt-sa-20170909-pypi/), now fixed, but I'm more referring to the more general issue.

My guess is, if python continues to grow in popularity, it is only a matter of time before some unhelpful folks decide to reserve generic package names (common words etc.) and there is a market for selling PyPI package names (like the situation with domain names now). Personally, I'm not sure this would be good for the python community, but I don't know if there is (or could be) any solutions?

----------
messages: 365454
nosy: ChrisRands
priority: normal
severity: normal
status: open
title: Mechanism to control who owns package names on PyPI?

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

From report at bugs.python.org  Wed Apr  1 06:00:05 2020
From: report at bugs.python.org (=?utf-8?q?Diego_Elio_Petten=C3=B2?=)
Date: Wed, 01 Apr 2020 10:00:05 +0000
Subject: [New-bugs-announce] [issue40133] Provide additional matchers for
 unittest.mock
Message-ID: <1585735205.76.0.306632606173.issue40133@roundup.psfhosted.org>


New submission from Diego Elio Petten? <flameeyes at flameeyes.com>:

The unittest.mock `assert_called_*with*` methods take either literals, or the single `ANY` special matcher (https://docs.python.org/3/library/unittest.mock.html#any) to match any argument.

Experience suggests me that it's useful to have more flexible matchers, such as INSTANCEOF or REGEXP.

Will provide a starting pull request for this today. (Be warned: it's the first time I try contributing to CPython.)

----------
components: Tests
messages: 365457
nosy: Diego Elio Petten?
priority: normal
severity: normal
status: open
title: Provide additional matchers for unittest.mock
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Wed Apr  1 07:05:53 2020
From: report at bugs.python.org (Dave Rove)
Date: Wed, 01 Apr 2020 11:05:53 +0000
Subject: [New-bugs-announce] [issue40134] Inconsistent ANSI escape code
 handling on Windows 10
Message-ID: <1585739153.82.0.592216373665.issue40134@roundup.psfhosted.org>


New submission from Dave Rove <daver1473 at bobmail.info>:

The correct handling of ANSI escape codes by the print() function may or may not be enabled in the Windows 10 command prompt window, depending on previous system calls. The following is quite repeatable. Comment-out the apparently meaningless os.system("") line and ANSI codes do not work, but leave that line in and ANSI codes DO work:

    import os
    os.system("") # Comment this out to disable ANSI codes
    ansi_red = "\x1b[31m"
    ansi_normal = "\x1b[0m"
    print(ansi_red + "This is red!" + ansi_normal)

To be consistent with Python on Linux and Mac, I believe that ANSI codes should be permanently enabled in Windows 10 rather than removed. ANSI code handling was present from the start of Windows 10, so it's reasonable to presume that it's now a permanent feature of the Windows command prompt window. Either way, the inconsistency of the handling should be fixed.

To emphasize that ANSI codes ARE a feature of the command prompt, comment out that line to disable the ANSI codes in print(), but redirect the output to a text file. Then display that file at the command prompt. The ANSI codes then work correctly. 

    python myansi.py > myansi.txt
    type myansi.txt

----------
components: Windows
messages: 365458
nosy: daverove, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Inconsistent ANSI escape code handling on Windows 10
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Wed Apr  1 09:18:18 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 01 Apr 2020 13:18:18 +0000
Subject: [New-bugs-announce] [issue40135] multiprocessing:
 test_shared_memory_across_processes() cannot be run twice in parallel
Message-ID: <1585747098.48.0.62220441008.issue40135@roundup.psfhosted.org>


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

Sometimes, I need to run multiprocessing tests multiple times in parallel to attempt to reproduce a race condition. Except that test_shared_memory_across_processes() fails in this case:

$ ./python -m test test_multiprocessing_spawn --fail-env-changed -v -j4 -F -m test_shared_memory_across_processes 

== CPython 3.9.0a5+ (heads/master:17b4733f2f, Apr 1 2020, 15:02:04) [GCC 9.2.1 20190827 (Red Hat 9.2.1-1)]
== Linux-5.5.9-200.fc31.x86_64-x86_64-with-glibc2.30 little-endian
== cwd: /home/vstinner/python/master/build/test_python_1133450
== CPU count: 8
== encodings: locale=UTF-8, FS=utf-8
0:00:00 load avg: 1.64 Run tests in parallel using 4 child processes
0:00:01 load avg: 1.64 [  1/1] test_multiprocessing_spawn failed
test_shared_memory_across_processes (test.test_multiprocessing_spawn.WithProcessesTestSharedMemory) ... ERROR

======================================================================
ERROR: test_shared_memory_across_processes (test.test_multiprocessing_spawn.WithProcessesTestSharedMemory)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/vstinner/python/master/Lib/test/_test_multiprocessing.py", line 3862, in test_shared_memory_across_processes
    sms = shared_memory.SharedMemory('test02_tsmap', True, size=512)
  File "/home/vstinner/python/master/Lib/multiprocessing/shared_memory.py", line 100, in __init__
    self._fd = _posixshmem.shm_open(
FileExistsError: [Errno 17] File exists: '/test02_tsmap'

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

Ran 1 test in 0.247s

FAILED (errors=1)
test test_multiprocessing_spawn failed
Kill <TestWorkerProcess #2 running test=test_multiprocessing_spawn pid=1133458 time=1.2 sec> process group
Kill <TestWorkerProcess #3 running test=test_multiprocessing_spawn pid=1133457 time=1.2 sec> process group
Kill <TestWorkerProcess #4 running test=test_multiprocessing_spawn pid=1133459 time=1.2 sec> process group

== Tests result: FAILURE ==

1 test failed:
    test_multiprocessing_spawn

Total duration: 1.2 sec
Tests result: FAILURE

----------
components: Tests
messages: 365462
nosy: vstinner
priority: normal
severity: normal
status: open
title: multiprocessing: test_shared_memory_across_processes() cannot be run twice in parallel
versions: Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Wed Apr  1 09:59:05 2020
From: report at bugs.python.org (Benedikt Bleimhofer)
Date: Wed, 01 Apr 2020 13:59:05 +0000
Subject: [New-bugs-announce] [issue40136] add warning to datetime.replace
 documentation to not use it for setting tzinfo unless UTC or None
Message-ID: <1585749545.84.0.350796397082.issue40136@roundup.psfhosted.org>


New submission from Benedikt Bleimhofer <benedikt.bleimhofer at gmail.com>:

It would probably save some people a lot of time if the documentation of datetime.replace (https://docs.python.org/3/library/datetime.html#datetime.datetime.replace) showed a warning not to use it for setting the timezone on a datetime object or at least that there is a high chance that the result will not be what you expect.

"
If you don't use tz.localize(), but use datetime.replace(), chances are that a historical offset is used instead; tz.localize() will pick the right offset in effect for the given date.
"
More information on the problem can be found here:
https://stackoverflow.com/questions/13994594/how-to-add-timezone-into-a-naive-datetime-instance-in-python

I ran into this problem and it took me quite some time to figure this out. datetime.replace seems more intuitive to use in this case, but since it does not work it might be useful to even link to tz.localize.

----------
assignee: docs at python
components: Documentation
messages: 365469
nosy: Benedikt Bleimhofer, docs at python
priority: normal
severity: normal
status: open
title: add warning to datetime.replace documentation to not use it for setting tzinfo unless UTC or None
type: enhancement

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

From report at bugs.python.org  Wed Apr  1 11:08:23 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 01 Apr 2020 15:08:23 +0000
Subject: [New-bugs-announce] [issue40137] TODO list when PEP 573 "Module
 State Access from C Extension Methods" will be implemented
Message-ID: <1585753703.83.0.0762180613721.issue40137@roundup.psfhosted.org>


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

In bpo-1635741, many C extension modules are converted to PEP 489 multiphase initialization and/or modified to get a module state. Problem: the module state cannot be accessed in some functions, and so some of these changes had to workaround the fact that PEP 573 "Module State Access from C Extension Methods" is not implemented yet.

This issue tracks C extension modules which should be modified once PEP 573 will be implemented:

* _functools: Py_CLEAR(kwd_mark); is commented in _functools_free()
  See commit eacc07439591c97f69ab4a3d17391b009cd78ae2

* _abc: abc_invalidation_counter is shared by all module instances. abc_data_new() requires access to abc_invalidation_counter but it doesn't have access to the module state. abc_invalidation_counter should be moved to the module state.

----------
components: Library (Lib)
messages: 365482
nosy: vstinner
priority: normal
severity: normal
status: open
title: TODO list when PEP 573 "Module State Access from C Extension Methods" will be implemented
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Wed Apr  1 13:05:27 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 01 Apr 2020 17:05:27 +0000
Subject: [New-bugs-announce] [issue40138] Windows implementation of
 os.waitpid() truncates the exit status (status << 8)
Message-ID: <1585760727.67.0.797995887325.issue40138@roundup.psfhosted.org>


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

On Windows, the exit code is a 32-bit value. It may or may not signed depending on the function.

Unsigned in the Windows native API:

BOOL TerminateProcess(HANDLE hProcess, UINT uExitCode);
BOOL GetExitCodeProcess(HANDLE hProcess, LPDWORD lpExitCode);

Signed in the POSIX API:

intptr_t _cwait(int *termstat, intptr_t procHandle, int action);

Problem: os.waitpid() uses "status << 8" which can overflow; status is an int.

static PyObject *
os_waitpid_impl(PyObject *module, intptr_t pid, int options)
{
    int status;
    (...)
    /* shift the status left a byte so this is more like the POSIX waitpid */
    return Py_BuildValue(_Py_PARSE_INTPTR "i", res, status << 8);
}

int64_t or uint64_t should be used, or a Python object should be used, to avoid the overflow.

I just added os.waitstatus_to_exitcode() in bpo-40094 which simply does "status >> 8" on Windows. Currently, this function casts the argument to a C int and so is limited to INT_MAX. It should also be adapted to handle values larger than INT_MAX.

By the way, I'm not sure how to handle values larger than INT_MAX. The POSIX API of Windows uses a signed integer, and so convert such value as a negative value. But the native Windows API uses unsigned numbers.

It seems like using unsigned number would be better.

--

By the way, currently os.waitstatus_to_exitcode() ignores the lower 8 bits of the status. Maybe it should raise an error if lower 8 bits are not zero, and maybe also raise an exception if the number is negative?


--

See also interesting comments by Eryk Sun in bpo-40094 about this problem.

----------
components: Library (Lib)
messages: 365498
nosy: vstinner
priority: normal
severity: normal
status: open
title: Windows implementation of os.waitpid() truncates the exit status (status << 8)
versions: Python 3.9

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

From report at bugs.python.org  Wed Apr  1 14:01:20 2020
From: report at bugs.python.org (=?utf-8?q?Uwe_Kleine-K=C3=B6nig?=)
Date: Wed, 01 Apr 2020 18:01:20 +0000
Subject: [New-bugs-announce] [issue40139] mimetypes module racy
Message-ID: <1585764080.54.0.0429329888929.issue40139@roundup.psfhosted.org>


New submission from Uwe Kleine-K?nig <uwe+python at kleine-koenig.org>:

Hello,

in a project using aiohttp with Python 3.5 as provided by Debian Stretch (3.5.3) I sometimes see a wrong mimetype assigned to .css files. When trying to create a minimal reproduction recipe a colleage and I came up with:

    import asyncio
    import sys
    from mimetypes import guess_type
    
    async def f():
        t = guess_type('foo.css')
    
        return t == ('text/css', None)
    
    
    async def main():
        done, pending = await asyncio.wait([
            asyncio.ensure_future(f()),
            asyncio.ensure_future(f()),
        ])
    
        return all(d.result() for d in done)
    
    if __name__ == '__main__':
        loop = asyncio.get_event_loop()
        if not loop.run_until_complete(main()):
            print("FAIL")
            exit(1)

We didn't see this exact code failing but something very similar and only once. Up to now we only tested on Python 3.5 as this is what is used in production.

By code inspection I found a race: In the module's guess_type function there is:

    if _db is None:
        init()
    return ...

It can happen here that init() is entered twice when the first context entered init() but gets preempted before setting _db.

However I failed to see how this can result in guess_type returning None (which is what we occasionally see in our production code).

Also the code in mimetypes.py is rather convoluted with two different guards for not calling init (_db is None + not inited), init() updating various global variables and instantiating a MimeTypes object that depends on these variables, ...

mimetypes.py changed in master a few times, as I didn't spot the actual problem yet and the issue hardly reproduces I cannot tell if the problem still exists in newer versions of Python.

There are also some bug reports that seem related, I found reading https://bugs.python.org/issue38656 and https://bugs.python.org/issue4963 interesting.

Best regards
Uwe

----------
components: Library (Lib)
messages: 365500
nosy: ukl
priority: normal
severity: normal
status: open
title: mimetypes module racy
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Wed Apr  1 15:39:48 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Wed, 01 Apr 2020 19:39:48 +0000
Subject: [New-bugs-announce] [issue40140] test_builtin crashes when runned
 in parallel mode on solaris
Message-ID: <1585769988.66.0.906908269911.issue40140@roundup.psfhosted.org>


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

test_builting works on serial run

0:00:00 load avg: 2.38 Run tests sequentially
0:00:00 load avg: 2.38 [1/1] test_builtin

== Tests result: SUCCESS ==

1 test OK.

Total duration: 1.3 sec
Tests result: SUCCESS

but with more then one processes, it crashes 

0:00:00 load avg: 1.71 Run tests in parallel using 2 child processes
0:00:01 load avg: 1.70 [1/1/1] test_builtin crashed (Exit code -1)
test_abs (test.test_builtin.BuiltinTest) ... ok
test_all (test.test_builtin.BuiltinTest) ... ok
test_any (test.test_builtin.BuiltinTest) ... ok
test_ascii (test.test_builtin.BuiltinTest) ... ok
test_bin (test.test_builtin.BuiltinTest) ... ok
test_bug_27936 (test.test_builtin.BuiltinTest) ... ok
test_bytearray_extend_error (test.test_builtin.BuiltinTest) ... ok
test_bytearray_translate (test.test_builtin.BuiltinTest) ... ok
test_callable (test.test_builtin.BuiltinTest) ... ok
test_chr (test.test_builtin.BuiltinTest) ... ok
test_cmp (test.test_builtin.BuiltinTest) ... ok
test_compile (test.test_builtin.BuiltinTest) ... ok
test_compile_async_generator (test.test_builtin.BuiltinTest)
With the PyCF_ALLOW_TOP_LEVEL_AWAIT flag added in 3.8, we want to ... ok
test_compile_top_level_await (test.test_builtin.BuiltinTest)
Test whether code some top level await can be compiled. ... ok
test_compile_top_level_await_invalid_cases (test.test_builtin.BuiltinTest) ... ok
test_construct_singletons (test.test_builtin.BuiltinTest) ... ok
test_delattr (test.test_builtin.BuiltinTest) ... ok
test_dir (test.test_builtin.BuiltinTest) ... ok
test_divmod (test.test_builtin.BuiltinTest) ... ok
test_eval (test.test_builtin.BuiltinTest) ... ok
test_exec (test.test_builtin.BuiltinTest) ... ok
test_exec_globals (test.test_builtin.BuiltinTest) ... ok
test_exec_redirected (test.test_builtin.BuiltinTest) ... ok
test_filter (test.test_builtin.BuiltinTest) ... ok
test_filter_pickle (test.test_builtin.BuiltinTest) ... ok
test_format (test.test_builtin.BuiltinTest) ... ok
test_general_eval (test.test_builtin.BuiltinTest) ... ok
test_getattr (test.test_builtin.BuiltinTest) ... ok
test_hasattr (test.test_builtin.BuiltinTest) ... ok
test_hash (test.test_builtin.BuiltinTest) ... ok
test_hex (test.test_builtin.BuiltinTest) ... ok
test_id (test.test_builtin.BuiltinTest) ... ok
test_import (test.test_builtin.BuiltinTest) ... ok
test_input (test.test_builtin.BuiltinTest) ... ok
test_isinstance (test.test_builtin.BuiltinTest) ... ok
test_issubclass (test.test_builtin.BuiltinTest) ... ok
test_iter (test.test_builtin.BuiltinTest) ... ok
test_len (test.test_builtin.BuiltinTest) ... ok
test_map (test.test_builtin.BuiltinTest) ... ok
test_map_pickle (test.test_builtin.BuiltinTest) ... ok
test_max (test.test_builtin.BuiltinTest) ... ok
test_min (test.test_builtin.BuiltinTest) ... ok
test_neg (test.test_builtin.BuiltinTest) ... ok
test_next (test.test_builtin.BuiltinTest) ... ok
test_oct (test.test_builtin.BuiltinTest) ... ok
test_open (test.test_builtin.BuiltinTest) ... ok
test_open_default_encoding (test.test_builtin.BuiltinTest) ... ok
test_open_non_inheritable (test.test_builtin.BuiltinTest) ... ok
test_ord (test.test_builtin.BuiltinTest) ... ok
test_pow (test.test_builtin.BuiltinTest) ... ok
test_repr (test.test_builtin.BuiltinTest) ... ok
test_round (test.test_builtin.BuiltinTest) ... ok
test_round_large (test.test_builtin.BuiltinTest) ... ok
test_setattr (test.test_builtin.BuiltinTest) ... ok
test_sum (test.test_builtin.BuiltinTest) ... ok
test_type (test.test_builtin.BuiltinTest) ... ok
test_vars (test.test_builtin.BuiltinTest) ... ok
test_warning_notimplemented (test.test_builtin.BuiltinTest) ... ok
test_zip (test.test_builtin.BuiltinTest) ... ok
test_zip_bad_iterable (test.test_builtin.BuiltinTest) ... ok
test_zip_pickle (test.test_builtin.BuiltinTest) ... ok
test_input_no_stdout_fileno (test.test_builtin.PtyTests) ...

== Tests result: FAILURE ==

1 test failed:
    test_builtin

Total duration: 1.4 sec
Tests result: FAILURE

System: SunOS gcc-solaris11 5.11 11.3 sun4u sparc SUNW,SPARC-Enterprise
Tested under both gcc (5.5.0) and solaris studio (12)

----------
components: Tests
messages: 365505
nosy: BTaskaya
priority: normal
severity: normal
status: open
title: test_builtin crashes when runned in parallel mode on solaris
versions: Python 3.9

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

From report at bugs.python.org  Wed Apr  1 16:49:16 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 01 Apr 2020 20:49:16 +0000
Subject: [New-bugs-announce] [issue40141] Add line and column information
 for keywords in the AST
Message-ID: <1585774156.85.0.46549854345.issue40141@roundup.psfhosted.org>


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

When inspecting keyword parameters in a function call, the keyword is stored as a string and not as a AST node:

>>> import ast
>>> r = "f(a,   xxxxxxxxxxa  =  34, y=23)"
>>> node = ast.parse(r)
>>> ll = node.body[0].value.keywords[0].arg
>>> node.body[0].value.keywords[0].arg
'xxxxxxxxxxa'

this makes impossible to locate the keyword in the code using the AST as it lacks AST attributes (lineno, col_offset, end_lineno, end_col_offset).

On the other hand, this does not happen with args, that has the meta-information:

>>> node.body[0].value.args[0].id
'a'
>>> dir(node.body[0].value.args[0])


So one can locate the arg string using:

>>> r[arg.col_offset:arg.end_col_offset]
'a'

For this reason, we should add the same information to keyword nodes.

----------
components: Interpreter Core
messages: 365509
nosy: pablogsal
priority: normal
severity: normal
status: open
title: Add line and column information for keywords in the AST
versions: Python 3.9

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

From report at bugs.python.org  Wed Apr  1 17:55:41 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 01 Apr 2020 21:55:41 +0000
Subject: [New-bugs-announce] [issue40142] Modify _PyObject_GC_TRACK() to
 ensure that newly tracked object is valid
Message-ID: <1585778141.93.0.504215883297.issue40142@roundup.psfhosted.org>


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

In bpo-38392, I modified PyObject_GC_Track() to ensure that the object newly tracked is valid: call its traverse function.
=> commit 1b1845569539db5c1a6948a5d32daea381f1e35f

I propose to now also attempt to implement the same check in _PyObject_GC_TRACK() which is part of the internal C API.

PyType_GenericAlloc() allocates memory for a type allocated on the heap... and then immediately track it in the GC. Problem: this type is not initialized yet, all fields are set to zero. Calling type_traverse() at this point fails with an assertion error:
---
Objects/typeobject.c:3570: type_traverse: Assertion failed: type_traverse() called on non-heap type '(null)'
Enable tracemalloc to get the memory block allocation traceback

object address  : 0x840860
object refcount : 1
object type     : 0x7e0900
object type name: type
object repr     : 
---

By the way, Python crash in _PyObject_Dump() on PyObject_Repr() call: type_repr() crash when accessing type->tp_name which is NULL.

type_call() should only track the newly created type when it's fully initialized.


Try attached track.patch to reproduce the crash.

----------
components: Interpreter Core
files: track.patch
keywords: patch
messages: 365515
nosy: vstinner
priority: normal
severity: normal
status: open
title: Modify _PyObject_GC_TRACK() to ensure that newly tracked object is valid
type: enhancement
versions: Python 3.9
Added file: https://bugs.python.org/file49021/track.patch

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

From report at bugs.python.org  Wed Apr  1 18:15:23 2020
From: report at bugs.python.org (Alexander Riccio)
Date: Wed, 01 Apr 2020 22:15:23 +0000
Subject: [New-bugs-announce] [issue40143] shutil.rmtree will frequently fail
 on Windows under heavy load due to racy deletion
Message-ID: <1585779323.08.0.697022705599.issue40143@roundup.psfhosted.org>


New submission from Alexander Riccio <test35965 at gmail.com>:

The "obvious" way to delete a directory tree on Windows is wrong. It's inherently racy, since deleting a file on Windows *doesn't actually delete it*, instead it marks the file for deletion. The system will eventually get around to deleting it, but under heavy load, this might be sometime after an attempt is made to delete the parent directory. I've seen this (windows error 145, directory is not empty) many times when running the testsuite, and it causes all kinds of intermittent failures.

The best way to do things correctly is kinda nuts, and is explained well by Niall Douglass here: https://www.youtube.com/watch?v=uhRWMGBjlO8&t=8m54s

In short, the correct way to do it involves moving each file to a randomly named file in %TEMP%, then deleting that, and then doing the same with each newly-empty directory.

----------
components: Windows
messages: 365520
nosy: Alexander Riccio, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: shutil.rmtree will frequently fail on Windows under heavy load due to racy deletion
versions: Python 3.9

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

From report at bugs.python.org  Wed Apr  1 18:29:54 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 01 Apr 2020 22:29:54 +0000
Subject: [New-bugs-announce] [issue40144] test.support.SuppressCrashReport
 fails on macOS
Message-ID: <1585780194.51.0.469585902062.issue40144@roundup.psfhosted.org>


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

Failure seen on the macOS job on a PR:

https://github.com/python/cpython/pull/19252/checks?check_run_id=552502971
of https://github.com/python/cpython/pull/19252/files

Reformatted error:

AssertionError: Regex didn't match:

"Fatal Python error: _enter_buffered_busy: could not acquire lock for <(_io\\.)?BufferedWriter name='<stderr>'> at interpreter shutdown, possibly due to daemon threads"

not found in

'Traceback (most recent call last):
  File "<string>", line 15, in <module>
  File "/Users/runner/runners/2.165.2/work/cpython/cpython/Lib/test/support/__init__.py", line 2913, in __enter__
    self.old_value = resource.getrlimit(resource.RLIMIT_CORE)
AttributeError: module \'resource\' has no attribute \'RLIMIT_CORE\'
'

It seems like resource.RLIMIT_CORE is not available on this macOS machine.

----------
components: Tests
messages: 365521
nosy: vstinner
priority: normal
severity: normal
status: open
title: test.support.SuppressCrashReport fails on macOS
versions: Python 3.9

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

From report at bugs.python.org  Wed Apr  1 18:43:57 2020
From: report at bugs.python.org (Alexander Riccio)
Date: Wed, 01 Apr 2020 22:43:57 +0000
Subject: [New-bugs-announce] [issue40145] Pyshellext room for binary size
 improvement
Message-ID: <1585781037.54.0.0844996141167.issue40145@roundup.psfhosted.org>


New submission from Alexander Riccio <test35965 at gmail.com>:

I've tweaked the pcbuild options for pyshellext to reduce the size of the binary.
Since this is a very simple component, there really isn't much benefit of
optimizing for speed, likely the slowest part of this component's lifetime is
simply loading it.

This patch turns on Whole Program Optimization, MinSpace optimization, /Ob2
AnySuitable function inlining (to expose more code to elimination, this does
actually help here), /Zo (so that people can still debug it when lots of code
has been optimized out), turns of C++ RTTI (nobody is using it), /OPT:REF dead
code elimination, /OPT:ICF COMDAT folding, Link Time Code Generation, and
DebugFull debugging information creation.

/Gw global data optimization seemed to do nothing, which makes sense since
there isn't much going on in this project, very little in the way of actual
global data. Disabling C++ exceptions both in the project config (i.e. /EH-),
and disabling stdlib exceptions via _HAS_EXCEPTIONS=0, had no effect.
Strangely, with exceptions disabled and _HAS_EXCEPTIONS=0, exception functions
are still emitted in the binary (as seen in IDA). I presume it has something
to do with the fact that its a dll.

Enabling optimizations (even for Debug builds) should have no effect. The debug
builds were not actually using debugging featuers (not even assert), so nothing
should change.

pyshellext.dll   32 bit unimproved release size: 42KB
pyshellext.dll   32 bit   improved release size: 25KB
                                size reduction: -17KB
                             %  size reduction:   40%

pyshellext_d.dll 32 bit unimproved debug size:   85KB
pyshellext_d.dll 32 bit   improved debug size:   32KB
                               size reduction:  -53KB
                             %  size reduction:   62%


pyshellext.dll   64 bit unimproved release size: 52KB
pyshellext.dll   64 bit   improved release size: 30KB
                               size reduction:  -22KB
                             %  size reduction:   42%

pyshellext_d.dll 64 bit unimproved debug size:  105KB
pyshellext_d.dll 64 bit   improved debug size:   38KB
                               size reduction:  -67KB
                             %  size reduction:   63%

----------
components: Windows
messages: 365527
nosy: Alexander Riccio, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Pyshellext room for binary size improvement
versions: Python 3.9

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

From report at bugs.python.org  Wed Apr  1 20:13:47 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 02 Apr 2020 00:13:47 +0000
Subject: [New-bugs-announce] [issue40146] Upgrade Azure Pipelines to OpenSSL
 1.1.1f
Message-ID: <1585786427.57.0.72048128353.issue40146@roundup.psfhosted.org>


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

The "Install Dependencies" step of the Ubuntu PR Tests job of Azure Pipelines failed with:
---
*** INFO /home/vsts/work/1/s/multissl/openssl/1.1.1d/bin/openssl
*** INFO Downloading from https://www.openssl.org/source/openssl-1.1.1d.tar.gz
Traceback (most recent call last):
(...)
urllib.error.HTTPError: HTTP Error 404: Not Found
---

The problem is that the tarball of OpenSSL 1.1.1d moved from /source/ to /source/old/ directory.

bpo-40125 updated multissl to OpenSSL 1.1.1f.

I propose to use the same OpenSSL version for Azure Pipelines.

By the way, PCbuild/get_externals.bat and Mac/BuildScript/build-installer.py still use OpenSSL 1.1.1d (released at 2019-Sep-10). It's maybe time to upgrade these as well.

----------
components: Tests
messages: 365534
nosy: vstinner
priority: normal
severity: normal
status: open
title: Upgrade Azure Pipelines to OpenSSL 1.1.1f
versions: Python 3.9

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

From report at bugs.python.org  Wed Apr  1 20:22:24 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 02 Apr 2020 00:22:24 +0000
Subject: [New-bugs-announce] [issue40147] Move checking for duplicated
 keywords to the compiler
Message-ID: <1585786944.89.0.491246758826.issue40147@roundup.psfhosted.org>


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

When a keyword is repeated in a call for instance:

'f(1, x=2, *(3, 4), x=5)'

we raise a SyntaxError:

  File "lel.py", line 1
    f(1, x=2, *(3, 4), x=5)
                       ^
SyntaxError: keyword argument repeated

This error is raised from the AST but there is nothing technically wrong with that code from the grammar perspective. Indeed, the grammar must accepts that code, but the check must fail later (in the compiler for instance) because the code is semantically invalid. When working on the new PEG parser we have encountered this situation and changing the parser would remove the check as it is right now. For these reasons, the check should be moved from the AST to the compiler.

----------
messages: 365537
nosy: pablogsal
priority: normal
severity: normal
status: open
title: Move checking for duplicated keywords to the compiler

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

From report at bugs.python.org  Wed Apr  1 20:40:24 2020
From: report at bugs.python.org (Tim Hoffmann)
Date: Thu, 02 Apr 2020 00:40:24 +0000
Subject: [New-bugs-announce] [issue40148] Add PurePath.with_stem()
Message-ID: <1585788024.89.0.165310869252.issue40148@roundup.psfhosted.org>


New submission from Tim Hoffmann <tim.hoffmann at posteo.de>:

Similar to PurePath.with_name() and PurePath.with_suffix() there should be a PurePath.with_stem().

A common use case would be appending something before the suffix: path.with_stem(path.stem + '_v2')

As of now this must be written more cumbersome as:
path.with_name(path.stem + '_v2' + path.suffix)

----------
components: Library (Lib)
messages: 365540
nosy: timhoffm
priority: normal
severity: normal
status: open
title: Add PurePath.with_stem()

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

From report at bugs.python.org  Wed Apr  1 21:54:05 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 02 Apr 2020 01:54:05 +0000
Subject: [New-bugs-announce] [issue40149] test_threading leaked [38, 38,
 38] references, sum=114
Message-ID: <1585792445.62.0.0518463995906.issue40149@roundup.psfhosted.org>


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

New changeset 53e4c91725083975598350877e2ed8e2d0194114 by Dong-hee Na in branch 'master':
bpo-40077: Convert _abc module to use PyType_FromSpec() (GH-19202)
https://github.com/python/cpython/commit/53e4c91725083975598350877e2ed8e2d0194114

This change introduced a reference leak:

$ ./python -m test -R 3:3 test_threading -m test.test_threading.SubinterpThreadingTests.test_threads_join_2
0:00:00 load avg: 1.52 Run tests sequentially
0:00:00 load avg: 1.52 [1/1] test_threading
beginning 6 repetitions
123456
......
test_threading leaked [19, 19, 19] references, sum=57
test_threading leaked [12, 12, 12] memory blocks, sum=36
test_threading failed

== Tests result: FAILURE ==

1 test failed:
    test_threading

Total duration: 768 ms
Tests result: FAILURE

----------
components: Tests
messages: 365557
nosy: corona10, vstinner
priority: normal
severity: normal
status: open
title: test_threading leaked [38, 38, 38] references, sum=114
versions: Python 3.9

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

From report at bugs.python.org  Wed Apr  1 23:13:59 2020
From: report at bugs.python.org (Alexander Riccio)
Date: Thu, 02 Apr 2020 03:13:59 +0000
Subject: [New-bugs-announce] [issue40150] (minor) mismatched argument in
 overlapped_RegisterWaitWithQueue call to RegisterWaitForSingleObject
Message-ID: <1585797239.79.0.769290971181.issue40150@roundup.psfhosted.org>


New submission from Alexander Riccio <test35965 at gmail.com>:

This popped out at me while looking for something else. It's probably not much of an actual problem, since the wrong datatype is larger than the correct one, but it's worth fixing.

The problem is in overlapped_RegisterWaitWithQueue, at overlapped.c:297 (in _overlapped):

    if (!RegisterWaitForSingleObject(
            &NewWaitObject, Object, (WAITORTIMERCALLBACK)PostToQueueCallback,
            pdata, Milliseconds,
            WT_EXECUTEINWAITTHREAD | WT_EXECUTEONLYONCE))


...it stood out to me immediately while I was paging past, since function pointer casts of this sort are almost always wrong, and I've seen it too many times.

WAITORTIMERCALLBACK is a typedef of WAITORTIMERCALLBACKFUNC:

typedef VOID (NTAPI * WAITORTIMERCALLBACKFUNC) (PVOID, BOOLEAN );

...and PostToQueueCallback is defined as:

static VOID CALLBACK
PostToQueueCallback(PVOID lpParameter, BOOL TimerOrWaitFired)

...where BOOL is an int, and BOOLEAN is an unsigned char. I guess there could be some kind of issue down the line if the generated code tries to read the BOOLEAN/int from the register/memory location where there's actually an unsigned char, but after about an hour of debugging, I can't see it. The documentation also states explicitly that this should be either TRUE or FALSE. Also, it doesn't matter what we actually pass to PostQueuedCompletionStatus: https://devblogs.microsoft.com/oldnewthing/20070525-00/?p=26693

By changing the (incorrect) BOOL declaration to BOOLEAN, then we don't need the cast.

----------
components: IO
messages: 365565
nosy: Alexander Riccio
priority: normal
severity: normal
status: open
title: (minor) mismatched argument in overlapped_RegisterWaitWithQueue call to RegisterWaitForSingleObject
versions: Python 3.9

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

From report at bugs.python.org  Wed Apr  1 23:46:48 2020
From: report at bugs.python.org (Alexander Riccio)
Date: Thu, 02 Apr 2020 03:46:48 +0000
Subject: [New-bugs-announce] [issue40151] _overlapped room for improvement
Message-ID: <1585799208.76.0.700272922922.issue40151@roundup.psfhosted.org>


New submission from Alexander Riccio <test35965 at gmail.com>:

Similarly to bpo-40145, I've tweaked build options to reduce the size of the
binary.

This patch turns on (for release builds) Whole Program Optimization, MinSpace
optimization, /Ob2 AnySuitable function inlining, /Zo (so that people can still
debug it when lots of code has been optimized out), /OPT:REF dead code
elimination, /OPT:ICF COMDAT folding, Link Time Code Generation, and DebugFull
debugging information creation.

For debug builds, it enables all of that, except instead of the MinSpace
optimization, it's only /Ob2 with custom optimization. My intent is to not
optimize any asserts or similar checks, while still getting the benefit of
dead and duplicate code elimination.


_overlapped.pyd   32 bit unimproved release size: 31KB
_overlapped.pyd   32 bit   improved release size: 29KB
                                size reduction:   -3KB
                             %  size reduction:    10%

_overlapped_d.pyd 32 bit unimproved release size: 55KB
_overlapped_d.pyd 32 bit   improved release size: 34KB
                                size reduction:  -21KB
                             %  size reduction:    38%




_overlapped.pyd   64 bit unimproved release size: 39KB
_overlapped.pyd   64 bit   improved release size: 36KB
                                size reduction:   -3KB
                             %  size reduction:     8%


_overlapped_d.pyd 64 bit unimproved release size: 74KB
_overlapped_d.pyd 64 bit   improved release size: 41KB
                                size reduction:  -33KB
                             %  size reduction:    45%


If this patch is merged, and all 7 million (estimated) Python developers update their installation, I calculate that I just saved the PSF 21GB worth of bandwidth costs :)

----------
components: Windows
messages: 365567
nosy: Alexander Riccio, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: _overlapped room for improvement
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Thu Apr  2 03:07:01 2020
From: report at bugs.python.org (Guilherme Salgado)
Date: Thu, 02 Apr 2020 07:07:01 +0000
Subject: [New-bugs-announce] [issue40152] Coroutine hangs if it performs
 async operations when handling exception sent using throw()
Message-ID: <1585811221.57.0.633761551121.issue40152@roundup.psfhosted.org>


New submission from Guilherme Salgado <gsalgado at gmail.com>:

A coroutine will hang forever if it that catches an exception sent via its throw() method and then makes async calls while handling that exception. The same coroutine will complete just fine if the exception is instead raised from within it. Here's a script that demonstrates that:

```
import asyncio
import sys

async def sleep_on_exc(inject):
    if inject:
        asyncio.ensure_future(inject_exc(coro))
    try:
        await asyncio.sleep(0.2)
        if not inject:
            print("Raising KeyboardInterrupt")
            raise KeyboardInterrupt()
    except KeyboardInterrupt:
        print("I'm not done yet")
        await asyncio.sleep(0.1)
        print("Now I'm done")

async def inject_exc(coro):
    await asyncio.sleep(0.1)
    print("Injecting KeyboardInterrupt")
    coro.throw(KeyboardInterrupt)

coro = sleep_on_exc(sys.argv[1] == "inject")
loop = asyncio.get_event_loop()
loop.run_until_complete(coro)
```

```
$ python throw.py raise
Raising KeyboardInterrupt
I'm not done yet
Now I'm done
```

```
$ python throw.py inject
Injecting KeyboardInterrupt
I'm not done yet                     # It hangs forever here until you Ctrl-C
^CTraceback (most recent call last):
...
```

----------
components: asyncio
messages: 365572
nosy: asvetlov, salgado, yselivanov
priority: normal
severity: normal
status: open
title: Coroutine hangs if it performs async operations when handling exception sent using throw()
type: behavior
versions: Python 3.7

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

From report at bugs.python.org  Thu Apr  2 08:19:18 2020
From: report at bugs.python.org (Facundo Batista)
Date: Thu, 02 Apr 2020 12:19:18 +0000
Subject: [New-bugs-announce] [issue40153] json dump with repeated key
Message-ID: <1585829958.79.0.134366704668.issue40153@roundup.psfhosted.org>


New submission from Facundo Batista <facundo at taniquetil.com.ar>:

As stated in docs [0], JSON structures must not have duplicated keys.

>>> json.dumps({1:2, "1":3})
'{"1": 2, "1": 3}'

This is related to https://bugs.python.org/issue34972 . 



[0] "The RFC specifies that the names within a JSON object should be unique, ..." https://docs.python.org/3/library/json.html#repeated-names-within-an-object

----------
messages: 365581
nosy: facundobatista
priority: normal
severity: normal
status: open
title: json dump with repeated key
versions: Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Thu Apr  2 08:23:03 2020
From: report at bugs.python.org (Fernando)
Date: Thu, 02 Apr 2020 12:23:03 +0000
Subject: [New-bugs-announce] [issue40154] embedded null byte when connecting
 to sqlite database using a bytes object
Message-ID: <1585830183.65.0.52883821516.issue40154@roundup.psfhosted.org>


New submission from Fernando <ferferga.fer at gmail.com>:

Hello. I think that I found a bug in how sqlite3 module handle bytes.

The connect function of sqlite3 accepts strings, FilePath objects and bytes. However, it's impossible for me to connect to bytes objects that are read from BufferedReaders. I always get: 

"ValueError: embedded null byte"

This is my current code (byteDec is the BytesIO object):

==============================================
byteDec.seek(0)
conn = sqlite3.connect(byteDec.read())
==============================================

That returns the "embedded null byte" error. However, if I do:

==============================================
byteDec.seek(0)
with open("db.db", "wb" as f:
    f.write(byteDec.read())
conn = sqlite3.connect("db.db")
==============================================

Everything works flawlessly, so the BufferedReader that I have in-memory is not corrupted in any way, as it's readable from a file. I want to avoid writing to disk at all, so this is not a solution for me.


I attach to this issue a very basic proof of concept to understand the issue.

I'm running Pyhton 3.8.2 amd64 on Windows 10 1909

----------
components: IO
files: bytes_io.py
messages: 365582
nosy: ferferga
priority: normal
severity: normal
status: open
title: embedded null byte when connecting to sqlite database using a bytes object
type: crash
versions: Python 3.8
Added file: https://bugs.python.org/file49025/bytes_io.py

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

From report at bugs.python.org  Thu Apr  2 08:34:23 2020
From: report at bugs.python.org (Michael Felt)
Date: Thu, 02 Apr 2020 12:34:23 +0000
Subject: [New-bugs-announce] [issue40155] AIX: bot status: stuck at: failed
 test (failure) uploading test-results.xml (failure)
Message-ID: <1585830863.71.0.596270299618.issue40155@roundup.psfhosted.org>


New submission from Michael Felt <aixtools at felt.demon.nl>:

related to 

Two AIX bots - different environments - continue to fail the test: `test_builtin` since

During the first run - the test fails with something such as:

0:31:47 [215/420] test_abc passed -- running: test_builtin (14 min 10 sec)
0:32:17 running: test_builtin (14 min 40 sec), test_decimal (30.0 sec)
0:32:37 [216/420] test_decimal passed (49.4 sec) -- running: test_builtin (15 min)
0:32:37 [217/420/1] test_builtin crashed (Exit code 1)
Timeout (0:15:00)!
Thread 0x00000001 (most recent call first):

And in the second pass (re-run of failed tests) the failure goes:

test_zip (test.test_builtin.BuiltinTest) ... ok
test_zip_bad_iterable (test.test_builtin.BuiltinTest) ... ok
test_zip_pickle (test.test_builtin.BuiltinTest) ... ok
Timeout (0:15:00)!
Thread 0x00000001 (most recent call first):
  File "/home/buildbot/buildarea/3.x.aixtools-aix-power6/build/Lib/test/support/__init__.py", line 3435 in wait_process
  File "/home/buildbot/buildarea/3.x.aixtools-aix-power6/build/Lib/test/test_builtin.py", line 1898 in run_child
  File "/home/buildbot/buildarea/3.x.aixtools-aix-power6/build/Lib/test/test_builtin.py", line 1952 in test_input_no_stdout_fileno
  File "/home/buildbot/buildarea/3.x.aixtools-aix-power6/build/Lib/unittest/case.py", line 616 in _callTestMethod
  File "/home/buildbot/buildarea/3.x.aixtools-aix-power6/build/Lib/unittest/case.py", line 659 in run
  File "/home/buildbot/buildarea/3.x.aixtools-aix-power6/build/Lib/unittest/case.py", line 719 in __call__
  File "/home/buildbot/buildarea/3.x.aixtools-aix-power6/build/Lib/unittest/suite.py", line 122 in run
  File "/home/buildbot/buildarea/3.x.aixtools-aix-power6/build/Lib/unittest/suite.py", line 84 in __call__
  File "/home/buildbot/buildarea/3.x.aixtools-aix-power6/build/Lib/unittest/suite.py", line 122 in run
  File "/home/buildbot/buildarea/3.x.aixtools-aix-power6/build/Lib/unittest/suite.py", line 84 in __call__
  File "/home/buildbot/buildarea/3.x.aixtools-aix-power6/build/Lib/unittest/suite.py", line 122 in run
  File "/home/buildbot/buildarea/3.x.aixtools-aix-power6/build/Lib/unittest/suite.py", line 84 in __call__
  File "/home/buildbot/buildarea/3.x.aixtools-aix-power6/build/Lib/unittest/runner.py", line 176 in run
  File "/home/buildbot/buildarea/3.x.aixtools-aix-power6/build/Lib/test/support/__init__.py", line 2079 in _run_suite
  File "/home/buildbot/buildarea/3.x.aixtools-aix-power6/build/Lib/test/support/__init__.py", line 2201 in run_unittest
  File "/home/buildbot/buildarea/3.x.aixtools-aix-power6/build/Lib/test/libregrtest/runtest.py", line 209 in _test_module
  File "/home/buildbot/buildarea/3.x.aixtools-aix-power6/build/Lib/test/libregrtest/runtest.py", line 234 in _runtest_inner2
  File "/home/buildbot/buildarea/3.x.aixtools-aix-power6/build/Lib/test/libregrtest/runtest.py", line 270 in _runtest_inner
  File "/home/buildbot/buildarea/3.x.aixtools-aix-power6/build/Lib/test/libregrtest/runtest.py", line 153 in _runtest
  File "/home/buildbot/buildarea/3.x.aixtools-aix-power6/build/Lib/test/libregrtest/runtest.py", line 193 in runtest
  File "/home/buildbot/buildarea/3.x.aixtools-aix-power6/build/Lib/test/libregrtest/main.py", line 318 in rerun_failed_tests
  File "/home/buildbot/buildarea/3.x.aixtools-aix-power6/build/Lib/test/libregrtest/main.py", line 691 in _main
  File "/home/buildbot/buildarea/3.x.aixtools-aix-power6/build/Lib/test/libregrtest/main.py", line 634 in main
  File "/home/buildbot/buildarea/3.x.aixtools-aix-power6/build/Lib/test/libregrtest/main.py", line 712 in main
  File "/home/buildbot/buildarea/3.x.aixtools-aix-power6/build/Lib/test/__main__.py", line 2 in <module>
  File "/home/buildbot/buildarea/3.x.aixtools-aix-power6/build/Lib/runpy.py", line 87 in _run_code
  File "/home/buildbot/buildarea/3.x.aixtools-aix-power6/build/Lib/runpy.py", line 197 in _run_module_as_main
make: 1254-004 The error code from the last command is 1.
Stop.
program finished with exit code 2
elapsedTime=3610.362052
test_input_no_stdout_fileno (test.test_builtin.PtyTests) ... 

NOTE: the run has stopped with the line

test_input_no_stdout_fileno (test.test_builtin.PtyTests) ... 

and, so the results also fail to get uploaded.

----------
components: Tests
messages: 365583
nosy: Michael.Felt
priority: normal
severity: normal
status: open
title: AIX: bot status: stuck at: failed test (failure) uploading test-results.xml (failure)
versions: Python 3.9

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

From report at bugs.python.org  Thu Apr  2 09:35:01 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 02 Apr 2020 13:35:01 +0000
Subject: [New-bugs-announce] [issue40156] codecov/patch stills runs on 3.5
 and 3.6 branches
Message-ID: <1585834501.29.0.235392349062.issue40156@roundup.psfhosted.org>


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

Larry Hastings (Python 3.5 release manager) failed to merge my security fix into Python 3.5. The Codecov job run on the PR, failed and it must pass to merge a PR if I understood correctly Larry:
https://github.com/python/cpython/pull/17344#issuecomment-605417483

The same job also ran and failed on another security fix for Python 3.6:
https://github.com/python/cpython/pull/19304

I propose to copy .github/codecov.yml configuration from master to 3.5 and 3.6 branches to disable the Codecov "patch" job.

See also recent issue: bpo-39704 "Disable code coverage". Codecov should no longer post comments with the result of the code coverage analysis: it's disabled for the whole Python organization.

There are no longer "Codecov patch" jobs on the 3.7, 3.8 and master branches.

----------
components: Tests
messages: 365594
nosy: vstinner
priority: normal
severity: normal
status: open
title: codecov/patch stills runs on 3.5 and 3.6 branches
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Thu Apr  2 09:52:09 2020
From: report at bugs.python.org (Eduard Bopp)
Date: Thu, 02 Apr 2020 13:52:09 +0000
Subject: [New-bugs-announce] [issue40157] SMTP email policy does not encode
 non-ASCII characters
Message-ID: <1585835529.27.0.884427076581.issue40157@roundup.psfhosted.org>


New submission from Eduard Bopp <eduard.bopp at aepsil0n.de>:

Using email.policy.SMTP a message's non-ASCII characters are not encoded. The policy.utf8 attribute is set to False as documented.

The attached script illustrates the behaviour. I get the following command line output from it:

Subject: =?utf-8?b?w7zDtsOk?=


False
Subject: ???


True
Subject: ???


The default compat32 policy encodes the string, but the SMTP policy does not encode it, but leaves it as UTF-8 despite policy.utf8 == False. I might be misreading the documentation here, but it seems to me like utf8 == False implies that encoding should happen.

----------
components: email
files: minimal.py
messages: 365596
nosy: aepsil0n, barry, r.david.murray
priority: normal
severity: normal
status: open
title: SMTP email policy does not encode non-ASCII characters
type: behavior
versions: Python 3.6, Python 3.7, Python 3.8
Added file: https://bugs.python.org/file49026/minimal.py

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

From report at bugs.python.org  Thu Apr  2 14:00:31 2020
From: report at bugs.python.org (Chris Martinez)
Date: Thu, 02 Apr 2020 18:00:31 +0000
Subject: [New-bugs-announce] [issue40158] MSBuild Extensions in CPython
 NuGet Package has Bad Expression
Message-ID: <1585850431.84.0.195210252651.issue40158@roundup.psfhosted.org>


New submission from Chris Martinez <sydefekt at hotmail.com>:

CPython provides a NuGet package as a mechanism to support non-installed Python distributions. The package includes MSBuild support to integrate with its build process.

The expressions on lines 32 and 33 in the file:

https://github.com/python/cpython/blob/master/PC/layout/support/props.py

are both missing closing parentheses, which results in literal text instead of the resolve file paths. This appears to be introduced in version 3.7.2 of the package onward, including the current pre-release 3.9.0-a5.

In addition, several build conditions use the form " $(Property) == 'value' ", but should instead use " '$(Property)' == 'value' ". By not surrounding the property value with '', the condition may resolve as "  == '' ", which is an invalid expression and will cause a build failure. This doesn't appear to have caused an issue yet, but it easily could.

If there is no further discussion or objection, I can submit a PR with the required fixes.

----------
components: Build, Demos and Tools, Distutils, Installation, Windows
messages: 365610
nosy: dstufft, eric.araujo, paul.moore, steve.dower, sydefekt, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: MSBuild Extensions in CPython NuGet Package has Bad Expression
type: compile error
versions: Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Thu Apr  2 16:11:36 2020
From: report at bugs.python.org (=?utf-8?q?Volker_Wei=C3=9Fmann?=)
Date: Thu, 02 Apr 2020 20:11:36 +0000
Subject: [New-bugs-announce] [issue40159] Make python -V -V output arguments
 of configure
Message-ID: <1585858296.94.0.293337697124.issue40159@roundup.psfhosted.org>


New submission from Volker Wei?mann <volker.weissmann at gmx.de>:

As you might know, you can e.g. compile a version with
../configure --with-pydebug
or with
../configure
Currently, there is no easy way to find out how an installation on your machine was compiled. It would be nice if python -V -V would output every argument of configure.

----------
messages: 365620
nosy: Volker Wei?mann
priority: normal
severity: normal
status: open
title: Make python -V -V output arguments of configure
type: enhancement

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

From report at bugs.python.org  Thu Apr  2 16:34:49 2020
From: report at bugs.python.org (John Taylor)
Date: Thu, 02 Apr 2020 20:34:49 +0000
Subject: [New-bugs-announce] [issue40160] documentation example of os.walk
 should be less destructive
Message-ID: <1585859689.83.0.950657489634.issue40160@roundup.psfhosted.org>


New submission from John Taylor <johntaylor at gmail.com>:

The example for os.walkdir should be less destructive.  It currently recursively removes all files and directories.  I will be submitting a PR on GitHub.

----------
assignee: docs at python
components: Documentation
messages: 365625
nosy: docs at python, jftuga
priority: normal
severity: normal
status: open
title: documentation example of os.walk should be less destructive
versions: Python 3.8

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

From report at bugs.python.org  Thu Apr  2 18:14:07 2020
From: report at bugs.python.org (Alexander Riccio)
Date: Thu, 02 Apr 2020 22:14:07 +0000
Subject: [New-bugs-announce] [issue40161] Name collisions in pythoncore,
 preventing unity/jumbo build
Message-ID: <1585865647.22.0.641248242876.issue40161@roundup.psfhosted.org>


New submission from Alexander Riccio <test35965 at gmail.com>:

This isn't a priority issue I'd say. However, fixing it could yield nice benefits. I ran into this while experimenting with JUMBO/Unity builds as part of a bit of fun I've been having tweaking build options across the CPython ecosystem.

Theoretically, a JUMBO/Unity build could reduce code size, improve performance, and maybe even help code analysis detect more bugs by building everything in a single compilation unit. Link Time Code Generation is great, but usually isn't as good as building everything in a single compilation unit.


An example of an interesting thing noticed while compiling as a Unity build:

This exact variable is defined twice in two separate source files, itertoolsmodule.c:4303, and and collectionsmodule.c:1774:

PyDoc_STRVAR(length_hint_doc, "Private method returning an estimate of len(list(it)).");

...the default Release configuration includes this exact string 12 (!) times.

There's a lot of stuff like that. It's not actually broken, and sometimes it's probably inconvenient to fix it (what are you gonna do? put it in a header?), but it would be nice.

----------
components: Interpreter Core
messages: 365636
nosy: Alexander Riccio
priority: normal
severity: normal
status: open
title: Name collisions in pythoncore, preventing unity/jumbo build
type: compile error
versions: Python 3.9

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

From report at bugs.python.org  Thu Apr  2 20:39:40 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 03 Apr 2020 00:39:40 +0000
Subject: [New-bugs-announce] [issue40162] Upgrade Travis CI to OpenSSL 1.1.1f
Message-ID: <1585874380.21.0.0841454255298.issue40162@roundup.psfhosted.org>


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

Similary to bpo-40146 "Upgrade Azure Pipelines to OpenSSL 1.1.1f", the Travis CI configuration has an OpenSSL version. It's currently 1.1.1d, but the tarball of this version moved from /source/ to /source/old/.

We should upgrade Travis CI configuration to OpenSSL 1.1.1f.

Attached PR does that.

----------
components: Tests
messages: 365652
nosy: vstinner
priority: normal
severity: normal
status: open
title: Upgrade Travis CI to OpenSSL 1.1.1f
versions: Python 3.9

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

From report at bugs.python.org  Thu Apr  2 20:48:58 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 03 Apr 2020 00:48:58 +0000
Subject: [New-bugs-announce] [issue40163] multissl doesn't support tarballs
 in /source/old/
Message-ID: <1585874938.56.0.268058447907.issue40163@roundup.psfhosted.org>


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

Tools/ssl/multissltests.py expects to find OpenSSL tarballs in:
https://www.openssl.org/source/

Like: https://www.openssl.org/source/openssl-1.1.1f.tar.gz

Problem: OpenSSL moves old versions to https://www.openssl.org/source/old/

If Tools/ssl/multissltests.py fails to download a tarball (HTTP error 404), it should try to get it from /source/old/.

It would prevent us to have to upgrade OpenSSL version immediately in all Python branches of all CIs (Azure Pipelines and Travis CI) as soon as OpenSSL decides to move a tarball. This move is not under our control.

Upgrading OpenSSL is a good practice. Breaking our CI is not :-)

----------
components: Demos and Tools
messages: 365654
nosy: christian.heimes, vstinner
priority: normal
severity: normal
status: open
title: multissl doesn't support tarballs in /source/old/
versions: Python 3.9

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

From report at bugs.python.org  Thu Apr  2 20:56:28 2020
From: report at bugs.python.org (Ned Deily)
Date: Fri, 03 Apr 2020 00:56:28 +0000
Subject: [New-bugs-announce] [issue40164] Upgrade Windows and macOS
 installer builds to OpenSSL 1.1.1f
Message-ID: <1585875388.92.0.251240838882.issue40164@roundup.psfhosted.org>


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

1.1.1f released 2020-03-31

Reminder to Windows team to update Windows build.

Reminder to macOS team to update macOS installer build.
(note: please don't submit a PR or patch for this!)

https://www.openssl.org/source/

----------
components: Windows, macOS
messages: 365657
nosy: ned.deily, paul.moore, ronaldoussoren, steve.dower, tim.golden, zach.ware
priority: deferred blocker
severity: normal
stage: needs patch
status: open
title: Upgrade Windows and macOS installer builds to OpenSSL 1.1.1f
versions: Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Thu Apr  2 21:52:03 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Fri, 03 Apr 2020 01:52:03 +0000
Subject: [New-bugs-announce] [issue40165] Hide stderror from the user if
 command failes
Message-ID: <1585878723.67.0.918823600877.issue40165@roundup.psfhosted.org>


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

This is an optional test that would only run if stty size returns a valid output, but if errors I dont think it makes sense to just print that error inside of test logs, there is already a noticement for skipped test.

----------
components: Tests
messages: 365670
nosy: BTaskaya
priority: normal
severity: normal
status: open
title: Hide stderror from the user if command failes
versions: Python 3.9

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

From report at bugs.python.org  Thu Apr  2 23:01:10 2020
From: report at bugs.python.org (Ama Aje My Fren)
Date: Fri, 03 Apr 2020 03:01:10 +0000
Subject: [New-bugs-announce] [issue40166] UNICODE HOWTO: Change the total
 number of code points in the introduction section
Message-ID: <1585882870.71.0.612117283125.issue40166@roundup.psfhosted.org>


New submission from Ama Aje My Fren <amaajemyfren at gmail.com>:

The dev version of CPython gets the latest version of Unicode integrated to it regularly - and usually within dates of the latest version of Unicode coming out.

The Unicode HOWTO documentation has a line in the introduction that refers to the number of Unicode code points assigned so far. This document does not appear to be changed to concur with the number of actual code points supported by CPython or the latest standard by Unicode, Inc (http://www.unicode.org/versions/latest/#Summary).

I propose that a change be done to reflect the current number of code points.

----------
assignee: docs at python
components: Documentation
messages: 365672
nosy: amaajemyfren, docs at python
priority: normal
severity: normal
status: open
title: UNICODE HOWTO: Change the total number of code points in the introduction section
versions: Python 3.9

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

From report at bugs.python.org  Thu Apr  2 23:11:53 2020
From: report at bugs.python.org (Beier Liu)
Date: Fri, 03 Apr 2020 03:11:53 +0000
Subject: [New-bugs-announce] [issue40167] Cython files don't compile on
 Mingw-w64 64-bit
Message-ID: <1585883513.89.0.776539669318.issue40167@roundup.psfhosted.org>


New submission from Beier Liu <imbenliu at gmail.com>:

details in https://github.com/cython/cython/issues/3405

----------
components: Cross-Build
messages: 365673
nosy: Alex.Willmer, Beier Liu
priority: normal
severity: normal
status: open
title: Cython files don't compile on Mingw-w64 64-bit
type: compile error

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

From report at bugs.python.org  Fri Apr  3 04:08:48 2020
From: report at bugs.python.org (Harish Gajjar)
Date: Fri, 03 Apr 2020 08:08:48 +0000
Subject: [New-bugs-announce] [issue40168] import pandas error[python 3.8.]
Message-ID: <1585901328.18.0.45804352886.issue40168@roundup.psfhosted.org>


New submission from Harish Gajjar <harishgajjar26696 at gmail.com>:

Dear Python Developers,
I am writing this to inform you that currently I am using python 3.8 and I installed pandas using "pip install pandas", but when I try to import pandas idle shows some error.

Python 3.8.2 (tags/v3.8.2:7b3ab59, Feb 25 2020, 22:45:29) [MSC v.1916 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license()" for more information.
>>> import pandas as pd
Traceback (most recent call last):
  File "<pyshell#0>", line 1, in <module>
    import pandas as pd
  File "C:\Users\Harish\AppData\Local\Programs\Python\Python38-32\lib\site-packages\pandas\__init__.py", line 55, in <module>
    from pandas.core.api import (
  File "C:\Users\Harish\AppData\Local\Programs\Python\Python38-32\lib\site-packages\pandas\core\api.py", line 29, in <module>
    from pandas.core.groupby import Grouper, NamedAgg
  File "C:\Users\Harish\AppData\Local\Programs\Python\Python38-32\lib\site-packages\pandas\core\groupby\__init__.py", line 1, in <module>
    from pandas.core.groupby.generic import DataFrameGroupBy, NamedAgg, SeriesGroupBy
  File "C:\Users\Harish\AppData\Local\Programs\Python\Python38-32\lib\site-packages\pandas\core\groupby\generic.py", line 60, in <module>
    from pandas.core.frame import DataFrame
  File "C:\Users\Harish\AppData\Local\Programs\Python\Python38-32\lib\site-packages\pandas\core\frame.py", line 124, in <module>
    from pandas.core.series import Series
  File "C:\Users\Harish\AppData\Local\Programs\Python\Python38-32\lib\site-packages\pandas\core\series.py", line 4572, in <module>
    Series._add_series_or_dataframe_operations()
  File "C:\Users\Harish\AppData\Local\Programs\Python\Python38-32\lib\site-packages\pandas\core\generic.py", line 10349, in _add_series_or_dataframe_operations
    from pandas.core.window import EWM, Expanding, Rolling, Window
  File "C:\Users\Harish\AppData\Local\Programs\Python\Python38-32\lib\site-packages\pandas\core\window\__init__.py", line 1, in <module>
    from pandas.core.window.ewm import EWM  # noqa:F401
  File "C:\Users\Harish\AppData\Local\Programs\Python\Python38-32\lib\site-packages\pandas\core\window\ewm.py", line 5, in <module>
    import pandas._libs.window.aggregations as window_aggregations
ImportError: DLL load failed while importing aggregations: The specified module could not be found.

----------
components: Library (Lib)
files: import pandas error report.pdf
messages: 365681
nosy: Harish Gajjar
priority: normal
severity: normal
status: open
title: import pandas error[python 3.8.]
type: compile error
versions: Python 3.8
Added file: https://bugs.python.org/file49028/import pandas error report.pdf

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

From report at bugs.python.org  Fri Apr  3 04:50:08 2020
From: report at bugs.python.org (laike9m)
Date: Fri, 03 Apr 2020 08:50:08 +0000
Subject: [New-bugs-announce] [issue40169] `dis.findlabels()` should accept a
 code object
Message-ID: <1585903808.2.0.0835498531407.issue40169@roundup.psfhosted.org>


New submission from laike9m <laike9m at gmail.com>:

Continuing our discussion in https://bugs.python.org/issue40122.

I would like to make `dis.findlabels()` accept a code object just like other APIs in the dis module. Also this can be a good chance to add tests for it.

----------
components: Library (Lib)
messages: 365684
nosy: laike9m, serhiy.storchaka
priority: normal
severity: normal
status: open
title: `dis.findlabels()` should accept a code object
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Fri Apr  3 07:57:03 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 03 Apr 2020 11:57:03 +0000
Subject: [New-bugs-announce] [issue40170] [C API] Make PyTypeObject
 structure an opaque structure in the public C API
Message-ID: <1585915023.07.0.846808236133.issue40170@roundup.psfhosted.org>


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

Leaking the PyTypeObject structure in the C API indirectly causes ABI issue (especially for statically allocated types), cause practical issues when old fields are removed and new fields are added (ex: tp_vectorcall addition and tp_print removal caused a lot of troubles with C code generated by Cython: see bpo-37250), prevents us to add feature and experiment optimization.

I don't expect that we will be able to make PyTypeObject opaque soon. The purpose of this issue is to track the work done towards this goal.

I propose to slowly prepare the Python code base, the C API and third party code (especially Cython) to make PyTypeObject structure opaque.

We have to identify most common code patterns which access directly PyTypeObject fields, provide helper functions, and ease the migration to solutions which don't access directly PyTypeObject.

See also bpo-39573: "Make PyObject an opaque structure in the limited C API" and bpo-39947 "Make the PyThreadState structure opaque (move it to the internal C API)".

Longer rationale about making structures of the C API opaque:

* https://pythoncapi.readthedocs.io/
* https://pythoncapi.readthedocs.io/bad_api.html
* https://pythoncapi.readthedocs.io/optimization_ideas.html

--

Multiple practical issues are preventing us to make PyTypeObject opaque right now.


(*) Many C extension modules are still using statically allocated types: there is an on-going effort in bpo-40077 to convert C extension modules one by one to PyType_FromSpec().


(*) Py_TYPE(obj)->tp_name is commonly accessed to format an error message. Example:

        PyErr_Format(PyExc_TypeError, "exec() globals must be a dict, not %.100s",
                     Py_TYPE(globals)->tp_name);

I worked on bpo-34595 and started a discussion on python-dev to propose to add a new %T formatter to PyUnicode_FromFormatV() and so indirectly to PyUnicode_FromFormat() and PyErr_Format():
https://mail.python.org/archives/list/python-dev at python.org/thread/HKYUMTVHNBVB5LJNRMZ7TPUQKGKAERCJ/#3UAMHYG6UF4MPLXBZORHO4JVKUBRUZ53

Sadly, we failed to reach a consensus and I gave up on this idea. We should reconsider this idea.

We need to agree on how types should be formatted:

* just the name without any dot "type_name",
* qualified name "something.type_name",
* fully qualified name "module.something.type_name"

There is also the question of breaking applications which rely on the current exact error message. And the question of removing legacy "%.100s" which was used before Python was able to allocate a buffer large enough to arbitrary string length. When an error is formatted in pure Python, names are never truncated.


(*) Call the function of the parent type when a method is overriden in a subclass. Example with PyTypeObject.tp_free called in a deallocator:

static void
abc_data_dealloc(_abc_data *self)
{
    PyTypeObject *tp = Py_TYPE(self);
    ...
    tp->tp_free(self);
    Py_DECREF(tp);
}


(*) The PEP 384 provides the most generic PyType_GetSlot() but it's not convenient to use: need to handle error (NULL), need to cast the void* into the expected type (error prone cast), etc.

We should slowly add more and more helper functions for most common use cases. We can try to convert a few C extension modules of the Python stdlib to see which use cases are the most common.

Hopefully, many use cases are already abstracted by widely used functions like PyNumber_Add(), PySequence_Size(), etc.


(*) Likely other issues that I forgot.

----------
components: C API
messages: 365689
nosy: vstinner
priority: normal
severity: normal
status: open
title: [C API] Make PyTypeObject structure an opaque structure in the public C API
versions: Python 3.9

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

From report at bugs.python.org  Fri Apr  3 10:41:40 2020
From: report at bugs.python.org (Konrad Borowski)
Date: Fri, 03 Apr 2020 14:41:40 +0000
Subject: [New-bugs-announce] [issue40171] Attempting to import inaccessible
 package imports an empty package
Message-ID: <1585924900.04.0.815860911425.issue40171@roundup.psfhosted.org>


New submission from Konrad Borowski <konrad at borowski.pw>:

The attached shell program returns `AttributeError: module 'mod' has no attribute 'x'`. I would rather expect `ImportError` instead of loading an empty package due to permission error causing Python module to be inaccessible.

----------
files: demonstration
messages: 365699
nosy: xfix
priority: normal
severity: normal
status: open
title: Attempting to import inaccessible package imports an empty package
type: behavior
versions: Python 3.8
Added file: https://bugs.python.org/file49029/demonstration

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

From report at bugs.python.org  Fri Apr  3 10:55:40 2020
From: report at bugs.python.org (Yudi)
Date: Fri, 03 Apr 2020 14:55:40 +0000
Subject: [New-bugs-announce] [issue40172] ZipInfo corrupts file names in
 some old zip archives
Message-ID: <1585925740.74.0.493426565247.issue40172@roundup.psfhosted.org>


New submission from Yudi <yudilevi at gmail.com>:

Some old zip files that don't yet use unicode file names might have entries with characters beyond the ascii range.
ZipInfo seems to encode these file names with 'cp437' codepage (correct for old zips) but decode them back with 'ascii' code page which might corrupt them.

----------
components: Library (Lib)
files: example.zip
messages: 365701
nosy: yudilevi
priority: normal
severity: normal
status: open
title: ZipInfo corrupts file names in some old zip archives
type: behavior
versions: Python 3.8
Added file: https://bugs.python.org/file49030/example.zip

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

From report at bugs.python.org  Fri Apr  3 11:18:43 2020
From: report at bugs.python.org (Paul Ganssle)
Date: Fri, 03 Apr 2020 15:18:43 +0000
Subject: [New-bugs-announce] [issue40173] test.support.import_fresh_module
 fails to correctly block submodules when fresh is specified
Message-ID: <1585927123.84.0.0735169096885.issue40173@roundup.psfhosted.org>


New submission from Paul Ganssle <p.ganssle at gmail.com>:

It seems that test.support.import_fresh_module gets tripped up with its module blocking when you attempt to get a fresh copy of a submodule of a module where you are also importing the module that you are trying to block (bit of a doozy of a sentence there...). So, for example, with the following configuration in mymodule/__init__.py:

    from .other import other
    
    try:
        from ._a import attr
    except ImportError:
        from ._b import attr

(Assuming _a.attr = "A" and _b.attr = "B"), if you attempt to do:

    m = test.support.import_fresh_module("mymodule", fresh=("mymodule._other",), blocked=("mymodule._a"))

Then you'll find that m.attr is pulled from _a.attr. Here's a small script to demonstrate:

    from test.support import import_fresh_module
    import sys

    def import_ab(fresh_other):
        fresh = ("mymodule._other", ) if fresh_other else ()

        mods_out = []
        for to_block in "_b", "_a":
            blocked = (f"mymodule.{to_block}",)

            mods_out.append(import_fresh_module("mymodule",
                                                fresh=fresh, blocked=blocked))
        return mods_out


    for fresh_other in [True, False]:
        mymodule_a, mymodule_b = import_ab(fresh_other)

        qualifier = "With" if fresh_other else "Without"
        print(f"{qualifier} a fresh import of mymodule._other")

        print(f"a: {mymodule_a.attr}")
        print(f"b: {mymodule_b.attr}")
        print()

When you run it with a suitably configured module on Python 3.8:

$ python importer.py 
With a fresh import of mymodule._other
a: A
b: A

Without a fresh import of mymodule._other
a: A
b: B

It also happens if you add `mymodule._a` or `mymodule._b` to the fresh list when you are trying to block the other one.

I *think* the problem is that in the step where _save_and_remove_module is called on fresh_name (see here: https://github.com/python/cpython/blob/76db37b1d37a9daadd9e5b320f2d5a53cd1352ec/Lib/test/support/__init__.py#L328-L329), it's necessarily populating `sys.modules` with a fresh import of the top-level module we're trying to import (mymodule) *before* the blocking goes into effect, then the final call to importlib.import_module just hits that cache.

I think either of the following options will fix this issue:

1. Switching the order of how "fresh" and "blocked" are resolved or
2. Deleting `sys.modules[name]` if it exists immediately before calling `importlib.import_module(name)

That said, I'm still having some weird statefulness problems if I block a C module's import and *then* block a Python module's import, so there may be some other underlying pathology to the current approach.

----------
components: Tests
files: test_support_repro.zip
messages: 365702
nosy: brett.cannon, eric.snow, ncoghlan, p-ganssle
priority: normal
severity: normal
status: open
title: test.support.import_fresh_module fails to correctly block submodules when fresh is specified
type: behavior
versions: Python 3.7, Python 3.8, Python 3.9
Added file: https://bugs.python.org/file49031/test_support_repro.zip

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

From report at bugs.python.org  Fri Apr  3 11:30:09 2020
From: report at bugs.python.org (=?utf-8?b?SsOpcsO0bWU=?=)
Date: Fri, 03 Apr 2020 15:30:09 +0000
Subject: [New-bugs-announce] [issue40174] HAVE_CLOCK_GETTIME not repected in
 pytime.c
Message-ID: <1585927809.98.0.29079570836.issue40174@roundup.psfhosted.org>


New submission from J?r?me <jerome.hamm at gmail.com>:

Hi,

In the file Python/pytime.c (line 886 and others), functions and constants that I infer should be declared by HAVE_CLOCK_GETTIME are called without #ifdef.

Best regards,
J?r?me.

----------
components: Interpreter Core
messages: 365703
nosy: jerome.hamm
priority: normal
severity: normal
status: open
title: HAVE_CLOCK_GETTIME not repected in pytime.c
type: compile error
versions: Python 3.8

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

From report at bugs.python.org  Fri Apr  3 11:38:22 2020
From: report at bugs.python.org (nergall2)
Date: Fri, 03 Apr 2020 15:38:22 +0000
Subject: [New-bugs-announce] [issue40175] Add support for removing zip entry
 in ZipInfo
Message-ID: <1585928302.7.0.507906192941.issue40175@roundup.psfhosted.org>


New submission from nergall2 <yudilevi at gmail.com>:

ZipInfo currently only allow adding entries to zip archives but doesn't have the ability to remove entries from them - pretty useful feature.

----------
components: Library (Lib)
messages: 365704
nosy: nergall2
priority: normal
severity: normal
status: open
title: Add support for removing zip entry in ZipInfo
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Fri Apr  3 13:58:44 2020
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 03 Apr 2020 17:58:44 +0000
Subject: [New-bugs-announce] [issue40176] unterminated string literal
 tokenization error messages could be better
Message-ID: <1585936724.82.0.54480834244.issue40176@roundup.psfhosted.org>


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

It has been pointed out to me that the errors the tokenizer produces for unterminated strings, "EOL while scanning string literal" and "EOF while scanning triple-quoted string literal", contain parsing jargon that make it difficult for new users to understand the problem, likely a missing quote.

----------
components: Interpreter Core
messages: 365713
nosy: benjamin.peterson
priority: normal
severity: normal
status: open
title: unterminated string literal tokenization error messages could be better
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Fri Apr  3 23:36:05 2020
From: report at bugs.python.org (Arnuld)
Date: Sat, 04 Apr 2020 03:36:05 +0000
Subject: [New-bugs-announce] [issue40177] Python Language Reference
 Documentation
Message-ID: <1585971365.58.0.193657354587.issue40177@roundup.psfhosted.org>


New submission from Arnuld <lispyarnuld at gmail.com>:

In section "6.10.1 Value comparisons", it is written:

https://docs.python.org/3/reference/expressions.html

"The not-a-number values float('NaN') and decimal.Decimal('NaN') are
special. Any ordered comparison of a number to a not-a-number value is
false. A counter-intuitive implication is that not-a-number values are
not equal to themselves. For example, if x = float('NaN'), 3 < x, x <
3, x == x, x != x are all false. This behavior is compliant with IEEE
754."

Last comparison "x != x" does not return False, it returns True. Here is the output from my iPython interpeter I am using on Arch Linux (latest as of today):

In [86]: x == y
Out[86]: False

In [87]: x != y
Out[87]: True


I verified the bug it on Wikipedia too:

https://en.wikipedia.org/wiki/NaN#Comparison_with_NaN

----------
assignee: docs at python
components: Documentation
files: Screenshot_2020-04-04 6 Expressions ? Python 3 8 2 documentation.png
messages: 365742
nosy: ArnuldOnData, docs at python
priority: normal
severity: normal
status: open
title: Python Language Reference Documentation
type: enhancement
versions: Python 3.7, Python 3.8, Python 3.9
Added file: https://bugs.python.org/file49033/Screenshot_2020-04-04 6 Expressions ? Python 3 8 2 documentation.png

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

From report at bugs.python.org  Sat Apr  4 08:25:08 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 04 Apr 2020 12:25:08 +0000
Subject: [New-bugs-announce] [issue40178] Convert the remaining os funtions
 to Argument Clinic
Message-ID: <1586003108.43.0.643087706293.issue40178@roundup.psfhosted.org>


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

The proposed PR converts os.getgrouplist(), os.initgroups(), os.sendfile() and os.get_terminal_size() to Argument Clinic.

----------
components: Extension Modules
messages: 365762
nosy: serhiy.storchaka
priority: normal
severity: normal
status: open
title: Convert the remaining os funtions to Argument Clinic
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Sat Apr  4 12:26:41 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 04 Apr 2020 16:26:41 +0000
Subject: [New-bugs-announce] [issue40179] Argument Clinic incorretly
 translates #elif
Message-ID: <1586017601.68.0.788293930127.issue40179@roundup.psfhosted.org>


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

It converts

    #if A
    ...
    #elif B
    ...
    #else
    ...
    #endif

into

    #if A
    ...
    #endif /* A */

    #if B
    ...
    #endif /* B */

    #if !B
    ...
    #endif /* !B */

The correct translation is:

    #if A
    ...
    #endif /* A */

    #if !A && B
    ...
    #endif /* !A && B */

    #if !A && !B
    ...
    #endif /* !A && !B */

----------
components: Argument Clinic, Build
messages: 365769
nosy: larry, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Argument Clinic incorretly translates #elif
type: compile error
versions: Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Sat Apr  4 15:28:49 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 04 Apr 2020 19:28:49 +0000
Subject: [New-bugs-announce] [issue40180] isinstance(cls_with_metaclass,
 non_type) raises KeyError
Message-ID: <1586028529.92.0.773288395215.issue40180@roundup.psfhosted.org>


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

Consider class Object defined as follows:

import types
class Type(type):
    __class__ = property({}.__getitem__, {}.__setitem__)
class Object(metaclass=Type):
    __slots__ = '__class__'

isinstance(Object, ob) is true for type and Type and false for anything else.  But for the examples of the latter that I tried, (list, int, types.CodeType, types.MethodType, see attached tem3.py), it incorrectly raises
  KeyError: <class '__main__.Object'> 

I cannot find the C source for isinstance.  In Python/bltinmodule.c, function builtin_isinstance_impl wraps
  retval = PyObject_IsInstance(obj, class_or_tuple);
but grepping for PyObject_IsInstance in *.c and *.h only returned other calls.

----------
components: Interpreter Core
files: tem3.py
messages: 365774
nosy: terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: isinstance(cls_with_metaclass, non_type) raises KeyError
type: behavior
versions: Python 3.7, Python 3.8, Python 3.9
Added file: https://bugs.python.org/file49034/tem3.py

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

From report at bugs.python.org  Sat Apr  4 16:28:14 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 04 Apr 2020 20:28:14 +0000
Subject: [New-bugs-announce] [issue40181] IDLE: remove positional-only note
 from calltips
Message-ID: <1586032094.19.0.965319984529.issue40181@roundup.psfhosted.org>


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

IDLE calltips currently contain "  # '/' marks preceding args as positional-only." when the signature contains '/' because, before 3.8, '/' was only used by argument clinic and only displayed by inspect.signature.  Now that '/' is a regular part of Python, the special note is not needed for the 3.8+ versions of IDLE.

The get_argspec docstring also needs updating, and I think the body has some redundant code.  The main test change needed is to remove the '/' note from expected returns.  I may first isolate any affected tests to minimize the difference between 3.7 and 3.8-9 code, so as to minimize the possibility of merge conflicts in backports.

----------
messages: 365777
nosy: terry.reedy
priority: normal
severity: normal
stage: test needed
status: open
title: IDLE: remove positional-only note from calltips
type: enhancement
versions: Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Sat Apr  4 16:42:01 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 04 Apr 2020 20:42:01 +0000
Subject: [New-bugs-announce] [issue40182] Remove the _field_types attribute
 of NamedTuple
Message-ID: <1586032921.73.0.44858415086.issue40182@roundup.psfhosted.org>


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

It was deprecated since 3.8 (see issue36320). The __annotations__ attribute has the same information.

----------
components: Library (Lib)
messages: 365780
nosy: gvanrossum, levkivskyi, rhettinger, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Remove the _field_types attribute of NamedTuple
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Sat Apr  4 16:45:48 2020
From: report at bugs.python.org (=?utf-8?b?SsOpcsO0bWU=?=)
Date: Sat, 04 Apr 2020 20:45:48 +0000
Subject: [New-bugs-announce] [issue40183] AC_COMPILE_IFELSE doesn't work in
 all cases
Message-ID: <1586033148.57.0.987289402861.issue40183@roundup.psfhosted.org>


New submission from J?r?me <jerome.hamm at gmail.com>:

Just compiling the symbol sometimes gives a false positive (for example chroot compiles OK), but also linking properly detects the symbol is missing.

----------
components: Interpreter Core
messages: 365781
nosy: jerome.hamm
priority: normal
severity: normal
status: open
title: AC_COMPILE_IFELSE doesn't work in all cases
type: compile error
versions: Python 3.9

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

From report at bugs.python.org  Sat Apr  4 16:52:56 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Sat, 04 Apr 2020 20:52:56 +0000
Subject: [New-bugs-announce] [issue40184] Compiler warnings under sparc64
Message-ID: <1586033576.89.0.798054068129.issue40184@roundup.psfhosted.org>


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

gcc -pthread -c -Wno-unused-result -Wsign-compare -g -Og -Wall    -std=c99 -Wextra -Wno-unused-result -Wno-unused-parameter -Wno-missing-field-initializers -Werror=implicit-function-declaration -fvisibility=hidden  -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o Python/symtable.o Python/symtable.c
Python/pyhash.c:416:1: warning: ?pysiphash? defined but not used [-Wunused-function]
  416 | pysiphash(const void *src, Py_ssize_t src_sz) {
      | ^~~~~~~~~
gcc -pthread -c -Wno-unused-result -Wsign-compare -g -Og -Wall    -std=c99 -Wextra -Wno-unused-result -Wno-unused-parameter -Wno-missing-field-initializers -Werror=implicit-function-declaration -fvisibility=hidden  -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE \
        -DABIFLAGS='"d"' \
        -DPLATLIBDIR='"lib"' \
        -DMULTIARCH=\"sparc64-linux-gnu\" \
        -o Python/sysmodule.o ./Python/sysmodule.c

----------
messages: 365782
nosy: BTaskaya
priority: normal
severity: normal
status: open
title: Compiler warnings under sparc64

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

From report at bugs.python.org  Sat Apr  4 17:08:45 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 04 Apr 2020 21:08:45 +0000
Subject: [New-bugs-announce] [issue40185] Refactor typing.NamedTuple
Message-ID: <1586034525.17.0.360408189871.issue40185@roundup.psfhosted.org>


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

typing.NamedTuple is used in two ways.

1. It is a callable which produces a new namedtuple type.
2. It can also be used as a base in the class statement for creating a new namedtuple type.

In both cases it is not a real class. You cannot create an instance of NamedTuple or a subclass of NamedTuple. But it is implemented as a class, and help() shows methods and data descriptors for it, which are useless.

The proposed PR implements NamedTuple like a function. Implementation of the __mro_entries__ method allows to use it as a base in the class statement.

----------
components: Library (Lib)
messages: 365783
nosy: gvanrossum, levkivskyi, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Refactor typing.NamedTuple
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Sat Apr  4 17:11:33 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Sat, 04 Apr 2020 21:11:33 +0000
Subject: [New-bugs-announce] [issue40186] test_notify_all hangs forever in
 sparc64
Message-ID: <1586034693.88.0.554542653956.issue40186@roundup.psfhosted.org>


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

isidentical at gcc202:~/cpython$ ./python -m test test_multiprocessing_fork -m test_notify_all -v
== CPython 3.9.0a5+ (heads/bpo-40184:b2504dfd51, Apr 4 2020, 23:55:00) [GCC 9.3.0]
== Linux-5.4.0-4-sparc64-smp-sparc64-with-glibc2.31 big-endian
== cwd: /home/isidentical/cpython/build/test_python_596632
== CPU count: 64
== encodings: locale=UTF-8, FS=utf-8
0:00:00 load avg: 3.29 Run tests sequentially
0:00:00 load avg: 3.29 [1/1] test_multiprocessing_fork
test_notify_all (test.test_multiprocessing_fork.WithManagerTestCondition) ... ok
test_notify_all (test.test_multiprocessing_fork.WithProcessesTestCondition) ... ok
test_notify_all (test.test_multiprocessing_fork.WithThreadsTestCondition) ...

----------
components: Tests
messages: 365784
nosy: BTaskaya
priority: normal
severity: normal
status: open
title: test_notify_all hangs forever in sparc64
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Sat Apr  4 17:20:39 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 04 Apr 2020 21:20:39 +0000
Subject: [New-bugs-announce] [issue40187] Refactor typing.TypedDict
Message-ID: <1586035239.71.0.90938203594.issue40187@roundup.psfhosted.org>


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

typing.TypedDict is used in two ways.

1. It is a callable which produces a new pseudo-subtype of dict.
2. It can also be used as a base in the class statement for creating a new pseudo-subtype of dict.

In both cases it is not a real class. You cannot create an instance of TypedDict or its "subclass". isinstance() and issubclass() do not work with it. Instantiating it "subclass" always returns a dict. But it is implemented as a class, and help() shows methods and data descriptors for it, which are useless.

The proposed PR implements TypedDict as a function. It adds the __mro_entries__ method that allows to use it as a base in the class statement.

----------
components: Library (Lib)
messages: 365786
nosy: gvanrossum, levkivskyi, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Refactor typing.TypedDict
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Sat Apr  4 18:19:43 2020
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 04 Apr 2020 22:19:43 +0000
Subject: [New-bugs-announce] [issue40188] Azure Pipelines jobs failing
 randomy with: Unable to connect to azure.archive.ubuntu.com
Message-ID: <1586038783.25.0.595016433162.issue40188@roundup.psfhosted.org>


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

Example:

https://github.com/python/cpython/pull/19375/checks?check_run_id=561058404
of https://github.com/python/cpython/pull/19375

The Install Dependencies step failed with:

 sudo ./.github/workflows/posix-deps-apt.sh && sudo apt-get install wamerican
(...)
Err:1 http://azure.archive.ubuntu.com/ubuntu bionic/universe amd64 lcov all 1.13-3
  Could not connect to azure.archive.ubuntu.com:80 (52.177.174.250), connection timed out [IP: 52.177.174.250 80]
Err:2 http://azure.archive.ubuntu.com/ubuntu bionic/main amd64 libgdbm-dev amd64 1.14.1-6
  Unable to connect to azure.archive.ubuntu.com:http: [IP: 52.177.174.250 80]
(..)
Err:15 http://azure.archive.ubuntu.com/ubuntu bionic-updates/main amd64 uuid-dev amd64 2.31.1-0.4ubuntu3.6
  Unable to connect to azure.archive.ubuntu.com:http: [IP: 52.177.174.250 80]
Get:5 http://security.ubuntu.com/ubuntu bionic-updates/main amd64 libsqlite3-dev amd64 3.22.0-1ubuntu0.3 [632 kB]
Fetched 632 kB in 1min 1s (10.5 kB/s)
E: Failed to fetch http://azure.archive.ubuntu.com/ubuntu/pool/universe/l/lcov/lcov_1.13-3_all.deb  Could not connect to azure.archive.ubuntu.com:80 (52.177.174.250), connection timed out [IP: 52.177.174.250 80]
E: Failed to fetch http://azure.archive.ubuntu.com/ubuntu/pool/main/g/gdbm/libgdbm-dev_1.14.1-6_amd64.deb  Unable to connect to azure.archive.ubuntu.com:http: [IP: 52.177.174.250 80]
(...)
E: Failed to fetch http://azure.archive.ubuntu.com/ubuntu/pool/main/u/util-linux/uuid-dev_2.31.1-0.4ubuntu3.6_amd64.deb  Unable to connect to azure.archive.ubuntu.com:http: [IP: 52.177.174.250 80]
E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing?
##[error]Process completed with exit code 100.

----------
components: Tests
messages: 365798
nosy: steve.dower, vstinner
priority: normal
severity: normal
status: open
title: Azure Pipelines jobs failing randomy with: Unable to connect to azure.archive.ubuntu.com
versions: Python 3.9

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

From report at bugs.python.org  Sat Apr  4 19:00:56 2020
From: report at bugs.python.org (Guy Kogan)
Date: Sat, 04 Apr 2020 23:00:56 +0000
Subject: [New-bugs-announce] [issue40189] MultiProcessing Subclass -
 overrides run method issue
Message-ID: <1586041256.49.0.0315110613604.issue40189@roundup.psfhosted.org>


New submission from Guy Kogan <Guy.kogan14 at gmail.com>:

unable to override run method. 

when running the code i am unable to run the "run" function

output from the code: 

Process 0 has been created
Process 1 has been created
Join for process <Process name='Process-1' pid=52125 parent=52123 stopped exitcode=0 daemon> is done
Join for process <Process name='Process-2' pid=52126 parent=52123 stopped exitcode=0 daemon> is done
Test Done

----------
files: Multi-processing_SYN_scan.py
messages: 365802
nosy: Python_dev_IL
priority: normal
severity: normal
status: open
title: MultiProcessing Subclass - overrides run method issue
versions: Python 3.8
Added file: https://bugs.python.org/file49035/Multi-processing_SYN_scan.py

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

From report at bugs.python.org  Sat Apr  4 19:57:19 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Sat, 04 Apr 2020 23:57:19 +0000
Subject: [New-bugs-announce] [issue40190] Add support for _SC_AIX_REALMEM in
 posix.sysconf
Message-ID: <1586044639.69.0.554430267599.issue40190@roundup.psfhosted.org>


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

We already have support for linux alternatives of this (PHYS_PAGES * PAGESIZE), it would good to add AIX_REALMEM to sysconf for AIX.

----------
components: Library (Lib)
messages: 365804
nosy: BTaskaya
priority: normal
severity: normal
status: open
title: Add support for _SC_AIX_REALMEM in posix.sysconf
versions: Python 3.9

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

From report at bugs.python.org  Sat Apr  4 20:39:24 2020
From: report at bugs.python.org (Howard Waterfall)
Date: Sun, 05 Apr 2020 00:39:24 +0000
Subject: [New-bugs-announce] [issue40191] tempfile.mkstemp() | Documentation
 Error
Message-ID: <1586047164.62.0.92715958345.issue40191@roundup.psfhosted.org>


New submission from Howard Waterfall <hwaterfall at gmail.com>:

The documentation for tempfile.mkstemp() says:
returns a tuple containing an OS-level handle to an open file (as would be returned by os.open()) and the absolute pathname of that file, in that order.

I don't believe this is correct. It should say:
returns a tuple containing an OS-level file descriptor and the absolute pathname of that file, in that order.

I say this because this works:
    file_descriptor, uri = tempfile.mkstemp()
    open_file = os.fdopen(file_descriptor, 'w')
    open_file.write("hello world")
    print(uri)

but this raises an error:
    open_file, uri = tempfile.mkstemp()
    open_file.write("hello world")
    print(uri)

    Traceback (most recent call last):
    File "test.py", line 78, in <module>
        main()
    File "test.py", line 74, in main
        open_file.write("hello world")
    AttributeError: 'int' object has no attribute 'write'

----------
assignee: docs at python
components: Documentation
messages: 365805
nosy: Howard Waterfall, docs at python
priority: normal
severity: normal
status: open
title: tempfile.mkstemp() | Documentation Error
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Sat Apr  4 21:15:32 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Sun, 05 Apr 2020 01:15:32 +0000
Subject: [New-bugs-announce] [issue40192] time.thread_time isn't outputting
 in nanoseconds in AIX
Message-ID: <1586049332.22.0.327858503775.issue40192@roundup.psfhosted.org>


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

The resolution for thread_time is really low on AIX, but fortunately there is a way to get thread time in nanoseconds with thread_cputime.

-bash-4.4$ ./python
Python 3.9.0a5+ (heads/master:909f4a3, Apr  4 2020, 20:15:24) [C] on aix
Type "help", "copyright", "credits" or "license" for more information.
>>> import time
>>> time.thread_time()
0.02

----------
components: Library (Lib)
messages: 365807
nosy: BTaskaya, pitrou
priority: normal
severity: normal
status: open
title: time.thread_time isn't outputting in nanoseconds in AIX
versions: Python 3.9

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

From report at bugs.python.org  Sat Apr  4 21:50:04 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Sun, 05 Apr 2020 01:50:04 +0000
Subject: [New-bugs-announce] [issue40193] thread.get_native_id() support for
 solaris
Message-ID: <1586051404.09.0.572439986747.issue40193@roundup.psfhosted.org>


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

Solaris supports accessing the native id of thread via pthread_self()
https://docs.oracle.com/cd/E19455-01/806-5257/6je9h032i/index.html#tlib-89129

----------
messages: 365808
nosy: BTaskaya
priority: normal
severity: normal
status: open
title: thread.get_native_id() support for solaris

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

From report at bugs.python.org  Sun Apr  5 05:50:14 2020
From: report at bugs.python.org (cripitone)
Date: Sun, 05 Apr 2020 09:50:14 +0000
Subject: [New-bugs-announce] [issue40194] Document special meanings of a
 single underscore
Message-ID: <1586080214.54.0.704924875033.issue40194@roundup.psfhosted.org>


New submission from cripitone <cri at fsfe.org>:

The official documentation doesn't seem to cover the various meanings/uses of the single underscore "_", in different contexts (not just the interactive interpreter).

See for example:

https://www.datacamp.com/community/tutorials/role-underscore-python

----------
assignee: docs at python
components: Documentation
messages: 365814
nosy: cripitone, docs at python
priority: normal
severity: normal
status: open
title: Document special meanings of a single underscore
type: enhancement

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

From report at bugs.python.org  Sun Apr  5 06:55:01 2020
From: report at bugs.python.org (Sander Land)
Date: Sun, 05 Apr 2020 10:55:01 +0000
Subject: [New-bugs-announce] [issue40195] multiprocessing.Queue.put can fail
 silently due to pickle errors
Message-ID: <1586084101.94.0.0680032285094.issue40195@roundup.psfhosted.org>


New submission from Sander Land <sander.land at cognite.com>:

The multiprocessing Queue uses a thread to pickle and send the object after a call to put. When pickling fails (e.g. due to recursion depth) the exception is not returned to the caller to .put but instead dumped on the screen, leaving any multiprocessing pools in a very unhappy state.

Suggested fix: pickle the object in the same thread as the caller and send the pickled object to the thread, ensuring the caller to .put can catch the exception.

Sad workaround: (un)pickle anything sent via this queue yourself.

----------
components: Library (Lib)
files: minimal_repr.py
messages: 365816
nosy: Sander Land
priority: normal
severity: normal
status: open
title: multiprocessing.Queue.put can fail silently due to pickle errors
type: behavior
versions: Python 3.7
Added file: https://bugs.python.org/file49036/minimal_repr.py

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

From report at bugs.python.org  Sun Apr  5 09:30:26 2020
From: report at bugs.python.org (=?utf-8?q?Wolfgang_St=C3=B6cher?=)
Date: Sun, 05 Apr 2020 13:30:26 +0000
Subject: [New-bugs-announce] [issue40196] symtable.Symbol.is_local() can be
 True for global symbols
Message-ID: <1586093426.2.0.0805536970057.issue40196@roundup.psfhosted.org>


New submission from Wolfgang St?cher <wolfgang at stoecher.com>:

Consider this function:

def f():
	global e
	e = 1

When inspecting symbols with symtable, symbol 'e' will be global and local, whereas is_local() should return False. See the attached file for reproducing. It will output to stdout:

symbol 'e' in function scope: is_global() = True, is_local() = True
global scope: e = 1

----------
components: Library (Lib)
files: global_and_local.py
messages: 365820
nosy: coproc
priority: normal
severity: normal
status: open
title: symtable.Symbol.is_local() can be True for global symbols
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9
Added file: https://bugs.python.org/file49037/global_and_local.py

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

From report at bugs.python.org  Sun Apr  5 12:04:08 2020
From: report at bugs.python.org (Morten Hels)
Date: Sun, 05 Apr 2020 16:04:08 +0000
Subject: [New-bugs-announce] [issue40197] Add microseconds to timing table
 in What's new python 3.8
Message-ID: <1586102648.92.0.310451381261.issue40197@roundup.psfhosted.org>


New submission from Morten Hels <morten at hels.dk>:

It is not immediately obvious to me what the units are in the timing table here: https://docs.python.org/3/whatsnew/3.8.html#demos-and-tools

Clicking through to https://bugs.python.org/issue35884 shows that the unit is microseconds, but I think it would be helpful to many readers to put that information in the docs itself, e.g.,

"Here?s a summary of performance improvements since Python 3.3 (timings are in microseconds):"

----------
assignee: docs at python
components: Demos and Tools, Documentation
messages: 365823
nosy: docs at python, frozenpaving
priority: normal
severity: normal
status: open
title: Add microseconds to timing table in What's new python 3.8
type: enhancement
versions: Python 3.8

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

From report at bugs.python.org  Sun Apr  5 16:20:49 2020
From: report at bugs.python.org (dgelessus)
Date: Sun, 05 Apr 2020 20:20:49 +0000
Subject: [New-bugs-announce] [issue40198] macOS Python builds from
 Python.org ignore DYLD_LIBRARY_PATH due to hardened runtime
Message-ID: <1586118049.02.0.786646499236.issue40198@roundup.psfhosted.org>


New submission from dgelessus <dgelessus+bugs.python.org at me.com>:

Recent Python.org versions of Python for macOS no longer respect the DYLD_LIBRARY_PATH environment variable for extending the dynamic library search path, and the envvar is completely invisible to the Python process. This is the case since at least Python 3.7.7 and Python 3.8.2. It was *not* the case with Python 3.7.5 or Python 3.8.0 or any earlier versions (I haven't tested 3.7.6 and 3.8.1). For example:

$ python3.6 --version
Python 3.6.8
$ DYLD_LIBRARY_PATH=tests/objc python3.6 -c 'import os; print(os.environ.get("DYLD_LIBRARY_PATH"))'
tests/objc
$ python3.7 --version
Python 3.7.7
$ DYLD_LIBRARY_PATH=tests/objc python3.7 -c 'import os; print(os.environ.get("DYLD_LIBRARY_PATH"))'
None

This seems to be because the Python binaries now fulfill the requirements for notarization (as mentioned in https://www.python.org/downloads/release/python-377/#macos-users), which includes enabling the hardened runtime (https://developer.apple.com/documentation/security/hardened_runtime), which by default hides DYLD_LIBRARY_PATH (and other DYLD_... envvars) from the hardened binary.

To disable this protection and allow using DYLD_... envvars again, the entitlement com.apple.security.cs.allow-dyld-environment-variables (https://developer.apple.com/documentation/bundleresources/entitlements/com_apple_security_cs_allow-dyld-environment-variables) can be added to a hardened binary. The Python binaries seem to have some entitlements, but not .allow-dyld-environment-variables:

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

Would it be possible to add this entitlement to the Python binaries, so that DYLD_LIBRARY_PATH can be used again, as was possible in previous versions?

----------
components: macOS
messages: 365824
nosy: dgelessus, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: macOS Python builds from Python.org ignore DYLD_LIBRARY_PATH due to hardened runtime
versions: Python 3.7, Python 3.8

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

From report at bugs.python.org  Sun Apr  5 16:29:24 2020
From: report at bugs.python.org (=?utf-8?q?Michal_Labo=C5=A1?=)
Date: Sun, 05 Apr 2020 20:29:24 +0000
Subject: [New-bugs-announce] [issue40199] Invalid escape sequence
 DeprecationWarnings don't trigger by default
Message-ID: <1586118564.22.0.0408193741044.issue40199@roundup.psfhosted.org>


New submission from Michal Labo? <miso1038 at gmail.com>:

The current warning filter seems to filter out the compile time DeprecationWarnings that get triggered on invalid escape sequences:

import warnings

compile("'\d'", "<string>", "eval")
warnings.resetwarnings()
compile("'\d'", "<string>", "eval")


results in one
<string>:1: DeprecationWarning: invalid escape sequence \d
being printed

----------
messages: 365825
nosy: Michal Labo?
priority: normal
severity: normal
status: open
title: Invalid escape sequence DeprecationWarnings don't trigger by default
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Sun Apr  5 18:44:37 2020
From: report at bugs.python.org (Talha Demirsoy)
Date: Sun, 05 Apr 2020 22:44:37 +0000
Subject: [New-bugs-announce] [issue40200] count 0 crash
Message-ID: <1586126677.48.0.798770412189.issue40200@roundup.psfhosted.org>


New submission from Talha Demirsoy <talhademirsoy at gmail.com>:

Dear Python Developers,

I made a program that finds how many 0's at the end of the number

But when I enter number has 23 zero its okay but when I enter number has 24 zero its crash

----------
components: Build
files: howmany0.py
messages: 365827
nosy: talha.demirsoy
priority: normal
severity: normal
status: open
title: count 0 crash
type: crash
versions: Python 3.8
Added file: https://bugs.python.org/file49038/howmany0.py

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

From report at bugs.python.org  Sun Apr  5 22:02:50 2020
From: report at bugs.python.org (Talha Demirsoy)
Date: Mon, 06 Apr 2020 02:02:50 +0000
Subject: [New-bugs-announce] [issue40201] Last digit count error
Message-ID: <1586138570.61.0.875101081918.issue40201@roundup.psfhosted.org>


New submission from Talha Demirsoy <talhademirsoy at gmail.com>:

When I try to enter 10^23 or less its gives me ture but when I  tried 10^24 and more its give me just 1

----------
files: howmany0.py
messages: 365834
nosy: talha.demirsoy
priority: normal
severity: normal
status: open
title: Last digit count error
type: crash
versions: Python 3.8
Added file: https://bugs.python.org/file49039/howmany0.py

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

From report at bugs.python.org  Mon Apr  6 04:16:14 2020
From: report at bugs.python.org (Jacob RR)
Date: Mon, 06 Apr 2020 08:16:14 +0000
Subject: [New-bugs-announce] [issue40202] Misleading grammatically of
 ValueError Message?
Message-ID: <1586160974.41.0.711704681431.issue40202@roundup.psfhosted.org>


New submission from Jacob RR <xboxgamermaple at gmail.com>:

hi,

so I *think* that ValueError shows an error grammatically incorrect?
In python 2.7
>>> x = [1,2,3]
>>> f,x, a, b = [1,2,3]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: need more than 3 values to unpack

Should have said: Received 3 values to unpack ?
The problem with that is the list size is 3 and the error says that I need more than 3 values to unpack which is logically wrong **IMHO** (don't kill me if im mistaken)

Now if I try to do something else, for example:

>>> x = [1,2,3]
>>> a, b = [1,2,3]

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: too many values to unpack

It says **too many** but I assign a few than the size of the list. am I the one who wrong here?

Now, I code in Python 3 I'm not a professional  like you, I'm novice and try to learn.. I'll get to the point, the same code in Python 3.7.6 (Anaconda, pip is disappoint me :< )

>>> a = [1,2,3]
>>> x,y = a
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: too many values to unpack (expected 2)

Should said something else because it received less values and expected should say 3 and not 2, correct?


thanks for reading.




PS: Sorry I'm not a native speaker and I might be wrong and am very sorry if time wasted.

----------
assignee: docs at python
components: Documentation
messages: 365842
nosy: Jacob RR, docs at python
priority: normal
severity: normal
status: open
title: Misleading grammatically of ValueError Message?
type: enhancement
versions: Python 3.7

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

From report at bugs.python.org  Mon Apr  6 08:59:15 2020
From: report at bugs.python.org (=?utf-8?q?Volker_Wei=C3=9Fmann?=)
Date: Mon, 06 Apr 2020 12:59:15 +0000
Subject: [New-bugs-announce] [issue40203] Warn about invalid PYTHONUSERBASE
Message-ID: <1586177955.41.0.354760283694.issue40203@roundup.psfhosted.org>


New submission from Volker Wei?mann <volker.weissmann at gmx.de>:

https://docs.python.org/2/using/cmdline.html says that PYTHONUSERBASE defines the user base directory. If I understand this correctly, this implies that PYTHONUSERBASE should be a path a directory. I therefore think that python should print a warning if PYTHONUSERBASE is:
1. Not a valid path (e.g. "invalid//path")
2. A path to something else than a directory
3. A non existing path (maybe)


I think that

export PYTHONUSERBASE="invalid//path"
python

should generate a warning, because there is no good reason to do so.

----------
messages: 365851
nosy: Volker Wei?mann
priority: normal
severity: normal
status: open
title: Warn about invalid PYTHONUSERBASE
type: enhancement

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

From report at bugs.python.org  Mon Apr  6 10:32:48 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 06 Apr 2020 14:32:48 +0000
Subject: [New-bugs-announce] [issue40204] Docs build error with Sphinx 3.0
 due to invalid C declaration
Message-ID: <1586183568.2.0.322929459864.issue40204@roundup.psfhosted.org>


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

The following error is caused in Docs build for a 3.8 backport since sphinx is ran with warnings. Sphinx released 3.0 on April 6. The last successful build on master uses Sphinx 2.2.0 [0]. My guess is sphinx new version possibly breaking the build on Python 3.8 where it's not pinned to use 2.2.0 pulling the latest version. The changelog for Sphinx has below note :

https://www.sphinx-doc.org/en/master/changes.html#release-3-0-0-released-apr-06-2020 

The C domain has been rewritten, with additional directives and roles. The existing ones are now more strict, resulting in new warnings.

Python 3.8 and Python 3.7 doesn't have Sphinx pinned to 2.2.0 while master does.

Python 3.8 Docs makefile : https://github.com/python/cpython/blob/f7b0259d0d243a71d79a3fda9ec7aad4306513eb/Doc/Makefile#L146

Failed build :

https://github.com/python/cpython/pull/19388/checks?check_run_id=563053793#step:7:46

Error :

Warning, treated as error:
/home/runner/work/cpython/cpython/Doc/c-api/buffer.rst:92:Error in declarator or parameters
Invalid C declaration: Expected identifier in nested name. [error at 5]
  void \*buf
  -----^
Makefile:49: recipe for target 'build' failed
make[1]: *** [build] Error 2


[0] https://github.com/python/cpython/runs/564123625#step:6:24

----------
assignee: docs at python
components: Documentation
messages: 365858
nosy: docs at python, eric.araujo, ezio.melotti, mdk, rhettinger, vstinner, willingc, xtreak
priority: normal
severity: normal
status: open
title: Docs build error with Sphinx 3.0 due to invalid C declaration
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Mon Apr  6 10:43:33 2020
From: report at bugs.python.org (Bar Harel)
Date: Mon, 06 Apr 2020 14:43:33 +0000
Subject: [New-bugs-announce] [issue40205] Profile 'builtins' parameter
 documentation missing
Message-ID: <1586184213.23.0.0753500955635.issue40205@roundup.psfhosted.org>


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

Profile and cProfile's documentation does not say anything about the builtins parameter.
Also, it exists only on cProfile, which means Profile is not a drop-in replacement.
Lastly, enable() method, that exists on cProfile, also accepts params, and are undocumented.

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 365859
nosy: bar.harel, docs at python
priority: normal
severity: normal
status: open
title: Profile 'builtins' parameter documentation missing
versions: Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Mon Apr  6 11:17:48 2020
From: report at bugs.python.org (ahmad dana)
Date: Mon, 06 Apr 2020 15:17:48 +0000
Subject: [New-bugs-announce] [issue40206] Multiplying 4.6*100 will result in
 459.99999999999994
Message-ID: <1586186268.64.0.709905151161.issue40206@roundup.psfhosted.org>


New submission from ahmad dana <ahmadjd94 at gmail.com>:

While we using python3.7 to do some  number multiplication, we faced an issue with multiplying 4.6*100 which lead to strange output, the result was 459.99999999999994, while it should be something like 460.00

----------
messages: 365860
nosy: ahmad dana
priority: normal
severity: normal
status: open
title: Multiplying 4.6*100 will result in 459.99999999999994
versions: Python 3.7

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

From report at bugs.python.org  Mon Apr  6 11:55:12 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Mon, 06 Apr 2020 15:55:12 +0000
Subject: [New-bugs-announce] [issue40207] Expose NCURSES_EXT_FUNCS under
 curses
Message-ID: <1586188512.46.0.148388356677.issue40207@roundup.psfhosted.org>


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

NCURSES_EXT_FUNCS defines the extension version number which is needed to determine if certain functions exist or not.

----------
components: Library (Lib)
messages: 365866
nosy: BTaskaya
priority: normal
severity: normal
status: open
title: Expose NCURSES_EXT_FUNCS under curses
versions: Python 3.9

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

From report at bugs.python.org  Mon Apr  6 13:05:22 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Mon, 06 Apr 2020 17:05:22 +0000
Subject: [New-bugs-announce] [issue40208] Remove deprecated
 SymbolTable.has_exec
Message-ID: <1586192722.9.0.88612242995.issue40208@roundup.psfhosted.org>


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

SymbolTable's has_exec method deprecated 14 years ago (2006) with 2def557aba1aaa42b638f9bf95624b7e6929191c, it can be safely removed since there is no user of it.

----------
components: Library (Lib)
messages: 365874
nosy: BTaskaya
priority: normal
severity: normal
status: open
title: Remove deprecated SymbolTable.has_exec
versions: Python 3.9

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

From report at bugs.python.org  Mon Apr  6 14:30:46 2020
From: report at bugs.python.org (Hakan)
Date: Mon, 06 Apr 2020 18:30:46 +0000
Subject: [New-bugs-announce] [issue40209] read_pyfile function refactor in
 Lib/test/test_unparse.py
Message-ID: <1586197846.97.0.19099018734.issue40209@roundup.psfhosted.org>


New submission from Hakan <hakancelik96 at outlook.com>:

The read_pyfile function can be written more effectively with the open function in the tokenize module.

----------
components: Tests
messages: 365875
nosy: hakancelik
priority: normal
severity: normal
status: open
title: read_pyfile function refactor in Lib/test/test_unparse.py
versions: Python 3.9

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

From report at bugs.python.org  Mon Apr  6 16:18:21 2020
From: report at bugs.python.org (Nikolai Ehrhardt)
Date: Mon, 06 Apr 2020 20:18:21 +0000
Subject: [New-bugs-announce] [issue40210] ttk.Combobox focus-out event
 inheritage
Message-ID: <1586204301.95.0.352088098712.issue40210@roundup.psfhosted.org>


New submission from Nikolai Ehrhardt <n.ehrhardt88 at gmail.com>:

Hi Guys,

I'm spawning entry fields in a treeview to make values editable while runtime, my codepiece:

the edit method is bind to left click:

    def edit(self, event):
        region = self.identify_region(event.x, event.y)
        if region == 'cell':
            # the user clicked on a cell

            def enter(event):
                self.set(item, column, entry.get())
                entry.destroy()

            column = self.identify_column(event.x)  # identify column
            item = self.identify_row(event.y)  # identify item
            self.parent_split = self.parent(item).split("__", 1)
            print(column, item, self.parent_split)
            if not tree_const.isEntryField(self.parent_split, column) or len(self.get_children(item)):
                return
                
            x, y, width, height = self.bbox(item, column) 
            value = self.set(item, column)
            entry = None
            if tree_const.tc_index_column_map[column] == tree_const.col_op:
                entry = ttk.Combobox(self, state="readonly", values=tree_const.combo_ops)
                entry.bind('<<ComboboxSelected>>', enter) 
                entry.set(value)
            else:
                entry = ttk.Entry(self) 
                entry.insert(0, value)  # put former value in entry
                entry.bind('<Return>', enter)  # validate with Enter     
                    
            entry.bind('<FocusOut>', enter)    
            # display the Entry   
            # create edition entry
            entry.place(x=x, y=y, width=width, height=height,
                        anchor='nw')  # display entry on top of cell
            entry.focus_set()

And now is the problem: The entries are not properly destroyed when focusing out, so I assume, that the button created for combobox, is not well connected to the focus-out event. When the button would just inherit the binding, the combobox would already disappear,while selecting.

So there is some logic missing. For destroying widget properly on focusing out.

----------
files: treeview_spawn_entries.png
messages: 365878
nosy: Nikolai Ehrhardt
priority: normal
severity: normal
status: open
title: ttk.Combobox focus-out event inheritage
type: behavior
versions: Python 3.5
Added file: https://bugs.python.org/file49041/treeview_spawn_entries.png

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

From report at bugs.python.org  Mon Apr  6 18:00:59 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Mon, 06 Apr 2020 22:00:59 +0000
Subject: [New-bugs-announce] [issue40211] Clarify preadv and pwritev is
 supported AIX 7.1 and newer.
Message-ID: <1586210459.59.0.898970260057.issue40211@roundup.psfhosted.org>


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

preadv and pwritev are supported on AIX 7.1 and newer, it would be good to clarify this in the documentation.

----------
assignee: docs at python
components: Documentation
messages: 365880
nosy: BTaskaya, docs at python, pablogsal
priority: normal
severity: normal
status: open
title: Clarify preadv and pwritev is supported AIX 7.1 and newer.
versions: Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Mon Apr  6 21:50:21 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Tue, 07 Apr 2020 01:50:21 +0000
Subject: [New-bugs-announce] [issue40212] Re-enable posix_fallocate and
 posix_fadvise on AIX
Message-ID: <1586224221.66.0.805239264306.issue40212@roundup.psfhosted.org>


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

fallocate and fadvise was problematic in AIX because of a bug that presents at the time of 2014, which looks like resolved in 2016. I think we can safely re-enable those functions back. I've tested this patch on AIX 7.2 and it works, this patch will also require pre-testing of buildbots.

http://www-01.ibm.com/support/docview.wss?uid=isg1IV56170

----------
components: Library (Lib)
messages: 365884
nosy: BTaskaya
priority: normal
severity: normal
status: open
title: Re-enable posix_fallocate and posix_fadvise on AIX
versions: Python 3.9

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

From report at bugs.python.org  Mon Apr  6 22:13:32 2020
From: report at bugs.python.org (John Belmonte)
Date: Tue, 07 Apr 2020 02:13:32 +0000
Subject: [New-bugs-announce] [issue40213] contextlib.aclosing()
Message-ID: <1586225612.65.0.881233882976.issue40213@roundup.psfhosted.org>


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

Please add aclosing() to contextlib, the async equivalent of closing().

It's needed to ensure deterministic call of aclose() on the resource object at block exit.

It's been available in the async_generator module for some time.  However that module is intended to provide async generators to Python 3.5, so it's odd for apps using modern Python versions to depend on it only for aclosing().

https://github.com/python-trio/async_generator/blob/22eddc191c2ae3fc152ca13cf2d6fa55ac3f1568/async_generator/_util.py#L6

----------
components: Library (Lib)
messages: 365885
nosy: John Belmonte, njs
priority: normal
severity: normal
status: open
title: contextlib.aclosing()
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Mon Apr  6 23:27:46 2020
From: report at bugs.python.org (Kyle Stanley)
Date: Tue, 07 Apr 2020 03:27:46 +0000
Subject: [New-bugs-announce] [issue40214]
 test_ctypes.test_load_dll_with_flags Windows failure
Message-ID: <1586230066.46.0.791582618244.issue40214@roundup.psfhosted.org>


New submission from Kyle Stanley <aeros167 at gmail.com>:

In several recent PRs, test_ctypes.test_load_dll_with_flags is failing for the Azure Pipelines "Windows PR tests win32" and "Windows PR tests win64" with the following error message:

```
======================================================================
ERROR: test_load_dll_with_flags (ctypes.test.test_loading.LoaderTest) [WinDLL('_sqlite3.dll', winmode=0)]
----------------------------------------------------------------------
Traceback (most recent call last):
  File "d:\a\1\s\lib\ctypes\test\test_loading.py", line 140, in should_pass
    subprocess.check_output(
  File "d:\a\1\s\lib\subprocess.py", line 419, in check_output
    return run(*popenargs, stdout=PIPE, timeout=timeout, check=True,
  File "d:\a\1\s\lib\subprocess.py", line 533, in run
    raise CalledProcessError(retcode, process.args,
subprocess.CalledProcessError: Command '['d:\\a\\1\\s\\PCbuild\\win32\\python.exe', '-c', "from ctypes import *; import nt;WinDLL('_sqlite3.dll', winmode=0)"]' returned non-zero exit status 1.

======================================================================
ERROR: test_load_dll_with_flags (ctypes.test.test_loading.LoaderTest) [WinDLL('_sqlite3.dll', winmode=0)]
----------------------------------------------------------------------
Traceback (most recent call last):
  File "d:\a\1\s\lib\ctypes\test\test_loading.py", line 140, in should_pass
    subprocess.check_output(
  File "d:\a\1\s\lib\subprocess.py", line 419, in check_output
    return run(*popenargs, stdout=PIPE, timeout=timeout, check=True,
  File "d:\a\1\s\lib\subprocess.py", line 533, in run
    raise CalledProcessError(retcode, process.args,
subprocess.CalledProcessError: Command '['d:\\a\\1\\s\\PCbuild\\win32\\python.exe', '-c', "from ctypes import *; import nt;WinDLL('_sqlite3.dll', winmode=0)"]' returned non-zero exit status 1.
```

Since this only started occurring recently in several unrelated PRs, I suspect it was most likely an intermittent regression introduced in master. Here are the PRs I have seen the same exact error occur in so far:

https://github.com/python/cpython/pull/18239
https://github.com/python/cpython/pull/19403
https://github.com/python/cpython/pull/19402
https://github.com/python/cpython/pull/19399

I was unable to reproduce it locally on my secondary boot of Windows 10.

----------
components: Library (Lib)
keywords: 3.9regression
messages: 365887
nosy: aeros
priority: normal
severity: normal
status: open
title: test_ctypes.test_load_dll_with_flags Windows failure
versions: Python 3.9

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

From report at bugs.python.org  Tue Apr  7 05:25:54 2020
From: report at bugs.python.org (=?utf-8?q?=C3=93scar_Garc=C3=ADa_Amor?=)
Date: Tue, 07 Apr 2020 09:25:54 +0000
Subject: [New-bugs-announce] [issue40215] Use xdg basedir spec on linux
Message-ID: <1586251554.83.0.931067679557.issue40215@roundup.psfhosted.org>


New submission from ?scar Garc?a Amor <ogarcia at moire.org>:

https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html

TLDR; For config files like .pypirc, configuration should be in the $XDG_CONFIG_HOME/python/

----------
components: Distutils
messages: 365899
nosy: dstufft, eric.araujo, ?scar Garc?a Amor
priority: normal
severity: normal
status: open
title: Use xdg basedir spec on linux
type: enhancement

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

From report at bugs.python.org  Tue Apr  7 11:24:36 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Tue, 07 Apr 2020 15:24:36 +0000
Subject: [New-bugs-announce] [issue40216] Support --runstatedir in configure
Message-ID: <1586273076.51.0.57389457106.issue40216@roundup.psfhosted.org>


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

AC allows to set runstatedir but looks like python's configure is a bit outdated, it requires to be regenerated.

----------
components: Build
messages: 365909
nosy: BTaskaya
priority: normal
severity: normal
status: open
title: Support --runstatedir in configure
versions: Python 3.9

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

From report at bugs.python.org  Tue Apr  7 12:23:41 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 07 Apr 2020 16:23:41 +0000
Subject: [New-bugs-announce] [issue40217] The garbage collector doesn't take
 in account that objects of heap allocated types hold a strong reference to
 their type
Message-ID: <1586276621.78.0.843757244355.issue40217@roundup.psfhosted.org>


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

The bpo-35810 modified the object allocate to hold a *strong* reference to the type in PyObject.ob_type, whereas PyObject.ob_type is a *borrowed* references if the type is statically allocated.

commit 364f0b0f19cc3f0d5e63f571ec9163cf41c62958
Author: Eddie Elizondo <eduardo.elizondorueda at gmail.com>
Date:   Wed Mar 27 07:52:18 2019 -0400

    bpo-35810: Incref heap-allocated types in PyObject_Init (GH-11661)
    
    * Incref heap-allocated types in PyObject_Init
    * Add documentation and porting notes to What's New


The problem is now in some corner cases, the GC fails to visit all referrer of a type and so considers that the type is still alive.

bpo-40149 is a concrete example of such bug.

I propose to modify the GC to take bpo-35810 in account.

... or maybe I just misunderstood bpo-40149 bug :-)

----------
components: Interpreter Core
messages: 365911
nosy: pablogsal, vstinner
priority: normal
severity: normal
status: open
title: The garbage collector doesn't take in account that objects of heap allocated types hold a strong reference to their type
versions: Python 3.9

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

From report at bugs.python.org  Tue Apr  7 16:16:39 2020
From: report at bugs.python.org (=?utf-8?q?Volker_Wei=C3=9Fmann?=)
Date: Tue, 07 Apr 2020 20:16:39 +0000
Subject: [New-bugs-announce] [issue40218] sys.executable is a non existing
 path if python is executed from gdb
Message-ID: <1586290599.79.0.960995339825.issue40218@roundup.psfhosted.org>


New submission from Volker Wei?mann <volker.weissmann at gmx.de>:

Note: I'm not sure if this is a bug in python or in gdb. I will also submit a bug report to gdb and post a link here.

Pythons documentation says that sys.executable is always either None, empty string or a path to the python interpreter. Using gdb and python, we can produce situations where this is not true.

Simple but unrealistic way to reproduce this bug:
Install gdb with python support. E.g using
$ pacman -S gdb
Remove all the python binaries:
$ rm /usr/bin/python
$ rm /usr/bin/python3
$ rm /usr/bin/python3.8
Run $gdb -x gdbinit$ with the contents of gdbinit being:
python
import sys
import os
print(sys.executable)
print(os.path.exists(sys.executable))
end

Result:
/usr/bin/python
False

Here, sys.executable is /usr/bin/python, but there is no python executable in /usr/bin/python, because we just deleted it.

Complicated but realistic way to reproduce this bug:
Build gdb with
../configure --with-python=python2
and run gdb with the gdbinit being:
python
import sys
print(sys.executable)
print(sys.version)
end
Result:
/usr/bin/python
2.7.17 (default, Mar 21 2020, 00:47:07) 
[GCC 9.3.0]
Here it says that the python2 executable lies in "/usr/bin/python", even if there is no python2 executable in /usr/bin/python.

----------
messages: 365934
nosy: Volker Wei?mann
priority: normal
severity: normal
status: open
title: sys.executable is a non existing path if python is executed from gdb

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

From report at bugs.python.org  Tue Apr  7 16:42:55 2020
From: report at bugs.python.org (Stephen Bell)
Date: Tue, 07 Apr 2020 20:42:55 +0000
Subject: [New-bugs-announce] [issue40219] ttk LabeledScale: label covered by
 hidden element
Message-ID: <1586292175.49.0.452846630354.issue40219@roundup.psfhosted.org>


New submission from Stephen Bell <bahejlbell at gmail.com>:

The LabeledScale in tkinter.ttk seems to have some kind of hidden element that covers the LabeledScale's label when the value is set to mid-scale. Tested on Windows 10, Python 3.6

See below code to reproduce:

import tkinter
from tkinter import ttk

master = tkinter.Tk()
_out1Value = tkinter.IntVar(master)
out1Slider = ttk.LabeledScale(master, from_=-100, to=100, variable=_out1Value, compound="bottom")
_out1Value.set(0)

# uncomment to "fix"
# out1Slider.label.lift()

out1Slider.pack()

master.mainloop()

----------
components: Tkinter
messages: 365940
nosy: Stephen Bell
priority: normal
severity: normal
status: open
title: ttk LabeledScale: label covered by hidden element
versions: Python 3.6

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

From report at bugs.python.org  Tue Apr  7 17:09:00 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 07 Apr 2020 21:09:00 +0000
Subject: [New-bugs-announce] [issue40220] Modules/gcmodule.c:434:
 update_refs: Assertion "gc_get_refs(gc) != 0" failed
Message-ID: <1586293740.28.0.163587748948.issue40220@roundup.psfhosted.org>


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

ARMv7 Debian buster 3.x:
https://buildbot.python.org/all/#/builders/168/builds/688

0:12:12 load avg: 9.96 [332/420] test_multiprocessing_spawn passed (8 min) -- running: test_zipfile (1 min 11 sec), test_largefile (1 min 25 sec), test_weakref (1 min 17 sec), test_asyncio (1 min 49 sec), test_concurrent_futures (4 min 16 sec)
./Include/object.h:492: _Py_NegativeRefcount: Assertion failed: object has negative ref count
Enable tracemalloc to get the memory block allocation traceback

object address  : 0xb5ef05a0
object refcount : -1
object type     : 0x6f9c6c
object type name: method_descriptor
object repr     : <refcnt -1 at 0xb5ef05a0>

Fatal Python error: _PyObject_AssertFailed: _PyObject_AssertFailed
Python runtime state: finalizing (tstate=0x1e11c50)

Current thread 0xb6f44010 (most recent call first):
<no Python frame>
/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/multiprocessing/resource_tracker.py:216: UserWarning: resource_tracker: There appear to be 1 leaked shared_memory objects to clean up at shutdown
  warnings.warn('resource_tracker: There appear to be %d '
/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/multiprocessing/resource_tracker.py:229: UserWarning: resource_tracker: '/psm_eec4c151': [Errno 2] No such file or directory: '/psm_eec4c151'
  warnings.warn('resource_tracker: %r: %s' % (name, e))

(...)

0:13:03 load avg: 8.51 [355/420/1] test_concurrent_futures failed (5 min 5 sec) -- running: test_asyncio (2 min 40 sec), test_compileall (33.7 sec)
Modules/gcmodule.c:434: update_refs: Assertion "gc_get_refs(gc) != 0" failed
Enable tracemalloc to get the memory block allocation traceback

object address  : 0xb63581c0
object refcount : 0
object type     : 0x69d1d0
object type name: tuple
object repr     : <refcnt 0 at 0xb63581c0>

Fatal Python error: _PyObject_AssertFailed: _PyObject_AssertFailed
Python runtime state: initialized

Current thread 0xb6fb3010 (most recent call first):
  File "/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/typing.py", line 762 in __setattr__
  File "/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/typing.py", line 658 in __init__
  File "/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/typing.py", line 1549 in _alias
  File "/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/typing.py", line 1607 in <module>
  File "<frozen importlib._bootstrap>", line 228 in _call_with_frames_removed
  File "<frozen importlib._bootstrap_external>", line 790 in exec_module
  File "<frozen importlib._bootstrap>", line 680 in _load_unlocked
  File "<frozen importlib._bootstrap>", line 986 in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 1007 in _find_and_load
  File "/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/asyncio/staggered.py", line 6 in <module>
  File "<frozen importlib._bootstrap>", line 228 in _call_with_frames_removed
  File "<frozen importlib._bootstrap_external>", line 790 in exec_module
  File "<frozen importlib._bootstrap>", line 680 in _load_unlocked
  File "<frozen importlib._bootstrap>", line 986 in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 1007 in _find_and_load
  File "<frozen importlib._bootstrap>", line 228 in _call_with_frames_removed
  File "<frozen importlib._bootstrap>", line 1058 in _handle_fromlist
  File "/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/asyncio/base_events.py", line 45 in <module>
  File "<frozen importlib._bootstrap>", line 228 in _call_with_frames_removed
  File "<frozen importlib._bootstrap_external>", line 790 in exec_module
  File "<frozen importlib._bootstrap>", line 680 in _load_unlocked
  File "<frozen importlib._bootstrap>", line 986 in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 1007 in _find_and_load
  File "/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/asyncio/__init__.py", line 8 in <module>
  File "<frozen importlib._bootstrap>", line 228 in _call_with_frames_removed
  File "<frozen importlib._bootstrap_external>", line 790 in exec_module
  File "<frozen importlib._bootstrap>", line 680 in _load_unlocked
  File "<frozen importlib._bootstrap>", line 986 in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 1007 in _find_and_load
  File "<frozen importlib._bootstrap>", line 228 in _call_with_frames_removed
  File "<frozen importlib._bootstrap>", line 972 in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 1007 in _find_and_load
  File "/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/test/support/__init__.py", line 6 in <module>
  File "<frozen importlib._bootstrap>", line 228 in _call_with_frames_removed
  File "<frozen importlib._bootstrap_external>", line 790 in exec_module
  File "<frozen importlib._bootstrap>", line 680 in _load_unlocked
  File "<frozen importlib._bootstrap>", line 986 in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 1007 in _find_and_load
  File "<frozen importlib._bootstrap>", line 228 in _call_with_frames_removed
  File "<frozen importlib._bootstrap>", line 1058 in _handle_fromlist
  File "/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/test/libregrtest/cmdline.py", line 4 in <module>
  File "<frozen importlib._bootstrap>", line 228 in _call_with_frames_removed
  File "<frozen importlib._bootstrap_external>", line 790 in exec_module
  File "<frozen importlib._bootstrap>", line 680 in _load_unlocked
  File "<frozen importlib._bootstrap>", line 986 in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 1007 in _find_and_load
  File "/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/test/libregrtest/__init__.py", line 1 in <module>
  File "<frozen importlib._bootstrap>", line 228 in _call_with_frames_removed
  File "<frozen importlib._bootstrap_external>", line 790 in exec_module
  File "<frozen importlib._bootstrap>", line 680 in _load_unlocked
  File "<frozen importlib._bootstrap>", line 986 in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 1007 in _find_and_load
  File "/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/test/regrtest.py", line 11 in <module>
  File "/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/runpy.py", line 87 in _run_code
  File "/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/runpy.py", line 97 in _run_module_code
  File "/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/runpy.py", line 210 in run_module
  File "/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/multiprocessing/spawn.py", line 258 in _fixup_main_from_name
  File "/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/multiprocessing/spawn.py", line 234 in prepare
  File "/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/multiprocessing/spawn.py", line 125 in _main
  File "/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/multiprocessing/forkserver.py", line 313 in _serve_one
  File "/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/multiprocessing/forkserver.py", line 274 in main
  File "<string>", line 1 in <module>
test_cancel (test.test_concurrent_futures.FutureTests) ... ok
test_cancelled (test.test_concurrent_futures.FutureTests) ... ok
test_done (test.test_concurrent_futures.FutureTests) ... ok
test_done_callback_already_cancelled (test.test_concurrent_futures.FutureTests) ... ok

(...)
test_ressources_gced_in_workers (test.test_concurrent_futures.ProcessPoolForkserverProcessPoolExecutorTest) ... ERROR
(...)

======================================================================
ERROR: test_ressources_gced_in_workers (test.test_concurrent_futures.ProcessPoolForkserverProcessPoolExecutorTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/test/test_concurrent_futures.py", line 952, in test_ressources_gced_in_workers
    mgr = get_context(self.ctx).Manager()
  File "/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/multiprocessing/context.py", line 57, in Manager
    m.start()
  File "/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/multiprocessing/managers.py", line 556, in start
    self._address = reader.recv()
  File "/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/multiprocessing/connection.py", line 255, in recv
    buf = self._recv_bytes()
  File "/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/multiprocessing/connection.py", line 419, in _recv_bytes
    buf = self._recv(4)
  File "/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/multiprocessing/connection.py", line 388, in _recv
    raise EOFError
EOFError

Stdout:
2.10s

----------
components: Interpreter Core, Tests
messages: 365944
nosy: vstinner
priority: normal
severity: normal
status: open
title: Modules/gcmodule.c:434: update_refs: Assertion "gc_get_refs(gc) != 0" failed
versions: Python 3.9

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

From report at bugs.python.org  Tue Apr  7 19:03:53 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 07 Apr 2020 23:03:53 +0000
Subject: [New-bugs-announce] [issue40221] Use new _at_fork_reinit() lock
 method in multiprocessing
Message-ID: <1586300633.14.0.457029058496.issue40221@roundup.psfhosted.org>


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

Currently, _ResourceSharer._after_fork() of multiprocessing.resource_sharer creates new locks and leak old locks on purpose. This method can benefit of the newly added _at_fork_reinit() method added by bpo-40089.

Queue._after_fork() could also call self._notempty._at_fork_reinit().

Also: ForkAwareThreadLock could reinitializes its lock.

----------
components: Library (Lib)
messages: 365957
nosy: vstinner
priority: normal
severity: normal
status: open
title: Use new _at_fork_reinit() lock method in multiprocessing
versions: Python 3.9

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

From report at bugs.python.org  Wed Apr  8 05:41:03 2020
From: report at bugs.python.org (Mark Shannon)
Date: Wed, 08 Apr 2020 09:41:03 +0000
Subject: [New-bugs-announce] [issue40222] "Zero cost" exception handling
Message-ID: <1586338863.3.0.393749013734.issue40222@roundup.psfhosted.org>


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

C++ and Java support what is known as "zero cost" exception handling.
The "zero cost" refers to the cost when no exception is raised. There is still a cost when exceptions are thrown.

The basic principle is that the compiler generates tables indicating where control should be transferred to when an exception is raised. When no exception is raised, there is no runtime overhead.

(C)Python should support "zero cost" exceptions.


Now that the bytecodes for exception handling are regular (meaning that their stack effect can be statically determined) it is possible for the bytecode compiler to emit exception handling tables.

Doing so would have two main benefits.
1. "try" and "with" statements would be faster (and "async for", but that is an implementation detail).
2. Calls to Python functions would be faster as frame objects would be considerably smaller. Currently each frame carries 240 bytes of overhead for exception handling.

----------
assignee: Mark.Shannon
messages: 365974
nosy: Mark.Shannon
priority: normal
severity: normal
status: open
title: "Zero cost" exception handling
type: performance

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

From report at bugs.python.org  Wed Apr  8 06:40:29 2020
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 08 Apr 2020 10:40:29 +0000
Subject: [New-bugs-announce] [issue40223] Add -fwrapv for new icc versions
Message-ID: <1586342429.44.0.914021178636.issue40223@roundup.psfhosted.org>


New submission from Stefan Krah <stefan at bytereef.org>:

Newer icc version require -fwrapv:

https://software.intel.com/en-us/forums/intel-c-compiler/topic/849064

----------
components: Build
messages: 365976
nosy: skrah
priority: normal
severity: normal
stage: needs patch
status: open
title: Add -fwrapv for new icc versions
type: behavior
versions: Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Wed Apr  8 07:45:10 2020
From: report at bugs.python.org (keyboardAnt)
Date: Wed, 08 Apr 2020 11:45:10 +0000
Subject: [New-bugs-announce] [issue40224] Execute a @staticmethod (Python
 3.8.2)
Message-ID: <1586346310.43.0.266820060566.issue40224@roundup.psfhosted.org>


New submission from keyboardAnt <nadav0012 at gmail.com>:

Executing the following code* raise a NameError**. Is it on purpose?
Attached minimal example to reproduce.

class C:
	val = C.sm()

	@staticmethod
	def sm():
		return 'val'

*With Python 3.8.2, on MacOS.
**"NameError: name 'C' is not defined"

Best regards

----------
components: macOS
files: example.py
messages: 365977
nosy: keyboardAnt, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: Execute a @staticmethod (Python 3.8.2)
versions: Python 3.8
Added file: https://bugs.python.org/file49042/example.py

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

From report at bugs.python.org  Wed Apr  8 08:10:27 2020
From: report at bugs.python.org (brendon zhang)
Date: Wed, 08 Apr 2020 12:10:27 +0000
Subject: [New-bugs-announce] [issue40225] max() performance regression
 (quadratic time)
Message-ID: <1586347827.41.0.754437002794.issue40225@roundup.psfhosted.org>


New submission from brendon zhang <brendon-zhang at hotmail.com>:

There is a performance regression of the max (and also min) function implementation starting in python 3.7.

I provide code and associated benchmarks in the file attachment.

----------
components: Library (Lib)
files: maxbug.py
messages: 365978
nosy: brendon-zhang at hotmail.com
priority: normal
severity: normal
status: open
title: max() performance regression (quadratic time)
type: performance
versions: Python 3.7
Added file: https://bugs.python.org/file49043/maxbug.py

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

From report at bugs.python.org  Wed Apr  8 08:19:31 2020
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 08 Apr 2020 12:19:31 +0000
Subject: [New-bugs-announce] [issue40226] Leak in
 tstate->interp->ceval.pending
Message-ID: <1586348371.36.0.292575347676.issue40226@roundup.psfhosted.org>


New submission from Stefan Krah <stefan at bytereef.org>:

50e6e991781db761c496561a995541ca8d83ff87 causes or exposes a
leak. Possibly the leak was there before but showed up under
"still reachable".

Now it is "definitely lost", so tstate->interp->ceval.pending
needs to be cleaned up.


==11235== 32 bytes in 1 blocks are definitely lost in loss record 186 of 1,901
==11235==    at 0x483880B: malloc (vg_replace_malloc.c:309)
==11235==    by 0x467061: _PyMem_RawMalloc (obmalloc.c:99)
==11235==    by 0x467A24: PyMem_RawMalloc (obmalloc.c:572)
==11235==    by 0x528599: PyThread_allocate_lock (thread_pthread.h:379)
==11235==    by 0x4C69B3: _PyEval_InitThreads (ceval.c:231)
==11235==    by 0x50F1EE: pycore_create_interpreter (pylifecycle.c:560)
==11235==    by 0x50FB8A: pyinit_config (pylifecycle.c:756)
==11235==    by 0x5102F7: pyinit_core (pylifecycle.c:923)
==11235==    by 0x510D7A: Py_InitializeFromConfig (pylifecycle.c:1133)
==11235==    by 0x41DAF1: pymain_init (main.c:66)
==11235==    by 0x41EB04: pymain_main (main.c:653)
==11235==    by 0x41EBAD: Py_BytesMain (main.c:686)
==11235==

----------
components: Interpreter Core
messages: 365980
nosy: skrah, vstinner
priority: normal
severity: normal
stage: needs patch
status: open
title: Leak in tstate->interp->ceval.pending
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Wed Apr  8 10:37:35 2020
From: report at bugs.python.org (Ivan Ivanyuk)
Date: Wed, 08 Apr 2020 14:37:35 +0000
Subject: [New-bugs-announce] [issue40227] SSLError is not passed to the
 client during handshake
Message-ID: <1586356655.96.0.9896517853.issue40227@roundup.psfhosted.org>


New submission from Ivan Ivanyuk <ivan.ivanyuk at gmail.com>:

Due to the combination of the logic here: https://github.com/python/cpython/blob/master/Lib/asyncio/sslproto.py#L483 and changes introduced in the issue https://bugs.python.org/issue37035, the assumption that "Not-logged exceptions are not skipped but reported to the user by protocol.connection_lost(exc) callback." as stated in the issue is not valid.
 If SSLError happens during the handshake, no exception get's propagated even if it's possible to log stacktrace using loop.set_debug(True).

 As opposed to the usage pattern mentioned in the initial issue comment, we are very much interested in the errors there, so, for now, I just monkey patch SSLprotocol.connection_lost() in runtime to be like this https://github.com/anthrax-0/cpython/pull/1/commits/d652ed8d0e72bb839fe4841530cc48928b3c3bb0 .

What should be the best solution for this?

----------
components: asyncio
messages: 365988
nosy: asvetlov, iivanyuk, yselivanov
priority: normal
severity: normal
status: open
title: SSLError is not passed to the client during handshake
type: behavior
versions: Python 3.7, Python 3.8

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

From report at bugs.python.org  Wed Apr  8 11:47:35 2020
From: report at bugs.python.org (Mark Shannon)
Date: Wed, 08 Apr 2020 15:47:35 +0000
Subject: [New-bugs-announce] [issue40228] Make setting line number in frame
 more robust.
Message-ID: <1586360855.72.0.434652598832.issue40228@roundup.psfhosted.org>


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

Debuggers are allowed to change the line number of the currently executing frame. Regardless of whether this is sensible or not, the current implementation rather fragile.

The code makes various assumptions about the layout of the bytecode that may not be true in the future, and I suspect, are not true now.

We should use a more brute-force approach of computing the exception stack for the whole function and then searching for a safe place to jump to. This is not only more robust it allows more jumps.

For example, it is safe to jump from one exception handler to another.
It may not be sensible, but it is safe.

----------
components: 2to3 (2.x to 3.x conversion tool)
messages: 365990
nosy: Mark.Shannon
priority: normal
severity: normal
status: open
title: Make setting line number in frame more robust.

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

From report at bugs.python.org  Wed Apr  8 13:44:06 2020
From: report at bugs.python.org (Steven Lu)
Date: Wed, 08 Apr 2020 17:44:06 +0000
Subject: [New-bugs-announce] [issue40229] tty unblocking setraw and
 save-restore features
Message-ID: <1586367846.83.0.241676972691.issue40229@roundup.psfhosted.org>


New submission from Steven Lu <steven.lu at prismsus.org>:

I hope to be able to set blocking or unblocking in `tty.setraw` so that I won't need to mess with `termios` in every of my python codes using an unblocking raw mode. I will personally find it useful in the situation where I want a mainloop that continues running even if I'm not typing into my terminal.

I also feel that a save-restore feature will make mode management a lot easier.

----------
components: Library (Lib)
messages: 365996
nosy: Steven Lu
priority: normal
severity: normal
status: open
title: tty unblocking setraw and save-restore features
type: behavior
versions: Python 3.7

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

From report at bugs.python.org  Wed Apr  8 16:12:06 2020
From: report at bugs.python.org (Henry Carscadden)
Date: Wed, 08 Apr 2020 20:12:06 +0000
Subject: [New-bugs-announce] [issue40230] Itertools.product() Out of Memory
 Errors
Message-ID: <1586376726.21.0.0873613535989.issue40230@roundup.psfhosted.org>


New submission from Henry Carscadden <hlc5v at virginia.edu>:

The product method in itertools provides an implementation of the Cartesian product that when run on with many arguments quickly gives out of memory errors. The current implementation creates a lot of unnecessary lists in this situation. A more appropriate implementation uses dynamic programming to avoid these out of memory issues.

----------
components: Distutils
messages: 366005
nosy: Henry Carscadden, dstufft, eric.araujo
priority: normal
severity: normal
status: open
title: Itertools.product() Out of Memory Errors
type: resource usage
versions: Python 3.7

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

From report at bugs.python.org  Wed Apr  8 17:33:25 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 08 Apr 2020 21:33:25 +0000
Subject: [New-bugs-announce] [issue40231] Fix pending calls in
 subinterpreters
Message-ID: <1586381605.22.0.272292107555.issue40231@roundup.psfhosted.org>


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

Currently, _Py_ThreadCanHandlePendingCalls() only returns true if the current thread is the Python "main thread" (_PyRuntime.main_thread).

_PyRuntime.main_thread is initialized by _PyRuntime_Initialize().

The problem is that a subinterpreter can run a separated thread which may not be the "main thread".

As a consequence, a subinterpreter will not run schedulded pending calls, or it will run them later than it could.

I modified COMPUTE_EVAL_BREAKER() of ceval.c in bpo-40010: now if tstate->interp->ceval.pending.calls_to_do is true, tstate->interp->ceval.eval_breaker is only set to 1 if _Py_ThreadCanHandlePendingCalls() is true.

One option would be to allow any thread to run "pending calls".

Another option is to have one "main thread" per interpreter, rather than having a single "main thread" for all interpreters.


I made pending calls per-interpreter in bpo-39984.


In Python 3.7, main_thread variable came from _PyRutimeState.ceval.pending.main_thread. It was moved into _PyRuntimeState by this change:

commit 5be45a6105d656c551adeee7770afdc3b806fbb5
Author: Eric Snow <ericsnowcurrently at gmail.com>
Date:   Fri Mar 8 22:47:07 2019 -0700

    bpo-33608: Minor cleanup related to pending calls. (gh-12247)

--

_Py_ThreadCanHandleSignals() doesn't have to change: it must only return true for the main thread of the main interpreter. Currently, it's implemented as:

static inline int
_Py_ThreadCanHandleSignals(PyThreadState *tstate)
{
    return (_Py_IsMainThread() && _Py_IsMainInterpreter(tstate));
}

----------
components: Interpreter Core
messages: 366010
nosy: eric.snow, vstinner
priority: normal
severity: normal
status: open
title: Fix pending calls in subinterpreters
versions: Python 3.9

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

From report at bugs.python.org  Wed Apr  8 17:43:23 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 08 Apr 2020 21:43:23 +0000
Subject: [New-bugs-announce] [issue40232] PyOS_AfterFork_Child() should use
 _PyThread_at_fork_reinit()
Message-ID: <1586382203.52.0.537965691861.issue40232@roundup.psfhosted.org>


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

In bpo-40089, I added _PyThread_at_fork_reinit() function to reinitialize a lock after a lock. PyOS_AfterFork_Child() should use it rather than creating new locks. For example, currently _PyEval_ReInitThreads() calls:

    pending->lock = PyThread_allocate_lock();

----------
components: Interpreter Core
messages: 366015
nosy: vstinner
priority: normal
severity: normal
status: open
title: PyOS_AfterFork_Child() should use _PyThread_at_fork_reinit()
versions: Python 3.9

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

From report at bugs.python.org  Wed Apr  8 19:14:05 2020
From: report at bugs.python.org (Daniel Holth)
Date: Wed, 08 Apr 2020 23:14:05 +0000
Subject: [New-bugs-announce] [issue40233] Awkward to set compression on
 writeable ZipFile.open()
Message-ID: <1586387645.18.0.880885386366.issue40233@roundup.psfhosted.org>


New submission from Daniel Holth <dholth at fastmail.fm>:

It looks like this is the current API to set compression at the individual file level when writing with ZipFile.open()

        z.compression = zipfile.ZIP_STORED
        data_writer = z.open(zip_info or filename, "w")
        z.compression = saved

It would be useful to have a parameter or to honor the compression setting of the passed ZipInfo.

----------
components: Library (Lib)
messages: 366028
nosy: alanmcintyre, dholth, serhiy.storchaka, twouters
priority: normal
severity: normal
status: open
title: Awkward to set compression on writeable ZipFile.open()
versions: Python 3.7

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

From report at bugs.python.org  Wed Apr  8 19:16:52 2020
From: report at bugs.python.org (Eric Snow)
Date: Wed, 08 Apr 2020 23:16:52 +0000
Subject: [New-bugs-announce] [issue40234] Disallow daemon threads in
 subinterpreters optionally.
Message-ID: <1586387812.86.0.0296012569674.issue40234@roundup.psfhosted.org>


New submission from Eric Snow <ericsnowcurrently at gmail.com>:

In bpo-37266 we strictly disallowed creation of daemon threads in subinterpreters.  However, this is backward-incompatible for existing users of the subinterpreter C-API (such as mod-wsgi).

Rather than reverting that change I suggest that we make it opt-in through the interpreter config.  That would preserve backward-compatibility.  It would also make it so we can disallow daemon threads in subinterpreters created through PEP 554.  We could also deprecate use of daemon threads in *all* subinterpreters, with the goal of dropping support after a while.

----------
components: Interpreter Core
messages: 366029
nosy: eric.snow, grahamd, vstinner
priority: normal
severity: normal
stage: needs patch
status: open
title: Disallow daemon threads in subinterpreters optionally.
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Wed Apr  8 23:47:22 2020
From: report at bugs.python.org (Daniel Holth)
Date: Thu, 09 Apr 2020 03:47:22 +0000
Subject: [New-bugs-announce] [issue40235] confusing documentation for
 IOBase.__exit__
Message-ID: <1586404042.0.0.215231917986.issue40235@roundup.psfhosted.org>


New submission from Daniel Holth <dholth at fastmail.fm>:

The io documentation says:

IOBase is also a context manager and therefore supports the with statement. In this example, file is closed after the with statement?s suite is finished?even if an exception occurs:

with open('spam.txt', 'w') as file:
    file.write('Spam and eggs!')


I read this to mean that my own subclass of io.BufferedIOBase would call close() when used as a context manager.

Instead, it is necessary to provide an implementation of __exit__ that calls close() to get this behavior.

The documentation lists Mixin Methods, but I couldn't find a definition of the term "Mixin Methods" in the docs.

----------
components: IO
messages: 366032
nosy: dholth
priority: normal
severity: normal
status: open
title: confusing documentation for IOBase.__exit__
versions: Python 3.7

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

From report at bugs.python.org  Thu Apr  9 05:55:31 2020
From: report at bugs.python.org (zhanying)
Date: Thu, 09 Apr 2020 09:55:31 +0000
Subject: [New-bugs-announce] [issue40236] datetime.datetime.strptime get day
 error
Message-ID: <1586426131.65.0.158262640104.issue40236@roundup.psfhosted.org>


New submission from zhanying <python82 at 126.com>:

In [7]: datetime.datetime.strptime("2024-0-3 00:00:00", "%Y-%W-%w %H:%M:%S")
Out[7]: datetime.datetime(2024, 1, 3, 0, 0)

In [8]: datetime.datetime.strptime("2024-1-3 00:00:00", "%Y-%W-%w %H:%M:%S")
Out[8]: datetime.datetime(2024, 1, 3, 0, 0)

----------
messages: 366039
nosy: zhanying
priority: normal
severity: normal
status: open
title: datetime.datetime.strptime get day error
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Thu Apr  9 08:52:10 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 09 Apr 2020 12:52:10 +0000
Subject: [New-bugs-announce] [issue40237] Test code coverage (C) job of
 Travis CI fails on test_distutils which creates _configtest.gcno file
Message-ID: <1586436730.26.0.786791148526.issue40237@roundup.psfhosted.org>


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

Example:
https://travis-ci.org/github/python/cpython/jobs/672698615

Output:
===========================================
0:09:01 load avg: 3.96 [104/421/1] test_distutils failed -- running: test_multiprocessing_forkserver (1 min 13 sec), test_unparse (6 min 21 sec)

Warning -- files was modified by test_distutils

  Before: []

  After:  ['_configtest.gcno'] 

test test_distutils failed -- Traceback (most recent call last):

  File "/home/travis/build/python/cpython/Lib/distutils/tests/test_build_ext.py", line 112, in test_build_ext

    assert_python_ok('-c', code)

  File "/home/travis/build/python/cpython/Lib/test/support/script_helper.py", line 156, in assert_python_ok

    return _assert_python(True, *args, **env_vars)

  File "/home/travis/build/python/cpython/Lib/test/support/script_helper.py", line 142, in _assert_python

    res.fail(cmd_line)

  File "/home/travis/build/python/cpython/Lib/test/support/script_helper.py", line 70, in fail

    raise AssertionError("Process return code is %d\n"

AssertionError: Process return code is 1

command line: ['/home/travis/build/python/cpython/python', '-X', 'faulthandler', '-I', '-c', "\ntmp_dir = '/tmp/tmp3y4hpawx'\n\nimport sys\nimport unittest\nfrom test import support\n\nsys.path.insert(0, tmp_dir)\nimport xx\n\nclass Tests(unittest.TestCase):\n    def test_xx(self):\n        for attr in ('error', 'foo', 'new', 'roj'):\n            self.assertTrue(hasattr(xx, attr))\n\n        self.assertEqual(xx.foo(2, 5), 7)\n        self.assertEqual(xx.foo(13,15), 28)\n        self.assertEqual(xx.new().demo(), None)\n        if support.HAVE_DOCSTRINGS:\n            doc = 'This is a template module just for instruction.'\n            self.assertEqual(xx.__doc__, doc)\n        self.assertIsInstance(xx.Null(), xx.Null)\n        self.assertIsInstance(xx.Str(), xx.Str)\n\n\nunittest.main()\n"]

stdout:

---

---

stderr:

---

Traceback (most recent call last):

  File "<string>", line 9, in <module>

ImportError: /tmp/tmp3y4hpawx/xx.cpython-39-x86_64-linux-gnu.so: undefined symbol: __gcov_merge_add

---

===========================================

Python is built GCC with -ftest-coverage option. But it seems like this option is "leaked" to C flags used to build third party extensions in distutils.

Maybe CFLAGS_NODIST should be used instead of CFLAGS.

The Travis CI job runs these commands:
---
./configure
xvfb-run make -j4 coverage-report
make pythoninfo
bash <(curl -s https://codecov.io/bash) -y .github/codecov.yml
---

----------
components: Tests
messages: 366047
nosy: vstinner
priority: normal
severity: normal
status: open
title: Test code coverage (C) job of Travis CI fails on test_distutils which creates _configtest.gcno file
versions: Python 3.9

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

From report at bugs.python.org  Thu Apr  9 10:25:30 2020
From: report at bugs.python.org (David Strobach)
Date: Thu, 09 Apr 2020 14:25:30 +0000
Subject: [New-bugs-announce] [issue40238] os.stat() on Windows succeeds for
 nonexistent paths with trailing spaces
Message-ID: <1586442330.4.0.896715206677.issue40238@roundup.psfhosted.org>


New submission from David Strobach <lalochcz at gmail.com>:

On Windows (Server 2012 R2 in my case) os.stat() seems to be striping significant trailing spaces off the path argument:

>>> import os
>>> os.stat("c:\\Program Files     ")
os.stat_result(st_mode=16749, st_ino=281474976710717, st_dev=173025906, st_nlink=1, st_uid=0, st_gid=0, st_size=8192, st_atime=1586154685, st_mtime=1586154685, st_ctime=1377178576)
>>> os.stat("c:\\Program Files\\     ")
os.stat_result(st_mode=16749, st_ino=281474976710717, st_dev=173025906, st_nlink=1, st_uid=0, st_gid=0, st_size=8192, st_atime=1586154685, st_mtime=1586154685, st_ctime=1377178576)
>>> # consequently
>>> os.path.isdir("c:\\Program Files\\     ")
True
>>> os.path.isdir("c:\\Program Files     ")
True
>>> os.scandir("c:\\Program Files     ")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
FileNotFoundError: [WinError 3] The system cannot find the path specified: 'c:\\Program Files     '

The same also applies to regular files, not just directories.

----------
components: Library (Lib), Windows
messages: 366054
nosy: David Strobach, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: os.stat() on Windows succeeds for nonexistent paths with trailing spaces
type: behavior
versions: Python 3.6, Python 3.7, Python 3.8

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

From report at bugs.python.org  Thu Apr  9 10:42:29 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 09 Apr 2020 14:42:29 +0000
Subject: [New-bugs-announce] [issue40239] Add a function for merging sorted
 iterables
Message-ID: <1586443349.52.0.011091886017.issue40239@roundup.psfhosted.org>


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

It would be useful to have a function in itertools to merge sorted iterables.

    merge_sorted(*iterables, key=None, reverse=False):

It should emit the same items as sorted(tee(*iterables), key=key, reverse=reverse) if iterables are sorted with key and reverse. But it should use the amount of memory O(M) where M is the number of iterables, and support infinite iterables.

----------
components: Library (Lib)
messages: 366056
nosy: rhettinger, serhiy.storchaka, tim.peters
priority: normal
severity: normal
status: open
title: Add a function for merging sorted iterables
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Thu Apr  9 11:00:32 2020
From: report at bugs.python.org (Eric Cousineau)
Date: Thu, 09 Apr 2020 15:00:32 +0000
Subject: [New-bugs-announce] [issue40240] Expose public spelling of
 _PyGC_FINALIZED and _PyGC_SET_FINALIZED?
Message-ID: <1586444432.56.0.946879588514.issue40240@roundup.psfhosted.org>


New submission from Eric Cousineau <eric.cousineau at tri.global>:

Motivated by this downstream project issue that I am working on:
https://github.com/RobotLocomotion/drake/issues/13026

In https://bugs.python.org/issue32377, I encountered PEP 442's updated resurrection behavior when moving from supporting Python 2 to Python 3.
There, Antoine Pitrou (pitrou) said that using this API (finalized + set finalized) could work, but that I could also try recreating the wrapper object. I have not yet attempted his suggestion given that (a) wrapping code is nuanced (pybind11, inheritance, etc.) and (b) this API has been working for us for the past 2 years.

Related to this, I saw some mentions of breakage of Cython due to its usage of this API:
https://bugs.python.org/issue35081#msg330045
The breakage was mitigated by keeping this internal API exposed (so kinda public, but not really?).

Is it at all possible to considering making some of this public API?

----------
components: C API
messages: 366059
nosy: Eric Cousineau
priority: normal
severity: normal
status: open
title: Expose public spelling of _PyGC_FINALIZED and _PyGC_SET_FINALIZED?
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/issue40240>
_______________________________________

From report at bugs.python.org  Thu Apr  9 11:19:56 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 09 Apr 2020 15:19:56 +0000
Subject: [New-bugs-announce] [issue40241] [C API] Make PyGC_Head structure
 opaque, or even more it to the internal C API
Message-ID: <1586445596.83.0.583225080007.issue40241@roundup.psfhosted.org>


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

Similarly to bpo-39573 (PyObject) and bpo-40170 (PyTypeObject), I propose to make the PyGC_Head structure opaque in the C API.

See https://bugs.python.org/issue39573#msg361513 for the rationale. In short, my plan is to hide all implementation details from the C API.

The PyGC_Head structure caused ABI issues recently: bpo-39599 "ABI breakage between Python 3.7.4 and 3.7.5: change in PyGC_Head structure". Making the structure opaque would reduce the risk of such ABI issue. In fact, the reporter of bpo-39599 really require to access PyGC_Head structure to write a profiler, so this issue doesn't fix all use cases, but it should benefit to most people ;-) PyGC_Head structure will remain accessible via the internal C API which doesn't provide any backward compatibility warranty.

----------
components: C API
messages: 366064
nosy: vstinner
priority: normal
severity: normal
status: open
title: [C API] Make PyGC_Head structure opaque, or even more it to the internal C API
versions: Python 3.9

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

From report at bugs.python.org  Thu Apr  9 13:59:55 2020
From: report at bugs.python.org (Rohit Gupta)
Date: Thu, 09 Apr 2020 17:59:55 +0000
Subject: [New-bugs-announce] [issue40242] zmq mysql core dump
Message-ID: <1586455195.03.0.155128936869.issue40242@roundup.psfhosted.org>


New submission from Rohit Gupta <rohit_gupta at amperehourenergy.com>:

# pyzmq==19.0.0
# zmq==0.0.0
# mysql-connector-python==8.0.19

# Following code is resulting in 
# Segmentation fault (core dumped)
##################################
import zmq
import mysql.connector

database = "dev"
host = "192.168.56.1"
port = 3306
user = "user"
pwd = "user"
print(database, host, port, user, pwd)
db  = mysql.connector.connect(host=host, port=int(port), user=user, password=pwd, database=database, autocommit=False)
cur = db.cursor()
print("Connected")

----------
components: Library (Lib)
messages: 366083
nosy: Rohit Gupta
priority: normal
severity: normal
status: open
title: zmq mysql core dump
type: crash
versions: Python 3.6

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

From report at bugs.python.org  Thu Apr  9 16:38:37 2020
From: report at bugs.python.org (William Meehan)
Date: Thu, 09 Apr 2020 20:38:37 +0000
Subject: [New-bugs-announce] [issue40243] Unicode 3.2 numeric uses
 decimal_changed instead of numeric_changed
Message-ID: <1586464717.76.0.49131184296.issue40243@roundup.psfhosted.org>


Change by William Meehan <wmeehan at fb.com>:


----------
components: Unicode
nosy: ezio.melotti, vstinner, wmeehan
priority: normal
severity: normal
status: open
title: Unicode 3.2 numeric uses decimal_changed instead of numeric_changed
type: behavior
versions: Python 2.7, 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/issue40243>
_______________________________________

From report at bugs.python.org  Fri Apr 10 04:28:36 2020
From: report at bugs.python.org (Michael Felt)
Date: Fri, 10 Apr 2020 08:28:36 +0000
Subject: [New-bugs-announce] [issue40244] AIX: build: _PyObject_GC_TRACK
 Asstertion failure
Message-ID: <1586507316.69.0.786578254213.issue40244@roundup.psfhosted.org>


New submission from Michael Felt <aixtools at felt.demon.nl>:

Calling this a compile error - as it seems to be compiler dependent.

In other projects - when I have experienced issues as this it has been an uninitiated variable - somewhere.

I would appreciate some suggestions on how to best debug this - as it seems to occur even before tracemalloc can be activated.

$ ./python -X tracemalloc
Objects/genobject.c:127: _PyObject_GC_TRACK: Assertion "!(((PyGC_Head *)(op)-1)->_gc_next != 0)" failed: object already tracked by the garbage collector
Enable tracemalloc to get the memory block allocation traceback

object address  : 30085150
object refcount : 0
object type     : 20013ea0
object type name: generator
object repr     : <refcnt 0 at 30085150>

Fatal Python error: _PyObject_AssertFailed: _PyObject_AssertFailed
Python runtime state: core initialized

Current thread 0x00000001 (most recent call first):
  File "<frozen importlib._bootstrap_external>", line 1593 in _setup
  File "<frozen importlib._bootstrap_external>", line 1634 in _install
  File "<frozen importlib._bootstrap>", line 1189 in _install_external_importers
IOT/Abort trap(coredump)

p.s. I can always build using a different compiler and try to get it to report on this object using the values listed above - and/or insert more debug code.

Next step I'll try is using dbx (AIX debugger) for a stacktrace.

Thanks!

----------
components: Build
messages: 366112
nosy: David.Edelsohn, Michael.Felt
priority: normal
severity: normal
status: open
title: AIX: build: _PyObject_GC_TRACK Asstertion failure
type: compile error
versions: Python 3.9

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

From report at bugs.python.org  Fri Apr 10 12:38:25 2020
From: report at bugs.python.org (Andrew Zhou)
Date: Fri, 10 Apr 2020 16:38:25 +0000
Subject: [New-bugs-announce] [issue40245] Add description meta tags to
 docs.python.org
Message-ID: <1586536705.62.0.749935364813.issue40245@roundup.psfhosted.org>


New submission from Andrew Zhou <andrewfzhou at gmail.com>:

This isn't a particularly high priority, but it would be nice to have the first paragraph of docs pages show up when searched or posted in Slack, Discord, Twitter, etc. This is done through the description meta tag, as well as Open Graph, etc. As the description meta tag covers most of the potential use cases, the others can wait.

What implementing this would entail is either manual addition of meta tags, or an automatic transform step that grabs the first paragraph of the relevant RST source. [1]

http://www.sphinx-doc.org/en/master/extdev/appapi.html#sphinx.application.Sphinx.add_transform

----------
assignee: docs at python
components: Documentation
messages: 366138
nosy: 0az, docs at python
priority: normal
severity: normal
status: open
title: Add description meta tags to docs.python.org
type: enhancement

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

From report at bugs.python.org  Fri Apr 10 14:05:58 2020
From: report at bugs.python.org (Lysandros Nikolaou)
Date: Fri, 10 Apr 2020 18:05:58 +0000
Subject: [New-bugs-announce] [issue40246] Different error messages for same
 error - invalid string prefixes
Message-ID: <1586541958.33.0.891000303304.issue40246@roundup.psfhosted.org>


New submission from Lysandros Nikolaou <lisandrosnik at gmail.com>:

While testing pegen, we found this out:

Python 3.9.0a5+ (heads/pegen:502dfb719e, Apr 10 2020, 20:57:05) 
[GCC 9.2.1 20191008] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> fur''
  File "<stdin>", line 1
    fur''
       ^
SyntaxError: invalid syntax
>>> eval("fur''")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<string>", line 1
    fur''
       ^
SyntaxError: unexpected EOF while parsing

----------
components: Interpreter Core
messages: 366143
nosy: lys.nikolaou
priority: normal
severity: normal
status: open
title: Different error messages for same error - invalid string prefixes
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Fri Apr 10 16:49:55 2020
From: report at bugs.python.org (J)
Date: Fri, 10 Apr 2020 20:49:55 +0000
Subject: [New-bugs-announce] [issue40247] Logged out of user when running
 Tkinter
Message-ID: <1586551795.67.0.408476098567.issue40247@roundup.psfhosted.org>


New submission from J <googoohashbrown at gmail.com>:

Whenever I run a python script with any Tkinter command, I get instantly logged out of my user. I have been using Tkinter for weeks now and it was running just fine until yesterday when I clicked the demo button in the default taskbar that shows up when launching a Tkinter GUI. It has been crashing now ever since if I include any Tkinter bits in the code. I have been using Python 3.7.7 with the Tkinter version that came with it before this problem started showing up. I have furiously tried everything I could think of (mind me, I'm pretty new to this) including installing preceding and later versions from the official python.org page (3.8.2, 3.8.1, 3.8.0, 3.7.0, 3.6.6 etc.). On some version of python, Tkinter runs and creates the main window with command tk.Tk(), however it would embed it into another window (see attached screenshot). Weird stuff. I've searched across the internet for similar issues to no avail.

Operation System: MacOS Mohave 10.14.6

I hope I'm in the right place to report this abnormal crashing. I would be very thankful for any guidance.

----------
components: Tkinter
files: 2.png
messages: 366153
nosy: Jordan
priority: normal
severity: normal
status: open
title: Logged out of user when running Tkinter
type: crash
versions: Python 3.7
Added file: https://bugs.python.org/file49048/2.png

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

From report at bugs.python.org  Fri Apr 10 17:19:46 2020
From: report at bugs.python.org (Steele Farnsworth)
Date: Fri, 10 Apr 2020 21:19:46 +0000
Subject: [New-bugs-announce] [issue40248] Proposed class for collections:
 dynamicdict
Message-ID: <1586553586.38.0.834422539726.issue40248@roundup.psfhosted.org>


New submission from Steele Farnsworth <swfarnsworth at gmail.com>:

I have implemented a class in the C code of the collections module which has similar behavior to the defaultdict class. This class, dynamicdict, supplies values for keys that have not yet been added using a default factory callable, but unlike defaultdict, the missing key itself is passed to the callable. This code can be seen here: https://github.com/swfarnsworth/cpython/blob/3.8/Modules/_collectionsmodule.c#L2234

While this does introduce a lot of redundant code, I'm not sure how it could be done without copying the implementation of the defaultdict class and adjusting how the default factory is called. For example, I don't believe that it's possible to support both behaviors within the defaultdict class without breaking backwards compatibility or adding another parameter to the constructor for the defaultdict class.

I would be happy to further explain the concept, implementation, potential use cases, or anything else that might work towards the adoption of this feature.

----------
components: ctypes
messages: 366157
nosy: Steele Farnsworth
priority: normal
severity: normal
status: open
title: Proposed class for collections: dynamicdict
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Fri Apr 10 18:33:48 2020
From: report at bugs.python.org (Stefan Seefeld)
Date: Fri, 10 Apr 2020 22:33:48 +0000
Subject: [New-bugs-announce] [issue40249] __import__ doesn't honour globals
Message-ID: <1586558028.61.0.331520667517.issue40249@roundup.psfhosted.org>


New submission from Stefan Seefeld <stefan at seefeld.name>:

I'm trying to import custom scripts that expect the presence of certain variables in the global namespace.
It seems `__import__('script', globals=dict(foo='bar'))` doesn't have the expected effect of injecting "foo" into the namespace and making it accessible to the script being loaded.

Is this a bug in `__import__` or am I missing something ? If the behaviour is expected, how can I achieve the desired behaviour ?

----------
components: Interpreter Core
messages: 366160
nosy: stefan
priority: normal
severity: normal
status: open
title: __import__ doesn't honour globals
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Fri Apr 10 19:03:11 2020
From: report at bugs.python.org (Elmar Bucher)
Date: Fri, 10 Apr 2020 23:03:11 +0000
Subject: [New-bugs-announce] [issue40250] unable to comment out r'\u' string
 with triple quote marks
Message-ID: <1586559791.68.0.297747169601.issue40250@roundup.psfhosted.org>


New submission from Elmar Bucher <elmbeech at gmail.com>:

When I try to comment out this little code by triple quotation, 
I run into
SyntaxError: (unicode error) 'unicodeescape' codec can't decode bytes in position 29-30: truncated \uXXXX escape

ls_tex = []
ls_tex.append(r'\usepackage{mathtools}')
print(ls_tex)

Basically it is not possible to use r'\u' and comment it out with ''' or """. I think this should not be the case, this is an interpreter error.

----------
components: Interpreter Core
messages: 366166
nosy: Elmar Bucher
priority: normal
severity: normal
status: open
title: unable to comment out r'\u' string with triple quote marks
versions: Python 3.7

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

From report at bugs.python.org  Fri Apr 10 19:13:44 2020
From: report at bugs.python.org (Russell Davis)
Date: Fri, 10 Apr 2020 23:13:44 +0000
Subject: [New-bugs-announce] [issue40251] selectors.KqueueSelector hangs on
 EOF, unlike other selectors
Message-ID: <1586560424.88.0.351958580551.issue40251@roundup.psfhosted.org>


New submission from Russell Davis <russell.davis at gmail.com>:

Repro (on macOS):

    from selectors import KqueueSelector, EVENT_READ
    with open('/tmp/foo', 'w') as f:
        f.write("bar")
        sel = KqueueSelector()
        sel.register(f, EVENT_READ)
        sel.select()

The above code will hang on the last line. If you change KqueueSelector to PollSelector or SelectSelector, it will not hang.

Per msg255116, the different selectors should behave consistently.

----------
components: IO, Library (Lib), asyncio
messages: 366167
nosy: asvetlov, russelldavis, yselivanov
priority: normal
severity: normal
status: open
title: selectors.KqueueSelector hangs on EOF, unlike other selectors
versions: Python 3.8

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

From report at bugs.python.org  Fri Apr 10 19:23:51 2020
From: report at bugs.python.org (Russell Davis)
Date: Fri, 10 Apr 2020 23:23:51 +0000
Subject: [New-bugs-announce] [issue40252] selectors.KqueueSelector should
 not be the default selector
Message-ID: <1586561031.94.0.13137100998.issue40252@roundup.psfhosted.org>


New submission from Russell Davis <russell.davis at gmail.com>:

There are at least two outstanding bugs where KqueueSelector behaves differently than the other selectors:

#40251
#25680

This breaks the abstraction of being able to rely on DefaultSelector() to provide consistent behavior. At least on macOS, PollSelector works reliably, so I propose using that instead of KqueueSelector when setting DefaultSelector. (Even if the above bugs eventually get fixed, sticking with PollSelector when possible seems more likely to avoid similar future issues.)

----------
components: IO, Library (Lib), asyncio
messages: 366168
nosy: asvetlov, russelldavis, yselivanov
priority: normal
severity: normal
status: open
title: selectors.KqueueSelector should not be the default selector
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/issue40252>
_______________________________________

From report at bugs.python.org  Sat Apr 11 03:29:49 2020
From: report at bugs.python.org (virtualnobi)
Date: Sat, 11 Apr 2020 07:29:49 +0000
Subject: [New-bugs-announce] [issue40253] Fix .py(w) file association with
 Pyhon 3 Windows installer
Message-ID: <1586590189.16.0.270400617976.issue40253@roundup.psfhosted.org>


New submission from virtualnobi <virtualnobi at zoho.com>:

Recently installed Python 3.8 (from 2.7) on Windows 10, and all my scripts didn't work anymore. For some strange reason 

> python -s script.py args

would put the args into sys.argv[], while

> script.py args

would only show the script in sys.argv[]. I found this report which fixed the problem: 

https://stackoverflow.com/questions/15281951/sys-argv-contents-when-calling-python-script-implicitly-on-windows

(Basically, the .py(w) association in the registry need an additional '%*' parameter to pass the script parameters.)

So I assume the Python 3 Windows installer overwrote my earlier registry associations. 

The other way the problem happened could be that the Python 3 installer did not change the registry assocation to 3.8, and I did this manually. I verified that setting a "default program" for windows will put the deficient association (without argument passing) into the registry. 

Either way, I would expect that after installing Python 3.8, my scripts would really run with 3.8, and with their arguments. :-) 

Danke & Gr??e von 
nobi

----------
components: Installation, Windows
messages: 366192
nosy: paul.moore, steve.dower, tim.golden, virtualnobi, zach.ware
priority: normal
severity: normal
status: open
title: Fix .py(w) file association with Pyhon 3 Windows installer
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Sat Apr 11 04:52:49 2020
From: report at bugs.python.org (Tomohiko Kinebuchi)
Date: Sat, 11 Apr 2020 08:52:49 +0000
Subject: [New-bugs-announce] [issue40254] pyspecific directives are not
 translatable
Message-ID: <1586595169.2.0.635960834529.issue40254@roundup.psfhosted.org>


New submission from Tomohiko Kinebuchi <cocoatomo77 at gmail.com>:

The new mechanism of Sphinx for internationalization was introduced at Sphinx 1.8, but directives implemented on pyspecific.py were not updated to follow that renewal.
As a result, the text of these directives is left untranslated.
(e.g. https://docs.python.org/ja/3.8/library/array.html)

----------
assignee: docs at python
components: Documentation
messages: 366196
nosy: cocoatomo, docs at python
priority: normal
severity: normal
status: open
title: pyspecific directives are not translatable
type: behavior
versions: Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Sat Apr 11 11:40:21 2020
From: report at bugs.python.org (Eddie Elizondo)
Date: Sat, 11 Apr 2020 15:40:21 +0000
Subject: [New-bugs-announce] [issue40255] Fixing Copy on Writes from
 reference counting
Message-ID: <1586619621.82.0.553262088399.issue40255@roundup.psfhosted.org>


New submission from Eddie Elizondo <eduardo.elizondorueda at gmail.com>:

Copy on writes are a big problem in large Python application that rely on multiple processes sharing the same memory.

With the implementation of `gc.freeze`, we've attenuated the problem by removing the CoW coming from the GC Head. However, reference counting still causes CoW.

This introduces Immortal Instances which allows the user to bypass reference counting on specific objects and avoid CoW on forked processes.

Immortal Instances are specially useful for applications that cache heap objects in shared memory which live throughout the entire execution (i.e modules, code, bytecode, etc.)

----------
components: Interpreter Core
messages: 366216
nosy: eelizondo
priority: normal
severity: normal
status: open
title: Fixing Copy on Writes from reference counting
versions: Python 3.9

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

From report at bugs.python.org  Sat Apr 11 14:04:31 2020
From: report at bugs.python.org (Yusuf Mumtaz)
Date: Sat, 11 Apr 2020 18:04:31 +0000
Subject: [New-bugs-announce] [issue40256] Python 3.8 Not Launching on
 Bootcamp Windows 10.
Message-ID: <1586628271.16.0.0390251857061.issue40256@roundup.psfhosted.org>


New submission from Yusuf Mumtaz <ymumtaz22 at gmail.com>:

Hello.
I am having trouble running python IDLE on Windows 10 Bootcamp. When searching and opening from windows taskbar, no window appears and nothing else appears to happen.

Please help me!

----------
components: Windows
messages: 366217
nosy: YusufM, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Python 3.8 Not Launching on Bootcamp Windows 10.
type: crash
versions: Python 3.8

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

From report at bugs.python.org  Sat Apr 11 16:54:38 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 11 Apr 2020 20:54:38 +0000
Subject: [New-bugs-announce] [issue40257] Improve the use of __doc__ in pydoc
Message-ID: <1586638478.83.0.463728061154.issue40257@roundup.psfhosted.org>


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

Currently pydoc outputs __doc__ for classes, functions, methods, properties, etc (using inspect.getdoc()). If the object itself does not have non-empty __doc__, it searches non-empty __doc__ in the class parenthesis (if the object is a class) or in the corresponding overloaded members of the class to which the object (method, property, etc) belongs.

There are several problems with this.

1. Using the docstring of a parent class is misleading in most classes, especially if it is a base or abstract class (like object, Exception, Mapping).

2. If the object does not have the __doc__ attribute, it inherits it from its class, so inspect.getdoc(1) returns the same as inspect.getdoc(int).

3. If the object has own docstring, but is not a class or function, it will be output in the section DATA without a docstring.

The following PR fixes these issues.

1. Docstrings for classes are not inherited. It is better to not output a docstring than output the wrong one.

2. inspect.getdoc() returns the object's own docstring.

3. Docstrings are always output for object with a docstring. See for example help(typing).

In future issues I'll make help(typing) even more informative.

----------
components: Library (Lib)
messages: 366220
nosy: gvanrossum, levkivskyi, ncoghlan, serhiy.storchaka, yselivanov
priority: normal
severity: normal
status: open
title: Improve the use of __doc__ in pydoc
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Sat Apr 11 19:21:45 2020
From: report at bugs.python.org (Nik Vaessen)
Date: Sat, 11 Apr 2020 23:21:45 +0000
Subject: [New-bugs-announce] [issue40258] random module does not have type
 hints
Message-ID: <1586647305.23.0.854473037711.issue40258@roundup.psfhosted.org>


Change by Nik Vaessen <nik at vaessen.tech>:


----------
nosy: nikvaes
priority: normal
severity: normal
status: open
title: random module does not have type hints
type: enhancement

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

From report at bugs.python.org  Sun Apr 12 03:52:00 2020
From: report at bugs.python.org (Dennis Chronopoulos)
Date: Sun, 12 Apr 2020 07:52:00 +0000
Subject: [New-bugs-announce] [issue40259] re.Scanner groups
Message-ID: <1586677920.32.0.0537949895316.issue40259@roundup.psfhosted.org>


Change by Dennis Chronopoulos <denchron at gmail.com>:


----------
components: Regular Expressions
nosy: dchron, ezio.melotti, mrabarnett
priority: normal
severity: normal
status: open
title: re.Scanner groups
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Sun Apr 12 04:37:00 2020
From: report at bugs.python.org (Barry Alan Scott)
Date: Sun, 12 Apr 2020 08:37:00 +0000
Subject: [New-bugs-announce] [issue40260] modulefinder traceback regression
 starting on Windows
Message-ID: <1586680620.99.0.514402715757.issue40260@roundup.psfhosted.org>


New submission from Barry Alan Scott <barry-scott at users.sourceforge.net>:

modulefinder.py does not open source files in "rb" which
prevents compile() from applying the encoding rules.

This first showed up for me on Windows with Python 3.8.

Here is my test case and the results on Windows with 3.8.

import modulefinder

with open('import_functools.py', 'w') as f:
   f.write('import functools\n')

mf = modulefinder.ModuleFinder()
mf.run_script('import_functools.py')
print('Test passed')

py -3.8-32 modulefinder_test.py
Traceback (most recent call last):
 File "modulefinder_test.py", line 7, in <module>
   mf.run_script('import_functools.py')
 File "C:\Python38.win32\lib\modulefinder.py", line 165, in run_script
   self.load_module('__main__', fp, pathname, stuff)
 File "C:\Python38.win32\lib\modulefinder.py", line 360, in load_module
   self.scan_code(co, m)
 File "C:\Python38.win32\lib\modulefinder.py", line 433, in scan_code
   self._safe_import_hook(name, m, fromlist, level=0)
 File "C:\Python38.win32\lib\modulefinder.py", line 378, in _safe_import_hook
   self.import_hook(name, caller, level=level)
 File "C:\Python38.win32\lib\modulefinder.py", line 177, in import_hook
   q, tail = self.find_head_package(parent, name)
 File "C:\Python38.win32\lib\modulefinder.py", line 233, in find_head_package
   q = self.import_module(head, qname, parent)
 File "C:\Python38.win32\lib\modulefinder.py", line 326, in import_module
   m = self.load_module(fqname, fp, pathname, stuff)
 File "C:\Python38.win32\lib\modulefinder.py", line 343, in load_module
   co = compile(fp.read()+'\n', pathname, 'exec')
 File "C:\Python38.win32\lib\encodings\cp1252.py", line 23, in decode
   return codecs.charmap_decode(input,self.errors,decoding_table)[0]
UnicodeDecodeError: 'charmap' codec can't decode byte 0x81 in position 308: character maps to <undefined>

Barry

----------
components: Library (Lib)
messages: 366227
nosy: barry-scott
priority: normal
severity: normal
status: open
title: modulefinder traceback regression starting on Windows
versions: Python 3.8, Python 3.9

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

From report at bugs.python.org  Sun Apr 12 07:04:21 2020
From: report at bugs.python.org (Ruben)
Date: Sun, 12 Apr 2020 11:04:21 +0000
Subject: [New-bugs-announce] [issue40261] Build of Python where make is
 called from subprocess, within a virtualenv, breaks on macOS
Message-ID: <1586689461.86.0.934526151918.issue40261@roundup.psfhosted.org>


New submission from Ruben <rubendibattista at gmail.com>:

This problem is driving me crazy. I'm working with a library (python-for-android) that builds python during a build process. 

Now, during this process, the classical workflow with `./configure` and `make` is being called from a subprocess. To try to isolate the issue, I call `make` to build Python from a file, let's call it `make.py`, in the source tree, where I simply do (after running `./configure`, manually or from a subprocess):

```
import subprocess; 
subprocess.run(["make", "-j8"])
```

I get the following error: 

```
/opt/local/bin/ranlib: file: libpython3.8.a(dynamic_annotations.o) has no symbols
/opt/local/bin/ranlib: file: libpython3.8.a(pymath.o) has no symbols
gcc     -Wl,-stack_size,1000000  -framework CoreFoundation -o python.exe Programs/python.o libpython3.8.a -ldl   -framework CoreFoundation
gcc     -Wl,-stack_size,1000000  -framework CoreFoundation -o Programs/_testembed Programs/_testembed.o libpython3.8.a -ldl   -framework CoreFoundation
./python.exe -E -S -m sysconfig --generate-posix-vars ;\
        if test $? -ne 0 ; then \
                echo "generate-posix-vars failed" ; \
                rm -f ./pybuilddir.txt ; \
                exit 1 ; \
        fi
 CC='gcc' LDSHARED='gcc -bundle -undefined dynamic_lookup    ' OPT='-DNDEBUG -g -fwrapv -O3 -Wall'      _TCLTK_INCLUDES='' _TCLTK_LIBS=''       ./python.exe -E ./setup.py  build
```

Is this a bug of my OS, my env configuration, venv/virtualenv, Python makefile or, most probably, myself? 

I attached the log files from the following runs: 
- make from the shell without virtualenv (`make.log`)
- make from shell within virtualenv (`make.venv.log`)
- make from python subprocess without virtualenv (`make.py.log`)
- make from python subprocess within a virtualenv creted with pew (`make.py.venv.log)
- make from python subprocess within a virtualenv created with venv (`make.py.venv2.log`)

My system details:

macOS 10.15.4

Steps to reproduce: 

1. Download Python-3.8.2
2. Extract the tgz
3. Run ./configure
4. cat `make.py` in the source tree where `make.py` is:
```
import subprocess

subprocess.run(["env"])
subprocess.run(["make", "-j8"])
```
5. Run python make.py

----------
components: Installation, macOS
files: make.py.venv.log.gz
messages: 366232
nosy: ned.deily, rdbisme, ronaldoussoren
priority: normal
severity: normal
status: open
title: Build of Python where make is called from subprocess, within a virtualenv, breaks on macOS
type: compile error
versions: Python 3.8
Added file: https://bugs.python.org/file49050/make.py.venv.log.gz

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

From report at bugs.python.org  Sun Apr 12 13:28:18 2020
From: report at bugs.python.org (tzickel)
Date: Sun, 12 Apr 2020 17:28:18 +0000
Subject: [New-bugs-announce] [issue40262] SSL recv_into requires the object
 to implement __len__ unlike socket one
Message-ID: <1586712498.2.0.649122705148.issue40262@roundup.psfhosted.org>


New submission from tzickel <icebreak at yahoo.com>:

I am writing this as a bug, as I have an object which implements the buffer protocol but not the __len__.

SSL's recv_into seems to require the buffer object to implement __len__, but this is unlike the socket recv_into which uses the buffer protocol length.

Here is the socket.recv_into implementation:
https://github.com/python/cpython/blob/402e1cdb132f384e4dcde7a3d7ec7ea1fc7ab527/Modules/socketmodule.c#L3556

as you can see, the length is optional, and it not given, it takes it from the buffer protocol length.

But here is SSL recv_into implementation:
https://github.com/python/cpython/blob/master/Lib/ssl.py#L1233

if length is not given, it tries to call the __len__ of the object itself (not it's buffer protocol).

----------
assignee: christian.heimes
components: SSL
messages: 366257
nosy: christian.heimes, tzickel
priority: normal
severity: normal
status: open
title: SSL recv_into requires the object to implement __len__ unlike socket one
type: behavior
versions: Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Sun Apr 12 14:19:42 2020
From: report at bugs.python.org (Ray Donnelly)
Date: Sun, 12 Apr 2020 18:19:42 +0000
Subject: [New-bugs-announce] [issue40263] Follow on bug from
 https://bugs.python.org/issue26903 (ValueError exception on
 _winapi.WaitForMultipleObjects)
Message-ID: <1586715582.96.0.679053084097.issue40263@roundup.psfhosted.org>


New submission from Ray Donnelly <rdonnelly at anaconda.com>:

See attached reproducer

----------
components: Interpreter Core, Windows
files: ppe.py
messages: 366258
nosy: Ray Donnelly, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Follow on bug from https://bugs.python.org/issue26903 (ValueError exception on _winapi.WaitForMultipleObjects)
versions: Python 3.7, Python 3.8
Added file: https://bugs.python.org/file49055/ppe.py

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

From report at bugs.python.org  Sun Apr 12 15:41:29 2020
From: report at bugs.python.org (Rahul B)
Date: Sun, 12 Apr 2020 19:41:29 +0000
Subject: [New-bugs-announce] [issue40264] List item inside tuple seemingly
 allows for item assignment even after throwing error
Message-ID: <1586720489.25.0.970851417478.issue40264@roundup.psfhosted.org>


New submission from Rahul B <rahul.bishain at gmail.com>:

Even though item assignment throws error, the list inside tuple 'a' gets modified in place. Refer below, where the list value [8] gets added to the list value [5,6,7,7] at a[3]

>>> a
(2, 3, 4, [5, 6, 7, 7], 1)
>>> id(a[3])
140531212178376
>>> a[3]+=[8]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'tuple' object does not support item assignment
>>> a
(2, 3, 4, [5, 6, 7, 7, 8], 1)
>>> id(a[3])
140531212178376

----------
messages: 366264
nosy: Rahul B
priority: normal
severity: normal
status: open
title: List item inside tuple seemingly allows for item assignment even after throwing error
type: behavior
versions: Python 3.7

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

From report at bugs.python.org  Sun Apr 12 15:46:18 2020
From: report at bugs.python.org (Saiyang Gou)
Date: Sun, 12 Apr 2020 19:46:18 +0000
Subject: [New-bugs-announce] [issue40265] argparse.Namespace __repr__ does
 not handle reserved keywords
Message-ID: <1586720778.53.0.603692808459.issue40265@roundup.psfhosted.org>


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

It is generally a convention to design the repr string such that `eval(repr(obj))` can reproduce the object. Issue 24360 handles the special situation when arg name passed to `argparse.Namespace` is not a valid identifier:

>>> from argparse import Namespace
>>> Namespace(**{')': 3})
Namespace(**{')': 3})

However there is one more corner case to handle: the arg name could be a reserved keyword.

>>> Namespace(**{'return': 3})
Namespace(return=3)
>>> Namespace(return=3)
  File "<stdin>", line 1
    Namespace(return=3)
              ^
SyntaxError: invalid syntax

I noticed that the documentation of `str.isidentifier` tells me to also check for keywords with `keyword.iskeyword`. However `__debug__` is not considered a keyword by `keyword.iskeyword`, but cannot be assigned to:

>>> keyword.iskeyword('__debug__')
False
>>> Namespace(**{'__debug__':3})
Namespace(__debug__=3)
>>> Namespace(__debug__=3)
  File "<stdin>", line 1
SyntaxError: cannot assign to __debug__

I propose to enhance the arg name check in `argparse._AttributeHolder` from `if name.isidentifier():` to `if name.isidentifier() and not keyword.iskeyword(name) and name != '__debug__:'` to fix this. However this may slow down the argparse library since it will need to `import keyword` at the beginning, and `__repr__` will also be slower due to the added arg name checks.

By the way, when I came across issue 39076, I noticed that `types.SimpleNamespace` is not considering this problem at all:

>>> types.SimpleNamespace(**{')': 1, 'return': 2})
namespace()=1, return=2)

----------
components: Library (Lib)
messages: 366265
nosy: gousaiyang
priority: normal
severity: normal
status: open
title: argparse.Namespace __repr__ does not handle reserved keywords
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Sun Apr 12 16:16:49 2020
From: report at bugs.python.org (Anthony Sottile)
Date: Sun, 12 Apr 2020 20:16:49 +0000
Subject: [New-bugs-announce] [issue40266] Failure to build _ssl module on
 ubuntu xenial
Message-ID: <1586722609.26.0.314965536558.issue40266@roundup.psfhosted.org>


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

Haven't yet bisected, but noticed this in the nightly builds I provide for ubuntu deadsnakes https://github.com/deadsnakes/nightly -- I believe it to be this patch so I've added to nosy: https://github.com/python/cpython/pull/19082

Both python3.8 and python3.9 are currently failing with a similar error:

2020-04-12T15:08:17.0217595Z x86_64-linux-gnu-gcc -pthread -fPIC -Wdate-time -D_FORTIFY_SOURCE=2 -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -g -fstack-protector -Wformat -Werror=format-security -std=c99 -Wextra -Wno-unused-result -Wno-unused-parameter -Wno-missing-field-initializers -Werror=implicit-function-declaration -I../Include/internal -I../Include -IObjects -IPython -I. -I/usr/include/x86_64-linux-gnu -I/tmp/code/Include -I/tmp/code/build-shared -c /tmp/code/Modules/_ssl.c -o build/temp.linux-x86_64-3.8/tmp/code/Modules/_ssl.o
2020-04-12T15:08:17.1350180Z In file included from /tmp/code/Modules/_ssl.c:136:0:
2020-04-12T15:08:17.1351441Z /tmp/code/Modules/_ssl_data.h:6:15: error: ???ERR_LIB_ASYNC??? undeclared here (not in a function)
2020-04-12T15:08:17.1352097Z      {"ASYNC", ERR_LIB_ASYNC},
2020-04-12T15:08:17.1352338Z                ^
2020-04-12T15:08:17.1355975Z /tmp/code/Modules/_ssl_data.h:13:12: error: ???ERR_LIB_CT??? undeclared here (not in a function)
2020-04-12T15:08:17.1356503Z      {"CT", ERR_LIB_CT},
2020-04-12T15:08:17.1356692Z             ^
2020-04-12T15:08:17.1357242Z /tmp/code/Modules/_ssl_data.h:19:13: error: ???ERR_LIB_KDF??? undeclared here (not in a function)
2020-04-12T15:08:17.1357579Z      {"KDF", ERR_LIB_KDF},
2020-04-12T15:08:17.1357784Z              ^
2020-04-12T15:08:17.1366068Z In file included from /tmp/code/Modules/_ssl.c:136:0:
2020-04-12T15:08:17.1366527Z /tmp/code/Modules/_ssl_data.h:598:28: error: initializer element is not constant
2020-04-12T15:08:17.1366913Z      {"FAILED_TO_SET_POOL", ERR_LIB_ASYNC, 101},
2020-04-12T15:08:17.1367202Z                             ^
2020-04-12T15:08:17.1368223Z /tmp/code/Modules/_ssl_data.h:598:28: note: (near initialization for ???error_codes[112].library???)
2020-04-12T15:08:17.1370670Z /tmp/code/Modules/_ssl_data.h:603:32: error: initializer element is not constant
2020-04-12T15:08:17.1371883Z      {"FAILED_TO_SWAP_CONTEXT", ERR_LIB_ASYNC, 102},
2020-04-12T15:08:17.1372824Z                                 ^
2020-04-12T15:08:17.1374744Z /tmp/code/Modules/_ssl_data.h:603:32: note: (near initialization for ???error_codes[113].library???)
2020-04-12T15:08:17.1376008Z /tmp/code/Modules/_ssl_data.h:608:21: error: initializer element is not constant
2020-04-12T15:08:17.1377003Z      {"INIT_FAILED", ERR_LIB_ASYNC, 105},
2020-04-12T15:08:17.1377757Z                      ^
2020-04-12T15:08:17.1378839Z /tmp/code/Modules/_ssl_data.h:608:21: note: (near initialization for ???error_codes[114].library???)
2020-04-12T15:08:17.1379355Z /tmp/code/Modules/_ssl_data.h:613:27: error: initializer element is not constant
2020-04-12T15:08:17.1379774Z      {"INVALID_POOL_SIZE", ERR_LIB_ASYNC, 103},
2020-04-12T15:08:17.1380044Z                            ^
2020-04-12T15:08:17.1380663Z /tmp/code/Modules/_ssl_data.h:613:27: note: (near initialization for ???error_codes[115].library???)
2020-04-12T15:08:17.1391167Z /tmp/code/Modules/_ssl_data.h:1458:29: error: initializer element is not constant
2020-04-12T15:08:17.1392255Z      {"BASE64_DECODE_ERROR", ERR_LIB_CT, 108},
2020-04-12T15:08:17.1392949Z                              ^
2020-04-12T15:08:17.1394611Z /tmp/code/Modules/_ssl_data.h:1458:29: note: (near initialization for ???error_codes[284].library???)
2020-04-12T15:08:17.1395718Z /tmp/code/Modules/_ssl_data.h:1463:31: error: initializer element is not constant
2020-04-12T15:08:17.1396628Z      {"INVALID_LOG_ID_LENGTH", ERR_LIB_CT, 100},
2020-04-12T15:08:17.1407884Z                                ^
2020-04-12T15:08:17.1408725Z /tmp/code/Modules/_ssl_data.h:1463:31: note: (near initialization for ???error_codes[285].library???)
2020-04-12T15:08:17.1409300Z /tmp/code/Modules/_ssl_data.h:1468:26: error: initializer element is not constant
2020-04-12T15:08:17.1409726Z      {"LOG_CONF_INVALID", ERR_LIB_CT, 109},
2020-04-12T15:08:17.1410042Z                           ^
2020-04-12T15:08:17.1410675Z /tmp/code/Modules/_ssl_data.h:1468:26: note: (near initialization for ???error_codes[286].library???)
2020-04-12T15:08:17.1411199Z /tmp/code/Modules/_ssl_data.h:1473:30: error: initializer element is not constant
2020-04-12T15:08:17.1411612Z      {"LOG_CONF_INVALID_KEY", ERR_LIB_CT, 110},
2020-04-12T15:08:17.1411921Z                               ^
2020-04-12T15:08:17.1412514Z /tmp/code/Modules/_ssl_data.h:1473:30: note: (near initialization for ???error_codes[287].library???)
2020-04-12T15:08:17.1413202Z /tmp/code/Modules/_ssl_data.h:1478:38: error: initializer element is not constant
2020-04-12T15:08:17.1413930Z      {"LOG_CONF_MISSING_DESCRIPTION", ERR_LIB_CT, 111},
2020-04-12T15:08:17.1414331Z                                       ^
2020-04-12T15:08:17.1415017Z /tmp/code/Modules/_ssl_data.h:1478:38: note: (near initialization for ???error_codes[288].library???)
2020-04-12T15:08:17.1415594Z /tmp/code/Modules/_ssl_data.h:1483:30: error: initializer element is not constant
2020-04-12T15:08:17.1416189Z      {"LOG_CONF_MISSING_KEY", ERR_LIB_CT, 112},
2020-04-12T15:08:17.1416559Z                               ^
2020-04-12T15:08:17.1417368Z /tmp/code/Modules/_ssl_data.h:1483:30: note: (near initialization for ???error_codes[289].library???)
2020-04-12T15:08:17.1417934Z /tmp/code/Modules/_ssl_data.h:1488:25: error: initializer element is not constant
2020-04-12T15:08:17.1418395Z      {"LOG_KEY_INVALID", ERR_LIB_CT, 113},
2020-04-12T15:08:17.1418734Z                          ^
2020-04-12T15:08:17.1419625Z /tmp/code/Modules/_ssl_data.h:1488:25: note: (near initialization for ???error_codes[290].library???)
2020-04-12T15:08:17.1420263Z /tmp/code/Modules/_ssl_data.h:1493:30: error: initializer element is not constant
2020-04-12T15:08:17.1420754Z      {"SCT_FUTURE_TIMESTAMP", ERR_LIB_CT, 116},
2020-04-12T15:08:17.1421155Z                               ^
2020-04-12T15:08:17.1421879Z /tmp/code/Modules/_ssl_data.h:1493:30: note: (near initialization for ???error_codes[291].library???)
2020-04-12T15:08:17.1422497Z /tmp/code/Modules/_ssl_data.h:1498:21: error: initializer element is not constant
2020-04-12T15:08:17.1422987Z      {"SCT_INVALID", ERR_LIB_CT, 104},
2020-04-12T15:08:17.1423346Z                      ^
2020-04-12T15:08:17.1424075Z /tmp/code/Modules/_ssl_data.h:1498:21: note: (near initialization for ???error_codes[292].library???)
2020-04-12T15:08:17.1424702Z /tmp/code/Modules/_ssl_data.h:1503:31: error: initializer element is not constant
2020-04-12T15:08:17.1425654Z      {"SCT_INVALID_SIGNATURE", ERR_LIB_CT, 107},
2020-04-12T15:08:17.1426049Z                                ^
2020-04-12T15:08:17.1426851Z /tmp/code/Modules/_ssl_data.h:1503:31: note: (near initialization for ???error_codes[293].library???)
2020-04-12T15:08:17.1427455Z /tmp/code/Modules/_ssl_data.h:1508:26: error: initializer element is not constant
2020-04-12T15:08:17.1427950Z      {"SCT_LIST_INVALID", ERR_LIB_CT, 105},
2020-04-12T15:08:17.1428323Z                           ^
2020-04-12T15:08:17.1429049Z /tmp/code/Modules/_ssl_data.h:1508:26: note: (near initialization for ???error_codes[294].library???)
2020-04-12T15:08:17.1429685Z /tmp/code/Modules/_ssl_data.h:1513:29: error: initializer element is not constant
2020-04-12T15:08:17.1430181Z      {"SCT_LOG_ID_MISMATCH", ERR_LIB_CT, 114},
2020-04-12T15:08:17.1430592Z                              ^
2020-04-12T15:08:17.1431317Z /tmp/code/Modules/_ssl_data.h:1513:29: note: (near initialization for ???error_codes[295].library???)
2020-04-12T15:08:17.1431922Z /tmp/code/Modules/_ssl_data.h:1518:21: error: initializer element is not constant
2020-04-12T15:08:17.1432389Z      {"SCT_NOT_SET", ERR_LIB_CT, 106},
2020-04-12T15:08:17.1432774Z                      ^
2020-04-12T15:08:17.1433487Z /tmp/code/Modules/_ssl_data.h:1518:21: note: (near initialization for ???error_codes[296].library???)
2020-04-12T15:08:17.1434091Z /tmp/code/Modules/_ssl_data.h:1523:33: error: initializer element is not constant
2020-04-12T15:08:17.1434602Z      {"SCT_UNSUPPORTED_VERSION", ERR_LIB_CT, 115},
2020-04-12T15:08:17.1435008Z                                  ^
2020-04-12T15:08:17.1437511Z /tmp/code/Modules/_ssl_data.h:1523:33: note: (near initialization for ???error_codes[297].library???)
2020-04-12T15:08:17.1438038Z /tmp/code/Modules/_ssl_data.h:1528:36: error: initializer element is not constant
2020-04-12T15:08:17.1438427Z      {"UNRECOGNIZED_SIGNATURE_NID", ERR_LIB_CT, 101},
2020-04-12T15:08:17.1438737Z                                     ^
2020-04-12T15:08:17.1439350Z /tmp/code/Modules/_ssl_data.h:1528:36: note: (near initialization for ???error_codes[298].library???)
2020-04-12T15:08:17.1439852Z /tmp/code/Modules/_ssl_data.h:1533:32: error: initializer element is not constant
2020-04-12T15:08:17.1440237Z      {"UNSUPPORTED_ENTRY_TYPE", ERR_LIB_CT, 102},
2020-04-12T15:08:17.1440533Z                                 ^
2020-04-12T15:08:17.1441138Z /tmp/code/Modules/_ssl_data.h:1533:32: note: (near initialization for ???error_codes[299].library???)
2020-04-12T15:08:17.1441633Z /tmp/code/Modules/_ssl_data.h:1538:29: error: initializer element is not constant
2020-04-12T15:08:17.1442122Z      {"UNSUPPORTED_VERSION", ERR_LIB_CT, 103},
2020-04-12T15:08:17.1442407Z                              ^
2020-04-12T15:08:17.1443077Z /tmp/code/Modules/_ssl_data.h:1538:29: note: (near initialization for ???error_codes[300].library???)
2020-04-12T15:08:17.1443577Z /tmp/code/Modules/_ssl_data.h:2598:24: error: initializer element is not constant
2020-04-12T15:08:17.1443946Z      {"INVALID_DIGEST", ERR_LIB_KDF, 100},
2020-04-12T15:08:17.1444216Z                         ^
2020-04-12T15:08:17.1444808Z /tmp/code/Modules/_ssl_data.h:2598:24: note: (near initialization for ???error_codes[512].library???)
2020-04-12T15:08:17.1445308Z /tmp/code/Modules/_ssl_data.h:2603:33: error: initializer element is not constant
2020-04-12T15:08:17.1445693Z      {"MISSING_ITERATION_COUNT", ERR_LIB_KDF, 109},
2020-04-12T15:08:17.1445977Z                                  ^
2020-04-12T15:08:17.1446599Z /tmp/code/Modules/_ssl_data.h:2603:33: note: (near initialization for ???error_codes[513].library???)
2020-04-12T15:08:17.1447090Z /tmp/code/Modules/_ssl_data.h:2608:21: error: initializer element is not constant
2020-04-12T15:08:17.1447467Z      {"MISSING_KEY", ERR_LIB_KDF, 104},
2020-04-12T15:08:17.1447717Z                      ^
2020-04-12T15:08:17.1448313Z /tmp/code/Modules/_ssl_data.h:2608:21: note: (near initialization for ???error_codes[514].library???)
2020-04-12T15:08:17.1448796Z /tmp/code/Modules/_ssl_data.h:2613:32: error: initializer element is not constant
2020-04-12T15:08:17.1449194Z      {"MISSING_MESSAGE_DIGEST", ERR_LIB_KDF, 105},
2020-04-12T15:08:17.1449475Z                                 ^
2020-04-12T15:08:17.1450094Z /tmp/code/Modules/_ssl_data.h:2613:32: note: (near initialization for ???error_codes[515].library???)
2020-04-12T15:08:17.1450579Z /tmp/code/Modules/_ssl_data.h:2618:27: error: initializer element is not constant
2020-04-12T15:08:17.1450972Z      {"MISSING_PARAMETER", ERR_LIB_KDF, 101},
2020-04-12T15:08:17.1451236Z                            ^
2020-04-12T15:08:17.1451856Z /tmp/code/Modules/_ssl_data.h:2618:27: note: (near initialization for ???error_codes[516].library???)
2020-04-12T15:08:17.1452339Z /tmp/code/Modules/_ssl_data.h:2623:22: error: initializer element is not constant
2020-04-12T15:08:17.1452727Z      {"MISSING_PASS", ERR_LIB_KDF, 110},
2020-04-12T15:08:17.1452973Z                       ^
2020-04-12T15:08:17.1453578Z /tmp/code/Modules/_ssl_data.h:2623:22: note: (near initialization for ???error_codes[517].library???)
2020-04-12T15:08:17.1454058Z /tmp/code/Modules/_ssl_data.h:2628:22: error: initializer element is not constant
2020-04-12T15:08:17.1454436Z      {"MISSING_SALT", ERR_LIB_KDF, 111},
2020-04-12T15:08:17.1454680Z                       ^
2020-04-12T15:08:17.1455277Z /tmp/code/Modules/_ssl_data.h:2628:22: note: (near initialization for ???error_codes[518].library???)
2020-04-12T15:08:17.1455758Z /tmp/code/Modules/_ssl_data.h:2633:24: error: initializer element is not constant
2020-04-12T15:08:17.1456145Z      {"MISSING_SECRET", ERR_LIB_KDF, 107},
2020-04-12T15:08:17.1456406Z                         ^
2020-04-12T15:08:17.1457006Z /tmp/code/Modules/_ssl_data.h:2633:24: note: (near initialization for ???error_codes[519].library???)
2020-04-12T15:08:17.1457495Z /tmp/code/Modules/_ssl_data.h:2638:22: error: initializer element is not constant
2020-04-12T15:08:17.1457874Z      {"MISSING_SEED", ERR_LIB_KDF, 106},
2020-04-12T15:08:17.1458120Z                       ^
2020-04-12T15:08:17.1458720Z /tmp/code/Modules/_ssl_data.h:2638:22: note: (near initialization for ???error_codes[520].library???)
2020-04-12T15:08:17.1459200Z /tmp/code/Modules/_ssl_data.h:2643:32: error: initializer element is not constant
2020-04-12T15:08:17.1459597Z      {"UNKNOWN_PARAMETER_TYPE", ERR_LIB_KDF, 103},
2020-04-12T15:08:17.1459878Z                                 ^
2020-04-12T15:08:17.1460496Z /tmp/code/Modules/_ssl_data.h:2643:32: note: (near initialization for ???error_codes[521].library???)
2020-04-12T15:08:17.1460976Z /tmp/code/Modules/_ssl_data.h:2648:21: error: initializer element is not constant
2020-04-12T15:08:17.1461411Z      {"VALUE_ERROR", ERR_LIB_KDF, 108},
2020-04-12T15:08:17.1461655Z                      ^
2020-04-12T15:08:17.1462262Z /tmp/code/Modules/_ssl_data.h:2648:21: note: (near initialization for ???error_codes[522].library???)
2020-04-12T15:08:17.1462798Z /tmp/code/Modules/_ssl_data.h:2653:23: error: initializer element is not constant
2020-04-12T15:08:17.1463177Z      {"VALUE_MISSING", ERR_LIB_KDF, 102},
2020-04-12T15:08:17.1463427Z                        ^
2020-04-12T15:08:17.1464034Z /tmp/code/Modules/_ssl_data.h:2653:23: note: (near initialization for ???error_codes[523].library???)


Here's a link to a full compile: https://dev.azure.com/deadsnakes/fd93d290-ae2b-4409-ab75-b3679f781215/_apis/build/builds/277/logs/89

----------
assignee: christian.heimes
components: Extension Modules, SSL
messages: 366266
nosy: Anthony Sottile, benjamin.peterson, christian.heimes
priority: normal
severity: normal
status: open
title: Failure to build _ssl module on ubuntu xenial
type: compile error
versions: Python 3.8, Python 3.9

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

From report at bugs.python.org  Sun Apr 12 17:59:24 2020
From: report at bugs.python.org (Lysandros Nikolaou)
Date: Sun, 12 Apr 2020 21:59:24 +0000
Subject: [New-bugs-announce] [issue40267] Error message differs when an
 expression is in an fstring
Message-ID: <1586728764.59.0.587923723315.issue40267@roundup.psfhosted.org>


New submission from Lysandros Nikolaou <lisandrosnik at gmail.com>:

There are cases, where the error message differs, when an expression is being parsed inside an fstring. For example:

>>> f'{x+}'
  File "<fstring>", line 1
    (x+)
       ^
SyntaxError: unexpected EOF while parsing
>>> (x+)
  File "<stdin>", line 1
    (x+)
       ^
SyntaxError: invalid syntax

Or with lambda definitions:

>>> f'{lambda x:x}'
  File "<fstring>", line 1
    (lambda x)
             ^
SyntaxError: unexpected EOF while parsing
>>> (lambda x)
  File "<stdin>", line 1
    (lambda x)
             ^
SyntaxError: invalid syntax

----------
components: Interpreter Core
messages: 366272
nosy: gvanrossum, lys.nikolaou, pablogsal
priority: normal
severity: normal
status: open
title: Error message differs when an expression is in an fstring
versions: Python 3.9

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

From report at bugs.python.org  Sun Apr 12 19:01:07 2020
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 12 Apr 2020 23:01:07 +0000
Subject: [New-bugs-announce] [issue40268] Reorganize pycore_pystate.h header
Message-ID: <1586732467.85.0.974458317268.issue40268@roundup.psfhosted.org>


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

Over the time, pycore_pystate.h header file becomes more and more complex. It exposes too many internals whereas most consumers only need basic functions like _PyThreadState_GET().

I plan to use this issue as a placeholder for changes to reorganize pycore_pystate.h. I'm working on multiple pull requests.

----------
components: Interpreter Core
messages: 366274
nosy: vstinner
priority: normal
severity: normal
status: open
title: Reorganize pycore_pystate.h header
versions: Python 3.9

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

From report at bugs.python.org  Sun Apr 12 20:03:28 2020
From: report at bugs.python.org (Rushil Udani)
Date: Mon, 13 Apr 2020 00:03:28 +0000
Subject: [New-bugs-announce] [issue40269] Inconsistent complex behavior with
 (-1j)
Message-ID: <1586736208.71.0.129112794549.issue40269@roundup.psfhosted.org>


New submission from Rushil Udani <rushil.udani at gmail.com>:

In a Python REPL:

>>> -1j
(-0-1j)
>>> (-1j)
(-0-1j)
>>> 0-1j
-1j
>>> -0-1j
-1j

This is clearly inconsistent behavior! -1j and (-1j) should report as -1j, as the other two do.

----------
components: Interpreter Core
messages: 366276
nosy: rushilu
priority: normal
severity: normal
status: open
title: Inconsistent complex behavior with (-1j)
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Mon Apr 13 05:37:52 2020
From: report at bugs.python.org (Big Stone)
Date: Mon, 13 Apr 2020 09:37:52 +0000
Subject: [New-bugs-announce] [issue40270] activation json1 extension in
 sqlite
Message-ID: <1586770672.18.0.207799300786.issue40270@roundup.psfhosted.org>


New submission from Big Stone <stonebig34 at gmail.com>:

hi all. On Windows/Mac, isn't sqlite3 module compiled with "json1" extension on recent Python releases ?

I thought it was, but fails to use it.

Python 3.9.0a5 (tags/v3.9.0a5:dcd4c4f, Mar 23 2020, 20:39:59) [MSC v.1924 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license()" for more information.
>>> import sqlite3
>>> conn = sqlite3.connect(":memory:")
>>> cursor = conn.cursor()
>>> cursor.execute("select sqlite_version()").fetchall()
[('3.31.1',)]
>>> cursor.execute("select json_object('a',2,'c',4)").fetchall()

Traceback (most recent call last):
  File "<pyshell#5>", line 1, in <module>
    cursor.execute("select json_object('a',2,'c',4)").fetchall()
sqlite3.OperationalError: no such function: json_object
>>>

----------
messages: 366290
nosy: Big Stone
priority: normal
severity: normal
status: open
title: activation json1 extension in sqlite

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

From report at bugs.python.org  Mon Apr 13 06:33:50 2020
From: report at bugs.python.org (Gavin D'souza)
Date: Mon, 13 Apr 2020 10:33:50 +0000
Subject: [New-bugs-announce] [issue40271] Allow shell like paths in
Message-ID: <1586774030.36.0.315208521295.issue40271@roundup.psfhosted.org>


New submission from Gavin D'souza <gavin18d at gmail.com>:

Related library: zipfile

Since zipfile allows relative dotted paths too, should shell-like paths, specifically with ~ (tilde) be allowed too?

This feels like unexpected behaviour and confusing for users as method "is_zipfile" returns False in case path doesn't exist as well. So, zipfile.is_zipfile("~/incorrect/path/to/zip") as well as zipfile.is_zipfile("~/path/to/zip") will return False

----------
components: Library (Lib)
messages: 366297
nosy: gavin
priority: normal
severity: normal
status: open
title: Allow shell like paths in
type: behavior
versions: Python 2.7, 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/issue40271>
_______________________________________

From report at bugs.python.org  Mon Apr 13 06:46:31 2020
From: report at bugs.python.org (Gavin D'souza)
Date: Mon, 13 Apr 2020 10:46:31 +0000
Subject: [New-bugs-announce] [issue40272] ModuleNotFoundEror thrown by
 system python while accessing it specifically via venv python
Message-ID: <1586774791.09.0.0735699698392.issue40272@roundup.psfhosted.org>


New submission from Gavin D'souza <gavin18d at gmail.com>:

I have a tool that works as a wrapper over a web framework which in turn utilizes a virtualenv environment. So every app to be installed for a project is installed in it's own env folder. 

Recently, the virtualenv has been breaking throwing 'ModuleNotFoundError's however this issue only persists in macOS. The applications installed in each project's env are editable installs. The ModuleNotFoundError's are raised by the global python install which is all the more confusing as the commands are specifically executing using absolute paths in the env python and should be in the env site-packages. Even after successful env installs, activating the env and simply typing "import frappe" throws a ModuleNotFoundError. 

Reference commands executed by the wrapper program are like
./env/bin/python -m install -q -U -e ./apps/frappe

have also tried absolute paths but faced the same issue. However, this issue doesn't persist while using pyenv on macOS. Linux systems work fine too.

----------
components: macOS
messages: 366299
nosy: gavin, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: ModuleNotFoundEror thrown by system python while accessing it specifically via venv python
type: behavior
versions: Python 2.7, Python 3.6, Python 3.7, Python 3.8

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

From report at bugs.python.org  Mon Apr 13 09:54:42 2020
From: report at bugs.python.org (jack1142)
Date: Mon, 13 Apr 2020 13:54:42 +0000
Subject: [New-bugs-announce] [issue40273] mappingproxy isn't reversible
Message-ID: <1586786082.33.0.84219610791.issue40273@roundup.psfhosted.org>


New submission from jack1142 <kuba.kuczys at gmail.com>:

Starting in version 3.8, dicts are reversible so it would make sense if mapping proxy were also reversible. Especially that `reversed(proxied_dict.keys())` does work.

----------
messages: 366315
nosy: jack1142
priority: normal
severity: normal
status: open
title: mappingproxy isn't reversible
versions: Python 3.8, Python 3.9

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

From report at bugs.python.org  Mon Apr 13 18:14:34 2020
From: report at bugs.python.org (Brian O'Sullivan)
Date: Mon, 13 Apr 2020 22:14:34 +0000
Subject: [New-bugs-announce] [issue40274] 3D plotting library doesn't
 occlude objects by depth/perspective (objects in the scene are printed in
 layers).
Message-ID: <1586816074.17.0.60379010692.issue40274@roundup.psfhosted.org>


New submission from Brian O'Sullivan <brianmosullivan at outlook.com>:

3D plotting library doesn't occlude objects by depth/perspective.

When the figure is regenerated during the animation, each additional line and points is printed on top of the prior lines and points.

Bug resolution:
 - incorporate occlusions in the 3D plotting / animation library

----------
components: Library (Lib)
files: hopf1.py
messages: 366334
nosy: mo-geometry
priority: normal
severity: normal
status: open
title: 3D plotting library doesn't occlude objects by depth/perspective (objects in the scene are printed in layers).
type: enhancement
versions: Python 3.6
Added file: https://bugs.python.org/file49060/hopf1.py

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

From report at bugs.python.org  Mon Apr 13 18:24:51 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 13 Apr 2020 22:24:51 +0000
Subject: [New-bugs-announce] [issue40275] test.support has way too many
 imports
Message-ID: <1586816691.28.0.874442798421.issue40275@roundup.psfhosted.org>


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

test_threading.ThreadJoinOnShutdown.test_reinit_tls_after_fork() does crash on AIX: bpo-40068. One of the issue is that logging does crash at fork: bpo-40091. The strange thing is that test_threading doesn't use logging. I'm quite sure that logging is imported through test.support.

"import test.support" imports not less than 171... That's quite "heavy". It includes "heavy" modules like concurrent.futures, asyncio or multiprocessing.

It's maybe time to slice again test.support until submodules to reduce the number of imports to the bare minimum. For example, "import test.support" imports asyncio, whereas it's only used by very few tests. Maybe we should add "test.support.asyncioutils".

$ ./python
Python 3.9.0a5+ (heads/pycore_interp:a1ff2c5cf3, Apr 13 2020, 12:27:13) 
>>> import sys
>>> import test

>>> before=set(sys.modules)
>>> import test.support
>>> after=set(sys.modules)

>>> len(after - before)
171

>>> import pprint
>>> pprint.pprint(sorted(after - before))
['__mp_main__',
 '_asyncio',
 '_bisect',
 '_blake2',
 '_bz2',
 '_collections',
 '_compat_pickle',
 '_compression',
 '_contextvars',
 '_datetime',
 '_elementtree',
 '_functools',
 '_hashlib',
 '_heapq',
 '_lzma',
 '_opcode',
 '_operator',
 '_pickle',
 '_posixsubprocess',
 '_queue',
 '_random',
 '_sha3',
 '_sha512',
 '_socket',
 '_sre',
 '_ssl',
 '_string',
 '_struct',
 '_sysconfigdata_d_linux_x86_64-linux-gnu',
 '_weakrefset',
 'argparse',
 'array',
 'asyncio',
 'asyncio.base_events',
 'asyncio.base_futures',
 'asyncio.base_subprocess',
 'asyncio.base_tasks',
 'asyncio.constants',
 'asyncio.coroutines',
 'asyncio.events',
 'asyncio.exceptions',
 'asyncio.format_helpers',
 'asyncio.futures',
 'asyncio.locks',
 'asyncio.log',
 'asyncio.protocols',
 'asyncio.queues',
 'asyncio.runners',
 'asyncio.selector_events',
 'asyncio.sslproto',
 'asyncio.staggered',
 'asyncio.streams',
 'asyncio.subprocess',
 'asyncio.tasks',
 'asyncio.transports',
 'asyncio.trsock',
 'asyncio.unix_events',
 'base64',
 'binascii',
 'bisect',
 'bz2',
 'collections',
 'collections.abc',
 'concurrent',
 'concurrent.futures',
 'concurrent.futures._base',
 'contextlib',
 'contextvars',
 'copy',
 'copyreg',
 'datetime',
 'difflib',
 'dis',
 'email',
 'email.base64mime',
 'email.charset',
 'email.encoders',
 'email.errors',
 'email.header',
 'email.quoprimime',
 'enum',
 'errno',
 'faulthandler',
 'fnmatch',
 'functools',
 'gc',
 'gettext',
 'glob',
 'grp',
 'gzip',
 'hashlib',
 'heapq',
 'importlib',
 'importlib._bootstrap',
 'importlib._bootstrap_external',
 'importlib.abc',
 'importlib.machinery',
 'importlib.util',
 'inspect',
 'itertools',
 'keyword',
 'linecache',
 'locale',
 'logging',
 'logging.handlers',
 'lzma',
 'math',
 'multiprocessing',
 'multiprocessing.context',
 'multiprocessing.process',
 'multiprocessing.reduction',
 'nntplib',
 'opcode',
 'operator',
 'pickle',
 'platform',
 'pprint',
 'pwd',
 'pyexpat',
 'pyexpat.errors',
 'pyexpat.model',
 'queue',
 'quopri',
 'random',
 're',
 'reprlib',
 'resource',
 'select',
 'selectors',
 'shutil',
 'signal',
 'socket',
 'sre_compile',
 'sre_constants',
 'sre_parse',
 'ssl',
 'string',
 'struct',
 'subprocess',
 'sysconfig',
 'tempfile',
 'test.support',
 'test.support.testresult',
 'threading',
 'token',
 'tokenize',
 'traceback',
 'types',
 'typing',
 'typing.io',
 'typing.re',
 'unittest',
 'unittest.async_case',
 'unittest.case',
 'unittest.loader',
 'unittest.main',
 'unittest.result',
 'unittest.runner',
 'unittest.signals',
 'unittest.suite',
 'unittest.util',
 'urllib',
 'urllib.error',
 'urllib.response',
 'warnings',
 'weakref',
 'xml',
 'xml.etree',
 'xml.etree.ElementPath',
 'xml.etree.ElementTree',
 'zlib']

----------
components: Tests
messages: 366337
nosy: vstinner
priority: normal
severity: normal
status: open
title: test.support has way too many imports
versions: Python 3.9

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

From report at bugs.python.org  Mon Apr 13 21:12:01 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 14 Apr 2020 01:12:01 +0000
Subject: [New-bugs-announce] [issue40276] Make member objects inspectable.
Message-ID: <1586826721.81.0.357033101024.issue40276@roundup.psfhosted.org>


New submission from Raymond Hettinger <raymond.hettinger at gmail.com>:

Given:

    class A:
        __slots__ = ['x', 'y', 'z')

    mo = vars(A)['x']

The field number should be viewable:

    >>> mo.offset
    0

And the __repr__ should be:

    >>> mo
    <member 'x' at slot_offset 0 of 'A' objects>

----------
components: Interpreter Core
keywords: easy (C)
messages: 366356
nosy: rhettinger
priority: normal
severity: normal
status: open
title: Make member objects inspectable.
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Mon Apr 13 21:23:39 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 14 Apr 2020 01:23:39 +0000
Subject: [New-bugs-announce] [issue40277] Improve repr for _tuplegetter
 objects
Message-ID: <1586827419.3.0.773379446138.issue40277@roundup.psfhosted.org>


New submission from Raymond Hettinger <raymond.hettinger at gmail.com>:

Formerly, the accessor for named tuples were more informative:

    >>> class Pt(NamedTuple):
            x: int
            y: int

    >>> vars(Pt)['x']
    <property object at 0x10cc09a70>
    >>> vars(Pt)['x'].fget
    operator.itemgetter(0)

Currently, it is less informative:

    >>> vars(Pt)['x']
    <_collections._tuplegetter object at 0x1066a08e0>

The repr should be updated to show how the object could been created:

    >>> vars(Pt)['x']
    _tuplegetter(0, 'Alias for field number 0')

----------
assignee: rhettinger
components: Interpreter Core
keywords: easy (C)
messages: 366357
nosy: rhettinger
priority: normal
severity: normal
status: open
title: Improve repr for _tuplegetter objects
type: enhancement

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

From report at bugs.python.org  Mon Apr 13 23:36:59 2020
From: report at bugs.python.org (Michael Selik)
Date: Tue, 14 Apr 2020 03:36:59 +0000
Subject: [New-bugs-announce] [issue40278] pathlib Path.replace raises
 OSError when target exists
Message-ID: <1586835419.23.0.357197099635.issue40278@roundup.psfhosted.org>


New submission from Michael Selik <mike at selik.org>:

The pathlib module ``Path.replace(target)`` states that "If target points to an existing file or directory, it will be unconditionally replaced."  However, this does not appear to be true.  I experience an OSError ``[Errno 66] Directory not empty`` when attempting to ``replace`` to an existant target.

https://docs.python.org/3/library/pathlib.html#pathlib.Path.replace


I see that others on StackOverflow encounter the same issue.  The top answer ignores the Python documentation and recommends removing the target directory before replacing.

https://stackoverflow.com/questions/50355180/use-pathlib-to-destructively-rename-one-directory-to-another-existing-directory

----------
messages: 366363
nosy: selik
priority: normal
severity: normal
status: open
title: pathlib Path.replace raises OSError when target exists
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Tue Apr 14 02:08:29 2020
From: report at bugs.python.org (Stefan Behnel)
Date: Tue, 14 Apr 2020 06:08:29 +0000
Subject: [New-bugs-announce] [issue40279] Documentation example of module
 init function lacks error handling
Message-ID: <1586844509.3.0.451475770029.issue40279@roundup.psfhosted.org>


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

The example in the docs that shows how to initialise an embedded module gives a wrong impression about error handling. Most of the functions that it calls return error codes, but those do not get looked at. Innocent users who copy and paste the example may miss some of them when adapting the code, thus ending up with an unsafe implementation.

The example should at least make it clear where error handling is needed.

https://docs.python.org/3/extending/extending.html#the-module-s-method-table-and-initialization-function

int
main(int argc, char *argv[])
{
    wchar_t *program = Py_DecodeLocale(argv[0], NULL);
    if (program == NULL) {
        fprintf(stderr, "Fatal error: cannot decode argv[0]\n");
        exit(1);
    }

    /* Add a built-in module, before Py_Initialize */
    PyImport_AppendInittab("spam", PyInit_spam);

    /* Pass argv[0] to the Python interpreter */
    Py_SetProgramName(program);

    /* Initialize the Python interpreter.  Required. */
    Py_Initialize();

    /* Optionally import the module; alternatively,
       import can be deferred until the embedded script
       imports it. */
    PyImport_ImportModule("spam");

    ...

    PyMem_RawFree(program);
    return 0;
}

----------
assignee: docs at python
components: Documentation
keywords: easy, newcomer friendly
messages: 366368
nosy: docs at python, scoder
priority: normal
severity: normal
stage: needs patch
status: open
title: Documentation example of module init function lacks error handling
type: enhancement
versions: Python 3.8, Python 3.9

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

From report at bugs.python.org  Tue Apr 14 03:11:35 2020
From: report at bugs.python.org (Simon Biggs)
Date: Tue, 14 Apr 2020 07:11:35 +0000
Subject: [New-bugs-announce] [issue40280] Consider supporting
 emscripten/webassembly as a build target
Message-ID: <1586848295.92.0.690921486188.issue40280@roundup.psfhosted.org>


New submission from Simon Biggs <simon.grant.biggs at gmail.com>:

Since asm.js came on the scene, and now Web Assembly people have created CPython patches to support building CPython with emscripten. See:

* https://github.com/PeachPy/EmCPython -- Python 2.7
* https://github.com/dgym/cpython-emscripten/tree/master/3.5.2/patches -- Python 3.5.2
* https://github.com/iodide-project/pyodide/tree/master/cpython/patches -- Python 3.7.4

To ease the compiling of CPython with emscripten it would be helpful if patches that achieved these ends for the compiling to Web Assembly with emscripten were built into the upstream source repository itself.

If web assembly were to became a supported compilation target of the upstream CPython repository this would significantly reduce the friction of allowing CPython, and the latest CPython, to become a language readily usable within the browser.

Cheers,
Simon

----------
components: Build
messages: 366369
nosy: Simon Biggs
priority: normal
severity: normal
status: open
title: Consider supporting emscripten/webassembly as a build target
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Tue Apr 14 09:13:01 2020
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 14 Apr 2020 13:13:01 +0000
Subject: [New-bugs-announce] [issue40281] Add pathlib.PurePath.as_uri()
Message-ID: <1586869981.39.0.314985055066.issue40281@roundup.psfhosted.org>


New submission from Antoine Pitrou <solipsis at pitrou.net>:

"file" scheme URIs are normalized:
https://tools.ietf.org/html/rfc8089

Therefore it would be possible to provide a PurePath method that returns a "file" scheme URI corresponding to the given path.

----------
components: Library (Lib)
messages: 366384
nosy: pitrou
priority: normal
severity: normal
status: open
title: Add pathlib.PurePath.as_uri()
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Tue Apr 14 11:32:35 2020
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 14 Apr 2020 15:32:35 +0000
Subject: [New-bugs-announce] [issue40282] random.getrandbits(0) should
 succeed
Message-ID: <1586878355.33.0.583777817655.issue40282@roundup.psfhosted.org>


New submission from Antoine Pitrou <solipsis at pitrou.net>:

When creating variable-sized random binary strings with random.getrandbits(), you currently have to special case when the number of bytes is 0, because otherwise getrandbits() raises:

  ValueError: number of bits must be greater than zero

It seems like it wouldn't hurt to simply return 0 in that case.

The actual snippet looks something like:

  random.getrandombits(nbytes * 8).to_bytes(nbytes, 'little')

----------
messages: 366392
nosy: mark.dickinson, pitrou, rhettinger, steven.daprano
priority: normal
severity: normal
status: open
title: random.getrandbits(0) should succeed
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Tue Apr 14 12:54:40 2020
From: report at bugs.python.org (guchao)
Date: Tue, 14 Apr 2020 16:54:40 +0000
Subject: [New-bugs-announce] [issue40283] Documentation of turtle.circle()
Message-ID: <1586883280.42.0.803600338852.issue40283@roundup.psfhosted.org>


New submission from guchao <guchao2000 at 163.com>:

refer to circle() in the url: https://docs.python.org/2/library/turtle.html#turtle.circle

[current]
... Draw the arc in counterclockwise direction if radius is positive, otherwise in clockwise direction. 

[suggestion]
... Draw the arc in counterclockwise direction if extent is positive, otherwise in clockwise direction. 

[explanation]
It should be "extent" , instead of "radius", that affects the direction.

----------
assignee: docs at python
components: Documentation
messages: 366401
nosy: docs at python, guchao
priority: normal
severity: normal
status: open
title: Documentation of turtle.circle()
type: resource usage

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

From report at bugs.python.org  Tue Apr 14 17:10:49 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 14 Apr 2020 21:10:49 +0000
Subject: [New-bugs-announce] [issue40284] Add mapping methods to
 types.SimpleNamespace
Message-ID: <1586898649.19.0.221456344176.issue40284@roundup.psfhosted.org>


New submission from Raymond Hettinger <raymond.hettinger at gmail.com>:

types.SimpleNamespace() would be much more usable if it were more substitutable for dictionaries.   In particular, it would be wonderful to be able to use object_hook=SimpleNamespace in json.load():

Current:

     catalog = json.load(f)
     print(catalog['clothing']['mens']['shoes']['extra_wide']['quantity'])

Proposed:

     catalog = json.load(f, object_hook=SimpleNamespace)
     print(catalog.clothing.mens.shoes.extra_wide.quantity])

----------
components: Library (Lib)
messages: 366447
nosy: rhettinger
priority: normal
severity: normal
status: open
title: Add mapping methods to types.SimpleNamespace
versions: Python 3.9

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

From report at bugs.python.org  Tue Apr 14 18:30:18 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 14 Apr 2020 22:30:18 +0000
Subject: [New-bugs-announce] [issue40286] Add getrandbytes() method to
 random.Random
Message-ID: <1586903418.02.0.530735802731.issue40286@roundup.psfhosted.org>


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

The random module lacks a getrandbytes() method which leads developers to be creative how to generate bytes:
https://stackoverflow.com/questions/5495492/random-byte-string-in-python

It's a common use request:

* bpo-13396 in 2011
* bpo-27096 in 2016
* https://bugs.python.org/issue40282#msg366444 in 2020

Python already has three functions to generate random bytes:

* os.getrandom(): specific to Linux, not portable
* os.urandom()
* secrets.token_bytes()

These 3 functions are based on system entropy and they block on Linux until the kernel collected enough entropy: PEP 524.

While many users are fine with these functions, there are also use cases for simulation where the security doesn't matter, and it's more about being able to get reproducible experience from a seed. That's what random.Random is about.

The numpy module provides numpy.random.bytes(length) function for such use case:
https://docs.scipy.org/doc/numpy-1.15.0/reference/generated/numpy.random.bytes.html

One example can be to generate UUID4 with the ability to reproduce the random UUID from a seed for testing purpose, or to get reproducible behavior.

Attached PR implements the getrandbytes() method.

----------
components: Library (Lib)
messages: 366454
nosy: vstinner
priority: normal
severity: normal
status: open
title: Add getrandbytes() method to random.Random
versions: Python 3.9

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

From report at bugs.python.org  Tue Apr 14 21:41:51 2020
From: report at bugs.python.org (amcinnes)
Date: Wed, 15 Apr 2020 01:41:51 +0000
Subject: [New-bugs-announce] [issue40287] SpooledTemporaryFile.seek returns
 None
Message-ID: <1586914911.28.0.271091942099.issue40287@roundup.psfhosted.org>


New submission from amcinnes <angus at amcinnes.info>:

The documentation says SpooledTemporaryFile "operates exactly as TemporaryFile() does".

seek() would be expected to return the new absolute position; this is what it does for TemporaryFile, and is the documented behaviour of seek() in IOBase. But for SpooledTemporaryFile it returns None.

Probably trivial to fix by sticking a "return" on https://github.com/python/cpython/blob/0361556537686f857f1025ead75e6af4ca7cc94a/Lib/tempfile.py#L741

Python 3.8.2 (default, Apr  8 2020, 14:31:25) 
[GCC 9.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import tempfile
>>> t = tempfile.TemporaryFile()
>>> print(t.seek(0))
0
>>> u = tempfile.SpooledTemporaryFile()
>>> print(u.seek(0))
None
>>>

----------
components: Library (Lib)
messages: 366475
nosy: amcinnes
priority: normal
severity: normal
status: open
title: SpooledTemporaryFile.seek returns None
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Tue Apr 14 22:16:49 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 15 Apr 2020 02:16:49 +0000
Subject: [New-bugs-announce] [issue40288] atexit module should not be loaded
 more than once per interpreter
Message-ID: <1586917009.7.0.806642420762.issue40288@roundup.psfhosted.org>


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

Since Python 3.7, it's possible to load the atexit module more than once:

commit 776407fe893fd42972c7e3f71423d9d86741d07c
Author: Marcel Plch <gmarcel.plch at gmail.com>
Date:   Wed Dec 20 11:17:58 2017 +0100

    bpo-31901: atexit callbacks should be run at subinterpreter shutdown (#4611)
    
    Change atexit behavior and PEP-489 multiphase init support.

Each new import executes the module which overrides PyInterpreterState.pyexitfunc with _Py_PyAtExit().

Example:
---
import sys

atexit1 = sys.modules.pop('atexit', None)
if atexit1 is None:
    import atexit as atexit1
    del sys.modules['atexit']

import atexit as atexit2

atexit1.register(print, "atexit1 callback")
atexit2.register(print, "atexit2 callback")
---

Output:
---
atexit2 callback
---

Either PyInterpreterState should support a list of exit functions, or atexit should raise an exception if it's loaded more than once.

call_ll_exitfuncs() calls a list of functions: _PyRuntimeState.exitfuncs. But these functions are called at the end of Py_Finalize(), whereas atexit functions are called after calling threading._shutdown() in Py_Finalize() and Py_EndInterpreter().

----------
components: Library (Lib)
messages: 366478
nosy: corona10, vstinner
priority: normal
severity: normal
status: open
title: atexit module should not be loaded more than once per interpreter
versions: Python 3.9

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

From report at bugs.python.org  Tue Apr 14 22:40:38 2020
From: report at bugs.python.org (thautwarm)
Date: Wed, 15 Apr 2020 02:40:38 +0000
Subject: [New-bugs-announce] [issue40289] "highlighting" how to get Python's
 Scripts directory in the documentation
Message-ID: <1586918438.96.0.496326994048.issue40289@roundup.psfhosted.org>


New submission from thautwarm <yaoxiansamma at gmail.com>:

Currently it's barely impossible for us to search about "How to get where Scripts directory/folder is".

If we google this, we can only get answers about '__file__', which is far from the expectation.

The correct information lies on
- https://github.com/python/cpython/blob/master/Doc/install/index.rst
- https://github.com/python/cpython/blob/master/Lib/sysconfig.py

It's also not the first time I want to google this but this is the first time I got the answer, by dipping into the source code and searching in the codebase.

I'd hope we can directly mention the phrase "Python Scripts directory" in the documentation of 'sysconfig' module.

----------
messages: 366480
nosy: thautwarm
priority: normal
severity: normal
status: open
title: "highlighting" how to get Python's Scripts directory in the documentation

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

From report at bugs.python.org  Tue Apr 14 23:14:09 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 15 Apr 2020 03:14:09 +0000
Subject: [New-bugs-announce] [issue40290] Add z_score to
 statistics.NormalDist
Message-ID: <1586920449.06.0.712419472387.issue40290@roundup.psfhosted.org>


New submission from Raymond Hettinger <raymond.hettinger at gmail.com>:

I've had a couple of requests for a z-score method, once to produce an actual z-score for output and another as a way of normalizing gaussian inputs for machine learning.

Proposed:

    >>> iq = NormalDist(100, 15)
    >>> iq.zscore(142)
    2.8

Same result as:

    >>> (142 - iq.mean) / iq.stdev
    2.8

There is some question about whether to name it zscore or z_score.  Numpy uses zscore but numpy tends to scrunch names where we would tend to spell them out or use an underscore for readability.

See: https://en.wikipedia.org/wiki/Standard_score

----------
assignee: rhettinger
components: Library (Lib)
messages: 366484
nosy: rhettinger, steven.daprano
priority: normal
severity: normal
status: open
title: Add z_score to statistics.NormalDist
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Wed Apr 15 01:29:19 2020
From: report at bugs.python.org (Karl Ding)
Date: Wed, 15 Apr 2020 05:29:19 +0000
Subject: [New-bugs-announce] [issue40291] socket library support for
 CAN_J1939
Message-ID: <1586928559.09.0.469111314858.issue40291@roundup.psfhosted.org>


New submission from Karl Ding <karl.jw.ding at gmail.com>:

It would be nice to have support J1939 sockets.

Support for J1939 landed as part of the SAE J1939 SocketCAN patches, which are available after the Linux 5.4rc1 kernel. This is another protocol family for SocketCAN, much like the existing support for ISOTP and BCM.

Effectively, supporting this would hand off as much to the kernel as possible, which gives Python programs the ability deal with J1939 without having to implement the logic existing in the kernel in userspace.

This is provided to userspace [0] via the <linux/can/j1939.h> header.

I'd be happy to work on this and provide a PR.

[0] https://www.kernel.org/doc/html/latest/networking/j1939.html

----------
components: Library (Lib)
messages: 366487
nosy: karlding
priority: normal
severity: normal
status: open
title: socket library support for CAN_J1939
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Wed Apr 15 04:36:26 2020
From: report at bugs.python.org (pavlos kallis)
Date: Wed, 15 Apr 2020 08:36:26 +0000
Subject: [New-bugs-announce] [issue40292] Memory leak when defining a new
 class inside a loop
Message-ID: <1586939786.47.0.691824545248.issue40292@roundup.psfhosted.org>


New submission from pavlos kallis <pakallis at gmail.com>:

Running the script, memory starts to leak and garbage count increases.

Running the same script in python 2.7 does not cause the memory leak.

----------
components: C API
files: memory_leak.py
messages: 366495
nosy: pavlos kallis
priority: normal
severity: normal
status: open
title: Memory leak when defining a new class inside a loop
type: resource usage
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9
Added file: https://bugs.python.org/file49062/memory_leak.py

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

From report at bugs.python.org  Wed Apr 15 11:02:42 2020
From: report at bugs.python.org (Gregory Szorc)
Date: Wed, 15 Apr 2020 15:02:42 +0000
Subject: [New-bugs-announce] [issue40293] cpython-source-deps project
 missing release for libffi commits
Message-ID: <1586962962.85.0.815414541497.issue40293@roundup.psfhosted.org>


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

The https://github.com/python/cpython-source-deps project is missing a source archive release for commits to libffi needed to support building on Windows.

The latest release of libffi is version libffi-3.3.0-rc0-r1, which corresponds to https://github.com/python/cpython-source-deps/commit/8ba2b2c38744420a235e3e7f419cce2591aaf331.

There have been a few commits since that release: https://github.com/python/cpython-source-deps/compare/8ba2b2c38744420a235e3e7f419cce2591aaf331...libffi

Most notable is https://github.com/python/cpython-source-deps/commit/ed22026f39b37f892ded95d7b30e77dfb5126334 because without this commit, the source is not buildable on Windows using MSVC, at least not with the  prepare_ffi.bat script in CPython's Git repository. (Build fails due to issues with FFI_BUILDING_DLL).

Would it be possible to cut a new tag and upload a source tarball for libffi?

----------
components: Build, Windows
messages: 366523
nosy: indygreg, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: cpython-source-deps project missing release for libffi commits
type: enhancement

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

From report at bugs.python.org  Wed Apr 15 13:32:05 2020
From: report at bugs.python.org (Jeffrey Quesnelle)
Date: Wed, 15 Apr 2020 17:32:05 +0000
Subject: [New-bugs-announce] [issue40294] Use-after-free crash if multiple
 interpreters import asyncio module
Message-ID: <1586971925.67.0.678462551955.issue40294@roundup.psfhosted.org>


New submission from Jeffrey Quesnelle <jquesnelle at gmail.com>:

Starting with Python 3.8 (GH-16598), the `_asyncio` module's C initialization is guarded behind a static variable. If the module is initialized a second time and this variable is set, the resources from the first initialization are used. However, when the module is freed and the corresponding resources released, the static variable is not cleared. If the module is subsequently initialized again, it will incorrectly believe it has already been initialized and use the previously freed resources, resulting in a crash.

This scenario is actually fairly easy to encounter in the presence of multiple interpreters whose lifetime is shorter than that of the whole program. Essentially, if any interpreter loads `asyncio` and then is freed with `Py_EndInterpreter`, any new interpreter that loads `asyncio` will crash. Since `asyncio` is a built-in module, it is loaded as a consequence of a wide variety of libraries.

I ran into this in my project because I use multiple interpreters to isolate user scripts, and I started to encounter crashes when switching to Python 3.8.

I've attached a simple reproduction program. I've personally tested that this runs without crashing in 3.6 and 3.7 (but I suspect it works down to 3.4 when `asyncio` was introduced).

----------
components: C API
files: main.c
messages: 366531
nosy: jquesnelle
priority: normal
severity: normal
status: open
title: Use-after-free crash if multiple interpreters import asyncio module
type: crash
versions: Python 3.8, Python 3.9
Added file: https://bugs.python.org/file49064/main.c

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

From report at bugs.python.org  Wed Apr 15 16:37:13 2020
From: report at bugs.python.org (=?utf-8?q?Filip_Rembia=C5=82kowski?=)
Date: Wed, 15 Apr 2020 20:37:13 +0000
Subject: [New-bugs-announce] [issue40295] doctest handling of multiline
 strings is broken
Message-ID: <1586983033.33.0.799206208911.issue40295@roundup.psfhosted.org>


New submission from Filip Rembia?kowski <filip.rembialkowski at gmail.com>:

The doctest module does not compare multiline strings properly, as attached example proves. 

Tested on 2.7, 3.6 and 3.9.0a5+. (platform: Ubuntu 18.04).

Related: https://stackoverflow.com/questions/60956015/unexpected-errors-while-testing-python3-code-with-doctest

----------
components: Library (Lib)
files: doctest-bugs.py
messages: 366554
nosy: Filip Rembia?kowski
priority: normal
severity: normal
status: open
title: doctest handling of multiline strings is broken
type: behavior
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9
Added file: https://bugs.python.org/file49065/doctest-bugs.py

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

From report at bugs.python.org  Wed Apr 15 16:50:17 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 15 Apr 2020 20:50:17 +0000
Subject: [New-bugs-announce] [issue40296] help(list[int]) fails
Message-ID: <1586983817.03.0.686824683966.issue40296@roundup.psfhosted.org>


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

>>> help(list[int])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/serhiy/py/cpython/Lib/_sitebuiltins.py", line 103, in __call__
    return pydoc.help(*args, **kwds)
  File "/home/serhiy/py/cpython/Lib/pydoc.py", line 1905, in __call__
    self.help(request)
  File "/home/serhiy/py/cpython/Lib/pydoc.py", line 1964, in help
    else: doc(request, 'Help on %s:', output=self._output)
  File "/home/serhiy/py/cpython/Lib/pydoc.py", line 1684, in doc
    pager(render_doc(thing, title, forceload))
  File "/home/serhiy/py/cpython/Lib/pydoc.py", line 1677, in render_doc
    return title % desc + '\n\n' + renderer.document(object, name)
  File "/home/serhiy/py/cpython/Lib/pydoc.py", line 381, in document
    if inspect.isclass(object): return self.docclass(*args)
  File "/home/serhiy/py/cpython/Lib/pydoc.py", line 1251, in docclass
    (str(cls.__name__) for cls in type.__subclasses__(object)
TypeError: descriptor '__subclasses__' for 'type' objects doesn't apply to a 'types.GenericAlias' object

----------
components: Library (Lib)
messages: 366558
nosy: gvanrossum, serhiy.storchaka
priority: normal
severity: normal
status: open
title: help(list[int]) fails
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Wed Apr 15 23:25:02 2020
From: report at bugs.python.org (Karl Ding)
Date: Thu, 16 Apr 2020 03:25:02 +0000
Subject: [New-bugs-announce] [issue40297] test_socket.CANTest is broken at
 HEAD on master
Message-ID: <1587007502.68.0.180919322143.issue40297@roundup.psfhosted.org>


New submission from Karl Ding <karl.jw.ding at gmail.com>:

While working on https://bugs.python.org/issue40291, I was trying to run the SocketCAN tests to ensure that my changes weren't causing any regressions. However, I was seeing test failures at HEAD.

I'm running the tests like so:

# Kernel version
uname -r
# 5.4.23-1-MANJARO

# Load SocketCAN vcan kernel module
sudo modprobe vcan

# Start and set up a virtual SocketCAN interface
sudo ip link add dev vcan0 type vcan
sudo ip link set up vcan0

# Run the socket tests using locally built python
./python -m unittest -v test.test_socket.CANTest

After bisecting, I discovered that the test started failing back in 2017, with the introduction of the ISOTP protocol. https://github.com/python/cpython/pull/2956/files#diff-a47fd74731aeb547ad780900bb8e6953L1376-R1391

Here, the address family (the second tuple item) is explicitly removed:

diff --git a/Modules/socketmodule.c b/Modules/socketmodule.c
index bf8d19fe2f..beadecfad5 100644
--- a/Modules/socketmodule.c
+++ b/Modules/socketmodule.c
@@ -1373,9 +1373,22 @@ makesockaddr(SOCKET_T sockfd, struct sockaddr *addr, size_t addrlen, int proto)
                 ifname = ifr.ifr_name;
         }

-        return Py_BuildValue("O&h", PyUnicode_DecodeFSDefault,
-                                    ifname,
-                                    a->can_family);
+        switch (proto) {
+#ifdef CAN_ISOTP
+          case CAN_ISOTP:
+          {
+              return Py_BuildValue("O&kk", PyUnicode_DecodeFSDefault,
+                                          ifname,
+                                          a->can_addr.tp.rx_id,
+                                          a->can_addr.tp.tx_id);
+          }
+#endif
+          default:
+          {
+              return Py_BuildValue("O&", PyUnicode_DecodeFSDefault,
+                                        ifname);
+          }
+        }
     }
 #endif

This seems to be an intentional breakage, since the code in getsockaddrarg also operates on just the interface name, ignoring the address family.

            if (!PyArg_ParseTuple(args,
                                  "O&;AF_CAN address must be a tuple "
                                  "(interface, )",
                                  PyUnicode_FSConverter, &interfaceName))

As such, I believe the test should have been updated, but was missed during the ISOTP changes. Can someone (a core member?) confirm that this is the correct approach?

Note: However, this also implies that the CANTest test was never being run (either via CI on PRs or on the Buildbot cluster) and instead was always skipped, since I would've expected this failure to show up right away...

----------
components: Library (Lib)
messages: 366576
nosy: karlding
priority: normal
severity: normal
status: open
title: test_socket.CANTest is broken at HEAD on master
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Thu Apr 16 03:27:17 2020
From: report at bugs.python.org (Noah May)
Date: Thu, 16 Apr 2020 07:27:17 +0000
Subject: [New-bugs-announce] [issue40298] Type annotation objects (Tuple,
 List, etc.) register as callable()
Message-ID: <1587022037.69.0.998051306567.issue40298@roundup.psfhosted.org>


New submission from Noah May <noahmouse2011 at gmail.com>:

Whether this is considered a bug or not is subjective. The question is should callable(Tuple) return True or False? Or should it for any other annotation object?

The reason it returns true in the first place is because of a warning to explicitly NOT call them as functions/constructors:

>>> from typing import Tuple
>>> callable(Tuple)
True
>>> Tuple()
TypeError: Type Tuple cannot be instantiated; use tuple() instead

Source code: https://github.com/python/cpython/blob/master/Lib/typing.py#L724:L733

I honestly don't know how this could be "fixed" if it even needs to be fixed. But I just wanted to bring attention to it.

Cheers.

----------
components: Library (Lib)
messages: 366580
nosy: Noah May
priority: normal
severity: normal
status: open
title: Type annotation objects (Tuple, List, etc.) register as callable()
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/issue40298>
_______________________________________

From report at bugs.python.org  Thu Apr 16 04:58:09 2020
From: report at bugs.python.org (krsna)
Date: Thu, 16 Apr 2020 08:58:09 +0000
Subject: [New-bugs-announce] [issue40299] os.dup seems broken with execvp
 (LINUX)
Message-ID: <1587027489.14.0.0429159118409.issue40299@roundup.psfhosted.org>


New submission from krsna <bhrt_k at yahoo.com>:

---CODE---
import os
path = "file.txt"
  
fd = os.open(path, os.O_WRONLY) 
  
os.close(1) #STDOUT
os.dup(fd)
pid = os.fork()

if pid == 0:
    args = "ls -l".split() 
    os.execvp(args[0], args)
else:
    os.waitpid(pid, 0)
    print('Done from Parent')
--- END CODE ---

Running this with python
```
> python -V
Python 3.8.2
```
I get the following:
```
> echo"" > file.txt && python example.py && cat file.txt 
ls: write error: Bad file descriptor
Done from Parent

```
Running the same with micropython:
```
> echo"">file.txt && micropython me && cat file.txt 
total 76
drwxr-xr-x 2 user user  4096 Apr  5 15:29 Desktop
drwxr-xr-x 2 user user  4096 Apr  5 15:29 Documents
drwxr-xr-x 2 user user  4096 Apr 13 18:22 Downloads
drwxr-xr-x 2 user user  4096 Apr  5 15:29 Music
drwxr-xr-x 2 user user  4096 Apr 12 11:16 Pictures
drwxr-xr-x 2 user user  4096 Apr  5 15:29 Public
drwxr-xr-x 2 user user  4096 Apr  5 15:29 Templates
drwxr-xr-x 2 user user  4096 Apr  5 15:29 Videos
-rw-rw-r-- 1 user user   244 Apr 15 22:02 example.py
Done from Parent
```
With the follow C which is almost a 1:1 to the CODE segment above
```
#include <stdio.h>
#include <fcntl.h>
#include <unistd.h>

int main(int argc, const char *argv[])
{
    int fd = open("file.txt", O_WRONLY);

	close(1);
	dup(fd);
	
    if (fork() == 0) {
    	char *cmd = "ls";
		char *argv[3];
		argv[0] = "ls";
		argv[1] = "-l";
		argv[2] = NULL;
  		execvp(cmd, argv);
	} else {
  		wait(0);
  		close(fd);

	    puts("Done from Parent");
	}

    return 0;
}
```
I get the same output as micropython example above
```
> echo"">file.txt && gcc ccc.c && ./a.out && cat file.txt 
total 76
drwxr-xr-x 2 user user  4096 Apr  5 15:29 Desktop
drwxr-xr-x 2 user user  4096 Apr  5 15:29 Documents
drwxr-xr-x 2 user user  4096 Apr 13 18:22 Downloads
drwxr-xr-x 2 user user  4096 Apr  5 15:29 Music
drwxr-xr-x 2 user user  4096 Apr 12 11:16 Pictures
drwxr-xr-x 2 user user  4096 Apr  5 15:29 Public
drwxr-xr-x 2 user user  4096 Apr  5 15:29 Templates
drwxr-xr-x 2 user user  4096 Apr  5 15:29 Videos
-rwxrwxr-x 1 user user 18904 Apr 15 22:53 a.out
-rw-rw-r-- 1 user user   395 Apr 15 22:50 ccc.c
-rw-rw-r-- 1 user user   244 Apr 15 22:02 example.py
Done from Parent
```
I tried looking around for the code of `dup` in cpython to compare, but could only find `dup2.c`.

----------
components: Library (Lib)
messages: 366587
nosy: krsna
priority: normal
severity: normal
status: open
title: os.dup seems broken with execvp (LINUX)
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Thu Apr 16 06:09:46 2020
From: report at bugs.python.org (Mariusz Felisiak)
Date: Thu, 16 Apr 2020 10:09:46 +0000
Subject: [New-bugs-announce] [issue40300] logging.Formatter crashes when
 default_msec_format is None.
Message-ID: <1587031786.91.0.398301028125.issue40300@roundup.psfhosted.org>


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

We would like to subclass logging.Formatter with a custom "default_time_format" and an empty "default_msec_format". Unfortunately logging.Formatter crashes when default_msec_format is None, see [1].

I'm happy to provide a patch.

[1] https://github.com/python/cpython/blob/5907e61a8d4da6d0f11bf1062d6d17484560a15e/Lib/logging/__init__.py#L607

----------
components: Library (Lib)
messages: 366589
nosy: Mariusz Felisiak
priority: normal
severity: normal
status: open
title: logging.Formatter crashes when default_msec_format is None.
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/issue40300>
_______________________________________

From report at bugs.python.org  Thu Apr 16 09:59:27 2020
From: report at bugs.python.org (Massimo Sala)
Date: Thu, 16 Apr 2020 13:59:27 +0000
Subject: [New-bugs-announce] [issue40301] zipfile module: new feature (two
 lines of code)
Message-ID: <1587045567.04.0.739688211881.issue40301@roundup.psfhosted.org>


New submission from Massimo Sala <massimo.sala.71 at gmail.com>:

module zipfile

Tag "Components": I am not sure "Library (Lib)" is the correct one. If it isn't, please fix.

I use python to check zip files against malware.
In these files the are binary blobs outside the ZIP archive.
The malware payload isn't inside the ZIP file structure.
Example: a file "openme.zip" with this content :
[blob from offset 0 to offset 5678] 
[ZIP archive from offset 5679 to end of file]

zipfile already handles this, finding the ZIP structure inside the file.

My change is just to add a new public property, to expose an internal variable: the file offset of the ZIP structure.

I know, I am after the code freeze of Python 2.7.18.
But the change is really trivial, see the diff.
I hope you can approve this patch for all the Python versions, also for 2.7, to have consistency. For 2.7 this is the last call.

----------
components: Library (Lib)
files: py27_zipfile.patch
keywords: patch
messages: 366597
nosy: massimosala
priority: normal
severity: normal
status: open
title: zipfile module: new feature (two lines of code)
type: enhancement
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9
Added file: https://bugs.python.org/file49067/py27_zipfile.patch

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

From report at bugs.python.org  Thu Apr 16 10:22:55 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 16 Apr 2020 14:22:55 +0000
Subject: [New-bugs-announce] [issue40302] Add _Py_bswap32() function to
 pyport.h
Message-ID: <1587046975.76.0.701994468055.issue40302@roundup.psfhosted.org>


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

There are multiple files which have to swap bytes. I propose to add functions for that:

* _Py_bswap16(): uint16_t
* _Py_bswap32(): uint32_t
* _Py_bswap64(): uint64_t

----------
components: Interpreter Core
messages: 366600
nosy: vstinner
priority: normal
severity: normal
status: open
title: Add _Py_bswap32() function to pyport.h
versions: Python 3.9

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

From report at bugs.python.org  Thu Apr 16 12:47:14 2020
From: report at bugs.python.org (Gharg)
Date: Thu, 16 Apr 2020 16:47:14 +0000
Subject: [New-bugs-announce] [issue40303] argparse parse_args args parameter
 bug or intended
Message-ID: <1587055634.08.0.65599497467.issue40303@roundup.psfhosted.org>


New submission from Gharg <ghaarg at gmail.com>:

I have a problem regarding args parameter of ArgumentParser.parse_args.

For example:
-------------------------------------
import argparse
parser = argparse.ArgumentParser()
parser.add_argument("--boolean", type=bool)
parsed_args = parser.parse_args(["--boolean=''"])
--------------------------------------

results in parsed_args.boolean evaluate to True.
While i understand why this is happening (inner call of bool("''") evaluates to True), i don't know if that is an expected behavior.
If we look from console argument pass perspective with the example altered:
test.py
-------------------------------------
import argparse
parser = argparse.ArgumentParser()
parser.add_argument("--boolean", type=bool)
parsed_args = parser.parse_args()
--------------------------------------

If i now call:

python test.py --boolean=""

parsed_args.boolean will evaluate to False.

----------
messages: 366608
nosy: Gharg
priority: normal
severity: normal
status: open
title: argparse parse_args args parameter bug or intended
type: behavior
versions: Python 3.7

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

From report at bugs.python.org  Thu Apr 16 13:31:50 2020
From: report at bugs.python.org (=?utf-8?b?0JHQvtGA0LjRgSDQktC10YDRhdC+0LLRgdC60LjQuQ==?=)
Date: Thu, 16 Apr 2020 17:31:50 +0000
Subject: [New-bugs-announce] [issue40304] Classes created using type() don't
 need to explicitly inherit from object
Message-ID: <1587058310.07.0.184434541864.issue40304@roundup.psfhosted.org>


New submission from ????? ?????????? <boris.verk at gmail.com>:

As far as I can tell, passing `(object,)` and `()` as the `bases` parameter to the 3-argument version of type() produces the same result, because classes inherit from `object` in Python 3:

>>> type('X', (object,), dict(a=1)).__bases__
(<class 'object'>,)
>>> type('X', (), dict(a=1)).__bases__
(<class 'object'>,)

I just want to make sure I'm not missing something and update the documentation of `type()` to reflect that.

----------
assignee: docs at python
components: Documentation
messages: 366613
nosy: boris, docs at python
priority: normal
pull_requests: 18902
severity: normal
status: open
title: Classes created using type() don't need to explicitly inherit from object
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Thu Apr 16 14:13:08 2020
From: report at bugs.python.org (ROUX antoine)
Date: Thu, 16 Apr 2020 18:13:08 +0000
Subject: [New-bugs-announce] [issue40305] Fix server_close() method for
 ThreadingHTTPServer and TCPServer class
Message-ID: <1587060788.93.0.613571029656.issue40305@roundup.psfhosted.org>


New submission from ROUX antoine <antoineroux51 at gmail.com>:

Maybe : 

Main problem is currently ThreadingHTTPServer which extends socketserver.ThreadingMixIn and HTTPServer don't overload his server_close() method. This method server_close is defined into both parent class and should be both call in implementation to avoid shadow definition.

Second and linked to first problem is the class socketserver.TCPServer which is parent class of HTTPServer and extend of BaseServer don't overload method server_close() properly indeed this overload call self.socket.close() but should also call super().shutdown() to avoid infinite thread join into ThreadingHTTPServer server_close() method.

Open to advice

----------
components: Library (Lib)
files: testHttpServer.py
messages: 366619
nosy: ROUX antoine2
priority: normal
severity: normal
status: open
title: Fix server_close() method for ThreadingHTTPServer and TCPServer class
type: behavior
versions: Python 3.9
Added file: https://bugs.python.org/file49068/testHttpServer.py

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

From report at bugs.python.org  Thu Apr 16 14:26:55 2020
From: report at bugs.python.org (bli2020)
Date: Thu, 16 Apr 2020 18:26:55 +0000
Subject: [New-bugs-announce] [issue40306] Enhancement request for SSLContext
 - flag to handle trailing dot in hostname
Message-ID: <1587061615.86.0.473018087621.issue40306@roundup.psfhosted.org>


New submission from bli2020 <brysonli at gmail.com>:

Issue31997 I know this issue was previously closed https://bugs.python.org/issue31997 because "it works as expected and should be handled in the application layer". But, could the team add a flag in SSLContext which will handle the trailing dot hostname appropriately (for the hostname check, since openssl does not support trailing dots in the hostname).

Previously in 2.7 and 3.6/before I was able to override ssl.match_hostname to add some extra checks, but now I am unable to do so because openssl is used instead. This extra flag/implementation would help solve this problem.

----------
assignee: christian.heimes
components: SSL
messages: 366620
nosy: bli2020, christian.heimes
priority: normal
severity: normal
status: open
title: Enhancement request for SSLContext - flag to handle trailing dot in hostname
type: enhancement
versions: Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Thu Apr 16 17:35:30 2020
From: report at bugs.python.org (Alessandro Molina)
Date: Thu, 16 Apr 2020 21:35:30 +0000
Subject: [New-bugs-announce] [issue40307] multiprocessing.BaseManager does
 not retain Client type.
Message-ID: <1587072930.89.0.0694830896032.issue40307@roundup.psfhosted.org>


New submission from Alessandro Molina <amol at turbogears.org>:

When a new `multiprocessing.managers.BaseManager` instance is made, the client used to connect is not stable across the life of the object.

A very quick example to show that is 

```
from unittest.mock import Mock
from multiprocessing.managers import SyncManager, listener_client

listener_client["faked"] = listener_client["xmlrpclib"] 
sm = SyncManager(serializer="faked")
```

As expected the manager is created with the XmlClient

```
>>> print(sm._Client.__name__)
XmlClient
```

but in reality, if the "faked" serializer is changed in any way

```
listener_client["faked"] = (None, Mock(side_effect=RuntimeError("BROKEN")))
```

When trying to connect, we will unexpectedly connect with whatever it is the serializer registered at the time of connection instead of the one bound to the SyncManager instance 

```
>>> sm.connect()
Traceback (most recent call last):
  File "/home/amol/wrk/cpython/prova.py", line 17, in <module>
    sm.connect()
  File "/home/amol/wrk/cpython/Lib/multiprocessing/managers.py", line 521, in connect
    conn = Client(self._address, authkey=self._authkey)
  ...
  File "/home/amol/wrk/cpython/Lib/unittest/mock.py", line 1152, in _execute_mock_call
    raise effect
RuntimeError: BROKEN
```

To make things worse, we would actually randomly use XmlClient or new one depending on which SyncManager method we call.

This makes also inconvenient to replace the connection layer with a fake one during tests to simulate stub responses. Furthermore the client of the manager is also not propagated properly to the proxies created through that manager making even less consistent the behaviour.

----------
components: Library (Lib)
messages: 366630
nosy: Alessandro Molina
priority: normal
severity: normal
status: open
title: multiprocessing.BaseManager does not retain Client type.
type: behavior
versions: Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Thu Apr 16 17:40:40 2020
From: report at bugs.python.org (Dennis Sweeney)
Date: Thu, 16 Apr 2020 21:40:40 +0000
Subject: [New-bugs-announce] [issue40308] Intermittent failure of
 test_os.TestScandir.test_attributes on Windows
Message-ID: <1587073240.99.0.668032471383.issue40308@roundup.psfhosted.org>


New submission from Dennis Sweeney <sweeney.dennis650 at gmail.com>:

I get the following intermittent failure when running the tests on Master on Windows 10.

=================================
=================================
=================================


PS C:\...\cpython> .\python.bat -m unittest -v test.test_os.TestScandir.test_attributes
Running Release|Win32 interpreter...
test_attributes (test.test_os.TestScandir) ... ok

----------------------------------------------------------------------
Ran 1 test in 0.005s

OK
PS C:\...\cpython> .\python.bat -m unittest -v test.test_os.TestScandir.test_attributes
Running Release|Win32 interpreter...
test_attributes (test.test_os.TestScandir) ... FAIL

======================================================================
FAIL: test_attributes (test.test_os.TestScandir)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\...\cpython\lib\test\test_os.py", line 3900, in test_attributes
    self.check_entry(entry, 'link_file.txt', False, True, False)
  File "C:\...\cpython\lib\test\test_os.py", line 3861, in check_entry
    self.assert_stat_equal(entry.stat(),
  File "C:\...\cpython\lib\test\test_os.py", line 3822, in assert_stat_equal
    self.assertEqual(getattr(stat1, attr),
AssertionError: 1587065935.7958326 != 1587065935.79683 : (os.stat_result(st_mode=33206, st_ino=0, st_dev=0, st_nlink=0, st_uid=0, st_gid=0, st_size=6, st_atime=1587065935, st_mtime=1587065935, st_ctime=1587065935), os.stat_result(st_mode=33206, st_ino=2533274791602992, st_dev=839545721, st_nlink=2, st_uid=0, st_gid=0, st_size=6, st_atime=1587065935, st_mtime=1587065935, st_ctime=1587065935), 'st_atime')

----------------------------------------------------------------------
Ran 1 test in 0.007s

FAILED (failures=1)

=================================
=================================
=================================


The failure seems to happen only about one in every 3 or 4 runs. Maybe this is unrelated, but I'm a little confused about why the repr of os.stat_result makes it look like st_atime is an int, but when accessing with .st_atime, we get a float that seems to just be st_atime_ns * 10**-9. I ran pdb during the failing test and got this:


=================================
=================================
=================================

-> self.assertEqual(getattr(stat1, attr),
(Pdb) stat1
os.stat_result(st_mode=33206, st_ino=0, st_dev=0, st_nlink=0, st_uid=0, st_gid=0, st_size=6, st_atime=1587071882, st_mtime=1587071882, st_ctime=1587071882)
(Pdb) stat1
os.stat_result(st_mode=33206, st_ino=0, st_dev=0, st_nlink=0, st_uid=0, st_gid=0, st_size=6, st_atime=1587071882, st_mtime=1587071882, st_ctime=1587071882)
(Pdb) stat1.st_atime == stat2.st_atime
False
(Pdb) stat1.st_atime
1587071882.6492443
(Pdb) stat2.st_atime
1587071882.6502416
(Pdb) stat1.st_atime_ns
1587071882649244400
(Pdb) stat2.st_atime_ns
1587071882650241700
(Pdb) dir(stat1)
['__add__', '__class__', '__class_getitem__', '__contains__', '__delattr__', '__dir__', '__doc__', '__eq__', '__format__', '__ge__', '__getattribute__', '__getitem__', '__getnewargs__', '__gt__', '__hash__', '__init__', '__init_subclass__', '__iter__', '__le__', '__len__', '__lt__', '__module__', '__mul__', '__ne__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__rmul__', '__setattr__', '__sizeof__', '__str__', '__subclasshook__', 'count', 'index', 'n_fields', 'n_sequence_fields', 'n_unnamed_fields', 'st_atime', 'st_atime_ns', 'st_ctime', 'st_ctime_ns', 'st_dev', 'st_file_attributes', 'st_gid', 'st_ino', 'st_mode', 'st_mtime', 'st_mtime_ns', 'st_nlink', 'st_reparse_tag', 'st_size', 'st_uid']
(Pdb) dir(stat2)
['__add__', '__class__', '__class_getitem__', '__contains__', '__delattr__', '__dir__', '__doc__', '__eq__', '__format__', '__ge__', '__getattribute__', '__getitem__', '__getnewargs__', '__gt__', '__hash__', '__init__', '__init_subclass__', '__iter__', '__le__', '__len__', '__lt__', '__module__', '__mul__', '__ne__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__rmul__', '__setattr__', '__sizeof__', '__str__', '__subclasshook__', 'count', 'index', 'n_fields', 'n_sequence_fields', 'n_unnamed_fields', 'st_atime', 'st_atime_ns', 'st_ctime', 'st_ctime_ns', 'st_dev', 'st_file_attributes', 'st_gid', 'st_ino', 'st_mode', 'st_mtime', 'st_mtime_ns', 'st_nlink', 'st_reparse_tag', 'st_size', 'st_uid']
(Pdb) tuple(stat1)
(33206, 0, 0, 0, 0, 0, 6, 1587071882, 1587071882, 1587071882)
(Pdb) tuple(stat2)
(33206, 9851624185502411, 839545721, 2, 0, 0, 6, 1587071882, 1587071882, 1587071882)
(Pdb)

=================================
=================================
=================================

----------
components: Windows
messages: 366631
nosy: Dennis Sweeney, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Intermittent failure of test_os.TestScandir.test_attributes on Windows
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Fri Apr 17 04:54:27 2020
From: report at bugs.python.org (Gerrit Ansmann)
Date: Fri, 17 Apr 2020 08:54:27 +0000
Subject: [New-bugs-announce] =?utf-8?b?W2lzc3VlNDAzMDldIOKAnHVubWF0Y2hl?=
 =?utf-8?q?d_paren=E2=80=9D_for_space_before_parenthesis_in_Py=5FBuildValu?=
 =?utf-8?q?e?=
Message-ID: <1587113667.76.0.930110442335.issue40309@roundup.psfhosted.org>


New submission from Gerrit Ansmann <gansmann at uni-bonn.de>:

According to the C-API documentation? for `Py_BuildValue`:

> The characters space, tab, colon and comma are ignored in format strings (but not within format units such as s#). This can be used to make long format strings a tad more readable.

However format strings such as `"(d )"` cause the error:

> Unmatched paren in format

By contrast `"( d)"` and `"(d d)"` cause no problems. I therefore assume that tuples are not considered ?format units? in the sense of the above quote and this is a bug. Alternatively, the documentation needs clarification.

I could reproduce this problem with Python 3.7 and 3.8. I did not try other versions.

Appended is a minimal C extension exhibiting the problem. I compile and run with:

gcc -fPIC -I/usr/include/python3.8 -c foo.c -o foo.o
gcc -shared foo.o -o foo.so
python3.8 -c "import foo; foo.bar()"

----

??https://docs.python.org/3/c-api/arg.html

----------
components: C API
files: foo.c
messages: 366647
nosy: Wrzlprmft
priority: normal
severity: normal
status: open
title: ?unmatched paren? for space before parenthesis in Py_BuildValue
versions: Python 3.7, Python 3.8
Added file: https://bugs.python.org/file49069/foo.c

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

From report at bugs.python.org  Fri Apr 17 06:17:23 2020
From: report at bugs.python.org (Maks Bleo)
Date: Fri, 17 Apr 2020 10:17:23 +0000
Subject: [New-bugs-announce] [issue40310] If use element from for in while
 loop it will have bad iterate.
Message-ID: <1587118643.2.0.902687286984.issue40310@roundup.psfhosted.org>


New submission from Maks Bleo <bleomaks at gmail.com>:

Windows 10
Version 1909 (OS Build18363.778)
Python 3.7.7 x64

cars_av_by_spider_scr.py - py file for scrapy.
bash command to use
scrapy runspider cars_av_by_spider_scr.py -o cars_av_by_spider_scr.json > cars_av_by_spider_scr.txt 2>&1

Bad behavior in line 52. (In comment fixed version)

When while loop iterate on second step instead of using
model[0], model[1] it start use model[1][0] and model[1][1].
On third step it  crash, out of range.

But if assign value before while loop and use it in while loop everything work fine. 


It's my first bug report.

----------
components: Interpreter Core
files: cars_av_by_spider_scr.py
messages: 366652
nosy: Maks Bleo
priority: normal
severity: normal
status: open
title: If use element from for in while loop it will have bad iterate.
type: behavior
versions: Python 3.7
Added file: https://bugs.python.org/file49071/cars_av_by_spider_scr.py

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

From report at bugs.python.org  Fri Apr 17 12:12:57 2020
From: report at bugs.python.org (Sumana Harihareswara)
Date: Fri, 17 Apr 2020 16:12:57 +0000
Subject: [New-bugs-announce] [issue40311] docs.python.org banner - release
 blocker for 2.7.18
Message-ID: <1587139977.42.0.984358391759.issue40311@roundup.psfhosted.org>


New submission from Sumana Harihareswara <sh at changeset.nyc>:

Add an --outdated flag to the build_docs.py script, which sets the 'outdated' value within HTML templates.

See also https://github.com/python/docsbuild-scripts/pull/86  which also would need to be merged.

I'm not sure how to mark this in the bug metadata, but this is a blocker for the final 2.7.18 release; see https://github.com/python/steering-council/issues/3 .

----------
assignee: docs at python
components: Documentation
messages: 366661
nosy: benjamin.peterson, docs at python, mdk, sumanah
priority: normal
pull_requests: 18911
severity: normal
status: open
title: docs.python.org banner - release blocker for 2.7.18
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Fri Apr 17 15:52:40 2020
From: report at bugs.python.org (Allan Feldman)
Date: Fri, 17 Apr 2020 19:52:40 +0000
Subject: [New-bugs-announce] [issue40312] Weakref callbacks running before
 finalizers in GC collection
Message-ID: <1587153160.93.0.26793085181.issue40312@roundup.psfhosted.org>


New submission from Allan Feldman <allan.d.feldman at gmail.com>:

Our team is making use of a weakref.WeakValueDictionary() that is accessed through the finalizer of a class. We observed that in Python 3 occasionally values that are directly referenced by an object being finalized were missing from the WeakValueDictionary.


Example:

    import weakref
    cache = weakref.WeakValueDictionary()

    class Foo(object):
        pass


    class Bar(object):
        def __init__(self, foo):
            self.foo = foo
            cache['foo'] = foo

        def __del__(self):
            del cache['foo']

    bar = Bar(Foo())
    del bar


Upon further investigation, we realized that this had to do with the weakref callback within WeakValueDictionary being called (removing the key from the dict) before the finalizer for Foo was called.

Reproduction:

    import gc
    import weakref

    cache = weakref.WeakValueDictionary()


    class Foo(object):
        pass


    class Bar(object):
        def __init__(self, foo):
            # Force a reference cycle to run del only on gc.collect
            self._self = self
            self.foo = foo
            cache["foo"] = foo

        def __del__(self):
            # foo is missing from the cache because the weakref callback has
            # already run. KeyError is raised.
            del cache["foo"]


    bar = Bar(Foo())
    del bar

    gc.collect()


Expected behavior:

The weakref callback should only be called when the object is known to be deleted (after the finalizer runs). Running weakref callbacks before then means that the weakref callback can run on objects being ressurected by the finalizer.

Example:

    import gc
    import weakref


    class ForeverObject(object):
        def __init__(self, circular):
            # Introduce a circular reference so that gc must collect the object
            if circular:
                self._self = self

        def __del__(self):
            global o
            o = self


    def callback(wr):
        print("callback running", wr)


    for circular in (True, False):
        print("------- Circular reference:", circular, "-------")
        o = ForeverObject(circular)
        wr = weakref.ref(o, callback)
        del o
        gc.collect()
        print("--------------")


Note: Python 2.7 appears to have the opposite behavior - weakref callbacks are only invoked when dealloc occurs outside of gc. The Python 2.7 behavior hasn't yet been investigated.


If the expected behavior above is confirmed, I would be happy to submit a patch for this issue!

----------
components: Interpreter Core
messages: 366675
nosy: a-feld
priority: normal
severity: normal
status: open
title: Weakref callbacks running before finalizers in GC collection
type: behavior
versions: Python 2.7, 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/issue40312>
_______________________________________

From report at bugs.python.org  Fri Apr 17 16:58:29 2020
From: report at bugs.python.org (Antony Lee)
Date: Fri, 17 Apr 2020 20:58:29 +0000
Subject: [New-bugs-announce] [issue40313] bytes.hex(sep,
 bytes_per_sep) is many times slower than manually inserting the
 separators
Message-ID: <1587157109.99.0.0253750787201.issue40313@roundup.psfhosted.org>


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

Consider the following example, linewrapping 10^4 bytes in hex form to 128 characters per line, on Py 3.8.2 (Arch Linux repo package):

    In [1]: import numpy as np, math

    In [2]: data = np.random.randint(0, 256, (100, 100), dtype=np.uint8).tobytes()                  

    In [3]: %timeit data.hex("\n", -64)
    123 ?s ? 5.8 ?s per loop (mean ? std. dev. of 7 runs, 10000 loops each)

    In [4]: %timeit h = data.hex(); "\n".join([h[n * 128 : (n+1) * 128] for n in range(math.ceil(len(h) / 128))])
    45.4 ?s ? 746 ns per loop (mean ? std. dev. of 7 runs, 10000 loops each)

    In [5]: h = data.hex(); "\n".join([h[n * 128 : (n+1) * 128] for n in range(math.ceil(len(h) / 128))]) == data.hex("\n", -64)                                                                       
    Out[5]: True

(the last line checks the validity of the code.)

It appears that a naive manual wrap is nearly 3x faster than the builtin functionality.

----------
components: Library (Lib)
messages: 366678
nosy: Antony.Lee
priority: normal
severity: normal
status: open
title: bytes.hex(sep, bytes_per_sep) is many times slower than manually inserting the separators
versions: Python 3.8

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

From report at bugs.python.org  Fri Apr 17 18:35:24 2020
From: report at bugs.python.org (deekay)
Date: Fri, 17 Apr 2020 22:35:24 +0000
Subject: [New-bugs-announce] [issue40314] python code order of magnitude
 faster than equivalent CPython code for simple import statement
Message-ID: <1587162924.52.0.924325577944.issue40314@roundup.psfhosted.org>


New submission from deekay <dee2thekay42 at gmail.com>:

I'm baffled by the performance difference of the following two semantically equivalent(?) programs.

Python:

    #test.py
    import time
    starttime=time.time()
    import tensorflow 
    print(f"Import took: {time.time() - starttime}")

vs C using CPython

    //test.c
    #include <Python.h>
    #include <stdio.h> 
    #include <time.h> 
    int main(int argc, char *argv[])
    {
        Py_Initialize();
        clock_t t = clock();
        PyObject* pModule = PyImport_ImportModule("tensorflow");
        double time_taken = ((double)clock() - t)/CLOCKS_PER_SEC;
        printf("Import took:  %f\n", time_taken);
        return 0;
    }

Now compare the two:

    cl.exe /I"C:\Program Files\Python37\include" test.c
    link test.obj python37.lib /LIBPATH:"C:\Program Files\Python37\libs"
    .\test.exe


> 2020-04-17 13:00:51.598550: W tensorflow/stream_executor/platform/default/dso_loader.cc:55] Could not load dynamic library 'cudart64_100.dll'; dlerror: cudart64_100.dll not found
> 2020-04-17 13:00:51.606296: I tensorflow/stream_executor/cuda/cudart_stub.cc:29] Ignore above cudart dlerror if you do not have a GPU set up on your machine.

> **Import took: 23.160523891448975**


    python test.py


> 2020-04-17 13:01:19.525648: W tensorflow/stream_executor/platform/default/dso_loader.cc:55] Could not load dynamic library 'cudart64_100.dll'; dlerror: cudart64_100.dll not found
> 2020-04-17 13:01:19.530726: I tensorflow/stream_executor/cuda/cudart_stub.cc:29] Ignore above cudart dlerror if you do not have a GPU set up on your machine.

> **Import took: 2.3172824382781982**


Not that it should matter much but my tensorflow version is 1.15
Why is the python VM code so much faster than the compiled CPython code?
Does the python vm add some magic that PyImport_ImportModule doesn't?

----------
components: C API
messages: 366683
nosy: deekay
priority: normal
severity: normal
status: open
title: python code order of magnitude faster than equivalent CPython code for simple import statement
versions: Python 3.7

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

From report at bugs.python.org  Fri Apr 17 23:37:01 2020
From: report at bugs.python.org (Skip Montanaro)
Date: Sat, 18 Apr 2020 03:37:01 +0000
Subject: [New-bugs-announce] [issue40315] Incorrect stacksize in code object
Message-ID: <1587181021.08.0.62849723006.issue40315@roundup.psfhosted.org>


New submission from Skip Montanaro <skip.montanaro at gmail.com>:

Consider this trivial function:

>>> def f():
... ? while True:
... ? ? pass
...

and its disassembly:

>>> dis.dis(f)
? 3 ? ? >> ? ?0 JUMP_ABSOLUTE ? ? ? ? ? ? ? 0
? ? ? ? ? ? ? 2 LOAD_CONST ? ? ? ? ? ? ? ? ?0 (None)
? ? ? ? ? ? ? 4 RETURN_VALUE

Despite its infinite-loop-ness, the generated LOAD_CONST/RETURN_VALUE pair suggests the code object's stacksize should be 1, but it's 0:

>>> print(f.__code__.co_stacksize)
0

I understand that the compiler might have decided the code was unreachable and the LOAD_CONST instruction would never be reached, but if that was the case, why would that instruction pair be generated?

This is only of interest because my register virtual machine translator trusts that the co_nlocals and co_stacksize attributes of the code object reflect the actual space allocation in the frame object. I can use

max(1, f.__code__.co_stacksize + f.__code__.co_nlocals)

as the allocated locals+stack space. (That first slot in the frame object will always be available.) That makes this example translate, but doesn't guarantee there's not a bug in determination of the stack size which could pop up again later.

----------
components: Interpreter Core
messages: 366692
nosy: skip.montanaro
priority: normal
severity: normal
status: open
title: Incorrect stacksize in code object
type: compile error
versions: Python 3.9

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

From report at bugs.python.org  Sat Apr 18 05:37:15 2020
From: report at bugs.python.org (Or Toledano)
Date: Sat, 18 Apr 2020 09:37:15 +0000
Subject: [New-bugs-announce] [issue40316] Add zero function to time, datetime,
 which acts as the use case of replace to limit resolution
Message-ID: <1587202635.96.0.0810977655343.issue40316@roundup.psfhosted.org>


New submission from Or Toledano <ortoledano at protonmail.com>:

I propose the zero(time_unit) function, which replaces all time units with greater equal resolution than time_unit by 0.
E.g. 
>>> datetime.datetime(2020, 4, 18, 12, 27, 30, 500).zero("second")
datetime.datetime(2020, 4, 18, 12, 27)
I purpose it for the datetime, time classes.
I also added unit tests for the function in those classes.
GitHub PR:

----------
components: Library (Lib)
messages: 366696
nosy: Or Toledano, belopolsky, lemburg, p-ganssle
priority: normal
severity: normal
status: open
title: Add zero function to time, datetime, which acts as the use case of replace to limit resolution
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Sat Apr 18 07:50:37 2020
From: report at bugs.python.org (=?utf-8?q?Grzegorz_Kraso=C5=84?=)
Date: Sat, 18 Apr 2020 11:50:37 +0000
Subject: [New-bugs-announce] [issue40317] inspect.getsource() examines
 incorrect target
Message-ID: <1587210637.54.0.0432450975105.issue40317@roundup.psfhosted.org>


New submission from Grzegorz Kraso? <grzegorz.krason at gmail.com>:

Based on the attached example:

Expected output:
```
123
    class Number:
        payload = 123

321
    class Number:
        payload = 321
```

Actual output:
```
123
    class Number:
        payload = 123

321
    class Number:
        payload = 123
```

Reproduced using:

* Python 2.7.17
* Python 3.7.7
* Python 3.8.2

----------
components: Library (Lib)
files: demo.py
messages: 366701
nosy: Grzegorz Kraso?
priority: normal
severity: normal
status: open
title: inspect.getsource() examines incorrect target
type: behavior
versions: Python 2.7, Python 3.7, Python 3.8
Added file: https://bugs.python.org/file49072/demo.py

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

From report at bugs.python.org  Sat Apr 18 07:56:10 2020
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Sat, 18 Apr 2020 11:56:10 +0000
Subject: [New-bugs-announce] [issue40318] Migrate to SQLite3 trace v2 API
Message-ID: <1587210970.59.0.35117859461.issue40318@roundup.psfhosted.org>


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

Currently, we're using the sqlite3_trace() for tracing statements. This API was been superseded by sqlite3_trace_v2() in SQLite3 v3.14 back in August 2016. Proposing to migrate to the new API, which allows more fine grained control over what to trace, and also opens up the door to stuff like prepared statement status variables.

See https://sqlite.org/c3ref/trace_v2.html, https://sqlite.org/c3ref/c_trace.html, https://sqlite.org/c3ref/c_stmtstatus_counter.html, and https://sqlite.org/c3ref/experimental.html.

Attached patch (against master) uses the new API if available. Make test completes without failures.

----------
components: Library (Lib)
files: 0002-Use-new-sqlite3_trace_v2-API-if-possible.patch
keywords: patch
messages: 366702
nosy: erlendaasland
priority: normal
severity: normal
status: open
title: Migrate to SQLite3 trace v2 API
versions: Python 3.8, Python 3.9
Added file: https://bugs.python.org/file49073/0002-Use-new-sqlite3_trace_v2-API-if-possible.patch

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

From report at bugs.python.org  Sat Apr 18 07:57:55 2020
From: report at bugs.python.org (AL3X_69)
Date: Sat, 18 Apr 2020 11:57:55 +0000
Subject: [New-bugs-announce] [issue40319] dict.update() return the updated
 dict instead of None
Message-ID: <1587211075.61.0.291186837344.issue40319@roundup.psfhosted.org>


New submission from AL3X_69 <alex69.minecraft at gmail.com>:

When a dict is updated with update(), instead of return None, it will return the updated dict.

example: 

>>> a = {"test": 1}
>>> b = {"type": 2}
>>> c = a.update(b)
>>> print(c)
{"test": 1, "type": 1}

----------
messages: 366703
nosy: AL3X_69
priority: normal
severity: normal
status: open
title: dict.update() return the updated dict instead of None
type: enhancement
versions: Python 3.8

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

From report at bugs.python.org  Sat Apr 18 11:28:07 2020
From: report at bugs.python.org (Jeff Laughlin)
Date: Sat, 18 Apr 2020 15:28:07 +0000
Subject: [New-bugs-announce] [issue40320] Add ability to specify instance of
 contextvars context to Task() & asyncio.create_task()
Message-ID: <1587223687.72.0.427454005421.issue40320@roundup.psfhosted.org>


New submission from Jeff Laughlin <jeff.laughlin at gmail.com>:

As a test engineer I want to be able to run async test fixtures and test cases in different async tasks with the same Context. Not a copy; the same specific instance of contextvars.Context().

I do NOT want the task to run in a COPY of the context because I want mutations to the context to be preserved so that I can pass the mutated context into another async task.

I do NOT want the task to inherit the potentially polluted global context.

class Task currently unconditionally copies the current global context and has no facility for the user to override the context.

Therefor I propose adding a context argument to the Task constructor and to create_task()

It should be noted that this argument should not be used for "normal" development and only for "weird" stuff like test frameworks.

I should also note that Context().run() is not useful here because it is not async and there is no obvious existing async equivalent. This proposal would be roughly equivalent.

I should also note that a hack like copying the items from one context to another will not work because it breaks ContextVar set/reset. I tried this. It was a heroic failure. It must be possible to run a task with an exist instance of context and not a copy.

Here is a real-world use case: https://github.com/pytest-dev/pytest-asyncio/pull/153/files

Here is the hacked Task constructor I cooked up:

class Task(asyncio.tasks._PyTask):
    def __init__(self, coro, *, loop=None, name=None, context=None):
...
        self._context = context if context is not None else copy_context()

        self._loop.call_soon(self.__step, context=self._context)
        asyncio._register_task(self) 


if folks are on board I can do a PR

----------
components: asyncio
messages: 366722
nosy: Jeff.Laughlin, asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: Add ability to specify instance of contextvars context to Task() & asyncio.create_task()
type: enhancement
versions: Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Sat Apr 18 13:47:38 2020
From: report at bugs.python.org (Jochem Schulenklopper)
Date: Sat, 18 Apr 2020 17:47:38 +0000
Subject: [New-bugs-announce] [issue40321] urllib.request does not support
 HTTP response status code 308
Message-ID: <1587232058.85.0.573866772263.issue40321@roundup.psfhosted.org>


New submission from Jochem Schulenklopper <j.schulenklopper at gmail.com>:

urllib.request does not yet support HTTP response status code 308, as defined in IETF RFC 7538, https://tools.ietf.org/html/rfc7538.

308 (permanent redirect) is the 307-variant (temporary redirect) of 301 (moved permanently).

----------
components: Library (Lib)
messages: 366729
nosy: Jochem Schulenklopper
priority: normal
severity: normal
status: open
title: urllib.request does not support HTTP response status code 308
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/issue40321>
_______________________________________

From report at bugs.python.org  Sat Apr 18 14:49:39 2020
From: report at bugs.python.org (Robert Bressan)
Date: Sat, 18 Apr 2020 18:49:39 +0000
Subject: [New-bugs-announce] [issue40322] struct.pack adding unexpected byte
 in 'B' format
Message-ID: <1587235779.35.0.377995541073.issue40322@roundup.psfhosted.org>


New submission from Robert Bressan <robert.bressan at gmail.com>:

struct.pack() is adding an unexpected null byte.

When I've run this code:
___________________________________________
import struct
d = {'c':b'a', 'b':1, 'B':1, '?':False, 'h':2, 'H':2, 'i':-3, 'I':3, 'l':4, 'L':4, 'q':5, 'Q':5, 'f':100.0, 'd':2.0}

for x in d:
    y = struct.pack(x,d[x])
    print('len('+x+') = ' + str(len(y)) + ': ' + str(y))

x = struct.pack('fBHL', 100, 1, 2,4)
print('len(fBHL) = ' + str(len(x)) + ': ' +  str(x))
???????????????????????????????????????????

I got this return:
___________________________________________
len(c) = 1: b'a'
len(b) = 1: b'\x01'
len(B) = 1: b'\x01'
len(?) = 1: b'\x00'
len(h) = 2: b'\x02\x00'
len(H) = 2: b'\x02\x00'
len(i) = 4: b'\xfd\xff\xff\xff'
len(I) = 4: b'\x03\x00\x00\x00'
len(l) = 4: b'\x04\x00\x00\x00'
len(L) = 4: b'\x04\x00\x00\x00'
len(q) = 8: b'\x05\x00\x00\x00\x00\x00\x00\x00'
len(Q) = 8: b'\x05\x00\x00\x00\x00\x00\x00\x00'
len(f) = 4: b'\x00\x00\xc8B'
len(d) = 8: b'\x00\x00\x00\x00\x00\x00\x00@'
len(fBHL) = 12: b'\x00\x00\xc8B\x01\x00\x02\x00\x04\x00\x00\x00'
???????????????????????????????????????????
I believe the last line pack ("fBHL") consumes 11 bytes (4+1+2+4), and analysing the bytearray, the B is packing 2 bytes, instead of one. My expected result was:
___________________________________________
len(fBHL) = 11: b'\x00\x00\xc8B\x01\x02\x00\x04\x00\x00\x00'
???????????????????????????????????????????

----------
components: Interpreter Core
messages: 366734
nosy: Robert Bressan
priority: normal
severity: normal
status: open
title: struct.pack adding unexpected byte in 'B' format
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Sat Apr 18 15:21:03 2020
From: report at bugs.python.org (Vishnuvenkatesh Dhage)
Date: Sat, 18 Apr 2020 19:21:03 +0000
Subject: [New-bugs-announce] [issue40323] Printing of Single (') and Double
 (") code in one sentence using escape Code
Message-ID: <1587237663.06.0.425937353103.issue40323@roundup.psfhosted.org>


New submission from Vishnuvenkatesh Dhage <vmdhage at gmail.com>:

In Python shell v3.8.2,

when user want to use both single quotation mark and double quotation mark in one sentence/paragraph then Single Quotation is displayed in the screen along with escape code i.e. \', but double quotation display ok i.e. ".

example:
>>>'\"Python\" programming language is very easy. It\'s used for developing rapid application development.'



The result is printed is as below
>>>'"Python" programming language is very easy. It\'s used for developing rapid application development.'

In my view, after pressing enter the output should be 
>>>'"Python" programming language is very easy. It's used for developing rapid application development.'
 
Please look into my observation.
Thanks with regards
Vishnuvenkatesh Dhage
encls: Python v3.8.2 Shell screenshot along with example

----------
components: IO
files: Single and Double Quotatin using escape code.jpg
messages: 366736
nosy: benjamin.peterson, vmdhage
priority: normal
severity: normal
status: open
title: Printing of Single (') and Double (") code in one sentence using escape Code
type: behavior
versions: Python 3.8
Added file: https://bugs.python.org/file49074/Single and Double Quotatin using escape code.jpg

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

From report at bugs.python.org  Sat Apr 18 15:44:22 2020
From: report at bugs.python.org (krishan danushka)
Date: Sat, 18 Apr 2020 19:44:22 +0000
Subject: [New-bugs-announce] [issue40324] python 3.8.2 idle not opening
Message-ID: <1587239062.2.0.770603015348.issue40324@roundup.psfhosted.org>


New submission from krishan danushka <krishandanushka536 at gmail.com>:

i downloaded python 3.8.2 version.but idle is not opening.i trying serveral time by reinstall but it doesn't working.

----------
assignee: terry.reedy
components: IDLE
messages: 366738
nosy: krishandanushka536 at gmail.com, terry.reedy
priority: normal
severity: normal
status: open
title: python 3.8.2 idle not opening
type: performance
versions: Python 3.8

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

From report at bugs.python.org  Sat Apr 18 17:25:19 2020
From: report at bugs.python.org (Yuval S)
Date: Sat, 18 Apr 2020 21:25:19 +0000
Subject: [New-bugs-announce] [issue40325] Random.seed does not affect string
 hash randomization leading to non-intuitive results
Message-ID: <1587245119.63.0.0763742728572.issue40325@roundup.psfhosted.org>


New submission from Yuval S <sadan.yuval at gmail.com>:

The following code gives different results on each run, even though "``random.seed()``" is used:

>>> import random
>>> random.seed(6)
>>> x = set(str(i) for i in range(500))
>>> print(random.sample(x, 1))

presumably because of string hash randomization (see also #27706),
unless "``PYTHONHASHSEED``" is set. 

However, this is non-intuitive, especially as this random aspect of Python is not mentioned in `Notes on Reproducability <https://docs.python.org/3/library/random.html#notes-on-reproducibility>`_.

I would suggest this is either fixed (using the provided seed for string hash randomization as well) or documented.

----------
assignee: docs at python
components: Documentation, Library (Lib)
files: test.py
messages: 366741
nosy: Yuval S, docs at python
priority: normal
severity: normal
status: open
title: Random.seed does not affect string hash randomization leading to non-intuitive results
versions: Python 3.7, Python 3.8
Added file: https://bugs.python.org/file49075/test.py

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

From report at bugs.python.org  Sun Apr 19 03:14:17 2020
From: report at bugs.python.org (Ronie Martinez)
Date: Sun, 19 Apr 2020 07:14:17 +0000
Subject: [New-bugs-announce] [issue40326] A string contains an empty string?
Message-ID: <1587280457.85.0.869206136308.issue40326@roundup.psfhosted.org>


New submission from Ronie Martinez <ronmarti18 at gmail.com>:

Testing if an empty string is in a given string returns True. Tried only on Python 3.7 but might exists on other versions.

Python 3.7.6 (default, Mar 13 2020, 18:48:35) 
[Clang 11.0.0 (clang-1100.0.33.17)] on darwin

```
>> "" in "hello"
True
```

----------
components: Interpreter Core
messages: 366757
nosy: roniemartinez
priority: normal
severity: normal
status: open
title: A string contains an empty string?
type: behavior
versions: Python 3.7

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

From report at bugs.python.org  Sun Apr 19 04:24:06 2020
From: report at bugs.python.org (Markus Mohrhard)
Date: Sun, 19 Apr 2020 08:24:06 +0000
Subject: [New-bugs-announce] [issue40327] list(sys.modules.items()) can
 throw RuntimeError: dictionary changed size during iteration
Message-ID: <1587284646.11.0.468516211586.issue40327@roundup.psfhosted.org>


New submission from Markus Mohrhard <markusm at dug.com>:

We have hit an issue in the pickle module where the code throws an exception in a threaded environment:

The interesting piece of the backtrace is:

  File "/xxx/1004060/lib/python3.7/site-packages/numpy/core/__init__.py", line 130, in _ufunc_reduce
    return _ufunc_reconstruct, (whichmodule(func, name), name)
  File "/xxx/lib/python3.7/pickle.py", line 309, in whichmodule
    for module_name, module in list(sys.modules.items()):
RuntimeError: dictionary changed size during iteration

I tried to find a code path that would explain how the dict could be changed while the list is created but have not been able to find a code path that releases the GIL.

The executable is using many threads with imports happening in random threads and a custom class loader but we already make sure that the class loader is always holding the GIL.

The issue happens quite rarely (maybe once every one thousand's execution) so I don't have a reproducer right now.

----------
components: Extension Modules
messages: 366762
nosy: Markus Mohrhard
priority: normal
severity: normal
status: open
title: list(sys.modules.items()) can throw RuntimeError: dictionary changed size during iteration
type: behavior
versions: Python 3.7

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

From report at bugs.python.org  Sun Apr 19 09:13:59 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Sun, 19 Apr 2020 13:13:59 +0000
Subject: [New-bugs-announce] [issue40328] Add tools for generating
 mappings_XX.h
Message-ID: <1587302039.42.0.928310034054.issue40328@roundup.psfhosted.org>


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

AFAIK, there are no tools for generating mappings_XX.h under Modules/cjkcodecs.

It would cause a maintainable issue,
fortunately, I got the old source from https://github.com/BackupTheBerlios/cjkpython.
And I success to port into Python3 version and successfully reproduce to generating header file except for mappings_hk.h mappings_tw.h.

The patch will include a generator and Unicode mapping file.
I am not the codec expert but hopefully it will help us.

----------
messages: 366777
nosy: corona10, inada.naoki, vstinner
priority: normal
severity: normal
status: open
title: Add tools for generating mappings_XX.h

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

From report at bugs.python.org  Sun Apr 19 10:39:04 2020
From: report at bugs.python.org (Tomas Nordin)
Date: Sun, 19 Apr 2020 14:39:04 +0000
Subject: [New-bugs-announce] [issue40329] Faulty dict arg gives ValueError
 but mostly TypeError
Message-ID: <1587307144.84.0.271412864136.issue40329@roundup.psfhosted.org>


New submission from Tomas Nordin <tomasn at kth.se>:

Hello Python bug tracker

Trying to create a dict with a top level set pair will fail, but how
will it fail?

Here comes a terminal session to reproduce the behavior. The same
command is just repeated.

----------------------------------8<----------------------------------
$ python3 -c 'd = dict({1, "one"})'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
TypeError: cannot convert dictionary update sequence element #0 to a sequence

# Understand, can't convert 1 to sequence.

$ python3 -c 'd = dict({1, "one"})'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ValueError: dictionary update sequence element #0 has length 3; 2 is required

# Not so helpful to me, don't understand.

$ python3 -c 'd = dict({1, "one"})'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
TypeError: cannot convert dictionary update sequence element #0 to a sequence

# OK, thanks

$ python3 -c 'd = dict({1, "one"})'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
TypeError: cannot convert dictionary update sequence element #0 to a sequence

$ python3 -c 'd = dict({1, "one"})'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
TypeError: cannot convert dictionary update sequence element #0 to a sequence

$ python3 -c 'd = dict({1, "one"})'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ValueError: dictionary update sequence element #0 has length 3; 2 is required

# Again?
---------------------------------->8----------------------------------

I searched the bug tracker on "dict typeerror valueerror" but couldn't
find something similar. What do you think about this?

$ python3 --version
Python 3.7.3

Best regards
--
Tomas

----------
components: Library (Lib)
messages: 366781
nosy: tomnor
priority: normal
severity: normal
status: open
title: Faulty dict arg gives ValueError but mostly TypeError
type: behavior
versions: Python 3.7

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

From report at bugs.python.org  Sun Apr 19 10:46:48 2020
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 19 Apr 2020 14:46:48 +0000
Subject: [New-bugs-announce] [issue40330] ShareableList size guard incorrect
 for str data
Message-ID: <1587307608.02.0.363031501355.issue40330@roundup.psfhosted.org>


Change by Antoine Pitrou <solipsis at pitrou.net>:


----------
assignee: pitrou
components: Library (Lib)
nosy: pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: ShareableList size guard incorrect for str data
type: behavior
versions: Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Sun Apr 19 12:24:48 2020
From: report at bugs.python.org (Tzanetos Balitsaris)
Date: Sun, 19 Apr 2020 16:24:48 +0000
Subject: [New-bugs-announce] [issue40331] Increase test coverage for the
 statistics module
Message-ID: <1587313488.32.0.170257726917.issue40331@roundup.psfhosted.org>


New submission from Tzanetos Balitsaris <tbalitsaris at gmail.com>:

The statistics module is already highly tested but it seems that there are 4 statements [0] that are not executed by the equivalent unit tests. Specifically, 3 statements which are part of the `_convert`, `_find_lteq`, and `_find_rteq` functions, and 1 statement of the `harmonic_mean` function.

[0] https://codecov.io/gh/python/cpython/src/8aea4b3605059e243f1827d9328d6fc8d698c0a7/Lib/statistics.py

----------
components: Tests
messages: 366788
nosy: tzabal
priority: normal
severity: normal
status: open
title: Increase test coverage for the statistics module
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Sun Apr 19 16:01:23 2020
From: report at bugs.python.org (Brandon)
Date: Sun, 19 Apr 2020 20:01:23 +0000
Subject: [New-bugs-announce] [issue40332] RegEx for numbers in documentation
 (easy fix - solution provided)
Message-ID: <1587326483.24.0.84255521064.issue40332@roundup.psfhosted.org>


New submission from Brandon <ymbmg777 at gmail.com>:

The regular expression used for matching numbers in the documentation for the regular expressions module (the tokenizer section) doesn't match the string ".5", but does match the string "3.".

Here's a link to the tokenizer section of the documentation: https://docs.python.org/3/library/re.html#writing-a-tokenizer

The tokenizer example uses r'\d+(\.\d*)?' for matching numbers. I would personally match ".5" as a number before I would match "3." as a number. In order to do this, I would use r'(\d*\.)?\d+' instead of r'\d+(\.\d*)?'. Python 3's interpreter matches both "3." and ".5" as numbers when interpreting code, so you could use a different regex example for matching both if you wanted to be consistent with Python's own interpreter.

----------
components: Regular Expressions
messages: 366801
nosy: TheBrandonGuy, ezio.melotti, mrabarnett
priority: normal
severity: normal
status: open
title: RegEx for numbers in documentation (easy fix - solution provided)
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/issue40332>
_______________________________________

From report at bugs.python.org  Sun Apr 19 16:10:33 2020
From: report at bugs.python.org (Gregory Szorc)
Date: Sun, 19 Apr 2020 20:10:33 +0000
Subject: [New-bugs-announce] [issue40333] Request for multi-phase
 initialization API to run code after importlib init
Message-ID: <1587327033.84.0.66503294203.issue40333@roundup.psfhosted.org>


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

I'm porting PyOxidizer to the PEP 587 APIs. So far, it is mostly straightforward.

I was looking forward to adopting the multi-phase initialization API because I thought it would enable me to get rid of the very ugly hack PyOxidizer uses to inject its custom meta path importer. This hack is described in gory detail at https://docs.rs/pyembed/0.7.0/pyembed/technotes/index.html#our-importing-mechanism and the tl;dr is we use a modified version of the `importlib._bootstrap_external` module to configure a builtin extension module on sys.meta_path so it can handle all imports during initialization.

The good news is the multi-phase initialization API gives us an injection point between "core" and "main." I _think_ I would be able to import the built-in extension here and register it on sys.meta_path.

However, the new multi-phase initialization API doesn't give us the total control that we need. Specifically, PyOxidizer's importer is leveraging a few functions in importlib._bootstrap_external as part of its operation. So it needs this module to be available before it can be loaded and installed on sys.meta_path. It also wants total control over sys.meta_path. So we don't want importlib._bootstrap_external to be mucking with sys.meta_path and imports being performed before PyOxidizer has a chance to readjust state.

The critical feature that PyOxidizer needs is the ability to muck with sys.meta_path and importlib *after* importlib externals are initialized and *before* any non-builtin, non-frozen import is attempted. In the current state of the initialization code, we need to run custom code between init_importlib_external() and when the first non-builtin, non-frozen import is attempted (currently during _PyUnicode_InitEncodings()).

Would it be possible to get a multi-phase initialization API that stops after init_importlib_external()?

If not, could we break up PyConfig._install_importlib into 2 pieces to allow disabling of just importlib._bootstrap_external and provide a supported mechanism to initialize the external mechanism between "core" and "main" initialization? (Although I'm not sure if this is possible, since "main" finishes initializing aspects of "sys" before init_importlib_external() and I'm not sure if it is safe to initialize importlib externals before this is done. I'm guessing there is a reason that code runs before importlib is fully initialized.)

I suppose I could change PyOxidizer's functionality a bit to work around the lack of an importlib._bootstrap_external module between "core" and "main" initialization. I'm pretty sure I could make this work. But my strong preference is to inject code after importlib external support is fully initialized but before any imports are performed with it.

Overall the PEP 587 APIs are terrific and a substantial improvement over what came before. Thank you for all your work on this feature, Victor!

----------
components: C API
messages: 366802
nosy: indygreg, vstinner
priority: normal
severity: normal
status: open
title: Request for multi-phase initialization API to run code after importlib init
versions: Python 3.8, Python 3.9

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

From report at bugs.python.org  Sun Apr 19 16:16:17 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 19 Apr 2020 20:16:17 +0000
Subject: [New-bugs-announce] [issue40334] PEP 617: new PEG-based parser
Message-ID: <1587327377.33.0.614039250584.issue40334@roundup.psfhosted.org>


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

Note: PEP 617 is currently under review by the Steering Council, but if they approve we'd like to get it into alpha 6, and reviews are welcome (even though we're still finagling some corner cases of the implementation).

----------
messages: 366803
nosy: gvanrossum, pablogsal
priority: normal
severity: normal
status: open
title: PEP 617: new PEG-based parser
versions: Python 3.9

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

From report at bugs.python.org  Sun Apr 19 17:40:55 2020
From: report at bugs.python.org (Anthony Sottile)
Date: Sun, 19 Apr 2020 21:40:55 +0000
Subject: [New-bugs-announce] [issue40335] Regression in multiline
 SyntaxError offsets
Message-ID: <1587332455.2.0.964330224308.issue40335@roundup.psfhosted.org>


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

this was noticed in pyflakes's testsuite: https://github.com/PyCQA/pyflakes/pull/532#pullrequestreview-396059622

I've created a small script to reproduce the problem

```
import sys

SRC = b"""\
def foo():
    '''

def bar():
    pass

def baz():
    '''quux'''
"""

try:
    exec(SRC)
except SyntaxError as e:
    print(
        f'{sys.version}\n\n'
        f'{type(e).__name__}:\n'
        f'- line: {e.lineno}\n'
        f'- offset: {e.offset}\n'
        f'- text: {e.text!r}\n'
    )
```

This was "fixed" in python3.8, but has regressed:

```
$ python3.6 t2.py
3.6.9 (default, Nov  7 2019, 10:44:02) 
[GCC 8.3.0]

SyntaxError:
- line: 8
- offset: 52
- text: "    '''\n\ndef bar():\n    pass\n\ndef baz():\n    '''quux'''\n"

$ python3.8 t2.py
3.8.2 (default, Feb 26 2020, 02:56:10) 
[GCC 7.4.0]

SyntaxError:
- line: 8
- offset: 8
- text: "    '''\n\ndef bar():\n    pass\n\ndef baz():\n    '''quux'''\n"

$ ./python t2.py
3.9.0a5+ (heads/master:3955da8568, Apr 19 2020, 14:29:48) 
[GCC 7.5.0]

SyntaxError:
- line: 8
- offset: 52
- text: "    '''\n\ndef bar():\n    pass\n\ndef baz():\n    '''quux'''\n"

```

----------
components: Interpreter Core
messages: 366805
nosy: Anthony Sottile
priority: normal
severity: normal
status: open
title: Regression in multiline SyntaxError offsets
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Mon Apr 20 07:27:57 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 20 Apr 2020 11:27:57 +0000
Subject: [New-bugs-announce] [issue40336] Refactor typing._SpecialForm
Message-ID: <1587382077.76.0.465264579833.issue40336@roundup.psfhosted.org>


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

The proposed PR refactors the implementation of typing._SpecialForm.

Different special forms are different by name, docstring, and the behavior of __getitem__. Instead of special casing by name in __getitem__, instances are now parametrized by the implementation of __getitem__. _SpecialForm is now used as a decorator and takes the name and the docstring from the decorated function. It looks nicer to me now.

Also removed implementations of some methods:

* Inheriting from _Immutable no longer needed because __reduce__ makes instance atomic for copying.

* __new__ was only needed when _SpecialForm was a subclass of type. It prevented using it as a metaclass. Now it is no longer needed.

* Docstring is now assigned directly to the __doc__ slot. Previously it conflicted with the class docstring, but now the class docstring was converted into the class comment. _SpecialForm is not a public class, and pydoc shows the class comment if there is no a class docstring.

* __eq__ and __hash__ are no longer needed. Instances are singletons, and comparing by identity works as well as comparing by name. They could be needed before implementing __reduce__().

* __call__ no longer needed. Instances are not callable, and the error message is good enough. The bonus -- callable() now returns False.

----------
components: Library (Lib)
messages: 366817
nosy: gvanrossum, levkivskyi, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Refactor typing._SpecialForm
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Mon Apr 20 10:00:55 2020
From: report at bugs.python.org (shawn)
Date: Mon, 20 Apr 2020 14:00:55 +0000
Subject: [New-bugs-announce] [issue40337] builtins.RuntimeError: Caught
 RuntimeError in pin memory thread for device 0.
Message-ID: <1587391255.49.0.649010801229.issue40337@roundup.psfhosted.org>


New submission from shawn <shawnxiang at yeah.net>:

? File "D:\yolov3\train.py", line 430, in <module>
  train() # train normally
? File "D:\yolov3\train.py", line 236, in train
  for i, (imgs, targets, paths, _) in pbar: # batch -------------------------------------------------------------
File "D:\Programs\Python\Python38\Lib\site-packages\tqdm\std.py", line 1127, in __iter__
  for obj in iterable:
File "D:\Programs\Python\Python38\Lib\site-packages\torch\utils\data\dataloader.py", line 345, in __next__
  data = self._next_data()
File "D:\Programs\Python\Python38\Lib\site-packages\torch\utils\data\dataloader.py", line 856, in _next_data
  return self._process_data(data)
File "D:\Programs\Python\Python38\Lib\site-packages\torch\utils\data\dataloader.py", line 881, in _process_data
  data.reraise()
File "D:\Programs\Python\Python38\Lib\site-packages\torch\_utils.py", line 394, in reraise
  raise self.exc_type(msg)

builtins.RuntimeError: Caught RuntimeError in pin memory thread for device 0.
Original Traceback (most recent call last):
File "D:\Programs\Python\Python38\lib\site-packages\torch\utils\data\_utils\pin_memory.py", line 31, in _pin_memory_loop
data = pin_memory(data)
File "D:\Programs\Python\Python38\lib\site-packages\torch\utils\data\_utils\pin_memory.py", line 55, in pin_memory
return [pin_memory(sample) for sample in data]
File "D:\Programs\Python\Python38\lib\site-packages\torch\utils\data\_utils\pin_memory.py", line 55, in <listcomp>
return [pin_memory(sample) for sample in data]
File "D:\Programs\Python\Python38\lib\site-packages\torch\utils\data\_utils\pin_memory.py", line 47, in pin_memory
return data.pin_memory()
 ... (truncated)

----------
messages: 366829
nosy: shawn
priority: normal
severity: normal
status: open
title: builtins.RuntimeError: Caught RuntimeError in pin memory thread for device 0.
versions: Python 3.8

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

From report at bugs.python.org  Mon Apr 20 10:43:38 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 20 Apr 2020 14:43:38 +0000
Subject: [New-bugs-announce] [issue40338] [Security] urllib and anti-slash
 (\) in the hostname
Message-ID: <1587393818.69.0.0669874545699.issue40338@roundup.psfhosted.org>


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

David Sch?tz reported the following urllib vulnerability to the PSRT at 2020-03-29.

He wrote an article about a similar vulnerability in Closure (Javascript):
https://bugs.xdavidhu.me/google/2020/03/08/the-unexpected-google-wide-domain-check-bypass/

David was able to bypass a wildcard domain check in Closure by using the "\" character in the URL like this:

  https://xdavidhu.me\test.corp.google.com

Example in Python:

>>> from urllib.parse import urlparse
>>> urlparse("https://xdavidhu.me\\test.corp.google.com")
ParseResult(scheme='https', netloc='xdavidhu.me\\test.corp.google.com', path='', params='', query='', fragment='')

urlparse() currently accepts "\" in the netloc.

This could present issues if server-side checks are used by applications to validate a URLs authority.

The problem emerges from the fact that the RFC and the WHATWG specifications differ, and the RFC does not mention the "\":

* RFC: https://tools.ietf.org/html/rfc3986#appendix-B
* WHATWG: https://url.spec.whatwg.org/#relative-state

This specification difference might cause issues, since David do understand that the parser is implemented by the RFC, but the WHATWG spec is what the browsers are using, who will mainly be the ones opening the URL.

----------
components: Library (Lib)
messages: 366832
nosy: vstinner
priority: normal
severity: normal
status: open
title: [Security] urllib and anti-slash (\) in the hostname
type: security
versions: Python 3.9

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

From report at bugs.python.org  Mon Apr 20 13:48:49 2020
From: report at bugs.python.org (M T)
Date: Mon, 20 Apr 2020 17:48:49 +0000
Subject: [New-bugs-announce] [issue40339] Instead of skipping,
 IPV6 test(s) fail on a non-IPV6 machine
Message-ID: <1587404929.24.0.675615215393.issue40339@roundup.psfhosted.org>


New submission from M T <mi+python-2020 at aldan.algebra.com>:

I have no use for IPv6 and, when recompiling my OS, disable the feature completely. Python compiles nicely despite of this, but the IPv6-related tests fail instead of being skipped:

ERROR: test_create_server_ipv6 (test.test_asyncio.test_base_events.BaseEventLoopWithSelectorTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/spare/usr/ports/lang/python36/work/Python-3.6.10/Lib/test/test_asyncio/test_base_events.py", line 1149, in test_create_server_ipv6
    self.loop.run_until_complete(main())
  File "/spare/usr/ports/lang/python36/work/Python-3.6.10/Lib/asyncio/base_events.py", line 488, in run_until_complete
    return future.result()
  File "/spare/usr/ports/lang/python36/work/Python-3.6.10/Lib/asyncio/coroutines.py", line 129, in throw
    return self.gen.throw(type, value, traceback)
  File "/spare/usr/ports/lang/python36/work/Python-3.6.10/Lib/test/test_asyncio/test_base_events.py", line 1141, in main
    lambda: None, '::1', 0, loop=self.loop)
  File "/spare/usr/ports/lang/python36/work/Python-3.6.10/Lib/asyncio/streams.py", line 119, in start_server
    return (yield from loop.create_server(factory, host, port, **kwds))
  File "/spare/usr/ports/lang/python36/work/Python-3.6.10/Lib/asyncio/base_events.py", line 1041, in create_server
    infos = yield from tasks.gather(*fs, loop=self)
  File "/spare/usr/ports/lang/python36/work/Python-3.6.10/Lib/asyncio/base_events.py", line 990, in _create_server_getaddrinfo
    flags=flags, loop=self)
  File "/spare/usr/ports/lang/python36/work/Python-3.6.10/Lib/concurrent/futures/thread.py", line 56, in run
    result = self.fn(*self.args, **self.kwargs)
  File "/spare/usr/ports/lang/python36/work/Python-3.6.10/Lib/socket.py", line 745, in getaddrinfo
    for res in _socket.getaddrinfo(host, port, family, type, proto, flags):
socket.gaierror: [Errno 8] hostname nor servname provided, or not known

======================================================================
FAIL: test_ipaddr_info (test.test_asyncio.test_base_events.BaseEventTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/spare/usr/ports/lang/python36/work/Python-3.6.10/Lib/test/test_asyncio/test_base_events.py", line 104, in test_ipaddr_info
    base_events._ipaddr_info('::3', 1, INET6, STREAM, TCP))
AssertionError: (<AddressFamily.AF_INET6: 28>, <SocketKin[38 chars], 0)) != None

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

Ran 1549 tests in 36.401s

FAILED (failures=1, errors=3, skipped=7)
test test_asyncio failed

----------
components: Tests
files: config.log
messages: 366858
nosy: UnitedMarsupials
priority: normal
severity: normal
status: open
title: Instead of skipping, IPV6 test(s) fail on a non-IPV6 machine
versions: Python 3.6
Added file: https://bugs.python.org/file49077/config.log

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

From report at bugs.python.org  Mon Apr 20 15:37:45 2020
From: report at bugs.python.org (Dominik V.)
Date: Mon, 20 Apr 2020 19:37:45 +0000
Subject: [New-bugs-announce] [issue40340] Programming FAQ about "How do I
 convert a string to a number?" contains a typo
Message-ID: <1587411465.5.0.0585658579804.issue40340@roundup.psfhosted.org>


New submission from Dominik V. <dominik.vilsmeier1123 at gmail.com>:

The paragraph about [How do I convert a string to a number?](https://docs.python.org/3/faq/programming.html#how-do-i-convert-a-string-to-a-number) contains the following sentence:

> By default, these interpret the number as decimal, so that `int('0144') == 144` and `int('0x144')` raises ValueError.

The first part however doesn't raise an error. Most likely octal notation was meant, i.e. `int('0o144') == 144`.

For consistency with the `int('0x144')` part one could also omit the equality comparison, i.e. just write `int('0o144')`.

In order to emphasize that the "and" is not part of the code (though this should be displayed by the browser) once could also write:

> [...] so that _both_ `int('0o144')` and `int('0x144')` raise ValueError.

(emphasis added)

----------
assignee: docs at python
components: Documentation
messages: 366870
nosy: Dominik V., docs at python
priority: normal
severity: normal
status: open
title: Programming FAQ about "How do I convert a string to a number?" contains a typo
type: enhancement
versions: Python 3.8, Python 3.9

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

From report at bugs.python.org  Mon Apr 20 16:59:25 2020
From: report at bugs.python.org (Dominik V.)
Date: Mon, 20 Apr 2020 20:59:25 +0000
Subject: [New-bugs-announce] [issue40341] Programming FAQ includes actively
 discouraged solutions; Should those be removed?
Message-ID: <1587416365.54.0.999974156982.issue40341@roundup.psfhosted.org>


New submission from Dominik V. <dominik.vilsmeier1123 at gmail.com>:

The Programming FAQ contains multiple solutions (examples) which it describes as "shouldn't be used". The question is why are these included in the first place? Some of them are complicated in a way that a (new) programmer is unlikely to discover them by themselves.

Below I include all the relevant parts, since I wasn't sure whether to open a new issue for each them.

# [How do I write a function with output parameters (call by reference)?](https://docs.python.org/3/faq/programming.html#how-do-i-write-a-function-with-output-parameters-call-by-reference)

Among others it contains these two list items:

> 2. By using global variables. This isn?t thread-safe, and is not recommended.
> [...]
> 5. Or bundle up values in a class instance: [...] There?s almost never a good reason to get this complicated.

Especially number (5) is a pretty obscure way of solving that particular problem (even more so since a perfectly viable solution exists with (1), which is again recommended at the end of the paragraph). This additional recommendation of (1) at the end of the paragraph feels only necessary to draw attention away from the above do-not-use-solutions.

Also solutions (3) and (4) are basically equivalent in a sense that they rely on mutable builtin objects. So either they could be merged in one example or the list version could be left out altogether.

# [How do I use strings to call functions/methods?](https://docs.python.org/3/faq/programming.html#how-do-i-use-strings-to-call-functions-methods)

The last bullet point:

> Use locals() or eval() to resolve the function name: [...] Note: Using eval() is slow and dangerous. If you don?t have absolute control over the contents of the string, someone could pass a string that resulted in an arbitrary function being executed.

This solution proposes to use `eval` and then actively discourages its use later on. Instead it could mention `globals` as an analogy to `locals` with the example of retrieving a globally defined function in another namespace.

# [How can I sort one list by values from another list?](https://docs.python.org/3/faq/programming.html#how-can-i-sort-one-list-by-values-from-another-list)

The second part of the paragraph speaks about using a `for` loop with repeated `append` instead of using the previously mentioned list comprehension. It then speaks about the many reasons why the usage of a `for` loop is discouraged here, so it seems strange that it was mentioned in first place. Also, right now, 50% of the whole section are devoted to an analysis about what not to do for the last step which distracts from the actual solution. IMO it is sufficient to just show the list comprehension.

----------
assignee: docs at python
components: Documentation
messages: 366878
nosy: Dominik V., docs at python
priority: normal
severity: normal
status: open
title: Programming FAQ includes actively discouraged solutions; Should those be removed?
type: enhancement
versions: Python 3.8, Python 3.9

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

From report at bugs.python.org  Mon Apr 20 17:06:38 2020
From: report at bugs.python.org (Dominik V.)
Date: Mon, 20 Apr 2020 21:06:38 +0000
Subject: [New-bugs-announce] [issue40342] Programming FAQ about "How do I
 apply a method to a sequence of objects?" should include the option of an
 explicit for-loop
Message-ID: <1587416798.17.0.310240358568.issue40342@roundup.psfhosted.org>


New submission from Dominik V. <dominik.vilsmeier1123 at gmail.com>:

Right now the question is simply answered with:

> result = [obj.method() for obj in mylist]

However this is only appropriate if the result of the method is needed (i.e. if it's some kind of transformation).

There are many cases where it's not and the method is meant to update the object in place. Here it's better to use a for loop:

    for obj in mylist:
        obj.update()

Sometimes people use a one-way list comprehension hack because it saves one line:

    [obj.update() for obj in mylist]

However this is discouraged for multiple reasons (builds a superfluous list, obfuscates the actual intent, ...).

So I feel like the Programming FAQ should actively mention this scenario and promote the usage of a for loop here.

----------
assignee: docs at python
components: Documentation
messages: 366880
nosy: Dominik V., docs at python
priority: normal
severity: normal
status: open
title: Programming FAQ about "How do I apply a method to a sequence of objects?" should include the option of an explicit for-loop
type: enhancement
versions: Python 3.8, Python 3.9

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

From report at bugs.python.org  Mon Apr 20 17:15:44 2020
From: report at bugs.python.org (Dominik V.)
Date: Mon, 20 Apr 2020 21:15:44 +0000
Subject: [New-bugs-announce] [issue40343] Programming FAQ about "How do I
 call a method defined in a base class from a derived class that overrides
 it?" should mention the no-arguments-version of `super`
Message-ID: <1587417344.72.0.411751348323.issue40343@roundup.psfhosted.org>


New submission from Dominik V. <dominik.vilsmeier1123 at gmail.com>:

Right now it contains the following example:

    class Derived(Base):
        def meth(self):
            super(Derived, self).meth()

`super()` without arguments is beneficial for multiple reasons, so it should be used in the example.

Also the paragraph speaks about versions prior 3.0 which seems strange because

1. the page is served at https://docs.python.org/3/faq/programming.html i.e. corresponding to version Python 3
2. Python 2 maintenance has been finally dropped.

The provided example is still useful though, for example in multiple inheritance scenarios (though these are very specific and `super()` of course also works if base classes are compatible). So perhaps it's better left out?

----------
assignee: docs at python
components: Documentation
messages: 366884
nosy: Dominik V., docs at python
priority: normal
severity: normal
status: open
title: Programming FAQ about "How do I call a method defined in a base class from a derived class that overrides it?" should mention the no-arguments-version of `super`
type: enhancement
versions: Python 3.8, Python 3.9

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

From report at bugs.python.org  Mon Apr 20 17:27:30 2020
From: report at bugs.python.org (Dominik V.)
Date: Mon, 20 Apr 2020 21:27:30 +0000
Subject: [New-bugs-announce] [issue40344] Programming FAQ about "What is the
 most efficient way to concatenate many strings together?" -- Improving the
 example
Message-ID: <1587418050.72.0.944089786988.issue40344@roundup.psfhosted.org>


New submission from Dominik V. <dominik.vilsmeier1123 at gmail.com>:

The section mentions the usage of `str.join` and contains the following example:

    chunks = []
    for s in my_strings:
        chunks.append(s)
    result = ''.join(chunks)

Since `join` accepts any iterable the creation of the `chunks` list in a for loop is superfluous. If people just copy & paste from this FAQ they'll even end up with less performant code.

The example could be improved by providing an example list such as:

    strings = ['spam', 'ham', 'eggs']
    meal = ', '.join(strings)

Arguably this isn't a particularly long list of strings, so one more example could be added using e.g. `range(100)`:

    numbers = ','.join(str(x) for x in range(100))

This also emphasizes the fact that `join` takes any iterable rather than just lists.

----------
assignee: docs at python
components: Documentation
messages: 366887
nosy: Dominik V., docs at python
priority: normal
severity: normal
status: open
title: Programming FAQ about "What is the most efficient way to concatenate many strings together?" -- Improving the example
type: enhancement
versions: Python 3.8, Python 3.9

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

From report at bugs.python.org  Mon Apr 20 17:38:25 2020
From: report at bugs.python.org (Dominik V.)
Date: Mon, 20 Apr 2020 21:38:25 +0000
Subject: [New-bugs-announce] [issue40345] Programming FAQ about "How do I
 iterate over a sequence in reverse order?" should be more precise about
 `reversed`
Message-ID: <1587418705.72.0.486955576796.issue40345@roundup.psfhosted.org>


New submission from Dominik V. <dominik.vilsmeier1123 at gmail.com>:

https://docs.python.org/3/faq/programming.html#how-do-i-iterate-over-a-sequence-in-reverse-order

It contains the following example:

    for x in reversed(sequence):
        ...  # do something with x ...

With the note:

> This won?t touch your original sequence, but build a new copy with reversed order to iterate over.

The part about "build a new copy" is not correct in a sense that `reversed` just returns an iterator over the original sequence. This has mainly two consequences:

1. It can't be indexed, i.e. `reversed(sequence)[0]` doesn't work.
2. Changing the original sequence after `r = reversed(sequence)` has been constructed, is reflected in `r` when iterating over it.

So the sentence should be changed into something like:

> This creates an iterator object that can be used to iterate over the original sequence in reverse order.

Then for the second example about `sequence[::-1]` it would be good to mention the difference to `reversed`, namely that this version *does* create a copy of the original list (in reverse order). It could also be used as an opportunity to show how to reverse a string, since that is a very popular question on StackOverflow.

Also the various mentions of Python versions 2.3 and 2.4 seem strange since this is documentation about Python 3 and those version are anyway very old. So they should be left out as well.

----------
assignee: docs at python
components: Documentation
messages: 366889
nosy: Dominik V., docs at python
priority: normal
severity: normal
status: open
title: Programming FAQ about "How do I iterate over a sequence in reverse order?" should be more precise about `reversed`
type: enhancement
versions: Python 3.8, Python 3.9

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

From report at bugs.python.org  Mon Apr 20 17:53:09 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 20 Apr 2020 21:53:09 +0000
Subject: [New-bugs-announce] [issue40346] Redesign random class inheritance
Message-ID: <1587419589.68.0.186666450831.issue40346@roundup.psfhosted.org>


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

The random.Random class has a strange inheritance which is something uncommon in Python: it inherits from _random.Random which a concrete Mersenne Twister PRNG.

When a class inherit it, like random.SystemRandom, it should carefully override the right method.

I would expect to have something like a base class with abstract methods which raise NotImplementedError, and a concrete implementation which inherits from the base class and the Mersenne Twister C implementation.

A concrete issue is the how subclass handle the newly added randbytes() method:
https://bugs.python.org/issue40286#msg366860

The base class should implement randbytes() using getrandbits(), and the Mersenne Twister would override randbytes() with its fast implementation.

It would avoid the need for such method:

    def __init_subclass__(cls, /, **kwargs):
        """Control how subclasses generate random integers.

        The algorithm a subclass can use depends on the random() and/or
        getrandbits() implementation available to it and determines
        whether it can generate random integers from arbitrarily large
        ranges.
        """

        for c in cls.__mro__:
            if '_randbelow' in c.__dict__:
                # just inherit it
                break
            if 'getrandbits' in c.__dict__:
                cls._randbelow = cls._randbelow_with_getrandbits
                break
            if 'random' in c.__dict__:
                cls._randbelow = cls._randbelow_without_getrandbits
                break

It would also be nice if the base class would support a RNG which only produce bytes, like SystemRandom with os.urandom() and implement getrandbits() from that.


I also had concerns with the implementation of bpo-40282 "Allow random.getrandbits(0)":
https://github.com/python/cpython/pull/19539#pullrequestreview-393728231


It's maybe time to fix the class hierarchy.

----------
components: Library (Lib)
messages: 366892
nosy: vstinner
priority: normal
severity: normal
status: open
title: Redesign random class inheritance
versions: Python 3.9

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

From report at bugs.python.org  Mon Apr 20 17:53:49 2020
From: report at bugs.python.org (Dominik V.)
Date: Mon, 20 Apr 2020 21:53:49 +0000
Subject: [New-bugs-announce] [issue40347] Programming FAQ about "How do you
 remove duplicates from a list?" -- Improve the examples + Mention possible
 caveats
Message-ID: <1587419629.91.0.799773224624.issue40347@roundup.psfhosted.org>


New submission from Dominik V. <dominik.vilsmeier1123 at gmail.com>:

https://docs.python.org/3/faq/programming.html#how-do-you-remove-duplicates-from-a-list

In the beginning it points to the recipes at https://code.activestate.com/recipes/52560/ which does mention various caveats such as

> [...] whether [elements are] hashable, and whether they support full comparisons.

It then shows a concrete example implementation which however does require that the elements define a total ordering. The code for the example is pretty long so it might discourage new programmers before they even discover the most likely best solution which comes at the end of the section:

    list(set(mylist))

This seems by far the most useful solution with evidence from this StackOverflow question: https://stackoverflow.com/questions/7961363/removing-duplicates-in-lists

Hence I propose two changes:

1. Include the first sentence of the abstract from the recipes at https://code.activestate.com/recipes/52560/ in the FAQs: "The fastest way to remove duplicates from a sequence depends on some pretty subtle properties of the sequence elements, such as whether they're hashable, and whether they support full comparisons." at the beginning in order to mention possible caveats.
2. Either remove or move the code example relying on `sort` in order to give more visibility to the most likely more relevant solution using `set`. In any case it has the disclaimer about hashability and hence won't trick people into believing it works for all cases.

If the `sort` example is not removed, at least it's description should mention that elements must define a total ordering (e.g. if the elements are sets it won't generally work).

----------
assignee: docs at python
components: Documentation
messages: 366893
nosy: Dominik V., docs at python
priority: normal
severity: normal
status: open
title: Programming FAQ about "How do you remove duplicates from a list?" -- Improve the examples + Mention possible caveats
type: enhancement
versions: Python 3.8, Python 3.9

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

From report at bugs.python.org  Mon Apr 20 17:57:48 2020
From: report at bugs.python.org (Dominik V.)
Date: Mon, 20 Apr 2020 21:57:48 +0000
Subject: [New-bugs-announce] [issue40348] Programming FAQ about "What is
 delegation?": Fix typos
Message-ID: <1587419868.54.0.356271490131.issue40348@roundup.psfhosted.org>


New submission from Dominik V. <dominik.vilsmeier1123 at gmail.com>:

https://docs.python.org/3/faq/programming.html#what-is-delegation

The code example uses `self._outfile` with a single leading underscore, however in the subsequent text it is referred to with a double leading underscore:

* [...] calling the underlying `self.__outfile.write()` method.
* All other methods are delegated to the underlying `self.__outfile` object.

These should be fixed to use a single leading underscore as well.

----------
assignee: docs at python
components: Documentation
messages: 366896
nosy: Dominik V., docs at python
priority: normal
severity: normal
status: open
title: Programming FAQ about "What is delegation?": Fix typos
type: enhancement
versions: Python 3.8, Python 3.9

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

From report at bugs.python.org  Mon Apr 20 23:58:08 2020
From: report at bugs.python.org (Shantanu)
Date: Tue, 21 Apr 2020 03:58:08 +0000
Subject: [New-bugs-announce] [issue40349] Python3.9 changes col_offset for
 some ast nodes
Message-ID: <1587441488.8.0.801232249249.issue40349@roundup.psfhosted.org>


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

With Python 3.8:
```
Python 3.8.1 (default, Jan 23 2020, 23:36:06) 
[Clang 11.0.0 (clang-1100.0.33.17)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import ast
>>> ast.parse("(a).x").body[0].value.col_offset
1
```

With Python 3.9:
```
Python 3.9.0a5+ (heads/master:799d7d6, Apr  6 2020, 16:05:37) 
[Clang 11.0.0 (clang-1100.0.33.17)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import ast
>>> ast.parse("(a).x").body[0].value.col_offset
0
```

Maybe related to the new parser? I couldn't find what the environment variable to turn it off was.

For context, I'm trying to get mypy tests to pass with 3.9, but the tests make use of specific col_offsets for error reporting. It would be nice if these continued to match with 3.9

----------
messages: 366909
nosy: hauntsaninja
priority: normal
severity: normal
status: open
title: Python3.9 changes col_offset for some ast nodes

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

From report at bugs.python.org  Tue Apr 21 03:33:37 2020
From: report at bugs.python.org (Greg Whiteley)
Date: Tue, 21 Apr 2020 07:33:37 +0000
Subject: [New-bugs-announce] [issue40350] modulefinder chokes on numpy -
 dereferencing None in spec.loader
Message-ID: <1587454417.83.0.816569073565.issue40350@roundup.psfhosted.org>


New submission from Greg Whiteley <greg.whiteley at gmail.com>:

Issue:

Running ModuleFinder.run_script() on numpy versions 1.16.1 to 1.18.3 (maybe more) fails with backtrace.  See steps to reproduce below.

I do not see this problem on earlier versions of python than 3.8 (tested 3.4, 3.5, 3.6 on ubuntu LTSs), but the code has changed around 3.8.

The failure comes to this line of modulefinder.py

https://github.com/python/cpython/blame/master/Lib/modulefinder.py#L79

    if spec.loader.is_package(name):
        return None, os.path.dirname(file_path), ("", "", _PKG_DIRECTORY)

I can work around it by changing that to check for None

    if spec.loader is not None and spec.loader.is_package(name):
        return None, os.path.dirname(file_path), ("", "", _PKG_DIRECTORY)


Environment:

Ubuntu 20.04 with default python3, python3-pip

Steps to reproduce:

# note any nump version I've tried 1.16.1 and greater fails - I included 1.18.3 to be precise for reproduciton
$ pip3 install "numpy==1.18.3"
$ cat test.py
import numpy

$ python3
>>> from modulefinder import ModuleFinder
>>> finder = ModuleFinder()
>>> finder.run_script("test.py")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.8/modulefinder.py", line 165, in run_script
    self.load_module('__main__', fp, pathname, stuff)
...

300 lines of stack elided - see attached fulllog.txt

...
  File "/usr/lib/python3.8/modulefinder.py", line 433, in scan_code
    self._safe_import_hook(name, m, fromlist, level=0)
  File "/usr/lib/python3.8/modulefinder.py", line 378, in _safe_import_hook
    self.import_hook(name, caller, level=level)
  File "/usr/lib/python3.8/modulefinder.py", line 177, in import_hook
    q, tail = self.find_head_package(parent, name)
  File "/usr/lib/python3.8/modulefinder.py", line 233, in find_head_package
    q = self.import_module(head, qname, parent)
  File "/usr/lib/python3.8/modulefinder.py", line 320, in import_module
    fp, pathname, stuff = self.find_module(partname,
  File "/usr/lib/python3.8/modulefinder.py", line 511, in find_module
    return _find_module(name, path)
  File "/usr/lib/python3.8/modulefinder.py", line 78, in _find_module
    if spec.loader.is_package(name):
AttributeError: 'NoneType' object has no attribute 'is_package'
>>> 


Obviously I can't tell if numpy or modulefinder is the real culprit.

Let me know if I can give any more information.

----------
components: Library (Lib)
files: fulllog.txt
messages: 366912
nosy: Greg Whiteley
priority: normal
severity: normal
status: open
title: modulefinder chokes on numpy - dereferencing None in spec.loader
type: behavior
versions: Python 3.8
Added file: https://bugs.python.org/file49079/fulllog.txt

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

From report at bugs.python.org  Tue Apr 21 06:01:31 2020
From: report at bugs.python.org (Nino)
Date: Tue, 21 Apr 2020 10:01:31 +0000
Subject: [New-bugs-announce] [issue40351] How to edit "python --help"?
Message-ID: <1587463291.28.0.618151648812.issue40351@roundup.psfhosted.org>


New submission from Nino <ninoponchev at gmail.com>:

Can someone tell how can I edit the "python --help". Is it possible and if yes, how? I build python 3.7 on my PC from source code.

----------
assignee: docs at python
components: Documentation
messages: 366914
nosy: Nino-95, docs at python
priority: normal
severity: normal
status: open
title: How to edit "python --help"?
type: resource usage
versions: Python 3.7

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

From report at bugs.python.org  Tue Apr 21 09:02:07 2020
From: report at bugs.python.org (Oleg Nykolyn)
Date: Tue, 21 Apr 2020 13:02:07 +0000
Subject: [New-bugs-announce] [issue40352] SocketHandler silently drops log
 messages on re-connect
Message-ID: <1587474127.52.0.907489557829.issue40352@roundup.psfhosted.org>


New submission from Oleg Nykolyn <juravel2 at gmail.com>:

Hi,

I've faced this issue when using logging.handlers.SocketHandler AWS TCP balancer. AWS balancer uses 60 second time-out by default (max 4000s), thus resulting in lots of closed sockets during inactive periods.
SocketHandler.send() drops current message on any socket errors, so only next message gets logged.
I've tried to reproduce this using Lib unit tests, but didn't find any easy way to close() socket on test server side.
 
Sample client/server scripts attached, server output:

Got connection from:  ('127.0.0.1', 58044)
Got message:  b'Message #1\n'
Got message:  b'Message #2\n'
Got connection from:  ('127.0.0.1', 58045)
Got message:  b'Message #5\n'

Server closes incoming connection is 2 seconds, client looses messages #3 and #4.

----------
components: Library (Lib)
files: Archive.zip
messages: 366920
nosy: Oleg Nykolyn
priority: normal
severity: normal
status: open
title: SocketHandler silently drops log messages on re-connect
type: behavior
versions: Python 3.8
Added file: https://bugs.python.org/file49080/Archive.zip

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

From report at bugs.python.org  Tue Apr 21 12:32:58 2020
From: report at bugs.python.org (Brandt Bucher)
Date: Tue, 21 Apr 2020 16:32:58 +0000
Subject: [New-bugs-announce] [issue40353] Add an optional "strict" check to
 zip
Message-ID: <1587486778.34.0.294525065748.issue40353@roundup.psfhosted.org>


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

As discussed on Python-ideas:

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

When a keyword-only argument "strict=True" is passed to zip's constructor, a ValueError will be raised in the case where one iterator is exhausted before the others. Otherwise, no side-effects (such as iterator consumption) will be changed.

I do wonder if we can use a better keyword than "strict" here.

I'm currently working on an implementation, and @cool-RR is working on tests and docs.

----------
assignee: brandtbucher
components: Interpreter Core
messages: 366926
nosy: brandtbucher, cool-RR
priority: normal
severity: normal
status: open
title: Add an optional "strict" check to zip
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Tue Apr 21 13:05:16 2020
From: report at bugs.python.org (xie)
Date: Tue, 21 Apr 2020 17:05:16 +0000
Subject: [New-bugs-announce] [issue40354] problem when using yield
Message-ID: <1587488716.21.0.425548141738.issue40354@roundup.psfhosted.org>


New submission from xie <xsmyqf at qq.com>:

----------version1?--------------
def func1():
    a=0 
    b=10
    for i in range(4):
        result = yield a+100 if b>100 else (yield a)
        print(result)

f1 = func1()
print("value:%s" % next(f1))
print("--------------")
print("value:%s" % next(f1))
print("--------------")

----------version2--------------

def func1():
    a=0 
    b=10
    for i in range(4):
        result = (yield a+100) if b>100 else (yield a)
        print(result)

f1 = func1()
print("value:%s" % next(f1))
print("--------------")
print("value:%s" % next(f1))
print("--------------")


------------------problem------------------------
I think two version should behave same,but it did not.Do this will be treated as a bug ?

----------
messages: 366931
nosy: xsmyqf
priority: normal
severity: normal
status: open
title: problem when using yield
type: behavior
versions: Python 3.7

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

From report at bugs.python.org  Tue Apr 21 15:59:22 2020
From: report at bugs.python.org (Brandt Bucher)
Date: Tue, 21 Apr 2020 19:59:22 +0000
Subject: [New-bugs-announce] [issue40355] The ast module fails to reject
 certain malformed nodes
Message-ID: <1587499162.97.0.267428394248.issue40355@roundup.psfhosted.org>


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

There are several places in the ast module where the use of zip is allowing malformed nodes to have unpaired children silently thrown away. A couple of short examples:

>>> from ast import Constant, Dict, literal_eval, unparse
>>> nasty_dict = Dict(keys=[Constant("I don't have a value!")], values=[])
>>> unparse(nasty_dict)
'{}'
>>> literal_eval(nasty_dict)
{}

I'm currently working on a patch to raise errors instead.

----------
assignee: brandtbucher
components: Library (Lib)
messages: 366938
nosy: brandtbucher
priority: normal
severity: normal
status: open
title: The ast module fails to reject certain malformed nodes
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Tue Apr 21 17:42:23 2020
From: report at bugs.python.org (darkman66)
Date: Tue, 21 Apr 2020 21:42:23 +0000
Subject: [New-bugs-announce] [issue40356] OverflowError: mktime argument out
 of range
Message-ID: <1587505343.63.0.318003481208.issue40356@roundup.psfhosted.org>


New submission from darkman66 <agaihubi at gmail.com>:

example test

import time, pickle

d=pickle.loads(b'\x80\x03ctime\nstruct_time\nq\x00(M\xe4\x07K\x04K\x10K\x13K\x0cK#K\x03KkK\x01tq\x01}q\x02(X\x07\x00\x00\x00tm_zoneq\x03NX\t\x00\x00\x00tm_gmtoffq\x04Nu\x86q\x05Rq\x06.')
time.mktime(d)

on macox python compiled via brew 
Python 3.7.3 (default, Mar  6 2020, 22:34:30)
Type "copyright", "credits" or "license" for more information.

IPython 5.3.0 -- An enhanced Interactive Python.

all good, result -> Out[3]: 1587064355.0

in docker installed out of official deb (ubuntu 9.10)

Python 3.7.5 (default, Nov 20 2019, 09:21:52)
Type "copyright", "credits" or "license" for more information.
IPython 5.3.0 -- An enhanced Interactive Python.


In [5]: time.mktime(d)
---------------------------------------------------------------------------
OverflowError                             Traceback (most recent call last)
<ipython-input-5-b475bfddba64> in <module>()
----> 1 time.mktime(d)

OverflowError: mktime argument out of range

----------
components: C API
messages: 366944
nosy: darkman66
priority: normal
severity: normal
status: open
title: OverflowError: mktime argument out of range
type: crash
versions: Python 3.7

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

From report at bugs.python.org  Tue Apr 21 18:00:47 2020
From: report at bugs.python.org (Chris Meyer)
Date: Tue, 21 Apr 2020 22:00:47 +0000
Subject: [New-bugs-announce] [issue40357] asyncio: will
 shutdown_default_executor work in single step (stop, run_forever) mode?
Message-ID: <1587506447.82.0.117857372941.issue40357@roundup.psfhosted.org>


New submission from Chris Meyer <cmeyer1969 at gmail.com>:

Is the new asyncio.loop.shutdown_default_executor() suitable for event loops that are run in single-step mode?

event_loop.create_task(event_loop.shutdown_default_executor())
event_loop.stop()
event_loop.run_forever()

I don't see how it will work since shutdown_default_executor() may not be finished during a single 'stopped' run_forever() call. 

Also, what happens to pending executor futures? Previously reported bug #28464.

Here is my currently working code for shutting down the event loop.

# give event loop one chance to finish up
event_loop.stop()
event_loop.run_forever()
# wait for everything to finish, including tasks running in executors
# this assumes that all outstanding tasks finish in a reasonable time (i.e. no infinite loops).
all_tasks_fn = getattr(asyncio, "all_tasks", None)
if not all_tasks_fn:
    all_tasks_fn = asyncio.Task.all_tasks
tasks = all_tasks_fn(loop=event_loop)
if tasks:
    gather_future = asyncio.gather(*tasks, return_exceptions=True)
else:
    # work around fact that gather always uses global event loop in Python 3.8
    gather_future = event_loop.create_future()
    gather_future.set_result([])
event_loop.run_until_complete(gather_future)
# due to a seeming bug in Python libraries, the default executor needs to be shutdown explicitly before the event loop
# see http://bugs.python.org/issue28464 .
_default_executor = getattr(event_loop, "_default_executor", None)
if _default_executor:
    _default_executor.shutdown()
event_loop.close()

----------
messages: 366945
nosy: cmeyer, vstinner
priority: normal
severity: normal
status: open
title: asyncio: will shutdown_default_executor work in single step (stop, run_forever) mode?
versions: Python 3.9

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

From report at bugs.python.org  Tue Apr 21 20:03:03 2020
From: report at bugs.python.org (Domenico Ragusa)
Date: Wed, 22 Apr 2020 00:03:03 +0000
Subject: [New-bugs-announce] [issue40358] pathlib's relative_to should
 behave like os.path.relpath
Message-ID: <1587513783.17.0.6950267733.issue40358@roundup.psfhosted.org>


New submission from Domenico Ragusa <domenicoragusa at gmail.com>:

Can we improve pathlib.relative_to(other) so that it handles the case of a path not being a direct child of other, like os.path.relpath?

For example:
Path('/some/thing').relative_to('/foo') -> Path('../some/thing')

At the moment it just raises an exception.

----------
components: Library (Lib)
files: pathlib.diff
keywords: patch
messages: 366958
nosy: Domenico Ragusa
priority: normal
severity: normal
status: open
title: pathlib's relative_to should behave like os.path.relpath
type: enhancement
versions: Python 3.9
Added file: https://bugs.python.org/file49081/pathlib.diff

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

From report at bugs.python.org  Tue Apr 21 20:26:27 2020
From: report at bugs.python.org (Matthew Davis)
Date: Wed, 22 Apr 2020 00:26:27 +0000
Subject: [New-bugs-announce] [issue40359] email.parse part.get_filename()
 fails to unwrap long attachment file names
Message-ID: <1587515187.44.0.744042033479.issue40359@roundup.psfhosted.org>


New submission from Matthew Davis <ubuntu.one at mdavis.xyz>:

# Summary

When parsing emails with long attachment file names, part.get_filename() often returns \n or \r\n.
It should strip those characters out.

# Steps to reproduce

I have attached a minimal working example.

The relevant part of the raw email is:

--_004_D6CEDE1EBD6645898F5643C0C6878005examplecom_
Content-Type: text/plain;
	name="an attachment with a very very very long super long file name which has
 many words and just keeps on going and going.txt"

# Expected output:

attachments = ["an attachment with a very very very long super long file name which has many words and just keeps on going and going.txt"]

Maybe I'm reading the email RFC spec wrong. My interpretation is that the parser should do something like:

raw = raw.replace('\r\n ', ' ').replace('\n ', ' ')

# Actual output

attachments = ["an attachment with a very very very long super long file name which\n has many words and just keeps on going and going.txt"]

Note that I have seen other examples where the output includes \r\n not just \n

# Impact

I'm trying to write an email bot which saves attachments to a database, and also forwards on the emails.
My both thinks that the filename includes a line break. This inevitably causes failures in my subsequent code.

# Relevant links:

The RFC for email spec is here: https://tools.ietf.org/html/rfc2822.html#section-2.2.3

This Stack Overflow answer seems relevant: https://stackoverflow.com/questions/3050298/parsing-email-with-python/3050374#3050374

Issue 3601 may be relevant, but doesn't seem exactly the same. It seems to be the reverse, *constructing* emails with long headers. My issue is *parsing* emails with long headers.

----------
components: email
files: mwe.py
messages: 366963
nosy: barry, matt-davis, r.david.murray
priority: normal
severity: normal
status: open
title: email.parse part.get_filename() fails to unwrap long attachment file names
versions: Python 3.6
Added file: https://bugs.python.org/file49083/mwe.py

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

From report at bugs.python.org  Wed Apr 22 00:40:54 2020
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 22 Apr 2020 04:40:54 +0000
Subject: [New-bugs-announce] [issue40360] Deprecate lib2to3 (and 2to3) for
 future removal
Message-ID: <1587530454.25.0.44181585934.issue40360@roundup.psfhosted.org>


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

Based on the PEP 617 acceptance thread on python-dev, lib2to3 is eventually going to run into trouble parsing modern syntax a few releases from now.

It would be better off maintained outside of the standard library.  It gets used by a lot of things and is generally useful, but would make a lot more sense as a PyPI project than as something only quasi-maintained within the stdlib (it only gained the ability to parse a couple modern syntax features in via bugfix contributions to the stdlib the past month or two...  meaning a lot of versions of it out there cannot)

Black has already forked it.

goal:  PendingDeprecationWarning and documentation as such in 3.9.  Move to DeprecationWarning in 3.10 or 3.11 and remove it by ~3.12.  Subject to our existing deprecation process guidelines.

----------
assignee: gregory.p.smith
messages: 366973
nosy: gregory.p.smith
priority: normal
severity: normal
status: open
title: Deprecate lib2to3 (and 2to3) for future removal
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Wed Apr 22 04:01:54 2020
From: report at bugs.python.org (Viraat Das)
Date: Wed, 22 Apr 2020 08:01:54 +0000
Subject: [New-bugs-announce] [issue40361] Darwin systems using win settings
 for webbrowser.py
Message-ID: <1587542514.76.0.13386911281.issue40361@roundup.psfhosted.org>


Change by Viraat Das <viraat.laldas at gmail.com>:


----------
components: Distutils
nosy: Viraat Das, dstufft, eric.araujo
priority: normal
severity: normal
status: open
title: Darwin systems using win settings for webbrowser.py
versions: Python 3.8

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

From report at bugs.python.org  Wed Apr 22 09:29:04 2020
From: report at bugs.python.org (Paul Stoner)
Date: Wed, 22 Apr 2020 13:29:04 +0000
Subject: [New-bugs-announce] [issue40362] AbstractBasicAuthHandler does not
 support the following scheme: 'Bearer'
Message-ID: <1587562144.16.0.694381500951.issue40362@roundup.psfhosted.org>


New submission from Paul Stoner <pstoner6765 at gmail.com>:

I found this issue when running an ansible playbook. In the playbook we go out to Azure Artifacts to download a customer jar to be deploy with a web application.

After some digging, I found the error comes from the request class in the urllib library. Knowing this I wrote a small program to test and try to decipher what is happening.

I've attached a scrubbed version of my test code. I've stripped all sensitive information. You may need to have an azure DevOps account with an artifact repository set up. I have not tested this against any other type of repository, such as GitHub.

Additional information:
1) I also use CNTLM in order to avoid authentication through our corporate firewall. I have tested this with and without CNTLM active

2) My organization utilizes ADFS Federated authentication. I am assuming this is where the Bearer token is coming from. I will try and test this on a private network to see if ADFS is the issue. I'll augment this bug with my findings

The debug output is shown below

3.8.2 (tags/v3.8.2:7b3ab59, Feb 25 2020, 23:03:10) [MSC v.1916 64 bit (AMD64)]
send: b'GET /.../_packaging/artifacts/maven/v1/custom.jar HTTP/1.1\r\nAccept-Encoding: identity\r\nHost: pkgs.dev.azure.com\r\nUser-Agent: Python-urllib/3.8\r\nConnection: close\r\n\r\n'
reply: 'HTTP/1.1 401 Unauthorized\r\n'
header: Cache-Control: no-cache
header: Pragma: no-cache
header: Content-Length: 307
header: Content-Type: application/json; charset=utf-8
header: Expires: -1
header: P3P: CP="CAO DSP COR ADMa DEV CONo TELo CUR PSA PSD TAI IVDo OUR SAMi BUS DEM NAV STA UNI COM INT PHY ONL FIN PUR LOC CNT"
header: WWW-Authenticate: Bearer authorization_uri=https://login.windows.net/...
header: WWW-Authenticate: Basic realm="https://pkgsprodcus1.pkgs.visualstudio.com/"
header: WWW-Authenticate: TFS-Federated
header: X-TFS-ProcessId: ...
header: Strict-Transport-Security: max-age=31536000; includeSubDomains
header: ActivityId: ...
header: X-TFS-Session: ...
header: X-VSS-E2EID: ...
header: X-FRAME-OPTIONS: SAMEORIGIN
header: X-TFS-FedAuthRealm: https://pkgsprodcus1.pkgs.visualstudio.com/
header: X-TFS-FedAuthIssuer: https://www.visualstudio.com/
header: X-VSS-AuthorizationEndpoint: https://vssps.dev.azure.com/.../
header: X-VSS-ResourceTenant: ...
header: X-VSS-S2STargetService: 00000030-0000-8888-8000-000000000000/visualstudio.com
header: X-TFS-FedAuthRedirect: https://spsprodcus2.vssps.visualstudio.com/...
header: Request-Context: appId=cid-v1:540f64bd-7388-47ab-bdf2-a94451f9dd55
header: Access-Control-Expose-Headers: Request-Context
header: X-Content-Type-Options: nosniff
header: X-MSEdge-Ref: Ref A: ... Ref B: CHGEDGE1216 Ref C: 2020-04-22T13:01:32Z
header: Date: Wed, 22 Apr 2020 13:01:32 GMT
header: Connection: close
AbstractBasicAuthHandler does not support the following scheme: 'Bearer'

----------
components: Library (Lib)
files: linktest_clean.py
messages: 367002
nosy: Paul Stoner
priority: normal
severity: normal
status: open
title: AbstractBasicAuthHandler does not support the following scheme: 'Bearer'
type: behavior
versions: Python 3.6, Python 3.7, Python 3.8
Added file: https://bugs.python.org/file49085/linktest_clean.py

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

From report at bugs.python.org  Wed Apr 22 11:21:31 2020
From: report at bugs.python.org (Jack Orenstein)
Date: Wed, 22 Apr 2020 15:21:31 +0000
Subject: [New-bugs-announce] [issue40363] shlex.quote applied to a glob
 pattern disables glob matching
Message-ID: <1587568891.1.0.0837751696044.issue40363@roundup.psfhosted.org>


New submission from Jack Orenstein <jao at geophile.com>:

I am using shlex.quote to pass filenames to a shell command, e.g. ls. The problem is that glob patterns, when quoted, no longer operate as glob patterns. So, for example, executing this:

    ls 'var/log/syslog*'

results in this output:

    ls: cannot access '/var/log/syslog*': No such file or directory

The documentation for shlex.quote says: "Return a shell-escaped version of the string s. The returned value is a string that can safely be used as one token in a shell command line, for cases where you cannot use a list."

I believe that quoting needs to preserve glob semantics to fulfill the documented goal. For example, it seems to me that quoting as follows would be better:

    ls '/var/log/syslog'*

----------
components: Library (Lib)
messages: 367010
nosy: geophile
priority: normal
severity: normal
status: open
title: shlex.quote applied to a glob pattern disables glob matching
versions: Python 3.7

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

From report at bugs.python.org  Wed Apr 22 12:51:11 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 22 Apr 2020 16:51:11 +0000
Subject: [New-bugs-announce] [issue40364] asyncio: replace
 _compute_returncode() with os.waitstatus_to_exitcode()
Message-ID: <1587574271.75.0.606427962214.issue40364@roundup.psfhosted.org>


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

I added os.waitstatus_to_exitcode() in bpo-40094. I propose to replace _compute_returncode() with os.waitstatus_to_exitcode() in Lib/asyncio/unix_events.py to simplify the code *and* to raise an exception if asyncio gets an unexpected wait status from os.waitpid().

There is a comment which suggest to detect when asyncio gets an unexpected status, see the last comment of:

def _compute_returncode(status):
    if os.WIFSIGNALED(status):
        # The child process died because of a signal.
        return -os.WTERMSIG(status)
    elif os.WIFEXITED(status):
        # The child process exited (e.g sys.exit()).
        return os.WEXITSTATUS(status)
    else:
        # The child exited, but we don't understand its status.
        # This shouldn't happen, but if it does, let's just
        # return that status; perhaps that helps debug it.
        return status

Replacing _compute_returncode() with os.waitstatus_to_exitcode() in Lib/asyncio/unix_events.py is trivial. The problem is to update Lib/test/test_asyncio/test_unix_events.py which uses tons of mocks on os.W*() functions (ex: os.WIFEXITED()).

I'm not sure how tests should be updated.

Is there someone interested to propose a PR for that?

----------
components: Library (Lib), asyncio
messages: 367021
nosy: aeros, asvetlov, corona10, vstinner, yselivanov
priority: normal
severity: normal
status: open
title: asyncio: replace _compute_returncode() with os.waitstatus_to_exitcode()
versions: Python 3.9

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

From report at bugs.python.org  Wed Apr 22 13:42:36 2020
From: report at bugs.python.org (strjan)
Date: Wed, 22 Apr 2020 17:42:36 +0000
Subject: [New-bugs-announce] [issue40365] argparse: action "extend" with 1
 parameter splits strings into characters
Message-ID: <1587577356.91.0.833148420465.issue40365@roundup.psfhosted.org>


New submission from strjan <str.jan at seznam.cz>:

When positional argument with action='extend' is given to parse only one string argument, the string is splitted into individual characters.

The problem occures, when no "nargs" is given; it makes sense that nargs is requiered, though at least notion in documentation would be nice, as the issue does not occure with action='append'

Minimal example included.

----------
files: argparse_bug.py
messages: 367033
nosy: strjan
priority: normal
severity: normal
status: open
title: argparse: action "extend" with 1 parameter splits strings into characters
type: behavior
versions: Python 3.8, Python 3.9
Added file: https://bugs.python.org/file49086/argparse_bug.py

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

From report at bugs.python.org  Wed Apr 22 15:44:23 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Wed, 22 Apr 2020 19:44:23 +0000
Subject: [New-bugs-announce] [issue40366] Start giving deprecation warnings
 for obsoleted flags in compile
Message-ID: <1587584663.02.0.972629021884.issue40366@roundup.psfhosted.org>


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

We can start deprecating usage of obsoleted flags in compile and slowly remove support for them. An example would be CO_NESTED. 

https://github.com/python/cpython/blob/master/Python/bltinmodule.c#L748

----------
messages: 367046
nosy: BTaskaya
priority: normal
severity: normal
status: open
title: Start giving deprecation warnings for obsoleted flags in compile
versions: Python 3.9

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

From report at bugs.python.org  Wed Apr 22 17:03:43 2020
From: report at bugs.python.org (YoSTEALTH)
Date: Wed, 22 Apr 2020 21:03:43 +0000
Subject: [New-bugs-announce] [issue40367] ImportError: libffi.so.6
Message-ID: <1587589423.16.0.82755935318.issue40367@roundup.psfhosted.org>


New submission from YoSTEALTH <ritesh at stealthcentral.com>:

>>> /opt/python/3.8.1/lib/python3 setup.py build_ext --inplace


Traceback (most recent call last):
  File "./setup.py", line 1, in <module>
    from setuptools import setup, find_packages
  File "/opt/python/3.8.1/lib/python3.8/site-packages/setuptools/__init__.py", line 19, in <module>
    from setuptools.dist import Distribution
  File "/opt/python/3.8.1/lib/python3.8/site-packages/setuptools/dist.py", line 34, in <module>
    from setuptools import windows_support
  File "/opt/python/3.8.1/lib/python3.8/site-packages/setuptools/windows_support.py", line 2, in <module>
    import ctypes
  File "/opt/python/3.8.1/lib/python3.8/ctypes/__init__.py", line 7, in <module>
    from _ctypes import Union, Structure, Array
ImportError: libffi.so.6: cannot open shared object file: No such file or directory



"libffi 3.3-3" on "5.6.5-3-MANJARO" is installed as:

/usr/lib/libffi.so
/usr/lib/libffi.so.7
/usr/lib/libffi.so.7.1.0
...


Maybe `_ctypes` should try to find "libffi.so" vs "libffi.so.6" ?

----------
components: ctypes
messages: 367048
nosy: YoSTEALTH
priority: normal
severity: normal
status: open
title: ImportError: libffi.so.6
type: compile error

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

From report at bugs.python.org  Wed Apr 22 17:25:43 2020
From: report at bugs.python.org (Kagami Sascha Rosylight)
Date: Wed, 22 Apr 2020 21:25:43 +0000
Subject: [New-bugs-announce] [issue40368] os.path.realpath uppercases
 Windows drive letter on Python 3.8
Message-ID: <1587590743.67.0.821024621015.issue40368@roundup.psfhosted.org>


New submission from Kagami Sascha Rosylight <saschanaz at outlook.com>:

```
$ python3.7
Python 3.7.4 (tags/v3.7.4:e09359112e, Jul  8 2019, 20:34:20) [MSC v.1916 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import os;os.path.realpath('c:/')
'c:\\'
```

```
$ python3.8
Python 3.8.2 (tags/v3.8.2:7b3ab59, Feb 25 2020, 23:03:10) [MSC v.1916 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import os;os.path.realpath('c:/')
'C:\\'
```

This behavior is inconsistent with `os.path.abspath` where it always returns lowercased drive letter, and also causes a failure in Gecko build script: https://bugzilla.mozilla.org/show_bug.cgi?id=1628726

----------
messages: 367053
nosy: saschanaz
priority: normal
severity: normal
status: open
title: os.path.realpath uppercases Windows drive letter on Python 3.8
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Wed Apr 22 22:48:54 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Thu, 23 Apr 2020 02:48:54 +0000
Subject: [New-bugs-announce] [issue40369] Use PEP 590 vectorcall to speed up
 GenericAlias.
Message-ID: <1587610134.42.0.272743433509.issue40369@roundup.psfhosted.org>


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

Since PEP 560 was approved,
The following syntax has become available. 

from queue import Queue
v = Queue[int]

It's a very shiny feature.
Given the direction of programming language, it's probably a very useful feature that users will use very often in the near future.

When I looked at Object/geneticiasobject.c, the current implementation is a very good condition for using the vectorcall proposed by PEP590 .

The benchmarks are as follows.
So I suggest using vectorcall in GenericAlias.

if the suggestion is accepted, I 'd like to summit the patch :)


+--------------------+----------------------+-----------------------------+
| Benchmark          | master-generic-alias | proposed-generic-alias      |
+====================+======================+=============================+
| bench GenericAlias | 143 ns               | 111 ns: 1.29x faster (-22%) |
+--------------------+----------------------+-----------------------------+

----------
components: Interpreter Core
files: bench_generic_alias.py
messages: 367074
nosy: corona10, gvanrossum, vstinner
priority: normal
severity: normal
status: open
title: Use PEP 590 vectorcall to speed up GenericAlias.
versions: Python 3.9
Added file: https://bugs.python.org/file49087/bench_generic_alias.py

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

From report at bugs.python.org  Thu Apr 23 01:56:20 2020
From: report at bugs.python.org (Michael Felt)
Date: Thu, 23 Apr 2020 05:56:20 +0000
Subject: [New-bugs-announce] [issue40370] AIX: ld_so_aix not found during
 test of test_peg_generator
Message-ID: <1587621380.1.0.901678392936.issue40370@roundup.psfhosted.org>


New submission from Michael Felt <aixtools at felt.demon.nl>:

As part, I assume, of PR19503, that includes 91 changed files with 27,058 additions and 147 deletions the AIX buildbot is broken.

Rather than looking/finding Modules/ld_so_aix (where I expect it to be) tests are failing, ulitmately because they look/expect it to be in a new location, and with a name dependent on being debug (or not) as the bots are configured using --pydebug.

Examples:
FileNotFoundError: [Errno 2] No such file or directory: '/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/target/lib/python3.9/config-3.9d/ld_so_aix'

or

FileNotFoundError: [Errno 2] No such file or directory: '/home/aixtools/buildarea/3.x.aixtools-aix-power6/build/target/lib/python3.9/config-3.9d/ld_so_aix'

This is (only?) in test_peg_generator.

One traceback example:
Captured traceback
==================

Traceback (most recent call last):
  File "/home/aixtools/buildarea/3.x.aixtools-aix-power6/build/Lib/test/test_peg_generator/test_c_parser.py", line 174, in test_nasty_mutually_left_recursive
    self.check_input_strings_for_grammar(grammar, self.tmp_path, valid_cases, invalid_cases)
  File "/home/aixtools/buildarea/3.x.aixtools-aix-power6/build/Lib/test/test_peg_generator/test_c_parser.py", line 40, in check_input_strings_for_grammar
    extension = generate_parser_c_extension(grammar, Path(tmp_path))
  File "/home/aixtools/buildarea/3.x.aixtools-aix-power6/build/Tools/peg_generator/pegen/testutil.py", line 95, in generate_parser_c_extension
    extension_path = compile_c_extension(str(source), build_dir=str(path / "build"))
  File "/home/aixtools/buildarea/3.x.aixtools-aix-power6/build/Tools/peg_generator/pegen/build.py", line 73, in compile_c_extension
    cmd.run()
  File "/home/aixtools/buildarea/3.x.aixtools-aix-power6/build/Lib/distutils/command/build_ext.py", line 340, in run
    self.build_extensions()
  File "/home/aixtools/buildarea/3.x.aixtools-aix-power6/build/Lib/distutils/command/build_ext.py", line 449, in build_extensions
    self._build_extensions_serial()
  File "/home/aixtools/buildarea/3.x.aixtools-aix-power6/build/Lib/distutils/command/build_ext.py", line 474, in _build_extensions_serial
    self.build_extension(ext)
  File "/home/aixtools/buildarea/3.x.aixtools-aix-power6/build/Lib/distutils/command/build_ext.py", line 551, in build_extension
    self.compiler.link_shared_object(
  File "/home/aixtools/buildarea/3.x.aixtools-aix-power6/build/Lib/distutils/ccompiler.py", line 713, in link_shared_object
    self.link(CCompiler.SHARED_OBJECT, objects,
  File "/home/aixtools/buildarea/3.x.aixtools-aix-power6/build/Lib/distutils/unixccompiler.py", line 204, in link
    self.spawn(linker + ld_args)
  File "/home/aixtools/buildarea/3.x.aixtools-aix-power6/build/Lib/distutils/ccompiler.py", line 910, in spawn
    spawn(cmd, dry_run=self.dry_run)
  File "/home/aixtools/buildarea/3.x.aixtools-aix-power6/build/Lib/distutils/spawn.py", line 74, in spawn
    proc = subprocess.Popen(cmd, env=env)
  File "/home/aixtools/buildarea/3.x.aixtools-aix-power6/build/Lib/subprocess.py", line 947, in __init__
    self._execute_child(args, executable, preexec_fn, close_fds,
  File "/home/aixtools/buildarea/3.x.aixtools-aix-power6/build/Lib/subprocess.py", line 1819, in _execute_child
    raise child_exception_type(errno_num, err_msg, err_filename)
FileNotFoundError: [Errno 2] No such file or directory: '/home/aixtools/buildarea/3.x.aixtools-aix-power6/build/target/lib/python3.9/config-3.9d/ld_so_aix'

See https://buildbot.python.org/all/#builders/119/builds/720 and https://buildbot.python.org/all/#builders/227/builds/723

----------
components: Build, Tests
messages: 367081
nosy: Michael.Felt
priority: normal
severity: normal
status: open
title: AIX: ld_so_aix not found during test of test_peg_generator
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Thu Apr 23 03:19:46 2020
From: report at bugs.python.org (mrc)
Date: Thu, 23 Apr 2020 07:19:46 +0000
Subject: [New-bugs-announce] [issue40371] Deadlock in
 logging.config.dictConfig
Message-ID: <1587626386.55.0.492075061182.issue40371@roundup.psfhosted.org>


New submission from mrc <marco.giusti at posteo.de>:

DataGraham in #django reported a deadlock with a very specific logging configuration. Issue is reproducible from this code: https://github.com/data-graham/wedge. To trigger the deadlock at least one handle must be enable. Note how there there are no loggers using those handlers. (https://github.com/data-graham/wedge/blob/master/wedge/settings.py#L127-L169)

The two offending locks causing the deadlock are logging._lock and a lock used by importlib._bootstrap._imp (_PyImport_AcquireLock).


TH1> start and complete the logging configuration via dictConfig. An handler is configured but no logger uses it, only a weakref holds it
TH2> start logging configuration, acquires logging._lock
TH1> import some module, acquiring the import lock
TH1> the garbage collector starts and reclaims the unused handled (only a weakref exists)
TH1> the weakref callback tries to acquire logging._lock. WAITING
TH2> start importing some module, try to acquire import lock. DEADLOCK

Attached the traceback of the threads. I could test this with Python3.7 only (and Django 3.0).

----------
components: Library (Lib)
files: deadlock_logging.log
messages: 367085
nosy: mrc
priority: normal
severity: normal
status: open
title: Deadlock in logging.config.dictConfig
versions: Python 3.7
Added file: https://bugs.python.org/file49088/deadlock_logging.log

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

From report at bugs.python.org  Thu Apr 23 04:16:12 2020
From: report at bugs.python.org (Andreas Sommer)
Date: Thu, 23 Apr 2020 08:16:12 +0000
Subject: [New-bugs-announce] [issue40372] doctest example programs should
 exit 1 if any test fails
Message-ID: <1587629772.69.0.383881965755.issue40372@roundup.psfhosted.org>


New submission from Andreas Sommer <andreas.sommer87 at googlemail.com>:

Documentation recommends calling `doctest.testmod()`, but exits with code 0 even if a test fails.

----------
assignee: docs at python
components: Documentation
messages: 367086
nosy: Andreas Sommer, docs at python
priority: normal
severity: normal
status: open
title: doctest example programs should exit 1 if any test fails
type: enhancement
versions: Python 2.7, 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/issue40372>
_______________________________________

From report at bugs.python.org  Thu Apr 23 07:12:54 2020
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Thu, 23 Apr 2020 11:12:54 +0000
Subject: [New-bugs-announce] [issue40373] urlunparse does not escape slash
 (/) for http+unix:// in netloc field
Message-ID: <1587640374.39.0.0313864696391.issue40373@roundup.psfhosted.org>


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

urlunsplit(('http+unix', '\x00qwe/asd', 'def', '', ''))                                                                       

gives:

'http+unix://\x00qwe/asd/def'

but should:

'http+unix://\x00qwe%2Fasd/def'

see https://github.com/msabramo/requests-unixsocket for examples of such URLs.

Workaround: build URL by hand, like `f'http+unix://{quote(..., safe='')}/....'`

----------
components: Library (Lib)
messages: 367092
nosy: socketpair
priority: normal
severity: normal
status: open
title: urlunparse does not escape slash (/) for http+unix:// in netloc field
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/issue40373>
_______________________________________

From report at bugs.python.org  Thu Apr 23 12:02:41 2020
From: report at bugs.python.org (Thor Whalen)
Date: Thu, 23 Apr 2020 16:02:41 +0000
Subject: [New-bugs-announce] [issue40374] collections.abc docs table:
 Mapping missing __reversed__
Message-ID: <1587657761.26.0.243868623408.issue40374@roundup.psfhosted.org>


New submission from Thor Whalen <thorwhalen1 at gmail.com>:

`Mapping.__reversed__` exists, but is not listed in the table: https://docs.python.org/3/library/collections.abc.html#collections-abstract-base-classes

https://github.com/python/cpython/blob/master/Doc/library/collections.abc.rst

----------
assignee: docs at python
components: Documentation
messages: 367127
nosy: Thor Whalen2, docs at python, rhettinger, stutzbach
priority: normal
pull_requests: 19001
severity: normal
status: open
title: collections.abc docs table: Mapping missing __reversed__
versions: Python 3.8

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

From report at bugs.python.org  Thu Apr 23 20:44:57 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 24 Apr 2020 00:44:57 +0000
Subject: [New-bugs-announce] [issue40375] Add the UNSELECT command to imaplib
Message-ID: <1587689097.33.0.419593805597.issue40375@roundup.psfhosted.org>


New submission from Eric V. Smith <eric at trueblade.com>:

RFC 3691 from 2004 adds support for the UNSELECT command as an extension capability. https://tools.ietf.org/html/rfc3691

imaplib does not support UNSELECT.

----------
components: Library (Lib)
messages: 367165
nosy: eric.smith
priority: normal
severity: normal
stage: needs patch
status: open
title: Add the UNSELECT command to imaplib
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Fri Apr 24 07:03:54 2020
From: report at bugs.python.org (=?utf-8?q?Jens_Holzk=C3=A4mper?=)
Date: Fri, 24 Apr 2020 11:03:54 +0000
Subject: [New-bugs-announce] [issue40376] documentation for os.getgrouplist
 potentially misleading
Message-ID: <1587726234.05.0.711517383833.issue40376@roundup.psfhosted.org>


New submission from Jens Holzk?mper <jens at holzkaemper.berlin>:

https://docs.python.org/3/library/os.html#os.getgrouplist states ?Return list of group ids that user belongs to. If group is not in the list, it is included; typically, group is specified as the group ID field from the password record for user.?, but the function is at least on Linux a wrapper for getgrouplist from the C standard library, which lists only the membership in groups in the group-database. Users can be members of groups without it being declared in the group database, this is often the case with the default group of the user which is only declared in the passwd database.

e.g. 
/etc/passwd: woodfighter:x:1000:1000:,,,:/home/woodfighter:/bin/bash
/etc/group: woodfighter:x:1000:

os.getgrouplist("woodfighter",65534) then doesn't contain group id 1000.

The documentation tries to steer a developer in the right direction with the second sentence but fails to state, that the list will be possibly incomplete otherwise. I would add something like ?, because that group ID will otherwise be potentially omitted.? before the last period.

----------
assignee: docs at python
components: Documentation
messages: 367187
nosy: docs at python, woodfighter
priority: normal
severity: normal
status: open
title: documentation for os.getgrouplist potentially misleading
type: enhancement

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

From report at bugs.python.org  Fri Apr 24 09:25:54 2020
From: report at bugs.python.org (Stephan Troyer)
Date: Fri, 24 Apr 2020 13:25:54 +0000
Subject: [New-bugs-announce] [issue40377] APPDATA location in Microsoft
 Store version
Message-ID: <1587734754.85.0.727792315124.issue40377@roundup.psfhosted.org>


New submission from Stephan Troyer <stephantroyer at live.at>:

In Microsoft Store apps, access to %APPDATA% and %LOCALAPPDATA% gets transparently redirected to an app specific location (such as %LOCALAPPDATA%\Packages\PythonSoftwareFoundation.Python.3.8_qbz5n2kfra8p0\LocalCache\). This is perfect for saving settings etc. of Python scripts and packages, however that doesn't work, when the unredirected paths are returned by a sandboxed Python script and consumed by a 3rd party tool.
One example for the issue created by that is Jupyter, which saves its kernel settings to %appdata% and returns that path when using the command `jupyter kernelspec list`. However other applications which rely on that output can't access the resulting paths (since their file access doesn't get redirected).
Would it make sense to add some API for accessing the UWP APIs ApplicationData.Current.LocalFolder and ApplicationData.Current.RoamingFolder, which provide a folder path, which doesn't get redirected?

Besides, I want to thank everyone involved in the Microsoft Store version of Python!

----------
components: IO
messages: 367188
nosy: stephtr
priority: normal
severity: normal
status: open
title: APPDATA location in Microsoft Store version
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Fri Apr 24 14:18:04 2020
From: report at bugs.python.org (Anthony Sottile)
Date: Fri, 24 Apr 2020 18:18:04 +0000
Subject: [New-bugs-announce] [issue40378] ast.parse fails to trigger
 SyntaxWarning that normal execution does
Message-ID: <1587752284.4.0.62112080929.issue40378@roundup.psfhosted.org>


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

compare the following:

```
if False: 'foo'(1)
```


$ python3.9
Python 3.9.0a5 (default, Mar 23 2020, 23:11:30) 
[GCC 7.5.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import ast
>>> ast.parse(b"if False: 'foo'(1)")
<ast.Module object at 0x7ff87a03cca0>
>>> if False: 'foo'(1)
... 
<stdin>:1: SyntaxWarning: 'str' object is not callable; perhaps you missed a comma?


even with `PYTHONWARNINGS=error` no warning / error is raised

----------
messages: 367207
nosy: Anthony Sottile
priority: normal
severity: normal
status: open
title: ast.parse fails to trigger SyntaxWarning that normal execution does
type: behavior
versions: Python 3.8, Python 3.9

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

From report at bugs.python.org  Fri Apr 24 14:22:23 2020
From: report at bugs.python.org (Itamar Turner-Trauring)
Date: Fri, 24 Apr 2020 18:22:23 +0000
Subject: [New-bugs-announce] [issue40379] multiprocessing's default start
 method of fork()-without-exec() is broken
Message-ID: <1587752543.41.0.119768714545.issue40379@roundup.psfhosted.org>


New submission from Itamar Turner-Trauring <itamar at futurefoundries.com>:

By default, multiprocessing uses fork() without exec() on POSIX. For a variety of reasons this can lead to inconsistent state in subprocesses: module-level globals are copied, which can mess up logging, threads don't survive fork(), etc..

The end results vary, but quite often are silent lockups.

In real world usage, this results in users getting mysterious hangs they do not have the knowledge to debug.

The fix for these people is to use "spawn" by default, which is the default on Windows.

Just a small sample:

1. Today I talked to a scientist who spent two weeks stuck, until she found my article on the subject (https://codewithoutrules.com/2018/09/04/python-multiprocessing/). Basically multiprocessing locked up, doing nothing forever. Switching to "spawn" fixed it.
2. https://github.com/dask/dask/issues/3759#issuecomment-476743555 is someone who had issues fixed by "spawn".
3. https://github.com/numpy/numpy/issues/15973 is a NumPy issue which apparently impacted scikit-learn.


I suggest changing the default on POSIX to match Windows.

----------
messages: 367210
nosy: itamarst
priority: normal
severity: normal
status: open
title: multiprocessing's default start method of fork()-without-exec() is broken
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/issue40379>
_______________________________________

From report at bugs.python.org  Fri Apr 24 15:48:29 2020
From: report at bugs.python.org (Steven Fleck)
Date: Fri, 24 Apr 2020 19:48:29 +0000
Subject: [New-bugs-announce] [issue40380] Errors during make test python
 3.8.2
Message-ID: <1587757709.05.0.540074868271.issue40380@roundup.psfhosted.org>


New submission from Steven Fleck <sjfleck at buffalo.edu>:

I'm having some issues with installing python 3.8.2. I'm installing it in my personal workspace on my university's computing resources (linux). I've installed many programs here, but python is giving me some issues. 

Ultimately, I'm failing 5 tests:
test_multiprocessing_forkserver 
test_pathlib
test_resource
test_socket 
test_zipfie

Any help into what I can do to fix these errors would be greatly appreciated. I've attached a file that has the outputs of each command listed below. I hope it helps

line 0001: ./configure
line 0754: make
line 1238: make test
line 3539: make test TESTOPTS="-v test_multiprocessing_forkserver test_pathlib test_resource test_socket test_zipfie"

----------
components: Installation
files: python_3.8.2_installation.txt
messages: 367215
nosy: Steven Fleck
priority: normal
severity: normal
status: open
title: Errors during make test python 3.8.2
type: compile error
versions: Python 3.8
Added file: https://bugs.python.org/file49090/python_3.8.2_installation.txt

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

From report at bugs.python.org  Fri Apr 24 15:52:32 2020
From: report at bugs.python.org (Clay Caviness)
Date: Fri, 24 Apr 2020 19:52:32 +0000
Subject: [New-bugs-announce] [issue40381] plistlib doesn't handle
 poorly-formatted plists
Message-ID: <1587757952.37.0.0995683897517.issue40381@roundup.psfhosted.org>


New submission from Clay Caviness <clay at boobah.com>:

Some Info.plist files are poorly formatted. I am using plistlib to read Info.plist file from various .app bundles. On some, plistlib.load raises a ValueError when trying to parse.

Examining one of these Info.plist files, it turns out *it* is poorly formatted, but while python's plistlib is unhappy, it passes "plutil -lint" just fine and "Foundation.NSDictionary.dictionaryWithContentsOfFile_" is happy to read it.

Here's a minimal sample plist file:
"""
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
  <key>An array</key>
  <array>
    <string>a string</string>
<key>A wild key appears!</key>
<string>it has a string</string>
    <string>another string</string>
  </array>
</dict>
</plist>
"""

plistlib (correctly, I think) says that's no good. Apple's tooling just ... changes the key to another string in the array and carries on.

I've attached an actual problematic Info.plist as well.

----------
components: Library (Lib)
files: Info.plist
messages: 367217
nosy: Clay Caviness
priority: normal
severity: normal
status: open
title: plistlib doesn't handle poorly-formatted plists
versions: Python 3.7
Added file: https://bugs.python.org/file49091/Info.plist

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

From report at bugs.python.org  Fri Apr 24 16:16:00 2020
From: report at bugs.python.org (Facundo Batista)
Date: Fri, 24 Apr 2020 20:16:00 +0000
Subject: [New-bugs-announce] [issue40382] Make 'rt' the default for open in
 docs
Message-ID: <1587759360.28.0.146955814508.issue40382@roundup.psfhosted.org>


New submission from Facundo Batista <facundo at taniquetil.com.ar>:

This is mostly a confusion about 'r' being a synonym of 'rt', while it's more explicit if we consider 'r' as one default, and 't' as other (as other parts of the documentation do).

Doing `help(open)` we get:

    mode is an optional string that specifies the mode in which the file
    is opened. It defaults to 'r' which means open for reading in text
    mode. 

Later in the same text it's stated:

    The default mode is 'rt' (open for reading text).

Which reflects the wording I want to have, but is confusing that initially it said a different thing.

If we get the html docs, it says "The default mode is 'r' (open for reading text, synonym of 'rt')."
    
Why not just stating that the default mode is 'rt'?

----------
assignee: docs at python
components: Documentation
messages: 367219
nosy: docs at python, facundobatista
priority: normal
severity: normal
stage: needs patch
status: open
title: Make 'rt' the default for open in docs
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Fri Apr 24 23:05:17 2020
From: report at bugs.python.org (OhBonsai)
Date: Sat, 25 Apr 2020 03:05:17 +0000
Subject: [New-bugs-announce] [issue40383] some class name are hardcoded in
 reprs
Message-ID: <1587783917.63.0.137882074418.issue40383@roundup.psfhosted.org>


New submission from OhBonsai <letbonsaibe at gmail.com>:

Same with #21861 #27541

hard-coding in https://github.com/python/cpython/blob/master/Objects/weakrefobject.c#L162  __repr__ 

----- Reproducing
>>> import weakref
>>> class ExtendRef(weakref.ref): pass
... 
>>> class Obj(): pass
... 
>>> eref = ExtendRef(Obj())
>>> eref
<weakref at 0x1046bc520; dead>

----- Expect the subclass name
>>> eref
<ExtendRef at 0x1046bc520; dead>

----------
components: Extension Modules
messages: 367248
nosy: OhBonsai, corona10, taleinat
priority: normal
severity: normal
status: open
title: some class name are hardcoded in reprs
type: enhancement
versions: Python 3.8

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

From report at bugs.python.org  Fri Apr 24 23:29:57 2020
From: report at bugs.python.org (Alex)
Date: Sat, 25 Apr 2020 03:29:57 +0000
Subject: [New-bugs-announce] [issue40384] IDLE: Undesired highlight
Message-ID: <1587785397.11.0.430287508325.issue40384@roundup.psfhosted.org>


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

In this code:

def a():
    #
def
def b():

When I delete the # at line 3, the keyword 'def' become blue.

----------
assignee: terry.reedy
components: IDLE
messages: 367249
nosy: Alex-Python-Programmer, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE: Undesired highlight
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Fri Apr 24 23:32:14 2020
From: report at bugs.python.org (Ammar Askar)
Date: Sat, 25 Apr 2020 03:32:14 +0000
Subject: [New-bugs-announce] [issue40385] Tools/checkpyc.py has been broken
 since PEP 552
Message-ID: <1587785534.8.0.504830740261.issue40385@roundup.psfhosted.org>


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

Looks like checkpyc.py has been broken since PEP 552 was implemented https://github.com/python/cpython/blob/0e80b561d442769631d66f1cc8813ac30f97378e/Tools/scripts/checkpyc.py#L44-L46

It fails to read the 4 bytes for the `flags` field nor does it handle hash based files. 

Considering it's been broken since 2017 and no one has complained, it might be safe to remove this particular script.

----------
components: Demos and Tools
messages: 367250
nosy: ammar2
priority: normal
severity: normal
status: open
title: Tools/checkpyc.py has been broken since PEP 552
type: behavior
versions: Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Fri Apr 24 23:57:29 2020
From: report at bugs.python.org (wyz23x2)
Date: Sat, 25 Apr 2020 03:57:29 +0000
Subject: [New-bugs-announce] [issue40386] Strange behavior during invalid
 import of modules without if __name__ == "__main__"
Message-ID: <1587787049.96.0.282415448462.issue40386@roundup.psfhosted.org>


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

This behavior:

Python 3.8.2 (tags/v3.8.2:7b3ab59, Feb 25 2020, 23:03:10) [MSC v.1916 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license()" for more information.
>>> import this.main
The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!
Traceback (most recent call last):
  File "<pyshell#0>", line 1, in <module>
    import this.main
ModuleNotFoundError: No module named 'this.main'; 'this' is not a package
>>> import this.main
Traceback (most recent call last):
  File "<pyshell#1>", line 1, in <module>
    import this.main
ModuleNotFoundError: No module named 'this.main'; 'this' is not a package
>>> del this
Traceback (most recent call last):
  File "<pyshell#2>", line 1, in <module>
    del this
NameError: name 'this' is not defined
>>> import this
>>>

This confuses users because the code of "this" is un the 1st time, but not the times after it. And "this" isn't actually imported after that; stranger is when you perform the correct import, it doesn't run.

Is this right?

----------
messages: 367253
nosy: wyz23x2
priority: normal
severity: normal
status: open
title: Strange behavior during invalid import of modules without if __name__ == "__main__"

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

From report at bugs.python.org  Sat Apr 25 03:58:55 2020
From: report at bugs.python.org (Santiago Blanco)
Date: Sat, 25 Apr 2020 07:58:55 +0000
Subject: [New-bugs-announce] [issue40387] queue example it does not work
Message-ID: <1587801535.61.0.75411956327.issue40387@roundup.psfhosted.org>


New submission from Santiago Blanco <sblancov84 at gmail.com>:

Copy the example of the next URL:

https://docs.python.org/3/library/queue.html#queue.Queue.join

and paste into a file, then try to run it. It does not work.

I have tried a new one (attachment) that works.

----------
assignee: docs at python
components: Documentation
files: example.py
messages: 367263
nosy: Santiago Blanco, docs at python
priority: normal
severity: normal
status: open
title: queue example it does not work
type: enhancement
versions: Python 3.7, Python 3.8, Python 3.9
Added file: https://bugs.python.org/file49092/example.py

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

From report at bugs.python.org  Sat Apr 25 04:56:27 2020
From: report at bugs.python.org (Nicholas Prowse)
Date: Sat, 25 Apr 2020 08:56:27 +0000
Subject: [New-bugs-announce] [issue40388] random.choice integer overflow
 v3.5.2
Message-ID: <1587804987.95.0.247989027545.issue40388@roundup.psfhosted.org>


New submission from Nicholas Prowse <nick5990 at yahoo.co.uk>:

Filename: random.py
Location of file: /use/lib/python3.5/random.py
Function: random.choice()
Input: 40 digit integer
Expected output: no crash
Actual output: Crash
Line number: 253
Error message: "Python int too large to convert to C ssize_t"

Traceback:
a = random.choice(sequence)
i= self._randbelow(len(seq))

Error occurs on last line 253.

----------
components: Library (Lib)
messages: 367266
nosy: dev00790
priority: normal
severity: normal
status: open
title: random.choice integer overflow v3.5.2
type: crash
versions: Python 3.5

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

From report at bugs.python.org  Sat Apr 25 14:03:02 2020
From: report at bugs.python.org (Vladislav Serebrennikov)
Date: Sat, 25 Apr 2020 18:03:02 +0000
Subject: [New-bugs-announce] [issue40389] No straightforward way to get repr
 of Optional
Message-ID: <1587837782.6.0.0357631726958.issue40389@roundup.psfhosted.org>


New submission from Vladislav Serebrennikov <brainvlad at gmail.com>:

When source code is not available, "typing.Union[T, NoneType]" is what autocompletion engines left with, if they don't have additional logic to cover this case. Which is noisy compared to typing.Optional[T].

Usecase when source code is not available

Consider the following: C++ library has C++ plugins, supplied by user. It provides Python wrappers for their functions, dynamically filling out their type annotations.

----------
components: Library (Lib)
messages: 367278
nosy: Endill
priority: normal
severity: normal
status: open
title: No straightforward way to get repr of Optional
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Sat Apr 25 15:19:24 2020
From: report at bugs.python.org (Benjamin Edwards)
Date: Sat, 25 Apr 2020 19:19:24 +0000
Subject: [New-bugs-announce] [issue40390] Implement a C API for
 channel_send_wait for subinterpreters.
Message-ID: <1587842364.13.0.0340365069537.issue40390@roundup.psfhosted.org>


New submission from Benjamin Edwards <benjaminedwards at live.co.uk>:

When sending a message to another interpreter allow the caller to wait until the message has been received.

----------
components: C API
messages: 367280
nosy: benedwards14, eric.snow
priority: normal
severity: normal
status: open
title: Implement a C API for channel_send_wait for subinterpreters.
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Sat Apr 25 20:50:56 2020
From: report at bugs.python.org (mike.parker)
Date: Sun, 26 Apr 2020 00:50:56 +0000
Subject: [New-bugs-announce] [issue40391] io.FileIO.mode doesn't comply with
 the docs
Message-ID: <1587862256.98.0.383192510406.issue40391@roundup.psfhosted.org>


New submission from mike.parker <mike.parker-3ob7b3hc at yopmail.com>:

io.FileIO.mode doesn't reflect "The mode as given in the constructor." as per the documentation(https://docs.python.org/3/library/io.html#io.FileIO.mode).
Was noted in issue4362, but seems to be still relevant.

Example:
>>> f = open("t.tmp", "w+b")
>>> f.mode
'rb+'

----------
assignee: docs at python
components: Documentation, IO
messages: 367288
nosy: benjamin.peterson, docs at python, mike.parker, stutzbach
priority: normal
severity: normal
status: open
title: io.FileIO.mode doesn't comply with the docs
type: behavior
versions: Python 3.7

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

From report at bugs.python.org  Sun Apr 26 02:17:53 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 26 Apr 2020 06:17:53 +0000
Subject: [New-bugs-announce] [issue40392] Remove deprecated _field_types in
 typing.NamedTuple
Message-ID: <1587881873.08.0.712123124267.issue40392@roundup.psfhosted.org>


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

_field_types of typing.NamedTuple was documented as deprecated and to be removed in Python 3.9 in favor of __annotations__ at https://docs.python.org/3/library/typing.html#typing.NamedTuple . Issue where it was deprecated : issue36320 .

----------
components: Library (Lib)
messages: 367302
nosy: josh.r, levkivskyi, rhettinger, serhiy.storchaka, xtreak
priority: normal
severity: normal
status: open
title: Remove deprecated _field_types in typing.NamedTuple
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Sun Apr 26 05:36:21 2020
From: report at bugs.python.org (J Arun Mani)
Date: Sun, 26 Apr 2020 09:36:21 +0000
Subject: [New-bugs-announce] [issue40393] Auto-response from Python Help
 points to Python 2 reference
Message-ID: <1587893781.17.0.655976493189.issue40393@roundup.psfhosted.org>


New submission from J Arun Mani <j.arunmani at protonmail.com>:

In the auto-response sent by python-help-bounces at python.org, at some intermediate paragraphs:
...
The most comprehensive overview of python.org help resources is at

	http://www.python.org/about/help/

The Python FAQ is available at

        http://docs.python.org/2/faq/index.html

and it has answers to many questions that people ask, possibly...

The link : http://docs.python.org/2/faq/index.html points to Python 2 resources, please change it to point Python 3 FAQ, i.e. https://docs.python.org/3/faq/index.html

The `http` in links can also be changed to `https. It doesn't help anyway as the link automatically takes to `https` sites.
Thanks.

----------
components: email
messages: 367305
nosy: J Arun Mani, barry, r.david.murray
priority: normal
severity: normal
status: open
title: Auto-response from Python Help points to Python 2 reference
type: enhancement

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

From report at bugs.python.org  Sun Apr 26 10:15:58 2020
From: report at bugs.python.org (Lewis Ball)
Date: Sun, 26 Apr 2020 14:15:58 +0000
Subject: [New-bugs-announce] [issue40394]
 difflib.SequenceMatcher.find_longest_match default arguments
Message-ID: <1587910558.56.0.865649390619.issue40394@roundup.psfhosted.org>


New submission from Lewis Ball <lrjball at gmail.com>:

The usage of difflib.SequenceMatcher.find_longest_match could be simplified for the most common use case (finding the longest match between the entirety of the two strings) by taking default args.

At the moment you have to do:

>>> from difflib import SequenceMatcher
>>> a, b = 'foo bar', 'foo baz'
>>> s = SequenceMatcher(a=a, b=b)
>>> s.find_longest_match(0, len(a), 0, len(b))
Match(a=0, b=0, size=6)

but with default args the final line could be simplified to just:

>>> s.find_longest_match()
Match(a=0, b=0, size=6)

which seems to be much cleaned and more readable.


I'd suggest updating the code so that the function signature becomes:

find_longest_match(alo=None, ahi=None, blo=None, bhi=None)

which is consistent with the current docstring of "Find longest matching block in a[alo:ahi] and b[blo:bhi]." as `a[None:None]` is the whole of `a`.

I think this would only be a minor code change, and if it is something that would be useful I'd be happy to have a go at a PR.

----------
components: Library (Lib)
messages: 367306
nosy: Lewis Ball
priority: normal
severity: normal
status: open
title: difflib.SequenceMatcher.find_longest_match default arguments
type: enhancement

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

From report at bugs.python.org  Sun Apr 26 10:18:10 2020
From: report at bugs.python.org (BenTen Jan)
Date: Sun, 26 Apr 2020 14:18:10 +0000
Subject: [New-bugs-announce] [issue40395] Scripts folder is Empty in python
 3.8.2 for Windows 7.
Message-ID: <1587910690.73.0.0218819691356.issue40395@roundup.psfhosted.org>


New submission from BenTen Jan <bentenjan365 at gmail.com>:

I downloaded python 3.8.2 which is the latest version of python for windows. Run as admin , changed path of installation though its getting  empty Scripts folder. though setup shows successful.

Please find attached log files from my %temp% folder.

Thanks Regards
Ben

----------
components: Installation
files: Installation Log.zip
messages: 367307
nosy: BenTen Jan
priority: normal
severity: normal
status: open
title: Scripts folder is Empty in python 3.8.2 for Windows 7.
versions: Python 3.8
Added file: https://bugs.python.org/file49093/Installation Log.zip

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

From report at bugs.python.org  Sun Apr 26 12:02:57 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 26 Apr 2020 16:02:57 +0000
Subject: [New-bugs-announce] [issue40396] Support GenericAlias in typing
Message-ID: <1587916977.12.0.758725068649.issue40396@roundup.psfhosted.org>


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

Currently typing functions get_origin(), get_args() and get_type_hints() do not support GenericAlias.

>>> from typing import *
>>> get_origin(List[int])
<class 'list'>
>>> get_origin(list[int])
>>> get_args(List[int])
(<class 'int'>,)
>>> get_args(list[int])
()
>>> def foo(x: List[ForwardRef('X')], y: list[ForwardRef('X')]) -> None: ...                                                                                                                                                                 
...                                                                                                                                                                                                                                          
>>> class X: ...
... 
>>> get_type_hints(foo)
{'x': typing.List[__main__.X], 'y': list[ForwardRef('X')], 'return': <class 'NoneType'>}

The proposed PR fixes this.

----------
components: Library (Lib)
messages: 367308
nosy: gvanrossum, levkivskyi, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Support GenericAlias in typing
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Sun Apr 26 12:35:15 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 26 Apr 2020 16:35:15 +0000
Subject: [New-bugs-announce] [issue40397] Refactor typing._GenericAlias
Message-ID: <1587918915.07.0.818996162208.issue40397@roundup.psfhosted.org>


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

typing._GenericAlias represents two different types: user defined (like List[int]) and special (like List). They have different behavior, and common methods contain special cases.

The proposed PR rewrites the implementation in more object-oriented paradigm: different classes for different behavior. _GenericAlias is split on three classes: user defined (it may be replaced with GenericAlias in future), special, and the base class for common methods. Its subclasses are also split on classes for special types Tuple and Callable and for parametrized Callable[] and Annotated[]. The work is not finished yet and the code is still complex.

----------
components: Library (Lib)
messages: 367312
nosy: gvanrossum, levkivskyi, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Refactor typing._GenericAlias
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Sun Apr 26 12:46:07 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 26 Apr 2020 16:46:07 +0000
Subject: [New-bugs-announce] [issue40398] get_args(Callable) fails
Message-ID: <1587919567.44.0.458722941462.issue40398@roundup.psfhosted.org>


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

>>> from typing import *
>>> get_args(Callable)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/serhiy/py/cpython/Lib/typing.py", line 1412, in get_args
    if get_origin(tp) is collections.abc.Callable and res[0] is not Ellipsis:
IndexError: tuple index out of range

What is the correct behavior?

----------
components: Library (Lib)
messages: 367313
nosy: gvanrossum, levkivskyi, serhiy.storchaka
priority: normal
severity: normal
status: open
title: get_args(Callable) fails
type: behavior
versions: Python 3.8, Python 3.9

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

From report at bugs.python.org  Sun Apr 26 12:58:22 2020
From: report at bugs.python.org (Delgan)
Date: Sun, 26 Apr 2020 16:58:22 +0000
Subject: [New-bugs-announce] [issue40399] Program hangs if process created
 right after adding object to a Queue
Message-ID: <1587920302.07.0.276002968457.issue40399@roundup.psfhosted.org>


New submission from Delgan <delgan.py at gmail.com>:

Hi.

I have a very basic program:
- one multiprocessing SimpleQueue
- one consumer thread
- one loop:
  - add one item to the queue
  - create a new process with itself add one item to the queue
  - wait for the process to end

For some unknown reason, it will hangs after some time. 

I know the docs said:

> This means that if you try joining that process you may get a deadlock unless you are sure that all items which have been put on the queue have been consumed. Similarly, if the child process is non-daemonic then the parent process may hang on exit when it tries to join all its non-daemonic children.

That's why I added "time.sleep(1)" inside the process, to make sure all items added by the child process are consumed. You can remove it and the hang will happen faster.


I'm using Python 3.8.2 on Linux. Forcing program to terminate with Ctrl+C (twice):

^CTraceback (most recent call last):
  File "bug.py", line 23, in <module>
    p.join()
  File "/usr/lib/python3.8/multiprocessing/process.py", line 149, in join
    res = self._popen.wait(timeout)
  File "/usr/lib/python3.8/multiprocessing/popen_fork.py", line 47, in wait
    return self.poll(os.WNOHANG if timeout == 0.0 else 0)
  File "/usr/lib/python3.8/multiprocessing/popen_fork.py", line 27, in poll
    pid, sts = os.waitpid(self.pid, flag)
KeyboardInterrupt
^CError in atexit._run_exitfuncs:
Traceback (most recent call last):
  File "/usr/lib/python3.8/multiprocessing/popen_fork.py", line 27, in poll
    pid, sts = os.waitpid(self.pid, flag)
KeyboardInterrupt

----------
components: Library (Lib)
files: bug.py
messages: 367317
nosy: Delgan
priority: normal
severity: normal
status: open
title: Program hangs if process created right after adding object to a Queue
type: behavior
versions: Python 3.8
Added file: https://bugs.python.org/file49094/bug.py

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

From report at bugs.python.org  Sun Apr 26 14:17:18 2020
From: report at bugs.python.org (h2a10)
Date: Sun, 26 Apr 2020 18:17:18 +0000
Subject: [New-bugs-announce] [issue40400] Mac build-installer.py doesn't
 support new plist format
Message-ID: <1587925038.05.0.935755179102.issue40400@roundup.psfhosted.org>


New submission from h2a10 <arieff.family at gmail.com>:

when you run cpython/Mac/BuildScript/build-installer.py with python 3.9.0 it failed with the following error
 from plistlib import Plist
ImportError: cannot import name 'Plist' from 'plistlib'

----------
components: macOS
messages: 367325
nosy: h2a10, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: Mac build-installer.py doesn't support new plist format
type: compile error
versions: Python 3.9

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

From report at bugs.python.org  Sun Apr 26 19:53:07 2020
From: report at bugs.python.org (Ammar Askar)
Date: Sun, 26 Apr 2020 23:53:07 +0000
Subject: [New-bugs-announce] [issue40401] pythoncore.vcxproj fails to load
 due to duplicated "..\Include\pyhash.h"
Message-ID: <1587945187.18.0.146744366129.issue40401@roundup.psfhosted.org>


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

The pythoncore project currently fails to load in Visual Studio with:

    cpython\PCbuild\pythoncore.vcxproj : error  : Cannot load project with duplicated project items: ..\Include\pyhash.h is included as 'ClInclude' and as 'ClInclude' item types. 


Looks like https://github.com/python/cpython/commit/c5fc15685202cda73f7c3f5c6f299b0945f58508#diff-fc48a1700be0140b57a172ea101297de accidentally introduced a duplicate for "..\Include\pyhash.h"

----------
components: Windows
messages: 367334
nosy: ammar2, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: pythoncore.vcxproj fails to load due to duplicated "..\Include\pyhash.h"
type: compile error
versions: Python 3.9

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

From report at bugs.python.org  Sun Apr 26 22:31:49 2020
From: report at bugs.python.org (Maxi)
Date: Mon, 27 Apr 2020 02:31:49 +0000
Subject: [New-bugs-announce] [issue40402] multiprocessing/connection.py
 broken handle
Message-ID: <1587954709.44.0.390905431083.issue40402@roundup.psfhosted.org>


New submission from Maxi <maxicooper at protonmail.com>:

## Sorry if this is not properly created, my first time here ##

I'm experiencing random Exceptions originating in multiprocessing/connection.py:368 where the handle seems to be broken:

Apr 25 19:39:44 app python[26282]:   File "/usr/lib/python3.5/multiprocessing/managers.py", line 716, in _callmethod
Apr 25 19:39:44 app python[26282]:     conn.send((self._id, methodname, args, kwds))
Apr 25 19:39:44 app python[26282]:   File "/usr/lib/python3.5/multiprocessing/connection.py", line 206, in send
Apr 25 19:39:44 app python[26282]:     self._send_bytes(ForkingPickler.dumps(obj))
Apr 25 19:39:44 app python[26282]:   File "/usr/lib/python3.5/multiprocessing/connection.py", line 404, in _send_bytes
Apr 25 19:39:44 app python[26282]:     self._send(header + buf)
Apr 25 19:39:44 app python[26282]:   File "/usr/lib/python3.5/multiprocessing/connection.py", line 368, in _send
Apr 25 19:39:44 app python[26282]:     n = write(self._handle, buf)
Apr 25 19:39:44 app python[26282]: TypeError: an integer is required (got type NoneType)

Not sure if there is something wrong at OS level, but I think a self._check_closed() before that line would help.

----------
messages: 367355
nosy: maxicooper
priority: normal
severity: normal
status: open
title: multiprocessing/connection.py broken handle
type: crash
versions: Python 3.5

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

From report at bugs.python.org  Sun Apr 26 23:07:36 2020
From: report at bugs.python.org (Kerrick Staley)
Date: Mon, 27 Apr 2020 03:07:36 +0000
Subject: [New-bugs-announce] [issue40403] pdb does not drop into debugger
 upon SyntaxError caused by ast.literal_eval
Message-ID: <1587956856.04.0.83965486478.issue40403@roundup.psfhosted.org>


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

Summary:
When you call ast.literal_eval on a string that does not contain valid Python code, it raises a SyntaxError. This causes pdb to exit instead of stopping execution at the point that the SyntaxError was raised.

To reproduce:
1. Create a Python file foo.py with these contents:

    import ast
    ast.literal_eval('')

2. Run python -m pdb foo.py
3. Type 'c' and hit enter.

Expected behavior:
pdb drops into a shell in ast.py at the point where the SyntaxError occurred.

Actual behavior:
The program exits, and a SyntaxError traceback is displayed.

System configuration:
Python 3.8.2 on Arch Linux.

----------
components: Library (Lib)
messages: 367363
nosy: Kerrick Staley
priority: normal
severity: normal
status: open
title: pdb does not drop into debugger upon SyntaxError caused by ast.literal_eval
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Mon Apr 27 00:24:31 2020
From: report at bugs.python.org (Joseph)
Date: Mon, 27 Apr 2020 04:24:31 +0000
Subject: [New-bugs-announce] [issue40404] Python quit unexpectedly
Message-ID: <1587961471.91.0.139904517244.issue40404@roundup.psfhosted.org>


New submission from Joseph <drjosephliu at gmail.com>:

Process:               Python [91080]
Path:                  /usr/local/Cellar/python/3.7.7/Frameworks/Python.framework/Versions/3.7/Resources/Python.app/Contents/MacOS/Python
Identifier:            Python
Version:               3.7.7 (3.7.7)
Code Type:             X86-64 (Native)
Parent Process:        bash [87533]
User ID:               501

Date/Time:             2020-04-27 11:30:31.044 +0800
OS Version:            Mac OS X 10.15.4 (19E287)
Report Version:        12
Bridge OS Version:     4.4 (17P4281)
Anonymous UUID:        2D923F70-DF15-0C75-5925-921AC7A6B975

Sleep/Wake UUID:       54C528EC-278D-4E97-9EA5-75A516A5B4EA

Time Awake Since Boot: 430000 seconds
Time Since Wake:       4500 seconds

System Integrity Protection: enabled

Crashed Thread:        0  Dispatch queue: com.apple.main-thread

Exception Type:        EXC_CRASH (SIGQUIT)
Exception Codes:       0x0000000000000000, 0x0000000000000000
Exception Note:        EXC_CORPSE_NOTIFY

Termination Signal:    Quit: 3
Termination Reason:    Namespace SIGNAL, Code 0x3
Terminating Process:   tmux [3601]

Application Specific Information:
dyld: in dlopen()

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   dyld                          	0x000000011591f899 ImageLoader::trieWalk(unsigned char const*, unsigned char const*, char const*) + 177
1   dyld                          	0x0000000115929410 ImageLoaderMachOCompressed::findShallowExportedSymbol(char const*, ImageLoader const**) const + 112
2   dyld                          	0x0000000115923085 ImageLoaderMachO::findExportedSymbol(char const*, bool, char const*, ImageLoader const**) const + 37
3   dyld                          	0x000000011591e513 ImageLoader::weakBindOld(ImageLoader::LinkContext const&) + 1485
4   dyld                          	0x000000011591c1ef ImageLoader::link(ImageLoader::LinkContext const&, bool, bool, bool, ImageLoader::RPathChain const&, char const*) + 333
5   dyld                          	0x000000011590e93f dyld::link(ImageLoader*, bool, bool, ImageLoader::RPathChain const&, unsigned int) + 161
6   dyld                          	0x0000000115918d77 dlopen_internal + 477
7   libdyld.dylib                 	0x00007fff7043dd8a dlopen + 171
8   org.python.python             	0x000000010c9eef11 _PyImport_FindSharedFuncptr + 301
9   org.python.python             	0x000000010c9cdd7a _PyImport_LoadDynamicModuleWithSpec + 495
10  org.python.python             	0x000000010c9cd8f0 _imp_create_dynamic + 309
11  org.python.python             	0x000000010c922b0e _PyMethodDef_RawFastCallDict + 549
12  org.python.python             	0x000000010c92211f _PyCFunction_FastCallDict + 41
13  org.python.python             	0x000000010c9b0e12 _PyEval_EvalFrameDefault + 7738
14  org.python.python             	0x000000010c9b82cd _PyEval_EvalCodeWithName + 1698
15  org.python.python             	0x000000010c922424 _PyFunction_FastCallKeywords + 212
16  org.python.python             	0x000000010c9b7ad9 call_function + 737
17  org.python.python             	0x000000010c9b0a47 _PyEval_EvalFrameDefault + 6767
18  org.python.python             	0x000000010c922830 function_code_fastcall + 106
19  org.python.python             	0x000000010c9b7ad9 call_function + 737
20  org.python.python             	0x000000010c9b0a2e _PyEval_EvalFrameDefault + 6742
21  org.python.python             	0x000000010c922830 function_code_fastcall + 106
22  org.python.python             	0x000000010c9b7ad9 call_function + 737
23  org.python.python             	0x000000010c9b0ae2 _PyEval_EvalFrameDefault + 6922
24  org.python.python             	0x000000010c922830 function_code_fastcall + 106
25  org.python.python             	0x000000010c9b7ad9 call_function + 737
26  org.python.python             	0x000000010c9b0ae2 _PyEval_EvalFrameDefault + 6922
27  org.python.python             	0x000000010c922830 function_code_fastcall + 106
28  org.python.python             	0x000000010c9b7ad9 call_function + 737
29  org.python.python             	0x000000010c9b0ae2 _PyEval_EvalFrameDefault + 6922
30  org.python.python             	0x000000010c9b82cd _PyEval_EvalCodeWithName + 1698
31  org.python.python             	0x000000010c922424 _PyFunction_FastCallKeywords + 212
32  org.python.python             	0x000000010c9b7ad9 call_function + 737
33  org.python.python             	0x000000010c9b0ae2 _PyEval_EvalFrameDefault + 6922
34  org.python.python             	0x000000010c922830 function_code_fastcall + 106
35  org.python.python             	0x000000010c9b7ad9 call_function + 737
36  org.python.python             	0x000000010c9b0a47 _PyEval_EvalFrameDefault + 6767
37  org.python.python             	0x000000010c922830 function_code_fastcall + 106
38  org.python.python             	0x000000010c9b7ad9 call_function + 737
39  org.python.python             	0x000000010c9b0ae2 _PyEval_EvalFrameDefault + 6922
40  org.python.python             	0x000000010c9b82cd _PyEval_EvalCodeWithName + 1698
41  org.python.python             	0x000000010c9aef35 PyEval_EvalCode + 51
42  org.python.python             	0x000000010c9ac9bf builtin_exec + 563
43  org.python.python             	0x000000010c922b0e _PyMethodDef_RawFastCallDict + 549
44  org.python.python             	0x000000010c92211f _PyCFunction_FastCallDict + 41
45  org.python.python             	0x000000010c9b0e12 _PyEval_EvalFrameDefault + 7738
46  org.python.python             	0x000000010c9b82cd _PyEval_EvalCodeWithName + 1698
47  org.python.python             	0x000000010c922424 _PyFunction_FastCallKeywords + 212
48  org.python.python             	0x000000010c9b7ad9 call_function + 737
49  org.python.python             	0x000000010c9b0a47 _PyEval_EvalFrameDefault + 6767
50  org.python.python             	0x000000010c922830 function_code_fastcall + 106
51  org.python.python             	0x000000010c9b7ad9 call_function + 737
52  org.python.python             	0x000000010c9b0a2e _PyEval_EvalFrameDefault + 6742
53  org.python.python             	0x000000010c922830 function_code_fastcall + 106
54  org.python.python             	0x000000010c9b7ad9 call_function + 737
55  org.python.python             	0x000000010c9b0ae2 _PyEval_EvalFrameDefault + 6922
56  org.python.python             	0x000000010c922830 function_code_fastcall + 106
57  org.python.python             	0x000000010c9b7ad9 call_function + 737
58  org.python.python             	0x000000010c9b0ae2 _PyEval_EvalFrameDefault + 6922
59  org.python.python             	0x000000010c922830 function_code_fastcall + 106
60  org.python.python             	0x000000010c923bde object_vacall + 267
61  org.python.python             	0x000000010c923cdd _PyObject_CallMethodIdObjArgs + 168
62  org.python.python             	0x000000010c9ccb2b PyImport_ImportModuleLevelObject + 1490
63  org.python.python             	0x000000010c9b5659 _PyEval_EvalFrameDefault + 26241
64  org.python.python             	0x000000010c9b82cd _PyEval_EvalCodeWithName + 1698
65  org.python.python             	0x000000010c9aef35 PyEval_EvalCode + 51
66  org.python.python             	0x000000010c9ac9bf builtin_exec + 563
67  org.python.python             	0x000000010c922b0e _PyMethodDef_RawFastCallDict + 549
68  org.python.python             	0x000000010c92211f _PyCFunction_FastCallDict + 41
69  org.python.python             	0x000000010c9b0e12 _PyEval_EvalFrameDefault + 7738
70  org.python.python             	0x000000010c9b82cd _PyEval_EvalCodeWithName + 1698
71  org.python.python             	0x000000010c922424 _PyFunction_FastCallKeywords + 212
72  org.python.python             	0x000000010c9b7ad9 call_function + 737
73  org.python.python             	0x000000010c9b0a47 _PyEval_EvalFrameDefault + 6767
74  org.python.python             	0x000000010c922830 function_code_fastcall + 106
75  org.python.python             	0x000000010c9b7ad9 call_function + 737
76  org.python.python             	0x000000010c9b0a2e _PyEval_EvalFrameDefault + 6742
77  org.python.python             	0x000000010c922830 function_code_fastcall + 106
78  org.python.python             	0x000000010c9b7ad9 call_function + 737
79  org.python.python             	0x000000010c9b0ae2 _PyEval_EvalFrameDefault + 6922
80  org.python.python             	0x000000010c922830 function_code_fastcall + 106
81  org.python.python             	0x000000010c9b7ad9 call_function + 737
82  org.python.python             	0x000000010c9b0ae2 _PyEval_EvalFrameDefault + 6922
83  org.python.python             	0x000000010c922830 function_code_fastcall + 106
84  org.python.python             	0x000000010c923bde object_vacall + 267
85  org.python.python             	0x000000010c923cdd _PyObject_CallMethodIdObjArgs + 168
86  org.python.python             	0x000000010c9ccb2b PyImport_ImportModuleLevelObject + 1490
87  org.python.python             	0x000000010c9abf7a builtin___import__ + 122
88  org.python.python             	0x000000010c9226fe PyCFunction_Call + 208
89  org.python.python             	0x000000010c9b0e12 _PyEval_EvalFrameDefault + 7738
90  org.python.python             	0x000000010c9b82cd _PyEval_EvalCodeWithName + 1698
91  org.python.python             	0x000000010c922424 _PyFunction_FastCallKeywords + 212
92  org.python.python             	0x000000010c9b7ad9 call_function + 737
93  org.python.python             	0x000000010c9b0ae2 _PyEval_EvalFrameDefault + 6922
94  org.python.python             	0x000000010c9b82cd _PyEval_EvalCodeWithName + 1698
95  org.python.python             	0x000000010c92209c _PyFunction_FastCallDict + 444
96  org.python.python             	0x000000010c923bde object_vacall + 267
97  org.python.python             	0x000000010c923cdd _PyObject_CallMethodIdObjArgs + 168
98  org.python.python             	0x000000010c9ccc47 PyImport_ImportModuleLevelObject + 1774
99  org.python.python             	0x000000010c9b5659 _PyEval_EvalFrameDefault + 26241
100 org.python.python             	0x000000010c9b82cd _PyEval_EvalCodeWithName + 1698
101 org.python.python             	0x000000010c9aef35 PyEval_EvalCode + 51
102 org.python.python             	0x000000010c9ac9bf builtin_exec + 563
103 org.python.python             	0x000000010c922b0e _PyMethodDef_RawFastCallDict + 549
104 org.python.python             	0x000000010c92211f _PyCFunction_FastCallDict + 41
105 org.python.python             	0x000000010c9b0e12 _PyEval_EvalFrameDefault + 7738
106 org.python.python             	0x000000010c9b82cd _PyEval_EvalCodeWithName + 1698
107 org.python.python             	0x000000010c922424 _PyFunction_FastCallKeywords + 212
108 org.python.python             	0x000000010c9b7ad9 call_function + 737
109 org.python.python             	0x000000010c9b0a47 _PyEval_EvalFrameDefault + 6767
110 org.python.python             	0x000000010c922830 function_code_fastcall + 106
111 org.python.python             	0x000000010c9b7ad9 call_function + 737
112 org.python.python             	0x000000010c9b0a2e _PyEval_EvalFrameDefault + 6742
113 org.python.python             	0x000000010c922830 function_code_fastcall + 106
114 org.python.python             	0x000000010c9b7ad9 call_function + 737
115 org.python.python             	0x000000010c9b0ae2 _PyEval_EvalFrameDefault + 6922
116 org.python.python             	0x000000010c922830 function_code_fastcall + 106
117 org.python.python             	0x000000010c9b7ad9 call_function + 737
118 org.python.python             	0x000000010c9b0ae2 _PyEval_EvalFrameDefault + 6922
119 org.python.python             	0x000000010c922830 function_code_fastcall + 106
120 org.python.python             	0x000000010c9b7ad9 call_function + 737
121 org.python.python             	0x000000010c9b0ae2 _PyEval_EvalFrameDefault + 6922
122 org.python.python             	0x000000010c9b82cd _PyEval_EvalCodeWithName + 1698
123 org.python.python             	0x000000010c922424 _PyFunction_FastCallKeywords + 212
124 org.python.python             	0x000000010c9b7ad9 call_function + 737
125 org.python.python             	0x000000010c9b0a47 _PyEval_EvalFrameDefault + 6767
126 org.python.python             	0x000000010c9b82cd _PyEval_EvalCodeWithName + 1698
127 org.python.python             	0x000000010c922424 _PyFunction_FastCallKeywords + 212
128 org.python.python             	0x000000010c9b7ad9 call_function + 737
129 org.python.python             	0x000000010c9b0a47 _PyEval_EvalFrameDefault + 6767
130 org.python.python             	0x000000010c922830 function_code_fastcall + 106
131 org.python.python             	0x000000010c9b7ad9 call_function + 737
132 org.python.python             	0x000000010c9b0a47 _PyEval_EvalFrameDefault + 6767
133 org.python.python             	0x000000010c922830 function_code_fastcall + 106
134 org.python.python             	0x000000010c9231a3 _PyObject_Call_Prepend + 131
135 org.python.python             	0x000000010c921e77 _PyObject_FastCallDict + 264
136 org.python.python             	0x000000010c923bde object_vacall + 267
137 org.python.python             	0x000000010c923d9d PyObject_CallFunctionObjArgs + 128
138 org.python.python             	0x000000010c962d62 call_attribute + 64
139 org.python.python             	0x000000010c95fdb7 slot_tp_getattr_hook + 288
140 org.python.python             	0x000000010c9b52b6 _PyEval_EvalFrameDefault + 25310
141 org.python.python             	0x000000010c922830 function_code_fastcall + 106
142 org.python.python             	0x000000010c9b7ad9 call_function + 737
143 org.python.python             	0x000000010c9b0ae2 _PyEval_EvalFrameDefault + 6922
144 org.python.python             	0x000000010c922830 function_code_fastcall + 106
145 org.python.python             	0x000000010c923bde object_vacall + 267
146 org.python.python             	0x000000010c923cdd _PyObject_CallMethodIdObjArgs + 168
147 org.python.python             	0x000000010c9ccb2b PyImport_ImportModuleLevelObject + 1490
148 org.python.python             	0x000000010c9b5659 _PyEval_EvalFrameDefault + 26241
149 org.python.python             	0x000000010c9b82cd _PyEval_EvalCodeWithName + 1698
150 org.python.python             	0x000000010c9aef35 PyEval_EvalCode + 51
151 org.python.python             	0x000000010c9ac9bf builtin_exec + 563
152 org.python.python             	0x000000010c922b0e _PyMethodDef_RawFastCallDict + 549
153 org.python.python             	0x000000010c92211f _PyCFunction_FastCallDict + 41
154 org.python.python             	0x000000010c9b0e12 _PyEval_EvalFrameDefault + 7738
155 org.python.python             	0x000000010c9b82cd _PyEval_EvalCodeWithName + 1698
156 org.python.python             	0x000000010c922424 _PyFunction_FastCallKeywords + 212
157 org.python.python             	0x000000010c9b7ad9 call_function + 737
158 org.python.python             	0x000000010c9b0a47 _PyEval_EvalFrameDefault + 6767
159 org.python.python             	0x000000010c922830 function_code_fastcall + 106
160 org.python.python             	0x000000010c9b7ad9 call_function + 737
161 org.python.python             	0x000000010c9b0a2e _PyEval_EvalFrameDefault + 6742
162 org.python.python             	0x000000010c922830 function_code_fastcall + 106
163 org.python.python             	0x000000010c9b7ad9 call_function + 737
164 org.python.python             	0x000000010c9b0ae2 _PyEval_EvalFrameDefault + 6922
165 org.python.python             	0x000000010c922830 function_code_fastcall + 106
166 org.python.python             	0x000000010c9b7ad9 call_function + 737
167 org.python.python             	0x000000010c9b0ae2 _PyEval_EvalFrameDefault + 6922
168 org.python.python             	0x000000010c922830 function_code_fastcall + 106
169 org.python.python             	0x000000010c923bde object_vacall + 267
170 org.python.python             	0x000000010c923cdd _PyObject_CallMethodIdObjArgs + 168
171 org.python.python             	0x000000010c9ccb2b PyImport_ImportModuleLevelObject + 1490
172 org.python.python             	0x000000010c9b5659 _PyEval_EvalFrameDefault + 26241
173 org.python.python             	0x000000010c9b82cd _PyEval_EvalCodeWithName + 1698
174 org.python.python             	0x000000010c9aef35 PyEval_EvalCode + 51
175 org.python.python             	0x000000010c9ac9bf builtin_exec + 563
176 org.python.python             	0x000000010c922b0e _PyMethodDef_RawFastCallDict + 549
177 org.python.python             	0x000000010c92211f _PyCFunction_FastCallDict + 41
178 org.python.python             	0x000000010c9b0e12 _PyEval_EvalFrameDefault + 7738
179 org.python.python             	0x000000010c9b82cd _PyEval_EvalCodeWithName + 1698
180 org.python.python             	0x000000010c922424 _PyFunction_FastCallKeywords + 212
181 org.python.python             	0x000000010c9b7ad9 call_function + 737
182 org.python.python             	0x000000010c9b0a47 _PyEval_EvalFrameDefault + 6767
183 org.python.python             	0x000000010c922830 function_code_fastcall + 106
184 org.python.python             	0x000000010c9b7ad9 call_function + 737
185 org.python.python             	0x000000010c9b0a2e _PyEval_EvalFrameDefault + 6742
186 org.python.python             	0x000000010c922830 function_code_fastcall + 106
187 org.python.python             	0x000000010c9b7ad9 call_function + 737
188 org.python.python             	0x000000010c9b0ae2 _PyEval_EvalFrameDefault + 6922
189 org.python.python             	0x000000010c922830 function_code_fastcall + 106
190 org.python.python             	0x000000010c9b7ad9 call_function + 737
191 org.python.python             	0x000000010c9b0ae2 _PyEval_EvalFrameDefault + 6922
192 org.python.python             	0x000000010c922830 function_code_fastcall + 106
193 org.python.python             	0x000000010c923bde object_vacall + 267
194 org.python.python             	0x000000010c923cdd _PyObject_CallMethodIdObjArgs + 168
195 org.python.python             	0x000000010c9ccb2b PyImport_ImportModuleLevelObject + 1490
196 org.python.python             	0x000000010c9b5659 _PyEval_EvalFrameDefault + 26241
197 org.python.python             	0x000000010c9b82cd _PyEval_EvalCodeWithName + 1698
198 org.python.python             	0x000000010c9aef35 PyEval_EvalCode + 51
199 org.python.python             	0x000000010c9ac9bf builtin_exec + 563
200 org.python.python             	0x000000010c922b0e _PyMethodDef_RawFastCallDict + 549
201 org.python.python             	0x000000010c92211f _PyCFunction_FastCallDict + 41
202 org.python.python             	0x000000010c9b0e12 _PyEval_EvalFrameDefault + 7738
203 org.python.python             	0x000000010c9b82cd _PyEval_EvalCodeWithName + 1698
204 org.python.python             	0x000000010c922424 _PyFunction_FastCallKeywords + 212
205 org.python.python             	0x000000010c9b7ad9 call_function + 737
206 org.python.python             	0x000000010c9b0a47 _PyEval_EvalFrameDefault + 6767
207 org.python.python             	0x000000010c922830 function_code_fastcall + 106
208 org.python.python             	0x000000010c9b7ad9 call_function + 737
209 org.python.python             	0x000000010c9b0a2e _PyEval_EvalFrameDefault + 6742
210 org.python.python             	0x000000010c922830 function_code_fastcall + 106
211 org.python.python             	0x000000010c9b7ad9 call_function + 737
212 org.python.python             	0x000000010c9b0ae2 _PyEval_EvalFrameDefault + 6922
213 org.python.python             	0x000000010c922830 function_code_fastcall + 106
214 org.python.python             	0x000000010c9b7ad9 call_function + 737
215 org.python.python             	0x000000010c9b0ae2 _PyEval_EvalFrameDefault + 6922
216 org.python.python             	0x000000010c922830 function_code_fastcall + 106
217 org.python.python             	0x000000010c923bde object_vacall + 267
218 org.python.python             	0x000000010c923cdd _PyObject_CallMethodIdObjArgs + 168
219 org.python.python             	0x000000010c9ccb2b PyImport_ImportModuleLevelObject + 1490
220 org.python.python             	0x000000010c9b5659 _PyEval_EvalFrameDefault + 26241
221 org.python.python             	0x000000010c9b82cd _PyEval_EvalCodeWithName + 1698
222 org.python.python             	0x000000010c9aef35 PyEval_EvalCode + 51
223 org.python.python             	0x000000010c9ac9bf builtin_exec + 563
224 org.python.python             	0x000000010c922b0e _PyMethodDef_RawFastCallDict + 549
225 org.python.python             	0x000000010c92211f _PyCFunction_FastCallDict + 41
226 org.python.python             	0x000000010c9b0e12 _PyEval_EvalFrameDefault + 7738
227 org.python.python             	0x000000010c9b82cd _PyEval_EvalCodeWithName + 1698
228 org.python.python             	0x000000010c922424 _PyFunction_FastCallKeywords + 212
229 org.python.python             	0x000000010c9b7ad9 call_function + 737
230 org.python.python             	0x000000010c9b0a47 _PyEval_EvalFrameDefault + 6767
231 org.python.python             	0x000000010c922830 function_code_fastcall + 106
232 org.python.python             	0x000000010c9b7ad9 call_function + 737
233 org.python.python             	0x000000010c9b0a2e _PyEval_EvalFrameDefault + 6742
234 org.python.python             	0x000000010c922830 function_code_fastcall + 106
235 org.python.python             	0x000000010c9b7ad9 call_function + 737
236 org.python.python             	0x000000010c9b0ae2 _PyEval_EvalFrameDefault + 6922
237 org.python.python             	0x000000010c922830 function_code_fastcall + 106
238 org.python.python             	0x000000010c9b7ad9 call_function + 737
239 org.python.python             	0x000000010c9b0ae2 _PyEval_EvalFrameDefault + 6922
240 org.python.python             	0x000000010c922830 function_code_fastcall + 106
241 org.python.python             	0x000000010c923bde object_vacall + 267
242 org.python.python             	0x000000010c923cdd _PyObject_CallMethodIdObjArgs + 168
243 org.python.python             	0x000000010c9ccb2b PyImport_ImportModuleLevelObject + 1490
244 org.python.python             	0x000000010c9b5659 _PyEval_EvalFrameDefault + 26241
245 org.python.python             	0x000000010c9b82cd _PyEval_EvalCodeWithName + 1698
246 org.python.python             	0x000000010c9aef35 PyEval_EvalCode + 51
247 org.python.python             	0x000000010c9ac9bf builtin_exec + 563
248 org.python.python             	0x000000010c922b0e _PyMethodDef_RawFastCallDict + 549
249 org.python.python             	0x000000010c92211f _PyCFunction_FastCallDict + 41
250 org.python.python             	0x000000010c9b0e12 _PyEval_EvalFrameDefault + 7738
251 org.python.python             	0x000000010c9b82cd _PyEval_EvalCodeWithName + 1698
252 org.python.python             	0x000000010c922424 _PyFunction_FastCallKeywords + 212
253 org.python.python             	0x000000010c9b7ad9 call_function + 737
254 org.python.python             	0x000000010c9b0a47 _PyEval_EvalFrameDefault + 6767
255 org.python.python             	0x000000010c922830 function_code_fastcall + 106
256 org.python.python             	0x000000010c9b7ad9 call_function + 737
257 org.python.python             	0x000000010c9b0a2e _PyEval_EvalFrameDefault + 6742
258 org.python.python             	0x000000010c922830 function_code_fastcall + 106
259 org.python.python             	0x000000010c9b7ad9 call_function + 737
260 org.python.python             	0x000000010c9b0ae2 _PyEval_EvalFrameDefault + 6922
261 org.python.python             	0x000000010c922830 function_code_fastcall + 106
262 org.python.python             	0x000000010c9b7ad9 call_function + 737
263 org.python.python             	0x000000010c9b0ae2 _PyEval_EvalFrameDefault + 6922
264 org.python.python             	0x000000010c922830 function_code_fastcall + 106
265 org.python.python             	0x000000010c923bde object_vacall + 267
266 org.python.python             	0x000000010c923cdd _PyObject_CallMethodIdObjArgs + 168
267 org.python.python             	0x000000010c9ccb2b PyImport_ImportModuleLevelObject + 1490
268 org.python.python             	0x000000010c9b5659 _PyEval_EvalFrameDefault + 26241
269 org.python.python             	0x000000010c9b82cd _PyEval_EvalCodeWithName + 1698
270 org.python.python             	0x000000010c9aef35 PyEval_EvalCode + 51
271 org.python.python             	0x000000010c9dd37c run_mod + 54
272 org.python.python             	0x000000010c9dc3af PyRun_FileExFlags + 160
273 org.python.python             	0x000000010c9dba66 PyRun_SimpleFileExFlags + 270
274 org.python.python             	0x000000010c9f4276 pymain_main + 5445
275 org.python.python             	0x000000010c9f48e4 _Py_UnixMain + 56
276 libdyld.dylib                 	0x00007fff70452cc9 start + 1

Thread 0 crashed with X86 Thread State (64-bit):
  rax: 0x0000000000000001  rbx: 0x00007fffcae6d9fd  rcx: 0x0000000000000001  rdx: 0x00007fffcae6d975
  rdi: 0x00007ffee32ef7d0  rsi: 0x0000000000000001  rbp: 0x00007ffee32ef800  rsp: 0x00007ffee32ef7c0
   r8: 0x00007fffcae6d93d   r9: 0x0000000000000000  r10: 0x00007fd5b9dd4c80  r11: 0x00007fd5b9d34990
  r12: 0x0000000000000001  r13: 0x00000001324b2288  r14: 0x00000001324b2287  r15: 0x00007fffcae7cfe8
  rip: 0x000000011591f899  rfl: 0x0000000000000202  cr2: 0x000000010f63d000
  
Logical CPU:     0
Error Code:      0x00000000
Trap Number:     222


Binary Images:
       0x10c904000 -        0x10c905fff +org.python.python (3.7.7 - 3.7.7) <9BB83026-A8FB-3729-9EAD-51515C0E65D0> /usr/local/Cellar/python/3.7.7/Frameworks/Python.framework/Versions/3.7/Resources/Python.app/Contents/MacOS/Python
       0x10c909000 -        0x10ca8cff7 +org.python.python (3.7.7, [c] 2001-2019 Python Software Foundation. - 3.7.7) <CF8C2BF9-3901-3F78-8AB1-24B17DD46724> /usr/local/Cellar/python/3.7.7/Frameworks/Python.framework/Versions/3.7/Python
       0x10ce7d000 -        0x10ce7efff +_heapq.cpython-37m-darwin.so (0) <E2F49CC0-B6E0-3437-B055-9C4AF522D939> /usr/local/Cellar/python/3.7.7/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_heapq.cpython-37m-darwin.so
       0x10cec3000 -        0x10ced8ff7 +libgcc_s.1.dylib (0) <7C6D7CB7-82DB-3290-8181-07646FEA1F80> /usr/local/lib/python3.7/site-packages/numpy/.dylibs/libgcc_s.1.dylib
       0x10ceef000 -        0x10cef3ff3 +math.cpython-37m-darwin.so (0) <2C8E657B-4446-3844-B549-0F4DB5F5C351> /usr/local/Cellar/python/3.7.7/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/math.cpython-37m-darwin.so
       0x10cefb000 -        0x10cefcfff +_posixsubprocess.cpython-37m-darwin.so (0) <D75D7192-18DF-3465-BF8C-AB9CC8678AF1> /usr/local/Cellar/python/3.7.7/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_posixsubprocess.cpython-37m-darwin.so
       0x10cf00000 -        0x10cf00ff7 +_move.cpython-37m-darwin.so (???) <3203C9B0-9669-38C9-9489-15E143D5A4E3> /usr/local/lib/python3.7/site-packages/pandas/util/_move.cpython-37m-darwin.so
       0x10cf43000 -        0x10d2a5fe7 +_multiarray_umath.cpython-37m-darwin.so (0) <589A85B0-F3E4-3C49-90C6-43384B2FDD17> /usr/local/lib/python3.7/site-packages/numpy/core/_multiarray_umath.cpython-37m-darwin.so
       0x10d3b8000 -        0x110e23ae7 +libopenblasp-r0.3.7.dylib (0) <9914A383-F8C9-3559-BC88-B4DD28689BC5> /usr/local/lib/python3.7/site-packages/numpy/.dylibs/libopenblasp-r0.3.7.dylib
       0x111063000 -        0x11117aff7 +libgfortran.3.dylib (0) <9ABE5EDE-AD43-391A-9E54-866711FAC32A> /usr/local/lib/python3.7/site-packages/numpy/.dylibs/libgfortran.3.dylib
       0x1111de000 -        0x111214fff +libquadmath.0.dylib (0) <7FFA409F-FB04-3B64-BE9A-3E3A494C975E> /usr/local/lib/python3.7/site-packages/numpy/.dylibs/libquadmath.0.dylib
       0x115263000 -        0x11526effb +_datetime.cpython-37m-darwin.so (0) <6EC669D9-CA77-3C3C-808A-CF23B74EB19A> /usr/local/Cellar/python/3.7.7/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_datetime.cpython-37m-darwin.so
       0x115340000 -        0x115343fff +_struct.cpython-37m-darwin.so (0) <4171BD07-989E-353C-820D-9F8BA813EFD2> /usr/local/Cellar/python/3.7.7/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_struct.cpython-37m-darwin.so
       0x11534a000 -        0x115356ffb +_pickle.cpython-37m-darwin.so (0) <629740D9-66EF-3FC5-A6E9-DCBF83335CEF> /usr/local/Cellar/python/3.7.7/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_pickle.cpython-37m-darwin.so
       0x1154cf000 -        0x1154dcff3 +_multiarray_tests.cpython-37m-darwin.so (0) <6122CECD-2D90-3973-A9C2-6FE07A6795AA> /usr/local/lib/python3.7/site-packages/numpy/core/_multiarray_tests.cpython-37m-darwin.so
       0x1154ed000 -        0x1154fcfff +_ctypes.cpython-37m-darwin.so (0) <0E20B73B-FD0D-3171-9ED4-84B758C8B90B> /usr/local/Cellar/python/3.7.7/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_ctypes.cpython-37m-darwin.so
       0x115548000 -        0x11554afff +select.cpython-37m-darwin.so (0) <048BD53F-21B5-3BC2-9696-EBDA8C796C53> /usr/local/Cellar/python/3.7.7/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/select.cpython-37m-darwin.so
       0x115610000 -        0x115611fff +lapack_lite.cpython-37m-darwin.so (0) <C3AA6C88-9EDB-3D5E-A9FA-7C9AF4ECFE3E> /usr/local/lib/python3.7/site-packages/numpy/linalg/lapack_lite.cpython-37m-darwin.so
       0x115615000 -        0x11562effb +_umath_linalg.cpython-37m-darwin.so (0) <A401AEEE-0CA9-3449-A288-19CED520AC55> /usr/local/lib/python3.7/site-packages/numpy/linalg/_umath_linalg.cpython-37m-darwin.so
       0x11570e000 -        0x115711fff +zlib.cpython-37m-darwin.so (0) <9F0544E2-DA98-3105-8E35-6C9EA1D83E1E> /usr/local/Cellar/python/3.7.7/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/zlib.cpython-37m-darwin.so
       0x115717000 -        0x115718fff +_bz2.cpython-37m-darwin.so (0) <7F5E7C34-9555-3C00-9002-D3872E2E1038> /usr/local/Cellar/python/3.7.7/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_bz2.cpython-37m-darwin.so
       0x11571d000 -        0x115720ff7 +_lzma.cpython-37m-darwin.so (0) <359A39BA-4669-3BD6-8174-7D03F3FAEC73> /usr/local/Cellar/python/3.7.7/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_lzma.cpython-37m-darwin.so
       0x115726000 -        0x115741fff +liblzma.5.dylib (0) <E4406E42-7BC4-3945-A1A4-E9B6874EF052> /usr/local/opt/xz/lib/liblzma.5.dylib
       0x115788000 -        0x115789fff +grp.cpython-37m-darwin.so (0) <068AE1FA-5DF7-30C7-AFB2-248D3602A60F> /usr/local/Cellar/python/3.7.7/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/grp.cpython-37m-darwin.so
       0x11578d000 -        0x1157baffb +_decimal.cpython-37m-darwin.so (0) <0F59A8DE-D1C4-3B48-B0BB-BE7659CB117B> /usr/local/Cellar/python/3.7.7/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_decimal.cpython-37m-darwin.so
       0x11580d000 -        0x11581effb +_pocketfft_internal.cpython-37m-darwin.so (0) <C71DAC57-DAD0-3695-A304-4CED45596071> /usr/local/lib/python3.7/site-packages/numpy/fft/_pocketfft_internal.cpython-37m-darwin.so
       0x115862000 -        0x115881ffb +_bit_generator.cpython-37m-darwin.so (0) <C1EC45A8-8E0B-38B7-8E1D-712F66920C0B> /usr/local/lib/python3.7/site-packages/numpy/random/_bit_generator.cpython-37m-darwin.so
       0x11589c000 -        0x1158cdff3 +_common.cpython-37m-darwin.so (0) <B71027BD-805E-3273-B799-0B4996164C4D> /usr/local/lib/python3.7/site-packages/numpy/random/_common.cpython-37m-darwin.so
       0x1158e2000 -        0x1158e5ff7 +binascii.cpython-37m-darwin.so (0) <8B08F4CA-677D-3433-A6B1-51EC47E46AE0> /usr/local/Cellar/python/3.7.7/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/binascii.cpython-37m-darwin.so
       0x1158ea000 -        0x1158edfff +_hashlib.cpython-37m-darwin.so (0) <DD86C4DA-E460-36B1-A44A-F84AA6C7B818> /usr/local/Cellar/python/3.7.7/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_hashlib.cpython-37m-darwin.so
       0x1158f2000 -        0x1158f7ffb +_blake2.cpython-37m-darwin.so (0) <24A45B55-A5EE-384C-9C8B-E2E19504DE49> /usr/local/Cellar/python/3.7.7/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_blake2.cpython-37m-darwin.so
       0x1158fc000 -        0x1158fcfff +_bisect.cpython-37m-darwin.so (0) <7C7230DF-C9CD-39F3-862E-DA9AFFEC69AE> /usr/local/Cellar/python/3.7.7/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_bisect.cpython-37m-darwin.so
       0x115900000 -        0x115901ffb +_random.cpython-37m-darwin.so (0) <3A53714A-1DEA-3F95-BE47-7933AC3AF60E> /usr/local/Cellar/python/3.7.7/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_random.cpython-37m-darwin.so
       0x115905000 -        0x115905fff +_opcode.cpython-37m-darwin.so (0) <1B368B19-685C-3521-8617-6A2D5D506088> /usr/local/Cellar/python/3.7.7/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_opcode.cpython-37m-darwin.so
       0x115909000 -        0x11599aeff  dyld (750.5) <1F893B81-89A5-3502-8510-95B97B9F730D> /usr/lib/dyld
       0x117a0e000 -        0x117a7afff +mtrand.cpython-37m-darwin.so (0) <68575578-5D1C-307F-B1E2-814E9D927576> /usr/local/lib/python3.7/site-packages/numpy/random/mtrand.cpython-37m-darwin.so
       0x117ace000 -        0x117b1dfff +libssl.1.1.dylib (0) <CB98AFA7-D014-3D75-80FD-84EEB607EC1A> /usr/local/opt/openssl at 1.1/lib/libssl.1.1.dylib
       0x117b46000 -        0x117ce0c2f +libcrypto.1.1.dylib (0) <9D836867-F469-3417-97DC-31B074FCB6F4> /usr/local/opt/openssl at 1.1/lib/libcrypto.1.1.dylib
       0x117d73000 -        0x117d83fff +_sha3.cpython-37m-darwin.so (0) <842E2E24-792A-31D8-90CC-59C25D799618> /usr/local/Cellar/python/3.7.7/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_sha3.cpython-37m-darwin.so
       0x117dc9000 -        0x117e1dffb +_bounded_integers.cpython-37m-darwin.so (0) <3708243B-E3EB-3E93-8C34-8C2610901644> /usr/local/lib/python3.7/site-packages/numpy/random/_bounded_integers.cpython-37m-darwin.so
       0x117e40000 -        0x117e53ff7 +_mt19937.cpython-37m-darwin.so (0) <F6CF6DD4-270A-3975-A492-9220634DCEC9> /usr/local/lib/python3.7/site-packages/numpy/random/_mt19937.cpython-37m-darwin.so
       0x117e5f000 -        0x117e6cff7 +_philox.cpython-37m-darwin.so (0) <F4A9DD22-5810-3D07-8D2A-4BDA08F63C2C> /usr/local/lib/python3.7/site-packages/numpy/random/_philox.cpython-37m-darwin.so
       0x117e77000 -        0x117e81ff3 +_pcg64.cpython-37m-darwin.so (0) <F679DB43-B3F4-3A7D-94CA-2E14F099CC1D> /usr/local/lib/python3.7/site-packages/numpy/random/_pcg64.cpython-37m-darwin.so
       0x117e8c000 -        0x117e94ff3 +_sfc64.cpython-37m-darwin.so (0) <87D78BD8-6E7E-344D-8852-1028DC1C6E02> /usr/local/lib/python3.7/site-packages/numpy/random/_sfc64.cpython-37m-darwin.so
       0x117e9e000 -        0x117f21ff3 +_generator.cpython-37m-darwin.so (0) <16E20BD0-31E4-3323-A302-E83C5BD30E50> /usr/local/lib/python3.7/site-packages/numpy/random/_generator.cpython-37m-darwin.so
       0x1180ff000 -        0x1181fdfff +unicodedata.cpython-37m-darwin.so (0) <2266541F-A89E-3965-8237-BF8FCEF2948B> /usr/local/Cellar/python/3.7.7/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/unicodedata.cpython-37m-darwin.so
       0x1182c3000 -        0x1182cbffb +_socket.cpython-37m-darwin.so (0) <132B2171-C425-3139-B7FF-79C3DAB3CDF0> /usr/local/Cellar/python/3.7.7/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_socket.cpython-37m-darwin.so
       0x118357000 -        0x118364fff +_ssl.cpython-37m-darwin.so (0) <15B2E6E2-B06C-34FE-BDAC-13EB1BAE7582> /usr/local/Cellar/python/3.7.7/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_ssl.cpython-37m-darwin.so
       0x118433000 -        0x118461ff7 +tslib.cpython-37m-darwin.so (???) <581A747E-9492-3E88-ABE4-9511AE2FA0AC> /usr/local/lib/python3.7/site-packages/pandas/_libs/tslib.cpython-37m-darwin.so
       0x118474000 -        0x1184b3ff7 +conversion.cpython-37m-darwin.so (???) <B51D48AD-1E8C-3C35-B883-5A1E527A5A9A> /usr/local/lib/python3.7/site-packages/pandas/_libs/tslibs/conversion.cpython-37m-darwin.so
       0x1184c8000 -        0x1184d0ff7 +np_datetime.cpython-37m-darwin.so (???) <9086CCDC-C58B-3150-A0E8-9A6BA6008B4C> /usr/local/lib/python3.7/site-packages/pandas/_libs/tslibs/np_datetime.cpython-37m-darwin.so
       0x1184d8000 -        0x1184fafff +nattype.cpython-37m-darwin.so (???) <50FDB62F-5398-3B9E-8154-63D3381C09AB> /usr/local/lib/python3.7/site-packages/pandas/_libs/tslibs/nattype.cpython-37m-darwin.so
       0x118515000 -        0x118559ff7 +timedeltas.cpython-37m-darwin.so (???) <2BF8AFB5-105D-3A4F-940B-BB12BFA0B4AF> /usr/local/lib/python3.7/site-packages/pandas/_libs/tslibs/timedeltas.cpython-37m-darwin.so
       0x1185bd000 -        0x1185d0ff7 +timezones.cpython-37m-darwin.so (???) <5C85D606-7E8F-3490-907E-34FE318D5C60> /usr/local/lib/python3.7/site-packages/pandas/_libs/tslibs/timezones.cpython-37m-darwin.so
       0x1185dd000 -        0x118613fff +parsing.cpython-37m-darwin.so (???) <D3738070-B044-3DA1-B67D-E1A17B2DE543> /usr/local/lib/python3.7/site-packages/pandas/_libs/tslibs/parsing.cpython-37m-darwin.so
       0x11862f000 -        0x118638fff +ccalendar.cpython-37m-darwin.so (???) <3DF6AB7D-019E-3215-9243-2BB521A6C527> /usr/local/lib/python3.7/site-packages/pandas/_libs/tslibs/ccalendar.cpython-37m-darwin.so
       0x118642000 -        0x11867bff7 +strptime.cpython-37m-darwin.so (???) <5E77132A-03EB-3C93-B4DC-2FC88E15226F> /usr/local/lib/python3.7/site-packages/pandas/_libs/tslibs/strptime.cpython-37m-darwin.so
       0x118699000 -        0x1186ddfff +timestamps.cpython-37m-darwin.so (???) <979FF39D-75E5-3D9D-AC59-804AD88D73A5> /usr/local/lib/python3.7/site-packages/pandas/_libs/tslibs/timestamps.cpython-37m-darwin.so
       0x118704000 -        0x118721ff7 +fields.cpython-37m-darwin.so (???) <20627348-8C24-3EC1-A621-6D767CFFF9DD> /usr/local/lib/python3.7/site-packages/pandas/_libs/tslibs/fields.cpython-37m-darwin.so
       0x118730000 -        0x1187a0fff +hashtable.cpython-37m-darwin.so (???) <D134A21F-8737-354E-BB44-8B4AEBDE9A4C> /usr/local/lib/python3.7/site-packages/pandas/_libs/hashtable.cpython-37m-darwin.so
       0x1187cb000 -        0x1187d9fff +missing.cpython-37m-darwin.so (???) <0E7CEC9C-CD82-32F1-9FC7-98B7AA65C5A5> /usr/local/lib/python3.7/site-packages/pandas/_libs/missing.cpython-37m-darwin.so
       0x1187e3000 -        0x118849ff7 +lib.cpython-37m-darwin.so (???) <FA76B5FA-D4D6-3321-927F-E8774F6B168F> /usr/local/lib/python3.7/site-packages/pandas/_libs/lib.cpython-37m-darwin.so
       0x1188fe000 -        0x118a3eff7 +algos.cpython-37m-darwin.so (???) <4B81EDB5-DBE2-3B62-A2C4-DC88A289CB33> /usr/local/lib/python3.7/site-packages/pandas/_libs/algos.cpython-37m-darwin.so
       0x118acb000 -        0x118ad4fff +properties.cpython-37m-darwin.so (???) <9DA8DECA-D6E4-3A9A-A22D-12349383C521> /usr/local/lib/python3.7/site-packages/pandas/_libs/properties.cpython-37m-darwin.so
       0x118add000 -        0x118ae6ff7 +hashing.cpython-37m-darwin.so (???) <5DD150C0-84C9-34A3-9C2F-56B9AB33C2F5> /usr/local/lib/python3.7/site-packages/pandas/_libs/hashing.cpython-37m-darwin.so
       0x118bef000 -        0x118c56fff +index.cpython-37m-darwin.so (???) <82E19CDD-CD23-3009-BE77-C61B4F4E1D10> /usr/local/lib/python3.7/site-packages/pandas/_libs/index.cpython-37m-darwin.so
       0x118cbf000 -        0x118d06ff7 +period.cpython-37m-darwin.so (???) <5C45C83A-0992-3ECB-A5E2-52ED4F4970C5> /usr/local/lib/python3.7/site-packages/pandas/_libs/tslibs/period.cpython-37m-darwin.so
       0x118d27000 -        0x118d3aff7 +frequencies.cpython-37m-darwin.so (???) <686C9301-A4EE-3B3A-BAA9-58F03B417D4B> /usr/local/lib/python3.7/site-packages/pandas/_libs/tslibs/frequencies.cpython-37m-darwin.so
       0x118d4b000 -        0x118d85ff7 +resolution.cpython-37m-darwin.so (???) <4AC5B450-8741-381F-8D47-87F664EA79F3> /usr/local/lib/python3.7/site-packages/pandas/_libs/tslibs/resolution.cpython-37m-darwin.so
       0x118de2000 -        0x118e21ff7 +offsets.cpython-37m-darwin.so (???) <F0425497-1EA5-3883-BBEC-1F31CF4B7B1B> /usr/local/lib/python3.7/site-packages/pandas/_libs/tslibs/offsets.cpython-37m-darwin.so
       0x118e4a000 -        0x11902efff +join.cpython-37m-darwin.so (???) <DC187F02-8E1F-327C-AE13-53FFCE36E34F> /usr/local/lib/python3.7/site-packages/pandas/_libs/join.cpython-37m-darwin.so
       0x1190a9000 -        0x1190baff7 +ops.cpython-37m-darwin.so (???) <7651AAB2-4577-305E-BFCA-2F5CC655C6B5> /usr/local/lib/python3.7/site-packages/pandas/_libs/ops.cpython-37m-darwin.so
       0x119144000 -        0x1192f6ff7 +interval.cpython-37m-darwin.so (???) <D87D80E4-9262-3142-85FA-0017F5DD3167> /usr/local/lib/python3.7/site-packages/pandas/_libs/interval.cpython-37m-darwin.so
       0x1194aa000 -        0x1194affff +_json.cpython-37m-darwin.so (0) <A16EB964-F4E8-3E51-B03F-64349CD6803B> /usr/local/Cellar/python/3.7.7/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_json.cpython-37m-darwin.so
       0x1194f4000 -        0x1194f9fff +indexing.cpython-37m-darwin.so (???) <D7E79669-8390-3B85-8B0F-877CC77F750D> /usr/local/lib/python3.7/site-packages/pandas/_libs/indexing.cpython-37m-darwin.so
       0x119540000 -        0x11956eff7 +internals.cpython-37m-darwin.so (???) <2825D996-AFE4-357C-8A30-74E56C78C7BB> /usr/local/lib/python3.7/site-packages/pandas/_libs/internals.cpython-37m-darwin.so
       0x1195c8000 -        0x119696fff +sparse.cpython-37m-darwin.so (???) <1F900899-7E6F-306D-8129-9FAA4BC25940> /usr/local/lib/python3.7/site-packages/pandas/_libs/sparse.cpython-37m-darwin.so
       0x1196f5000 -        0x1196f8fff +_csv.cpython-37m-darwin.so (0) <0A1B0AC0-5DA1-3D33-8DEB-F4F57A1CD138> /usr/local/Cellar/python/3.7.7/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_csv.cpython-37m-darwin.so
       0x1196fe000 -        0x119700fff +mmap.cpython-37m-darwin.so (0) <B29EAB03-27E7-3153-AACE-A37451EDF63D> /usr/local/Cellar/python/3.7.7/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/mmap.cpython-37m-darwin.so
       0x119785000 -        0x119786fff +_scproxy.cpython-37m-darwin.so (0) <7306C2E0-79B7-30CE-A953-A7154E3381C2> /usr/local/Cellar/python/3.7.7/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_scproxy.cpython-37m-darwin.so
       0x119bcb000 -        0x119bcbff3 +_C.cpython-37m-darwin.so (0) <E0B158D3-4CFA-3081-8CD3-E52CF4C32134> /usr/local/lib/python3.7/site-packages/torch/_C.cpython-37m-darwin.so
       0x119bce000 -        0x119bd4ff7 +libshm.dylib (0) <E08BC964-249E-3A8D-8BA1-2CDFD9AA3E9B> /usr/local/lib/python3.7/site-packages/torch/lib/libshm.dylib
       0x119c59000 -        0x119c7dff7 +_path.cpython-37m-darwin.so (???) <C4AFA7FF-1E1A-39AA-B6C4-BAF5EC37622D> /usr/local/lib/python3.7/site-packages/matplotlib/_path.cpython-37m-darwin.so
       0x119ce1000 -        0x119d69ff7 +window.cpython-37m-darwin.so (???) <982386C6-2CED-3942-A579-B6A15E04073D> /usr/local/lib/python3.7/site-packages/pandas/_libs/window.cpython-37m-darwin.so
       0x119d98000 -        0x119da8fff +skiplist.cpython-37m-darwin.so (???) <32ED5599-54B8-34FA-9E02-F75DFD3E34AE> /usr/local/lib/python3.7/site-packages/pandas/_libs/skiplist.cpython-37m-darwin.so
       0x119e33000 -        0x119e66ff7 +reduction.cpython-37m-darwin.so (???) <E1C60DCB-9F9F-30ED-81AE-BFE650A324B8> /usr/local/lib/python3.7/site-packages/pandas/_libs/reduction.cpython-37m-darwin.so
       0x119e7d000 -        0x119f1ffff +groupby.cpython-37m-darwin.so (???) <A5780566-B199-3C58-9133-EA964A3B6B7F> /usr/local/lib/python3.7/site-packages/pandas/_libs/groupby.cpython-37m-darwin.so
       0x119f89000 -        0x119f9dff7 +reshape.cpython-37m-darwin.so (???) <8B01D695-DA13-3EC5-915D-E5C593298ACC> /usr/local/lib/python3.7/site-packages/pandas/_libs/reshape.cpython-37m-darwin.so
       0x11a028000 -        0x11a095ff7 +parsers.cpython-37m-darwin.so (???) <5CC2AE52-6888-3EC0-9EF6-F761E1E1421D> /usr/local/lib/python3.7/site-packages/pandas/_libs/parsers.cpython-37m-darwin.so
       0x11a100000 -        0x11a110ff7 +json.cpython-37m-darwin.so (???) <109DB40C-CC12-3DA7-B975-7E903BA73BFC> /usr/local/lib/python3.7/site-packages/pandas/_libs/json.cpython-37m-darwin.so
       0x11a19a000 -        0x11a1bcfff +writers.cpython-37m-darwin.so (???) <FABBBBD1-025F-397C-ADC6-2C9853796342> /usr/local/lib/python3.7/site-packages/pandas/_libs/writers.cpython-37m-darwin.so
       0x11a254000 -        0x11a25fff7 +_packer.cpython-37m-darwin.so (???) <F8015084-39F9-3704-8954-0B21168C45BF> /usr/local/lib/python3.7/site-packages/pandas/io/msgpack/_packer.cpython-37m-darwin.so
       0x11a2aa000 -        0x11a2b9ff7 +_unpacker.cpython-37m-darwin.so (???) <B1643345-4CA7-312F-9A78-051D814DE253> /usr/local/lib/python3.7/site-packages/pandas/io/msgpack/_unpacker.cpython-37m-darwin.so
       0x11a2c7000 -        0x11a2d5ff7 +testing.cpython-37m-darwin.so (???) <5B6DBC36-2188-3FFC-9363-DB9F0616853A> /usr/local/lib/python3.7/site-packages/pandas/_libs/testing.cpython-37m-darwin.so
       0x11a2de000 -        0x11a8ffff3 +libtorch_python.dylib (0) <4C60D24F-F73C-36BA-9B2C-0D2D2EECCC6C> /usr/local/lib/python3.7/site-packages/torch/lib/libtorch_python.dylib
       0x11aabe000 -        0x11cb8efd3 +libcaffe2.dylib (0) <6B4CCC38-5D40-3EF4-A8A7-7CD03C140967> /usr/local/lib/python3.7/site-packages/torch/lib/libcaffe2.dylib
       0x11d61c000 -        0x11d634ff3 +libc10.dylib (0) <BA240F39-3717-36C6-A7B1-48E68EC5AD10> /usr/local/lib/python3.7/site-packages/torch/lib/libc10.dylib
       0x11d64a000 -        0x123514f8f +libmklml.dylib (0) <7DC94FEC-1801-334E-A667-242205717048> /usr/local/lib/python3.7/site-packages/torch/lib/libmklml.dylib
       0x1239b1000 -        0x123ab6fdf +libiomp5.dylib (0) <7052FBE9-0DC4-3593-AD19-293AE34638F3> /usr/local/lib/python3.7/site-packages/torch/lib/libiomp5.dylib
       0x123b1c000 -        0x123f90fe7 +libmkldnn.0.dylib (0) <73514B57-2A82-3737-8221-C69826DB87D9> /usr/local/lib/python3.7/site-packages/torch/lib/libmkldnn.0.dylib
       0x124162000 -        0x124e50ff3 +libtorch.1.dylib (0) <F6909E4B-A7C2-337C-97E9-A7D61127E68F> /usr/local/lib/python3.7/site-packages/torch/lib/libtorch.1.dylib
       0x12565c000 -        0x125661ffb +array.cpython-37m-darwin.so (0) <B792199A-07E5-3469-9B0B-DCA95D4873A1> /usr/local/Cellar/python/3.7.7/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/array.cpython-37m-darwin.so
       0x125a69000 -        0x125a6afff +_queue.cpython-37m-darwin.so (0) <48C4453F-AF5E-30EF-B482-02C1CE001FE2> /usr/local/Cellar/python/3.7.7/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_queue.cpython-37m-darwin.so
       0x125aae000 -        0x125aafffb +_multiprocessing.cpython-37m-darwin.so (0) <DA5DB622-3D54-3003-8A54-A4F6C9146108> /usr/local/Cellar/python/3.7.7/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_multiprocessing.cpython-37m-darwin.so
       0x125bf3000 -        0x125bf4fff +termios.cpython-37m-darwin.so (0) <9808B153-1946-3BF9-B7D0-D38D95836A03> /usr/local/Cellar/python/3.7.7/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/termios.cpython-37m-darwin.so
       0x125bf8000 -        0x125bf9fff +fcntl.cpython-37m-darwin.so (0) <5DF6EC0F-7822-349D-99EB-381F012CC7A8> /usr/local/Cellar/python/3.7.7/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/fcntl.cpython-37m-darwin.so
       0x125e0f000 -        0x125e16ff3 +_elementtree.cpython-37m-darwin.so (0) <27B457C2-CA66-3E9A-9C78-154032E9FD51> /usr/local/Cellar/python/3.7.7/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_elementtree.cpython-37m-darwin.so
       0x125e1e000 -        0x125e3dffb +pyexpat.cpython-37m-darwin.so (0) <A088687C-5A14-317C-AC56-0F39E42AF1ED> /usr/local/Cellar/python/3.7.7/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/pyexpat.cpython-37m-darwin.so
       0x1260af000 -        0x1260affff +_uuid.cpython-37m-darwin.so (0) <49D01DE5-A3E3-3F6E-AB2A-54C1783B7B1C> /usr/local/Cellar/python/3.7.7/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_uuid.cpython-37m-darwin.so
       0x126580000 -        0x126581ffb +resource.cpython-37m-darwin.so (0) <63B15777-7663-3705-9659-2EC391A784EC> /usr/local/Cellar/python/3.7.7/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/resource.cpython-37m-darwin.so
       0x1269c6000 -        0x1269c6fff +_contextvars.cpython-37m-darwin.so (0) <0A57AD35-9696-32A0-9625-20DE748D4270> /usr/local/Cellar/python/3.7.7/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_contextvars.cpython-37m-darwin.so
       0x1269ca000 -        0x1269cffff +_asyncio.cpython-37m-darwin.so (0) <AA4B1BE4-B295-356A-B0A2-60AA38306CBB> /usr/local/Cellar/python/3.7.7/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_asyncio.cpython-37m-darwin.so
       0x126ad9000 -        0x126ae1ff7 +_sqlite3.cpython-37m-darwin.so (0) <91CF53B8-7E43-3D52-8337-BB1C94CA39C8> /usr/local/Cellar/python/3.7.7/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_sqlite3.cpython-37m-darwin.so
       0x126aec000 -        0x126bc7ff7 +libsqlite3.0.dylib (0) <05322D5B-03FA-3E3B-86FF-2E9150DF1C1B> /usr/local/opt/sqlite/lib/libsqlite3.0.dylib
       0x12724a000 -        0x12724bff7 +_lsprof.cpython-37m-darwin.so (0) <86CB08B5-4923-3966-8A47-631251DD93FB> /usr/local/Cellar/python/3.7.7/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_lsprof.cpython-37m-darwin.so
       0x127367000 -        0x1314cbbb7 +_pywrap_tensorflow_internal.so (0) <8F1B25FA-F2F4-3395-A3FB-BE98FE5DFB96> /usr/local/lib/python3.7/site-packages/tensorflow_core/python/_pywrap_tensorflow_internal.so
       0x13c82d000 -        0x13d82830f +libtensorflow_framework.2.dylib (0) <9DF0409D-3C47-348E-9375-75510306EA03> /usr/local/lib/python3.7/site-packages/tensorflow_core/libtensorflow_framework.2.dylib
    0x7fff3211c000 -     0x7fff3211cfff  com.apple.Accelerate (1.11 - Accelerate 1.11) <8BE0965F-6A6A-35B0-89D0-F0A75835C2CA> /System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate
    0x7fff32134000 -     0x7fff3278afef  com.apple.vImage (8.1 - 524.2) <DAE0E5C5-BA70-325D-8B4C-6B821F009CBF> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vImage.framework/Versions/A/vImage
    0x7fff3278b000 -     0x7fff329f2ff7  libBLAS.dylib (1303.60.1) <4E980D6B-4B3A-33D6-B52C-AFC7D120D11A> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib
    0x7fff329f3000 -     0x7fff32ec6fef  libBNNS.dylib (144.100.2) <C05F9F9D-4498-37BD-9C1C-2F7B920B401D> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBNNS.dylib
    0x7fff32ec7000 -     0x7fff33262fff  libLAPACK.dylib (1303.60.1) <F8E9D081-7C60-32EC-A47D-2D30CAD73C5F> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libLAPACK.dylib
    0x7fff33263000 -     0x7fff33278fec  libLinearAlgebra.dylib (1303.60.1) <79CB28C5-F811-3EAF-AD8E-7D7D879FE662> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libLinearAlgebra.dylib
    0x7fff33279000 -     0x7fff3327eff3  libQuadrature.dylib (7) <EB7C9E98-D1E7-314C-90B4-3EB04428CC7C> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libQuadrature.dylib
    0x7fff3327f000 -     0x7fff332effff  libSparse.dylib (103) <8C55F5F2-6AE3-393C-B2FF-22B8CFCBD7FC> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libSparse.dylib
    0x7fff332f0000 -     0x7fff33302fef  libSparseBLAS.dylib (1303.60.1) <08F6D629-5DAC-3A99-B261-2B6095DD38B4> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libSparseBLAS.dylib
    0x7fff33303000 -     0x7fff334dafd7  libvDSP.dylib (735.100.4) <0744F29B-F822-3571-9B4A-B592146D4E03> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvDSP.dylib
    0x7fff334db000 -     0x7fff3359dfef  libvMisc.dylib (735.100.4) <E6C94B52-931B-3858-AF4D-C2EA52ACB7F5> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvMisc.dylib
    0x7fff3359e000 -     0x7fff3359efff  com.apple.Accelerate.vecLib (3.11 - vecLib 3.11) <66282197-81EE-316F-978E-EF1471551DEF> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/vecLib
    0x7fff34cff000 -     0x7fff3508dffd  com.apple.CFNetwork (1125.2 - 1125.2) <1D4D81F7-FC48-3588-87FC-481E2586E345> /System/Library/Frameworks/CFNetwork.framework/Versions/A/CFNetwork
    0x7fff36488000 -     0x7fff36907ffb  com.apple.CoreFoundation (6.9 - 1675.129) <9E632A1E-9622-33D6-BCCE-23AC16DAA6B7> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
    0x7fff37870000 -     0x7fff37870fff  com.apple.CoreServices (1069.22 - 1069.22) <888FE7B9-CE6C-3C7C-BA33-63364462228A> /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices
    0x7fff37871000 -     0x7fff378f6fff  com.apple.AE (838.1 - 838.1) <2BAB1B88-C198-3D20-8DA3-056E66510E7A> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/AE.framework/Versions/A/AE
    0x7fff378f7000 -     0x7fff37bd8ff7  com.apple.CoreServices.CarbonCore (1217 - 1217) <D0FECC17-7E16-308F-98EA-AF311CB77FE6> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CarbonCore.framework/Versions/A/CarbonCore
    0x7fff37bd9000 -     0x7fff37c26ffd  com.apple.DictionaryServices (1.2 - 323.6) <11513ED9-8B4B-39BB-A6B2-AA6AA0A2DF72> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/DictionaryServices.framework/Versions/A/DictionaryServices
    0x7fff37c27000 -     0x7fff37c2fff7  com.apple.CoreServices.FSEvents (1268.100.1 - 1268.100.1) <CE3D8B13-2583-3527-8532-D5DDAAD7D56B> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/FSEvents.framework/Versions/A/FSEvents
    0x7fff37c30000 -     0x7fff37e69ffc  com.apple.LaunchServices (1069.22 - 1069.22) <E51EE658-608C-3034-9635-4FDF1E241E62> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/LaunchServices
    0x7fff37e6a000 -     0x7fff37f02ff1  com.apple.Metadata (10.7.0 - 2076.3) <EE42CCA1-FEC2-3F1C-9B62-2E73EFB05FCC> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Metadata.framework/Versions/A/Metadata
    0x7fff37f03000 -     0x7fff37f30fff  com.apple.CoreServices.OSServices (1069.22 - 1069.22) <A0654B4E-3194-3066-911F-FF1FBEE1D2C2> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/OSServices.framework/Versions/A/OSServices
    0x7fff37f31000 -     0x7fff37f98fff  com.apple.SearchKit (1.4.1 - 1.4.1) <D4F82BC9-FD9B-3E04-B78E-D9E2A73B0BD7> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/SearchKit.framework/Versions/A/SearchKit
    0x7fff37f99000 -     0x7fff37fbdff5  com.apple.coreservices.SharedFileList (131.4 - 131.4) <AEB4E42C-F5A2-3F63-80B0-4226483AD4F5> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/SharedFileList.framework/Versions/A/SharedFileList
    0x7fff38803000 -     0x7fff38809fff  com.apple.DiskArbitration (2.7 - 2.7) <D7617B57-B01C-3848-8818-593FB12039E9> /System/Library/Frameworks/DiskArbitration.framework/Versions/A/DiskArbitration
    0x7fff38b3e000 -     0x7fff38f03ff8  com.apple.Foundation (6.9 - 1675.129) <9A74FA97-7F7B-3929-B381-D9514B1E4754> /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation
    0x7fff39277000 -     0x7fff3931bff3  com.apple.framework.IOKit (2.0.2 - 1726.100.16) <3D8BA34A-AAF7-3AF2-9B5B-189AC4755404> /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit
    0x7fff3ce1a000 -     0x7fff3ce26ffe  com.apple.NetFS (6.0 - 4.0) <7A96A8FE-17F3-3850-8E81-9DDDC5A48DDB> /System/Library/Frameworks/NetFS.framework/Versions/A/NetFS
    0x7fff3fa08000 -     0x7fff3fa24fff  com.apple.CFOpenDirectory (10.15 - 220.40.1) <58835104-9E7A-32E8-862B-530CE899C9B4> /System/Library/Frameworks/OpenDirectory.framework/Versions/A/Frameworks/CFOpenDirectory.framework/Versions/A/CFOpenDirectory
    0x7fff3fa25000 -     0x7fff3fa30ffd  com.apple.OpenDirectory (10.15 - 220.40.1) <D846BA35-59A1-3B78-B1C8-7E0EDE972AD2> /System/Library/Frameworks/OpenDirectory.framework/Versions/A/OpenDirectory
    0x7fff42dca000 -     0x7fff43113ff1  com.apple.security (7.0 - 59306.101.1) <430E04FE-F068-3476-9CA2-72CB5F040D1F> /System/Library/Frameworks/Security.framework/Versions/A/Security
    0x7fff43114000 -     0x7fff4319cffb  com.apple.securityfoundation (6.0 - 55236.60.1) <BC15B825-955D-33CF-B416-A64D69A1D008> /System/Library/Frameworks/SecurityFoundation.framework/Versions/A/SecurityFoundation
    0x7fff431cb000 -     0x7fff431cfff8  com.apple.xpc.ServiceManagement (1.0 - 1) <C66FC9CF-224B-348C-94A5-ABAC579F5C0A> /System/Library/Frameworks/ServiceManagement.framework/Versions/A/ServiceManagement
    0x7fff43e7a000 -     0x7fff43ee8ff7  com.apple.SystemConfiguration (1.19 - 1.19) <71AC15DE-7018-3D2B-B599-F2972F0288AE> /System/Library/Frameworks/SystemConfiguration.framework/Versions/A/SystemConfiguration
    0x7fff47e45000 -     0x7fff47f0aff7  com.apple.APFS (1412.101.1 - 1412.101.1) <2F5A48FB-9788-3A24-87FE-C1B7DDBC8A07> /System/Library/PrivateFrameworks/APFS.framework/Versions/A/APFS
    0x7fff49d8f000 -     0x7fff49d9efd7  com.apple.AppleFSCompression (119.100.1 - 1.0) <E1B024EB-DAB1-30A1-A43D-01D9E9357F2B> /System/Library/PrivateFrameworks/AppleFSCompression.framework/Versions/A/AppleFSCompression
    0x7fff4b55d000 -     0x7fff4b566ff7  com.apple.coreservices.BackgroundTaskManagement (1.0 - 104) <2088BC70-5329-3390-A851-C4ECF654047C> /System/Library/PrivateFrameworks/BackgroundTaskManagement.framework/Versions/A/BackgroundTaskManagement
    0x7fff4e31c000 -     0x7fff4e32cff3  com.apple.CoreEmoji (1.0 - 107) <AC83B860-61BD-384E-81BF-CA3CBE655968> /System/Library/PrivateFrameworks/CoreEmoji.framework/Versions/A/CoreEmoji
    0x7fff4e96c000 -     0x7fff4e9d6ff0  com.apple.CoreNLP (1.0 - 213) <687A4C31-A307-3255-83BE-9B123971FF62> /System/Library/PrivateFrameworks/CoreNLP.framework/Versions/A/CoreNLP
    0x7fff4f851000 -     0x7fff4f87fffd  com.apple.CSStore (1069.22 - 1069.22) <39E431F9-3584-34DF-A64D-C5895AA72068> /System/Library/PrivateFrameworks/CoreServicesStore.framework/Versions/A/CoreServicesStore
    0x7fff5baaa000 -     0x7fff5bb78ffd  com.apple.LanguageModeling (1.0 - 215.1) <3FAF1700-F7D4-3F92-88AA-A3920702B8BB> /System/Library/PrivateFrameworks/LanguageModeling.framework/Versions/A/LanguageModeling
    0x7fff5bb79000 -     0x7fff5bbc1fff  com.apple.Lexicon-framework (1.0 - 72) <212D02CE-11BC-3C7F-BDFD-DF1A0C4017EE> /System/Library/PrivateFrameworks/Lexicon.framework/Versions/A/Lexicon
    0x7fff5bbc8000 -     0x7fff5bbcdff3  com.apple.LinguisticData (1.0 - 353.18) <BA3869B7-9C39-32DA-A4BA-12F1BC4B04CF> /System/Library/PrivateFrameworks/LinguisticData.framework/Versions/A/LinguisticData
    0x7fff5cf34000 -     0x7fff5cf80fff  com.apple.spotlight.metadata.utilities (1.0 - 2076.3) <EF8AC054-B15F-375F-AACB-018DC73CD16E> /System/Library/PrivateFrameworks/MetadataUtilities.framework/Versions/A/MetadataUtilities
    0x7fff5da35000 -     0x7fff5da3ffff  com.apple.NetAuth (6.2 - 6.2) <D324C7CC-E614-35F6-8619-DECBE90ECAEB> /System/Library/PrivateFrameworks/NetAuth.framework/Versions/A/NetAuth
    0x7fff66c9f000 -     0x7fff66cafff3  com.apple.TCC (1.0 - 1) <AEE98D6E-03FD-3C80-90AC-5B45B4AE7A2E> /System/Library/PrivateFrameworks/TCC.framework/Versions/A/TCC
    0x7fff6a37a000 -     0x7fff6a37cff3  com.apple.loginsupport (1.0 - 1) <B84ABC31-431B-3F99-BABE-44ED0A7DB3C0> /System/Library/PrivateFrameworks/login.framework/Versions/A/Frameworks/loginsupport.framework/Versions/A/loginsupport
    0x7fff6ce95000 -     0x7fff6cec9fff  libCRFSuite.dylib (48) <E52BECF7-1819-3998-ACC4-8D1A332CE4EB> /usr/lib/libCRFSuite.dylib
    0x7fff6cecc000 -     0x7fff6ced6fff  libChineseTokenizer.dylib (34) <EE842A48-3D30-34B0-B9D2-F045DE582650> /usr/lib/libChineseTokenizer.dylib
    0x7fff6cf62000 -     0x7fff6cf64ff7  libDiagnosticMessagesClient.dylib (112) <BE749883-9400-334A-8FBF-F3321CF205F5> /usr/lib/libDiagnosticMessagesClient.dylib
    0x7fff6d438000 -     0x7fff6d439fff  libSystem.B.dylib (1281.100.1) <DB8310F1-272D-3533-A840-3B390AF55C26> /usr/lib/libSystem.B.dylib
    0x7fff6d4c6000 -     0x7fff6d4c7fff  libThaiTokenizer.dylib (3) <DC582222-7C1F-3C27-8C3A-BAF696A2197D> /usr/lib/libThaiTokenizer.dylib
    0x7fff6d4df000 -     0x7fff6d4f5fff  libapple_nghttp2.dylib (1.39.2) <268F4E3E-95DC-35FB-82DC-5B0D1855A676> /usr/lib/libapple_nghttp2.dylib
    0x7fff6d52a000 -     0x7fff6d59cff7  libarchive.2.dylib (72.100.1) <65E0870E-02AB-365D-84F9-5800B5BB69FC> /usr/lib/libarchive.2.dylib
    0x7fff6d63a000 -     0x7fff6d63aff3  libauto.dylib (187) <FD0E5750-7004-36A7-B9C2-D6B6B4EF559B> /usr/lib/libauto.dylib
    0x7fff6d700000 -     0x7fff6d710ffb  libbsm.0.dylib (60.100.1) <B0373A39-DBC6-3A84-879B-BA46E30D04BF> /usr/lib/libbsm.0.dylib
    0x7fff6d711000 -     0x7fff6d71dfff  libbz2.1.0.dylib (44) <FFCD4427-AF87-36D2-8097-8870FDC75A1B> /usr/lib/libbz2.1.0.dylib
    0x7fff6d71e000 -     0x7fff6d770fff  libc++.1.dylib (902.1) <08199809-33CA-321E-9B9D-FD5B2BC64580> /usr/lib/libc++.1.dylib
    0x7fff6d771000 -     0x7fff6d786ffb  libc++abi.dylib (902) <1C880020-396D-3F91-BE27-5A09A9239F68> /usr/lib/libc++abi.dylib
    0x7fff6d787000 -     0x7fff6d787fff  libcharset.1.dylib (59) <4E63BA25-04A3-329A-923D-251155C03F30> /usr/lib/libcharset.1.dylib
    0x7fff6d788000 -     0x7fff6d799fff  libcmph.dylib (8) <D4C5E0A8-92D9-33D5-9F83-6F4742FFBE29> /usr/lib/libcmph.dylib
    0x7fff6d79a000 -     0x7fff6d7b1fd7  libcompression.dylib (87) <7F258A06-E01D-32D2-9CD2-6B2931DA5DA7> /usr/lib/libcompression.dylib
    0x7fff6da8b000 -     0x7fff6daa1ff7  libcoretls.dylib (167) <EFC237BB-78F7-33C6-BFF9-53860062DD99> /usr/lib/libcoretls.dylib
    0x7fff6daa2000 -     0x7fff6daa3fff  libcoretls_cfhelpers.dylib (167) <2E542A2B-7730-33EE-9B3B-154B08608AA6> /usr/lib/libcoretls_cfhelpers.dylib
    0x7fff6e1cb000 -     0x7fff6e1cbfff  libenergytrace.dylib (21) <FFB9FB70-8DBD-3025-BC92-51F02481A489> /usr/lib/libenergytrace.dylib
    0x7fff6e1f2000 -     0x7fff6e1f4fff  libfakelink.dylib (149.1) <B04F9A05-7E52-3382-9186-F603BE4BFBB2> /usr/lib/libfakelink.dylib
    0x7fff6e203000 -     0x7fff6e208fff  libgermantok.dylib (24) <8091F952-B592-38E3-982B-7DEA0A44E211> /usr/lib/libgermantok.dylib
    0x7fff6e213000 -     0x7fff6e303fff  libiconv.2.dylib (59) <9458704B-A702-37CB-9707-66ABBB5DB71E> /usr/lib/libiconv.2.dylib
    0x7fff6e304000 -     0x7fff6e55bfff  libicucore.A.dylib (64260.0.1) <DCC4A4EE-32FD-350F-84D8-E857F2F29855> /usr/lib/libicucore.A.dylib
    0x7fff6e575000 -     0x7fff6e576fff  liblangid.dylib (133) <E9595222-602B-38F0-8572-0F1872A00527> /usr/lib/liblangid.dylib
    0x7fff6e577000 -     0x7fff6e58fff3  liblzma.5.dylib (16) <0AA1EB11-A433-327E-B8DB-7395CFF06554> /usr/lib/liblzma.5.dylib
    0x7fff6e5a7000 -     0x7fff6e64eff7  libmecab.dylib (883.10) <13136C11-8763-37BA-AEB2-676092798DAA> /usr/lib/libmecab.dylib
    0x7fff6e64f000 -     0x7fff6e8b1fe1  libmecabra.dylib (883.10) <6AC22857-F528-35CE-94A9-D70F6F766C15> /usr/lib/libmecabra.dylib
    0x7fff6ed7d000 -     0x7fff6f1f8ff5  libnetwork.dylib (1880.100.30) <9519B6F8-44E2-3F53-B995-1527C5333240> /usr/lib/libnetwork.dylib
    0x7fff6f298000 -     0x7fff6f2cbfde  libobjc.A.dylib (787.1) <20AC082F-2DB7-3974-A2D4-8C5E01787584> /usr/lib/libobjc.A.dylib
    0x7fff6f2de000 -     0x7fff6f2e2fff  libpam.2.dylib (25.100.1) <D5CEC1AD-A2EC-362C-B71A-22FD521917F1> /usr/lib/libpam.2.dylib
    0x7fff6f2e5000 -     0x7fff6f31bff7  libpcap.A.dylib (89.100.1) <171BAAB0-A5C8-32C5-878E-83D46073BF8C> /usr/lib/libpcap.A.dylib
    0x7fff6f413000 -     0x7fff6f5fdff7  libsqlite3.dylib (308.4) <BBC375B7-AF20-3D2C-8826-78D3BDC8A004> /usr/lib/libsqlite3.dylib
    0x7fff6f721000 -     0x7fff6f76bff7  libstdc++.6.dylib (104.1) <3779D567-DCA6-3175-AC9B-0A8293DA5E70> /usr/lib/libstdc++.6.dylib
    0x7fff6f84e000 -     0x7fff6f851ffb  libutil.dylib (57) <07ED7CF0-1744-3386-B8B2-0DDBD446999E> /usr/lib/libutil.dylib
    0x7fff6f852000 -     0x7fff6f85fff7  libxar.1.dylib (425.2) <625F24E1-1A0F-3301-9F99-F0F3DADE0287> /usr/lib/libxar.1.dylib
    0x7fff6f865000 -     0x7fff6f947ff7  libxml2.2.dylib (33.3) <24147A90-E3EB-3926-BFB0-5F0FC9F706E2> /usr/lib/libxml2.2.dylib
    0x7fff6f94b000 -     0x7fff6f973fff  libxslt.1.dylib (16.9) <8C8648B1-F2CA-38EA-A409-D6F19715C6E6> /usr/lib/libxslt.1.dylib
    0x7fff6f974000 -     0x7fff6f986ff3  libz.1.dylib (76) <6A449C6A-DF88-36C1-8F2D-DB9A808263B5> /usr/lib/libz.1.dylib
    0x7fff70234000 -     0x7fff70239ff3  libcache.dylib (83) <5F90FFCE-403B-3724-991D-BA32401D99C5> /usr/lib/system/libcache.dylib
    0x7fff7023a000 -     0x7fff70245fff  libcommonCrypto.dylib (60165) <C7A5E3F7-1E5A-3785-875A-B6647082B614> /usr/lib/system/libcommonCrypto.dylib
    0x7fff70246000 -     0x7fff7024dfff  libcompiler_rt.dylib (101.2) <A517E149-2D25-3C04-BCEF-F69149C85B18> /usr/lib/system/libcompiler_rt.dylib
    0x7fff7024e000 -     0x7fff70257ff7  libcopyfile.dylib (166.40.1) <1A5270B5-0D97-35DA-9296-4F4A428BC6A2> /usr/lib/system/libcopyfile.dylib
    0x7fff70258000 -     0x7fff702eafe3  libcorecrypto.dylib (866.100.30) <FCDEC0D1-8C30-3989-BDD1-996BBC715C29> /usr/lib/system/libcorecrypto.dylib
    0x7fff703f7000 -     0x7fff70437ff0  libdispatch.dylib (1173.100.2) <EB592997-B11C-3AB3-85B1-F725F3D0B412> /usr/lib/system/libdispatch.dylib
    0x7fff70438000 -     0x7fff7046efff  libdyld.dylib (750.5) <D2A07EF5-A64B-3692-BE13-89DAA2EC5E80> /usr/lib/system/libdyld.dylib
    0x7fff7046f000 -     0x7fff7046fffb  libkeymgr.dylib (30) <CC5A2B43-770B-3C6C-BA10-AA3A6B4A142D> /usr/lib/system/libkeymgr.dylib
    0x7fff70470000 -     0x7fff7047cff3  libkxld.dylib (6153.101.6) <77282DCB-83D6-3199-874E-9A4A0FD7D4F3> /usr/lib/system/libkxld.dylib
    0x7fff7047d000 -     0x7fff7047dff7  liblaunch.dylib (1738.100.39) <A7FF7357-600F-3014-8C28-A4F367717E8D> /usr/lib/system/liblaunch.dylib
    0x7fff7047e000 -     0x7fff70483ff7  libmacho.dylib (959.0.1) <D8FED478-25A2-3844-AE4B-A5C9F9827615> /usr/lib/system/libmacho.dylib
    0x7fff70484000 -     0x7fff70486ff3  libquarantine.dylib (110.40.3) <51E0304F-AB11-3BF7-99DC-BB916CC9088B> /usr/lib/system/libquarantine.dylib
    0x7fff70487000 -     0x7fff70488ff7  libremovefile.dylib (48) <078F29AB-26BA-3493-BCAA-E1E75A187521> /usr/lib/system/libremovefile.dylib
    0x7fff70489000 -     0x7fff704a0ff3  libsystem_asl.dylib (377.60.2) <0F1BAC19-2AE0-3F8E-9B90-AACF819B2BF7> /usr/lib/system/libsystem_asl.dylib
    0x7fff704a1000 -     0x7fff704a1ff7  libsystem_blocks.dylib (74) <32224AFF-C06F-3279-B753-097194EDEF49> /usr/lib/system/libsystem_blocks.dylib
    0x7fff704a2000 -     0x7fff70529fff  libsystem_c.dylib (1353.100.2) <4F5EED22-4D46-3F04-8C64-C492CDAD70EB> /usr/lib/system/libsystem_c.dylib
    0x7fff7052a000 -     0x7fff7052dffb  libsystem_configuration.dylib (1061.101.1) <2A2C778D-07EB-35C7-A954-8BF8FD74BD75> /usr/lib/system/libsystem_configuration.dylib
    0x7fff7052e000 -     0x7fff70531fff  libsystem_coreservices.dylib (114) <FDA41CC4-170A-3D93-85BD-838A563B03C4> /usr/lib/system/libsystem_coreservices.dylib
    0x7fff70532000 -     0x7fff7053afff  libsystem_darwin.dylib (1353.100.2) <B567B86D-8818-38A4-A861-03EB83B55867> /usr/lib/system/libsystem_darwin.dylib
    0x7fff7053b000 -     0x7fff70542fff  libsystem_dnssd.dylib (1096.100.3) <7C690DF5-E119-33FB-85CD-9EFC67A36E40> /usr/lib/system/libsystem_dnssd.dylib
    0x7fff70543000 -     0x7fff70544ffb  libsystem_featureflags.dylib (17) <415D83EF-084C-3485-B757-53001870EA94> /usr/lib/system/libsystem_featureflags.dylib
    0x7fff70545000 -     0x7fff70592ff7  libsystem_info.dylib (538) <17049D3F-C798-3651-B391-1551FC699D3E> /usr/lib/system/libsystem_info.dylib
    0x7fff70593000 -     0x7fff705bfff7  libsystem_kernel.dylib (6153.101.6) <E76440E1-D1E8-3D9A-8B47-D01F554FF1C4> /usr/lib/system/libsystem_kernel.dylib
    0x7fff705c0000 -     0x7fff70607fff  libsystem_m.dylib (3178) <74741FA8-5C29-3241-9046-4FC91C6A6D4A> /usr/lib/system/libsystem_m.dylib
    0x7fff70608000 -     0x7fff7062ffff  libsystem_malloc.dylib (283.100.5) <97833239-2F83-3AEB-A426-0593997C8A54> /usr/lib/system/libsystem_malloc.dylib
    0x7fff70630000 -     0x7fff7063dffb  libsystem_networkextension.dylib (1095.100.29) <C9E988B2-6A18-35C0-9577-63201E9D6018> /usr/lib/system/libsystem_networkextension.dylib
    0x7fff7063e000 -     0x7fff70647ff7  libsystem_notify.dylib (241.100.2) <E405F84B-BD4F-3874-9755-CB3EC86E18D5> /usr/lib/system/libsystem_notify.dylib
    0x7fff70648000 -     0x7fff70650fef  libsystem_platform.dylib (220.100.1) <6EF12F34-C33F-36BF-9A9A-2A35EA19EFE0> /usr/lib/system/libsystem_platform.dylib
    0x7fff70651000 -     0x7fff7065bfff  libsystem_pthread.dylib (416.100.3) <A8514582-E000-3854-911A-0A73D2C79600> /usr/lib/system/libsystem_pthread.dylib
    0x7fff7065c000 -     0x7fff70660ff3  libsystem_sandbox.dylib (1217.101.2) <E9D78CDE-FB67-32E7-BABC-9EFC23AA0DC6> /usr/lib/system/libsystem_sandbox.dylib
    0x7fff70661000 -     0x7fff70663fff  libsystem_secinit.dylib (62.100.2) <AAC639E5-7103-3366-A602-8FC6944E2C13> /usr/lib/system/libsystem_secinit.dylib
    0x7fff70664000 -     0x7fff7066bffb  libsystem_symptoms.dylib (1238.100.26) <487B92DE-45F9-39F9-A478-89BBD478157D> /usr/lib/system/libsystem_symptoms.dylib
    0x7fff7066c000 -     0x7fff70682ff2  libsystem_trace.dylib (1147.100.8) <BB90B1FD-8C09-3DF4-BD8B-9E4AEADFEA2B> /usr/lib/system/libsystem_trace.dylib
    0x7fff70684000 -     0x7fff70689ff7  libunwind.dylib (35.4) <CC87C836-BE9D-334E-A0E6-0297D52E9D73> /usr/lib/system/libunwind.dylib
    0x7fff7068a000 -     0x7fff706bfffe  libxpc.dylib (1738.100.39) <32B0E31E-9DA3-328B-A962-BC9591B93537> /usr/lib/system/libxpc.dylib

External Modification Summary:
  Calls made by other processes targeting this process:
    task_for_pid: 0
    thread_create: 0
    thread_set_state: 0
  Calls made by this process:
    task_for_pid: 0
    thread_create: 0
    thread_set_state: 0
  Calls made by all processes on this machine:
    task_for_pid: 377155
    thread_create: 0
    thread_set_state: 0

VM Region Summary:
ReadOnly portion of Libraries: Total=1.1G resident=0K(0%) swapped_out_or_unallocated=1.1G(100%)
Writable regions: Total=249.6M written=0K(0%) resident=0K(0%) swapped_out=0K(0%) unallocated=249.6M(100%)
 
                                VIRTUAL   REGION 
REGION TYPE                        SIZE    COUNT (non-coalesced) 
===========                     =======  ======= 
Kernel Alloc Once                    8K        1 
MALLOC                            87.9M       61 
MALLOC guard page                   16K        4 
MALLOC_LARGE (reserved)            640K        2         reserved VM address space (unallocated)
STACK GUARD                          4K        1 
Stack                             16.0M        1 
VM_ALLOCATE                       47.3M      190 
VM_ALLOCATE (reserved)            96.0M        2         reserved VM address space (unallocated)
__DATA                            17.6M      281 
__DATA_CONST                       420K       47 
__LINKEDIT                       602.9M      118 
__OBJC_RO                         32.2M        1 
__OBJC_RW                         1892K        2 
__TEXT                           482.1M      236 
__UNICODE                          564K        1 
shared memory                       12K        3 
===========                     =======  ======= 
TOTAL                              1.4G      951 
TOTAL, minus reserved VM space     1.3G      951 

Model: MacBookPro15,4, BootROM 1037.100.362.0.0 (iBridge: 17.16.14281.0.0,0), 4 processors, Quad-Core Intel Core i5, 1.4 GHz, 16 GB, SMC 
Graphics: kHW_IntelIrisGraphics645Item, Intel Iris Plus Graphics 645, spdisplays_builtin
Memory Module: BANK 0/ChannelA-DIMM0, 8 GB, LPDDR3, 2133 MHz, SK Hynix, -
Memory Module: BANK 2/ChannelB-DIMM0, 8 GB, LPDDR3, 2133 MHz, SK Hynix, -
AirPort: spairport_wireless_card_type_airport_extreme, wl0: Feb 28 2020 15:26:30 version 16.20.192.27.3.6.77 FWID 01-f80dbb9b
Bluetooth: Version 7.0.4f6, 3 services, 27 devices, 1 incoming serial ports
Network Service: Wi-Fi, AirPort, en0
USB Device: USB 3.1 Bus
USB Device: 2.4G Receiver
USB Device: Apple T2 Bus
USB Device: Touch Bar Backlight
USB Device: Touch Bar Display
USB Device: Apple Internal Keyboard / Trackpad
USB Device: Headset
USB Device: Ambient Light Sensor
USB Device: FaceTime HD Camera (Built-in)
USB Device: Apple T2 Controller
Thunderbolt Bus: MacBook Pro, Apple Inc., 51.1

----------
components: macOS
messages: 367390
nosy: drliu, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: Python quit unexpectedly
versions: Python 3.7

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

From report at bugs.python.org  Mon Apr 27 07:14:50 2020
From: report at bugs.python.org (Bar Harel)
Date: Mon, 27 Apr 2020 11:14:50 +0000
Subject: [New-bugs-announce] [issue40405] ast
Message-ID: <1587986090.72.0.850288416668.issue40405@roundup.psfhosted.org>


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

Continuing with bpo-27589, looks like as_completed documentation is still misleading. According to the docs, it "Return(s) an iterator of Future objects. Each Future object returned represents the earliest result from the set of the remaining awaitables."

There's only one problem: The only thing it definitely doesn't do, is return an iterator of future objects. To be honest with you, I'm not entirely sure how to phrase it.

For reference, I fell for this:

mapping = {fut: index for fut, index in enumerate(futures)}
for fut in as_completed(mapping):
  mapping[fut]  # KeyError

----------
assignee: docs at python
components: Documentation, asyncio
messages: 367410
nosy: aronacher, asvetlov, bar.harel, docs at python, gvanrossum, hynek, vstinner, xtreak, yselivanov
priority: normal
severity: normal
status: open
title: ast
versions: Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Mon Apr 27 09:33:28 2020
From: report at bugs.python.org (Thomas Grainger)
Date: Mon, 27 Apr 2020 13:33:28 +0000
Subject: [New-bugs-announce] [issue40406] MagicMock __aenter__ should be
 AsyncMock(return_value=MagicMock())
Message-ID: <1587994408.9.0.812209740883.issue40406@roundup.psfhosted.org>


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

aentering a MagicMock() results in an AsyncMock which behaves differently than I expected:

```
python3.9 -m asyncio
asyncio REPL 3.9.0a5 (default, Apr 18 2020, 00:00:31) 
[GCC 9.3.0] on linux
Use "await" directly instead of "asyncio.run()".
Type "help", "copyright", "credits" or "license" for more information.
>>> import asyncio
>>> from unittest import mock
>>> with mock.MagicMock() as m:
...     with m.foo() as u:
...         u.hello()
... 
<MagicMock name='mock.__enter__().foo().__enter__().hello()' id='140670894620048'>
>>> async with mock.MagicMock() as m:
...     async with m.foo() as u:
...         u.hello()
... 
<console>:2: RuntimeWarning: coroutine 'AsyncMockMixin._execute_mock_call' was never awaited
RuntimeWarning: Enable tracemalloc to get the object allocation traceback
Traceback (most recent call last):
  File "/usr/lib/python3.9/concurrent/futures/_base.py", line 439, in result
    return self.__get_result()
  File "/usr/lib/python3.9/concurrent/futures/_base.py", line 388, in __get_result
    raise self._exception
  File "<console>", line 2, in <module>
AttributeError: __aenter__
```

This is annoying for mocking database interfaces like

```
async def update_users(db, user):
    async with db.connection() as conn:
        async with conn.transaction() as tx:
            ...
```

----------
components: Tests, asyncio
messages: 367419
nosy: asvetlov, graingert, yselivanov
priority: normal
severity: normal
status: open
title: MagicMock __aenter__ should be AsyncMock(return_value=MagicMock())
versions: Python 3.8, Python 3.9

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

From report at bugs.python.org  Mon Apr 27 11:17:58 2020
From: report at bugs.python.org (=?utf-8?b?6rmA7KeA7ZuI?=)
Date: Mon, 27 Apr 2020 15:17:58 +0000
Subject: [New-bugs-announce] [issue40407] Zipfile couldn`t recognized
 character set rightly.
Message-ID: <1588000678.57.0.461120883839.issue40407@roundup.psfhosted.org>


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

Hi,

I am not a developer.
However, when I inquired about an abnormality of an open source program before,
it was said that there was a problem with the Zipfile module of Python.
So I would like to ask it here.

I`m a Korean, and a Windows user.
And there are useful Windows compression programs in Korea.
However, when using those compression programs, Debian's unzip utility finds character sets well, but fails to find in the case of python.

If you look at the attached file,
(File size is too large, so attach it elsewhere - https://kutt.it/2F2Xec)
there are other compressed files in the compressed file.
The names in the compressed file are the names of the compressed programs.

And, as I have seen, the result of the basic compression is:
7zip : UTF-8
Alzip : UTF-8
BandiZip : EUC-KR
BreadZip : EUC-KR
PKZip : UTF-8
StarZip : EUC-KR
WinRAR : UTF-8
WinZIP : EUC-KR
Zipware : EUC-KR

BandiZip and Alzip are the two programs that compete in Korea.
I use BandiZip with few ads and this supports multi-core for compression.
StarZip is also a Korean program, but its share is not high.
BreadZip is also a Korean program, which has been used a lot, but has been discontinued and used only for some people.

Anyway, it can be considered that compression softwares in Korea use both EUC-KR and UTF-8 formats. However, the Zipfile module does not recognize this properly.

----------
components: 2to3 (2.x to 3.x conversion tool)
messages: 367429
nosy: ???
priority: normal
severity: normal
status: open
title: Zipfile couldn`t recognized character set rightly.
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Mon Apr 27 11:57:57 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 27 Apr 2020 15:57:57 +0000
Subject: [New-bugs-announce] [issue40408] GenericAlias does not support
 nested type variables
Message-ID: <1588003077.18.0.979842098769.issue40408@roundup.psfhosted.org>


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

While trying to replace typing._GenericAlias with GenericAlias I have found that the latter does not support nested type variables.

>>> from typing import *
>>> T = TypeVar('T')
>>> X = List[List[T]]
>>> X.__parameters__
(~T,)
>>> X[int]
typing.List[typing.List[int]]
>>> Y = list[list[T]]
>>> Y.__parameters__
()
>>> Y[int]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: There are no type variables left in list[list[~T]]

----------
components: Interpreter Core
messages: 367433
nosy: gvanrossum, levkivskyi, serhiy.storchaka
priority: normal
severity: normal
status: open
title: GenericAlias does not support nested type variables
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Mon Apr 27 15:59:49 2020
From: report at bugs.python.org (Samani Gikandi)
Date: Mon, 27 Apr 2020 19:59:49 +0000
Subject: [New-bugs-announce] [issue40409] urllib.parse.urlsplit parses
 schemes that do not begin with letters
Message-ID: <1588017589.4.0.372039789784.issue40409@roundup.psfhosted.org>


New submission from Samani Gikandi <samani at gojulas.com>:

RFC 3986 (STD66) says that a URL scheme should begin with an "letter", however urllib.parse.urlsplit (and urlparse) parse strings that don't adhere to this as valid schemes.

Example from Python3.8 using "+git+ssh://git at github.com/user/project.git":

>>> from urllib.parse import urlsplit, urlparse
>>> urlparse("+git+ssh://git at github.com/user/project.git")
ParseResult(scheme='+git+ssh', netloc='git at github.com', path='/user/project.git', params='', query='', fragment='')
>>> urlsplit("+git+ssh://git at github.com/user/project.git")
SplitResult(scheme='+git+ssh', netloc='git at github.com', path='/user/project.git', query='', fragment='')

I double checked this behavior and number of other languages (Rust, Go, Javascript, Ruby) all complain if you try to use parse this URL

For reference, RFC3986 section 3.1 --

Scheme names consist of a sequence of characters beginning with a
   letter and followed by any combination of letters, digits, plus
   ("+"), period ("."), or hyphen ("-"). 

   [...]

   scheme      = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." )

----------
components: Library (Lib)
messages: 367452
nosy: sgg
priority: normal
severity: normal
status: open
title: urllib.parse.urlsplit parses schemes that do not begin with letters
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/issue40409>
_______________________________________

From report at bugs.python.org  Mon Apr 27 17:00:54 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 27 Apr 2020 21:00:54 +0000
Subject: [New-bugs-announce] [issue40410]
 test_multiprocessing_forktest_terminate() timed out after 15 min on s390x
 Fedora LTO + PGO 3.x
Message-ID: <1588021254.28.0.401763643257.issue40410@roundup.psfhosted.org>


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

s390x Fedora LTO + PGO 3.x:
https://buildbot.python.org/all/#/builders/460/builds/364

0:15:21 load avg: 0.00 [423/423/1] test_multiprocessing_fork crashed (Exit code 1)
Timeout (0:15:00)!
Thread 0x000003ff83dff910 (most recent call first):
  File "/home/dje/cpython-buildarea/3.x.edelsohn-fedora-z.lto-pgo/build/Lib/multiprocessing/connection.py", line 384 in _recv
  File "/home/dje/cpython-buildarea/3.x.edelsohn-fedora-z.lto-pgo/build/Lib/multiprocessing/connection.py", line 419 in _recv_bytes
  File "/home/dje/cpython-buildarea/3.x.edelsohn-fedora-z.lto-pgo/build/Lib/multiprocessing/connection.py", line 255 in recv
  File "/home/dje/cpython-buildarea/3.x.edelsohn-fedora-z.lto-pgo/build/Lib/multiprocessing/pool.py", line 600 in _handle_results
  File "/home/dje/cpython-buildarea/3.x.edelsohn-fedora-z.lto-pgo/build/Lib/threading.py", line 888 in run
  File "/home/dje/cpython-buildarea/3.x.edelsohn-fedora-z.lto-pgo/build/Lib/threading.py", line 950 in _bootstrap_inner
  File "/home/dje/cpython-buildarea/3.x.edelsohn-fedora-z.lto-pgo/build/Lib/threading.py", line 908 in _bootstrap

Thread 0x000003ff976f8b20 (most recent call first):
  File "/home/dje/cpython-buildarea/3.x.edelsohn-fedora-z.lto-pgo/build/Lib/multiprocessing/pool.py", line 673 in _help_stuff_finish
  File "/home/dje/cpython-buildarea/3.x.edelsohn-fedora-z.lto-pgo/build/Lib/multiprocessing/pool.py", line 693 in _terminate_pool
  File "/home/dje/cpython-buildarea/3.x.edelsohn-fedora-z.lto-pgo/build/Lib/multiprocessing/util.py", line 224 in __call__
  File "/home/dje/cpython-buildarea/3.x.edelsohn-fedora-z.lto-pgo/build/Lib/multiprocessing/pool.py", line 655 in terminate
  File "/home/dje/cpython-buildarea/3.x.edelsohn-fedora-z.lto-pgo/build/Lib/test/_test_multiprocessing.py", line 2546 in test_terminate
  (...)

----------
components: Tests
messages: 367457
nosy: vstinner
priority: normal
severity: normal
status: open
title: test_multiprocessing_forktest_terminate() timed out after 15 min on s390x Fedora LTO + PGO 3.x
versions: Python 3.9

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

From report at bugs.python.org  Mon Apr 27 19:59:59 2020
From: report at bugs.python.org (paul rubin)
Date: Mon, 27 Apr 2020 23:59:59 +0000
Subject: [New-bugs-announce] [issue40411] frozen collection.Counter
Message-ID: <1588031999.2.0.641079021792.issue40411@roundup.psfhosted.org>


New submission from paul rubin <phr-pythonbugs at nightsong.com>:

It would be nice to have frozen Counters analogous to frozensets, so they are usable as dictionary keys.  One can of course create frozenset(counter.items()) but that means the set items are tuples rather than the original set elements, so it's no longer quick to check membership.  I can work around this in my immediate application but it seems like a shortcoming.  There are some other set operations that aren't supported by counters either, that would be nice if they are conceptually multisets.

----------
components: Library (Lib)
messages: 367472
nosy: phr
priority: normal
severity: normal
status: open
title: frozen collection.Counter
type: enhancement

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

From report at bugs.python.org  Mon Apr 27 20:51:49 2020
From: report at bugs.python.org (Gregory Szorc)
Date: Tue, 28 Apr 2020 00:51:49 +0000
Subject: [New-bugs-announce] [issue40412] inittab_copy not set to NULL after
 free,
 can lead to crashes when running multiple interpreters in a single process
Message-ID: <1588035109.97.0.994346077967.issue40412@roundup.psfhosted.org>


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

Filing a bug to placate the requirement that pull requests have issues.

----------
components: C API
messages: 367477
nosy: indygreg
priority: normal
severity: normal
status: open
title: inittab_copy not set to NULL after free, can lead to crashes when running multiple interpreters in a single process
type: crash
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/issue40412>
_______________________________________

From report at bugs.python.org  Mon Apr 27 21:54:31 2020
From: report at bugs.python.org (Gregory Szorc)
Date: Tue, 28 Apr 2020 01:54:31 +0000
Subject: [New-bugs-announce] [issue40413] Py_RunMain() crashes on
 subsequence call
Message-ID: <1588038871.72.0.754759187006.issue40413@roundup.psfhosted.org>


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

I'm attempting to perform the following actions multiple times in a single process with CPython 3.8.2:

1) Initialize an interpreter using the PEP-587 APIs.
2) Call Py_RunMain() (which finalizes the interpreter).

However, I've encountered at least 2 crashes due to use-after-free or unchecked NULL access (due to apparent state getting funky).

Are multiple interpreters / Py_RunMain() calls in a single process supported? Should I file bugs for all of the crashes I encounter?

----------
components: C API
messages: 367479
nosy: indygreg, vstinner
priority: normal
severity: normal
status: open
title: Py_RunMain() crashes on subsequence call
type: crash
versions: Python 3.8, Python 3.9

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

From report at bugs.python.org  Mon Apr 27 22:06:14 2020
From: report at bugs.python.org (Jah-On)
Date: Tue, 28 Apr 2020 02:06:14 +0000
Subject: [New-bugs-announce] [issue40414] Incorrect mouse and keyboard
 mapping
Message-ID: <1588039574.12.0.381855507551.issue40414@roundup.psfhosted.org>


New submission from Jah-On <john.schulz1 at protonmail.com>:

Hi all,
On Ubuntu Cinnamon Remix, with python3, and tkinter,

canvas.bind("<1>", callback)
canvas.bind("<2>", callback)
canvas.bind("<3>", callback)
canvas.bind("<4>", callback)
canvas.bind("<5>", callback)

are now mapped to mouse buttons, instead of keyboard number buttons.

----------
components: Tkinter
messages: 367481
nosy: Jah-On
priority: normal
severity: normal
status: open
title: Incorrect mouse and keyboard mapping
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Mon Apr 27 22:27:25 2020
From: report at bugs.python.org (Gregory Szorc)
Date: Tue, 28 Apr 2020 02:27:25 +0000
Subject: [New-bugs-announce] [issue40415] _asyncio extensions crashes if
 initialized multiple times in same process
Message-ID: <1588040845.09.0.680555822876.issue40415@roundup.psfhosted.org>


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

Most of CPython's extensions can be initialized and freed multiple times in the same process. However, _asyncio crashes on at least CPython 3.8.2 when this is done.

STR:

1. Create a new Python interpreter
2. Have it import _asyncio
3. Finalize that interpreter.
4. Create a new Python interpreter
5. Have it import _asyncio

There are probably STR in pure Python by forcing _imp.create_dynamic() to run multiple times after the module is unloaded.

The crash occurs due to unchecked NULL access in `Py_INCREF(all_tasks);` in `PyInit__asyncio()`.

I think the underlying problem is module_init() is short-circuiting because `module_initialized` is set. And `module_initialized` is set on subsequent module loads because `module_free()` isn't clearing it.

----------
components: asyncio
messages: 367483
nosy: asvetlov, indygreg, yselivanov
priority: normal
severity: normal
status: open
title: _asyncio extensions crashes if initialized multiple times in same process
versions: Python 3.8, Python 3.9

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

From report at bugs.python.org  Tue Apr 28 00:33:56 2020
From: report at bugs.python.org (Rob Malouf)
Date: Tue, 28 Apr 2020 04:33:56 +0000
Subject: [New-bugs-announce] [issue40416] Calling TextIOWrapper.tell() in
 the middle of reading a gb2312-encoded file causes UnicodeDecodeError
Message-ID: <1588048436.43.0.594940005352.issue40416@roundup.psfhosted.org>


New submission from Rob Malouf <rmalouf at mail.sdsu.edu>:

Calling TextIOWrapper.tell() while reading the attached gb2312-encoded file like this:

with open('udhr-gb2312.txt', encoding='GB2312') as f: 
    while True: 
       line = f.readline() 
       t = f.tell()
       if not line: 
           break 

gives this result:

Traceback (most recent call last):
  File "test.py", line 4, in <module>
    t = f.tell()
UnicodeDecodeError: 'gb2312' codec can't decode byte 0xb5 in position 0: illegal multibyte sequence

The file seems to be well-formed and can be read without any problem.  It's only the call to tell() that raises an issue.

----------
components: IO, Unicode
files: udhr-gb2312.txt
messages: 367494
nosy: ezio.melotti, rmalouf, vstinner
priority: normal
severity: normal
status: open
title: Calling TextIOWrapper.tell() in the middle of reading a gb2312-encoded file causes UnicodeDecodeError
type: crash
versions: Python 3.7
Added file: https://bugs.python.org/file49096/udhr-gb2312.txt

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

From report at bugs.python.org  Tue Apr 28 02:40:55 2020
From: report at bugs.python.org (Robert Rouhani)
Date: Tue, 28 Apr 2020 06:40:55 +0000
Subject: [New-bugs-announce] [issue40417] PyImport_ReloadModule emits
 deprecation warning
Message-ID: <1588056055.69.0.268035650537.issue40417@roundup.psfhosted.org>


New submission from Robert Rouhani <robert.rouhani at gmail.com>:

It appears as though PyImport_ReloadModule is importing the deprecated "imp" module.

I integrated a newer version of Python into Unreal Engine 4, which internally calls this function for some of it's own modules. Normally a stray warning wouldn't be of much concern to me, but the process of "cooking" (converting raw assets to optimized/final assets) will fail if anything is written to stderr. This makes it impossible to package a copy of the game for testing or release without a workaround.

I'm going to add a test to _testembed.c to verify my fix. Is this something that I should include in the Github PR?

----------
components: Interpreter Core
messages: 367501
nosy: Robert Rouhani
priority: normal
severity: normal
status: open
title: PyImport_ReloadModule emits deprecation warning
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/issue40417>
_______________________________________

From report at bugs.python.org  Tue Apr 28 02:55:28 2020
From: report at bugs.python.org (Dennis Sweeney)
Date: Tue, 28 Apr 2020 06:55:28 +0000
Subject: [New-bugs-announce] [issue40418] Small Refactoring: Use the
 bytes.hex() in secrets.token_hex()
Message-ID: <1588056928.85.0.969050564689.issue40418@roundup.psfhosted.org>


New submission from Dennis Sweeney <sweeney.dennis650 at gmail.com>:

Since bytes.hex() was added in 3.5, we should be able to make the following change:

    diff --git a/Lib/secrets.py b/Lib/secrets.py
    index a546efbdd4..1dd8629f52 100644
    --- a/Lib/secrets.py
    +++ b/Lib/secrets.py
    @@ -13,7 +13,6 @@ __all__ = ['choice', 'randbelow', 'randbits',     'SystemRandom',
    
    
     import base64
    -import binascii
    
     from hmac import compare_digest
     from random import SystemRandom
    @@ -56,7 +55,7 @@ def token_hex(nbytes=None):
         'f9bf78b9a18ce6d46a0cd2b0b86df9da'
    
         """
    -    return binascii.hexlify(token_bytes(nbytes)).decode('ascii')
    +    return token_bytes(nbytes).hex()
    
     def token_urlsafe(nbytes=None):
         """Return a random URL-safe text string, in Base64 encoding.


Performance: python -m pyperf timeit -s "from secrets import token_hex" "token_hex(...)"

    * token_hex() on master:
        Mean +- std dev: 892 ns +- 22 ns
    * token_hex() with change: 
        Mean +- std dev: 750 ns +- 22 ns
    * token_hex(1_000_000) on master:
        Mean +- std dev: 3.31 ms +- 0.08 ms
    * token_hex(1_000_000) with change: 
        Mean +- std dev: 2.34 ms +- 0.04 ms


Simpler code, better performance. Are there any downsides?

----------
components: Library (Lib)
messages: 367502
nosy: Dennis Sweeney
priority: normal
severity: normal
status: open
title: Small Refactoring: Use the bytes.hex() in secrets.token_hex()
type: performance
versions: Python 3.9

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

From report at bugs.python.org  Tue Apr 28 06:52:30 2020
From: report at bugs.python.org (Sander van Rijn)
Date: Tue, 28 Apr 2020 10:52:30 +0000
Subject: [New-bugs-announce] [issue40419] timeit CLI docs still mention old
 power sequence
Message-ID: <1588071150.59.0.956744642529.issue40419@roundup.psfhosted.org>


New submission from Sander van Rijn <svr003 at gmail.com>:

The docs for the `timeit` CLI (https://docs.python.org/3/library/timeit.html#cmdoption-timeit-h) still mention that successive powers of 10 are tried. However, as this also uses the `timeit.Timer.autorange()` function, it uses the new sequence 1, 2, 5, 10, 20, 50, ... instead.

----------
assignee: docs at python
components: Documentation
messages: 367517
nosy: Sander van Rijn, docs at python
priority: normal
severity: normal
status: open
title: timeit CLI docs still mention old power sequence
type: enhancement
versions: Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Tue Apr 28 08:34:22 2020
From: report at bugs.python.org (Leonid Ilyevsky)
Date: Tue, 28 Apr 2020 12:34:22 +0000
Subject: [New-bugs-announce] [issue40420] argparse choices formatter
Message-ID: <1588077262.4.0.512927383758.issue40420@roundup.psfhosted.org>


New submission from Leonid Ilyevsky <lilyevsky at gmail.com>:

In my script I have a positional argument with list of choices, and that list is pretty long. The help formatter shows it as one long line,  list in curly brackets, comma-separated. This is very difficult to look at and find the choice I need.
It would be nice to have an option to print the choices list one per line.

----------
components: Library (Lib)
messages: 367524
nosy: Leonid Ilyevsky
priority: normal
severity: normal
status: open
title: argparse choices formatter
type: behavior

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

From report at bugs.python.org  Tue Apr 28 09:17:50 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Apr 2020 13:17:50 +0000
Subject: [New-bugs-announce] [issue40421] [C API] Add getter functions for
 PyFrameObject and maybe move PyFrameObject to the internal C API
Message-ID: <1588079870.34.0.984904607646.issue40421@roundup.psfhosted.org>


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

Similarly to bpo-39573 (make PyObject opaque) and bpo-39947 (make PyThreadState opaque), I propose to add getter functions to access PyFrameObject members without exposing the PyFrameObject structure in the C API.

The first step is to identify common usage of the PyFrameObject structure inside CPython code base to add getter functions, and maybe a few setter functions as well.

frameobject.h is not part of Python.h, but it's part of the public C API. The long term plan is to move PyFrameObject structure to the internal C API to hide implementation details from the public C API.

----------
components: C API
messages: 367527
nosy: vstinner
priority: normal
severity: normal
status: open
title: [C API] Add getter functions for PyFrameObject and maybe move PyFrameObject to the internal C API
versions: Python 3.9

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

From report at bugs.python.org  Tue Apr 28 09:35:44 2020
From: report at bugs.python.org (Kyle Evans)
Date: Tue, 28 Apr 2020 13:35:44 +0000
Subject: [New-bugs-announce] [issue40422] Light refactor: create a common
 _Py_closerange API
Message-ID: <1588080944.1.0.768613011974.issue40422@roundup.psfhosted.org>


New submission from Kyle Evans <kevans at FreeBSD.org>:

Such an API can be used for both os.closerange and subprocess, re-using much of os_closerange_impl. Pull request enroute.

----------
components: C API
messages: 367530
nosy: kevans91
priority: normal
severity: normal
status: open
title: Light refactor: create a common _Py_closerange API
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Tue Apr 28 10:10:08 2020
From: report at bugs.python.org (Kyle Evans)
Date: Tue, 28 Apr 2020 14:10:08 +0000
Subject: [New-bugs-announce] [issue40423] Optimization: use close_range(2)
 if available
Message-ID: <1588083008.52.0.574583659738.issue40423@roundup.psfhosted.org>


New submission from Kyle Evans <kevans at FreeBSD.org>:

This is dependent on issue40422; the diff on top of that (PR19075) looks like the attached. Effectively, close_range(2) should be preferred at all times if it's available, otherwise we'll use closefrom(2) if available with a fallback to fdwalk(3) or plain old loop over fd range in order of most efficient to least.

PR will be sent after issue40422 is resolved.

----------
components: C API
files: cpython-close_range.diff
keywords: patch
messages: 367531
nosy: kevans91
priority: normal
severity: normal
status: open
title: Optimization: use close_range(2) if available
type: enhancement
versions: Python 3.9
Added file: https://bugs.python.org/file49097/cpython-close_range.diff

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

From report at bugs.python.org  Tue Apr 28 12:20:00 2020
From: report at bugs.python.org (Michael Felt)
Date: Tue, 28 Apr 2020 16:20:00 +0000
Subject: [New-bugs-announce] [issue40424] AIX: parallel build and ld WARNINGS
Message-ID: <1588090800.25.0.961976947202.issue40424@roundup.psfhosted.org>


New submission from Michael Felt <aixtools at felt.demon.nl>:

Currently, on AIX, whenever the -j option is passed to make there are many WARNINGS from the loader (ld) re: duplicate symbols.

While it is not possible to eliminate these warnings completely - as some are not related to the Python build, but external (3rd party) packaging - MOST of these warnings can be eliminated by ensuring that the export file creation completes before additional steps try to use it.

By adding a small test to see if the export file is in the process of being made - and waiting for that to finish - the messages "go away".

The PR that is being proposed only affects AIX (a script named makeaix_exp). The script has not been modified in 22 years - so I guess the -j option is something that showed up after 1998 :)

I know it is not perfect - but removes a tremendous amount of noise - most of the time.

Michael

p.s. requesting backport to 3.8 so all buildbots benefit.

----------
components: Build
messages: 367541
nosy: Michael.Felt
priority: normal
severity: normal
status: open
title: AIX: parallel build and ld WARNINGS
type: behavior
versions: Python 3.8, Python 3.9

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

From report at bugs.python.org  Tue Apr 28 13:38:18 2020
From: report at bugs.python.org (Cubi)
Date: Tue, 28 Apr 2020 17:38:18 +0000
Subject: [New-bugs-announce] [issue40425] Refleak in CDataObject
Message-ID: <1588095498.31.0.363636876654.issue40425@roundup.psfhosted.org>


New submission from Cubi <dennis-danne at protonmail.com>:

String buffers are not freed when pointers to them (created via ctypes.cast) are deleted, even though those pointers hold references to the string buffer (in tagCDataObject.b_objects, I think). Code examples can be found on StackOverflow.com [1]. Thanks to Mark Tolonen's answer on that StackOverflow post we know that it is a refcount problem.

Tested in
  Python v3.7.4 x64 on Windows 10 x64, and in
  Python v3.8.2 x64 on ArchLinux x64 (5.6.7-arch1-1)

[1] https://stackoverflow.com/q/61479041

----------
components: ctypes
messages: 367549
nosy: cubinator
priority: normal
severity: normal
status: open
title: Refleak in CDataObject
type: resource usage
versions: Python 3.8

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

From report at bugs.python.org  Tue Apr 28 14:14:11 2020
From: report at bugs.python.org (Eisuke Kawashima)
Date: Tue, 28 Apr 2020 18:14:11 +0000
Subject: [New-bugs-announce] [issue40426] Unable to use lowercase
 hexadecimal digits for percent encoding
Message-ID: <1588097651.68.0.271507304283.issue40426@roundup.psfhosted.org>


New submission from Eisuke Kawashima <e.kawaschima+python at gmail.com>:

RFC 3986 (https://tools.ietf.org/html/rfc3986#section-2.1) allows lower hexadecimal digits for percent encoding, but urllib.parse.quote and its variants convert into only UPPERCASE digits [A-F].

I will create a PR for fix.

----------
components: Library (Lib)
messages: 367551
nosy: e-kwsm
priority: normal
severity: normal
status: open
title: Unable to use lowercase hexadecimal digits for percent encoding
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Tue Apr 28 15:00:54 2020
From: report at bugs.python.org (John Andersen)
Date: Tue, 28 Apr 2020 19:00:54 +0000
Subject: [New-bugs-announce] [issue40427] importlib of module results in
 different id than when imported with import keyword
Message-ID: <1588100454.16.0.607696168199.issue40427@roundup.psfhosted.org>


New submission from John Andersen <johnandersenpdx at gmail.com>:

When importing a file using importlib the id() of the object being imported is not the same as when imported using the `import` keyword. I feel like this is a bug. As if I have a package which is using relative imports, and then I import all of the files in that package via importlib. issubclass and isinstance and others no longer work when the relative imported object and then importlib imported object are checked against each other, I assume because the id()s are different.

$ cat > target.py <<'EOF'
class Target:
    pass

EOF

$ cat > importer.py <<'EOF'
import importlib
from target import Target

spec = importlib.util.spec_from_file_location("target", "target.py")
imported_by_importlib = importlib.util.module_from_spec(spec)
spec.loader.exec_module(imported_by_importlib)

print("isinstance(imported_by_importlib.Target(), Target:",
isinstance(imported_by_importlib.Target(), Target))
print("id(Target):", id(Target))
print("id(imported_by_importlib.Target):", id(imported_by_importlib.Target))

EOF

$ python importer.py
isinstance(imported_by_importlib.Target(), Target: False
id(Target): 93824998820112
id(imported_by_importlib.Target): 93824998821056

----------
messages: 367554
nosy: pdxjohnny
priority: normal
severity: normal
status: open
title: importlib of module results in different id than when imported with import keyword
type: behavior
versions: Python 3.7

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

From report at bugs.python.org  Tue Apr 28 17:04:13 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Apr 2020 21:04:13 +0000
Subject: [New-bugs-announce] [issue40428] [C API] Move
 PyXXX_ClearFreeLists() functions to the internal C API
Message-ID: <1588107853.55.0.523053148553.issue40428@roundup.psfhosted.org>


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

The following C functions are implementation details and should not be called directly:

- PyAsyncGen_ClearFreeLists()
- PyContext_ClearFreeList()
- PyDict_ClearFreeList()
- PyFloat_ClearFreeList()
- PyFrame_ClearFreeList()
- PyList_ClearFreeList()
- PySet_ClearFreeList()
- PyTuple_ClearFreeList()

To call them all at once, simply call explicitly PyGC_Collect().

Attached PR move these functions to the internal C API and stop to export them.

----------
components: C API
messages: 367561
nosy: vstinner
priority: normal
severity: normal
status: open
title: [C API] Move PyXXX_ClearFreeLists() functions to the internal C API
versions: Python 3.9

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

From report at bugs.python.org  Tue Apr 28 17:55:17 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Apr 2020 21:55:17 +0000
Subject: [New-bugs-announce] [issue40429] [C API] PyThreadState_GetFrame()
 and PyFrame_GetCode() should return a strong refrence
Message-ID: <1588110917.55.0.0908942535567.issue40429@roundup.psfhosted.org>


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

I recently added PyThreadState_GetFrame() and PyFrame_GetCode() functions to the C API of Python 3.9.

Currently, these functions return borrowed references.

I asked on capi-sig and Brett confirms that borrowed refrences should be avoided:
https://mail.python.org/archives/list/capi-sig at python.org/thread/LHESBBB3IYTXMBUKQ3WZI5CWB4WUH5YZ/

Borrowed references should be avoidedd!
https://github.com/vstinner/misc/blob/master/cpython/pep-opaque-c-api.rst#borrowed-references

I will work on a PR to modify these functions to return a strong reference instead.

----------
components: C API
messages: 367570
nosy: vstinner
priority: normal
severity: normal
status: open
title: [C API] PyThreadState_GetFrame() and PyFrame_GetCode() should return a strong refrence
versions: Python 3.9

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

From report at bugs.python.org  Tue Apr 28 18:48:03 2020
From: report at bugs.python.org (Anthony Sottile)
Date: Tue, 28 Apr 2020 22:48:03 +0000
Subject: [New-bugs-announce] [issue40430] ast.Slice is no longer a subclass
 of ast.slice
Message-ID: <1588114083.65.0.758237100014.issue40430@roundup.psfhosted.org>


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

unclear if this is intentional or not, I noticed this while seeing that `ast.Subscript.slice` is no longer `Index` / `Slice` / `ExtSlice`

# python3.8

>>> isinstance(ast.Slice(), ast.slice)
True

# python3.9a6

>>> isinstance(ast.Slice(), ast.slice)
False

----------
messages: 367571
nosy: Anthony Sottile
priority: normal
severity: normal
status: open
title: ast.Slice is no longer a subclass of ast.slice
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Tue Apr 28 19:29:18 2020
From: report at bugs.python.org (=?utf-8?q?Miro_Hron=C4=8Dok?=)
Date: Tue, 28 Apr 2020 23:29:18 +0000
Subject: [New-bugs-announce] [issue40431] turtledemo/__main__.py:
 SyntaxError: invalid string prefix else"#fca"
Message-ID: <1588116558.63.0.121077562738.issue40431@roundup.psfhosted.org>


New submission from Miro Hron?ok <miro at hroncok.cz>:

With Python 3.9.0a6 we get the following syntax error when bytecompiling the standard library in Fedora:


Compiling '/usr/lib64/python3.9/turtledemo/__main__.py'...
***   File "/usr/lib64/python3.9/turtledemo/__main__.py", line 275
    bg="#d00" if clear == NORMAL else"#fca")
                                    ^
SyntaxError: invalid string prefix


I've looked and the bad code is there for all branches, but only with 3.9.0a6 I get the SyntaxError.

I wonder whether this is a know new SyntaxError or not. This "worked" with 3.9.0a5:

>>> "yes" if False else"no"
'no'

Happy to submit a PR for turtledemo.

----------
components: Demos and Tools
messages: 367575
nosy: hroncok, petr.viktorin, vstinner
priority: normal
severity: normal
status: open
title: turtledemo/__main__.py: SyntaxError: invalid string prefix else"#fca"
versions: Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Tue Apr 28 22:37:10 2020
From: report at bugs.python.org (anthony shaw)
Date: Wed, 29 Apr 2020 02:37:10 +0000
Subject: [New-bugs-announce] [issue40432] Pegen regenerate project for
 Windows not working
Message-ID: <1588127830.15.0.595745305392.issue40432@roundup.psfhosted.org>


New submission from anthony shaw <anthonyshaw at apache.org>:

The additional tasks in the MSBuild project for pegen regeneration are not functional:

- Setting PYTHONPATH= inline cannot be done in Windows using that method
- The task does not inherit environment variables that way
- The path to the peg_generator module is in Unix path format

PR to follow

----------
assignee: anthonypjshaw
components: Build
messages: 367613
nosy: anthonypjshaw, pablogsal
priority: normal
severity: normal
status: open
title: Pegen regenerate project for Windows not working
versions: Python 3.9

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

From report at bugs.python.org  Tue Apr 28 22:52:17 2020
From: report at bugs.python.org (Ahmed Amr)
Date: Wed, 29 Apr 2020 02:52:17 +0000
Subject: [New-bugs-announce] [issue40433] Equality operations between lists
 and arrays
Message-ID: <1588128737.73.0.376280736154.issue40433@roundup.psfhosted.org>


New submission from Ahmed Amr <ahmedamron at gmail.com>:

Hi, I was thinking if we could add equality between array and list to work out of the box on the supported datatypes by arrays.

Currently, comparing a list and an array with the same contents returns False.

Also, creating an array of floats from a listA, then turning that array into a listB, returns different contents between listA and listB.

It's somehow counter-intuitive for me as even if the underlying implementations are different between array and list, they can be viewed as an array data structure but with different restrictions/implementations, along with that, arrays compare to each other correctly, and lists compare to each other correctly.

based on that, switching some lists to arrays in a python codebase may break some equality conditions within that code between lists and arrays

----------
files: equality_between_arrays_and_lists.py
messages: 367615
nosy: Ahmed Amr
priority: normal
severity: normal
status: open
title: Equality operations between lists and arrays
type: enhancement
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9
Added file: https://bugs.python.org/file49098/equality_between_arrays_and_lists.py

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

From report at bugs.python.org  Wed Apr 29 04:27:47 2020
From: report at bugs.python.org (Ama Aje My Fren)
Date: Wed, 29 Apr 2020 08:27:47 +0000
Subject: [New-bugs-announce] [issue40434] Update of reasoning why there is
 no case statement
Message-ID: <1588148867.59.0.249886730635.issue40434@roundup.psfhosted.org>


New submission from Ama Aje My Fren <amaajemyfren at gmail.com>:

The design and history FAQ (https://docs.python.org/dev/faq/design.html#why-isn-t-there-a-switch-or-case-statement-in-python) explains why there is no case statement referencing PEP 275(https://www.python.org/dev/peps/pep-0275/).

For Python 3 there is, however, PEP 3103(https://www.python.org/dev/peps/pep-3103/) which rejected the proposal for a switch statement.

----------
assignee: docs at python
components: Documentation
messages: 367633
nosy: amaajemyfren, docs at python
priority: normal
severity: normal
status: open
title: Update of reasoning why there is no case statement
versions: Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Wed Apr 29 06:05:36 2020
From: report at bugs.python.org (=?utf-8?b?5bem6L+f?=)
Date: Wed, 29 Apr 2020 10:05:36 +0000
Subject: [New-bugs-announce] [issue40435] Failed to launch IDLE in a UTF-8
 code page terminal environment
Message-ID: <1588154736.32.0.92562314697.issue40435@roundup.psfhosted.org>


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

Environment:
1.OS:
Windows 10 1909 Pro
2.Python version:
3.7.4 (default, Aug  9 2019, 18:34:13) [MSC v.1915 64 bit (AMD64)]
3.Error message:
UnicodeDecodeError: 'CP_UTF8' codec can't decode byte 0xd0 in position 23: No mapping for the Unicode character exists in the target code page

How to reporduce?
Set the code page to UTF-8 in windows control pannel/region/
Type idle in the terminal hoping to launch the IDLE, but you will get the error.

----------
assignee: terry.reedy
components: IDLE
files: pic04-29-18-05-10.png
messages: 367639
nosy: terry.reedy, ??
priority: normal
severity: normal
status: open
title: Failed to launch IDLE in a UTF-8 code page terminal environment
type: crash
versions: Python 3.7
Added file: https://bugs.python.org/file49099/pic04-29-18-05-10.png

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

From report at bugs.python.org  Wed Apr 29 07:36:45 2020
From: report at bugs.python.org (=?utf-8?q?Miro_Hron=C4=8Dok?=)
Date: Wed, 29 Apr 2020 11:36:45 +0000
Subject: [New-bugs-announce] [issue40436] pythoninfo collect_gdb() blows up
 when gdb fails to run
Message-ID: <1588160205.58.0.824942554925.issue40436@roundup.psfhosted.org>


New submission from Miro Hron?ok <miro at hroncok.cz>:

We had this weird traceback when running pythoninfo in Fedora build with Python 3.9.0a6:

+ /builddir/build/BUILD/Python-3.9.0a6/build/optimized/python -m test.pythoninfo
ERROR: collect_gdb() failed
Traceback (most recent call last):
  File "/builddir/build/BUILD/Python-3.9.0a6/Lib/test/pythoninfo.py", line 761, in collect_info
    collect_func(info_add)
  File "/builddir/build/BUILD/Python-3.9.0a6/Lib/test/pythoninfo.py", line 383, in collect_gdb
    version = version.splitlines()[0]
IndexError: list index out of range


I have debugged the problem and it is:


>>> subprocess.run(["gdb", "-nx", "--version"])
CompletedProcess(args=['gdb', '-nx', '--version'], returncode=-11)

There is a segfault. Possibly because gdb was linked to libpython from 3.9.0a5 and we run it trough subprocess from 3.9.0a6.


The code in pythoninfo is:

    try:
        proc = subprocess.Popen(["gdb", "-nx", "--version"],
                                stdout=subprocess.PIPE,
                                stderr=subprocess.PIPE,
                                universal_newlines=True)
        version = proc.communicate()[0]
    except OSError:
        return

That means it is designed to ignore errors. But it only ignores some errors. Should it only attempt to parse the version when proc.returncode is 0?

I don't know yet if the tests will fail as well, maybe the problem will be bigger.

----------
components: Tests
messages: 367641
nosy: hroncok, vstinner
priority: normal
severity: normal
status: open
title: pythoninfo collect_gdb() blows up when gdb fails to run
versions: Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Wed Apr 29 08:48:52 2020
From: report at bugs.python.org (jeffolsi10)
Date: Wed, 29 Apr 2020 12:48:52 +0000
Subject: [New-bugs-announce] [issue40437] add string.snake function
Message-ID: <1588164532.34.0.674721156435.issue40437@roundup.psfhosted.org>


New submission from jeffolsi10 <yirage2897 at coalamails.com>:

Like we have:
capitalize
swapcase
and others we should also have snake case

Which converts:
before: First Name, Last Name, Employee Status, Subject
after: first_name, last_name, employee_status, subject

This is very useful when working with titles of columns that are to be used in databases columns
usage example
https://github.com/pandas-dev/pandas/issues/33826

----------
messages: 367643
nosy: jeffolsi10
priority: normal
severity: normal
status: open
title: add string.snake function
type: enhancement
versions: Python 3.7

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

From report at bugs.python.org  Wed Apr 29 11:02:05 2020
From: report at bugs.python.org (Jonathan Crall)
Date: Wed, 29 Apr 2020 15:02:05 +0000
Subject: [New-bugs-announce] [issue40438] Python 3.9 eval on list
 comprehension sometimes returns coroutines
Message-ID: <1588172525.03.0.278979936503.issue40438@roundup.psfhosted.org>


New submission from Jonathan Crall <erotemic at gmail.com>:

I first noticed this when testing xdoctest on Python 3.9, and then again when using IPython.

I was finally able to generate a minimal working example in Python itself. The following code:

python -c "print(eval(compile('[i for i in range(3)]', mode='eval', filename='foo', flags=221184)))"

produces 

[0, 1, 2]
 
in Python <= 3.8, but in 3.9 it produces: 

<coroutine object <module> at 0x7fa336d40ec0>
<string>:1: RuntimeWarning: coroutine '<module>' was never awaited
RuntimeWarning: Enable tracemalloc to get the object allocation traceback


Is this an intended change? I can't find any notes in the CHANGELOG that seem to correspond to it.

----------
components: Interpreter Core
messages: 367651
nosy: Jonathan Crall
priority: normal
severity: normal
status: open
title: Python 3.9 eval on list comprehension sometimes returns coroutines
versions: Python 3.9

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

From report at bugs.python.org  Wed Apr 29 11:43:28 2020
From: report at bugs.python.org (Patrick A.)
Date: Wed, 29 Apr 2020 15:43:28 +0000
Subject: [New-bugs-announce] [issue40439] Error in an external reference
Message-ID: <1588175008.34.0.523121738721.issue40439@roundup.psfhosted.org>


New submission from Patrick A. <paudemard at gmail.com>:

This URL doesn't exist anymore. If you click on this URL you have a 404 not found.

https://www.dcl.hpi.uni-potsdam.de/home/loewis/table-3131.html

The website was changed and Dr. Martin v. L?wis is not hosted on the new site.

Regards

----------
assignee: docs at python
components: Documentation
messages: 367665
nosy: audpa31, docs at python
priority: normal
severity: normal
status: open
title: Error in an external reference
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/issue40439>
_______________________________________

From report at bugs.python.org  Wed Apr 29 15:01:33 2020
From: report at bugs.python.org (Benjamin Keen)
Date: Wed, 29 Apr 2020 19:01:33 +0000
Subject: [New-bugs-announce] [issue40440] allow array.array construction
 from memoryview w/o copy
Message-ID: <1588186893.13.0.865332377255.issue40440@roundup.psfhosted.org>


New submission from Benjamin Keen <benjamin.keen at hpe.com>:

Currently the array.array object can export a memoryview, but there is no way to construct one from a memoryview without making a copy of the underlying data.  So in that sense array.array only supports one half of the buffer protocol and this is to allow for the other half.

This proposal is to allow the array object to be constructed from an existing exported buffer without copying and reallocating the memory, permitting operations that can modify the underlying buffer's contents but not the allocation.

This is useful when working with many small pieces of one very large underlying buffer that you do not want to copy, when desiring to work with different parts of it with different types, and as part of a way to work with shared memory in multiple processes.

I will shortly have a PR for this, including updates for the documentation and unit tests.

 - Modules/arraymodule.c already must check if the array object has exported a buffer for methods that might resize. If the array was constructed from an imported buffer, the same restrictions apply.  So the object just needs to know whether it is constructed from a Py_Buffer or not and check in the same places it checks for the export count being nonzero. So the code doesn't need to be perturbed that much.

- Only MemoryView objects with contiguous layout, size, and alignment compatible with the data type of the array element are allowed.

- I'm proposing this is only for when it's an actual memoryview object, not just if the object can export buffers. This preserves more of the existing behavior.

- Currently you /can/ initialize an array with a type-compatible memoryview - but it makes a copy, iterating the elements and the types have to match, not just in size. We could maintain exact backward compatibility by adding an extra argument to array.array() or another letter to the format specifier; my current patch doesn't do this though.

-----------------------------------------------------------
Example of current behavior:

>>> import array
>>> x = array.array('b', [1,2,3,4])
>>> y = memoryview(x)
>>> z = array.array('b', y)
>>> z
array('b', [1, 2, 3, 4])
>>> z[0] = 42
>>> x
array('b', [1, 2, 3, 4])
>>> z
array('b', [42, 2, 3, 4])
     # x and z are backed by different memory
>>> x.append(17)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
BufferError: cannot resize an array that is exporting buffers
     # this is because y is still a live object
>>> z.append(17)
     # it is really a copy, x and y are irrelevant to z
>>> z
array('b', [42, 2, 3, 4, 17])

----------------------------------------
Example of new behavior:

>>> import array
>>> x = array.array('b', [1,2,3,4])
>>> x
array('b', [1, 2, 3, 4])
>>> y = memoryview(x)
>>> z = array.array('b', y)
>>> z
array('b', [1, 2, 3, 4])
>>> z[0] = 42
>>> x
array('b', [42, 2, 3, 4])
>>> x.append(4)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
BufferError: cannot resize an array that is exporting buffers
>>> z.append(4)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
BufferError: cannot resize an array constructed from an imported buffer

----------
components: Library (Lib)
messages: 367688
nosy: bjkeen
priority: normal
severity: normal
status: open
title: allow array.array construction from memoryview w/o copy
type: enhancement

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

From report at bugs.python.org  Wed Apr 29 16:02:11 2020
From: report at bugs.python.org (alexpovel)
Date: Wed, 29 Apr 2020 20:02:11 +0000
Subject: [New-bugs-announce] [issue40441] Plural typo in Design and History
 FAQ
Message-ID: <1588190531.44.0.663545958427.issue40441@roundup.psfhosted.org>


New submission from alexpovel <python at alexpovel.de>:

The documentation under "Design and History FAQ" has a typo in its "Why doesn?t Python have a ?with? statement for attribute assignments?" section:

https://docs.python.org/3/faq/design.html#why-doesn-t-python-have-a-with-statement-for-attribute-assignments

where it says:

> Some language have a construct that looks like this:

which should of course read:

> Some languages have a construct that looks like this:

Attached is a git diff patch file.

----------
assignee: docs at python
components: Documentation
files: fix_plural_typo_in_documentation.patch
keywords: patch
messages: 367696
nosy: alexpovel, docs at python
priority: normal
pull_requests: 19120
severity: normal
status: open
title: Plural typo in Design and History FAQ
versions: Python 3.8
Added file: https://bugs.python.org/file49100/fix_plural_typo_in_documentation.patch

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

From report at bugs.python.org  Wed Apr 29 16:46:13 2020
From: report at bugs.python.org (Deomid Ryabkov)
Date: Wed, 29 Apr 2020 20:46:13 +0000
Subject: [New-bugs-announce] [issue40442] Spurious warning emitted during
 fork() can deadlock a multi-threaded process
Message-ID: <1588193173.96.0.734255401294.issue40442@roundup.psfhosted.org>


New submission from Deomid Ryabkov <rojer at rojer.me>:

I know, I know - forking a multi-threaded process is bad. But it happens.

This is related  to https://bugs.python.org/issue40399 and https://bugs.python.org/issue6721 but is distinct because the problem is entirely self-inflicted.

What happens:

1) A multithreaded program forks using one of the functions, such as os.forkpty()
2) In the child process the Python interpreter, in its PyOS_AfterFork_Child function ([1]) tries to kill all the threads other than the one doing the forking.
3) Among the objects being destroyed may include file or socket objects that are now being destroyed too, without having been previosuly closed, which triggers a ResourceWarning in the finalizer [2], [3].
4) Default action for warnings is to write to sys.stderr
5) A mutex used in BufferedIO is held by some other (now deceased thread).
6) Deadlock in _enter_buffered_busy [4].

This is bad because there is absolutely no way to avoid it without disabling warnings.
Even if the program is super careful to not do anything after forking other than exec, it doesn't help because the resource warning and the resulting deadlock is triggered by activity of the interpreter: it is the interpreter that orphans and is forcibly destroying the files and sockets, not the program that lost track of them.

[1] https://github.com/python/cpython/blob/beba1a808000d5fc445cb28eab96bdb4cdb7c959/Modules/posixmodule.c#L451

[2] https://github.com/python/cpython/blob/beba1a808000d5fc445cb28eab96bdb4cdb7c959/Modules/_io/fileio.c#L95

[3] https://github.com/python/cpython/blob/beba1a808000d5fc445cb28eab96bdb4cdb7c959/Modules/socketmodule.c#L4800

[4] https://github.com/python/cpython/blob/beba1a808000d5fc445cb28eab96bdb4cdb7c959/Modules/_io/bufferedio.c#L282

----------
components: Library (Lib)
messages: 367701
nosy: rojer
priority: normal
severity: normal
status: open
title: Spurious warning emitted during fork() can deadlock a multi-threaded process
versions: Python 3.7

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

From report at bugs.python.org  Wed Apr 29 18:42:28 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Apr 2020 22:42:28 +0000
Subject: [New-bugs-announce] [issue40443] Remove unused imports in the
 stdlib (April 2020 edition)
Message-ID: <1588200148.3.0.742578477052.issue40443@roundup.psfhosted.org>


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

Attached PRs removed unused imports from the Python standard library.

I used pyflakes and looked for "imported but unused" warnings. I ignored tons of warnings, since many are false alarms: imports done on purpose.

Previous editions:

* 2014: bpo-20976
* 2017: bpo-29919

----------
components: Library (Lib), Tests
messages: 367711
nosy: vstinner
priority: normal
severity: normal
status: open
title: Remove unused imports in the stdlib (April 2020 edition)
versions: Python 3.9

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

From report at bugs.python.org  Wed Apr 29 18:52:09 2020
From: report at bugs.python.org (Darin Tay)
Date: Wed, 29 Apr 2020 22:52:09 +0000
Subject: [New-bugs-announce] [issue40444] multiprocessing.Pool deadlocks
 with only print statements
Message-ID: <1588200729.96.0.263407738291.issue40444@roundup.psfhosted.org>


New submission from Darin Tay <darin.tay at gmail.com>:

I ran into a deadlock that I've reduced to a small and consistent repro, tested on 3.7.5 and 3.8.0.


Reading through https://bugs.python.org/issue6721 now I suspect it is just another case of that, but not certain.


In particular, I'm not using any explicit threads, though presumably multiprocessing.Pool is using one under-the-hood.  If so, it seems a bit rough that multiprocessing can by itself cause the fork issues it tries to warn about ("Note that safely forking a multithreaded process is problematic.")



# This very quickly and consistently hangs after a few attempts on my machines
def run(x):
    print("Worker with ", x)
    return x

def main():
    for i in range(1000):
        print("Attempt #", i)
        from multiprocessing import Pool

        with Pool(processes=16, maxtasksperchild=1) as p:
            for entry in p.imap_unordered(run, range(50)):
                print("Main received back ", entry)


if __name__ == "__main__":
    main()

----------
components: Library (Lib)
messages: 367712
nosy: DarinTay
priority: normal
severity: normal
status: open
title: multiprocessing.Pool deadlocks with only print statements
type: behavior
versions: Python 3.7, Python 3.8

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

From report at bugs.python.org  Wed Apr 29 19:37:52 2020
From: report at bugs.python.org (Shantanu)
Date: Wed, 29 Apr 2020 23:37:52 +0000
Subject: [New-bugs-announce] [issue40445] compileall.compile_dir docs aren't
 updated for bpo-38112
Message-ID: <1588203472.21.0.62841448361.issue40445@roundup.psfhosted.org>


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

While the signature was updated in the documentation, the text below wasn't, and still reflects the old default of 10.

https://docs.python.org/3.9/library/compileall.html#compileall.compile_dir

----------
assignee: docs at python
components: Documentation
messages: 367714
nosy: docs at python, hauntsaninja
priority: normal
severity: normal
status: open
title: compileall.compile_dir docs aren't updated for bpo-38112
versions: Python 3.9

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

From report at bugs.python.org  Thu Apr 30 01:13:20 2020
From: report at bugs.python.org (Basic ICT Repairs)
Date: Thu, 30 Apr 2020 05:13:20 +0000
Subject: [New-bugs-announce] [issue40446] pow(a, b,
 p) where b=int((p-1)/2) spits out gibbrish for big p
Message-ID: <1588223600.07.0.719223766764.issue40446@roundup.psfhosted.org>


New submission from Basic ICT Repairs <basic.ict.repairs at gmail.com>:

Hi, I was calculating Legendre coefficients, and quadratic residues and encountered what I believe to be a bug while using this code: 

for a in range (5):
        exp=int((p-1)/2)
        x=pow(a,exp,p)
        print(x)

If p is an odd prime, then x can have three values [-1,0,-1] - where "-1" refers to p-1. The code works well for reasonably small primes (like 9973). But with big primes(see below), python 3.7 spits out gibberish. Same code in python 2.7 works well.

The problem in python 3.7 can be avoided if exp is defined thusly :  
exp=(p-1)//2

Here is the prime I tried it on : 
p = 101524035174539890485408575671085261788758965189060164484385690801466167356667036677932998889725476582421738788500738738503134356158197247473850273565349249573867251280253564698939768700489401960767007716413932851838937641880157263936985954881657889497583485535527613578457628399173971810541670838543309159139

----------
messages: 367735
nosy: Basic ICT Repairs
priority: normal
severity: normal
status: open
title: pow(a,b,p) where b=int((p-1)/2) spits out gibbrish for big p

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

From report at bugs.python.org  Thu Apr 30 02:18:15 2020
From: report at bugs.python.org (Shantanu)
Date: Thu, 30 Apr 2020 06:18:15 +0000
Subject: [New-bugs-announce] [issue40447] compile_file's stripdir does not
 accept pathlib.Path
Message-ID: <1588227495.91.0.144745322662.issue40447@roundup.psfhosted.org>


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

Python 3.9 added the stripdir argument to compileall functions. From https://docs.python.org/3.9/library/compileall.html#compileall.compile_file:
> The stripdir, prependdir and limit_sl_dest arguments correspond to the -s, -p and -e options described above. They may be specified as str, bytes or os.PathLike.

```
~ ? python3.9
Python 3.9.0a6+ (heads/master:360371f, Apr 29 2020, 15:44:56) 
[Clang 11.0.0 (clang-1100.0.33.17)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import compileall, pathlib
>>> compileall.compile_file(pathlib.Path("tmp/test.py"), stripdir=pathlib.Path("tmp"))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/shantanu/.pyenv/versions/3.9-dev/lib/python3.9/compileall.py", line 161, in compile_file
    stripdir_parts = stripdir.split(os.path.sep)
AttributeError: 'PosixPath' object has no attribute 'split'
```

Found by Jelle Zijlstra in https://github.com/python/typeshed/pull/3956#discussion_r417735663

----------
components: Library (Lib)
messages: 367740
nosy: hauntsaninja
priority: normal
severity: normal
status: open
title: compile_file's stripdir does not accept pathlib.Path
versions: Python 3.9

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

From report at bugs.python.org  Thu Apr 30 05:39:11 2020
From: report at bugs.python.org (Krzysztof Konopko)
Date: Thu, 30 Apr 2020 09:39:11 +0000
Subject: [New-bugs-announce] [issue40448] ensurepip uses cache directory
Message-ID: <1588239551.95.0.236818491517.issue40448@roundup.psfhosted.org>


New submission from Krzysztof Konopko <kris at konagma.com>:

ensurepip optionally installs or upgrades 'pip' and 'setuptools' using the version of those modules bundled with Python.  The internal PIP
installation routine by default temporarily uses its cache, if it
exists.  This is undesirable as Python builds and installations may be
independent of the user running the build, whilst PIP cache location
is dependent on the user's environment and outside of the build
environment.

At the same time, there's no value in using the cache while installing
bundled modules.  By design ensurepip does not access network so there's no point in checking or in any way accessing the cache.

This causes a problem in somewhat less usual build environments where Python is built into a designated `DESTDIR` with `--prefix` specified etc. If it does not have write permission to the cache directory (eg. `$HOME/.cache/pip` on Linux), it issues a warning but it installs bundled 'pip' and 'setuptools' fine.  But if it does not have execute access (to read directories), it fails hard.

`strace` also shows a lot of checks and even temporary use of the cache directory while processing whl files.

----------
components: Build, Installation
messages: 367751
nosy: kkonopko
priority: normal
severity: normal
status: open
title: ensurepip uses cache directory
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Thu Apr 30 06:43:54 2020
From: report at bugs.python.org (Gerrit Holl)
Date: Thu, 30 Apr 2020 10:43:54 +0000
Subject: [New-bugs-announce] [issue40449] multi-line f-string,
 syntaxerror points to wrong line
Message-ID: <1588243434.48.0.11950945946.issue40449@roundup.psfhosted.org>


New submission from Gerrit Holl <gerrit.holl at gmail.com>:

When there is a syntax error in a multi-line f-string, the arrow in the reported syntax error points to the wrong line:

$ cat mwe.py 
s = ("apricot "
     "pineapple"
     f"shallot{")
$ python mwe.py 
  File "mwe.py", line 1
    s = ("apricot "
        ^
SyntaxError: f-string: expecting '}'

Tested with Python 3.7.4 and 3.8.2.

----------
components: Interpreter Core
messages: 367753
nosy: Gerrit.Holl
priority: normal
severity: normal
status: open
title: multi-line f-string, syntaxerror points to wrong line
versions: Python 3.7, Python 3.8

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

From report at bugs.python.org  Thu Apr 30 09:00:47 2020
From: report at bugs.python.org (wei gu)
Date: Thu, 30 Apr 2020 13:00:47 +0000
Subject: [New-bugs-announce] [issue40450] wrong
Message-ID: <1588251647.23.0.779890676087.issue40450@roundup.psfhosted.org>


Change by wei gu <guwei0802 at gmail.com>:


----------
nosy: wei gu
priority: normal
severity: normal
status: open
title: wrong

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

From report at bugs.python.org  Thu Apr 30 11:18:10 2020
From: report at bugs.python.org (Cristian Martinez de Morentin)
Date: Thu, 30 Apr 2020 15:18:10 +0000
Subject: [New-bugs-announce] [issue40451] Unexpected sys.getrefcount(foo)
 output
Message-ID: <1588259890.93.0.389588994308.issue40451@roundup.psfhosted.org>


New submission from Cristian Martinez de Morentin <cmartinez at das-nano.com>:

Hello, I have observed a strange behaviour regarding reference counting in Python 3.8.2 (Windows 64 bits). Perhaps, it could be linked to a memory leakage issue.

In the following code, I would not expect an output of '137' for the reference counter of the 'aux' object. Could you please explain this behaviour?

>>> import sys
>>> test = {'a': 0, 'b': 1}
>>> sys.getrefcount(test)
2
>>> aux = test['b']
>>> sys.getrefcount(aux)
137

Thank you so much.

----------
components: Windows
messages: 367760
nosy: Cristian Martinez de Morentin, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Unexpected sys.getrefcount(foo) output
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Thu Apr 30 13:35:47 2020
From: report at bugs.python.org (E. Paine)
Date: Thu, 30 Apr 2020 17:35:47 +0000
Subject: [New-bugs-announce] [issue40452] IDLE preserve clipboard on closure
 (Windows)
Message-ID: <1588268147.56.0.852233274654.issue40452@roundup.psfhosted.org>


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

Currently, on a Windows machine, the clipboard contents is lost when the root is closed. This, therefore requires you to keep the IDLE instance open until after the copy has been complete (particularly annoying when copying between different IDLE instances). The solution is to pipe the tkinter clipboard contents to "clip.exe" (built-in to Windows) which will preserve it after root closure.

----------
assignee: terry.reedy
components: IDLE
messages: 367765
nosy: epaine, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE preserve clipboard on closure (Windows)
versions: Python 3.9

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

From report at bugs.python.org  Thu Apr 30 16:00:57 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 30 Apr 2020 20:00:57 +0000
Subject: [New-bugs-announce] [issue40453] Add
 PyConfig._isolated_interpreter: isolated subinterpreters
Message-ID: <1588276857.13.0.360538290387.issue40453@roundup.psfhosted.org>


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

I propose to add PyConfig._isolated_interpreter configuration parameter to disallow threads, subprocesses and fork in a subinterpreter.

_xxsubinterpreter.create() gets a new keyword-only isolated=True parameter to opt-in for not isolated mode, which is the current behavior of Py_NewInterpreter(). For example, mod_wsgi would continue to run in "non isolated" mode.

Attached PR implements this change. With the change, os.fork() is allowed again in "non isolated" subinterpreters (like mod_wsgi). os.fork() was disallowed in subinterpreters in Python 3.8, but subprocess was still allowed.

----------
components: Interpreter Core
messages: 367778
nosy: vstinner
priority: normal
severity: normal
status: open
title: Add PyConfig._isolated_interpreter: isolated subinterpreters
versions: Python 3.9

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

From report at bugs.python.org  Thu Apr 30 16:06:09 2020
From: report at bugs.python.org (Paul Martin)
Date: Thu, 30 Apr 2020 20:06:09 +0000
Subject: [New-bugs-announce] [issue40454] DEBUG kw to asyncio.run overrides
 DEBUG mode set elsewhere
Message-ID: <1588277169.66.0.186559339191.issue40454@roundup.psfhosted.org>


New submission from Paul Martin <greatestloginnameever at gmail.com>:

According to the docs:

"
There are several ways to enable asyncio debug mode.

Setting the PYTHONASYNCIODEBUG environment variable to 1.
Using the -X dev Python command line option.
Passing debug=True to asyncio.run().
Calling loop.set_debug().
"

My understanding of this would be that any of the above methods can be used to enable debug mode. However if asyncio.run is used then whatever value for DEBUG is passed to asyncio.run (or False by default) overrides DEBUG mode being set elsewhere. So, when asyncio.run is used, the only way to enable DEBUG mode is to pass DEBUG=True to asyncio.run. The other methods won't work. 

One solution might be to change this line in asyncio/runners.py:

loop.set_debug(debug)

To

loop.set_debug(debug or coroutines._DEBUG)

So asyncio.run won't disable debug mode if it's already been set elsewhere

----------
components: asyncio
messages: 367779
nosy: asvetlov, primal, yselivanov
priority: normal
severity: normal
status: open
title: DEBUG kw to asyncio.run overrides DEBUG mode set elsewhere
versions: Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Thu Apr 30 16:51:08 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 30 Apr 2020 20:51:08 +0000
Subject: [New-bugs-announce] [issue40455] GCC 10 compiler warnings
Message-ID: <1588279868.77.0.13865368461.issue40455@roundup.psfhosted.org>


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

GCC 10.0.1 on PPC64LE Fedora Rawhide LTO 3.x buildbot:
https://buildbot.python.org/all/#/builders/351/builds/406

Objects/longobject.c: In function ?_PyLong_Frexp?:
Objects/longobject.c:2928:33: warning: ?x_digits[0]? may be used uninitialized in this function [-Wmaybe-uninitialized]
 2928 |                     x_digits[0] |= 1;
      |                                 ^~

In function ?assemble_lnotab?,
    inlined from ?assemble_emit? at Python/compile.c:5709:25,
    inlined from ?assemble? at Python/compile.c:6048:18:
Python/compile.c:5663:19: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]
 5663 |         *lnotab++ = k;
      |         ~~~~~~~~~~^~~

----------
components: Build
messages: 367785
nosy: vstinner
priority: normal
severity: normal
status: open
title: GCC 10 compiler warnings
versions: Python 3.9

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

From report at bugs.python.org  Thu Apr 30 18:25:30 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 30 Apr 2020 22:25:30 +0000
Subject: [New-bugs-announce] [issue40456] py_compile.main(): undefined name
 'quiet'
Message-ID: <1588285530.29.0.122281949999.issue40456@roundup.psfhosted.org>


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

pyflakes found 3 errors:

Lib/py_compile.py:200:20 undefined name 'quiet'
Lib/py_compile.py:204:20 undefined name 'quiet'
Lib/py_compile.py:213:20 undefined name 'quiet'

It seems like the code was introduced by PR 12976:

commit 2e33ecd7c9b0cac3efc6fcbdd4547fd086b4e2d1
Author: Joannah Nanjekye <33177550+nanjekyejoannah at users.noreply.github.com>
Date:   Tue May 28 13:29:04 2019 -0300

    bpo-22640: Add silent mode to py_compile.compile() (GH-12976)

----------
components: Library (Lib)
messages: 367790
nosy: nanjekyejoannah, vstinner
priority: normal
severity: normal
status: open
title: py_compile.main(): undefined name 'quiet'
versions: Python 3.9

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

From report at bugs.python.org  Thu Apr 30 18:41:34 2020
From: report at bugs.python.org (Mitch Lindgren)
Date: Thu, 30 Apr 2020 22:41:34 +0000
Subject: [New-bugs-announce] [issue40457] Python fails to compile/load _ssl
 module if OpenSSL is compiled with no-tls1-method
Message-ID: <1588286494.27.0.412005858691.issue40457@roundup.psfhosted.org>


New submission from Mitch Lindgren <lindgren.mitch at gmail.com>:

I'm working on a project which uses OpenSSL 1.1.1g. For security and compliance reasons, it is built with SSL and TLS < 1.2 methods compiled out, using the following OpenSSL build options:

no-ssl no-ssl3 no-tls1 no-tls1_1 no-ssl3-method no-tls1-method no-tls1_1-method

When compiling Python v3.8.2 with CFLAGS="-DOPENSSL_NO_SSL2 -DOPENSSL_NO_SSL3 -DOPENSSL_NO_TLS1 -DOPENSSL_NO_TLS1_1" and --with-openssl=/path/to/custom/openssl, _ssl.c fails to compile with the following error:

gcc -pthread -fPIC -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -DOPENSSL_NO_SSL2 -DOPENSSL_NO_SSL3 -DOPENSSL_NO_TLS1 -DOPENSSL_NO_TLS1_1 -DOPENSSL_NO_SSL2 -DOPENSSL_NO_SSL3 -DOPENSSL_NO_TLS1 -DOPENSSL_NO_TLS1_1 -std=c99 -Wextra -Wno-unused-result -Wno-unused-parameter -Wno-missing-field-initializers -Werror=implicit-function-declaration -I./Include/internal -I/home/mitch/openssl/include -I./Include -I. -I/usr/include/x86_64-linux-gnu -I/usr/local/include -I/home/mitch/cpython/Include -I/home/mitch/cpython -c /home/mitch/cpython/Modules/_ssl.c -o build/temp.linux-x86_64-3.8/home/mitch/cpython/Modules/_ssl.o
/home/mitch/cpython/Modules/_ssl.c: In function ?_ssl__SSLContext_impl?:
/home/mitch/cpython/Modules/_ssl.c:3088:27: error: implicit declaration of function ?TLSv1_method?; did you mean ?DTLSv1_method?? [-Werror=implicit-function-declaration]
         ctx = SSL_CTX_new(TLSv1_method());
                           ^~~~~~~~~~~~
                           DTLSv1_method
/home/mitch/cpython/Modules/_ssl.c:3088:27: warning: passing argument 1 of ?SSL_CTX_new? makes pointer from integer without a cast [-Wint-conversion]
In file included from /home/mitch/cpython/Modules/_ssl.c:62:0:
/home/mitch/openssl/include/openssl/ssl.h:1503:17: note: expected ?const SSL_METHOD * {aka const struct ssl_method_st *}? but argument is of type ?int?
 __owur SSL_CTX *SSL_CTX_new(const SSL_METHOD *meth);
                 ^~~~~~~~~~~
/home/mitch/cpython/Modules/_ssl.c:3091:27: error: implicit declaration of function ?TLSv1_1_method?; did you mean ?TLSv1_2_method?? [-Werror=implicit-function-declaration]
         ctx = SSL_CTX_new(TLSv1_1_method());
                           ^~~~~~~~~~~~~~
                           TLSv1_2_method
/home/mitch/cpython/Modules/_ssl.c:3091:27: warning: passing argument 1 of ?SSL_CTX_new? makes pointer from integer without a cast [-Wint-conversion]
In file included from /home/mitch/cpython/Modules/_ssl.c:62:0:
/home/mitch/openssl/include/openssl/ssl.h:1503:17: note: expected ?const SSL_METHOD * {aka const struct ssl_method_st *}? but argument is of type ?int?
 __owur SSL_CTX *SSL_CTX_new(const SSL_METHOD *meth);
                 ^~~~~~~~~~~
cc1: some warnings being treated as errors

This also affects older versions. With v3.5.6, the _ssl module compiles successfully (it may be getting the declaration of TLSv1_method from the system default OpenSSL header since the --with-openssl option doesn't exist in this version), but importing the module at runtime fails:

root at 10:/tmp/acmstest# python3
Python 3.5.6 (default, Mar 23 2020, 05:11:33)
[GCC 8.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import ssl
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.5/ssl.py", line 99, in <module>
    import _ssl             # if we can't import it, let the error propagate
ImportError: /usr/lib/python3.5/lib-dynload/_ssl.cpython-35m-aarch64-linux-gnu.so: undefined symbol: TLSv1_method

----------
assignee: christian.heimes
components: SSL
messages: 367793
nosy: Mitch Lindgren, christian.heimes
priority: normal
severity: normal
status: open
title: Python fails to compile/load _ssl module if OpenSSL is compiled with no-tls1-method
type: compile error
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8

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

From report at bugs.python.org  Thu Apr 30 19:10:27 2020
From: report at bugs.python.org (Steve Dower)
Date: Thu, 30 Apr 2020 23:10:27 +0000
Subject: [New-bugs-announce] [issue40458] test_attribute_name_interning
 crashes on APPX test
Message-ID: <1588288227.67.0.928950925895.issue40458@roundup.psfhosted.org>


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

The Windows CI machines on Azure Pipelines run additional tests to check an "installed" layout and with the UWP entry point that's used for the Windows Store package.

These tests have been failing intermittently (though regularly) with a stack overflow crash in the PyPickler tests.

Example: https://dev.azure.com/Python/cpython/_build/results?buildId=62055&view=results

test_attribute_name_interning (test.test_pickle.PyPicklerTests) ... ok
  File "D:\a\1\b\layout-appx-amd64\lib\test\pickletester.py", line 3085 in __getattr__
  File "D:\a\1\b\layout-appx-amd64\lib\test\pickletester.py", line 3085 in __getattr__
  File "D:\a\1\b\layout-appx-amd64\lib\test\pickletester.py", line 3085 in __getattr__
  File "D:\a\1\b\layout-appx-amd64\lib\test\pickletester.py", line 3085 in __getattr__
...

I assume this is due to having more code on the start at the start, and so the recursion limit isn't low enough. But it might also be worth checking this particular case to see whether there is unnecessary data being kept on the stack (e.g. in local C variables).

The crash occurs in both 3.8 and master, but not 3.7.

----------
components: Windows
messages: 367803
nosy: paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: test_attribute_name_interning crashes on APPX test
versions: Python 3.8, Python 3.9

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

From report at bugs.python.org  Thu Apr 30 19:45:08 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 30 Apr 2020 23:45:08 +0000
Subject: [New-bugs-announce] [issue40459] [easy] undefined names in
 platform.py
Message-ID: <1588290308.75.0.293273104248.issue40459@roundup.psfhosted.org>


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

pyflakes found the two following issues in platform.py:

Lib/platform.py:401:35 undefined name 'HKEY_LOCAL_MACHINE'
Lib/platform.py:402:25 undefined name 'QueryValueEx'

Line 353:

            with winreg.OpenKeyEx(winreg.HKEY_LOCAL_MACHINE, cvkey) as key:
                return winreg.QueryValueEx(key, 'EditionId')[0]

vs Line 401:

            with winreg.OpenKeyEx(HKEY_LOCAL_MACHINE, cvkey) as key:
                ptype = QueryValueEx(key, 'CurrentType')[0]


This issue seems easy to fix ;-)

----------
components: Library (Lib)
keywords: newcomer friendly
messages: 367808
nosy: vstinner
priority: normal
severity: normal
status: open
title: [easy] undefined names in platform.py
versions: Python 3.9

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

From report at bugs.python.org  Thu Apr 30 19:48:17 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 30 Apr 2020 23:48:17 +0000
Subject: [New-bugs-announce] [issue40460] [easy] undefined name in
 Lib/idlelib/zzdummy.py
Message-ID: <1588290497.54.0.985175585062.issue40460@roundup.psfhosted.org>


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

pyflakes found the following issue:

Lib/idlelib/zzdummy.py:31:33 undefined name 'ztest'

Code:

ztext = idleConf.GetOption('extensions', 'ZzDummy', 'z-text')
(...)
        for line in range(1, text.index('end')):
            text.insert('%d.0', ztest)

Maybe it's a typo: ztext instead of ztest? I'm not sure.

----------
assignee: terry.reedy
components: IDLE
keywords: newcomer friendly
messages: 367810
nosy: terry.reedy, vstinner
priority: normal
severity: normal
status: open
title: [easy] undefined name in Lib/idlelib/zzdummy.py
versions: Python 3.9

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

From report at bugs.python.org  Thu Apr 30 19:48:45 2020
From: report at bugs.python.org (Hugo Benavides)
Date: Thu, 30 Apr 2020 23:48:45 +0000
Subject: [New-bugs-announce] [issue40461] execution of file with pictures
 doesn't work in command --onefile in pyinstaller
Message-ID: <1588290525.38.0.683228123996.issue40461@roundup.psfhosted.org>


New submission from Hugo Benavides <hugohernanbp at gmail.com>:

hi, 
I have a problem to crete an executable using the command pyinstaller at the time of use the helper --onefile

I've created an executable using the next instruction:

pyinstaller --windowed --add-data "Rute PC to my Folder\Imagen";"Imagen"  Aplicacion_Calculadora.py  

The folder Imagen has an imagen that is called into the code and at this time everything work fine, the executable starts and works very fine. I have used the calculator and operations are correct and the imagen is upload in the interface, but I deleted everything and started again.

I would like to add everything in one File using the command:

pyinstaller --onefile --add-data "Rute PC to mi Folder\Imagen";"Imagen"  Aplicacion_Calculadora.py 

At this point, the executable never starts. If I saw the message in console when the .exe is running and it shows me the next error: 

File "tkinter\__init__.py", line 4061, in __init__
File "tkinter\__init__.py", line 4006, in __init__
_tkinter.TclError: couldn't open "./Imagen/Retroceder.png": no such file or directory [11320] Failed to execute script Aplicacion_Calculadora 

The executable never can find the folder and the imagen, it happenning just when I use the command --onefile

I've been looking in every documentation and instructions but I've not found anything about that error just using the command --onefile


May you help me with that error or what instruction I should add, please?

Attach code and folder with the imagen


Thanks

----------
components: Library (Lib)
files: Aplicacion_Calculadora.zip
messages: 367811
nosy: Hugo Benavides
priority: normal
severity: normal
status: open
title: execution of file with pictures doesn't work in command --onefile in pyinstaller
versions: Python 3.8
Added file: https://bugs.python.org/file49103/Aplicacion_Calculadora.zip

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

From report at bugs.python.org  Thu Apr 30 19:50:30 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 30 Apr 2020 23:50:30 +0000
Subject: [New-bugs-announce] [issue40462] [easy] undefined name in
 Lib/test/mock_socket.py
Message-ID: <1588290630.2.0.182306583677.issue40462@roundup.psfhosted.org>


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

pyflakes found the following issues in sendall():

Lib/test/mock_socket.py:95:21 undefined name 'data'
Lib/test/mock_socket.py:96:28 undefined name 'data'
Lib/test/mock_socket.py:97:20 undefined name 'data'

Code:

    def sendall(self, buffer, flags=None):
        self.last = data
        self.output.append(data)
        return len(data)

    def send(self, data, flags=None):
        self.last = data
        self.output.append(data)
        return len(data)

I guess that sendall() buffer parameter should be renamed to data.

----------
components: Tests
keywords: newcomer friendly
messages: 367812
nosy: vstinner
priority: normal
severity: normal
status: open
title: [easy] undefined name in Lib/test/mock_socket.py
versions: Python 3.9

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