From report at bugs.python.org  Wed Apr  1 01:50:19 2020
From: report at bugs.python.org (laike9m)
Date: Wed, 01 Apr 2020 05:50:19 +0000
Subject: [issue40122] The implementation and documentation of "dis.findlables"
 don't match
In-Reply-To: <1585636419.17.0.745722185034.issue40122@roundup.psfhosted.org>
Message-ID: <1585720219.87.0.900403025202.issue40122@roundup.psfhosted.org>


Change by laike9m <laike9m at gmail.com>:


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

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

From report at bugs.python.org  Wed Apr  1 01:52:53 2020
From: report at bugs.python.org (laike9m)
Date: Wed, 01 Apr 2020 05:52:53 +0000
Subject: [issue40122] The implementation and documentation of "dis.findlables"
 don't match
In-Reply-To: <1585636419.17.0.745722185034.issue40122@roundup.psfhosted.org>
Message-ID: <1585720373.21.0.214997590695.issue40122@roundup.psfhosted.org>


laike9m <laike9m at gmail.com> added the comment:

I've created a PR to fix documentation.
https://github.com/python/cpython/pull/19274

I'll create a new issue for making the function accept a code object.

----------

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

From report at bugs.python.org  Wed Apr  1 03:08:17 2020
From: report at bugs.python.org (Davide Golinelli)
Date: Wed, 01 Apr 2020 07:08:17 +0000
Subject: [issue40113] Turtle demo
In-Reply-To: <1585567945.94.0.599224677.issue40113@roundup.psfhosted.org>
Message-ID: <1585724897.91.0.998834834875.issue40113@roundup.psfhosted.org>


Davide Golinelli <davi84 at gmail.com> added the comment:

you're absolutely right! 
I'm so sorry for wasting your time.

thanks and regards

----------

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

From report at bugs.python.org  Wed Apr  1 04:24:07 2020
From: report at bugs.python.org (Petr Viktorin)
Date: Wed, 01 Apr 2020 08:24:07 +0000
Subject: [issue37207] Use PEP 590 vectorcall to speed up calls to range(),
 list() and dict()
In-Reply-To: <1560072227.25.0.180298594259.issue37207@roundup.psfhosted.org>
Message-ID: <1585729447.1.0.809998928967.issue37207@roundup.psfhosted.org>


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

Definitely!

----------

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

From report at bugs.python.org  Wed Apr  1 04:38:46 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 01 Apr 2020 08:38:46 +0000
Subject: [issue40121] socket module missing audit events
In-Reply-To: <1585603899.47.0.326918129099.issue40121@roundup.psfhosted.org>
Message-ID: <1585730326.79.0.455031422974.issue40121@roundup.psfhosted.org>


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


----------
pull_requests: +18631
pull_request: https://github.com/python/cpython/pull/19275

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

From report at bugs.python.org  Wed Apr  1 04:38:49 2020
From: report at bugs.python.org (Steve Dower)
Date: Wed, 01 Apr 2020 08:38:49 +0000
Subject: [issue40121] socket module missing audit events
In-Reply-To: <1585603899.47.0.326918129099.issue40121@roundup.psfhosted.org>
Message-ID: <1585730329.09.0.0833504821605.issue40121@roundup.psfhosted.org>


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


New changeset 3ef4a7e5a7c29e17d5152d1fa6ceeb1fee269699 by Steve Dower in branch 'master':
bpo-40121: Fix exception type in test (GH-19267)
https://github.com/python/cpython/commit/3ef4a7e5a7c29e17d5152d1fa6ceeb1fee269699


----------

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

From report at bugs.python.org  Wed Apr  1 04:39:16 2020
From: report at bugs.python.org (Steve Dower)
Date: Wed, 01 Apr 2020 08:39:16 +0000
Subject: [issue40121] socket module missing audit events
In-Reply-To: <1585603899.47.0.326918129099.issue40121@roundup.psfhosted.org>
Message-ID: <1585730356.64.0.199945875341.issue40121@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


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

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

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: [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 05:16:39 2020
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Wed, 01 Apr 2020 09:16:39 +0000
Subject: [issue40132] Mechanism to control who owns package names on PyPI?
In-Reply-To: <1585731365.14.0.524521872477.issue40132@roundup.psfhosted.org>
Message-ID: <1585732599.39.0.768834135582.issue40132@roundup.psfhosted.org>


R?mi Lapeyre <remi.lapeyre at henki.fr> added the comment:

Hi Chris, this is explicitly forbidden in the Terms of use of Pypi and the PEP 451 at https://www.python.org/dev/peps/pep-0541/#invalid-projects:


> Invalid projects

> A project published on the Package Index meeting ANY of the following is considered invalid and will be removed from the Index:

[...]

> project is malware (designed to exploit or harm systems or users);

[...]

> project is name squatting (package has no functionality or is empty);

----------
nosy: +remi.lapeyre

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

From report at bugs.python.org  Wed Apr  1 05:40:39 2020
From: report at bugs.python.org (Eryk Sun)
Date: Wed, 01 Apr 2020 09:40:39 +0000
Subject: [issue40094] Add os.waitstatus_to_exitcode() function
In-Reply-To: <1585351787.12.0.917977186474.issue40094@roundup.psfhosted.org>
Message-ID: <1585734039.55.0.0553649727865.issue40094@roundup.psfhosted.org>


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

> It's more the opposite, if tomorrow we want to encode the status 
> of a terminated process differently, it will be easier if 
> os.waitstatus_to_exitcode() is available, no?

This new status-to-exitcode function applies to Windows waitpid() only due to a design choice in CPython -- not the operating system. The current waitpid() implementation assumes it's okay to discard the upper 8 bits of the exit status, which can lose important information. Maybe it's best to address Windows support in a new issue that also addresses the design of waitpid() in 3.9, in particular if this would change the design of the new function -- at the very least with regard to data type (e.g. `int status` doesn't have the required range).

Off topic: Despite the function name, waitpid in Windows takes a process handle, such as is returned by os.spawn*, and not a process ID, such as is required by os.kill. The current documentation is sometimes clear on this detail but sometimes confusingly mixes up "handle" and "id" in Windows-only sections.

> The result is a Python object. IMHO it's ok if the shifted result 
> ("status") is larger than 32 bits. But I'm not sure that the 
> current os.waitpid() implementation handles integer overflow 
> correctly...

The overflow problem could be addressed by using a 64-bit value for the status in os_waitpid_impl and elsewhere.

> Do you suggest that os.waitstatus_to_exitcode() result should be 
> negative if a process was terminated by TerminateProcess()?

Returning a signed result is an interesting suggestion. The native process exit status is actually an NTSTATUS value, and NTSTATUS and HRESULT codes are signed, with failure codes (i.e. errors and warnings) reported as negative values. That said, the exit status gets handled as an unsigned value in the Windows API, e.g. ExitProcess, TerminateProcess, and GetExitCodeProcess.

> When I look at GetExitCodeProcess() documentation, I don't see any 
> distinction between "normal exit" and a program terminated by 
> TerminateProcess(). The only different is the actual exit code:

In almost all cases a process terminates via TerminateProcess -- or rather the internal NTAPI function NtTerminateProcess. For a clean exit via ExitProcess (i.e. native RtlExitUserProcess), NtTerminateProcess gets called twice. The first time it gets called specially (with the process handle passed as NULL) in order to forcefully terminate all other threads in the process. Once the thread that calls ExitProcess is the last remaining thread, the loader shuts down the user-mode aspects of the process (e.g. it calls DLL entry points for process detach). Finally, the last thread makes a regular NtTerminateProcess call (with the current-process handle instead of NULL), which actually terminates the process.

An abnormal termination just does the latter step, but it doesn't necessarily use an exit status value that clearly indicates an abnormal termination. Thus not all abnormal terminations can be identified as such. Also, nothing stops a normal termination via ExitProcess from using an NTSTATUS code. For example, the default control handler for a console process exits via ExitProcess with the status code STATUS_CONTROL_C_EXIT (0xC000_013A). This is similar to an abnormal exit, since the process is killed by the closest thing to a Unix 'signal' that Windows console applications support. Moreover, the same status code is used for a genuinely abnormal exit due to a Ctrl+Close event (i.e. the console window was closed) if the session server is forced to terminate a console process that doesn't exit gracefully in the allotted time (default 5 seconds).

----------

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

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: [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:00:01 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 01 Apr 2020 11:00:01 +0000
Subject: [issue40133] Provide additional matchers for unittest.mock
In-Reply-To: <1585735205.76.0.306632606173.issue40133@roundup.psfhosted.org>
Message-ID: <1585738801.09.0.306815465295.issue40133@roundup.psfhosted.org>


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


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/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: [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 08:41:58 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 01 Apr 2020 12:41:58 +0000
Subject: [issue40130] Remove _PyUnicode_AsKind from private C API
In-Reply-To: <1585689343.48.0.60884405546.issue40130@roundup.psfhosted.org>
Message-ID: <1585744918.25.0.347843466945.issue40130@roundup.psfhosted.org>


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


New changeset 17b4733f2ff0a4abc06e8c745755c06fc32942dd by Serhiy Storchaka in branch 'master':
bpo-40130: _PyUnicode_AsKind() should not be exported. (GH-19265)
https://github.com/python/cpython/commit/17b4733f2ff0a4abc06e8c745755c06fc32942dd


----------

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

From report at bugs.python.org  Wed Apr  1 08:42:11 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 01 Apr 2020 12:42:11 +0000
Subject: [issue40130] Remove _PyUnicode_AsKind from private C API
In-Reply-To: <1585689343.48.0.60884405546.issue40130@roundup.psfhosted.org>
Message-ID: <1585744931.75.0.740558298543.issue40130@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Wed Apr  1 08:45:07 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 01 Apr 2020 12:45:07 +0000
Subject: [issue40121] socket module missing audit events
In-Reply-To: <1585603899.47.0.326918129099.issue40121@roundup.psfhosted.org>
Message-ID: <1585745107.5.0.526554113811.issue40121@roundup.psfhosted.org>


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


----------
pull_requests: +18632
pull_request: https://github.com/python/cpython/pull/19276

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

From report at bugs.python.org  Wed Apr  1 08:53:13 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 01 Apr 2020 12:53:13 +0000
Subject: [issue39837] Remove Azure Pipelines from GitHub PRs
In-Reply-To: <1583255119.77.0.277327127951.issue39837@roundup.psfhosted.org>
Message-ID: <1585745593.64.0.878382400166.issue39837@roundup.psfhosted.org>


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

I cannot merge a PR until it completes. It re-runs jobs which are already run as GH Actions.

There is another annoying issue with Azure Pipelines. When a job fails randomly for whatever reason, a job cannot be re-run, even if I log in Microsoft Azure.

Usually, the workaround is to close/reopen a PR to re-run all CIs.

Except that for a backport PR created automatically by miss-islington bot, when I close the PR, the bot removes its branch and so the PR cannot be re-open.

Well, the second workaround is to ask the bot to create a new PR backport. That what I did.

I did that for PR 19276 of bpo-40121. It's annoying to have to use *two* workarounds.

On the other side, Travis CI is not currently required, I don't understand why.

Is it possible to make Travis CI required and make Azure Pipelines not required?

----------

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

From report at bugs.python.org  Wed Apr  1 09:03:03 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 01 Apr 2020 13:03:03 +0000
Subject: [issue40121] socket module missing audit events
In-Reply-To: <1585603899.47.0.326918129099.issue40121@roundup.psfhosted.org>
Message-ID: <1585746183.22.0.924214268918.issue40121@roundup.psfhosted.org>


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


New changeset f971c8c0a0fbe1959843179e2811b047001125a0 by Miss Islington (bot) in branch '3.8':
bpo-40121: Fix exception type in test (GH-19267)
https://github.com/python/cpython/commit/f971c8c0a0fbe1959843179e2811b047001125a0


----------

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

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: [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:21:33 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 01 Apr 2020 13:21:33 +0000
Subject: [issue40135] multiprocessing: test_shared_memory_across_processes()
 cannot be run twice in parallel
In-Reply-To: <1585747098.48.0.62220441008.issue40135@roundup.psfhosted.org>
Message-ID: <1585747293.27.0.364155381635.issue40135@roundup.psfhosted.org>


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

Python 3.7 is not affected: it doesn't have test_shared_memory_across_processes().

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

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

From report at bugs.python.org  Wed Apr  1 09:36:29 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 01 Apr 2020 13:36:29 +0000
Subject: [issue40120] Undefined C behavior going beyond end of struct via a
 [1] arrays.
In-Reply-To: <1585602263.71.0.279519604291.issue40120@roundup.psfhosted.org>
Message-ID: <1585748189.77.0.64919184097.issue40120@roundup.psfhosted.org>


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

The following C++ code fails to build:
---
#ifdef __cplusplus
#  include <cstdlib>
#else
#  include <stdlib.h>
#endif

#ifdef __cplusplus
extern "C" {
#endif

typedef struct {
    int x;
    int y;
    char array[];
} mystruct_t;

#ifdef __cplusplus
}
#endif

int main()
{
    size_t size = 2;
    mystruct_t *obj = (mystruct_t *)malloc(sizeof(mystruct_t) - 1 + size);
    obj->array[0] = 'O';
    obj->array[1] = 'K';
    free(obj);
    return 0;
}
---

Error:
---
$ LANG= g++ -pedantic -Werror x.cpp
x.c:14:10: error: ISO C++ forbids flexible array member 'array' [-Werror=pedantic]
   14 |     char array[];
      |          ^~~~~
cc1plus: all warnings being treated as errors
---

----------

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

From report at bugs.python.org  Wed Apr  1 09:41:27 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 01 Apr 2020 13:41:27 +0000
Subject: [issue40120] Undefined C behavior going beyond end of struct via a
 [1] arrays.
In-Reply-To: <1585602263.71.0.279519604291.issue40120@roundup.psfhosted.org>
Message-ID: <1585748487.82.0.154298244226.issue40120@roundup.psfhosted.org>


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

Modules/hashtable.c and Modules/hashtable.h use a different approach. The variable size data is *not* part of the structure:

typedef struct {
    /* used by _Py_hashtable_t.buckets to link entries */
    _Py_slist_item_t _Py_slist_item;

    Py_uhash_t key_hash;

    /* key (key_size bytes) and then data (data_size bytes) follows */
} _Py_hashtable_entry_t;

In memory, we have: [_Py_slist_item, key_hash, key, data] where key size is table->key_size bytes (not stored in each table entry, only in the stable).

Pointer to key and data is computed with these macros:

#define _Py_HASHTABLE_ENTRY_PKEY(ENTRY) \
        ((const void *)((char *)(ENTRY) \
                        + sizeof(_Py_hashtable_entry_t)))

#define _Py_HASHTABLE_ENTRY_PDATA(TABLE, ENTRY) \
        ((const void *)((char *)(ENTRY) \
                        + sizeof(_Py_hashtable_entry_t) \
                        + (TABLE)->key_size))

But this approach is more annoying to use, it requires to play with pointers and requires such ugly macros.

----------

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

From report at bugs.python.org  Wed Apr  1 09:42:58 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 01 Apr 2020 13:42:58 +0000
Subject: [issue40120] Undefined C behavior going beyond end of struct via a
 [1] arrays.
In-Reply-To: <1585602263.71.0.279519604291.issue40120@roundup.psfhosted.org>
Message-ID: <1585748578.09.0.595653503286.issue40120@roundup.psfhosted.org>


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

> Undefined C behavior going beyond end of struct via a [1] arrays.

How is it an undefined C behavior? It works well in practice, no?

----------

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

From report at bugs.python.org  Wed Apr  1 09:48:30 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 01 Apr 2020 13:48:30 +0000
Subject: [issue40094] Add os.waitstatus_to_exitcode() function
In-Reply-To: <1585351787.12.0.917977186474.issue40094@roundup.psfhosted.org>
Message-ID: <1585748910.16.0.678959504293.issue40094@roundup.psfhosted.org>


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


----------
pull_requests: +18634
pull_request: https://github.com/python/cpython/pull/19278

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

From report at bugs.python.org  Wed Apr  1 09:48:21 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 01 Apr 2020 13:48:21 +0000
Subject: [issue40094] Add os.waitstatus_to_exitcode() function
In-Reply-To: <1585351787.12.0.917977186474.issue40094@roundup.psfhosted.org>
Message-ID: <1585748901.19.0.766834467363.issue40094@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Wed Apr  1 09:48:09 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 01 Apr 2020 13:48:09 +0000
Subject: [issue40094] Add os.waitstatus_to_exitcode() function
In-Reply-To: <1585351787.12.0.917977186474.issue40094@roundup.psfhosted.org>
Message-ID: <1585748889.25.0.370754699461.issue40094@roundup.psfhosted.org>


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


New changeset 7c72383f95b0cdedf390726069428d7b69ed2597 by Victor Stinner in branch 'master':
bpo-40094: Enhance os.WIFEXITED documentation (GH-19244)
https://github.com/python/cpython/commit/7c72383f95b0cdedf390726069428d7b69ed2597


----------

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

From report at bugs.python.org  Wed Apr  1 09:58:59 2020
From: report at bugs.python.org (Paul Ganssle)
Date: Wed, 01 Apr 2020 13:58:59 +0000
Subject: [issue33262] Deprecate shlex.split(None) to read from stdin.
In-Reply-To: <1523442529.49.0.682650639539.issue33262@psf.upfronthosting.co.za>
Message-ID: <1585749539.23.0.815086181106.issue33262@roundup.psfhosted.org>


Paul Ganssle <p.ganssle at gmail.com> added the comment:


New changeset 975ac326ffe265e63a103014fd27e9d098fe7548 by Zackery Spytz in branch 'master':
bpo-33262: Deprecate passing None for `s` to shlex.split() (GH-6514)
https://github.com/python/cpython/commit/975ac326ffe265e63a103014fd27e9d098fe7548


----------
nosy: +p-ganssle

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

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: [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 10:04:39 2020
From: report at bugs.python.org (Paul Ganssle)
Date: Wed, 01 Apr 2020 14:04:39 +0000
Subject: [issue40136] add warning to datetime.replace documentation to not use
 it for setting tzinfo unless UTC or None
In-Reply-To: <1585749545.84.0.350796397082.issue40136@roundup.psfhosted.org>
Message-ID: <1585749879.27.0.101735443824.issue40136@roundup.psfhosted.org>


Paul Ganssle <p.ganssle at gmail.com> added the comment:

That is a specific problem with the third-party library `pytz`, not a standard feature of the datetime module. Using `datetime.replace` is the intended way to set a time zone, see: https://blog.ganssle.io/articles/2018/03/pytz-fastest-footgun.html

As of Python 3.6, we've been recommending dateutil.tz instead of pytz, and assuming PEP 615 is accepted ( https://www.python.org/dev/peps/pep-0615/ ), we will have a built in time zone type that supports IANA time zones.

I am going to close this because this is not a bug in CPython, but if you think otherwise feel free to continue using this ticket to make the case.

----------
nosy: +p-ganssle
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Wed Apr  1 10:05:20 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 01 Apr 2020 14:05:20 +0000
Subject: [issue39983] test.regrtest: test marked as failed (env changed),
 but no warning: test_multiprocessing_forkserver
In-Reply-To: <1584397271.26.0.591205335177.issue39983@roundup.psfhosted.org>
Message-ID: <1585749920.62.0.980229547626.issue39983@roundup.psfhosted.org>


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

Another example: AMD64 RHEL7 LTO 3.7
"1 test altered the execution environment: test_multiprocessing_spawn"
https://buildbot.python.org/all/#/builders/43/builds/138

----------

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

From report at bugs.python.org  Wed Apr  1 10:09:12 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 01 Apr 2020 14:09:12 +0000
Subject: [issue40120] Undefined C behavior going beyond end of struct via a
 [1] arrays.
In-Reply-To: <1585602263.71.0.279519604291.issue40120@roundup.psfhosted.org>
Message-ID: <1585750152.1.0.403574859453.issue40120@roundup.psfhosted.org>


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

AFAIK extern "C" only affects mangling of function names. Because of overloading in C++ you can have several functions with the same name, and to distinguish "int abs(int)" from "float abs(float)" the C++ compiler mangles function names, that makes them incompatible with C.

----------

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

From report at bugs.python.org  Wed Apr  1 10:11:12 2020
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 01 Apr 2020 14:11:12 +0000
Subject: [issue39682] pathlib.Path objects can be used as context managers
In-Reply-To: <1582078235.85.0.126538415089.issue39682@roundup.psfhosted.org>
Message-ID: <1585750272.74.0.486084354887.issue39682@roundup.psfhosted.org>


Change by Antoine Pitrou <solipsis at pitrou.net>:


----------
versions: +Python 3.9 -Python 3.8

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

From report at bugs.python.org  Wed Apr  1 10:11:00 2020
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 01 Apr 2020 14:11:00 +0000
Subject: [issue39682] pathlib.Path objects can be used as context managers
In-Reply-To: <1582078235.85.0.126538415089.issue39682@roundup.psfhosted.org>
Message-ID: <1585750260.21.0.902905250377.issue39682@roundup.psfhosted.org>


Antoine Pitrou <solipsis at pitrou.net> added the comment:


New changeset 00002e6d8b0ccdb6e0d9e98a9a7f9c9edfdf1311 by Barney Gale in branch 'master':
bpo-39682: make `pathlib.Path` immutable by removing (undocumented) support for "closing" a path by using it as a context manager (GH-18846)
https://github.com/python/cpython/commit/00002e6d8b0ccdb6e0d9e98a9a7f9c9edfdf1311


----------

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

From report at bugs.python.org  Wed Apr  1 10:11:09 2020
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 01 Apr 2020 14:11:09 +0000
Subject: [issue39682] pathlib.Path objects can be used as context managers
In-Reply-To: <1582078235.85.0.126538415089.issue39682@roundup.psfhosted.org>
Message-ID: <1585750269.39.0.253067039704.issue39682@roundup.psfhosted.org>


Change by Antoine Pitrou <solipsis at pitrou.net>:


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

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

From report at bugs.python.org  Wed Apr  1 10:20:19 2020
From: report at bugs.python.org (Antony Lee)
Date: Wed, 01 Apr 2020 14:20:19 +0000
Subject: [issue39682] pathlib.Path objects can be used as context managers
In-Reply-To: <1582078235.85.0.126538415089.issue39682@roundup.psfhosted.org>
Message-ID: <1585750819.35.0.0417717410253.issue39682@roundup.psfhosted.org>


Change by Antony Lee <anntzer.lee at gmail.com>:


----------
nosy:  -Antony.Lee

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

From report at bugs.python.org  Wed Apr  1 10:31:10 2020
From: report at bugs.python.org (Michael Felt)
Date: Wed, 01 Apr 2020 14:31:10 +0000
Subject: [issue31160] Enhance support.reap_children()
In-Reply-To: <1502283003.36.0.514915057261.issue31160@psf.upfronthosting.co.za>
Message-ID: <1585751470.59.0.10988496046.issue31160@roundup.psfhosted.org>


Michael Felt <aixtools at felt.demon.nl> added the comment:

With PR19263 The AIX bots are now red.

======================================================================
ERROR: test_input_no_stdout_fileno (test.test_builtin.PtyTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/test_builtin.py", line 1952, in test_input_no_stdout_fileno
    lines = self.run_child(child, b"quux\r")
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/test_builtin.py", line 1898, in run_child
    support.wait_process(pid, exitcode=0)
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/support/__init__.py", line 3432, in wait_process
    os.kill(pid, signal.SIGKILL)
NameError: name 'signal' is not defined
----------------------------------------------------------------------
Ran 101 tests in 30.348s
FAILED (errors=1, skipped=7)
1 test failed again:
    test_builtin

+++++++++++++++
The Buildbot has detected a failed build on builder PPC64 AIX 3.x while building python/cpython.
Full details are available at:
    https://buildbot.python.org/all/#builders/227/builds/565

Buildbot URL: https://buildbot.python.org/all/

Worker for this Build: edelsohn-aix-ppc64
Worker for this Build: aixtools-aix-power6

----------
nosy: +Michael.Felt

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

From report at bugs.python.org  Wed Apr  1 10:41:24 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 01 Apr 2020 14:41:24 +0000
Subject: [issue31160] Enhance support.reap_children()
In-Reply-To: <1502283003.36.0.514915057261.issue31160@psf.upfronthosting.co.za>
Message-ID: <1585752084.79.0.746632859739.issue31160@roundup.psfhosted.org>


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

> With PR19263 The AIX bots are now red.

I know, I saw and I already pushed fixes.

> NameError: name 'signal' is not defined

Fixed by commit afeaea2d6e346f627b24cc9e84e2986a7266a70e.

> 1 test failed again: test_builtin

Fixed by commit 16d75675d2ad2454f6dfbf333c94e6237df36018.

----------

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

From report at bugs.python.org  Wed Apr  1 10:49:59 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 01 Apr 2020 14:49:59 +0000
Subject: [issue31160] Enhance support.reap_children()
In-Reply-To: <1502283003.36.0.514915057261.issue31160@psf.upfronthosting.co.za>
Message-ID: <1585752599.87.0.668879112803.issue31160@roundup.psfhosted.org>


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

> Ah - great. Sorry for the noise then.

It's not noise, it is useful :-)

----------

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

From report at bugs.python.org  Wed Apr  1 10:49:15 2020
From: report at bugs.python.org (Michael Felt)
Date: Wed, 01 Apr 2020 14:49:15 +0000
Subject: [issue31160] Enhance support.reap_children()
In-Reply-To: <1502283003.36.0.514915057261.issue31160@psf.upfronthosting.co.za>
Message-ID: <1585752555.97.0.236739568261.issue31160@roundup.psfhosted.org>


Michael Felt <aixtools at felt.demon.nl> added the comment:

Ah - great. Sorry for the noise then.

----------

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

From report at bugs.python.org  Wed Apr  1 11:00:19 2020
From: report at bugs.python.org (Michael Felt)
Date: Wed, 01 Apr 2020 15:00:19 +0000
Subject: [issue31160] Enhance support.reap_children()
In-Reply-To: <1502283003.36.0.514915057261.issue31160@psf.upfronthosting.co.za>
Message-ID: <1585753219.4.0.469540546724.issue31160@roundup.psfhosted.org>


Michael Felt <aixtools at felt.demon.nl> added the comment:

I think something is not yet what it needs to be:

the bots both finish test with:

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=3501.292487
test_input_no_stdout_fileno (test.test_builtin.PtyTests) ... 

And the bot status is still FAIL (aka red): failed test (failure) uploading test-results.xml (failure)

----------

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

From report at bugs.python.org  Wed Apr  1 11:03:24 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 01 Apr 2020 15:03:24 +0000
Subject: [issue31160] Enhance support.reap_children()
In-Reply-To: <1502283003.36.0.514915057261.issue31160@psf.upfronthosting.co.za>
Message-ID: <1585753404.63.0.524775247055.issue31160@roundup.psfhosted.org>


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

> I think something is not yet what it needs to be: (...)

https://buildbot.python.org/all/#/builders/227/builds/571 build failed but it has my commit 16d75675d2ad2454f6dfbf333c94e6237df36018. Ok, something failed.

Please open a new issue. This one is closed.

----------

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

From report at bugs.python.org  Wed Apr  1 11:06:16 2020
From: report at bugs.python.org (Matej Cepl)
Date: Wed, 01 Apr 2020 15:06:16 +0000
Subject: [issue12735] request full Unicode collation support in std python
 library
In-Reply-To: <1313093897.54.0.111250936422.issue12735@psf.upfronthosting.co.za>
Message-ID: <1585753576.39.0.220531422151.issue12735@roundup.psfhosted.org>


Matej Cepl <mcepl at cepl.eu> added the comment:

Isn?t this done by the system? It feels like barking at the wrong tree.

----------

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

From report at bugs.python.org  Wed Apr  1 11:06:25 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 01 Apr 2020 15:06:25 +0000
Subject: [issue40071] test__xxsubinterpreters  leaked [1, 1,
 1] references: test_ids_global()
In-Reply-To: <1585185925.55.0.269553071046.issue40071@roundup.psfhosted.org>
Message-ID: <1585753585.62.0.0476664225761.issue40071@roundup.psfhosted.org>


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


New changeset eacc07439591c97f69ab4a3d17391b009cd78ae2 by Paulo Henrique Silva in branch 'master':
bpo-40071: Fix potential crash in _functoolsmodule.c (GH-19273)
https://github.com/python/cpython/commit/eacc07439591c97f69ab4a3d17391b009cd78ae2


----------

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

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: [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 11:09:56 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 01 Apr 2020 15:09:56 +0000
Subject: [issue40071] test__xxsubinterpreters  leaked [1, 1,
 1] references: test_ids_global()
In-Reply-To: <1585185925.55.0.269553071046.issue40071@roundup.psfhosted.org>
Message-ID: <1585753796.82.0.494611944406.issue40071@roundup.psfhosted.org>


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

I closed the issue, the leak is now fixed and _functools has been fixed.

I created bpo-40137: TODO list when PEP 573 "Module State Access from C Extension Methods" will be implemented.

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

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

From report at bugs.python.org  Wed Apr  1 11:12:34 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 01 Apr 2020 15:12:34 +0000
Subject: [issue1635741] Py_Finalize() doesn't clear all Python objects at exit
Message-ID: <1585753954.89.0.789881242839.issue1635741@roundup.psfhosted.org>


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

I created bpo-40137: TODO list when PEP 573 "Module State Access from C Extension Methods" will be implemented.

It tracks code that should be fixed once PEP 573 will be implemented, like _functools and _abc modules.

----------

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

From report at bugs.python.org  Wed Apr  1 11:14:45 2020
From: report at bugs.python.org (Paulo Henrique Silva)
Date: Wed, 01 Apr 2020 15:14:45 +0000
Subject: [issue40137] TODO list when PEP 573 "Module State Access from C
 Extension Methods" will be implemented
In-Reply-To: <1585753703.83.0.0762180613721.issue40137@roundup.psfhosted.org>
Message-ID: <1585754085.02.0.461596737128.issue40137@roundup.psfhosted.org>


Change by Paulo Henrique Silva <ph.silva at gmail.com>:


----------
nosy: +phsilva

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

From report at bugs.python.org  Wed Apr  1 11:19:18 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 01 Apr 2020 15:19:18 +0000
Subject: [issue38527] configure script fails to detect "float word ordering"
 on Solaris
In-Reply-To: <1571496425.89.0.0695984738868.issue38527@roundup.psfhosted.org>
Message-ID: <1585754358.18.0.0373721494219.issue38527@roundup.psfhosted.org>


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


New changeset 5dd836030e0e399b21ab0865ae0d93934bdb3930 by Arnon Yaari in branch 'master':
bpo-38527: fix configure script for Solaris (GH-16845)
https://github.com/python/cpython/commit/5dd836030e0e399b21ab0865ae0d93934bdb3930


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

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

From report at bugs.python.org  Wed Apr  1 11:19:29 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 01 Apr 2020 15:19:29 +0000
Subject: [issue38527] configure script fails to detect "float word ordering"
 on Solaris
In-Reply-To: <1571496425.89.0.0695984738868.issue38527@roundup.psfhosted.org>
Message-ID: <1585754369.24.0.649186213974.issue38527@roundup.psfhosted.org>


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


----------
pull_requests: +18635
pull_request: https://github.com/python/cpython/pull/19279

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

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


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

Another minor issue: "assert(PyScanner_Check(self));" and "assert(PyEncoder_Check(self));" were removed by commit 33f15a16d40cb8010a8c758952cbf88d7912ee2d when _json module got a module state.

scanner_traverse(), scanner_clear(), encoder_traverse() and encoder_clear() cannot get the module state of a module using PEP 489 multiphase initialization.

Similar issue in scanner_call() and encoder_call().

I'm not sure that the PEP 573 provide a solution for this exact issue, since the intent of the assertion is to check the type of the argument. The PEP 573 gives access to the module state through types. But here we are not sure that the object type is the expected type... :-)

Again, it's a minor issue, it can be ignored. That's why I accepted to merge the commit. Technically, I don't see how we could get the wrong type in practice.

----------

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

From report at bugs.python.org  Wed Apr  1 11:20:42 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Wed, 01 Apr 2020 15:20:42 +0000
Subject: [issue40137] TODO list when PEP 573 "Module State Access from C
 Extension Methods" will be implemented
In-Reply-To: <1585753703.83.0.0762180613721.issue40137@roundup.psfhosted.org>
Message-ID: <1585754442.31.0.734944764427.issue40137@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
keywords: +patch
nosy: +corona10
nosy_count: 2.0 -> 3.0
pull_requests: +18636
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19177

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

From report at bugs.python.org  Wed Apr  1 11:38:33 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 01 Apr 2020 15:38:33 +0000
Subject: [issue38527] configure script fails to detect "float word ordering"
 on Solaris
In-Reply-To: <1571496425.89.0.0695984738868.issue38527@roundup.psfhosted.org>
Message-ID: <1585755513.66.0.238922224889.issue38527@roundup.psfhosted.org>


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


New changeset fc036409226d2c65dad9503854f09b9a39c84f14 by Miss Islington (bot) in branch '3.8':
bpo-38527: fix configure script for Solaris (GH-16845)
https://github.com/python/cpython/commit/fc036409226d2c65dad9503854f09b9a39c84f14


----------

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

From report at bugs.python.org  Wed Apr  1 11:39:16 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Wed, 01 Apr 2020 15:39:16 +0000
Subject: [issue37207] Use PEP 590 vectorcall to speed up calls to range(),
 list() and dict()
In-Reply-To: <1560072227.25.0.180298594259.issue37207@roundup.psfhosted.org>
Message-ID: <1585755556.91.0.258115798769.issue37207@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

+------------------+-------------------+-----------------------------+
| Benchmark        | master-dict-empty | bpo-37207-dict-empty        |
+==================+===================+=============================+
| bench dict empty | 502 ns            | 443 ns: 1.13x faster (-12%) |
+------------------+-------------------+-----------------------------+

+------------------+--------------------+-----------------------------+
| Benchmark        | master-dict-update | bpo-37207-dict-update       |
+==================+====================+=============================+
| bench dict empty | 497 ns             | 425 ns: 1.17x faster (-15%) |
+------------------+--------------------+-----------------------------+

+--------------------+---------------------+-----------------------------+
| Benchmark          | master-dict-kwnames | bpo-37207-dict-kwnames      |
+====================+=====================+=============================+
| bench dict kwnames | 1.38 us             | 917 ns: 1.51x faster (-34%) |
+--------------------+---------------------+-----------------------------+

----------

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

From report at bugs.python.org  Wed Apr  1 11:39:29 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Wed, 01 Apr 2020 15:39:29 +0000
Subject: [issue37207] Use PEP 590 vectorcall to speed up calls to range(),
 list() and dict()
In-Reply-To: <1560072227.25.0.180298594259.issue37207@roundup.psfhosted.org>
Message-ID: <1585755569.81.0.610880522744.issue37207@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


Added file: https://bugs.python.org/file49018/bench_dict_empty.py

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

From report at bugs.python.org  Wed Apr  1 11:39:37 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Wed, 01 Apr 2020 15:39:37 +0000
Subject: [issue37207] Use PEP 590 vectorcall to speed up calls to range(),
 list() and dict()
In-Reply-To: <1560072227.25.0.180298594259.issue37207@roundup.psfhosted.org>
Message-ID: <1585755577.31.0.0865704437946.issue37207@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


Added file: https://bugs.python.org/file49019/bench_dict_kwnames.py

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

From report at bugs.python.org  Wed Apr  1 11:39:44 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Wed, 01 Apr 2020 15:39:44 +0000
Subject: [issue37207] Use PEP 590 vectorcall to speed up calls to range(),
 list() and dict()
In-Reply-To: <1560072227.25.0.180298594259.issue37207@roundup.psfhosted.org>
Message-ID: <1585755584.27.0.34095602609.issue37207@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


Added file: https://bugs.python.org/file49020/bench_dict_update.py

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

From report at bugs.python.org  Wed Apr  1 11:40:56 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Wed, 01 Apr 2020 15:40:56 +0000
Subject: [issue37207] Use PEP 590 vectorcall to speed up calls to range(),
 list() and dict()
In-Reply-To: <1560072227.25.0.180298594259.issue37207@roundup.psfhosted.org>
Message-ID: <1585755656.09.0.275248790231.issue37207@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

@vstinner @petr.viktorin

Looks like benchmark showing very impressive result.
Can I submit the patch?

----------

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

From report at bugs.python.org  Wed Apr  1 11:45:57 2020
From: report at bugs.python.org (Petr Viktorin)
Date: Wed, 01 Apr 2020 15:45:57 +0000
Subject: [issue37207] Use PEP 590 vectorcall to speed up calls to range(),
 list() and dict()
In-Reply-To: <1560072227.25.0.180298594259.issue37207@roundup.psfhosted.org>
Message-ID: <1585755957.96.0.197434327677.issue37207@roundup.psfhosted.org>


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

> Can I submit the patch?

Yes!

If you think a patch is ready for review, just submit it. There's not much we can comment on before we see the code :)

(I hope that doesn't contradict what your mentor says...)

----------

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

From report at bugs.python.org  Wed Apr  1 11:48:51 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 01 Apr 2020 15:48:51 +0000
Subject: [issue37207] Use PEP 590 vectorcall to speed up calls to range(),
 list() and dict()
In-Reply-To: <1560072227.25.0.180298594259.issue37207@roundup.psfhosted.org>
Message-ID: <1585756131.6.0.422198041091.issue37207@roundup.psfhosted.org>


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

When I designed the FASTCALL calling convention, I experimented a new tp_fastcall slot to PyTypeObject to optimize __call__() method: bpo-29259.

Results on the pyperformance benchmark suite were not really convincing and I had technical issues (decide if tp_call or tp_fastcall should be called, handle ABI compatibility and backward compatibility, etc.). I decided to give up on this idea.

I'm happy to see that PEP 590 managed to find its way into Python internals and actually make Python faster ;-)

----------

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

From report at bugs.python.org  Wed Apr  1 11:57:53 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Wed, 01 Apr 2020 15:57:53 +0000
Subject: [issue37207] Use PEP 590 vectorcall to speed up calls to range(),
 list() and dict()
In-Reply-To: <1560072227.25.0.180298594259.issue37207@roundup.psfhosted.org>
Message-ID: <1585756673.97.0.547643891909.issue37207@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
pull_requests: +18637
stage: resolved -> patch review
pull_request: https://github.com/python/cpython/pull/19280

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

From report at bugs.python.org  Wed Apr  1 12:15:17 2020
From: report at bugs.python.org (Paul Moore)
Date: Wed, 01 Apr 2020 16:15:17 +0000
Subject: [issue40134] Inconsistent ANSI escape code handling on Windows 10
In-Reply-To: <1585739153.82.0.592216373665.issue40134@roundup.psfhosted.org>
Message-ID: <1585757717.27.0.0418963495675.issue40134@roundup.psfhosted.org>


Paul Moore <p.f.moore at gmail.com> added the comment:

This works fine for me in Windows terminal, but I see the behaviour described when using the conventional "Command prompt" window.

Enabling ANSI codes is handled via SetConsoleMode (see here: https://docs.microsoft.com/en-us/windows/console/setconsolemode). The following proof of concept script correctly displays coloured text:

    from ctypes import *
    kernel32 = windll.kernel32
    kernel32.SetConsoleMode(kernel32.GetStdHandle(-11), 7)
    ansi_red = "\x1b[31m"
    ansi_normal = "\x1b[0m"
    print(ansi_red + "This is red!" + ansi_normal)

Agreed this would be worthwhile setting on stdout by default. The code at https://docs.microsoft.com/en-us/windows/console/console-virtual-terminal-sequences#example-of-enabling-virtual-terminal-processing seems to be an example of how to do this while still supporting older systems

----------

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

From report at bugs.python.org  Wed Apr  1 12:15:29 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 01 Apr 2020 16:15:29 +0000
Subject: [issue40094] Add os.waitstatus_to_exitcode() function
In-Reply-To: <1585351787.12.0.917977186474.issue40094@roundup.psfhosted.org>
Message-ID: <1585757729.08.0.246728816446.issue40094@roundup.psfhosted.org>


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

Eryk:
> The current waitpid() implementation assumes it's okay to discard the upper 8 bits of the exit status, which can lose important information.

That's a bug which is independent of this issue.

> Thus not all abnormal terminations can be identified as such. Also, nothing stops a normal termination via ExitProcess from using an NTSTATUS code.

Ok, so the current os.waitstatus_to_exitcode() design is fine. On Windows, we can just consider all exit code as a "normal" process exit code.

And there is no need to modify os.waitpid() to return a negative value for values larger than (INT_MAX >> 8). We should "just" fix os.waitstatus_to_exitcode() to accept any Python integer and simply compute "x >> 8", whereas currently the argument is casted to a C int.

I propose to fix os.waitpid() and os.waitstatus_to_exitcode() for "large" exit code on Windows in a second time.

----------

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

From report at bugs.python.org  Wed Apr  1 12:17:55 2020
From: report at bugs.python.org (hai shi)
Date: Wed, 01 Apr 2020 16:17:55 +0000
Subject: [issue40137] TODO list when PEP 573 "Module State Access from C
 Extension Methods" will be implemented
In-Reply-To: <1585753703.83.0.0762180613721.issue40137@roundup.psfhosted.org>
Message-ID: <1585757875.69.0.566946379311.issue40137@roundup.psfhosted.org>


Change by hai shi <shihai1991 at 126.com>:


----------
nosy: +shihai1991

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

From report at bugs.python.org  Wed Apr  1 12:49:38 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 01 Apr 2020 16:49:38 +0000
Subject: [issue40094] Add os.waitstatus_to_exitcode() function
In-Reply-To: <1585351787.12.0.917977186474.issue40094@roundup.psfhosted.org>
Message-ID: <1585759778.38.0.954459310814.issue40094@roundup.psfhosted.org>


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


New changeset 65a796e5272f61b42792d3a8c69686558c1872c5 by Victor Stinner in branch 'master':
bpo-40094: Add os.waitstatus_to_exitcode() (GH-19201)
https://github.com/python/cpython/commit/65a796e5272f61b42792d3a8c69686558c1872c5


----------

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

From report at bugs.python.org  Wed Apr  1 12:52:39 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 01 Apr 2020 16:52:39 +0000
Subject: [issue38527] configure script fails to detect "float word ordering"
 on Solaris
In-Reply-To: <1571496425.89.0.0695984738868.issue38527@roundup.psfhosted.org>
Message-ID: <1585759959.22.0.399860075087.issue38527@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


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

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

From report at bugs.python.org  Wed Apr  1 12:54:17 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 01 Apr 2020 16:54:17 +0000
Subject: [issue40094] Add os.waitstatus_to_exitcode() function
In-Reply-To: <1585351787.12.0.917977186474.issue40094@roundup.psfhosted.org>
Message-ID: <1585760057.07.0.82863037692.issue40094@roundup.psfhosted.org>


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

sys.exit() accepts negative number and values larger than 255. I checked with strace: Python calls Linux exit_group() syscall with the value passed to sys.exit().

But then os.waitid() (waitid, not waitpid!) returns the lower 8-bits of the exit code.

In fact, the exit_group() syscall truncates the exit status:
https://github.com/torvalds/linux/blob/1a323ea5356edbb3073dc59d51b9e6b86908857d/kernel/exit.c#L895-L905

So on Linux, an exit code is always in the range [0; 255]. For example, exit_group(-1) syscall gives an exit code of 255.

----------

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

From report at bugs.python.org  Wed Apr  1 12:55:48 2020
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 01 Apr 2020 16:55:48 +0000
Subject: [issue39837] Remove Azure Pipelines from GitHub PRs
In-Reply-To: <1583255119.77.0.277327127951.issue39837@roundup.psfhosted.org>
Message-ID: <1585760148.51.0.121770549768.issue39837@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

> Is it possible to make Travis CI required and make Azure Pipelines not required?

Yes, but I don't want to to do that as we have had equivalent flakiness issues with Travis which is why it isn't required ATM.

The only way to prevent flaky CI from blocking anything is to simply make no CI required and trust core devs not to merge unless they are certain they know why a CI run failed (although I don't know what that does to miss-islington). Passed that is being extremely specific about what CI is considered stable enough to block on an would probably need to be down to the OS level on top of what is being tested.

----------

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

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


Benedikt Bleimhofer <benedikt.bleimhofer at gmail.com> added the comment:

Thx for this really helpful info.
After reading the article i switched all my code from using pytz to dateutil.tz.

----------

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

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: [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 13:16:54 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 01 Apr 2020 17:16:54 +0000
Subject: [issue40094] Add os.waitstatus_to_exitcode() function
In-Reply-To: <1585351787.12.0.917977186474.issue40094@roundup.psfhosted.org>
Message-ID: <1585761414.11.0.228283987477.issue40094@roundup.psfhosted.org>


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

TODO:

* Modify asyncio.unix_events._compute_returncode() to use waitstatus_to_exitcode(): need to update tests.
* Modify run_cgi() of http.server to log the exit code rather the exit status: use waitstatus_to_exitcode().
* Modify Tools/scripts/which.py to log the exit code using waitstatus_to_exitcode(): result of os.system('ls ' + longlist + ' ' + filename).
* Modify mailcap.test() to use waitstatus_to_exitcode(): os.system(command).
* Fix CI to get PR 19277 and PR 19278 merged.
* Decide if subprocess should reject WIFSTOPPED() or not.
* Check if the pure Python implementation of os._spawnvef() handles WIFSTOPPED() properly.
* Maybe implement timeout on Windows for test.support.wait_process().


Eryk Sun:
> FWIW, I wouldn't recommend relying on os.waitpid to get the correct process exit status in Windows. Status codes are 32 bits and generally all bits are required.

I created bpo-40138 "Windows implementation of os.waitpid() truncates the exit status (status << 8)".

----------

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

From report at bugs.python.org  Wed Apr  1 13:34:26 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Wed, 01 Apr 2020 17:34:26 +0000
Subject: [issue40048] _PyEval_EvalFrameDefault() doesn't reset tstate->frame
 if _PyCode_InitOpcache() fails
In-Reply-To: <1584974213.54.0.484285807208.issue40048@roundup.psfhosted.org>
Message-ID: <1585762466.61.0.881811146218.issue40048@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
nosy: +corona10

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

From report at bugs.python.org  Wed Apr  1 13:47:38 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Wed, 01 Apr 2020 17:47:38 +0000
Subject: [issue39740] Select module fails to build on Solaris 11.4
In-Reply-To: <1582564565.67.0.773509979349.issue39740@roundup.psfhosted.org>
Message-ID: <1585763258.25.0.879374844305.issue39740@roundup.psfhosted.org>


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


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

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

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: [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 14:16:32 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 01 Apr 2020 18:16:32 +0000
Subject: [issue40138] Windows implementation of os.waitpid() truncates the
 exit status (status << 8)
In-Reply-To: <1585760727.67.0.797995887325.issue40138@roundup.psfhosted.org>
Message-ID: <1585764992.01.0.0422614388389.issue40138@roundup.psfhosted.org>


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


----------
nosy: +eryksun

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

From report at bugs.python.org  Wed Apr  1 14:21:46 2020
From: report at bugs.python.org (Ahmad Azizi)
Date: Wed, 01 Apr 2020 18:21:46 +0000
Subject: [issue12735] request full Unicode collation support in std python
 library
In-Reply-To: <1313093897.54.0.111250936422.issue12735@psf.upfronthosting.co.za>
Message-ID: <1585765306.31.0.492782533038.issue12735@roundup.psfhosted.org>


Ahmad Azizi <activepost at gmail.com> added the comment:

No, this is not an OS dependent issue. Python does not use Unicode collation(uses utf-8) for sorting.

----------
versions:  -Python 3.4

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

From report at bugs.python.org  Wed Apr  1 14:34:22 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 01 Apr 2020 18:34:22 +0000
Subject: [issue40048] _PyEval_EvalFrameDefault() doesn't reset tstate->frame
 if _PyCode_InitOpcache() fails
In-Reply-To: <1584974213.54.0.484285807208.issue40048@roundup.psfhosted.org>
Message-ID: <1585766062.09.0.645157378627.issue40048@roundup.psfhosted.org>


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

Will prepare a pr soon

----------

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

From report at bugs.python.org  Wed Apr  1 14:37:04 2020
From: report at bugs.python.org (Steve Dower)
Date: Wed, 01 Apr 2020 18:37:04 +0000
Subject: [issue39837] Remove Azure Pipelines from GitHub PRs
In-Reply-To: <1583255119.77.0.277327127951.issue39837@roundup.psfhosted.org>
Message-ID: <1585766224.95.0.589477511292.issue39837@roundup.psfhosted.org>


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

Or we could remove the path filter on GitHub Actions so that all checks run even for doc-only changes? Then they can be marked as required.

----------

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

From report at bugs.python.org  Wed Apr  1 15:25:11 2020
From: report at bugs.python.org (Kyle Stanley)
Date: Wed, 01 Apr 2020 19:25:11 +0000
Subject: [issue40115] test_asyncio leaked [3, 3, 3] references, sum=9
In-Reply-To: <1585579110.73.0.577311644063.issue40115@roundup.psfhosted.org>
Message-ID: <1585769111.9.0.197204487993.issue40115@roundup.psfhosted.org>


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

Currently working on addressing this, see bpo-39812. If I can't find a fix by tonight, I'll open a PR to revert it for now so that other regressions don't go undetected in the meantime.

----------
nosy: +aeros

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

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: [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:19:49 2020
From: report at bugs.python.org (Kyle Stanley)
Date: Wed, 01 Apr 2020 20:19:49 +0000
Subject: [issue40115] test_asyncio leaked [3, 3, 3] references, sum=9
In-Reply-To: <1585579110.73.0.577311644063.issue40115@roundup.psfhosted.org>
Message-ID: <1585772389.71.0.412184895317.issue40115@roundup.psfhosted.org>


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

I was able to find a fix! Specifically, I think the issue was a subtle problem with test_run_in_executor_cancel: it never properly shuts down the executor prior to closing the event loop. 

We do this in asyncio.run() (with the loop.shutdown_default_executor() that I added last year), but it should be called explicitly when using loop.close() directly. Otherwise, the resources of the executor may not be cleaned up properly. I think the issue was being covered up because of the usage of daemon threads in the ThreadPoolExecutor, but revealed itself when the workers were converted to non-daemon threads since they require proper cleanup.

The change is very minimal:

```
    def test_run_in_executor_cancel(self):
        called = False

        def patched_call_soon(*args):
            nonlocal called
            called = True

        def run():
            time.sleep(0.05)

        f2 = self.loop.run_in_executor(None, run)
        f2.cancel()
+      self.loop.run_until_complete(
+          self.loop.shutdown_default_executor())
        self.loop.close()
        self.loop.call_soon = patched_call_soon
        self.loop.call_soon_threadsafe = patched_call_soon
        time.sleep(0.4)
        self.assertFalse(called)
```

Before change:
```
[aeros:~/repos/aeros-cpython]$ ./python -m test --fail-env-changed -R 3:3 test_asyncio -m test.test_asyncio.test_events.EPollEventLoopTests.test_run_in_executor_cancel
0:00:00 load avg: 0.63 Run tests sequentially
0:00:00 load avg: 0.63 [1/1] test_asyncio
beginning 6 repetitions
123456
......
test_asyncio leaked [1, 1, 1] references, sum=3
test_asyncio leaked [2, 1, 1] memory blocks, sum=4
test_asyncio failed

== Tests result: FAILURE ==

1 test failed:
    test_asyncio

Total duration: 3.2 sec
Tests result: FAILURE
```

After change:
```
[aeros:~/repos/aeros-cpython]$ ./python -m test --fail-env-changed -R 3:3 test_asyncio -m test.test_asyncio.test_events.EPollEventLoopTests.test_run_in_executor_cancel
0:00:00 load avg: 0.24 Run tests sequentially
0:00:00 load avg: 0.24 [1/1] test_asyncio
beginning 6 repetitions
123456
......

== Tests result: SUCCESS ==

1 test OK.

Total duration: 3.5 sec
Tests result: SUCCESS
```

I'll also test the PR using the `test-with-buildbots` label to double check, it should be attached to this issue within the next couple of hours.

----------

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

From report at bugs.python.org  Wed Apr  1 16:30:07 2020
From: report at bugs.python.org (Furkan Onder)
Date: Wed, 01 Apr 2020 20:30:07 +0000
Subject: [issue15140] PEP 384 inconsistent with implementation
In-Reply-To: <1340388687.85.0.64744522039.issue15140@psf.upfronthosting.co.za>
Message-ID: <1585773007.14.0.846168082587.issue15140@roundup.psfhosted.org>


Furkan Onder <furkanonder at protonmail.com> added the comment:

It fixed.

----------
nosy: +furkanonder

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

From report at bugs.python.org  Wed Apr  1 16:36:17 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 01 Apr 2020 20:36:17 +0000
Subject: [issue15140] PEP 384 inconsistent with implementation
In-Reply-To: <1340388687.85.0.64744522039.issue15140@psf.upfronthosting.co.za>
Message-ID: <1585773377.22.0.458136844015.issue15140@roundup.psfhosted.org>


Change by Guido van Rossum <guido at python.org>:


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

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

From report at bugs.python.org  Wed Apr  1 16:40:11 2020
From: report at bugs.python.org (Kyle Stanley)
Date: Wed, 01 Apr 2020 20:40:11 +0000
Subject: [issue40115] test_asyncio leaked [3, 3, 3] references, sum=9
In-Reply-To: <1585579110.73.0.577311644063.issue40115@roundup.psfhosted.org>
Message-ID: <1585773611.5.0.506771625633.issue40115@roundup.psfhosted.org>


Change by Kyle Stanley <aeros167 at gmail.com>:


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

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

From report at bugs.python.org  Wed Apr  1 16:44:40 2020
From: report at bugs.python.org (Kyle Stanley)
Date: Wed, 01 Apr 2020 20:44:40 +0000
Subject: [issue39812] Avoid daemon threads in concurrent.futures
In-Reply-To: <1583071410.96.0.599538732629.issue39812@roundup.psfhosted.org>
Message-ID: <1585773880.56.0.94753969765.issue39812@roundup.psfhosted.org>


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

I attached a PR to bpo-40115 to address the refleak in test_asyncio: PR-19282.

----------

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

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: [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 16:50:02 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 01 Apr 2020 20:50:02 +0000
Subject: [issue40141] Add line and column information for keywords in the AST
In-Reply-To: <1585774156.85.0.46549854345.issue40141@roundup.psfhosted.org>
Message-ID: <1585774202.62.0.0523130935653.issue40141@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


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

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

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


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

I am preparing more PRs for other nodes that are missing the meta-information as well but will open them in a separate issue.

----------

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

From report at bugs.python.org  Wed Apr  1 17:41:47 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 01 Apr 2020 21:41:47 +0000
Subject: [issue40140] test_builtin crashes when runned in parallel mode on
 solaris
In-Reply-To: <1585769988.66.0.906908269911.issue40140@roundup.psfhosted.org>
Message-ID: <1585777307.87.0.658572035556.issue40140@roundup.psfhosted.org>


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

Try making bigger the stack size (with ulimit -s ... or similar)

----------
nosy: +pablogsal

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

From report at bugs.python.org  Wed Apr  1 17:42:59 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 01 Apr 2020 21:42:59 +0000
Subject: [issue31160] Enhance support.reap_children()
In-Reply-To: <1502283003.36.0.514915057261.issue31160@psf.upfronthosting.co.za>
Message-ID: <1585777379.29.0.805902513873.issue31160@roundup.psfhosted.org>


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

> Please open a new issue. This one is closed.

Pablo Galindo opened bpo-40140, let's use this one.

----------

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

From report at bugs.python.org  Wed Apr  1 17:48:12 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 01 Apr 2020 21:48:12 +0000
Subject: [issue40140] test_builtin crashes when runned in parallel mode on
 solaris
In-Reply-To: <1585769988.66.0.906908269911.issue40140@roundup.psfhosted.org>
Message-ID: <1585777692.44.0.531517822071.issue40140@roundup.psfhosted.org>


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

I modified recently the test:

(1) commit 278c1e159c970da6cd6683d18c6211f5118674cc

-        os.waitpid(pid, 0)
+        support.wait_process(pid, exitcode=0)

(2) commit 16d75675d2ad2454f6dfbf333c94e6237df36018

Close the fd *after* calling support.wait_process() to prevent sending SIGHUP to the child process, which made support.wait_process(pid, exitcode=0) to fail since exitcode=-1 (-SIGHUP) != 0.

--

test_builtin.test_input_no_stdout_fileno() also hangs on AIX:
https://bugs.python.org/issue31160#msg365478

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

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

From report at bugs.python.org  Wed Apr  1 17:50:39 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 01 Apr 2020 21:50:39 +0000
Subject: [issue40140] test_builtin crashes when runned in parallel mode on
 solaris
In-Reply-To: <1585769988.66.0.906908269911.issue40140@roundup.psfhosted.org>
Message-ID: <1585777839.28.0.27944109848.issue40140@roundup.psfhosted.org>


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

I am understanding "crashing" as "segfaulting"

----------

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

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: [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 17:59:33 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 01 Apr 2020 21:59:33 +0000
Subject: [issue40140] test_builtin crashes when runned in parallel mode on
 solaris
In-Reply-To: <1585769988.66.0.906908269911.issue40140@roundup.psfhosted.org>
Message-ID: <1585778373.45.0.436905155302.issue40140@roundup.psfhosted.org>


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

> 0:00:01 load avg: 1.70 [1/1/1] test_builtin crashed (Exit code -1)

Exit code -1 looks like a process killed by SIGHUP. Which commit did you try?

Can you please check that you tested with my commit 16d75675d2ad2454f6dfbf333c94e6237df36018?

----------

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

From report at bugs.python.org  Wed Apr  1 18:03:51 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 01 Apr 2020 22:03:51 +0000
Subject: [issue31160] Enhance support.reap_children()
In-Reply-To: <1502283003.36.0.514915057261.issue31160@psf.upfronthosting.co.za>
Message-ID: <1585778631.9.0.96650358512.issue31160@roundup.psfhosted.org>


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

> Pablo Galindo opened bpo-40140, let's use this one.

Note: Oops, Batuhan created it, Pablo only commented.

----------

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

From report at bugs.python.org  Wed Apr  1 18:04:39 2020
From: report at bugs.python.org (Chris Barker)
Date: Wed, 01 Apr 2020 22:04:39 +0000
Subject: [issue33493] dataclasses: allow keyword-only arguments
In-Reply-To: <1526293950.07.0.682650639539.issue33493@psf.upfronthosting.co.za>
Message-ID: <1585778679.84.0.680534663076.issue33493@roundup.psfhosted.org>


Chris Barker <Chris.Barker at noaa.gov> added the comment:

This does not actually appear to be a Duplicate of #33129.

That one was asking to add **kwargs (I think) to the __init__. And was discussed and I think rejected on gitHub:

https://github.com/python/cpython/pull/19206

But this calls for having keyword-only parameters, which I think would still be a good idea.

----------
nosy: +ChrisBarker

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

From report at bugs.python.org  Wed Apr  1 18:06:02 2020
From: report at bugs.python.org (Kyle Stanley)
Date: Wed, 01 Apr 2020 22:06:02 +0000
Subject: [issue40024] Add PyModule_AddType helper function
In-Reply-To: <1584697189.32.0.684240851627.issue40024@roundup.psfhosted.org>
Message-ID: <1585778762.75.0.936486561479.issue40024@roundup.psfhosted.org>


Change by Kyle Stanley <aeros167 at gmail.com>:


----------
nosy: +aeros
nosy_count: 3.0 -> 4.0
pull_requests: +18641
pull_request: https://github.com/python/cpython/pull/19282

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

From report at bugs.python.org  Wed Apr  1 18:08:27 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 01 Apr 2020 22:08:27 +0000
Subject: [issue39837] Remove Azure Pipelines from GitHub PRs
In-Reply-To: <1583255119.77.0.277327127951.issue39837@roundup.psfhosted.org>
Message-ID: <1585778907.16.0.866865992148.issue39837@roundup.psfhosted.org>


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

> Yes, but I don't want to to do that as we have had equivalent flakiness issues with Travis which is why it isn't required ATM.

I'm not aware of Travis CI current issue. There were issues in the past, as with any CI, right ;-) Travis CI looks quite reliable these days.

Whereas the Docs and Ubuntu GH Action job of Azure failed to install dependencies :-(

----------

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

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: [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: [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:31:45 2020
From: report at bugs.python.org (Kyle Stanley)
Date: Wed, 01 Apr 2020 22:31:45 +0000
Subject: [issue40024] Add PyModule_AddType helper function
In-Reply-To: <1584697189.32.0.684240851627.issue40024@roundup.psfhosted.org>
Message-ID: <1585780305.12.0.02607273734.issue40024@roundup.psfhosted.org>


Change by Kyle Stanley <aeros167 at gmail.com>:


----------
pull_requests:  -18641

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

From report at bugs.python.org  Wed Apr  1 18:33:07 2020
From: report at bugs.python.org (Kyle Stanley)
Date: Wed, 01 Apr 2020 22:33:07 +0000
Subject: [issue40024] Add PyModule_AddType helper function
In-Reply-To: <1584697189.32.0.684240851627.issue40024@roundup.psfhosted.org>
Message-ID: <1585780387.7.0.47904748176.issue40024@roundup.psfhosted.org>


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

(disregard the above, the PR was mistakenly linked from a GitHub bug)

----------

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

From report at bugs.python.org  Wed Apr  1 18:34:52 2020
From: report at bugs.python.org (Nick Guenther)
Date: Wed, 01 Apr 2020 22:34:52 +0000
Subject: [issue40110] multiprocessing.Pool.imap() should be lazy
In-Reply-To: <1585541187.46.0.606629490552.issue40110@roundup.psfhosted.org>
Message-ID: <1585780492.17.0.42194278579.issue40110@roundup.psfhosted.org>


Nick Guenther <nick at kousu.ca> added the comment:

Thank you for taking the time to consider my points! Yes, I think you understood exactly what I was getting at.

I slept on it and thought about what I'd posted the day after and realized most of the points you raise, especially that serialized next() would mean serialized processing. So the naive approach is out.

I am motivated by trying to introduce backpressure to my pipelines. The example you gave has potentially infinite memory usage; if I simply slow it down with sleep() I get a memory leak and the main python proc pinning my CPU, even though it "isn't" doing anything:

    with multiprocessing.Pool(4) as pool:
        for i, v in enumerate(pool.imap(worker, itertools.count(1)), 1):
            time.sleep(7)
            print(f"At {i}: {v}, memory usage is {sys.getallocatedblocks()}")

At 1->1, memory usage is 230617
At 2->8, memory usage is 411053
At 3->27, memory usage is 581439
At 4->64, memory usage is 748584
At 5->125, memory usage is 909694
At 6->216, memory usage is 1074304
At 7->343, memory usage is 1238106
At 8->512, memory usage is 1389162
At 9->729, memory usage is 1537830
At 10->1000, memory usage is 1648502
At 11->1331, memory usage is 1759864
At 12->1728, memory usage is 1909807
At 13->2197, memory usage is 2005700
At 14->2744, memory usage is 2067407
At 15->3375, memory usage is 2156479
At 16->4096, memory usage is 2240936
At 17->4913, memory usage is 2328123
At 18->5832, memory usage is 2456865
At 19->6859, memory usage is 2614602
At 20->8000, memory usage is 2803736
At 21->9261, memory usage is 2999129

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND     
11314 kousu     20   0  303308  40996   6340 S  91.4  2.1   0:21.68 python3.8   
11317 kousu     20   0   54208  10264   4352 S  16.2  0.5   0:03.76 python3.8   
11315 kousu     20   0   54208  10260   4352 S  15.8  0.5   0:03.74 python3.8   
11316 kousu     20   0   54208  10260   4352 S  15.8  0.5   0:03.74 python3.8   
11318 kousu     20   0   54208  10264   4352 S  15.5  0.5   0:03.72 python3.8 

It seems to me like any usage of Pool.imap() either has the same issue lurking or is run on a small finite data set where you are better off using Pool.map().

I like generators because they keep constant-time constant-memory work, which seems like a natural fit for stream processing situations. Unix pipelines have backpressure built-in, because write() blocks when the pipe buffer is full.

I did come up with one possibility after sleeping on it again: run the final iteration in parallel, perhaps by a special plist() method that makes as many parallel next() calls as possible. There's definitely details to work out but I plan to prototype when I have spare time in the next couple weeks.

You're entirely right that it's a risky change to suggest, so maybe it would be best expressed as a package if I get it working. Can I keep this issue open to see if it draws in insights from anyone else in the meantime?

Thanks again for taking a look! That's really cool of you!

----------

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

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


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

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

test.pythoninfo says:

os.uname: posix.uname_result(sysname='Darwin', nodename='Mac-1307.local', release='19.4.0', version='Darwin Kernel Version 19.4.0: Wed Mar  4 22:28:40 PST 2020; root:xnu-6153.101.6~15/RELEASE_X86_64', machine='x86_64')

platform.platform: macOS-10.15.4-x86_64-i386-64bit

----------

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

From report at bugs.python.org  Wed Apr  1 18:38:14 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Wed, 01 Apr 2020 22:38:14 +0000
Subject: [issue40141] Add line and column information for keywords in the AST
In-Reply-To: <1585774156.85.0.46549854345.issue40141@roundup.psfhosted.org>
Message-ID: <1585780694.0.0.535958945698.issue40141@roundup.psfhosted.org>


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


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

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

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


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

Other errors on the same build:

13 tests failed:
    test_capi test_cmd_line test_exceptions test_faulthandler test_gc
    test_io test_repl test_resource test_selectors test_subprocess
    test_sys test_tempfile test_tracemalloc

test_subprocess: AttributeError: module 'resource' has no attribute 'RLIMIT_NOFILE'

test_selectors.test_above_fd_setsize(): AttributeError: module 'resource' has no attribute 'RLIMIT_NOFILE'

test_resource.test_getrusage(): AttributeError: module 'resource' has no attribute 'RUSAGE_SELF'

Many tests failed because of SuppressCrashReport issue (missing resource.RLIMIT_CORE).

----------

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

From report at bugs.python.org  Wed Apr  1 18:43:32 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 01 Apr 2020 22:43:32 +0000
Subject: [issue40144] test.support.SuppressCrashReport fails on macOS 10.15.4
In-Reply-To: <1585780194.51.0.469585902062.issue40144@roundup.psfhosted.org>
Message-ID: <1585781012.1.0.931335717826.issue40144@roundup.psfhosted.org>


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

Yesterday, macOS job was fine with test.pythoninfo:

os.uname: posix.uname_result(sysname='Darwin', nodename='Mac-1303.local', release='19.3.0', version='Darwin Kernel Version 19.3.0: Thu Jan  9 20:58:23 PST 2020; root:xnu-6153.81.5~1/RELEASE_X86_64', machine='x86_64')

platform.platform: macOS-10.15.3-x86_64-i386-64bit


So something changed in<sys/resource.h> header between macOS 10.15.3 and macOS 10.15.4.

----------
components: +macOS
nosy: +ned.deily, ronaldoussoren
title: test.support.SuppressCrashReport fails on macOS -> test.support.SuppressCrashReport fails on macOS 10.15.4

_______________________________________
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: [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 18:49:16 2020
From: report at bugs.python.org (Alexander Riccio)
Date: Wed, 01 Apr 2020 22:49:16 +0000
Subject: [issue40145] Pyshellext room for binary size improvement
In-Reply-To: <1585781037.54.0.0844996141167.issue40145@roundup.psfhosted.org>
Message-ID: <1585781356.17.0.269651428474.issue40145@roundup.psfhosted.org>


Change by Alexander Riccio <test35965 at gmail.com>:


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

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

From report at bugs.python.org  Wed Apr  1 18:57:25 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 01 Apr 2020 22:57:25 +0000
Subject: [issue40144] resource: RLIMIT_xxx and RUSAGE_xxx constants are
 missing on macOS 10.15.4
In-Reply-To: <1585780194.51.0.469585902062.issue40144@roundup.psfhosted.org>
Message-ID: <1585781845.46.0.0991585859111.issue40144@roundup.psfhosted.org>


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


----------
title: test.support.SuppressCrashReport fails on macOS 10.15.4 -> resource: RLIMIT_xxx and RUSAGE_xxx constants are missing on macOS 10.15.4

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

From report at bugs.python.org  Wed Apr  1 19:14:38 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 01 Apr 2020 23:14:38 +0000
Subject: [issue40094] Add os.waitstatus_to_exitcode() function
In-Reply-To: <1585351787.12.0.917977186474.issue40094@roundup.psfhosted.org>
Message-ID: <1585782878.56.0.0502070665353.issue40094@roundup.psfhosted.org>


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


----------
pull_requests: +18643
pull_request: https://github.com/python/cpython/pull/19285

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

From report at bugs.python.org  Wed Apr  1 19:22:36 2020
From: report at bugs.python.org (Anthony Sottile)
Date: Wed, 01 Apr 2020 23:22:36 +0000
Subject: [issue30465] FormattedValue expressions have wrong lineno and
 col_offset information
In-Reply-To: <1495666417.53.0.222363680661.issue30465@psf.upfronthosting.co.za>
Message-ID: <1585783356.16.0.820807166309.issue30465@roundup.psfhosted.org>


Change by Anthony Sottile <asottile at umich.edu>:


----------
nosy: +Anthony Sottile
nosy_count: 6.0 -> 7.0
pull_requests: +18644
pull_request: https://github.com/python/cpython/pull/10021

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

From report at bugs.python.org  Wed Apr  1 19:24:04 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 01 Apr 2020 23:24:04 +0000
Subject: [issue40094] Add os.waitstatus_to_exitcode() function
In-Reply-To: <1585351787.12.0.917977186474.issue40094@roundup.psfhosted.org>
Message-ID: <1585783444.15.0.427162054607.issue40094@roundup.psfhosted.org>


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

See also: "Appendix E. Exit Codes With Special Meanings" section of the Bash documentation
https://tldp.org/LDP/abs/html/exitcodes.html

----------

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

From report at bugs.python.org  Wed Apr  1 19:24:28 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 01 Apr 2020 23:24:28 +0000
Subject: [issue40094] Add os.waitstatus_to_exitcode() function
In-Reply-To: <1585351787.12.0.917977186474.issue40094@roundup.psfhosted.org>
Message-ID: <1585783468.41.0.729446354845.issue40094@roundup.psfhosted.org>


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


----------
pull_requests: +18645
pull_request: https://github.com/python/cpython/pull/19286

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

From report at bugs.python.org  Wed Apr  1 19:26:59 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 01 Apr 2020 23:26:59 +0000
Subject: [issue40094] Add os.waitstatus_to_exitcode() function
In-Reply-To: <1585351787.12.0.917977186474.issue40094@roundup.psfhosted.org>
Message-ID: <1585783619.09.0.343036664716.issue40094@roundup.psfhosted.org>


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


New changeset 267afc2ab2014e1e3c6b2ff088350a69b691a544 by Miss Islington (bot) in branch '3.8':
bpo-40094: Enhance os.WIFEXITED documentation (GH-19244) (GH-19277)
https://github.com/python/cpython/commit/267afc2ab2014e1e3c6b2ff088350a69b691a544


----------

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

From report at bugs.python.org  Wed Apr  1 19:26:54 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 01 Apr 2020 23:26:54 +0000
Subject: [issue40094] Add os.waitstatus_to_exitcode() function
In-Reply-To: <1585351787.12.0.917977186474.issue40094@roundup.psfhosted.org>
Message-ID: <1585783614.2.0.863428998987.issue40094@roundup.psfhosted.org>


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


New changeset c8dd641b6214bdcf794bab469a51da6843feb770 by Miss Islington (bot) in branch '3.7':
bpo-40094: Enhance os.WIFEXITED documentation (GH-19244) (GH-19278)
https://github.com/python/cpython/commit/c8dd641b6214bdcf794bab469a51da6843feb770


----------

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

From report at bugs.python.org  Wed Apr  1 19:27:10 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 01 Apr 2020 23:27:10 +0000
Subject: [issue40094] Add os.waitstatus_to_exitcode() function
In-Reply-To: <1585351787.12.0.917977186474.issue40094@roundup.psfhosted.org>
Message-ID: <1585783630.53.0.892523250174.issue40094@roundup.psfhosted.org>


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


----------
pull_requests: +18646
pull_request: https://github.com/python/cpython/pull/19287

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

From report at bugs.python.org  Wed Apr  1 19:47:58 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 01 Apr 2020 23:47:58 +0000
Subject: [issue40141] Add line and column information for keywords in the AST
In-Reply-To: <1585774156.85.0.46549854345.issue40141@roundup.psfhosted.org>
Message-ID: <1585784878.22.0.232035555223.issue40141@roundup.psfhosted.org>


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


New changeset 168660b547d5f683c5d3c60447cfa8c6d620efc3 by Pablo Galindo in branch 'master':
bpo-40141: Add line and column information to ast.keyword nodes (GH-19283)
https://github.com/python/cpython/commit/168660b547d5f683c5d3c60447cfa8c6d620efc3


----------

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

From report at bugs.python.org  Wed Apr  1 19:59:19 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 01 Apr 2020 23:59:19 +0000
Subject: [issue40094] Add os.waitstatus_to_exitcode() function
In-Reply-To: <1585351787.12.0.917977186474.issue40094@roundup.psfhosted.org>
Message-ID: <1585785559.67.0.181770053128.issue40094@roundup.psfhosted.org>


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

> Decide if subprocess should reject WIFSTOPPED() or not.

This code path was added by bpo-29335.

----------

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

From report at bugs.python.org  Wed Apr  1 20:00:09 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 02 Apr 2020 00:00:09 +0000
Subject: [issue40094] Add os.waitstatus_to_exitcode() function
In-Reply-To: <1585351787.12.0.917977186474.issue40094@roundup.psfhosted.org>
Message-ID: <1585785609.49.0.789296246444.issue40094@roundup.psfhosted.org>


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


New changeset d57cf557366584539f400db523b555296487e8f5 by Victor Stinner in branch 'master':
bpo-40094: mailcap.test() uses waitstatus_to_exitcode() (GH-19287)
https://github.com/python/cpython/commit/d57cf557366584539f400db523b555296487e8f5


----------

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

From report at bugs.python.org  Wed Apr  1 20:06:26 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 02 Apr 2020 00:06:26 +0000
Subject: [issue40141] Add line and column information for keywords in the AST
In-Reply-To: <1585774156.85.0.46549854345.issue40141@roundup.psfhosted.org>
Message-ID: <1585785986.44.0.368585372444.issue40141@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


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

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

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: [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:15:11 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 02 Apr 2020 00:15:11 +0000
Subject: [issue40146] Upgrade Azure Pipelines to OpenSSL 1.1.1f
In-Reply-To: <1585786427.57.0.72048128353.issue40146@roundup.psfhosted.org>
Message-ID: <1585786511.28.0.290749822845.issue40146@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Wed Apr  1 20:18:20 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 02 Apr 2020 00:18:20 +0000
Subject: [issue39837] Remove Azure Pipelines from GitHub PRs
In-Reply-To: <1583255119.77.0.277327127951.issue39837@roundup.psfhosted.org>
Message-ID: <1585786700.74.0.950899589276.issue39837@roundup.psfhosted.org>


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

About the "Install Dependencies" issue, I created bpo-40146: "Upgrade Azure Pipelines to OpenSSL 1.1.1f".

I don't understand how it's possible that the Ubuntu job passed in the GitHub action, but failed in Azure Pipelines. Maybe there was a download cache somehow, and the cache is now outdated.

----------

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

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


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

Because of this issue, "Azure Pipelines PR" fails on pull requests and so it's no longer possible to merge any pull request.

----------

_______________________________________
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: [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:23:07 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 02 Apr 2020 00:23:07 +0000
Subject: [issue40147] Move checking for duplicated keywords to the compiler
In-Reply-To: <1585786944.89.0.491246758826.issue40147@roundup.psfhosted.org>
Message-ID: <1585786987.42.0.920398946088.issue40147@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
nosy: +lys.nikolaou

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

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


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


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

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

From report at bugs.python.org  Wed Apr  1 20:25:00 2020
From: report at bugs.python.org (Ben Caller)
Date: Thu, 02 Apr 2020 00:25:00 +0000
Subject: [issue39503] [security][CVE-2020-8492] Denial of service in
 urllib.request.AbstractBasicAuthHandler
In-Reply-To: <1580397089.41.0.564267118679.issue39503@roundup.psfhosted.org>
Message-ID: <1585787100.15.0.433706203983.issue39503@roundup.psfhosted.org>


Ben Caller <bcaller at gmail.com> added the comment:

Instead of

repeat_10_3 = 'Basic ' + ', ' * (10 ** 3) + simple

in the benchmark, try

repeat_10_3 = 'Basic ' + ', ' * (10 ** 3) + 'A'

----------
Added file: https://bugs.python.org/file49022/bench_parser2.py

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

From report at bugs.python.org  Wed Apr  1 20:36:42 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 02 Apr 2020 00:36:42 +0000
Subject: [issue40120] Undefined C behavior going beyond end of struct via a
 [1] arrays.
In-Reply-To: <1585602263.71.0.279519604291.issue40120@roundup.psfhosted.org>
Message-ID: <1585787802.56.0.367415240492.issue40120@roundup.psfhosted.org>


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

> How is it an undefined C behavior? It works well in practice, no?

Famous last words ;)

----------
nosy: +pablogsal

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

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: [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 20:44:09 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 02 Apr 2020 00:44:09 +0000
Subject: [issue39503] [security][CVE-2020-8492] Denial of service in
 urllib.request.AbstractBasicAuthHandler
In-Reply-To: <1580397089.41.0.564267118679.issue39503@roundup.psfhosted.org>
Message-ID: <1585788249.05.0.124264820797.issue39503@roundup.psfhosted.org>


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

Ooooh, I see. I didn't measure the performance of the right header. I re-run a benchmark using the HTTP header (repeat=15):

    header = 'Basic ' + ', ' * 15 + 'A'

Now I see a major performance difference. Comparison between master ("ref") and PR 18284 ("fix"):

Mean +- std dev: [ref] 88.9 ms +- 2.4 ms -> [fix] 17.5 us +- 0.7 us: 5083.23x faster (-100%)

So the worst case is now way faster: more than 5000x faster!

It's even possible to go up to repeat=10**6 characters, it still takes less than 1 seconds: 412 ms +- 19 ms.

On the master branch, repeat=20 already takes around 3 seconds... The slowdown is exponential with repeat increase.

----------

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

From report at bugs.python.org  Wed Apr  1 20:46:00 2020
From: report at bugs.python.org (Ben Caller)
Date: Thu, 02 Apr 2020 00:46:00 +0000
Subject: [issue39503] [security][CVE-2020-8492] Denial of service in
 urllib.request.AbstractBasicAuthHandler
In-Reply-To: <1580397089.41.0.564267118679.issue39503@roundup.psfhosted.org>
Message-ID: <1585788360.27.0.904031656036.issue39503@roundup.psfhosted.org>


Change by Ben Caller <bcaller at gmail.com>:


Added file: https://bugs.python.org/file49023/bench_parser2.py

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

From report at bugs.python.org  Wed Apr  1 20:46:16 2020
From: report at bugs.python.org (Ben Caller)
Date: Thu, 02 Apr 2020 00:46:16 +0000
Subject: [issue39503] [security][CVE-2020-8492] Denial of service in
 urllib.request.AbstractBasicAuthHandler
In-Reply-To: <1580397089.41.0.564267118679.issue39503@roundup.psfhosted.org>
Message-ID: <1585788376.97.0.854926078206.issue39503@roundup.psfhosted.org>


Change by Ben Caller <bcaller at gmail.com>:


Removed file: https://bugs.python.org/file49022/bench_parser2.py

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

From report at bugs.python.org  Wed Apr  1 20:51:39 2020
From: report at bugs.python.org (Zackery Spytz)
Date: Thu, 02 Apr 2020 00:51:39 +0000
Subject: [issue40131] Zipapp example has parameters in the wrong order
In-Reply-To: <1585697297.66.0.208168236164.issue40131@roundup.psfhosted.org>
Message-ID: <1585788699.19.0.4885316479.issue40131@roundup.psfhosted.org>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
keywords: +patch
nosy: +ZackerySpytz
nosy_count: 2.0 -> 3.0
pull_requests: +18649
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19290

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

From report at bugs.python.org  Wed Apr  1 20:52:23 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 02 Apr 2020 00:52:23 +0000
Subject: [issue39503] [security][CVE-2020-8492] Denial of service in
 urllib.request.AbstractBasicAuthHandler
In-Reply-To: <1580397089.41.0.564267118679.issue39503@roundup.psfhosted.org>
Message-ID: <1585788743.87.0.267085531308.issue39503@roundup.psfhosted.org>


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


New changeset 0b297d4ff1c0e4480ad33acae793fbaf4bf015b4 by Victor Stinner in branch 'master':
bpo-39503: CVE-2020-8492: Fix AbstractBasicAuthHandler (GH-18284)
https://github.com/python/cpython/commit/0b297d4ff1c0e4480ad33acae793fbaf4bf015b4


----------

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

From report at bugs.python.org  Wed Apr  1 20:52:45 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 02 Apr 2020 00:52:45 +0000
Subject: [issue39503] [security][CVE-2020-8492] Denial of service in
 urllib.request.AbstractBasicAuthHandler
In-Reply-To: <1580397089.41.0.564267118679.issue39503@roundup.psfhosted.org>
Message-ID: <1585788765.76.0.807925420478.issue39503@roundup.psfhosted.org>


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


----------
pull_requests: +18651
pull_request: https://github.com/python/cpython/pull/19292

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

From report at bugs.python.org  Wed Apr  1 20:52:38 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 02 Apr 2020 00:52:38 +0000
Subject: [issue39503] [security][CVE-2020-8492] Denial of service in
 urllib.request.AbstractBasicAuthHandler
In-Reply-To: <1580397089.41.0.564267118679.issue39503@roundup.psfhosted.org>
Message-ID: <1585788758.18.0.399506140629.issue39503@roundup.psfhosted.org>


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


----------
nosy: +miss-islington
nosy_count: 5.0 -> 6.0
pull_requests: +18650
pull_request: https://github.com/python/cpython/pull/19291

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

From report at bugs.python.org  Wed Apr  1 20:52:57 2020
From: report at bugs.python.org (Alexander Riccio)
Date: Thu, 02 Apr 2020 00:52:57 +0000
Subject: [issue40145] Pyshellext room for binary size improvement
In-Reply-To: <1585781037.54.0.0844996141167.issue40145@roundup.psfhosted.org>
Message-ID: <1585788777.68.0.693756196999.issue40145@roundup.psfhosted.org>


Alexander Riccio <test35965 at gmail.com> added the comment:

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

I'll take my 10 cents in the mail please :D

----------

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

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


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


New changeset 224e1c34d677ef42fe665ac008a000d4dcec1398 by Victor Stinner in branch 'master':
bpo-40146: Update OpenSSL to 1.1.1f in Azure Pipelines (GH-19288)
https://github.com/python/cpython/commit/224e1c34d677ef42fe665ac008a000d4dcec1398


----------

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

From report at bugs.python.org  Wed Apr  1 20:55:47 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 02 Apr 2020 00:55:47 +0000
Subject: [issue37207] Use PEP 590 vectorcall to speed up calls to range(),
 list() and dict()
In-Reply-To: <1560072227.25.0.180298594259.issue37207@roundup.psfhosted.org>
Message-ID: <1585788947.5.0.559147828286.issue37207@roundup.psfhosted.org>


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


New changeset e27916b1fc0364e3627438df48550c16f0b80b82 by Dong-hee Na in branch 'master':
bpo-37207: Use PEP 590 vectorcall to speed up dict() (GH-19280)
https://github.com/python/cpython/commit/e27916b1fc0364e3627438df48550c16f0b80b82


----------

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

From report at bugs.python.org  Wed Apr  1 20:56:53 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 02 Apr 2020 00:56:53 +0000
Subject: [issue37207] Use PEP 590 vectorcall to speed up calls to range(),
 list() and dict()
In-Reply-To: <1560072227.25.0.180298594259.issue37207@roundup.psfhosted.org>
Message-ID: <1585789013.01.0.574169453334.issue37207@roundup.psfhosted.org>


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

Can we now close this issue? Or does someone plan to push further optimizations. Maybe new issues can be opened for next optimizations?

----------

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

From report at bugs.python.org  Wed Apr  1 21:02:30 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 02 Apr 2020 01:02:30 +0000
Subject: [issue40144] resource: RLIMIT_xxx and RUSAGE_xxx constants are
 missing on macOS 10.15.4
In-Reply-To: <1585780194.51.0.469585902062.issue40144@roundup.psfhosted.org>
Message-ID: <1585789350.77.0.305804261723.issue40144@roundup.psfhosted.org>


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

I upgraded my macbook to macOS 10.15.4:

$ ./python.exe -m test.pythoninfo|grep -E 'uname|platform'

os.uname: posix.uname_result(sysname='Darwin', nodename='macbook', release='19.4.0', version='Darwin Kernel Version 19.4.0: Wed Mar  4 22:28:40 PST 2020; root:xnu-6153.101.6~15/RELEASE_X86_64', machine='x86_64')

platform.platform: macOS-10.15.4-x86_64-i386-64bit


I get resource attributes:

$ ./python.exe
Python 3.9.0a5+ (heads/master:e27916b, Apr  2 2020, 02:58:34) 
[Clang 11.0.3 (clang-1103.0.32.29)] on darwin
>>> import resource
>>> resource.RLIMIT_CORE
4
>>> resource.RLIMIT_NOFILE
8
>>> resource.RUSAGE_SELF
0


I'm not sure what's wrong with the macOS job. It doesn't seem to use a "framework" build, but:

./configure --with-pydebug --with-openssl=/usr/local/opt/openssl --prefix=/opt/python-dev
make -j4

----------

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

From report at bugs.python.org  Wed Apr  1 21:05:42 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 02 Apr 2020 01:05:42 +0000
Subject: [issue40146] Upgrade Azure Pipelines to OpenSSL 1.1.1f
In-Reply-To: <1585786427.57.0.72048128353.issue40146@roundup.psfhosted.org>
Message-ID: <1585789542.74.0.917779411868.issue40146@roundup.psfhosted.org>


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

Hum, right now 3.7 and 3.8 still work because they use a cache:

"Cache restored from key: Linux-multissl-openssl-1.1.1d"

But I think that the fix should be backported to 3.7 and 3.8 as well.

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

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

From report at bugs.python.org  Wed Apr  1 21:06:08 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 02 Apr 2020 01:06:08 +0000
Subject: [issue40146] Upgrade Azure Pipelines to OpenSSL 1.1.1f
In-Reply-To: <1585786427.57.0.72048128353.issue40146@roundup.psfhosted.org>
Message-ID: <1585789568.63.0.66413477764.issue40146@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Wed Apr  1 21:06:16 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 02 Apr 2020 01:06:16 +0000
Subject: [issue40146] Upgrade Azure Pipelines to OpenSSL 1.1.1f
In-Reply-To: <1585786427.57.0.72048128353.issue40146@roundup.psfhosted.org>
Message-ID: <1585789576.85.0.898223208261.issue40146@roundup.psfhosted.org>


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


----------
pull_requests: +18653
pull_request: https://github.com/python/cpython/pull/19294

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

From report at bugs.python.org  Wed Apr  1 21:08:50 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 02 Apr 2020 01:08:50 +0000
Subject: [issue40125] update OpenSSL 1.1.1 in multissltests.py to 1.1.1f
In-Reply-To: <1585667417.42.0.205219366434.issue40125@roundup.psfhosted.org>
Message-ID: <1585789730.2.0.230498089246.issue40125@roundup.psfhosted.org>


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

See also bpo-40146: the OpenSSL version is also hardcoded in .azure-pipelines/ci.yml and .azure-pipelines/pr.yml. I updated it as well.

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

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

From report at bugs.python.org  Wed Apr  1 21:12:16 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 02 Apr 2020 01:12:16 +0000
Subject: [issue40146] Upgrade Azure Pipelines to OpenSSL 1.1.1f
In-Reply-To: <1585786427.57.0.72048128353.issue40146@roundup.psfhosted.org>
Message-ID: <1585789936.65.0.0687169477555.issue40146@roundup.psfhosted.org>


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

> But I think that the fix should be backported to 3.7 and 3.8 as well.

Alright, it's required. Azure Pipelines now fails on 3.7 as well which prevents me to merge PR 19292 security fix.

----------

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

From report at bugs.python.org  Wed Apr  1 21:23:18 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 02 Apr 2020 01:23:18 +0000
Subject: [issue40146] Upgrade Azure Pipelines to OpenSSL 1.1.1f
In-Reply-To: <1585786427.57.0.72048128353.issue40146@roundup.psfhosted.org>
Message-ID: <1585790598.95.0.976221434807.issue40146@roundup.psfhosted.org>


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


New changeset 8e069fc2ee19f40ce97e61e880bb409ed415d98c by Miss Islington (bot) in branch '3.7':
bpo-40146: Update OpenSSL to 1.1.1f in Azure Pipelines (GH-19288)
https://github.com/python/cpython/commit/8e069fc2ee19f40ce97e61e880bb409ed415d98c


----------

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

From report at bugs.python.org  Wed Apr  1 21:26:16 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 02 Apr 2020 01:26:16 +0000
Subject: [issue40146] Upgrade Azure Pipelines to OpenSSL 1.1.1f
In-Reply-To: <1585786427.57.0.72048128353.issue40146@roundup.psfhosted.org>
Message-ID: <1585790776.13.0.086083354404.issue40146@roundup.psfhosted.org>


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


New changeset 40fff1ff04aa5bc2cf1b965d573b87c48e4da8cc by Miss Islington (bot) in branch '3.8':
bpo-40146: Update OpenSSL to 1.1.1f in Azure Pipelines (GH-19288)
https://github.com/python/cpython/commit/40fff1ff04aa5bc2cf1b965d573b87c48e4da8cc


----------

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

From report at bugs.python.org  Wed Apr  1 21:31:24 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 02 Apr 2020 01:31:24 +0000
Subject: [issue37207] Use PEP 590 vectorcall to speed up calls to range(),
 list() and dict()
In-Reply-To: <1560072227.25.0.180298594259.issue37207@roundup.psfhosted.org>
Message-ID: <1585791084.56.0.0863669632294.issue37207@roundup.psfhosted.org>


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

> When I designed the FASTCALL calling convention, I experimented a new tp_fastcall slot to PyTypeObject to optimize __call__() method: bpo-29259.

Ah, by the way, I also made an attempt to use the FASTCALL calling convention for tp_new and tp_init: bpo-29358. Again, the speedup wasn't obvious and the implementation was quite complicated with many corner cases. So I gave up on this one. It didn't seem to be really worth it.

----------

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

From report at bugs.python.org  Wed Apr  1 21:31:56 2020
From: report at bugs.python.org (Tim Hoffmann)
Date: Thu, 02 Apr 2020 01:31:56 +0000
Subject: [issue40148] Add PurePath.with_stem()
In-Reply-To: <1585788024.89.0.165310869252.issue40148@roundup.psfhosted.org>
Message-ID: <1585791116.68.0.130315820478.issue40148@roundup.psfhosted.org>


Change by Tim Hoffmann <tim.hoffmann at posteo.de>:


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

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

From report at bugs.python.org  Wed Apr  1 21:39:16 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 02 Apr 2020 01:39:16 +0000
Subject: [issue39503] [security][CVE-2020-8492] Denial of service in
 urllib.request.AbstractBasicAuthHandler
In-Reply-To: <1580397089.41.0.564267118679.issue39503@roundup.psfhosted.org>
Message-ID: <1585791556.62.0.43677393774.issue39503@roundup.psfhosted.org>


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


----------
pull_requests: +18655
pull_request: https://github.com/python/cpython/pull/19296

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

From report at bugs.python.org  Wed Apr  1 21:39:24 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 02 Apr 2020 01:39:24 +0000
Subject: [issue39503] [security][CVE-2020-8492] Denial of service in
 urllib.request.AbstractBasicAuthHandler
In-Reply-To: <1580397089.41.0.564267118679.issue39503@roundup.psfhosted.org>
Message-ID: <1585791564.94.0.228349772844.issue39503@roundup.psfhosted.org>


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


----------
pull_requests: +18656
pull_request: https://github.com/python/cpython/pull/19297

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

From report at bugs.python.org  Wed Apr  1 21:39:51 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 02 Apr 2020 01:39:51 +0000
Subject: [issue40146] Upgrade Azure Pipelines to OpenSSL 1.1.1f
In-Reply-To: <1585786427.57.0.72048128353.issue40146@roundup.psfhosted.org>
Message-ID: <1585791591.77.0.913940439567.issue40146@roundup.psfhosted.org>


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

Ok, the issue should now be fixed.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.7, Python 3.8

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

From report at bugs.python.org  Wed Apr  1 21:42:09 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 02 Apr 2020 01:42:09 +0000
Subject: [issue40094] Add os.waitstatus_to_exitcode() function
In-Reply-To: <1585351787.12.0.917977186474.issue40094@roundup.psfhosted.org>
Message-ID: <1585791729.11.0.553381246445.issue40094@roundup.psfhosted.org>


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


New changeset 9a679a0e47d58aa73b7747d4e16140048c10baf5 by Victor Stinner in branch 'master':
bpo-40094: CGIHTTPRequestHandler logs exit code (GH-19285)
https://github.com/python/cpython/commit/9a679a0e47d58aa73b7747d4e16140048c10baf5


----------

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

From report at bugs.python.org  Wed Apr  1 21:42:50 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 02 Apr 2020 01:42:50 +0000
Subject: [issue40094] Add os.waitstatus_to_exitcode() function
In-Reply-To: <1585351787.12.0.917977186474.issue40094@roundup.psfhosted.org>
Message-ID: <1585791770.78.0.623415562852.issue40094@roundup.psfhosted.org>


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


New changeset e7c98f08e228e9f6e139d61e3e5d0a5018a38f0b by Victor Stinner in branch 'master':
bpo-40094: Fix which.py script exit code (GH-19286)
https://github.com/python/cpython/commit/e7c98f08e228e9f6e139d61e3e5d0a5018a38f0b


----------

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

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: [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 21:56:23 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 02 Apr 2020 01:56:23 +0000
Subject: [issue40077] Convert static types to PyType_FromSpec()
In-Reply-To: <1585238684.65.0.246012172449.issue40077@roundup.psfhosted.org>
Message-ID: <1585792583.89.0.249630040072.issue40077@roundup.psfhosted.org>


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

> bpo-40077: Convert _abc module to use PyType_FromSpec() (GH-19202)

This change introduced a reference leak: bpo-40149 "test_threading leaked [38, 38, 38] references, sum=114".

----------

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

From report at bugs.python.org  Wed Apr  1 22:09:45 2020
From: report at bugs.python.org (fireattack)
Date: Thu, 02 Apr 2020 02:09:45 +0000
Subject: [issue36541] Make lib2to3 grammar better match Python,
 support the := walrus
In-Reply-To: <1554514880.92.0.277848417721.issue36541@roundup.psfhosted.org>
Message-ID: <1585793385.52.0.140410837246.issue36541@roundup.psfhosted.org>


Change by fireattack <human.peng at gmail.com>:


----------
nosy: +fireattack

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

From report at bugs.python.org  Wed Apr  1 22:14:43 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 02 Apr 2020 02:14:43 +0000
Subject: [issue40149] test_threading leaked [38, 38, 38] references, sum=114
In-Reply-To: <1585792445.62.0.0518463995906.issue40149@roundup.psfhosted.org>
Message-ID: <1585793683.0.0.771921071974.issue40149@roundup.psfhosted.org>


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

Attached test_leak.py is enough to reproduce the leak. It's related to subinterpreters and the _abc module.

----------
Added file: https://bugs.python.org/file49024/test_leak.py

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

From report at bugs.python.org  Wed Apr  1 22:42:42 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 02 Apr 2020 02:42:42 +0000
Subject: [issue40149] test_threading leaked [38, 38, 38] references, sum=114
In-Reply-To: <1585792445.62.0.0518463995906.issue40149@roundup.psfhosted.org>
Message-ID: <1585795362.17.0.751600893706.issue40149@roundup.psfhosted.org>


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

I'm not sure why, but trigger explicitly a second GC collection fix the issue.

diff --git a/Python/pylifecycle.c b/Python/pylifecycle.c
index 2d5cb0ff78..d20ae01238 100644
--- a/Python/pylifecycle.c
+++ b/Python/pylifecycle.c
@@ -1295,6 +1295,7 @@ finalize_interp_clear(PyThreadState *tstate)
     /* Trigger a GC collection on subinterpreters*/
     if (!is_main_interp) {
         _PyGC_CollectNoFail();
+        _PyGC_CollectNoFail();
     }
 
     finalize_interp_types(tstate, is_main_interp);

----------

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

From report at bugs.python.org  Wed Apr  1 22:45:20 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 02 Apr 2020 02:45:20 +0000
Subject: [issue39837] Remove Azure Pipelines from GitHub PRs
In-Reply-To: <1583255119.77.0.277327127951.issue39837@roundup.psfhosted.org>
Message-ID: <1585795520.71.0.421097786864.issue39837@roundup.psfhosted.org>


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

> About the "Install Dependencies" issue, I created bpo-40146: "Upgrade Azure Pipelines to OpenSSL 1.1.1f".

I fixed this issue.

There is another issue: sometimes, the Ubuntu VM fails to download .deb from azure.archive.ubuntu.com.

Example:
https://github.com/python/cpython/pull/19282/checks?check_run_id=553744077

---
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
---

This error is followed by many similar errors.

----------

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

From report at bugs.python.org  Wed Apr  1 22:46:52 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 02 Apr 2020 02:46:52 +0000
Subject: [issue40115] test_asyncio leaked [3, 3, 3] references, sum=9
In-Reply-To: <1585579110.73.0.577311644063.issue40115@roundup.psfhosted.org>
Message-ID: <1585795612.15.0.453945051409.issue40115@roundup.psfhosted.org>


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


New changeset 8ec7cb53f0705509bac20c96d19fdbd9baec0cb2 by Kyle Stanley in branch 'master':
bpo-40115: Fix refleak in test_asyncio.test_run_in_executor_cancel() (GH-19282)
https://github.com/python/cpython/commit/8ec7cb53f0705509bac20c96d19fdbd9baec0cb2


----------

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

From report at bugs.python.org  Wed Apr  1 22:47:50 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 02 Apr 2020 02:47:50 +0000
Subject: [issue40115] test_asyncio leaked [3, 3, 3] references, sum=9
In-Reply-To: <1585579110.73.0.577311644063.issue40115@roundup.psfhosted.org>
Message-ID: <1585795670.02.0.705931651386.issue40115@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Wed Apr  1 22:48:44 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 02 Apr 2020 02:48:44 +0000
Subject: [issue39812] Avoid daemon threads in concurrent.futures
In-Reply-To: <1583071410.96.0.599538732629.issue39812@roundup.psfhosted.org>
Message-ID: <1585795724.83.0.897373561891.issue39812@roundup.psfhosted.org>


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

Kyle fixed bpo-40115, I close again this issue. Thanks Kyle for the test_asyncio fix!

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

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

From report at bugs.python.org  Wed Apr  1 22:53:50 2020
From: report at bugs.python.org (Kyle Stanley)
Date: Thu, 02 Apr 2020 02:53:50 +0000
Subject: [issue39812] Avoid daemon threads in concurrent.futures
In-Reply-To: <1583071410.96.0.599538732629.issue39812@roundup.psfhosted.org>
Message-ID: <1585796030.16.0.954151560672.issue39812@roundup.psfhosted.org>


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

> Thanks Kyle for the test_asyncio fix!

No problem! Thanks for the review. :-)

----------

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

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: [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:19:21 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Thu, 02 Apr 2020 03:19:21 +0000
Subject: [issue40149] test_threading leaked [38, 38, 38] references, sum=114
In-Reply-To: <1585792445.62.0.0518463995906.issue40149@roundup.psfhosted.org>
Message-ID: <1585797561.09.0.0894048039893.issue40149@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

FYI,
first gc collect 772
secondary gc collect 4

----------

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

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: [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  Wed Apr  1 23:55:50 2020
From: report at bugs.python.org (Alexander Riccio)
Date: Thu, 02 Apr 2020 03:55:50 +0000
Subject: [issue40151] _overlapped room for improvement
In-Reply-To: <1585799208.76.0.700272922922.issue40151@roundup.psfhosted.org>
Message-ID: <1585799750.15.0.333409098732.issue40151@roundup.psfhosted.org>


Change by Alexander Riccio <test35965 at gmail.com>:


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

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

From report at bugs.python.org  Wed Apr  1 23:55:50 2020
From: report at bugs.python.org (Alexander Riccio)
Date: Thu, 02 Apr 2020 03:55:50 +0000
Subject: [issue40145] Pyshellext room for binary size improvement
In-Reply-To: <1585781037.54.0.0844996141167.issue40145@roundup.psfhosted.org>
Message-ID: <1585799750.25.0.333103121105.issue40145@roundup.psfhosted.org>


Change by Alexander Riccio <test35965 at gmail.com>:


----------
pull_requests: +18659
pull_request: https://github.com/python/cpython/pull/19298

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

From report at bugs.python.org  Thu Apr  2 00:17:51 2020
From: report at bugs.python.org (Kyle Stanley)
Date: Thu, 02 Apr 2020 04:17:51 +0000
Subject: [issue40124] Clearer assertion error
In-Reply-To: <1585654498.8.0.880221845215.issue40124@roundup.psfhosted.org>
Message-ID: <1585801071.88.0.597878622316.issue40124@roundup.psfhosted.org>


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

> Do we really want this to be just an assert, or do we want to raise another type of exception?

IMO, we should look into converting this into an exception. Mistakenly having a task await StreamWriter.drain() at the same time as another is calling StreamWriter.write() does seem like a reasonable programming error that should preferably have an informative error message. Optimally, assertions shouldn't occur from normal programming errors in production.

The tricky part is figuring out how to implement it properly. I'm not 100% certain that we can make any guarantees that when the _drain_waiter future hasn't been cancelled and not set to None that someone is mistakenly doing the above. It could potentially trigger from other errors.

Either way though, I think just adding a message to the assert could end up being misleading if someone else encounters this in production for another reason. Instead, I think we could leave a comment there for now and in the long term figure out how to properly implement the exception or warning. We also need a reliable way to reproduce it, mainly for the purpose of writing a new test to ensure the exception is correctly triggered when someone makes the above programming error.

----------
nosy: +aeros

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

From report at bugs.python.org  Thu Apr  2 00:50:31 2020
From: report at bugs.python.org (hai shi)
Date: Thu, 02 Apr 2020 04:50:31 +0000
Subject: [issue40144] resource: RLIMIT_xxx and RUSAGE_xxx constants are
 missing on macOS 10.15.4
In-Reply-To: <1585780194.51.0.469585902062.issue40144@roundup.psfhosted.org>
Message-ID: <1585803031.13.0.672888815603.issue40144@roundup.psfhosted.org>


Change by hai shi <shihai1991 at 126.com>:


----------
nosy: +shihai1991

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

From report at bugs.python.org  Thu Apr  2 01:18:30 2020
From: report at bugs.python.org (Rajesh R Naik)
Date: Thu, 02 Apr 2020 05:18:30 +0000
Subject: [issue40083] No run option available in python idle in version 3.8.2
In-Reply-To: <1585292684.98.0.176532437082.issue40083@roundup.psfhosted.org>
Message-ID: <1585804710.16.0.718252047574.issue40083@roundup.psfhosted.org>


Rajesh R Naik <naikrajesh.naik110 at gmail.com> added the comment:

i thought this issue is with windows home edition 
please confirm and resolve

----------

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

From report at bugs.python.org  Thu Apr  2 01:30:08 2020
From: report at bugs.python.org (Glenn Linderman)
Date: Thu, 02 Apr 2020 05:30:08 +0000
Subject: [issue28029] Replace and empty strings
In-Reply-To: <1473366641.62.0.989746465638.issue28029@psf.upfronthosting.co.za>
Message-ID: <1585805408.93.0.987889827534.issue28029@roundup.psfhosted.org>


Glenn Linderman <v+python at g.nevcal.com> added the comment:

Thanks St?pha?e and Serhiy, I just discovered this strange behavior in 3.8, and wondered how my logic was wrong, until I pinpointed the inconsistent behaviour of str.replace with an empty first parameter and replace count of 1.

Glad to see it is fixed in 3.9.

I guess for   x.replace( a, b, c )  the workaround would be

x.replace( a, b, c ) if a else x.replace( a, b )

At least for recent versions of Python 3.

----------
nosy: +v+python

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

From report at bugs.python.org  Thu Apr  2 01:39:20 2020
From: report at bugs.python.org (Glenn Linderman)
Date: Thu, 02 Apr 2020 05:39:20 +0000
Subject: [issue28029] Replace and empty strings
In-Reply-To: <1473366641.62.0.989746465638.issue28029@psf.upfronthosting.co.za>
Message-ID: <1585805960.92.0.30532942323.issue28029@roundup.psfhosted.org>


Glenn Linderman <v+python at g.nevcal.com> added the comment:

Nope:

I guess for   x.replace( a, b, c )  the workaround would be

x.replace( a, b, c ) if x else x.replace( a, b )

----------

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

From report at bugs.python.org  Thu Apr  2 01:44:21 2020
From: report at bugs.python.org (SilentGhost)
Date: Thu, 02 Apr 2020 05:44:21 +0000
Subject: [issue40148] Add PurePath.with_stem()
In-Reply-To: <1585788024.89.0.165310869252.issue40148@roundup.psfhosted.org>
Message-ID: <1585806261.49.0.0763529404611.issue40148@roundup.psfhosted.org>


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


----------
nosy: +pitrou
type:  -> enhancement
versions: +Python 3.9

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

From report at bugs.python.org  Thu Apr  2 01:46:24 2020
From: report at bugs.python.org (SilentGhost)
Date: Thu, 02 Apr 2020 05:46:24 +0000
Subject: [issue40124] Clearer assertion error
In-Reply-To: <1585654498.8.0.880221845215.issue40124@roundup.psfhosted.org>
Message-ID: <1585806384.81.0.500603175626.issue40124@roundup.psfhosted.org>


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


----------
versions:  -Python 3.5, Python 3.6

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

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: [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 03:09:03 2020
From: report at bugs.python.org (Tapas Kundu)
Date: Thu, 02 Apr 2020 07:09:03 +0000
Subject: [issue39503] [security][CVE-2020-8492] Denial of service in
 urllib.request.AbstractBasicAuthHandler
In-Reply-To: <1580397089.41.0.564267118679.issue39503@roundup.psfhosted.org>
Message-ID: <1585811343.06.0.243337327864.issue39503@roundup.psfhosted.org>


Change by Tapas Kundu <tkundu at vmware.com>:


----------
nosy: +tapakund
nosy_count: 6.0 -> 7.0
pull_requests: +18661
pull_request: https://github.com/python/cpython/pull/19299

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

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


Change by Guilherme Salgado <gsalgado at gmail.com>:


----------
versions: +Python 3.8

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

From report at bugs.python.org  Thu Apr  2 03:22:54 2020
From: report at bugs.python.org (Ned Deily)
Date: Thu, 02 Apr 2020 07:22:54 +0000
Subject: [issue40144] resource: RLIMIT_xxx and RUSAGE_xxx constants are
 missing on macOS 10.15.4
In-Reply-To: <1585780194.51.0.469585902062.issue40144@roundup.psfhosted.org>
Message-ID: <1585812174.64.0.13033616117.issue40144@roundup.psfhosted.org>


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

There's nothing wrong with the Azure CI job, AFAICT.  The issue seems to be in the changes made by the PR itself.  Testing on 10.15.4 from master HEAD, test_resource passes as always.  But after applying the PR under test in the CI, PR 19252 from Issue1635741, the test fails.  It wasn't obvious to me from a quick glance what the problem is but it's late here :)

----------

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

From report at bugs.python.org  Thu Apr  2 04:26:46 2020
From: report at bugs.python.org (Tapas Kundu)
Date: Thu, 02 Apr 2020 08:26:46 +0000
Subject: [issue38576] CVE-2019-18348: CRLF injection via the host part of the
 url passed to urlopen()
In-Reply-To: <1571903478.88.0.753943817426.issue38576@roundup.psfhosted.org>
Message-ID: <1585816006.53.0.012430485795.issue38576@roundup.psfhosted.org>


Change by Tapas Kundu <tkundu at vmware.com>:


----------
pull_requests: +18662
pull_request: https://github.com/python/cpython/pull/19300

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

From report at bugs.python.org  Thu Apr  2 05:02:21 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 02 Apr 2020 09:02:21 +0000
Subject: [issue40083] No run option available in python idle in version 3.8.2
In-Reply-To: <1585292684.98.0.176532437082.issue40083@roundup.psfhosted.org>
Message-ID: <1585818141.18.0.129805213091.issue40083@roundup.psfhosted.org>


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

I cannot do anything until you answer all 6 question.  Perhaps you should post on python-list to get help doing so.

----------

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

From report at bugs.python.org  Thu Apr  2 05:13:52 2020
From: report at bugs.python.org (Tapas Kundu)
Date: Thu, 02 Apr 2020 09:13:52 +0000
Subject: [issue39503] [security][CVE-2020-8492] Denial of service in
 urllib.request.AbstractBasicAuthHandler
In-Reply-To: <1580397089.41.0.564267118679.issue39503@roundup.psfhosted.org>
Message-ID: <1585818832.88.0.21155621166.issue39503@roundup.psfhosted.org>


Change by Tapas Kundu <tkundu at vmware.com>:


----------
pull_requests: +18663
pull_request: https://github.com/python/cpython/pull/19301

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

From report at bugs.python.org  Thu Apr  2 05:17:07 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 02 Apr 2020 09:17:07 +0000
Subject: [issue40144] resource: RLIMIT_xxx and RUSAGE_xxx constants are
 missing on macOS 10.15.4
In-Reply-To: <1585780194.51.0.469585902062.issue40144@roundup.psfhosted.org>
Message-ID: <1585819027.59.0.543465379944.issue40144@roundup.psfhosted.org>


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

> There's nothing wrong with the Azure CI job, AFAICT.  The issue seems to be in the changes made by the PR itself.

The PR modify the resource module. Oh. OOOOH. I see :-D

----------

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

From report at bugs.python.org  Thu Apr  2 05:49:11 2020
From: report at bugs.python.org (hai shi)
Date: Thu, 02 Apr 2020 09:49:11 +0000
Subject: [issue40144] resource: RLIMIT_xxx and RUSAGE_xxx constants are
 missing on macOS 10.15.4
In-Reply-To: <1585780194.51.0.469585902062.issue40144@roundup.psfhosted.org>
Message-ID: <1585820951.01.0.562958519845.issue40144@roundup.psfhosted.org>


hai shi <shihai1991 at 126.com> added the comment:

> The PR modify the resource module. Oh. OOOOH. I see :-D
Do I miss something?

----------

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

From report at bugs.python.org  Thu Apr  2 06:11:11 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 02 Apr 2020 10:11:11 +0000
Subject: [issue40144] resource: RLIMIT_xxx and RUSAGE_xxx constants are
 missing on macOS 10.15.4
In-Reply-To: <1585780194.51.0.469585902062.issue40144@roundup.psfhosted.org>
Message-ID: <1585822271.15.0.0202407518356.issue40144@roundup.psfhosted.org>


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

Ignore this issue, it's a typo in the PR ;-)

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

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

From report at bugs.python.org  Thu Apr  2 06:15:59 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 02 Apr 2020 10:15:59 +0000
Subject: [issue39503] [security][CVE-2020-8492] Denial of service in
 urllib.request.AbstractBasicAuthHandler
In-Reply-To: <1580397089.41.0.564267118679.issue39503@roundup.psfhosted.org>
Message-ID: <1585822559.46.0.401728894181.issue39503@roundup.psfhosted.org>


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


New changeset ea9e240aa02372440be8024acb110371f69c9d41 by Miss Islington (bot) in branch '3.8':
bpo-39503: CVE-2020-8492: Fix AbstractBasicAuthHandler (GH-18284) (GH-19296)
https://github.com/python/cpython/commit/ea9e240aa02372440be8024acb110371f69c9d41


----------

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

From report at bugs.python.org  Thu Apr  2 06:16:20 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 02 Apr 2020 10:16:20 +0000
Subject: [issue39503] [security][CVE-2020-8492] Denial of service in
 urllib.request.AbstractBasicAuthHandler
In-Reply-To: <1580397089.41.0.564267118679.issue39503@roundup.psfhosted.org>
Message-ID: <1585822580.59.0.121457493006.issue39503@roundup.psfhosted.org>


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


New changeset b57a73694e26e8b2391731b5ee0b1be59437388e by Miss Islington (bot) in branch '3.7':
bpo-39503: CVE-2020-8492: Fix AbstractBasicAuthHandler (GH-18284) (GH-19297)
https://github.com/python/cpython/commit/b57a73694e26e8b2391731b5ee0b1be59437388e


----------

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

From report at bugs.python.org  Thu Apr  2 06:27:09 2020
From: report at bugs.python.org (Tapas Kundu)
Date: Thu, 02 Apr 2020 10:27:09 +0000
Subject: [issue39503] [security][CVE-2020-8492] Denial of service in
 urllib.request.AbstractBasicAuthHandler
In-Reply-To: <1580397089.41.0.564267118679.issue39503@roundup.psfhosted.org>
Message-ID: <1585823229.32.0.210285420189.issue39503@roundup.psfhosted.org>


Change by Tapas Kundu <tkundu at vmware.com>:


----------
pull_requests: +18664
pull_request: https://github.com/python/cpython/pull/19302

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

From report at bugs.python.org  Thu Apr  2 06:40:35 2020
From: report at bugs.python.org (Ammar Askar)
Date: Thu, 02 Apr 2020 10:40:35 +0000
Subject: [issue39865] getattr silences an unrelated AttributeError
In-Reply-To: <1583436241.07.0.803311507701.issue39865@roundup.psfhosted.org>
Message-ID: <1585824035.96.0.784559824313.issue39865@roundup.psfhosted.org>


Change by Ammar Askar <ammar at ammaraskar.com>:


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

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

From report at bugs.python.org  Thu Apr  2 06:43:41 2020
From: report at bugs.python.org (Ammar Askar)
Date: Thu, 02 Apr 2020 10:43:41 +0000
Subject: [issue39865] getattr silences an unrelated AttributeError
In-Reply-To: <1583436241.07.0.803311507701.issue39865@roundup.psfhosted.org>
Message-ID: <1585824221.84.0.270339917989.issue39865@roundup.psfhosted.org>


Ammar Askar <ammar at ammaraskar.com> added the comment:

Update: opened up https://github.com/python/cpython/pull/19303 as a quick first pass at implementing this. It works as expected and retains the context from the original exception just in case it's needed. The code isn't too pretty, looks like exception chaining was primarily designed to be a first class citizen using the `raise e2 from e` syntax. A helper in exceptions.c would definitely go a long way to making it more readable.

----------

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

From report at bugs.python.org  Thu Apr  2 07:43:04 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 02 Apr 2020 11:43:04 +0000
Subject: [issue39503] [security][CVE-2020-8492] Denial of service in
 urllib.request.AbstractBasicAuthHandler
In-Reply-To: <1580397089.41.0.564267118679.issue39503@roundup.psfhosted.org>
Message-ID: <1585827784.59.0.869361192773.issue39503@roundup.psfhosted.org>


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


----------
versions:  -Python 2.7

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

From report at bugs.python.org  Thu Apr  2 07:59:15 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 02 Apr 2020 11:59:15 +0000
Subject: [issue39503] [security][CVE-2020-8492] Denial of service in
 urllib.request.AbstractBasicAuthHandler
In-Reply-To: <1580397089.41.0.564267118679.issue39503@roundup.psfhosted.org>
Message-ID: <1585828755.31.0.839158362391.issue39503@roundup.psfhosted.org>


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


----------
pull_requests: +18666
pull_request: https://github.com/python/cpython/pull/19304

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

From report at bugs.python.org  Thu Apr  2 08:05:26 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 02 Apr 2020 12:05:26 +0000
Subject: [issue39503] [security][CVE-2020-8492] Denial of service in
 urllib.request.AbstractBasicAuthHandler
In-Reply-To: <1580397089.41.0.564267118679.issue39503@roundup.psfhosted.org>
Message-ID: <1585829126.38.0.690924035656.issue39503@roundup.psfhosted.org>


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


----------
pull_requests: +18667
pull_request: https://github.com/python/cpython/pull/19305

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

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: [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: [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: [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 08:35:26 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 02 Apr 2020 12:35:26 +0000
Subject: [issue1635741] Py_Finalize() doesn't clear all Python objects at exit
Message-ID: <1585830926.62.0.773844508761.issue1635741@roundup.psfhosted.org>


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


New changeset 45f7008a66a30cdf749ec03e580bd2692be9a8df by Hai Shi in branch 'master':
bpo-1635741: Port resource extension module to multiphase initialization (PEP 489) (GH-19252)
https://github.com/python/cpython/commit/45f7008a66a30cdf749ec03e580bd2692be9a8df


----------

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

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


Michael Felt <aixtools at felt.demon.nl> added the comment:

did not get issue numbers in above: issue31160 and issue40094.

I waited a day, before posting - in the hope it would go away.

Also, I have been testing manually (no -j arguments) - and test_builtin passes when run manually. So, becoming hard to dissect and propose a "cure".

I have started with:

./python  ./Tools/scripts/run_tests.py -j 1 -u all -W --slowest --fail-env-changed --timeout=1200 -j2

and now see the test stalled:

0:39:41 running: test_builtin (5 min 14 sec)
0:40:11 running: test_builtin (5 min 44 sec)
0:40:41 running: test_builtin (6 min 14 sec)
0:41:11 running: test_builtin (6 min 44 sec)
0:41:41 running: test_builtin (7 min 14 sec)
0:42:11 running: test_builtin (7 min 44 sec)
0:42:41 running: test_builtin (8 min 14 sec)
0:43:11 running: test_builtin (8 min 44 sec)

----------

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

From report at bugs.python.org  Thu Apr  2 08:46:28 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 02 Apr 2020 12:46:28 +0000
Subject: [issue40155] AIX: test_builtin.test_input_no_stdout_fileno() hangs
In-Reply-To: <1585830863.71.0.596270299618.issue40155@roundup.psfhosted.org>
Message-ID: <1585831588.14.0.333972212915.issue40155@roundup.psfhosted.org>


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

See also bpo-40140: test_builtin crashes when runned in parallel mode on solaris.

----------
nosy: +vstinner
title: AIX: bot status: stuck at: failed test (failure) uploading test-results.xml (failure) -> AIX: test_builtin.test_input_no_stdout_fileno() hangs

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

From report at bugs.python.org  Thu Apr  2 08:47:03 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 02 Apr 2020 12:47:03 +0000
Subject: [issue40094] Add os.waitstatus_to_exitcode() function
In-Reply-To: <1585351787.12.0.917977186474.issue40094@roundup.psfhosted.org>
Message-ID: <1585831623.54.0.938956948275.issue40094@roundup.psfhosted.org>


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

See also bpo-40155: "AIX: test_builtin.test_input_no_stdout_fileno() hangs".

----------

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

From report at bugs.python.org  Thu Apr  2 08:46:58 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 02 Apr 2020 12:46:58 +0000
Subject: [issue40140] test_builtin crashes when runned in parallel mode on
 solaris
In-Reply-To: <1585769988.66.0.906908269911.issue40140@roundup.psfhosted.org>
Message-ID: <1585831618.48.0.567245153583.issue40140@roundup.psfhosted.org>


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

See also bpo-40155: "AIX: test_builtin.test_input_no_stdout_fileno() hangs".

----------

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

From report at bugs.python.org  Thu Apr  2 09:01:24 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Thu, 02 Apr 2020 13:01:24 +0000
Subject: [issue40155] AIX: test_builtin.test_input_no_stdout_fileno() hangs
In-Reply-To: <1585830863.71.0.596270299618.issue40155@roundup.psfhosted.org>
Message-ID: <1585832484.15.0.00941691842677.issue40155@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Thu Apr  2 09:01:52 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Thu, 02 Apr 2020 13:01:52 +0000
Subject: [issue40140] test_builtin crashes when runned in parallel mode on
 solaris
In-Reply-To: <1585769988.66.0.906908269911.issue40140@roundup.psfhosted.org>
Message-ID: <1585832512.91.0.236630185216.issue40140@roundup.psfhosted.org>


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

The ulimit results with infinity and this happens on the current master.

----------

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

From report at bugs.python.org  Thu Apr  2 09:02:35 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Thu, 02 Apr 2020 13:02:35 +0000
Subject: [issue40140] test_builtin crashes when runned in parallel mode on
 solaris
In-Reply-To: <1585769988.66.0.906908269911.issue40140@roundup.psfhosted.org>
Message-ID: <1585832555.86.0.389923456755.issue40140@roundup.psfhosted.org>


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

> I am understanding "crashing" as "segfaulting"

"crashing" as in the test result but not segfaulting
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)

----------

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

From report at bugs.python.org  Thu Apr  2 09:04:30 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Thu, 02 Apr 2020 13:04:30 +0000
Subject: [issue40094] Add os.waitstatus_to_exitcode() function
In-Reply-To: <1585351787.12.0.917977186474.issue40094@roundup.psfhosted.org>
Message-ID: <1585832670.94.0.949404209348.issue40094@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Thu Apr  2 09:07:34 2020
From: report at bugs.python.org (Ankesh Saha)
Date: Thu, 02 Apr 2020 13:07:34 +0000
Subject: [issue28859] os.path.ismount sometimes raises FileNotFoundError on
 Windows
In-Reply-To: <1480689560.28.0.129916928722.issue28859@psf.upfronthosting.co.za>
Message-ID: <1585832854.88.0.719398761292.issue28859@roundup.psfhosted.org>


Ankesh Saha <ankesh.1987 at gmail.com> added the comment:

s I have tried to workout a solution for the problem. Below is my observation and possible solution.

os.path.ismount("F:\\doesnotexist")

Exception occurs for the above line if the system fails to find both drive and the path that follows it.

A 'FileNotFoundError' exception is thrown. If we can handle this exception and return false for method ismount(), then problem can be resolved.

I changed the existing code ismount method and it is working.
Existing code=>
    if _getvolumepathname:
        return path.rstrip(seps) == _getvolumepathname(path).rstrip(seps)
    else:
        return False

Changed Code=>
    if _getvolumepathname:
        try:
            return path.rstrip(seps) == _getvolumepathname(path).rstrip(seps)
        except FileNotFoundError:
            return False

Please check, if this solution is correct.

----------
nosy: +ankeshsaha

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

From report at bugs.python.org  Thu Apr  2 09:13:54 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 02 Apr 2020 13:13:54 +0000
Subject: [issue40140] test_builtin crashes when runned in parallel mode on
 solaris
In-Reply-To: <1585769988.66.0.906908269911.issue40140@roundup.psfhosted.org>
Message-ID: <1585833234.54.0.913783829991.issue40140@roundup.psfhosted.org>


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

> "crashing" as in the test result but not segfaulting
> 0:00:01 load avg: 1.70 [1/1/1] test_builtin crashed (Exit code -1)

What is the signal 1 on Solaris? On Linux, it's SIGHUP, not SIGSEGV:

$ python3
Python 3.7.6 (default, Jan 30 2020, 09:44:41) 
>>> import signal
>>> signal.SIGSEGV
<Signals.SIGSEGV: 11>
>>> signal.SIGHUP
<Signals.SIGHUP: 1>

----------

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

From report at bugs.python.org  Thu Apr  2 09:34:31 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Thu, 02 Apr 2020 13:34:31 +0000
Subject: [issue40140] test_builtin crashes when runned in parallel mode on
 solaris
In-Reply-To: <1585769988.66.0.906908269911.issue40140@roundup.psfhosted.org>
Message-ID: <1585834471.32.0.463297093235.issue40140@roundup.psfhosted.org>


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

isidentical at gcc-solaris11:~$ cpython/python
Python 3.9.0a5+ (heads/master:98ff332, Apr  2 2020, 01:20:22) 
[GCC 5.5.0] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
>>> import signal
>>> signal.SIGSEGV
<Signals.SIGSEGV: 11>
>>> signal.SIGHUP
<Signals.SIGHUP: 1>

----------

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

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: [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:36:31 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 02 Apr 2020 13:36:31 +0000
Subject: [issue40156] codecov/patch stills runs on 3.5 and 3.6 branches
In-Reply-To: <1585834501.29.0.235392349062.issue40156@roundup.psfhosted.org>
Message-ID: <1585834591.38.0.177124421956.issue40156@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Thu Apr  2 09:37:48 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 02 Apr 2020 13:37:48 +0000
Subject: [issue39704] Disable code coverage
In-Reply-To: <1582241922.94.0.0257768022577.issue39704@roundup.psfhosted.org>
Message-ID: <1585834668.59.0.407932262749.issue39704@roundup.psfhosted.org>


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

FYI I created bpo-40156: "codecov/patch stills runs on 3.5 and 3.6 branches".

----------

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

From report at bugs.python.org  Thu Apr  2 09:38:20 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 02 Apr 2020 13:38:20 +0000
Subject: [issue40156] CodeCov/patch job stills runs on pull requests on 3.5
 and 3.6 branches
In-Reply-To: <1585834501.29.0.235392349062.issue40156@roundup.psfhosted.org>
Message-ID: <1585834700.28.0.929790672279.issue40156@roundup.psfhosted.org>


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


----------
title: codecov/patch stills runs on 3.5 and 3.6 branches -> CodeCov/patch job stills runs on pull requests on 3.5 and 3.6 branches

_______________________________________
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: [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 10:13:16 2020
From: report at bugs.python.org (Michael Felt)
Date: Thu, 02 Apr 2020 14:13:16 +0000
Subject: [issue40155] AIX: test_builtin.test_input_no_stdout_fileno() hangs
In-Reply-To: <1585830863.71.0.596270299618.issue40155@roundup.psfhosted.org>
Message-ID: <1585836796.91.0.608779787232.issue40155@roundup.psfhosted.org>


Michael Felt <aixtools at felt.demon.nl> added the comment:

Now consistently - stalled.

aixtools at x064:[/home/aixtools/py39-3.9]git diff
diff --git a/Lib/test/test_builtin.py b/Lib/test/test_builtin.py
index eaada1b504..89c4ebc2bd 100644
--- a/Lib/test/test_builtin.py
+++ b/Lib/test/test_builtin.py
@@ -1849,26 +1849,40 @@ class PtyTests(unittest.TestCase):

         if pid == 0:
             # Child
+            pid = os.getpid() # get my PID
+            tty = open("/dev/pts/3", "a")
+            tty.write("\nI am child - this is my PID:{}".format(pid))
+            tty.close()
             try:
                 # Make sure we don't get stuck if there's a problem
-                signal.alarm(2)
+                # signal.alarm(2)
                 os.close(r)
                 with open(w, "w") as wpipe:
                     child(wpipe)
             except:
                 traceback.print_exc()
             finally:
+                tty = open("/dev/pts/3", "a")
+                tty.write("\nI am child - exiting PID:{}".format(pid))
+                tty.close()
                 # We don't want to return to unittest...
                 os._exit(0)

         # Parent
         os.close(w)
+        tty = open("/dev/pts/3", "a")
+        tty.write("\nI am parent:{} with child:{}".format(os.getpid(), pid))
+        tty.write("fd:{} input:{}".format(fd, terminal_input))
+        tty.close()
         os.write(fd, terminal_input)

         # Get results from the pipe
         with open(r, "r") as rpipe:
             lines = []
             while True:
+                tty = open("/dev/pts/3", "a")
+                tty.write("\nI am parent:{} with lines:{}".format(os.getpid(), lines))
+                tty.close()
                 line = rpipe.readline().strip()
                 if line == "":
                     # The other end was closed => the child exited
@@ -1895,6 +1909,9 @@ class PtyTests(unittest.TestCase):

         # Wait until the child process completes before closing the PTY to
         # prevent sending SIGHUP to the child process.
+        tty = open("/dev/pts/3", "a")
+        tty.write("\nI am parent:{} starting wait_process({}, exitcode=0)".format(os.getpid(), pid))
+        tty.close()
         support.wait_process(pid, exitcode=0)

         # Close the PTY

======== Debug ========
aixtools at x064:[/home/aixtools/py39-3.9]./python -m test test_builtin
0:00:00 Run tests sequentially
0:00:00 [1/1] test_builtin

I am child - this is my PID:22544440
I am parent:21954660 with child:22544440fd:6 input:b'quux\r'
I am parent:21954660 with lines:[]
I am child - exiting PID:22544440
I am parent:21954660 with lines:['stdin.isatty(): True']
I am parent:21954660 with lines:['stdin.isatty(): True', "captured: 'prompt'"]
I am parent:21954660 starting wait_process(22544440, exitcode=0)

----------

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

From report at bugs.python.org  Thu Apr  2 10:20:27 2020
From: report at bugs.python.org (Michael Felt)
Date: Thu, 02 Apr 2020 14:20:27 +0000
Subject: [issue40155] AIX: test_builtin.test_input_no_stdout_fileno() hangs
In-Reply-To: <1585830863.71.0.596270299618.issue40155@roundup.psfhosted.org>
Message-ID: <1585837227.16.0.492141578305.issue40155@roundup.psfhosted.org>


Michael Felt <aixtools at felt.demon.nl> added the comment:

If I move the close to before the support.waitprocess() call I get:

aixtools at x064:[/home/aixtools/py39-3.9]./python -m test test_builtin
0:00:00 Run tests sequentially
0:00:00 [1/1] test_builtin

I am child - this is my PID:22544444
I am parent:21954666 with child:22544444fd:6 input:b'quux\r'
I am parent:21954666 with lines:[]
I am child - exiting PID:22544444
I am parent:21954666 with lines:['stdin.isatty(): True']
I am parent:21954666 with lines:['stdin.isatty(): True', "captured: 'prompt'"]
I am parent:21954666 starting wait_process(22544444, exitcode=0)
I am parent:21954666 with child:22544446fd:6 input:b'quux\r\n'
I am parent:21954666 with lines:[]
I am child - this is my PID:22544446
I am child - exiting PID:22544446
I am parent:21954666 with lines:['tty = True']
I am parent:21954666 with lines:['tty = True', "'quux'"]
I am parent:21954666 starting wait_process(22544446, exitcode=0)
I am parent:21954666 with child:22544448fd:6 input:b'quux\xe9\r\n'
I am parent:21954666 with lines:[]
I am child - this is my PID:22544448
I am child - exiting PID:22544448
I am parent:21954666 with lines:['tty = True']
I am parent:21954666 with lines:['tty = True', "'quux\\udce9'"]
I am parent:21954666 starting wait_process(22544448, exitcode=0)
I am parent:21954666 with child:22544450fd:6 input:b'quux\xe9\r\n'
I am parent:21954666 with lines:[]
I am child - this is my PID:22544450
I am child - exiting PID:22544450
I am parent:21954666 with lines:['tty = True']
I am parent:21954666 with lines:['tty = True', "'quux\\udce9'"]
I am parent:21954666 starting wait_process(22544450, exitcode=0)
== Tests result: SUCCESS ==

1 test OK.

----------

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

From report at bugs.python.org  Thu Apr  2 10:30:28 2020
From: report at bugs.python.org (Michael Felt)
Date: Thu, 02 Apr 2020 14:30:28 +0000
Subject: [issue40155] AIX: test_builtin.test_input_no_stdout_fileno() hangs
In-Reply-To: <1585830863.71.0.596270299618.issue40155@roundup.psfhosted.org>
Message-ID: <1585837828.07.0.619104470134.issue40155@roundup.psfhosted.org>


Michael Felt <aixtools at felt.demon.nl> added the comment:

I tried moving the child/parent logic blocks and get this as debug output:

aixtools at x064:[/home/aixtools/py39-3.9]./python -m test test_builtin
0:00:00 Run tests sequentially
0:00:00 [1/1] test_builtin

I am child - this is my PID:8519822
I am parent:6422696 with child:8519822fd:6 input:b'quux\r'
I am child - exiting PID:8519822
I am parent:6422696 with lines:[]
I am parent:6422696 with lines:['stdin.isatty(): True']
I am parent:6422696 with lines:['stdin.isatty(): True', "captured: 'prompt'"]
I am parent:6422696 starting wait_process(8519822, exitcode=0)

+++++++
Diff as attachment...

----------
Added file: https://bugs.python.org/file49027/test_builtin.txt

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

From report at bugs.python.org  Thu Apr  2 10:35:30 2020
From: report at bugs.python.org (Michael Felt)
Date: Thu, 02 Apr 2020 14:35:30 +0000
Subject: [issue40155] AIX: test_builtin.test_input_no_stdout_fileno() hangs
In-Reply-To: <1585830863.71.0.596270299618.issue40155@roundup.psfhosted.org>
Message-ID: <1585838130.21.0.755353787072.issue40155@roundup.psfhosted.org>


Michael Felt <aixtools at felt.demon.nl> added the comment:

Next debug info:

I am child - this is my PID:8519830
I am parent:18284612 with child:8519830fd:6 input:b'quux\r'
I am parent:18284612 with lines:[]
I am child - exiting PID:8519830
I am parent:18284612 with lines:['stdin.isatty(): True']
I am parent:18284612 with lines:['stdin.isatty(): True', "captured: 'prompt'"]
I am parent:18284612 starting wait_process(8519830, exitcode=0)[2] + Stopped (SIGTSTP)        ./python -m test test_builtin
aixtools at x064:[/home/aixtools/py39-3.9]ps -p 8519830
      PID    TTY  TIME CMD
  8519830            - <exiting>
aixtools at x064:[/home/aixtools/py39-3.9]kill 8519830
aixtools at x064:[/home/aixtools/py39-3.9]ps -p 8519830
      PID    TTY  TIME CMD
  8519830            - <exiting>
aixtools at x064:[/home/aixtools/py39-3.9]kill -9 8519830
aixtools at x064:[/home/aixtools/py39-3.9]ps -p 8519830
      PID    TTY  TIME CMD
  8519830            - <exiting>
aixtools at x064:[/home/aixtools/py39-3.9]fg
./python -m test test_builtin
[2] + Stopped (SIGTSTP)        ./python -m test test_builtin
aixtools at x064:[/home/aixtools/py39-3.9]ps -p 8519830
      PID    TTY  TIME CMD
  8519830            - <exiting>

----------

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

From report at bugs.python.org  Thu Apr  2 10:37:53 2020
From: report at bugs.python.org (Michael Felt)
Date: Thu, 02 Apr 2020 14:37:53 +0000
Subject: [issue40155] AIX: test_builtin.test_input_no_stdout_fileno() hangs
In-Reply-To: <1585830863.71.0.596270299618.issue40155@roundup.psfhosted.org>
Message-ID: <1585838273.79.0.867968550897.issue40155@roundup.psfhosted.org>


Michael Felt <aixtools at felt.demon.nl> added the comment:

FYI: in child block:

calling os.exit(0), rather than os._exit() gives same result.

----------

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

From report at bugs.python.org  Thu Apr  2 11:30:23 2020
From: report at bugs.python.org (hai shi)
Date: Thu, 02 Apr 2020 15:30:23 +0000
Subject: [issue1635741] Py_Finalize() doesn't clear all Python objects at exit
Message-ID: <1585841423.12.0.566142997355.issue1635741@roundup.psfhosted.org>


Change by hai shi <shihai1991 at 126.com>:


----------
pull_requests: +18669
pull_request: https://github.com/python/cpython/pull/19307

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

From report at bugs.python.org  Thu Apr  2 11:30:27 2020
From: report at bugs.python.org (Michael Felt)
Date: Thu, 02 Apr 2020 15:30:27 +0000
Subject: [issue40155] AIX: test_builtin.test_input_no_stdout_fileno() hangs
In-Reply-To: <1585830863.71.0.596270299618.issue40155@roundup.psfhosted.org>
Message-ID: <1585841427.03.0.683102400381.issue40155@roundup.psfhosted.org>


Michael Felt <aixtools at felt.demon.nl> added the comment:

To get it to move forward: as it is not solely and AIX thing (see bpo-40-140) 

This works: but is it what is wanted?

Tests result: SUCCESS
aixtools at x064:[/home/aixtools/py39-3.9]git diff
diff --git a/Lib/test/test_builtin.py b/Lib/test/test_builtin.py
index eaada1b504..4a5addc6fe 100644
--- a/Lib/test/test_builtin.py
+++ b/Lib/test/test_builtin.py
@@ -1893,12 +1893,18 @@ class PtyTests(unittest.TestCase):
             self.fail("got %d lines in pipe but expected 2, child output was:\n%s"
                       % (len(lines), child_output))

-        # Wait until the child process completes before closing the PTY to
-        # prevent sending SIGHUP to the child process.
-        support.wait_process(pid, exitcode=0)
+        if sys.platform == "linux" or not os.name == "posix":
+            # Wait until the child process completes before closing the PTY to
+            # prevent sending SIGHUP to the child process.
+            support.wait_process(pid, exitcode=0)

-        # Close the PTY
-        os.close(fd)
+            # Close the PTY
+            os.close(fd)
+        else:
+            # Other posix need to close the pty for the child to exit normally
+            # Close the PTY
+            os.close(fd)
+            support.wait_process(pid, exitcode=0)

----------
type:  -> behavior

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

From report at bugs.python.org  Thu Apr  2 12:31:31 2020
From: report at bugs.python.org (Steve Dower)
Date: Thu, 02 Apr 2020 16:31:31 +0000
Subject: [issue40145] Pyshellext room for binary size improvement
In-Reply-To: <1585781037.54.0.0844996141167.issue40145@roundup.psfhosted.org>
Message-ID: <1585845091.98.0.888336017401.issue40145@roundup.psfhosted.org>


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

I'm seeing some numbers that suggest it's even bigger than 7 million, so you might be deserving of more! Of course, that bandwidth is a donation, so you'll have to apply to Fastly ;)

Our MSBuild projects are hand-maintained (often by people on non-Windows systems). Could you tidy the XML to minimize the "Condition" attributes? And as much as is reasonable, move defaults into pyproject.props and per-project overrides in the specific projects?

----------

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

From report at bugs.python.org  Thu Apr  2 12:34:00 2020
From: report at bugs.python.org (Steve Dower)
Date: Thu, 02 Apr 2020 16:34:00 +0000
Subject: [issue39837] Remove Azure Pipelines from GitHub PRs
In-Reply-To: <1583255119.77.0.277327127951.issue39837@roundup.psfhosted.org>
Message-ID: <1585845240.87.0.613556441795.issue39837@roundup.psfhosted.org>


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

> I don't understand how it's possible that the Ubuntu job passed in the GitHub action, but failed in Azure Pipelines.

Random network issues, most likely. Those are about the only flakiness I've seen in recent times.

The OpenSSL cache should only be for the from-source build we do on Ubuntu for CI. It uses the multissl script in our repo and downloads directly from openssl.org. The dependencies obtained using apt are not cached by us.

----------

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

From report at bugs.python.org  Thu Apr  2 12:39:03 2020
From: report at bugs.python.org (Steve Dower)
Date: Thu, 02 Apr 2020 16:39:03 +0000
Subject: [issue40151] _overlapped room for improvement
In-Reply-To: <1585799208.76.0.700272922922.issue40151@roundup.psfhosted.org>
Message-ID: <1585845543.19.0.0103799488979.issue40151@roundup.psfhosted.org>


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

While you're working on these, the most important comparison to make is against the binaries from our 64-bit release. We've run PGO on those, and from the stats shown it optimises almost everything for size already. (You can enable the same profile by running "build.bat --pgo".)

For debug builds, I would prefer to optimise for (re)compile time. We can accept larger binaries in that case.

----------

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

From report at bugs.python.org  Thu Apr  2 13:29:55 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 02 Apr 2020 17:29:55 +0000
Subject: [issue40156] CodeCov/patch job stills runs on pull requests on 3.5
 and 3.6 branches
In-Reply-To: <1585834501.29.0.235392349062.issue40156@roundup.psfhosted.org>
Message-ID: <1585848595.59.0.685843821427.issue40156@roundup.psfhosted.org>


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

Here is my concrete solution for CodeCov issues on 3.5 and 3.6 branches.

----------
nosy: +larry, ned.deily

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

From report at bugs.python.org  Thu Apr  2 13:33:10 2020
From: report at bugs.python.org (Larry Hastings)
Date: Thu, 02 Apr 2020 17:33:10 +0000
Subject: [issue40156] CodeCov/patch job stills runs on pull requests on 3.5
 and 3.6 branches
In-Reply-To: <1585834501.29.0.235392349062.issue40156@roundup.psfhosted.org>
Message-ID: <1585848790.85.0.79015367424.issue40156@roundup.psfhosted.org>


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

I need to do a little more reading on it, but I expect if you make an equivalent PR for 3.5 I'll merge it.  Thanks for taking this on, Victor!

----------

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

From report at bugs.python.org  Thu Apr  2 13:43:42 2020
From: report at bugs.python.org (Michael Felt)
Date: Thu, 02 Apr 2020 17:43:42 +0000
Subject: [issue31160] Enhance support.reap_children()
In-Reply-To: <1502283003.36.0.514915057261.issue31160@psf.upfronthosting.co.za>
Message-ID: <1585849422.97.0.0493987193551.issue31160@roundup.psfhosted.org>


Change by Michael Felt <aixtools at felt.demon.nl>:


----------
pull_requests: +18670
pull_request: https://github.com/python/cpython/pull/19308

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

From report at bugs.python.org  Thu Apr  2 13:44:14 2020
From: report at bugs.python.org (Michael Felt)
Date: Thu, 02 Apr 2020 17:44:14 +0000
Subject: [issue40155] AIX: test_builtin.test_input_no_stdout_fileno() hangs
In-Reply-To: <1585830863.71.0.596270299618.issue40155@roundup.psfhosted.org>
Message-ID: <1585849454.76.0.358720606302.issue40155@roundup.psfhosted.org>


Change by Michael Felt <aixtools at felt.demon.nl>:


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

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

From report at bugs.python.org  Thu Apr  2 13:46:11 2020
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 02 Apr 2020 17:46:11 +0000
Subject: [issue40148] Add PurePath.with_stem()
In-Reply-To: <1585788024.89.0.165310869252.issue40148@roundup.psfhosted.org>
Message-ID: <1585849571.77.0.112359920223.issue40148@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

I personally would rather not add more methods that are doing simple string manipulations.

----------
nosy: +brett.cannon

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

From report at bugs.python.org  Thu Apr  2 13:49:27 2020
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 02 Apr 2020 17:49:27 +0000
Subject: [issue39837] Remove Azure Pipelines from GitHub PRs
In-Reply-To: <1583255119.77.0.277327127951.issue39837@roundup.psfhosted.org>
Message-ID: <1585849767.62.0.360403081851.issue39837@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

> I'm not aware of Travis CI current issue. There were issues in the past, as with any CI, right ;-) Travis CI looks quite reliable these days.

That's what everyone said when Travis was required and before it went flaky the last time. ;)

The point is I don't want to keep flipping on and off required checks based on whatever CI people deem flaky or not at any one time.

----------

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

From report at bugs.python.org  Thu Apr  2 13:53:08 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 02 Apr 2020 17:53:08 +0000
Subject: [issue39704] Disable code coverage
In-Reply-To: <1582241922.94.0.0257768022577.issue39704@roundup.psfhosted.org>
Message-ID: <1585849988.77.0.84451059375.issue39704@roundup.psfhosted.org>


Change by Guido van Rossum <guido at python.org>:


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

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

From report at bugs.python.org  Thu Apr  2 13:55:10 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 02 Apr 2020 17:55:10 +0000
Subject: [issue40156] CodeCov/patch job stills runs on pull requests on 3.5
 and 3.6 branches
In-Reply-To: <1585834501.29.0.235392349062.issue40156@roundup.psfhosted.org>
Message-ID: <1585850110.43.0.761346953909.issue40156@roundup.psfhosted.org>


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


----------
pull_requests: +18672
pull_request: https://github.com/python/cpython/pull/19309

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

From report at bugs.python.org  Thu Apr  2 14:00:56 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 02 Apr 2020 18:00:56 +0000
Subject: [issue1635741] Py_Finalize() doesn't clear all Python objects at exit
Message-ID: <1585850456.16.0.732700193798.issue1635741@roundup.psfhosted.org>


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


New changeset 7a6f3bcc43ed729f8038524528c0b326b5610506 by Hai Shi in branch 'master':
bpo-1635741: Fix refleak in _locale init error handling (GH-19307)
https://github.com/python/cpython/commit/7a6f3bcc43ed729f8038524528c0b326b5610506


----------

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

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: [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 14:02:03 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 02 Apr 2020 18:02:03 +0000
Subject: [issue40156] CodeCov/patch job stills runs on pull requests on 3.5
 and 3.6 branches
In-Reply-To: <1585834501.29.0.235392349062.issue40156@roundup.psfhosted.org>
Message-ID: <1585850523.67.0.524056010105.issue40156@roundup.psfhosted.org>


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

> I need to do a little more reading on it, but I expect if you make an equivalent PR for 3.5 I'll merge it.  Thanks for taking this on, Victor!

Done with PR 19309.

----------

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

From report at bugs.python.org  Thu Apr  2 14:16:31 2020
From: report at bugs.python.org (Steve Dower)
Date: Thu, 02 Apr 2020 18:16:31 +0000
Subject: [issue40158] MSBuild Extensions in CPython NuGet Package has Bad
 Expression
In-Reply-To: <1585850431.84.0.195210252651.issue40158@roundup.psfhosted.org>
Message-ID: <1585851391.97.0.78499196871.issue40158@roundup.psfhosted.org>


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

The closing parentheses are needed - a PR would be appreciated for that.

The quotes around a variable reference are unnecessary. At a parser level, it just changes it from a variable reference to a string literal with substitutions (unlike most shells, which do a textual substitution before parsing).

----------

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

From report at bugs.python.org  Thu Apr  2 14:48:59 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 02 Apr 2020 18:48:59 +0000
Subject: [issue17005] Add a topological sort algorithm
In-Reply-To: <1358717952.33.0.209682941713.issue17005@psf.upfronthosting.co.za>
Message-ID: <1585853339.53.0.0269448119345.issue17005@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

At some point in the next two or three weeks, I'll have a chance to work on this more and to offer a competing patch.  IMO, the current checkin is over-engineered, both in its API and implementation.  This could have been a simple, fast tool written as one or two short Python functions.

Also, I would like to try to out the API alternatives on some groups of engineers to get some user feedback.

For me, as the API currently stands, I would have to write a wrapper to make it usable for my applications.

----------

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

From report at bugs.python.org  Thu Apr  2 14:51:29 2020
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 02 Apr 2020 18:51:29 +0000
Subject: [issue40133] Provide additional matchers for unittest.mock
In-Reply-To: <1585735205.76.0.306632606173.issue40133@roundup.psfhosted.org>
Message-ID: <1585853489.85.0.605866883178.issue40133@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch
nosy: +python-dev
nosy_count: 2.0 -> 3.0
pull_requests: +18673
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19310

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

From report at bugs.python.org  Thu Apr  2 14:58:48 2020
From: report at bugs.python.org (Christophe Nanteuil)
Date: Thu, 02 Apr 2020 18:58:48 +0000
Subject: [issue40127] Documentation of SSL library
In-Reply-To: <1585672825.27.0.231879770193.issue40127@roundup.psfhosted.org>
Message-ID: <1585853928.68.0.267356319824.issue40127@roundup.psfhosted.org>


Christophe Nanteuil <christophe.nanteuil at gmail.com> added the comment:

I modified the PR according to the source code: 
"if all three are None and SSLContext.verify_mode is not set to CERT_NONE, this function uses the system's default CA certificates."

The way the system is configured may depend on multiple parameters but I hope this statement is clearer and it disturbs me to read that the function "can choose", all the more for a security module.

----------

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

From report at bugs.python.org  Thu Apr  2 15:00:27 2020
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 02 Apr 2020 19:00:27 +0000
Subject: [issue38972] [venv] Link to instructions to change PowerShell
 execution policy for venv activation
In-Reply-To: <1575483846.28.0.24893284684.issue38972@roundup.psfhosted.org>
Message-ID: <1585854027.64.0.733366617418.issue38972@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:


New changeset 45217af29c7f380089af17beb48a5ea0560bbb9d by Derek Keeler in branch 'master':
bpo-38972: Link to instructions to change PowerShell execution policy (GH-19131)
https://github.com/python/cpython/commit/45217af29c7f380089af17beb48a5ea0560bbb9d


----------

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

From report at bugs.python.org  Thu Apr  2 15:00:45 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 02 Apr 2020 19:00:45 +0000
Subject: [issue38972] [venv] Link to instructions to change PowerShell
 execution policy for venv activation
In-Reply-To: <1575483846.28.0.24893284684.issue38972@roundup.psfhosted.org>
Message-ID: <1585854045.72.0.134129921285.issue38972@roundup.psfhosted.org>


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


----------
nosy: +miss-islington
nosy_count: 6.0 -> 7.0
pull_requests: +18674
pull_request: https://github.com/python/cpython/pull/19311

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

From report at bugs.python.org  Thu Apr  2 15:01:45 2020
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 02 Apr 2020 19:01:45 +0000
Subject: [issue38972] [venv] Link to instructions to change PowerShell
 execution policy for venv activation
In-Reply-To: <1575483846.28.0.24893284684.issue38972@roundup.psfhosted.org>
Message-ID: <1585854105.76.0.672397420297.issue38972@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


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

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

From report at bugs.python.org  Thu Apr  2 15:02:23 2020
From: report at bugs.python.org (=?utf-8?q?Diego_Elio_Petten=C3=B2?=)
Date: Thu, 02 Apr 2020 19:02:23 +0000
Subject: [issue40133] Provide additional matchers for unittest.mock
In-Reply-To: <1585735205.76.0.306632606173.issue40133@roundup.psfhosted.org>
Message-ID: <1585854143.29.0.925486311398.issue40133@roundup.psfhosted.org>


Change by Diego Elio Petten? <flameeyes at flameeyes.com>:


----------
nosy: +gregory.p.smith

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

From report at bugs.python.org  Thu Apr  2 15:19:46 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 02 Apr 2020 19:19:46 +0000
Subject: [issue38972] [venv] Link to instructions to change PowerShell
 execution policy for venv activation
In-Reply-To: <1575483846.28.0.24893284684.issue38972@roundup.psfhosted.org>
Message-ID: <1585855186.17.0.959764592734.issue38972@roundup.psfhosted.org>


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


New changeset b7345c24a4d962e2adbafc86e4af77de9e3ef09e by Miss Islington (bot) in branch '3.8':
bpo-38972: Link to instructions to change PowerShell execution policy (GH-19131)
https://github.com/python/cpython/commit/b7345c24a4d962e2adbafc86e4af77de9e3ef09e


----------

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

From report at bugs.python.org  Thu Apr  2 15:32:56 2020
From: report at bugs.python.org (Tim Peters)
Date: Thu, 02 Apr 2020 19:32:56 +0000
Subject: [issue17005] Add a topological sort algorithm
In-Reply-To: <1358717952.33.0.209682941713.issue17005@psf.upfronthosting.co.za>
Message-ID: <1585855976.15.0.459138434166.issue17005@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

Raymond, what application do you have that wouldn't be completely addressed by sticking to just .add() (to record dependencies) and .static_order() (to retrieve a linear order)?

Larry Hastings and I originally worked out the fancier bits of the interface to deal with problems he actually had, and for which no existing Python topsort implementation we could find was of any use:  extract maximal parallelism.  If you don't want that, fine, stick to the two simple bits.

The bits to support parallelism are very easy to use to write correct parallelized code, but of course can seem baffling if you don't give a rip about parallelism.  But in that case you have no need to learn about them either.

If your alternative isn't equally easy to use in a parallelized context, I'll be at best +0.

About "fast", this is linear time, in the sum of the number of items and dependencies.  Including the part checking for a cycle, which is by far the "hardest" part.  So it's asymptotically optimal, although I've never seen a real context in which topsort speed made a lick of difference.

In the real world, in a parallelized context it can be important to check for a cycle _before_ running a topsort:  actions are performed ASAP based on order-deduced-so-far, and it can be no good to find out "oh! I can't finish this" at the end.  There's actually nothing gratuitous here.  If it seems "over-engineered", that's because it's addressing problems you haven't had yet ;-)

----------

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

From report at bugs.python.org  Thu Apr  2 16:08:02 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 02 Apr 2020 20:08:02 +0000
Subject: [issue31160] Enhance support.reap_children()
In-Reply-To: <1502283003.36.0.514915057261.issue31160@psf.upfronthosting.co.za>
Message-ID: <1585858082.9.0.281704302585.issue31160@roundup.psfhosted.org>


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


----------
pull_requests: +18675
pull_request: https://github.com/python/cpython/pull/19312

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

From report at bugs.python.org  Thu Apr  2 16:08:03 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 02 Apr 2020 20:08:03 +0000
Subject: [issue40140] test_builtin crashes when runned in parallel mode on
 solaris
In-Reply-To: <1585769988.66.0.906908269911.issue40140@roundup.psfhosted.org>
Message-ID: <1585858083.01.0.0223244751835.issue40140@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Thu Apr  2 16:08:03 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 02 Apr 2020 20:08:03 +0000
Subject: [issue40155] AIX: test_builtin.test_input_no_stdout_fileno() hangs
In-Reply-To: <1585830863.71.0.596270299618.issue40155@roundup.psfhosted.org>
Message-ID: <1585858083.08.0.488742182412.issue40155@roundup.psfhosted.org>


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


----------
pull_requests: +18677
pull_request: https://github.com/python/cpython/pull/19312

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

From report at bugs.python.org  Thu Apr  2 16:10:53 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 02 Apr 2020 20:10:53 +0000
Subject: [issue40155] AIX: test_builtin.test_input_no_stdout_fileno() hangs
In-Reply-To: <1585830863.71.0.596270299618.issue40155@roundup.psfhosted.org>
Message-ID: <1585858253.72.0.894783449326.issue40155@roundup.psfhosted.org>


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

Michael Felt: Can you please test if PR 19312 fix the issue for you on AIX?

----------

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

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: [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:12:05 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 02 Apr 2020 20:12:05 +0000
Subject: [issue40140] test_builtin crashes when runned in parallel mode on
 solaris
In-Reply-To: <1585769988.66.0.906908269911.issue40140@roundup.psfhosted.org>
Message-ID: <1585858325.61.0.324176128534.issue40140@roundup.psfhosted.org>


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

Batuhan: Can you please test if PR 19312 fix the issue for you on Solaris?

----------

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

From report at bugs.python.org  Thu Apr  2 16:20:18 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 02 Apr 2020 20:20:18 +0000
Subject: [issue17005] Add a topological sort algorithm
In-Reply-To: <1358717952.33.0.209682941713.issue17005@psf.upfronthosting.co.za>
Message-ID: <1585858818.61.0.657436898381.issue17005@roundup.psfhosted.org>


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

I just want to echo what Tim mentioned with the extra data point that some of the maintainers of some popular and wide-used open-source libraries that indeed have to deal with this problem or the parallel version of the problem (like gaborbernat in this thread, the maintainer of "tox" and "virtualenv") do indeed find the current API desirable.

----------

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

From report at bugs.python.org  Thu Apr  2 16:20:35 2020
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 02 Apr 2020 20:20:35 +0000
Subject: [issue40159] Make python -V -V output arguments of configure
In-Reply-To: <1585858296.94.0.293337697124.issue40159@roundup.psfhosted.org>
Message-ID: <1585858835.1.0.275200810341.issue40159@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

How about `python3 -c 'import sysconfig;print(sysconfig.get_config_vars()["CONFIG_ARGS"])'`?

----------
nosy: +zach.ware

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

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


Change by Volker Wei?mann <volker.weissmann at gmx.de>:


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

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

From report at bugs.python.org  Thu Apr  2 16:34:22 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Thu, 02 Apr 2020 20:34:22 +0000
Subject: [issue40140] test_builtin crashes when runned in parallel mode on
 solaris
In-Reply-To: <1585769988.66.0.906908269911.issue40140@roundup.psfhosted.org>
Message-ID: <1585859662.19.0.612490334726.issue40140@roundup.psfhosted.org>


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

I tested with both PR 19312 and PR 19308 and I still have the same crash 
0:00:00 load avg: 0.80 Run tests in parallel using 2 child processes
0:00:01 load avg: 0.79 [1/1/1] test_builtin crashed (Exit code -1)

----------

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

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: [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 16:49:51 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 02 Apr 2020 20:49:51 +0000
Subject: [issue17005] Add a topological sort algorithm
In-Reply-To: <1358717952.33.0.209682941713.issue17005@psf.upfronthosting.co.za>
Message-ID: <1585860591.75.0.759514630009.issue17005@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Thu Apr  2 16:51:48 2020
From: report at bugs.python.org (Jason Williams)
Date: Thu, 02 Apr 2020 20:51:48 +0000
Subject: [issue17681] Work with an extra field of gzip and zip files
In-Reply-To: <1365519781.38.0.309194725625.issue17681@psf.upfronthosting.co.za>
Message-ID: <1585860708.85.0.763532485935.issue17681@roundup.psfhosted.org>


Jason Williams <jasonjwwilliams at gmail.com> added the comment:

What's needed to get this integrated?  It will be great to not have to fork the GZIP.

----------
nosy: +Jason Williams

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

From report at bugs.python.org  Thu Apr  2 17:22:30 2020
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 02 Apr 2020 21:22:30 +0000
Subject: [issue40160] documentation example of os.walk should be less
 destructive
In-Reply-To: <1585859689.83.0.950657489634.issue40160@roundup.psfhosted.org>
Message-ID: <1585862550.9.0.661265305005.issue40160@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch
nosy: +python-dev
nosy_count: 2.0 -> 3.0
pull_requests: +18678
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19313

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

From report at bugs.python.org  Thu Apr  2 17:30:54 2020
From: report at bugs.python.org (John Taylor)
Date: Thu, 02 Apr 2020 21:30:54 +0000
Subject: [issue40160] documentation example of os.walk should be less
 destructive
In-Reply-To: <1585859689.83.0.950657489634.issue40160@roundup.psfhosted.org>
Message-ID: <1585863054.51.0.418778416279.issue40160@roundup.psfhosted.org>


John Taylor <johntaylor at gmail.com> added the comment:

https://github.com/python/cpython/pull/19313

I have just signed the CLA.

----------

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

From report at bugs.python.org  Thu Apr  2 17:32:34 2020
From: report at bugs.python.org (Larry Hastings)
Date: Thu, 02 Apr 2020 21:32:34 +0000
Subject: [issue39704] Disable code coverage
In-Reply-To: <1582241922.94.0.0257768022577.issue39704@roundup.psfhosted.org>
Message-ID: <1585863154.72.0.575401043169.issue39704@roundup.psfhosted.org>


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

Since explicit is better than implicit: yes, we do need backports.  PRs against 3.5 are getting marked red because of automated codecov complaints.

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

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

From report at bugs.python.org  Thu Apr  2 17:44:24 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 02 Apr 2020 21:44:24 +0000
Subject: [issue40140] test_builtin crashes when runned in parallel mode on
 solaris
In-Reply-To: <1585769988.66.0.906908269911.issue40140@roundup.psfhosted.org>
Message-ID: <1585863864.82.0.868909996895.issue40140@roundup.psfhosted.org>


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

> I tested with both PR 19312 and PR 19308 and I still have the same crash 

Which test is causing the issue? Does it still crash if you comment test_input_no_stdout_fileno()? Try to rename it "Xtest_input_no_stdout_fileno" to skip it.

What if you only run this test?

./python -m test test_builtin -m test_input_no_stdout_fileno -F -j10 -v

Maybe this test should register a signal handler for SIGHUP?

This bug looks like bpo-38547 which affected test_pty. I fixed it by registering a SIGHUP signal handler:

commit a1838ec2592e5082c75c77888f2a7a3eb21133e5
Author: Victor Stinner <vstinner at python.org>
Date:   Mon Dec 9 11:57:05 2019 +0100

    bpo-38547: Fix test_pty if the process is the session leader (GH-17519)
    
    Fix test_pty: if the process is the session leader, closing the
    master file descriptor raises a SIGHUP signal: simply ignore SIGHUP
    when running the tests.

----------

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

From report at bugs.python.org  Thu Apr  2 17:45:40 2020
From: report at bugs.python.org (Furkan Onder)
Date: Thu, 02 Apr 2020 21:45:40 +0000
Subject: [issue19961] MacOSX: Tkinter build failure when building without
 command-line tools
In-Reply-To: <1386850286.1.0.287048995559.issue19961@psf.upfronthosting.co.za>
Message-ID: <1585863940.06.0.472827315042.issue19961@roundup.psfhosted.org>


Furkan Onder <furkanonder at protonmail.com> added the comment:

You can try this solution,
https://stackoverflow.com/questions/11465258/xlib-h-not-found-when-building-graphviz-on-mac-os-x-10-8-mountain-lion#12089021

----------
nosy: +furkanonder

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

From report at bugs.python.org  Thu Apr  2 17:45:54 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 02 Apr 2020 21:45:54 +0000
Subject: [issue17005] Add a topological sort algorithm
In-Reply-To: <1358717952.33.0.209682941713.issue17005@psf.upfronthosting.co.za>
Message-ID: <1585863954.53.0.045104484323.issue17005@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> If your alternative isn't equally easy to use in a parallelized
> context, I'll be at best +0.

We may need two versions then, a full-featured TopologicalSorter() class and a simple tsort() function that doesn't aspire to be all things to all people.

----------

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

From report at bugs.python.org  Thu Apr  2 17:52:17 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 02 Apr 2020 21:52:17 +0000
Subject: [issue40140] test_builtin crashes when runned in parallel mode on
 solaris
In-Reply-To: <1585769988.66.0.906908269911.issue40140@roundup.psfhosted.org>
Message-ID: <1585864337.16.0.153924792611.issue40140@roundup.psfhosted.org>


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


----------
pull_requests: +18679
pull_request: https://github.com/python/cpython/pull/19314

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

From report at bugs.python.org  Thu Apr  2 17:53:52 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 02 Apr 2020 21:53:52 +0000
Subject: [issue17005] Add a topological sort algorithm
In-Reply-To: <1358717952.33.0.209682941713.issue17005@psf.upfronthosting.co.za>
Message-ID: <1585864432.02.0.481127760398.issue17005@roundup.psfhosted.org>


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

> We may need two versions then, a full-featured TopologicalSorter() class and a simple tsort() function that doesn't aspire to be all things to all people.

How this other version would differ from using .add() + .static_order() as Tim mentions? Originally we designed static_order() so it will satisfy the simpler use cases so I would suggest aspiring to simplify that interface if needed instead of adding an extra function.

----------

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

From report at bugs.python.org  Thu Apr  2 17:55:58 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Thu, 02 Apr 2020 21:55:58 +0000
Subject: [issue40140] test_builtin crashes when runned in parallel mode on
 solaris
In-Reply-To: <1585769988.66.0.906908269911.issue40140@roundup.psfhosted.org>
Message-ID: <1585864558.1.0.89955190347.issue40140@roundup.psfhosted.org>


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

isidentical at gcc-solaris11:~/cpython$ ./python -m test test_builtin -m test_input_no_stdout_fileno -F -j10 -v
== CPython 3.9.0a5+ (heads/master:dc4e965, Apr 2 2020, 23:53:26) [GCC 5.5.0]
== Solaris-2.11-sun4u-sparc-32bit big-endian
== cwd: /export/home/isidentical/cpython/build/test_python_24804
== CPU count: 8
== encodings: locale=UTF-8, FS=utf-8
0:00:00 load avg: 1.56 Run tests in parallel using 10 child processes
0:00:02 load avg: 1.57 [  1/1] test_builtin crashed (Exit code -1)
test_input_no_stdout_fileno (test.test_builtin.PtyTests) ...
Kill <TestWorkerProcess #2 running test=test_builtin pid=24812 time=2.1 sec> process group
Kill <TestWorkerProcess #3 running test=test_builtin pid=24810 time=2.1 sec> process group
Kill <TestWorkerProcess #4 running test=test_builtin pid=24815 time=2.1 sec> process group
Kill <TestWorkerProcess #5 running test=test_builtin pid=24807 time=2.1 sec> process group
Kill <TestWorkerProcess #6 running test=test_builtin pid=24809 time=2.1 sec> process group
Kill <TestWorkerProcess #7 running test=test_builtin pid=24814 time=2.1 sec> process group
Kill <TestWorkerProcess #8 running test=test_builtin pid=24808 time=2.1 sec> process group
Kill <TestWorkerProcess #9 running test=test_builtin pid=24813 time=2.1 sec> process group
Kill <TestWorkerProcess #10 running test=test_builtin pid=24816 time=2.1 sec> process group

== Tests result: FAILURE ==

1 test failed:
    test_builtin

Total duration: 2.2 sec
Tests result: FAILURE
isidentical at gcc-solaris11:~/cpython$ wget https://patch-diff.githubusercontent.com/raw/python/cpython/pull/19312.patch
--2020-04-02 23:53:51--  https://patch-diff.githubusercontent.com/raw/python/cpython/pull/19312.patch
Resolving patch-diff.githubusercontent.com (patch-diff.githubusercontent.com)... 140.82.118.4
Connecting to patch-diff.githubusercontent.com (patch-diff.githubusercontent.com)|140.82.118.4|:443... connected.
HTTP request sent, awaiting response... 200 OK
Cookie coming from patch-diff.githubusercontent.com attempted to set domain to github.com
Length: unspecified [text/plain]
Saving to: ?19312.patch?

19312.patch                                 [ <=>                                                                            ]   1.62K  --.-KB/s    in 0s      

2020-04-02 23:53:51 (3.38 MB/s) - ?19312.patch? saved [4252]
isidentical at gcc-solaris11:~/cpython$ git apply 19312.patch
isidentical at gcc-solaris11:~/cpython$ gmake -j8
...
isidentical at gcc-solaris11:~/cpython$ ./python -m test test_builtin -m test_input_no_stdout_fileno -F -j10 -v          
== CPython 3.9.0a5+ (heads/master:dc4e965, Apr 2 2020, 23:53:26) [GCC 5.5.0]
== Solaris-2.11-sun4u-sparc-32bit big-endian
== cwd: /export/home/isidentical/cpython/build/test_python_24850
== CPU count: 8
== encodings: locale=UTF-8, FS=utf-8
0:00:00 load avg: 1.71 Run tests in parallel using 10 child processes
0:00:02 load avg: 1.78 [  1/1] test_builtin crashed (Exit code -1)
test_input_no_stdout_fileno (test.test_builtin.PtyTests) ...
Kill <TestWorkerProcess #1 running test=test_builtin pid=24855 time=2.6 sec> process group
Kill <TestWorkerProcess #3 running test=test_builtin pid=24862 time=2.6 sec> process group
Kill <TestWorkerProcess #4 running test=test_builtin pid=24856 time=2.6 sec> process group
Kill <TestWorkerProcess #5 running test=test_builtin pid=24853 time=2.6 sec> process group
Kill <TestWorkerProcess #6 running test=test_builtin pid=24854 time=2.6 sec> process group
Kill <TestWorkerProcess #7 running test=test_builtin pid=24861 time=2.5 sec> process group
Kill <TestWorkerProcess #8 running test=test_builtin pid=24860 time=2.5 sec> process group
Kill <TestWorkerProcess #9 running test=test_builtin pid=24859 time=2.5 sec> process group
Kill <TestWorkerProcess #10 running test=test_builtin pid=24858 time=2.5 sec> process group

== Tests result: FAILURE ==

1 test failed:
    test_builtin

Total duration: 2.7 sec
Tests result: FAILURE

----------

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

From report at bugs.python.org  Thu Apr  2 17:57:58 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 02 Apr 2020 21:57:58 +0000
Subject: [issue40140] test_builtin crashes when runned in parallel mode on
 solaris
In-Reply-To: <1585769988.66.0.906908269911.issue40140@roundup.psfhosted.org>
Message-ID: <1585864678.89.0.0665508383749.issue40140@roundup.psfhosted.org>


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

Batuhan: Ok, now please test PR 19314 which registers a signal handler for SIGHUP. It should fix the issue for Solaris. Moreover, I also includes the fix for AIX (bpo-40155).

----------

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

From report at bugs.python.org  Thu Apr  2 18:06:18 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Thu, 02 Apr 2020 22:06:18 +0000
Subject: [issue35455] Solaris thread_time doesn't work with current
 implementation
In-Reply-To: <1544452341.93.0.788709270274.issue35455@psf.upfronthosting.co.za>
Message-ID: <1585865178.85.0.206756194055.issue35455@roundup.psfhosted.org>


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

This issue is still valid under other solaris/sunos versions. @kulikjak are you still interested in resolving this issue?

----------
nosy: +BTaskaya
resolution: not a bug -> 
status: closed -> open
versions: +Python 3.9

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

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: [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 18:14:10 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Thu, 02 Apr 2020 22:14:10 +0000
Subject: [issue40140] test_builtin crashes when runned in parallel mode on
 solaris
In-Reply-To: <1585769988.66.0.906908269911.issue40140@roundup.psfhosted.org>
Message-ID: <1585865650.77.0.273615549079.issue40140@roundup.psfhosted.org>


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

Victor, PR 19314 works perfectly.

----------

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

From report at bugs.python.org  Thu Apr  2 18:20:46 2020
From: report at bugs.python.org (Tim Peters)
Date: Thu, 02 Apr 2020 22:20:46 +0000
Subject: [issue17005] Add a topological sort algorithm
In-Reply-To: <1358717952.33.0.209682941713.issue17005@psf.upfronthosting.co.za>
Message-ID: <1585866046.97.0.627618038785.issue17005@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

Possibly, sure.  But I believe it's hard to beat

    add(node, *predecessors)

for usability as a way to build the dependency graph.  For example, a list of pairs is a comparative PITA for most use cases I've had.  Whether it's following a recipe to bake a cake, or tracing a maze of C include files, it seems _most_ natural to get input in the form "this thing depends on these other things".  Not the other way around, and neither a sequence of pairs.

_If_ you buy that, then .add() is screamingly natural, and trying to squash a pile of .add()s into a single sequence-of-sequences argument seems strained.

Typically I don't get input in one big, single gulp.  It's instead discovered one item at a time.  Fine - .add() it and then move on to the next item.  It's certainly possible to append the item and its predecessors to a persistent (across items) list, and call a function once at the end with that list.

But what does that buy?  I'm building the list solely to meet the function's input requirement - the list serves no other purpose.  Instead of calling .add() N times, I call .append() N times.  "add" is 3 letters shorter ;-)

----------

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

From report at bugs.python.org  Thu Apr  2 18:28:28 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 02 Apr 2020 22:28:28 +0000
Subject: [issue17005] Add a topological sort algorithm
In-Reply-To: <1358717952.33.0.209682941713.issue17005@psf.upfronthosting.co.za>
Message-ID: <1585866508.3.0.475429129862.issue17005@roundup.psfhosted.org>


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

Is also notable to mention that you can also provide the graph as a dictionary to the constructor:

>>> graph = {D: {B, C}, C: {A}, B: {A}, A:{object}}
>>> ts = TopologicalSorter(graph)

----------

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

From report at bugs.python.org  Thu Apr  2 18:30:51 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 02 Apr 2020 22:30:51 +0000
Subject: [issue17005] Add a topological sort algorithm
In-Reply-To: <1358717952.33.0.209682941713.issue17005@psf.upfronthosting.co.za>
Message-ID: <1585866651.61.0.785968276188.issue17005@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

How about I post a PR so we can talk about something concrete.  Then you two can either fight it to its death or you can join me in making it is good as possible, hopefully the latter :-)

I am not happy with the current API but do accept that both of you are in love with it.

----------

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

From report at bugs.python.org  Thu Apr  2 18:36:27 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 02 Apr 2020 22:36:27 +0000
Subject: [issue36541] Make lib2to3 grammar better match Python,
 support the := walrus
In-Reply-To: <1554514880.92.0.277848417721.issue36541@roundup.psfhosted.org>
Message-ID: <1585866987.07.0.578750554279.issue36541@roundup.psfhosted.org>


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


----------
nosy: +miss-islington
nosy_count: 9.0 -> 10.0
pull_requests: +18680
pull_request: https://github.com/python/cpython/pull/19315

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

From report at bugs.python.org  Thu Apr  2 18:40:32 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 02 Apr 2020 22:40:32 +0000
Subject: [issue40140] test_builtin crashes when runned in parallel mode on
 solaris
In-Reply-To: <1585769988.66.0.906908269911.issue40140@roundup.psfhosted.org>
Message-ID: <1585867232.47.0.778193447363.issue40140@roundup.psfhosted.org>


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


New changeset 7a51a7e19f0143f75f8fc9ff68f93ed40937aec6 by Victor Stinner in branch 'master':
bpo-40140: test_builtin.PtyTests registers SIGHUP handler (GH-19314)
https://github.com/python/cpython/commit/7a51a7e19f0143f75f8fc9ff68f93ed40937aec6


----------

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

From report at bugs.python.org  Thu Apr  2 18:41:11 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 02 Apr 2020 22:41:11 +0000
Subject: [issue40155] AIX: test_builtin.test_input_no_stdout_fileno() hangs
In-Reply-To: <1585830863.71.0.596270299618.issue40155@roundup.psfhosted.org>
Message-ID: <1585867271.11.0.135086894908.issue40155@roundup.psfhosted.org>


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

I pushed this change which should fix the issue on AIX:

New changeset 7a51a7e19f0143f75f8fc9ff68f93ed40937aec6 by Victor Stinner in branch 'master':
bpo-40140: test_builtin.PtyTests registers SIGHUP handler (GH-19314)
https://github.com/python/cpython/commit/7a51a7e19f0143f75f8fc9ff68f93ed40937aec6

I'm waiting for buildbots before closing this issue.

----------

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

From report at bugs.python.org  Thu Apr  2 18:44:16 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 02 Apr 2020 22:44:16 +0000
Subject: [issue40140] test_builtin crashes when runned in parallel mode on
 solaris
In-Reply-To: <1585769988.66.0.906908269911.issue40140@roundup.psfhosted.org>
Message-ID: <1585867456.62.0.0339707946718.issue40140@roundup.psfhosted.org>


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


----------
pull_requests: +18681
pull_request: https://github.com/python/cpython/pull/19316

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

From report at bugs.python.org  Thu Apr  2 18:49:28 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 02 Apr 2020 22:49:28 +0000
Subject: [issue40140] test_builtin crashes when runned in parallel mode on
 solaris
In-Reply-To: <1585769988.66.0.906908269911.issue40140@roundup.psfhosted.org>
Message-ID: <1585867768.6.0.584597804925.issue40140@roundup.psfhosted.org>


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

> Victor, PR 19314 works perfectly.

Thanks for testing Batuhan ;-)

By the way, Solaris is no longer officially supported by Python:
https://pythondev.readthedocs.io/platforms.html#best-effort-and-unofficial-platforms

There is no more Solaris buildbot. Solaris 11.4 will be likely the last release: Oracle no longer supports Solaris.

We may accept minor changes, but no invasive changes.

----------

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

From report at bugs.python.org  Thu Apr  2 18:55:16 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 02 Apr 2020 22:55:16 +0000
Subject: [issue17005] Add a topological sort algorithm
In-Reply-To: <1358717952.33.0.209682941713.issue17005@psf.upfronthosting.co.za>
Message-ID: <1585868116.36.0.971120453019.issue17005@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
Removed message: https://bugs.python.org/msg365640

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

From report at bugs.python.org  Thu Apr  2 18:57:44 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 02 Apr 2020 22:57:44 +0000
Subject: [issue17005] Add a topological sort algorithm
In-Reply-To: <1358717952.33.0.209682941713.issue17005@psf.upfronthosting.co.za>
Message-ID: <1585868264.54.0.829282467239.issue17005@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

How about I post a PR so we can talk about something concrete.  Then you two can either fight it to its death or you can join me in making it is good as possible, hopefully the latter :-)

I am not happy with the current API but do accept that both of you are in satisfied with it.

----------

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

From report at bugs.python.org  Thu Apr  2 19:10:05 2020
From: report at bugs.python.org (Larry Hastings)
Date: Thu, 02 Apr 2020 23:10:05 +0000
Subject: [issue40156] CodeCov/patch job stills runs on pull requests on 3.5
 and 3.6 branches
In-Reply-To: <1585834501.29.0.235392349062.issue40156@roundup.psfhosted.org>
Message-ID: <1585869005.15.0.0291833533592.issue40156@roundup.psfhosted.org>


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


New changeset ed07522a5faa3101f68be8e4b8369310f60860f8 by Victor Stinner in branch '3.5':
bpo-40156: Copy Codecov configuration from master (#19309)
https://github.com/python/cpython/commit/ed07522a5faa3101f68be8e4b8369310f60860f8


----------

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

From report at bugs.python.org  Thu Apr  2 19:13:45 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 02 Apr 2020 23:13:45 +0000
Subject: [issue40160] documentation example of os.walk should be less
 destructive
In-Reply-To: <1585859689.83.0.950657489634.issue40160@roundup.psfhosted.org>
Message-ID: <1585869225.47.0.511962720559.issue40160@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

The proposed replacement doesn't succeed in demonstrating why topdown=False is necessary.  Consider doing a rename instead of a deletion or print.

----------
nosy: +rhettinger

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

From report at bugs.python.org  Thu Apr  2 19:24:48 2020
From: report at bugs.python.org (Chris Martinez)
Date: Thu, 02 Apr 2020 23:24:48 +0000
Subject: [issue40158] MSBuild Extensions in CPython NuGet Package has Bad
 Expression
In-Reply-To: <1585850431.84.0.195210252651.issue40158@roundup.psfhosted.org>
Message-ID: <1585869888.82.0.151743130482.issue40158@roundup.psfhosted.org>


Chris Martinez <sydefekt at hotmail.com> added the comment:

In testing the fix, another issue has arisen. It appears the specified expression will never yield a usable path.

Expression 1:
$([msbuild]::GetDirectoryNameOfFileAbove($(MSBuildThisFileDirectory), "python_d.exe"))

Expression 2:
$([msbuild]::GetDirectoryNameOfFileAbove($(MSBuildThisFileDirectory), "python.exe"))

The package has the abridged structure of:

?? build
?  ?
?  ?? native
?     ?
?     ?? python.props
?
?? tools
   ?
   ?? python.exe


Based on this hierachy, neither exe will resolve because they do not have the same common ancestor. Additionally,
I found that "python_d.exe" is always assumed for "Configuration=Debug", but "python_d.exe" does not exist in
the package (that I could find). I'm not sure if this means the path is wrong, "python_d.exe" was accidentally
omiitted, or this property assignment simply should not exist. This current behavior will ultimately result in
the build integration failing because "python_d.exe" is resolved, but it doesn't exist.

Interestingly, the property specified in versions 3.7.1 and earlier appear to define the correct path as:

<PythonHome>$(MSBuildThisFileDirectory)\..\..\tools</PythonHome>

My suggestion is to revert back to this older variant. If "python_d.exe" isn't needed, then it should be removed.
If it is needed, then the path needs to be fixed. To make the path more robust, I also recommend resolving this
path using one of the following forms:

<PythonHome>$([MSBuild]::NormalizePath($(MSBuildThisFileDirectory)\..\..\tools))</PythonHome>

OR

<PythonHome>$([System.IO.Path]::GetFullPath($(MSBuildThisFileDirectory)\..\..\tools))</PythonHome>


In my particular case, the tooling I'm plugging this into wasn't happy unless the path was absolute. There
doesn't appear to be any reason or downside to resolving the path ahead of time. I can easily workaround
that issue, but I suspect resolving an absolute path may be useful to other package consumers as well.

As soon as I know what the final form of the property should be, I'll submit the PR and update this issue with the link

----------

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

From report at bugs.python.org  Thu Apr  2 19:43:31 2020
From: report at bugs.python.org (Tim Hatch)
Date: Thu, 02 Apr 2020 23:43:31 +0000
Subject: [issue36541] Make lib2to3 grammar better match Python,
 support the := walrus
In-Reply-To: <1554514880.92.0.277848417721.issue36541@roundup.psfhosted.org>
Message-ID: <1585871011.85.0.826802056676.issue36541@roundup.psfhosted.org>


Change by Tim Hatch <tim at timhatch.com>:


----------
pull_requests: +18682
pull_request: https://github.com/python/cpython/pull/19317

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

From report at bugs.python.org  Thu Apr  2 20:11:58 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 03 Apr 2020 00:11:58 +0000
Subject: [issue40140] test_builtin crashes when runned in parallel mode on
 solaris
In-Reply-To: <1585769988.66.0.906908269911.issue40140@roundup.psfhosted.org>
Message-ID: <1585872718.09.0.103483070368.issue40140@roundup.psfhosted.org>


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


New changeset 745bd91bab8e57c52d63a2d541465551d7551f78 by Victor Stinner in branch '3.8':
bpo-40140: test_builtin.PtyTests registers SIGHUP handler (GH-19314) (GH-19316)
https://github.com/python/cpython/commit/745bd91bab8e57c52d63a2d541465551d7551f78


----------

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

From report at bugs.python.org  Thu Apr  2 20:12:43 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 03 Apr 2020 00:12:43 +0000
Subject: [issue40155] AIX: test_builtin.test_input_no_stdout_fileno() hangs
In-Reply-To: <1585830863.71.0.596270299618.issue40155@roundup.psfhosted.org>
Message-ID: <1585872763.81.0.439186957553.issue40155@roundup.psfhosted.org>


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

> bpo-40140: test_builtin.PtyTests registers SIGHUP handler (GH-19314)

With this change, PPC64 AIX 3.x is back to green. I close this issue. Thanks for the bug report Michael Felt.

FYI I also backported my fix to 3.8: PR 19316.

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

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

From report at bugs.python.org  Thu Apr  2 20:15:04 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 03 Apr 2020 00:15:04 +0000
Subject: [issue40140] test_builtin crashes when runned in parallel mode on
 solaris
In-Reply-To: <1585769988.66.0.906908269911.issue40140@roundup.psfhosted.org>
Message-ID: <1585872904.32.0.725505280453.issue40140@roundup.psfhosted.org>


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


----------
pull_requests: +18683
pull_request: https://github.com/python/cpython/pull/19318

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

From report at bugs.python.org  Thu Apr  2 20:16:08 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 03 Apr 2020 00:16:08 +0000
Subject: [issue40140] test_builtin crashes when runned in parallel mode on
 solaris
In-Reply-To: <1585769988.66.0.906908269911.issue40140@roundup.psfhosted.org>
Message-ID: <1585872968.32.0.420488225447.issue40140@roundup.psfhosted.org>


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

I close the issue, it's now fixed in 3.8 and master (and I'm working on a 3.7 backport: PR 19318). Thanks Batuhan for the bug report.

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

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

From report at bugs.python.org  Thu Apr  2 20:34:11 2020
From: report at bugs.python.org (Ned Deily)
Date: Fri, 03 Apr 2020 00:34:11 +0000
Subject: [issue40156] CodeCov/patch job stills runs on pull requests on 3.5
 and 3.6 branches
In-Reply-To: <1585834501.29.0.235392349062.issue40156@roundup.psfhosted.org>
Message-ID: <1585874051.41.0.0199147102693.issue40156@roundup.psfhosted.org>


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


New changeset ebeabb5b728f009480ced3ca4738c20fa073b507 by Victor Stinner in branch '3.6':
bpo-40156: Copy Codecov configuration from master (GH-19306)
https://github.com/python/cpython/commit/ebeabb5b728f009480ced3ca4738c20fa073b507


----------

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

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: [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:40:39 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 03 Apr 2020 00:40:39 +0000
Subject: [issue40162] Upgrade Travis CI to OpenSSL 1.1.1f
In-Reply-To: <1585874380.21.0.0841454255298.issue40162@roundup.psfhosted.org>
Message-ID: <1585874439.18.0.354409000157.issue40162@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Thu Apr  2 20:41:06 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 03 Apr 2020 00:41:06 +0000
Subject: [issue40125] update OpenSSL 1.1.1 in multissltests.py to 1.1.1f
In-Reply-To: <1585667417.42.0.205219366434.issue40125@roundup.psfhosted.org>
Message-ID: <1585874466.07.0.72092724833.issue40125@roundup.psfhosted.org>


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

See also bpo-40162: Upgrade Travis CI to OpenSSL 1.1.1f.

----------

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

From report at bugs.python.org  Thu Apr  2 20:44:10 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 03 Apr 2020 00:44:10 +0000
Subject: [issue40146] Upgrade Azure Pipelines to OpenSSL 1.1.1f
In-Reply-To: <1585786427.57.0.72048128353.issue40146@roundup.psfhosted.org>
Message-ID: <1585874650.05.0.861164009927.issue40146@roundup.psfhosted.org>


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


----------
pull_requests: +18685
pull_request: https://github.com/python/cpython/pull/19320

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

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: [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:49:21 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 03 Apr 2020 00:49:21 +0000
Subject: [issue40125] update OpenSSL 1.1.1 in multissltests.py to 1.1.1f
In-Reply-To: <1585667417.42.0.205219366434.issue40125@roundup.psfhosted.org>
Message-ID: <1585874961.47.0.540768795679.issue40125@roundup.psfhosted.org>


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

I created bpo-40163: multissl doesn't support tarballs in /source/old/.

----------

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

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


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

When OpenSSL moves a tarball, all our pre-commit CIs are broken and suddenly, all PRs can no longer be merged. We have first write PRs to update the configuration of our CI to use the newer OpenSSL version, merge these PRs, and then *all* pending PRs must be rebased on top of these merged PRS to retrieve the newer CI configuration.

There are currently 1085 pending PRs at https://github.com/python/cpython/pulls Well, for most of them, the CI already passed so we can merge them. But if a reviewer requires changes, the CI will re-run and then fail :-(

Moreover, fixing multissltests.py doesn't help neither, since again, PRs should be rebased to retrieve multissltests.py changes.

I hope that I'm wrong and the situation is not so bad.

--

Another solution would be to enhance our workflow to always rebase PRs on the development branch. Something like what https://mergify.io/ does.

I'm not sure what is the configuration of Azure Pipelines, GitHub actions and Travis CI. Would it be possible to make them rebase the PRs before running tests.

----------

_______________________________________
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: [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 20:59:11 2020
From: report at bugs.python.org (Ned Deily)
Date: Fri, 03 Apr 2020 00:59:11 +0000
Subject: [issue40125] update OpenSSL 1.1.1 in multissltests.py to 1.1.1f
In-Reply-To: <1585667417.42.0.205219366434.issue40125@roundup.psfhosted.org>
Message-ID: <1585875551.67.0.0570987924491.issue40125@roundup.psfhosted.org>


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

Also bpo-40164: reminder to update Windows and macOS installer builds

----------
nosy: +ned.deily

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

From report at bugs.python.org  Thu Apr  2 20:59:24 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 03 Apr 2020 00:59:24 +0000
Subject: [issue40156] CodeCov/patch job stills runs on pull requests on 3.5
 and 3.6 branches
In-Reply-To: <1585834501.29.0.235392349062.issue40156@roundup.psfhosted.org>
Message-ID: <1585875564.96.0.662895243232.issue40156@roundup.psfhosted.org>


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

Thanks Ned and Larry.

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

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

From report at bugs.python.org  Thu Apr  2 21:04:02 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 03 Apr 2020 01:04:02 +0000
Subject: [issue40162] Upgrade Travis CI to OpenSSL 1.1.1f
In-Reply-To: <1585874380.21.0.0841454255298.issue40162@roundup.psfhosted.org>
Message-ID: <1585875842.98.0.5835732194.issue40162@roundup.psfhosted.org>


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


New changeset b1ffb8b72307a556442d09b427c3b29badb9878c by Victor Stinner in branch 'master':
bpo-40162: Update Travis CI config to OpenSSL 1.1.1f (GH-19319)
https://github.com/python/cpython/commit/b1ffb8b72307a556442d09b427c3b29badb9878c


----------

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

From report at bugs.python.org  Thu Apr  2 21:04:21 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 03 Apr 2020 01:04:21 +0000
Subject: [issue40162] Upgrade Travis CI to OpenSSL 1.1.1f
In-Reply-To: <1585874380.21.0.0841454255298.issue40162@roundup.psfhosted.org>
Message-ID: <1585875861.06.0.286263805162.issue40162@roundup.psfhosted.org>


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


----------
pull_requests: +18687
pull_request: https://github.com/python/cpython/pull/19322

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

From report at bugs.python.org  Thu Apr  2 21:04:12 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 03 Apr 2020 01:04:12 +0000
Subject: [issue40162] Upgrade Travis CI to OpenSSL 1.1.1f
In-Reply-To: <1585874380.21.0.0841454255298.issue40162@roundup.psfhosted.org>
Message-ID: <1585875852.67.0.262949052003.issue40162@roundup.psfhosted.org>


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


----------
nosy: +miss-islington
nosy_count: 1.0 -> 2.0
pull_requests: +18686
pull_request: https://github.com/python/cpython/pull/19321

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

From report at bugs.python.org  Thu Apr  2 21:04:49 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 03 Apr 2020 01:04:49 +0000
Subject: [issue40153] json dump with repeated key
In-Reply-To: <1585829958.79.0.134366704668.issue40153@roundup.psfhosted.org>
Message-ID: <1585875889.84.0.776786166643.issue40153@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Has this been a problem in practice, or just a theoretical issue?

To make this raise an exception, the JSON encoder would have to add one extra test per key.

I think we should just document the possibility.

----------
nosy: +rhettinger

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

From report at bugs.python.org  Thu Apr  2 21:05:13 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 03 Apr 2020 01:05:13 +0000
Subject: [issue40146] Upgrade Azure Pipelines to OpenSSL 1.1.1f
In-Reply-To: <1585786427.57.0.72048128353.issue40146@roundup.psfhosted.org>
Message-ID: <1585875913.94.0.558810978741.issue40146@roundup.psfhosted.org>


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


New changeset 1767a0490f80c7b90d81051db24ef2b82cd9434f by Victor Stinner in branch 'master':
bpo-40146: Update OpenSSL to 1.1.1f in Azure Pipelines (GH-19320)
https://github.com/python/cpython/commit/1767a0490f80c7b90d81051db24ef2b82cd9434f


----------

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

From report at bugs.python.org  Thu Apr  2 21:05:31 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 03 Apr 2020 01:05:31 +0000
Subject: [issue40146] Upgrade Azure Pipelines to OpenSSL 1.1.1f
In-Reply-To: <1585786427.57.0.72048128353.issue40146@roundup.psfhosted.org>
Message-ID: <1585875931.24.0.0423689800163.issue40146@roundup.psfhosted.org>


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


----------
pull_requests: +18689
pull_request: https://github.com/python/cpython/pull/19324

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

From report at bugs.python.org  Thu Apr  2 21:05:24 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 03 Apr 2020 01:05:24 +0000
Subject: [issue40146] Upgrade Azure Pipelines to OpenSSL 1.1.1f
In-Reply-To: <1585786427.57.0.72048128353.issue40146@roundup.psfhosted.org>
Message-ID: <1585875924.23.0.0305781304378.issue40146@roundup.psfhosted.org>


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


----------
pull_requests: +18688
pull_request: https://github.com/python/cpython/pull/19323

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

From report at bugs.python.org  Thu Apr  2 21:16:03 2020
From: report at bugs.python.org (Ned Deily)
Date: Fri, 03 Apr 2020 01:16:03 +0000
Subject: [issue39503] [security][CVE-2020-8492] Denial of service in
 urllib.request.AbstractBasicAuthHandler
In-Reply-To: <1580397089.41.0.564267118679.issue39503@roundup.psfhosted.org>
Message-ID: <1585876563.42.0.32879704181.issue39503@roundup.psfhosted.org>


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


New changeset 69cdeeb93e0830004a495ed854022425b93b3f3e by Victor Stinner in branch '3.6':
bpo-39503: CVE-2020-8492: Fix AbstractBasicAuthHandler (GH-18284) (GH-19304)
https://github.com/python/cpython/commit/69cdeeb93e0830004a495ed854022425b93b3f3e


----------
nosy: +ned.deily

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

From report at bugs.python.org  Thu Apr  2 21:21:40 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 03 Apr 2020 01:21:40 +0000
Subject: [issue40162] Upgrade Travis CI to OpenSSL 1.1.1f
In-Reply-To: <1585874380.21.0.0841454255298.issue40162@roundup.psfhosted.org>
Message-ID: <1585876900.61.0.247457681577.issue40162@roundup.psfhosted.org>


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


New changeset 1ba6fe43e888668acfbf74038b82c6ee24ab1c41 by Miss Islington (bot) in branch '3.7':
bpo-40162: Update Travis CI config to OpenSSL 1.1.1f (GH-19319)
https://github.com/python/cpython/commit/1ba6fe43e888668acfbf74038b82c6ee24ab1c41


----------

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

From report at bugs.python.org  Thu Apr  2 21:21:58 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 03 Apr 2020 01:21:58 +0000
Subject: [issue40162] Upgrade Travis CI to OpenSSL 1.1.1f
In-Reply-To: <1585874380.21.0.0841454255298.issue40162@roundup.psfhosted.org>
Message-ID: <1585876918.12.0.601595148425.issue40162@roundup.psfhosted.org>


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


New changeset 1c325c4e0bf31a18d06784006eabf4d5a4a1d706 by Miss Islington (bot) in branch '3.8':
bpo-40162: Update Travis CI config to OpenSSL 1.1.1f (GH-19319)
https://github.com/python/cpython/commit/1c325c4e0bf31a18d06784006eabf4d5a4a1d706


----------

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

From report at bugs.python.org  Thu Apr  2 21:25:57 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 03 Apr 2020 01:25:57 +0000
Subject: [issue40146] Upgrade Azure Pipelines to OpenSSL 1.1.1f
In-Reply-To: <1585786427.57.0.72048128353.issue40146@roundup.psfhosted.org>
Message-ID: <1585877157.52.0.839622592143.issue40146@roundup.psfhosted.org>


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


New changeset f2296ef9ce586bf2f51c125b085c2b080768040c by Miss Islington (bot) in branch '3.8':
bpo-40146: Update OpenSSL to 1.1.1f in Azure Pipelines (GH-19320)
https://github.com/python/cpython/commit/f2296ef9ce586bf2f51c125b085c2b080768040c


----------

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

From report at bugs.python.org  Thu Apr  2 21:28:39 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Fri, 03 Apr 2020 01:28:39 +0000
Subject: [issue40140] test_builtin crashes when runned in parallel mode on
 solaris
In-Reply-To: <1585769988.66.0.906908269911.issue40140@roundup.psfhosted.org>
Message-ID: <1585877319.32.0.729531768885.issue40140@roundup.psfhosted.org>


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

> There is no more Solaris buildbot. Solaris 11.4 will be likely the last release: Oracle no longer supports Solaris.

Well, if needed I can create one but looks like it is going be an obsoleted OS soon :/

----------

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

From report at bugs.python.org  Thu Apr  2 21:37:36 2020
From: report at bugs.python.org (Larry Hastings)
Date: Fri, 03 Apr 2020 01:37:36 +0000
Subject: [issue38804] Regular Expression Denial of Service in http.cookiejar
In-Reply-To: <1573774680.03.0.864081161145.issue38804@roundup.psfhosted.org>
Message-ID: <1585877856.22.0.54275422384.issue38804@roundup.psfhosted.org>


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


New changeset 55a6a16a46239a71b635584e532feb8b17ae7fdf by Victor Stinner in branch '3.5':
bpo-38804: Fix REDoS in http.cookiejar (GH-17157) (#17344)
https://github.com/python/cpython/commit/55a6a16a46239a71b635584e532feb8b17ae7fdf


----------

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

From report at bugs.python.org  Thu Apr  2 21:40:58 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 03 Apr 2020 01:40:58 +0000
Subject: [issue40162] Upgrade Travis CI to OpenSSL 1.1.1f
In-Reply-To: <1585874380.21.0.0841454255298.issue40162@roundup.psfhosted.org>
Message-ID: <1585878058.59.0.944788723693.issue40162@roundup.psfhosted.org>


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


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.7, Python 3.8

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

From report at bugs.python.org  Thu Apr  2 21:45:43 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 03 Apr 2020 01:45:43 +0000
Subject: [issue40146] Upgrade Azure Pipelines to OpenSSL 1.1.1f
In-Reply-To: <1585786427.57.0.72048128353.issue40146@roundup.psfhosted.org>
Message-ID: <1585878343.81.0.835493863529.issue40146@roundup.psfhosted.org>


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


New changeset 7ed2acc6e89cea07f140fc374a77e8b36442df2e by Miss Islington (bot) in branch '3.7':
bpo-40146: Update OpenSSL to 1.1.1f in Azure Pipelines (GH-19320) (GH-19324)
https://github.com/python/cpython/commit/7ed2acc6e89cea07f140fc374a77e8b36442df2e


----------

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

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: [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 21:54:04 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Fri, 03 Apr 2020 01:54:04 +0000
Subject: [issue40165] Hide stderror from the user if command failes
In-Reply-To: <1585878723.67.0.918823600877.issue40165@roundup.psfhosted.org>
Message-ID: <1585878844.82.0.696960174666.issue40165@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Thu Apr  2 22:40:16 2020
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 03 Apr 2020 02:40:16 +0000
Subject: [issue40120] Undefined C behavior going beyond end of struct via a
 [1] arrays.
In-Reply-To: <1585602263.71.0.279519604291.issue40120@roundup.psfhosted.org>
Message-ID: <1585881616.07.0.781871012.issue40120@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:

updates:

- extern "C" is indeed really only about linking so it has no bearing.

What I'm hearing from talking to our C++ compiler team is unfortunately sad: The C++ standard does not support flexible array member syntax on purpose because it leads to problems specific to C++ (ex: what do "new" and "del" do?)

So some compilers will reject such code (just as some accept it treating it as C99 does).  Meaning we can't do this in any public header file.

One workaround would indeed be to do something similar to that hashtable code, but it is quite annoying and I don't know that we could actually change the definition of PyBytesObject that way as its internals could be referenced externally.  (though all the bytes should line up regardless so even macros before and after such a change would be compatible?)

Within our internal private pure C code we could move to use this feature; things in .h files are the cross language issue.

Anyways I'm following up internally to better understand the motivation for wanting code to not use the "it's worked forever" technically undefined behavior of the trailing [1] member and out of bounds access.

Pondering, I wonder if this could turn into a "-fwrapv" style of situation, we depend on that behavior working so we adopted the compiler flag when compilers started to care; so at most we might some day need to pass another compiler flag to ensure it stays?  we'll see.

I'm inclined not to move forward with my PRs for now.

----------

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

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: [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: [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  Thu Apr  2 23:13:26 2020
From: report at bugs.python.org (Beier Liu)
Date: Fri, 03 Apr 2020 03:13:26 +0000
Subject: [issue40167] Cython files don't compile on Mingw-w64 64-bit
In-Reply-To: <1585883513.89.0.776539669318.issue40167@roundup.psfhosted.org>
Message-ID: <1585883606.25.0.0933630040614.issue40167@roundup.psfhosted.org>


Change by Beier Liu <imbenliu at gmail.com>:


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

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

From report at bugs.python.org  Thu Apr  2 23:22:08 2020
From: report at bugs.python.org (Andy Lester)
Date: Fri, 03 Apr 2020 03:22:08 +0000
Subject: [issue39943] Meta: Clean up various issues in C internals
In-Reply-To: <1583983387.49.0.277830283994.issue39943@roundup.psfhosted.org>
Message-ID: <1585884128.52.0.0490302447243.issue39943@roundup.psfhosted.org>


Change by Andy Lester <andy at petdance.com>:


----------
pull_requests: +18692
pull_request: https://github.com/python/cpython/pull/19327

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

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


Change by Ama Aje My Fren <amaajemyfren at gmail.com>:


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

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

From report at bugs.python.org  Fri Apr  3 02:06:30 2020
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 03 Apr 2020 06:06:30 +0000
Subject: [issue40163] multissl doesn't support tarballs in /source/old/
In-Reply-To: <1585874938.56.0.268058447907.issue40163@roundup.psfhosted.org>
Message-ID: <1585893990.37.0.273905324331.issue40163@roundup.psfhosted.org>


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

Ah crap :/ That's annoying.

This breaks all CI of all our active branches and all open PRs. I'll fix the issue and talk to OpenSSL upstream.

----------
assignee:  -> christian.heimes
versions: +Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8

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

From report at bugs.python.org  Fri Apr  3 02:36:25 2020
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 03 Apr 2020 06:36:25 +0000
Subject: [issue40163] multissl doesn't support tarballs in /source/old/
In-Reply-To: <1585874938.56.0.268058447907.issue40163@roundup.psfhosted.org>
Message-ID: <1585895785.19.0.112010508459.issue40163@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Fri Apr  3 02:38:22 2020
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 03 Apr 2020 06:38:22 +0000
Subject: [issue40163] multissl doesn't support tarballs in /source/old/
In-Reply-To: <1585874938.56.0.268058447907.issue40163@roundup.psfhosted.org>
Message-ID: <1585895902.49.0.125294453583.issue40163@roundup.psfhosted.org>


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

Benjamin, Larry,
The problem affects testing of security-only branches and 2.7.

----------
components: +Tests
nosy: +benjamin.peterson, larry
type:  -> behavior

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

From report at bugs.python.org  Fri Apr  3 03:11:54 2020
From: report at bugs.python.org (Rajesh R Naik)
Date: Fri, 03 Apr 2020 07:11:54 +0000
Subject: [issue40083] No run option available in python idle in version 3.8.2
In-Reply-To: <1585292684.98.0.176532437082.issue40083@roundup.psfhosted.org>
Message-ID: <1585897914.96.0.434815910965.issue40083@roundup.psfhosted.org>


Rajesh R Naik <naikrajesh.naik110 at gmail.com> added the comment:

1.How are you installing python?  From the python.org installer (which one)?  From the Window store?  From a 3rd party installer (which one)?
>> we installed form python.org not from windows store and not 3rd party
2.How do you start IDLE?
>> by searching python idle on start windows in laptop
3. What does Help => About IDLE say about the tk version?
>> We are using python 3.8.2 version
4.How do you get an editor window?  What do you see on the menu?  If Run appears, what happens when you click it?
>> after installed its shows the editor window in that not showing run option.
5.Start IDLE from Command Prompt with "py -3.8 -m idlelib".  Do you ever see any error messages?
>> no idea how to run py idel in command promot
6.Have you touched any files in Lib/idlelib?
>> I have touched the Lib/idlelib.

----------

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

From report at bugs.python.org  Fri Apr  3 04:00:36 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 03 Apr 2020 08:00:36 +0000
Subject: [issue40122] The implementation and documentation of "dis.findlables"
 don't match
In-Reply-To: <1585636419.17.0.745722185034.issue40122@roundup.psfhosted.org>
Message-ID: <1585900836.73.0.356473530814.issue40122@roundup.psfhosted.org>


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


New changeset b74468e233a5137ff518e61eff65ca2d8833e38a by laike9m in branch 'master':
bpo-40122: Updated documentation for dis.findlabels() (GH-19274)
https://github.com/python/cpython/commit/b74468e233a5137ff518e61eff65ca2d8833e38a


----------

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

From report at bugs.python.org  Fri Apr  3 04:00:26 2020
From: report at bugs.python.org (ChrisRands)
Date: Fri, 03 Apr 2020 08:00:26 +0000
Subject: [issue40132] Mechanism to control who owns package names on PyPI?
In-Reply-To: <1585731365.14.0.524521872477.issue40132@roundup.psfhosted.org>
Message-ID: <1585900826.47.0.810764083602.issue40132@roundup.psfhosted.org>


ChrisRands <chrisrands0 at gmail.com> added the comment:

Thanks R?mi, I missed that in PEP 541. I am still concerned that PyPI may become saturated with unmaintained packages (it is already common that one's preferred package name is taken). However, the guidance is already clear, and I guess anything stronger, like revoking unmaintained/unused packages, would be difficult to police fairly

----------

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

From report at bugs.python.org  Fri Apr  3 04:00:44 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 03 Apr 2020 08:00:44 +0000
Subject: [issue40122] The implementation and documentation of "dis.findlables"
 don't match
In-Reply-To: <1585636419.17.0.745722185034.issue40122@roundup.psfhosted.org>
Message-ID: <1585900844.1.0.382037443511.issue40122@roundup.psfhosted.org>


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


----------
nosy: +miss-islington
nosy_count: 4.0 -> 5.0
pull_requests: +18695
pull_request: https://github.com/python/cpython/pull/19330

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

From report at bugs.python.org  Fri Apr  3 04:00:51 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 03 Apr 2020 08:00:51 +0000
Subject: [issue40122] The implementation and documentation of "dis.findlables"
 don't match
In-Reply-To: <1585636419.17.0.745722185034.issue40122@roundup.psfhosted.org>
Message-ID: <1585900851.27.0.93366333788.issue40122@roundup.psfhosted.org>


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


----------
pull_requests: +18696
pull_request: https://github.com/python/cpython/pull/19331

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

From report at bugs.python.org  Fri Apr  3 04:06:15 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 03 Apr 2020 08:06:15 +0000
Subject: [issue40122] The implementation and documentation of "dis.findlables"
 don't match
In-Reply-To: <1585636419.17.0.745722185034.issue40122@roundup.psfhosted.org>
Message-ID: <1585901175.09.0.498104445239.issue40122@roundup.psfhosted.org>


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


New changeset 00c779fd9c0a9e7586681a44e35607c1113b5014 by Miss Islington (bot) in branch '3.7':
bpo-40122: Updated documentation for dis.findlabels() (GH-19274)
https://github.com/python/cpython/commit/00c779fd9c0a9e7586681a44e35607c1113b5014


----------

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

From report at bugs.python.org  Fri Apr  3 04:07:22 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 03 Apr 2020 08:07:22 +0000
Subject: [issue40122] The implementation and documentation of "dis.findlables"
 don't match
In-Reply-To: <1585636419.17.0.745722185034.issue40122@roundup.psfhosted.org>
Message-ID: <1585901242.76.0.301657501401.issue40122@roundup.psfhosted.org>


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


New changeset 77c623ba3d084e99d68c30f368bd7fbd7f175b60 by Miss Islington (bot) in branch '3.8':
bpo-40122: Updated documentation for dis.findlabels() (GH-19274)
https://github.com/python/cpython/commit/77c623ba3d084e99d68c30f368bd7fbd7f175b60


----------

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

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: [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:13:21 2020
From: report at bugs.python.org (Lin Gao)
Date: Fri, 03 Apr 2020 08:13:21 +0000
Subject: [issue39952] Using VS2019 to automatically build Python3 and it
 failed to build
In-Reply-To: <1584071199.52.0.120678224037.issue39952@roundup.psfhosted.org>
Message-ID: <1585901601.14.0.450812146701.issue39952@roundup.psfhosted.org>


Lin Gao <gaolin01 at beyondsoft.com> added the comment:

Hi Steve,

Sorry for the delay.

Thanks for your information and help. We mainly use open source projects to test the vs compiler backend. Now is the migration for testing and need to replace vs2017 with vs2019. 

Currently we used the second work around you provided,it works. 

Thanks,
Lin

----------

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

From report at bugs.python.org  Fri Apr  3 04:21:38 2020
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Fri, 03 Apr 2020 08:21:38 +0000
Subject: [issue40168] import pandas error[python 3.8.]
In-Reply-To: <1585901328.18.0.45804352886.issue40168@roundup.psfhosted.org>
Message-ID: <1585902098.97.0.357953890479.issue40168@roundup.psfhosted.org>


R?mi Lapeyre <remi.lapeyre at henki.fr> added the comment:

Hi Harish, it looks like you are having an issue related to Pandas and not Python itself. This bug tracker is for issues related to Python, for issues related to Pandas you will want to open a new issue at https://github.com/pandas-dev/pandas

----------
nosy: +remi.lapeyre

_______________________________________
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: [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 05:14:10 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 03 Apr 2020 09:14:10 +0000
Subject: [issue40122] The implementation and documentation of "dis.findlables"
 don't match
In-Reply-To: <1585636419.17.0.745722185034.issue40122@roundup.psfhosted.org>
Message-ID: <1585905250.69.0.201619483888.issue40122@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Fri Apr  3 05:27:55 2020
From: report at bugs.python.org (Steve Dower)
Date: Fri, 03 Apr 2020 09:27:55 +0000
Subject: [issue40158] MSBuild Extensions in CPython NuGet Package has Bad
 Expression
In-Reply-To: <1585850431.84.0.195210252651.issue40158@roundup.psfhosted.org>
Message-ID: <1585906075.7.0.532228875727.issue40158@roundup.psfhosted.org>


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

Either of those fixes look good. I normally use IO.Path personally, which might be because it's been around longer, but anything that works on VS 2017 and later should be fine.

----------

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

From report at bugs.python.org  Fri Apr  3 05:31:22 2020
From: report at bugs.python.org (Steve Dower)
Date: Fri, 03 Apr 2020 09:31:22 +0000
Subject: [issue40143] shutil.rmtree will frequently fail on Windows under
 heavy load due to racy deletion
In-Reply-To: <1585779323.08.0.697022705599.issue40143@roundup.psfhosted.org>
Message-ID: <1585906282.92.0.830860086646.issue40143@roundup.psfhosted.org>


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

What about renaming the base directory in place? Moving things across drives doesn't help, and we can't reasonably determine a suitable location for temp files other than by leaving them where they are.

----------

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

From report at bugs.python.org  Fri Apr  3 05:38:01 2020
From: report at bugs.python.org (Michael Felt)
Date: Fri, 03 Apr 2020 09:38:01 +0000
Subject: [issue40155] AIX: test_builtin.test_input_no_stdout_fileno() hangs
In-Reply-To: <1585830863.71.0.596270299618.issue40155@roundup.psfhosted.org>
Message-ID: <1585906681.43.0.933951492018.issue40155@roundup.psfhosted.org>


Michael Felt <aixtools at felt.demon.nl> added the comment:

Thanks for the fix!

----------

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

From report at bugs.python.org  Fri Apr  3 06:54:09 2020
From: report at bugs.python.org (Miguel Amaral)
Date: Fri, 03 Apr 2020 10:54:09 +0000
Subject: [issue36906] Compile time textwrap.dedent() equivalent for str or
 bytes literals
In-Reply-To: <1557772831.22.0.440689390024.issue36906@roundup.psfhosted.org>
Message-ID: <1585911249.79.0.778684644323.issue36906@roundup.psfhosted.org>


Miguel Amaral <amaral.miguel2 at gmail.com> added the comment:

A related issue(which I believe has no topic in this forum yet) is substituting an expression that results in a multiline string into a multiline f-string while matching its indentation.
If a new type of string prefix is made to auto-dedent, maybe the substitutions should match the local indentation.
Some related stackoverflow posts:

https://stackoverflow.com/questions/36739667/python-templates-for-generating-python-code-with-proper-multiline-indentation

https://stackoverflow.com/a/57189263/2976410

I.e. ideally we would have:
```python
def make_g_code():
  nl='\n'
  return d"""\
    def g():
      {nl.join(something(i) for i in range(n))}
      return something_else
    """
```
This still has issues. Newline needs to be put into a variable, for instance. In the case of using this template for languages, great many use braces for delimiting blocks and those need to be escaped inside f-strings.

An implementation that works with spaces only (does not suit my case where mixed indentation is possible) is here:

http://code.activestate.com/recipes/578835-string-templates-with-adaptive-indenting/

Please let me know if this is the wrong place to comment on this issue.

----------
nosy: +Miguel Amaral

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

From report at bugs.python.org  Fri Apr  3 07:22:15 2020
From: report at bugs.python.org (brent s.)
Date: Fri, 03 Apr 2020 11:22:15 +0000
Subject: [issue9253] argparse: optional subparsers
In-Reply-To: <1279056589.03.0.566167994161.issue9253@psf.upfronthosting.co.za>
Message-ID: <1585912935.24.0.974384748739.issue9253@roundup.psfhosted.org>


Change by brent s. <brent.saner at gmail.com>:


----------
nosy: +bsaner

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

From report at bugs.python.org  Fri Apr  3 07:48:40 2020
From: report at bugs.python.org (Piotr Dobrogost)
Date: Fri, 03 Apr 2020 11:48:40 +0000
Subject: [issue24132] Direct sub-classing of pathlib.Path
In-Reply-To: <1430890013.04.0.304568332905.issue24132@psf.upfronthosting.co.za>
Message-ID: <1585914520.29.0.428505794767.issue24132@roundup.psfhosted.org>


Change by Piotr Dobrogost <bugs.python.org at p.dobrogost.net>:


----------
nosy: +piotr.dobrogost

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

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: [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 07:57:17 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 03 Apr 2020 11:57:17 +0000
Subject: [issue39573] Make PyObject an opaque structure in the limited C API
In-Reply-To: <1581030432.16.0.48160379721.issue39573@roundup.psfhosted.org>
Message-ID: <1585915037.75.0.813295715387.issue39573@roundup.psfhosted.org>


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

I created bpo-40170 "[C API] Make PyTypeObject structure an opaque structure in the public C API".

----------

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

From report at bugs.python.org  Fri Apr  3 07:58:24 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Fri, 03 Apr 2020 11:58:24 +0000
Subject: [issue40170] [C API] Make PyTypeObject structure an opaque structure
 in the public C API
In-Reply-To: <1585915023.07.0.846808236133.issue40170@roundup.psfhosted.org>
Message-ID: <1585915104.16.0.841095422757.issue40170@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
nosy: +corona10

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

From report at bugs.python.org  Fri Apr  3 08:08:15 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 03 Apr 2020 12:08:15 +0000
Subject: [issue40120] Undefined C behavior going beyond end of struct via a
 [1] arrays.
In-Reply-To: <1585602263.71.0.279519604291.issue40120@roundup.psfhosted.org>
Message-ID: <1585915695.41.0.402257087469.issue40120@roundup.psfhosted.org>


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

For me, the most sane option is to make structures opaque in the C API, and then flexible array members.

I did something similar for atomic types. First, we got tons of build isssues with various C compilers and then with C++ compilers. I moved the header to our "internal C API", so basically I removed it from the public C API. Since that time, we stopped to get bug reports about pyatomic.h :-)

----------

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

From report at bugs.python.org  Fri Apr  3 08:09:14 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 03 Apr 2020 12:09:14 +0000
Subject: [issue40140] test_builtin crashes when runned in parallel mode on
 solaris
In-Reply-To: <1585769988.66.0.906908269911.issue40140@roundup.psfhosted.org>
Message-ID: <1585915754.94.0.955602087497.issue40140@roundup.psfhosted.org>


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


New changeset 0961dbdea2a449fc5b7d77610d6d10e6036fbdf3 by Victor Stinner in branch '3.7':
bpo-40140: test_builtin.PtyTests registers SIGHUP handler (GH-19314) (GH-19316) (GH-19318)
https://github.com/python/cpython/commit/0961dbdea2a449fc5b7d77610d6d10e6036fbdf3


----------

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

From report at bugs.python.org  Fri Apr  3 08:09:59 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 03 Apr 2020 12:09:59 +0000
Subject: [issue40140] test_builtin crashes when runned in parallel mode on
 solaris
In-Reply-To: <1585769988.66.0.906908269911.issue40140@roundup.psfhosted.org>
Message-ID: <1585915799.68.0.130222981245.issue40140@roundup.psfhosted.org>


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

> Well, if needed I can create one but looks like it is going be an obsoleted OS soon :/

I dislike the idea of making Python codes to support Solaris, since Solaris vendor doesn't support it anymore... Moreover, it's closed source, and most core devs don't have access to Solaris (ex: me).

----------

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

From report at bugs.python.org  Fri Apr  3 08:13:34 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 03 Apr 2020 12:13:34 +0000
Subject: [issue40163] multissl doesn't support tarballs in /source/old/
In-Reply-To: <1585874938.56.0.268058447907.issue40163@roundup.psfhosted.org>
Message-ID: <1585916014.77.0.141760510251.issue40163@roundup.psfhosted.org>


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

> talk to OpenSSL upstream.

Do you mean continue to provide old versions in /source/ directory as well? Maybe they move tarballs to /source/old/ on purpose, to force users to use the latest versions which get fixes for new vulnerabilities?

----------

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

From report at bugs.python.org  Fri Apr  3 08:13:57 2020
From: report at bugs.python.org (=?utf-8?q?Ugra_D=C3=A1niel?=)
Date: Fri, 03 Apr 2020 12:13:57 +0000
Subject: [issue37095] [Feature Request]: Add zstd support in tarfile
In-Reply-To: <1559187768.11.0.7498103877.issue37095@roundup.psfhosted.org>
Message-ID: <1585916037.23.0.600859996438.issue37095@roundup.psfhosted.org>


Change by Ugra D?niel <daniel.ugra at gmail.com>:


----------
nosy: +daniel.ugra

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

From report at bugs.python.org  Fri Apr  3 08:15:18 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Fri, 03 Apr 2020 12:15:18 +0000
Subject: [issue40149] test_threading leaked [38, 38, 38] references, sum=114
In-Reply-To: <1585792445.62.0.0518463995906.issue40149@roundup.psfhosted.org>
Message-ID: <1585916118.8.0.172968213311.issue40149@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

gc: collectable <type 0x7fc033c3cbd0>
gc: collectable <dict 0x104d79830>
gc: collectable <tuple 0x104d725a0>
gc: collectable <builtin_function_or_method 0x104d79890>

is not collected for the first time.

----------

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

From report at bugs.python.org  Fri Apr  3 08:54:50 2020
From: report at bugs.python.org (John Taylor)
Date: Fri, 03 Apr 2020 12:54:50 +0000
Subject: [issue40160] documentation example of os.walk should be less
 destructive
In-Reply-To: <1585859689.83.0.950657489634.issue40160@roundup.psfhosted.org>
Message-ID: <1585918490.58.0.856453778593.issue40160@roundup.psfhosted.org>


John Taylor <johntaylor at gmail.com> added the comment:

I would prefer an example that does not actually modify the file system.  Is there any way this could be achieved, yet still demonstrate why topdown=False is necessary?

----------

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

From report at bugs.python.org  Fri Apr  3 09:09:32 2020
From: report at bugs.python.org (Eryk Sun)
Date: Fri, 03 Apr 2020 13:09:32 +0000
Subject: [issue40143] shutil.rmtree will frequently fail on Windows under
 heavy load due to racy deletion
In-Reply-To: <1585779323.08.0.697022705599.issue40143@roundup.psfhosted.org>
Message-ID: <1585919372.82.0.0144022466097.issue40143@roundup.psfhosted.org>


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

> 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.

Commonly, WINAPI DeleteFileW and RemoveDirectoryW unlink the target file or directory synchronously. There are cases such as a watched directory and malware scanners that can make deleting asynchronous, but it's unlike the above characterization. It's not like the delete operation gets queued by the filesystem for the system to get around to sometime later.

Deleting or renaming a filesystem file/directory begins with creating a File object that's granted delete access. This is the first hurdle, since all existing File objects for a file have to share data access, including read/execute, write/append, and delete/rename access. Sharing delete/rename access is uncommon, and trying to delete an open file fails with ERROR_SHARING_VIOLATION (32).

If the caller has a handle with delete access, the next hurdle is being allowed to set the delete disposition on the underlying file/link control block (FCB/LCB) in the filesystem. This request will be denied with ERROR_ACCESS_DENIED (5) if the file is flagged as readonly or is currently memory-mapped as data or image. In these cases, a file can still be renamed within the filesystem, which is useful if there is a known destination path.

Assuming that setting the FCB/LCB delete disposition succeeds, then, with classic Windows delete semantics (as opposed to POSIX semantics in available in Windows 10), the file will be unlinked when the last File object that references the FCB/LCB gets cleaned up. This in turn occurs when the last handle for the last File object gets closed. 

WINAPI CloseHandle calls the NtClose system function, which synchronously calls a kernel object's close method, if implemented. A File object has a close method that, if it's the last handle for the object in the system, synchronously calls the filesystem device stack with an IRP_MJ_CLEANUP request. You can see how a filesystem cleanup function works in the source of the fastfat sample driver [1]. Pay attention to blocks in FatCommonCleanup that check the flag FCB_STATE_DELETE_ON_CLOSE in the UserDirectoryOpen and UserFileOpen cases. Note that even if the cleanup function were to complete asynchronously with STATUS_PENDING, the close method of the File object itself waits for completion. So the bases are covered to ensure deleting works synchronously in the common case when a file is referenced only by the handle that's used to delete it. This excludes the cases of pre-existing references that share delete access and implicit interference from malware scanners that inject themselves into the filesystem device stack.

In Windows 10, NTFS supports POSIX delete semantics [2], i.e. FILE_DISPOSITION_DELETE | FILE_DISPOSITION_POSIX_SEMANTICS. In this case, a delete request still has to pass the hurdles of the file sharing mode, readonly flag, and data/image file mappings. What changes is that the file will be unlinked as soon as the deleting handle is closed. Existing opens can continue to access data in the file. 

DeleteFileW in Windows 10 first tries to use a POSIX delete, though this is still undocumented. If a POSIX delete fails (e.g. it's a FAT32 filesystem), DeleteFileW falls back on a classic delete. 

RemoveDirectoryW is limited to a classic delete in Windows 10, so it's subject to race conditions with watched directories. In particular, Explorer keeps directories open to watch for changes. It shares delete access, which allows RemoveDirectoryW to successfully set the delete disposition of a watched directory. In turn, when a watch fails when the delete disposition is set, Explorer immediately closes its handle. This unlinks the directory, but it's a race condition.

When I have time, I'll check whether NTFS supports POSIX delete semantics on directories -- by directly calling NtSetInformationFile: FileDispositionInformationEx. If it does, then probably a future version of Windows will try to use a POSIX delete in RemoveDirectoryW, just as DeleteFileW current does. That will eliminate the problem with watched directories -- at least on the system volume (C:), which is required to use NTFS.

[1]: https://github.com/microsoft/Windows-driver-samples/blob/6c1981b8504329521343ad00f32daa847fa6083a/filesys/fastfat/cleanup.c#L47
[2]: https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/ntddk/ns-ntddk-_file_disposition_information_ex

----------
nosy: +eryksun

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

From report at bugs.python.org  Fri Apr  3 10:38:35 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 03 Apr 2020 14:38:35 +0000
Subject: [issue40112] AIX: xlc - default path changed and no longer recognized
In-Reply-To: <1585567095.85.0.705098258477.issue40112@roundup.psfhosted.org>
Message-ID: <1585924715.63.0.218259402723.issue40112@roundup.psfhosted.org>


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


New changeset 76db37b1d37a9daadd9e5b320f2d5a53cd1352ec by Michael Felt in branch 'master':
bpo-40112: distutils test_search_cpp: Fix logic to determine if C compiler is xlc on AIX (GH-19225)
https://github.com/python/cpython/commit/76db37b1d37a9daadd9e5b320f2d5a53cd1352ec


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

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

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: [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:46:07 2020
From: report at bugs.python.org (Konrad Borowski)
Date: Fri, 03 Apr 2020 14:46:07 +0000
Subject: [issue40171] Attempting to import inaccessible package imports an
 empty package
In-Reply-To: <1585924900.04.0.815860911425.issue40171@roundup.psfhosted.org>
Message-ID: <1585925167.41.0.600677330488.issue40171@roundup.psfhosted.org>


Konrad Borowski <konrad at borowski.pw> added the comment:

The attached example works on Python 2, but it breaks with Python 3. This may be a regression.

----------

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

From report at bugs.python.org  Fri Apr  3 10:48:11 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 03 Apr 2020 14:48:11 +0000
Subject: [issue40112] AIX: xlc - default path changed and no longer recognized
In-Reply-To: <1585567095.85.0.705098258477.issue40112@roundup.psfhosted.org>
Message-ID: <1585925291.68.0.613582990815.issue40112@roundup.psfhosted.org>


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


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

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

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: [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 10:59:12 2020
From: report at bugs.python.org (mzr)
Date: Fri, 03 Apr 2020 14:59:12 +0000
Subject: [issue40105] Updating zip comment doesn't truncate the zip file
In-Reply-To: <1585514903.71.0.609611507951.issue40105@roundup.psfhosted.org>
Message-ID: <1585925952.83.0.192463652961.issue40105@roundup.psfhosted.org>


Change by mzr <mzr4141 at gmail.com>:


----------
nosy: +mzr

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

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: [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:19:26 2020
From: report at bugs.python.org (Yudi)
Date: Fri, 03 Apr 2020 15:19:26 +0000
Subject: [issue40172] ZipInfo corrupts file names in some old zip archives
In-Reply-To: <1585925740.74.0.493426565247.issue40172@roundup.psfhosted.org>
Message-ID: <1585927166.34.0.14682111595.issue40172@roundup.psfhosted.org>


Change by Yudi <yudilevi at gmail.com>:


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

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

From report at bugs.python.org  Fri Apr  3 11:20:38 2020
From: report at bugs.python.org (Yudi)
Date: Fri, 03 Apr 2020 15:20:38 +0000
Subject: [issue40105] Updating zip comment doesn't truncate the zip file
In-Reply-To: <1585514903.71.0.609611507951.issue40105@roundup.psfhosted.org>
Message-ID: <1585927238.75.0.705413236413.issue40105@roundup.psfhosted.org>


Change by Yudi <yudilevi at gmail.com>:


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

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

From report at bugs.python.org  Fri Apr  3 11:30:10 2020
From: report at bugs.python.org (=?utf-8?b?SsOpcsO0bWU=?=)
Date: Fri, 03 Apr 2020 15:30:10 +0000
Subject: [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: [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 11:43:22 2020
From: report at bugs.python.org (nergall2)
Date: Fri, 03 Apr 2020 15:43:22 +0000
Subject: [issue40175] Add support for removing zip entry in ZipInfo
In-Reply-To: <1585928302.7.0.507906192941.issue40175@roundup.psfhosted.org>
Message-ID: <1585928602.63.0.956638590401.issue40175@roundup.psfhosted.org>


Change by nergall2 <yudilevi at gmail.com>:


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

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

From report at bugs.python.org  Fri Apr  3 11:52:41 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Fri, 03 Apr 2020 15:52:41 +0000
Subject: [issue40149] test_threading leaked [38, 38, 38] references, sum=114
In-Reply-To: <1585792445.62.0.0518463995906.issue40149@roundup.psfhosted.org>
Message-ID: <1585929161.13.0.36773177337.issue40149@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

Running 
from abc import ABCMeta
on the subinterpreter makes same size of leak.

----------

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

From report at bugs.python.org  Fri Apr  3 12:08:10 2020
From: report at bugs.python.org (mzr)
Date: Fri, 03 Apr 2020 16:08:10 +0000
Subject: [issue40105] Updating zip comment doesn't truncate the zip file
In-Reply-To: <1585514903.71.0.609611507951.issue40105@roundup.psfhosted.org>
Message-ID: <1585930090.94.0.00013572880004.issue40105@roundup.psfhosted.org>


Change by mzr <mzr4141 at gmail.com>:


----------
pull_requests: +18700
pull_request: https://github.com/python/cpython/pull/19337

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

From report at bugs.python.org  Fri Apr  3 12:30:36 2020
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 03 Apr 2020 16:30:36 +0000
Subject: [issue40126] Incorrect error handling in unittest.mock
In-Reply-To: <1585670844.45.0.631660598637.issue40126@roundup.psfhosted.org>
Message-ID: <1585931436.85.0.878605138388.issue40126@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch
nosy: +python-dev
nosy_count: 1.0 -> 2.0
pull_requests: +18701
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19338

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

From report at bugs.python.org  Fri Apr  3 12:31:38 2020
From: report at bugs.python.org (Barry McLarnon)
Date: Fri, 03 Apr 2020 16:31:38 +0000
Subject: [issue40126] Incorrect error handling in unittest.mock
In-Reply-To: <1585670844.45.0.631660598637.issue40126@roundup.psfhosted.org>
Message-ID: <1585931498.98.0.593099296208.issue40126@roundup.psfhosted.org>


Barry McLarnon <bmclarnon at hotmail.co.uk> added the comment:

After further investigation, it seems this was fixed in https://github.com/python/cpython/commit/436c2b0d67da68465e709a96daac7340af3a5238

However, this fix was as part of an unrelated changeset and in a different function in 3.8+, and was never rolled back to 3.7 and below. PR opened to add the missing attribute instantiation to 3.7.

----------
nosy:  -python-dev
versions:  -Python 3.8, Python 3.9

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

From report at bugs.python.org  Fri Apr  3 12:36:46 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 03 Apr 2020 16:36:46 +0000
Subject: [issue40131] Zipapp example has parameters in the wrong order
In-Reply-To: <1585697297.66.0.208168236164.issue40131@roundup.psfhosted.org>
Message-ID: <1585931806.22.0.319495589773.issue40131@roundup.psfhosted.org>


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


----------
nosy: +miss-islington
nosy_count: 4.0 -> 5.0
pull_requests: +18703
pull_request: https://github.com/python/cpython/pull/19339

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

From report at bugs.python.org  Fri Apr  3 12:36:42 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 03 Apr 2020 16:36:42 +0000
Subject: [issue40131] Zipapp example has parameters in the wrong order
In-Reply-To: <1585697297.66.0.208168236164.issue40131@roundup.psfhosted.org>
Message-ID: <1585931802.56.0.465701801351.issue40131@roundup.psfhosted.org>


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


New changeset bd6a4c3d72828d3d0e13922e165998539d24f8bc by Zackery Spytz in branch 'master':
bpo-40131: Fix source and target order in zipapp example (GH-19290)
https://github.com/python/cpython/commit/bd6a4c3d72828d3d0e13922e165998539d24f8bc


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

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

From report at bugs.python.org  Fri Apr  3 12:36:52 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 03 Apr 2020 16:36:52 +0000
Subject: [issue40131] Zipapp example has parameters in the wrong order
In-Reply-To: <1585697297.66.0.208168236164.issue40131@roundup.psfhosted.org>
Message-ID: <1585931812.8.0.0607677242111.issue40131@roundup.psfhosted.org>


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


----------
pull_requests: +18704
pull_request: https://github.com/python/cpython/pull/19340

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

From report at bugs.python.org  Fri Apr  3 13:02:10 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Fri, 03 Apr 2020 17:02:10 +0000
Subject: [issue39537] Change line number table format
In-Reply-To: <1580724394.63.0.487397350613.issue39537@roundup.psfhosted.org>
Message-ID: <1585933330.26.0.155262459369.issue39537@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
nosy: +corona10

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

From report at bugs.python.org  Fri Apr  3 13:14:02 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 03 Apr 2020 17:14:02 +0000
Subject: [issue40131] Zipapp example has parameters in the wrong order
In-Reply-To: <1585697297.66.0.208168236164.issue40131@roundup.psfhosted.org>
Message-ID: <1585934042.41.0.422646076629.issue40131@roundup.psfhosted.org>


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


New changeset e6783981df6ae5c63f73be67cc41b1350bc0fcc6 by Miss Islington (bot) in branch '3.8':
bpo-40131: Fix source and target order in zipapp example (GH-19290) (GH-19339)
https://github.com/python/cpython/commit/e6783981df6ae5c63f73be67cc41b1350bc0fcc6


----------

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

From report at bugs.python.org  Fri Apr  3 13:14:20 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 03 Apr 2020 17:14:20 +0000
Subject: [issue40131] Zipapp example has parameters in the wrong order
In-Reply-To: <1585697297.66.0.208168236164.issue40131@roundup.psfhosted.org>
Message-ID: <1585934060.16.0.534532450277.issue40131@roundup.psfhosted.org>


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


New changeset d19162fe5b2aba48a94278baa0f569fc42932072 by Miss Islington (bot) in branch '3.7':
bpo-40131: Fix source and target order in zipapp example (GH-19290) (GH-19340)
https://github.com/python/cpython/commit/d19162fe5b2aba48a94278baa0f569fc42932072


----------

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

From report at bugs.python.org  Fri Apr  3 13:18:29 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 03 Apr 2020 17:18:29 +0000
Subject: [issue40131] Zipapp example has parameters in the wrong order
In-Reply-To: <1585697297.66.0.208168236164.issue40131@roundup.psfhosted.org>
Message-ID: <1585934309.74.0.229289228564.issue40131@roundup.psfhosted.org>


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

Thanks Leron for the report. Thanks Zackery for the patch.

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

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

From report at bugs.python.org  Fri Apr  3 13:38:26 2020
From: report at bugs.python.org (hai shi)
Date: Fri, 03 Apr 2020 17:38:26 +0000
Subject: [issue40077] Convert static types to PyType_FromSpec()
In-Reply-To: <1585238684.65.0.246012172449.issue40077@roundup.psfhosted.org>
Message-ID: <1585935506.87.0.124175611723.issue40077@roundup.psfhosted.org>


Change by hai shi <shihai1991 at 126.com>:


----------
pull_requests: +18705
pull_request: https://github.com/python/cpython/pull/19341

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

From report at bugs.python.org  Fri Apr  3 13:40:35 2020
From: report at bugs.python.org (Barney Gale)
Date: Fri, 03 Apr 2020 17:40:35 +0000
Subject: [issue40038] pathlib: remove partial support for preserving accessor
 when modifying a path
In-Reply-To: <1584854130.01.0.225016964026.issue40038@roundup.psfhosted.org>
Message-ID: <1585935635.18.0.744868721659.issue40038@roundup.psfhosted.org>


Change by Barney Gale <barney.gale at gmail.com>:


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

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

From report at bugs.python.org  Fri Apr  3 13:42:39 2020
From: report at bugs.python.org (Chris Martinez)
Date: Fri, 03 Apr 2020 17:42:39 +0000
Subject: [issue40158] MSBuild Extensions in CPython NuGet Package has Bad
 Expression
In-Reply-To: <1585850431.84.0.195210252651.issue40158@roundup.psfhosted.org>
Message-ID: <1585935759.61.0.115514340523.issue40158@roundup.psfhosted.org>


Change by Chris Martinez <sydefekt at hotmail.com>:


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

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

From report at bugs.python.org  Fri Apr  3 13:49:13 2020
From: report at bugs.python.org (hai shi)
Date: Fri, 03 Apr 2020 17:49:13 +0000
Subject: [issue40077] Convert static types to PyType_FromSpec()
In-Reply-To: <1585238684.65.0.246012172449.issue40077@roundup.psfhosted.org>
Message-ID: <1585936153.96.0.135425316751.issue40077@roundup.psfhosted.org>


Change by hai shi <shihai1991 at 126.com>:


----------
pull_requests: +18708
pull_request: https://github.com/python/cpython/pull/19344

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

From report at bugs.python.org  Fri Apr  3 13:49:29 2020
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 03 Apr 2020 17:49:29 +0000
Subject: [issue40174] HAVE_CLOCK_GETTIME not repected in pytime.c
In-Reply-To: <1585927809.98.0.29079570836.issue40174@roundup.psfhosted.org>
Message-ID: <1585936169.03.0.885653036883.issue40174@roundup.psfhosted.org>


Benjamin Peterson <benjamin at python.org> added the comment:

Does this cause a problem? At this point, it might be preferable to just assume clock_gettime exists on POSIX systems.

----------
nosy: +benjamin.peterson

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

From report at bugs.python.org  Fri Apr  3 13:58:06 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 03 Apr 2020 17:58:06 +0000
Subject: [issue40174] HAVE_CLOCK_GETTIME not repected in pytime.c
In-Reply-To: <1585927809.98.0.29079570836.issue40174@roundup.psfhosted.org>
Message-ID: <1585936686.17.0.534194536487.issue40174@roundup.psfhosted.org>


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


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

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

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: [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 14:04:12 2020
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 03 Apr 2020 18:04:12 +0000
Subject: [issue39576] Surprising MemoryError in `decimal` with MAX_PREC
In-Reply-To: <1581046760.48.0.443155322154.issue39576@roundup.psfhosted.org>
Message-ID: <1585937052.4.0.646503875863.issue39576@roundup.psfhosted.org>


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

Has anything emerged xlc-wise? Traceback, does it work --without-pymalloc?

I have the feeling that (in many OSS projects) the more complex xlc
issues never get resolved after the initial report.

So I'm contemplating to do the same as 

   https://devhub.vr.rwth-aachen.de/soehrl/arbor/commit/775fe80796c717da4ed61e1cb7ace27268afc965

and disable the xlc build for _decimal.

----------

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

From report at bugs.python.org  Fri Apr  3 14:22:21 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 03 Apr 2020 18:22:21 +0000
Subject: [issue39943] Meta: Clean up various issues in C internals
In-Reply-To: <1583983387.49.0.277830283994.issue39943@roundup.psfhosted.org>
Message-ID: <1585938141.1.0.552892079563.issue39943@roundup.psfhosted.org>


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


----------
pull_requests: +18709
pull_request: https://github.com/python/cpython/pull/19345

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

From report at bugs.python.org  Fri Apr  3 14:37:31 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Fri, 03 Apr 2020 18:37:31 +0000
Subject: [issue40176] unterminated string literal tokenization error messages
 could be better
In-Reply-To: <1585936724.82.0.54480834244.issue40176@roundup.psfhosted.org>
Message-ID: <1585939051.05.0.64846714658.issue40176@roundup.psfhosted.org>


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


----------
keywords: +patch
nosy: +BTaskaya
nosy_count: 1.0 -> 2.0
pull_requests: +18710
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19346

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

From report at bugs.python.org  Fri Apr  3 14:54:47 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 03 Apr 2020 18:54:47 +0000
Subject: [issue39576] Surprising MemoryError in `decimal` with MAX_PREC
In-Reply-To: <1581046760.48.0.443155322154.issue39576@roundup.psfhosted.org>
Message-ID: <1585940087.8.0.960250762047.issue39576@roundup.psfhosted.org>


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

> Traceback, does it work --without-pymalloc?

No, it does also not work with `--without-pymalloc?`.

> Has anything emerged xlc-wise?

Not for now, I keep investigating and I may try to contact
IBM about this, but at this stage, I am getting more confident
that this is a bug in xlc or something going on with the platform
or the libC implementation.

I am currently chasing something weird that I saw while investigating
regarding too big malloc() calls and the data segment size on AIX that
produces a similar hang.

----------

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

From report at bugs.python.org  Fri Apr  3 14:58:02 2020
From: report at bugs.python.org (Andy Lester)
Date: Fri, 03 Apr 2020 18:58:02 +0000
Subject: [issue40170] [C API] Make PyTypeObject structure an opaque structure
 in the public C API
In-Reply-To: <1585915023.07.0.846808236133.issue40170@roundup.psfhosted.org>
Message-ID: <1585940282.47.0.203910263074.issue40170@roundup.psfhosted.org>


Change by Andy Lester <andy at petdance.com>:


----------
nosy: +petdance

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

From report at bugs.python.org  Fri Apr  3 15:14:18 2020
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 03 Apr 2020 19:14:18 +0000
Subject: [issue36541] Make lib2to3 grammar better match Python,
 support the := walrus
In-Reply-To: <1554514880.92.0.277848417721.issue36541@roundup.psfhosted.org>
Message-ID: <1585941258.91.0.888578537266.issue36541@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:


New changeset 96c5f5a3a3fabf43e8114d0dbc30bed409da1ba6 by Tim Hatch in branch '3.7':
[3.7] bpo-36541: lib2to3: Support named assignment expressions (GH-12702) (GH-19317)
https://github.com/python/cpython/commit/96c5f5a3a3fabf43e8114d0dbc30bed409da1ba6


----------

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

From report at bugs.python.org  Fri Apr  3 15:18:17 2020
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 03 Apr 2020 19:18:17 +0000
Subject: [issue36541] Make lib2to3 grammar better match Python,
 support the := walrus
In-Reply-To: <1554514880.92.0.277848417721.issue36541@roundup.psfhosted.org>
Message-ID: <1585941497.62.0.0636681071259.issue36541@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:

master/3.9 changeset:
https://github.com/python/cpython/commit/3c3aa4516c70753de06bb142b6793d01330fcf0f

3.8 changeset: https://github.com/python/cpython/commit/1098671e4e5ec1513247f05598158eaa3428c5be

----------

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

From report at bugs.python.org  Fri Apr  3 15:18:58 2020
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 03 Apr 2020 19:18:58 +0000
Subject: [issue36541] Make lib2to3 grammar better match Python,
 support the := walrus
In-Reply-To: <1554514880.92.0.277848417721.issue36541@roundup.psfhosted.org>
Message-ID: <1585941538.02.0.259893090223.issue36541@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:

Support for `:=` is in, are we still lacking `f(**not x)` support?

----------

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

From report at bugs.python.org  Fri Apr  3 15:37:20 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 03 Apr 2020 19:37:20 +0000
Subject: [issue40147] Move checking for duplicated keywords to the compiler
In-Reply-To: <1585786944.89.0.491246758826.issue40147@roundup.psfhosted.org>
Message-ID: <1585942640.47.0.51053393644.issue40147@roundup.psfhosted.org>


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


New changeset 254ec783411d9d16e51f1116f98918be2ef0e884 by Pablo Galindo in branch 'master':
bpo-40147: Move the check for duplicate keywords to the compiler (GH-19289)
https://github.com/python/cpython/commit/254ec783411d9d16e51f1116f98918be2ef0e884


----------

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

From report at bugs.python.org  Fri Apr  3 15:40:31 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 03 Apr 2020 19:40:31 +0000
Subject: [issue40141] Add line and column information for keywords in the AST
In-Reply-To: <1585774156.85.0.46549854345.issue40141@roundup.psfhosted.org>
Message-ID: <1585942831.72.0.942664585333.issue40141@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
pull_requests: +18711
pull_request: https://github.com/python/cpython/pull/19348

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

From report at bugs.python.org  Fri Apr  3 15:42:15 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 03 Apr 2020 19:42:15 +0000
Subject: [issue40147] Move checking for duplicated keywords to the compiler
In-Reply-To: <1585786944.89.0.491246758826.issue40147@roundup.psfhosted.org>
Message-ID: <1585942935.15.0.608986560774.issue40147@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


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

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

From report at bugs.python.org  Fri Apr  3 16:02:33 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 03 Apr 2020 20:02:33 +0000
Subject: [issue40141] Add line and column information for keywords in the AST
In-Reply-To: <1585774156.85.0.46549854345.issue40141@roundup.psfhosted.org>
Message-ID: <1585944153.52.0.00508056451722.issue40141@roundup.psfhosted.org>


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


New changeset 40cf35c5b070b3f33aae58a996fea0e8291a8616 by Pablo Galindo in branch 'master':
bpo-40141: Include the value in the column position for keyword AST nodes (GH-19348)
https://github.com/python/cpython/commit/40cf35c5b070b3f33aae58a996fea0e8291a8616


----------

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

From report at bugs.python.org  Fri Apr  3 16:03:58 2020
From: report at bugs.python.org (Steve Dower)
Date: Fri, 03 Apr 2020 20:03:58 +0000
Subject: [issue40158] MSBuild Extensions in CPython NuGet Package has Bad
 Expression
In-Reply-To: <1585850431.84.0.195210252651.issue40158@roundup.psfhosted.org>
Message-ID: <1585944238.1.0.226668993969.issue40158@roundup.psfhosted.org>


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


New changeset 6e623ff9d251e0ce86e9b18a01bfd6f067079d7a by Chris Martinez in branch 'master':
bpo-40158: Fix CPython MSBuild Properties in NuGet Package (GH-19343)
https://github.com/python/cpython/commit/6e623ff9d251e0ce86e9b18a01bfd6f067079d7a


----------

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

From report at bugs.python.org  Fri Apr  3 16:04:08 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 03 Apr 2020 20:04:08 +0000
Subject: [issue40158] MSBuild Extensions in CPython NuGet Package has Bad
 Expression
In-Reply-To: <1585850431.84.0.195210252651.issue40158@roundup.psfhosted.org>
Message-ID: <1585944248.71.0.338345976059.issue40158@roundup.psfhosted.org>


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


----------
nosy: +miss-islington
nosy_count: 7.0 -> 8.0
pull_requests: +18712
pull_request: https://github.com/python/cpython/pull/19349

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

From report at bugs.python.org  Fri Apr  3 16:04:16 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 03 Apr 2020 20:04:16 +0000
Subject: [issue40158] MSBuild Extensions in CPython NuGet Package has Bad
 Expression
In-Reply-To: <1585850431.84.0.195210252651.issue40158@roundup.psfhosted.org>
Message-ID: <1585944256.29.0.861630970893.issue40158@roundup.psfhosted.org>


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


----------
pull_requests: +18713
pull_request: https://github.com/python/cpython/pull/19350

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

From report at bugs.python.org  Fri Apr  3 16:05:25 2020
From: report at bugs.python.org (Steve Dower)
Date: Fri, 03 Apr 2020 20:05:25 +0000
Subject: [issue40158] MSBuild Extensions in CPython NuGet Package has Bad
 Expression
In-Reply-To: <1585850431.84.0.195210252651.issue40158@roundup.psfhosted.org>
Message-ID: <1585944325.13.0.813310119128.issue40158@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


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

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

From report at bugs.python.org  Fri Apr  3 16:10:40 2020
From: report at bugs.python.org (Barry McLarnon)
Date: Fri, 03 Apr 2020 20:10:40 +0000
Subject: [issue40126] Incorrect error handling in unittest.mock
In-Reply-To: <1585670844.45.0.631660598637.issue40126@roundup.psfhosted.org>
Message-ID: <1585944640.91.0.486695080601.issue40126@roundup.psfhosted.org>


Change by Barry McLarnon <bmclarnon at hotmail.co.uk>:


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

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

From report at bugs.python.org  Fri Apr  3 16:22:59 2020
From: report at bugs.python.org (Ammar Askar)
Date: Fri, 03 Apr 2020 20:22:59 +0000
Subject: [issue40118] os.stat in linux shows the wrong inode
In-Reply-To: <1585582528.02.0.848256815415.issue40118@roundup.psfhosted.org>
Message-ID: <1585945379.76.0.368946701747.issue40118@roundup.psfhosted.org>


Ammar Askar <ammar at ammaraskar.com> added the comment:

As noted in the documentation for os.stat (https://docs.python.org/3.9/library/os.html#os.stat):

> This function normally follows symlinks; to stat a symlink add the argument follow_symlinks=False, or use lstat().

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

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

From report at bugs.python.org  Fri Apr  3 17:19:56 2020
From: report at bugs.python.org (Tim Peters)
Date: Fri, 03 Apr 2020 21:19:56 +0000
Subject: [issue40110] multiprocessing.Pool.imap() should be lazy
In-Reply-To: <1585541187.46.0.606629490552.issue40110@roundup.psfhosted.org>
Message-ID: <1585948796.37.0.66822482346.issue40110@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

Whenever there's parallel processing with communication, there's always the potential for producers to pump out data faster than consumers can process them.  But builtin primitives generally don't try to address that directly.  They don't - and can't - know enough about the application's intent.

Instead, as I briefly alluded to earlier, mediation (when needed) is frequently accomplished by users by explicit use of bounded queues.  When process A produces data for process B, it sends the data over a bounded queue.  Nothing is done to slow A down, except that when a bounded queue is full, an attempt to enqueue a new piece of data blocks until B removes some old data from the queue.  That's a dead easy, painless, and foolproof way to limit A's speed to the rate at which B can consume data.  Nothing in A's logic changes - it's the communication channel that applies the brakes.

I'll attach `pipe.py` to illustrate.  It constructs a 10-stage pipeline.  The first process in the chain *could* produce data at a ferocious rate - but the bounded queue connecting it to the next process slows it to the rate at which the second process runs.  All the other processes in the pipeline grab data from the preceding process via a bounded queue, work on it for a second (just a sleep(1) here), then enqueue the result for the next process in the pipeline.  The main program loops, pulling data off the final process as fast as results show up.

So, if you run it, you'll see that new data is produced once per second, then when the pipeline is full final results are delivered once per second.  When the first process is done, results continue to be pulled off one per second until the pipeline is drained.

The queues here have maximum size 1, just to show that it works.  In practice, a larger bound is usually used, to allow for that processes in real life often take varying amounts of time depending on the data they're currently processing.  Letting a handful of work items queue up keeps processes busy - if processing some piece of data goes especially fast, fine, there may be more in the input queue waiting to go immediately.  How many is "a handful"?  Again, that's something that can't in general be guessed - the programmer has to apply their best judgment based on their deep knowledge of intended application behavior.

Just to be cute ;-) , the code here uses imap() to start the 10 worker processes.  The result of calling imap() is never used, it's just an easy way to apply a Pool to the task.  And it absolutely relies on that imap() consumes its iterable (range(NSTAGES)) as fast as it can, to get the NSTAGES=10 worker processes running.

----------
Added file: https://bugs.python.org/file49032/pipe.py

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

From report at bugs.python.org  Fri Apr  3 17:43:37 2020
From: report at bugs.python.org (Alexander Riccio)
Date: Fri, 03 Apr 2020 21:43:37 +0000
Subject: [issue40145] Pyshellext room for binary size improvement
In-Reply-To: <1585781037.54.0.0844996141167.issue40145@roundup.psfhosted.org>
Message-ID: <1585950217.81.0.411500472109.issue40145@roundup.psfhosted.org>


Alexander Riccio <test35965 at gmail.com> added the comment:

Ahh, ok. Even though I question the usefulness of manually maintaining MSBuild files instead of something like CMake, I can work with that. Is there a preferred way to do it? It looks like I can do a Condition="'$(Configuration)|$(Platform)'=='Release|x64'" and merge a bunch of things under each one.

----------

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

From report at bugs.python.org  Fri Apr  3 17:44:56 2020
From: report at bugs.python.org (Alexander Riccio)
Date: Fri, 03 Apr 2020 21:44:56 +0000
Subject: [issue40145] Pyshellext room for binary size improvement
In-Reply-To: <1585781037.54.0.0844996141167.issue40145@roundup.psfhosted.org>
Message-ID: <1585950296.89.0.519293834307.issue40145@roundup.psfhosted.org>


Alexander Riccio <test35965 at gmail.com> added the comment:

Oh, uh, also, do you prefer I add a commit or a new branch & PR?

----------

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

From report at bugs.python.org  Fri Apr  3 17:50:15 2020
From: report at bugs.python.org (Steve Dower)
Date: Fri, 03 Apr 2020 21:50:15 +0000
Subject: [issue40164] Upgrade Windows and macOS installer builds to OpenSSL
 1.1.1f
In-Reply-To: <1585875388.92.0.251240838882.issue40164@roundup.psfhosted.org>
Message-ID: <1585950615.79.0.144043875425.issue40164@roundup.psfhosted.org>


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

I've pushed new binaries for OpenSSL 1.1.1f on Windows. I'll try and to the rest over the weekend, but if someone else wants to do the PCbuild PR feel free.

----------

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

From report at bugs.python.org  Fri Apr  3 17:48:51 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 03 Apr 2020 21:48:51 +0000
Subject: [issue40160] documentation example of os.walk should be less
 destructive
In-Reply-To: <1585859689.83.0.950657489634.issue40160@roundup.psfhosted.org>
Message-ID: <1585950531.07.0.0644342193106.issue40160@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

One possibility is a gathering cumulative directory statistics that include totals from all descendants (i.e. how many bytes of files would you save by removing the directory with rm -rf).

Outside of aggregating statistics, the normal reason to use topdown=False is when paths are being mutated.

----------

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

From report at bugs.python.org  Fri Apr  3 17:50:50 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 03 Apr 2020 21:50:50 +0000
Subject: [issue40126] Incorrect error handling in unittest.mock
In-Reply-To: <1585670844.45.0.631660598637.issue40126@roundup.psfhosted.org>
Message-ID: <1585950650.33.0.759872578858.issue40126@roundup.psfhosted.org>


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

I think that the current code is not correct. __exit__ should not be called if __enter__ is failed. If some __enter__ implementation calls other __enter__s it should manually call corresponding __exit__s.

----------
nosy: +michael.foord, ncoghlan, serhiy.storchaka
versions: +Python 3.8, Python 3.9 -Python 3.5, Python 3.6

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

From report at bugs.python.org  Fri Apr  3 17:52:23 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 03 Apr 2020 21:52:23 +0000
Subject: [issue40126] Incorrect error handling in unittest.mock
In-Reply-To: <1585670844.45.0.631660598637.issue40126@roundup.psfhosted.org>
Message-ID: <1585950743.03.0.00437331107846.issue40126@roundup.psfhosted.org>


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


----------
pull_requests: +18714
pull_request: https://github.com/python/cpython/pull/19351

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

From report at bugs.python.org  Fri Apr  3 18:00:20 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 03 Apr 2020 22:00:20 +0000
Subject: [issue40160] documentation example of os.walk should be less
 destructive
In-Reply-To: <1585859689.83.0.950657489634.issue40160@roundup.psfhosted.org>
Message-ID: <1585951220.87.0.705732468649.issue40160@roundup.psfhosted.org>


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

I do not think there is clearer example of topdown=False than recursive remove.

If you think that this example is destructive, consider how destructive is any possible example for shutil.rmtree()!

----------
nosy: +serhiy.storchaka

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

From report at bugs.python.org  Fri Apr  3 18:07:34 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 03 Apr 2020 22:07:34 +0000
Subject: [issue40176] unterminated string literal tokenization error messages
 could be better
In-Reply-To: <1585936724.82.0.54480834244.issue40176@roundup.psfhosted.org>
Message-ID: <1585951654.19.0.956249766021.issue40176@roundup.psfhosted.org>


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

It could be even better. Inside the tokenizer we know where the string literal starts and what quotes it uses. The line and the offset of the *start* of the literal can be set in a SyntaxError.

----------
nosy: +serhiy.storchaka

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

From report at bugs.python.org  Fri Apr  3 18:17:34 2020
From: report at bugs.python.org (Steve Dower)
Date: Fri, 03 Apr 2020 22:17:34 +0000
Subject: [issue40145] Pyshellext room for binary size improvement
In-Reply-To: <1585781037.54.0.0844996141167.issue40145@roundup.psfhosted.org>
Message-ID: <1585952254.76.0.061230659306.issue40145@roundup.psfhosted.org>


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

In general, no settings rely on both Platform AND Configuration, so you likely only need to check one or the other.

Look at PCbuild/pyproject.props for the best examples. IIRC, properties are set assuming Win32/Release, and then we override those that need to be different for either Debug or x64/ARM builds. Any settings that you think are worth applying to all projects can go in this file, while any that are strictly for pyshellext can go in its vcxproj (but using a similar style).

Let's not start a CMake debate here - there are plenty of other issues on here about that. We currently maintain MSBuild files by hand, and it works well.

More commits on the same PR are fine. We squash merge at the end, so the history only remains in the commit message if we need to put it there.

----------

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

From report at bugs.python.org  Fri Apr  3 18:18:32 2020
From: report at bugs.python.org (Steve Dower)
Date: Fri, 03 Apr 2020 22:18:32 +0000
Subject: [issue40158] MSBuild Extensions in CPython NuGet Package has Bad
 Expression
In-Reply-To: <1585850431.84.0.195210252651.issue40158@roundup.psfhosted.org>
Message-ID: <1585952312.69.0.680490052628.issue40158@roundup.psfhosted.org>


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


New changeset 7f70456b92c9ff0bcc4df2a2cec213ab2a897591 by Miss Islington (bot) in branch '3.7':
bpo-40158: Fix CPython MSBuild Properties in NuGet Package (GH-19343)
https://github.com/python/cpython/commit/7f70456b92c9ff0bcc4df2a2cec213ab2a897591


----------

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

From report at bugs.python.org  Fri Apr  3 18:20:16 2020
From: report at bugs.python.org (Steve Dower)
Date: Fri, 03 Apr 2020 22:20:16 +0000
Subject: [issue40158] MSBuild Extensions in CPython NuGet Package has Bad
 Expression
In-Reply-To: <1585850431.84.0.195210252651.issue40158@roundup.psfhosted.org>
Message-ID: <1585952416.33.0.379059892694.issue40158@roundup.psfhosted.org>


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


New changeset e6685ad05385f8cb492e8e1c7c07889a94517f55 by Miss Islington (bot) in branch '3.8':
bpo-40158: Fix CPython MSBuild Properties in NuGet Package (GH-19343)
https://github.com/python/cpython/commit/e6685ad05385f8cb492e8e1c7c07889a94517f55


----------

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

From report at bugs.python.org  Fri Apr  3 20:56:42 2020
From: report at bugs.python.org (Kyle Stanley)
Date: Sat, 04 Apr 2020 00:56:42 +0000
Subject: [issue40175] Add support for removing zip entry in ZipInfo
In-Reply-To: <1585928302.7.0.507906192941.issue40175@roundup.psfhosted.org>
Message-ID: <1585961802.66.0.491339504935.issue40175@roundup.psfhosted.org>


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

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

This public API enhancement seems substantial enough to warrant a python-ideas ML thread or topic in the "Ideas" category of discuss.python.org. It would help to demonstrate some real-world examples where one may want to programmatically remove entries.

Also, added zipfile maintainers to the nosy list.

----------
nosy: +aeros, alanmcintyre, serhiy.storchaka, twouters

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

From report at bugs.python.org  Fri Apr  3 21:16:46 2020
From: report at bugs.python.org (Kyle Stanley)
Date: Sat, 04 Apr 2020 01:16:46 +0000
Subject: [issue40160] documentation example of os.walk should be less
 destructive
In-Reply-To: <1585859689.83.0.950657489634.issue40160@roundup.psfhosted.org>
Message-ID: <1585963006.36.0.073094413487.issue40160@roundup.psfhosted.org>


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

Serhiy Storchaka wrote:
> I do not think there is clearer example of topdown=False than recursive remove.
>
> If you think that this example is destructive, consider how destructive is any possible example for shutil.rmtree()!

I concur with Serhiy. If the example is changed to just print out the file and directory path, as the PR proposes to do, it seems to defeat the purpose of using `topdown=False` (and the code example) in the first place.

If anything, I would suggest adding succinct comments or a note that very briefly explains how one could see a visual demonstration of what it does without removing any files or directories. For example: ``print(f"os.remove({os.path.join(root, name)})")``.

----------
nosy: +aeros

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

From report at bugs.python.org  Fri Apr  3 22:30:51 2020
From: report at bugs.python.org (John Taylor)
Date: Sat, 04 Apr 2020 02:30:51 +0000
Subject: [issue40160] documentation example of os.walk should be less
 destructive
In-Reply-To: <1585859689.83.0.950657489634.issue40160@roundup.psfhosted.org>
Message-ID: <1585967451.06.0.15118129713.issue40160@roundup.psfhosted.org>


John Taylor <johntaylor at gmail.com> added the comment:

I made the suggested change to just print the os.remove() statements (instead of executing them) and also removed the 'skip news'.

----------

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

From report at bugs.python.org  Fri Apr  3 23:06:05 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 04 Apr 2020 03:06:05 +0000
Subject: [issue38689] IDLE crashes when KeyError is raised during calltip
 generation
In-Reply-To: <1572911156.46.0.933839006151.issue38689@roundup.psfhosted.org>
Message-ID: <1585969565.15.0.352633913238.issue38689@roundup.psfhosted.org>


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


New changeset 52013e5b6d5ca32eef5a3d65ecdf7db89cefc2fd by Tal Einat in branch 'master':
bpo-38689: avoid IDLE hanging when calltip fails getting a signature (GH-17152)
https://github.com/python/cpython/commit/52013e5b6d5ca32eef5a3d65ecdf7db89cefc2fd


----------

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

From report at bugs.python.org  Fri Apr  3 23:06:19 2020
From: report at bugs.python.org (miss-islington)
Date: Sat, 04 Apr 2020 03:06:19 +0000
Subject: [issue38689] IDLE crashes when KeyError is raised during calltip
 generation
In-Reply-To: <1572911156.46.0.933839006151.issue38689@roundup.psfhosted.org>
Message-ID: <1585969579.93.0.711847325431.issue38689@roundup.psfhosted.org>


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


----------
nosy: +miss-islington
nosy_count: 3.0 -> 4.0
pull_requests: +18715
pull_request: https://github.com/python/cpython/pull/19353

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

From report at bugs.python.org  Fri Apr  3 23:06:27 2020
From: report at bugs.python.org (miss-islington)
Date: Sat, 04 Apr 2020 03:06:27 +0000
Subject: [issue38689] IDLE crashes when KeyError is raised during calltip
 generation
In-Reply-To: <1572911156.46.0.933839006151.issue38689@roundup.psfhosted.org>
Message-ID: <1585969587.04.0.54398218457.issue38689@roundup.psfhosted.org>


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


----------
pull_requests: +18716
pull_request: https://github.com/python/cpython/pull/19354

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

From report at bugs.python.org  Fri Apr  3 23:17:20 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 04 Apr 2020 03:17:20 +0000
Subject: [issue40127] Documentation of SSL library
In-Reply-To: <1585672825.27.0.231879770193.issue40127@roundup.psfhosted.org>
Message-ID: <1585970240.71.0.552468382833.issue40127@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions:  -Python 2.7, Python 3.5, Python 3.6

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

From report at bugs.python.org  Fri Apr  3 23:20:10 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 04 Apr 2020 03:20:10 +0000
Subject: [issue40132] Mechanism to control who owns package names on PyPI?
In-Reply-To: <1585731365.14.0.524521872477.issue40132@roundup.psfhosted.org>
Message-ID: <1585970410.64.0.996786912102.issue40132@roundup.psfhosted.org>


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

PyPI is a separate project from CPython and has its own repository, tracker, and developers.

----------
nosy: +terry.reedy
resolution:  -> third party
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Fri Apr  3 23:24:46 2020
From: report at bugs.python.org (miss-islington)
Date: Sat, 04 Apr 2020 03:24:46 +0000
Subject: [issue38689] IDLE crashes when KeyError is raised during calltip
 generation
In-Reply-To: <1572911156.46.0.933839006151.issue38689@roundup.psfhosted.org>
Message-ID: <1585970686.18.0.885317111639.issue38689@roundup.psfhosted.org>


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


New changeset 681044a0ab6c93554ff8d003c7f9fe5fdb0c83ba by Miss Islington (bot) in branch '3.7':
bpo-38689: avoid IDLE hanging when calltip fails getting a signature (GH-17152)
https://github.com/python/cpython/commit/681044a0ab6c93554ff8d003c7f9fe5fdb0c83ba


----------

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

From report at bugs.python.org  Fri Apr  3 23:25:12 2020
From: report at bugs.python.org (miss-islington)
Date: Sat, 04 Apr 2020 03:25:12 +0000
Subject: [issue38689] IDLE crashes when KeyError is raised during calltip
 generation
In-Reply-To: <1572911156.46.0.933839006151.issue38689@roundup.psfhosted.org>
Message-ID: <1585970712.7.0.470717700302.issue38689@roundup.psfhosted.org>


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


New changeset 15337726e5b92976c2815d05c514804e9aa49a8c by Miss Islington (bot) in branch '3.8':
bpo-38689: avoid IDLE hanging when calltip fails getting a signature (GH-17152)
https://github.com/python/cpython/commit/15337726e5b92976c2815d05c514804e9aa49a8c


----------

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

From report at bugs.python.org  Fri Apr  3 23:29:28 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 04 Apr 2020 03:29:28 +0000
Subject: [issue40139] mimetypes module racy
In-Reply-To: <1585764080.54.0.0429329888929.issue40139@roundup.psfhosted.org>
Message-ID: <1585970968.71.0.269857023332.issue40139@roundup.psfhosted.org>


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

3.5.3 is not the most recent 3.5.  Anyway, 3.5 and 3.6 and soon 3.7 only get security patches.  So it needs to be determined if there are failure with 3.8 and 3.9.

----------
nosy: +terry.reedy
versions:  -Python 3.5

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

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: [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  Fri Apr  3 23:44:09 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 04 Apr 2020 03:44:09 +0000
Subject: [issue40177] Python Language Reference Documentation
In-Reply-To: <1585971365.58.0.193657354587.issue40177@roundup.psfhosted.org>
Message-ID: <1585971849.69.0.490177873053.issue40177@roundup.psfhosted.org>


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


----------
nosy: +mark.dickinson, rhettinger, stutzbach

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

From report at bugs.python.org  Fri Apr  3 23:56:15 2020
From: report at bugs.python.org (Alex Gaynor)
Date: Sat, 04 Apr 2020 03:56:15 +0000
Subject: [issue40176] unterminated string literal tokenization error messages
 could be better
In-Reply-To: <1585936724.82.0.54480834244.issue40176@roundup.psfhosted.org>
Message-ID: <1585972575.62.0.438086543603.issue40176@roundup.psfhosted.org>


Alex Gaynor <alex.gaynor at gmail.com> added the comment:

Here's my suggestion:

End of line reached without finding the end of string literal. Are you missing a closing quote?

----------
nosy: +alex

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

From report at bugs.python.org  Sat Apr  4 00:26:22 2020
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 04 Apr 2020 04:26:22 +0000
Subject: [issue40120] Undefined C behavior going beyond end of struct via a
 [1] arrays.
In-Reply-To: <1585602263.71.0.279519604291.issue40120@roundup.psfhosted.org>
Message-ID: <1585974382.07.0.691774737576.issue40120@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:

agreed, being opaque seems ideal.

----------

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

From report at bugs.python.org  Sat Apr  4 00:27:58 2020
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 04 Apr 2020 04:27:58 +0000
Subject: [issue40120] Undefined C behavior going beyond end of struct via a
 [1] arrays.
In-Reply-To: <1585602263.71.0.279519604291.issue40120@roundup.psfhosted.org>
Message-ID: <1585974478.77.0.164201836678.issue40120@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:

PyBytesObject could become a struct that contains a single opaque internal struct.

there is some code out there that references PyBytesObjects internals by field name but my searches across a broad swath of code so far seem to suggest that is so rare this change may be plausible (more research needed).  People are using the PyBytes_ macros and APIs.  yay!

----------

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

From report at bugs.python.org  Sat Apr  4 00:36:27 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Sat, 04 Apr 2020 04:36:27 +0000
Subject: [issue40177] Python Language Reference Documentation
In-Reply-To: <1585971365.58.0.193657354587.issue40177@roundup.psfhosted.org>
Message-ID: <1585974987.8.0.883292583404.issue40177@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

How about this?


"The not-a-number values ``float('NaN')`` and ``decimal.Decimal('NaN')`` are
special. Not-a-number values always compare unordered and unequal to any other value, including themselves. For example, if ``x = float('NaN')``, then ``x == x``, ``3 < x``, and ``x < 3`` are all false, but ``x != x`` is true. This behavior is compliant with the IEEE 754 standard."


Due to technology problems at my end, I cannot submit a PR for this, but this should be an easy issue. If somebody wants to use the text above as a start, please feel free to do so.

----------
nosy: +steven.daprano

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

From report at bugs.python.org  Sat Apr  4 00:38:48 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Sat, 04 Apr 2020 04:38:48 +0000
Subject: [issue40177] Python Language Reference Documentation
In-Reply-To: <1585971365.58.0.193657354587.issue40177@roundup.psfhosted.org>
Message-ID: <1585975128.63.0.238086325087.issue40177@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

Oops, that should be

    ... ``x == x``, ``3 < x``, and ``x > 3`` are all false ...

----------

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

From report at bugs.python.org  Sat Apr  4 00:39:49 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Sat, 04 Apr 2020 04:39:49 +0000
Subject: [issue40177] Python Language Reference Documentation
In-Reply-To: <1585971365.58.0.193657354587.issue40177@roundup.psfhosted.org>
Message-ID: <1585975189.8.0.197748059511.issue40177@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

Oh never mind, I'm just going to slink away now and stop posting corrections when distracted...

----------

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

From report at bugs.python.org  Sat Apr  4 00:50:34 2020
From: report at bugs.python.org (Ammar Askar)
Date: Sat, 04 Apr 2020 04:50:34 +0000
Subject: [issue40176] unterminated string literal tokenization error messages
 could be better
In-Reply-To: <1585936724.82.0.54480834244.issue40176@roundup.psfhosted.org>
Message-ID: <1585975834.32.0.473755850037.issue40176@roundup.psfhosted.org>


Ammar Askar <ammar at ammaraskar.com> added the comment:

Just re-posting this here from the open PR. Rust's handling of this seems nice and beginner friendly:

  error: unterminated double quote string
   --> src/main.rs:2:19
    |
  2 |       let message = "Hello world
    |  ___________________^
  3 | |     println!(message);
  4 | | }
    | |_^

Like Serhiy suggested, it points to the /start/ of the string, rather than the EOL and the message seems nice too.

----------
nosy: +ammar2

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

From report at bugs.python.org  Sat Apr  4 01:28:30 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 04 Apr 2020 05:28:30 +0000
Subject: [issue40126] Incorrect error handling in unittest.mock
In-Reply-To: <1585670844.45.0.631660598637.issue40126@roundup.psfhosted.org>
Message-ID: <1585978110.01.0.148693104462.issue40126@roundup.psfhosted.org>


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


----------
nosy: +cjw296, xtreak

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

From report at bugs.python.org  Sat Apr  4 03:14:55 2020
From: report at bugs.python.org (laike9m)
Date: Sat, 04 Apr 2020 07:14:55 +0000
Subject: [issue40169] `dis.findlabels()` should accept a code object
In-Reply-To: <1585903808.2.0.0835498531407.issue40169@roundup.psfhosted.org>
Message-ID: <1585984495.55.0.569576986035.issue40169@roundup.psfhosted.org>


Change by laike9m <laike9m at gmail.com>:


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

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

From report at bugs.python.org  Sat Apr  4 03:26:38 2020
From: report at bugs.python.org (laike9m)
Date: Sat, 04 Apr 2020 07:26:38 +0000
Subject: [issue40169] `dis.findlabels()` should accept a code object
In-Reply-To: <1585903808.2.0.0835498531407.issue40169@roundup.psfhosted.org>
Message-ID: <1585985198.95.0.105397897475.issue40169@roundup.psfhosted.org>


Change by laike9m <laike9m at gmail.com>:


----------
type: enhancement -> behavior

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

From report at bugs.python.org  Sat Apr  4 04:38:02 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 04 Apr 2020 08:38:02 +0000
Subject: [issue40175] Add support for removing zip entry in ZipInfo
In-Reply-To: <1585928302.7.0.507906192941.issue40175@roundup.psfhosted.org>
Message-ID: <1585989482.12.0.171359232163.issue40175@roundup.psfhosted.org>


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

This is a duplicate of issue700858 and issue6818.

----------

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

From report at bugs.python.org  Sat Apr  4 04:56:32 2020
From: report at bugs.python.org (=?utf-8?b?SsOpcsO0bWU=?=)
Date: Sat, 04 Apr 2020 08:56:32 +0000
Subject: [issue40174] HAVE_CLOCK_GETTIME not repected in pytime.c
In-Reply-To: <1585927809.98.0.29079570836.issue40174@roundup.psfhosted.org>
Message-ID: <1585990592.03.0.996605925038.issue40174@roundup.psfhosted.org>


J?r?me <jerome.hamm at gmail.com> added the comment:

Hold on, this was the case with Python 3.8.2, but I just checked Github and the code is different! I'll have to check again with HEAD, and sorry if it was fixed!

"Drop your panties sir William, I cannot wait till lunchtime".

----------

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

From report at bugs.python.org  Sat Apr  4 05:02:28 2020
From: report at bugs.python.org (Kyle Stanley)
Date: Sat, 04 Apr 2020 09:02:28 +0000
Subject: [issue40175] Add support for removing zip entry in ZipInfo
In-Reply-To: <1585928302.7.0.507906192941.issue40175@roundup.psfhosted.org>
Message-ID: <1585990948.0.0.0666938540006.issue40175@roundup.psfhosted.org>


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

Serhiy Storchaka wrote:
> This is a duplicate of issue700858 and issue6818.

It probably would have been better to mention it in issue6818, but IMO, those issues have been inactive long enough that it's reasonable to re-address the issue. zipfile is not an area of expertise for me though, so I can't say if anything substantial has changed for the arguments against it in issue6818 to no longer apply. That's partly why I suggested python-ideas or discuss.python.org.

----------

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

From report at bugs.python.org  Sat Apr  4 05:33:11 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 04 Apr 2020 09:33:11 +0000
Subject: [issue40177] Python Language Reference Documentation
In-Reply-To: <1585971365.58.0.193657354587.issue40177@roundup.psfhosted.org>
Message-ID: <1585992791.5.0.560032309156.issue40177@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Sat Apr  4 06:14:35 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 04 Apr 2020 10:14:35 +0000
Subject: [issue40175] Add support for removing zip entry in ZipInfo
In-Reply-To: <1585928302.7.0.507906192941.issue40175@roundup.psfhosted.org>
Message-ID: <1585995275.62.0.21948401695.issue40175@roundup.psfhosted.org>


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

There were other issues and discussions about this.

The problem of removing a file from a ZIP archive is similar to the problem of removing a line from a file. It cannot be made efficiently, and it is not even always possible. In some cases it may be better (simpler, more efficient and robust) to copy a file line by line into a new file, skipping particular lines, and the same is true for a ZIP archive. In other cases you can truncate the file or the ZIP archive. Solution that is optimal in one case may be inappropriate in other case.

----------

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

From report at bugs.python.org  Sat Apr  4 06:20:54 2020
From: report at bugs.python.org (nergall2)
Date: Sat, 04 Apr 2020 10:20:54 +0000
Subject: [issue40175] Add support for removing zip entry in ZipInfo
In-Reply-To: <1585928302.7.0.507906192941.issue40175@roundup.psfhosted.org>
Message-ID: <1585995654.66.0.256860151539.issue40175@roundup.psfhosted.org>


nergall2 <yudilevi at gmail.com> added the comment:

Sorry, I didn't see the old issue, let's move the discussion over there -
https://bugs.python.org/issue6818

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

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

From report at bugs.python.org  Sat Apr  4 06:26:54 2020
From: report at bugs.python.org (nergall2)
Date: Sat, 04 Apr 2020 10:26:54 +0000
Subject: [issue6818] remove/delete method for zipfile/tarfile objects
In-Reply-To: <1251866532.69.0.504306670253.issue6818@psf.upfronthosting.co.za>
Message-ID: <1585996014.08.0.840756726993.issue6818@roundup.psfhosted.org>


nergall2 <yudilevi at gmail.com> added the comment:

I wasn't aware of this issue and opened another one which I just closed as a duplicate -
https://bugs.python.org/issue40175

I also submitted a PR for the other one -
https://github.com/python/cpython/pull/19336

The implementation does involve shifting the bytes of the files and updating the offset of each file in the central directory.
I do handle the case in which the central directory order and the order of the actual files in the archive isn't the same simply by sorting the central directory in memory before execution.

The only issue I see here is the fact that if something happens during the process, the archive might get corrupted - but IMO it's worth it.
Many tools provide that functionality (Windows, Total Commander) and as far as I know they do it in place.
In the worst case, it's possible to implement it by creating a temp archive like Serhiy suggested - not too difficult to implement either since it simply requires duplicating the file and operating on it.

----------
nosy: +nergall2

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

From report at bugs.python.org  Sat Apr  4 06:31:04 2020
From: report at bugs.python.org (nergall2)
Date: Sat, 04 Apr 2020 10:31:04 +0000
Subject: [issue6818] remove/delete method for zipfile/tarfile objects
In-Reply-To: <1251866532.69.0.504306670253.issue6818@psf.upfronthosting.co.za>
Message-ID: <1585996264.86.0.0696129081316.issue6818@roundup.psfhosted.org>


Change by nergall2 <yudilevi at gmail.com>:


----------
pull_requests: +18719
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19336

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

From report at bugs.python.org  Sat Apr  4 06:36:04 2020
From: report at bugs.python.org (nergall2)
Date: Sat, 04 Apr 2020 10:36:04 +0000
Subject: [issue6818] remove/delete method for zipfile/tarfile objects
In-Reply-To: <1251866532.69.0.504306670253.issue6818@psf.upfronthosting.co.za>
Message-ID: <1585996564.35.0.365618204703.issue6818@roundup.psfhosted.org>


nergall2 <yudilevi at gmail.com> added the comment:

Closed my initial PR and opened this one instead -
https://github.com/python/cpython/pull/19336

----------

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

From report at bugs.python.org  Sat Apr  4 06:37:50 2020
From: report at bugs.python.org (nergall2)
Date: Sat, 04 Apr 2020 10:37:50 +0000
Subject: [issue6818] remove/delete method for zipfile/tarfile objects
In-Reply-To: <1251866532.69.0.504306670253.issue6818@psf.upfronthosting.co.za>
Message-ID: <1585996670.1.0.509976399624.issue6818@roundup.psfhosted.org>


nergall2 <yudilevi at gmail.com> added the comment:

Sorry, typo, here's the new PR -
https://github.com/python/cpython/pull/19358

----------

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

From report at bugs.python.org  Sat Apr  4 06:40:28 2020
From: report at bugs.python.org (nergall2)
Date: Sat, 04 Apr 2020 10:40:28 +0000
Subject: [issue6818] remove/delete method for zipfile/tarfile objects
In-Reply-To: <1251866532.69.0.504306670253.issue6818@psf.upfronthosting.co.za>
Message-ID: <1585996828.42.0.591129824568.issue6818@roundup.psfhosted.org>


Change by nergall2 <yudilevi at gmail.com>:


----------
pull_requests: +18720
pull_request: https://github.com/python/cpython/pull/19358

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

From report at bugs.python.org  Sat Apr  4 06:43:32 2020
From: report at bugs.python.org (=?utf-8?b?SsOpcsO0bWU=?=)
Date: Sat, 04 Apr 2020 10:43:32 +0000
Subject: [issue40174] HAVE_CLOCK_GETTIME not repected in pytime.c
In-Reply-To: <1585927809.98.0.29079570836.issue40174@roundup.psfhosted.org>
Message-ID: <1585997012.98.0.997921341733.issue40174@roundup.psfhosted.org>


J?r?me <jerome.hamm at gmail.com> added the comment:

Hi, 
OK, I was looking at the wrong line numbers, the problem is still there and as follows.
You might call me a perfectionist, but if HAVE_CLOCK_GETTIME is not defined, the function pytime_fromtimespec is taken out by the preprocessor, but still called  by the function pymonotonic, so python does not compile.
I'm thinking of two ways to go, either stop configure if HAVE_CLOCK_GETTIME is not defined, or rewrite the function differently (I don't know how badly a truly monotonic clock is needed).
It does feel strange to me to partially only honor HAVE_CLOCK_GETTIME.

"With government backing, I could make it very silly"

----------

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

From report at bugs.python.org  Sat Apr  4 07:15:17 2020
From: report at bugs.python.org (=?utf-8?q?Uwe_Kleine-K=C3=B6nig?=)
Date: Sat, 04 Apr 2020 11:15:17 +0000
Subject: [issue40139] mimetypes module racy
In-Reply-To: <1585764080.54.0.0429329888929.issue40139@roundup.psfhosted.org>
Message-ID: <1585998917.55.0.733229420047.issue40139@roundup.psfhosted.org>


Uwe Kleine-K?nig <uwe+python at kleine-koenig.org> added the comment:

I agree that 3.5 is ancient and the focus should be to fix the newer versions of Python.

But given that the problem seems to be hard to reproduce -- I have the reproducer script from the original report running under the tracer since over a week now without a hit -- it seems to be beneficial to me to understand the issue on 3.5 to then check if 3.8+ is also affected.

Also note that Lib/mimetypes.py didn't change between 3.5.3 and 3.5.9.
The difference between 3.5.x and 3.6.x in this file doesn't affect the code flow, in fact the first commit that has a change to actually change the behavior I saw between 3.5.0 and current master is bpo-4963 that only went into 3.9.x.

I added dhess and steve.dower who were involved in bpo-4963 to the nosy list, maybe one of them remembers or is able to quickly spot the problem.

----------
nosy: +dhess, steve.dower

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

From report at bugs.python.org  Sat Apr  4 07:27:26 2020
From: report at bugs.python.org (=?utf-8?q?M=C3=A1rton_Marczell?=)
Date: Sat, 04 Apr 2020 11:27:26 +0000
Subject: [issue17088] ElementTree incorrectly refuses to write attributes
 without namespaces when default_namespace is used
In-Reply-To: <1359599707.26.0.771342463799.issue17088@psf.upfronthosting.co.za>
Message-ID: <1585999646.14.0.0540352947708.issue17088@roundup.psfhosted.org>


M?rton Marczell <dalokmarcinak at gmail.com> added the comment:

Can he please get a review of the pull request?

----------
nosy: +marczellm

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

From report at bugs.python.org  Sat Apr  4 07:49:12 2020
From: report at bugs.python.org (Ama Aje My Fren)
Date: Sat, 04 Apr 2020 11:49:12 +0000
Subject: [issue40166] UNICODE HOWTO: Change the total number of code points in
 the introduction section
In-Reply-To: <1585882870.71.0.612117283125.issue40166@roundup.psfhosted.org>
Message-ID: <1586000952.07.0.733338403808.issue40166@roundup.psfhosted.org>


Change by Ama Aje My Fren <amaajemyfren at gmail.com>:


----------
type:  -> enhancement

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

From report at bugs.python.org  Sat Apr  4 08:10:23 2020
From: report at bugs.python.org (David K. Hess)
Date: Sat, 04 Apr 2020 12:10:23 +0000
Subject: [issue40139] mimetypes module racy
In-Reply-To: <1585764080.54.0.0429329888929.issue40139@roundup.psfhosted.org>
Message-ID: <1586002223.47.0.130637204125.issue40139@roundup.psfhosted.org>


David K. Hess <david_k_hess at mac.com> added the comment:

I?m not sure I can shed any light on this particular bug, but I would say that based on my dealings with this module, it is definitely not thread-safe. That means that if you are going to have multiple threads accessing it simultaneously, you really should have a mutex around that access ensuring only one thread is running through the code in this module at a time. 

Now in reality, asyncio and other cooperatively scheduled multi-processing packages like gevent are not going to unpredictably yield control to another thread like true threads will. So, in this particular case, since the init code doesn?t use async or await, I don?t think there is a chance of an initialization race bug there. 

As to the bug witnessed, the only thing I can suggest is to add a considerable amount of debugging that logs the argument to guess_type and prints out the mimetype module?s internal state if and when this happens again. My best guess based on the amount of work that method does to inspect the passed in url, is that it has something to do with the url itself.

----------

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

From report at bugs.python.org  Sat Apr  4 08:14:36 2020
From: report at bugs.python.org (Steve Dower)
Date: Sat, 04 Apr 2020 12:14:36 +0000
Subject: [issue40164] Upgrade Windows and macOS installer builds to OpenSSL
 1.1.1f
In-Reply-To: <1585875388.92.0.251240838882.issue40164@roundup.psfhosted.org>
Message-ID: <1586002476.06.0.787703039743.issue40164@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


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

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

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: [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 08:26:36 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 04 Apr 2020 12:26:36 +0000
Subject: [issue40178] Convert the remaining os funtions to Argument Clinic
In-Reply-To: <1586003108.43.0.643087706293.issue40178@roundup.psfhosted.org>
Message-ID: <1586003196.39.0.306252511523.issue40178@roundup.psfhosted.org>


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


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

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

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


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

The problems which prevented their conversions before (in issue20170):

1. os.sendfile() had parameter names conflicting with Python keywords. Was solved in issue38378.

2. os.get_terminal_size() has an optional argument without default value. It was solved in a way similar to issue37206.

3. Some functions have platform-specific types of arguments. os.sendfile() has additional parameters. It was solved by using a preprocessor. We need to repeat most of the declaration and docstring, but it is the best that we can have now.

----------

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

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


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


----------
components: +Argument Clinic
nosy: +larry

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

From report at bugs.python.org  Sat Apr  4 10:12:15 2020
From: report at bugs.python.org (hai shi)
Date: Sat, 04 Apr 2020 14:12:15 +0000
Subject: [issue40170] [C API] Make PyTypeObject structure an opaque structure
 in the public C API
In-Reply-To: <1585915023.07.0.846808236133.issue40170@roundup.psfhosted.org>
Message-ID: <1586009535.08.0.747634664273.issue40170@roundup.psfhosted.org>


Change by hai shi <shihai1991 at 126.com>:


----------
nosy: +shihai1991

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

From report at bugs.python.org  Sat Apr  4 10:19:15 2020
From: report at bugs.python.org (Steve Dower)
Date: Sat, 04 Apr 2020 14:19:15 +0000
Subject: [issue40164] Upgrade Windows and macOS installer builds to OpenSSL
 1.1.1f
In-Reply-To: <1585875388.92.0.251240838882.issue40164@roundup.psfhosted.org>
Message-ID: <1586009955.52.0.394396830453.issue40164@roundup.psfhosted.org>


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


New changeset a1d4dbdfc78e3aed4c245e1810ef24eaa4e744c2 by Steve Dower in branch 'master':
bpo-40164: Update Windows to OpenSSL 1.1.1f (GH-19359)
https://github.com/python/cpython/commit/a1d4dbdfc78e3aed4c245e1810ef24eaa4e744c2


----------

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

From report at bugs.python.org  Sat Apr  4 10:22:24 2020
From: report at bugs.python.org (Steve Dower)
Date: Sat, 04 Apr 2020 14:22:24 +0000
Subject: [issue40164] Upgrade Windows and macOS installer builds to OpenSSL
 1.1.1f
In-Reply-To: <1585875388.92.0.251240838882.issue40164@roundup.psfhosted.org>
Message-ID: <1586010144.6.0.6065220823.issue40164@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
pull_requests: +18723
pull_request: https://github.com/python/cpython/pull/19361

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

From report at bugs.python.org  Sat Apr  4 10:24:34 2020
From: report at bugs.python.org (Steve Dower)
Date: Sat, 04 Apr 2020 14:24:34 +0000
Subject: [issue40164] Upgrade Windows and macOS installer builds to OpenSSL
 1.1.1f
In-Reply-To: <1585875388.92.0.251240838882.issue40164@roundup.psfhosted.org>
Message-ID: <1586010274.95.0.503323360785.issue40164@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
pull_requests: +18724
pull_request: https://github.com/python/cpython/pull/19362

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

From report at bugs.python.org  Sat Apr  4 10:39:21 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Sat, 04 Apr 2020 14:39:21 +0000
Subject: [issue40176] unterminated string literal tokenization error messages
 could be better
In-Reply-To: <1585936724.82.0.54480834244.issue40176@roundup.psfhosted.org>
Message-ID: <1586011161.6.0.670095238846.issue40176@roundup.psfhosted.org>


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

>>> message = "sadsa
  File "<stdin>", line 1
    message = "sadsa
              ^
SyntaxError: unterminated double quote

----------

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

From report at bugs.python.org  Sat Apr  4 10:47:46 2020
From: report at bugs.python.org (Steve Dower)
Date: Sat, 04 Apr 2020 14:47:46 +0000
Subject: [issue40164] Upgrade Windows and macOS installer builds to OpenSSL
 1.1.1f
In-Reply-To: <1585875388.92.0.251240838882.issue40164@roundup.psfhosted.org>
Message-ID: <1586011666.61.0.133662360701.issue40164@roundup.psfhosted.org>


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


New changeset 37126e7bd242bce03f3c4f208d8871edd3febcbe by Steve Dower in branch '3.8':
bpo-40164: Update Windows to OpenSSL 1.1.1f (GH-19359)
https://github.com/python/cpython/commit/37126e7bd242bce03f3c4f208d8871edd3febcbe


----------

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

From report at bugs.python.org  Sat Apr  4 10:47:50 2020
From: report at bugs.python.org (Steve Dower)
Date: Sat, 04 Apr 2020 14:47:50 +0000
Subject: [issue40164] Upgrade Windows and macOS installer builds to OpenSSL
 1.1.1f
In-Reply-To: <1585875388.92.0.251240838882.issue40164@roundup.psfhosted.org>
Message-ID: <1586011670.47.0.654330361676.issue40164@roundup.psfhosted.org>


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


New changeset e7a47c23dd25a144ec4afc2db46393818694926f by Steve Dower in branch '3.7':
bpo-40164: Update Windows to OpenSSL 1.1.1f (GH-19359)
https://github.com/python/cpython/commit/e7a47c23dd25a144ec4afc2db46393818694926f


----------

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

From report at bugs.python.org  Sat Apr  4 10:51:10 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 04 Apr 2020 14:51:10 +0000
Subject: [issue36517] typing.NamedTuple does not support mixins
In-Reply-To: <1554296850.04.0.71784053328.issue36517@roundup.psfhosted.org>
Message-ID: <1586011870.83.0.864853771298.issue36517@roundup.psfhosted.org>


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


----------
keywords: +patch
nosy: +serhiy.storchaka
nosy_count: 3.0 -> 4.0
pull_requests: +18725
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19363

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

From report at bugs.python.org  Sat Apr  4 11:00:46 2020
From: report at bugs.python.org (hai shi)
Date: Sat, 04 Apr 2020 15:00:46 +0000
Subject: [issue40173] test.support.import_fresh_module fails to correctly
 block submodules when fresh is specified
In-Reply-To: <1585927123.84.0.0735169096885.issue40173@roundup.psfhosted.org>
Message-ID: <1586012446.42.0.564938189328.issue40173@roundup.psfhosted.org>


Change by hai shi <shihai1991 at 126.com>:


----------
nosy: +shihai1991

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

From report at bugs.python.org  Sat Apr  4 11:10:11 2020
From: report at bugs.python.org (Ofek Lev)
Date: Sat, 04 Apr 2020 15:10:11 +0000
Subject: [issue33240] shutil.rmtree fails if inner folder is open in Windows
 Explorer
In-Reply-To: <1523155916.86.0.682650639539.issue33240@psf.upfronthosting.co.za>
Message-ID: <1586013011.6.0.128838141251.issue33240@roundup.psfhosted.org>


Ofek Lev <ofekmeister at gmail.com> added the comment:

> For convenience, a handler that retries unlink() and rmdir() could be distributed with shutil. For ease of use, it could be enabled by default on Windows.

Any update on that? I just spent a bunch of time debugging this on Windows.

----------
nosy: +Ofekmeister

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

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: [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 12:37:37 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 04 Apr 2020 16:37:37 +0000
Subject: [issue40179] Argument Clinic incorretly translates #elif
In-Reply-To: <1586017601.68.0.788293930127.issue40179@roundup.psfhosted.org>
Message-ID: <1586018257.9.0.631502114943.issue40179@roundup.psfhosted.org>


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


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

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

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


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


----------
pull_requests: +18727
pull_request: https://github.com/python/cpython/pull/19360

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

From report at bugs.python.org  Sat Apr  4 12:46:51 2020
From: report at bugs.python.org (Rodriguez)
Date: Sat, 04 Apr 2020 16:46:51 +0000
Subject: [issue36207] robotsparser deny all with some rules
In-Reply-To: <1551865321.24.0.407834320039.issue36207@roundup.psfhosted.org>
Message-ID: <1586018811.27.0.0896629093326.issue36207@roundup.psfhosted.org>


Rodriguez <lagustais at gmail.com> added the comment:

I can't display my robot.TXT. I want to ban robots
 https://melwynn-rodriguez.fr/robots.txt

----------
nosy: +lagustais

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

From report at bugs.python.org  Sat Apr  4 13:41:31 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Sat, 04 Apr 2020 17:41:31 +0000
Subject: [issue1635741] Py_Finalize() doesn't clear all Python objects at exit
Message-ID: <1586022091.52.0.804988368912.issue1635741@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
pull_requests: +18728
pull_request: https://github.com/python/cpython/pull/19366

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

From report at bugs.python.org  Sat Apr  4 13:51:43 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Sat, 04 Apr 2020 17:51:43 +0000
Subject: [issue1635741] Py_Finalize() doesn't clear all Python objects at exit
Message-ID: <1586022703.44.0.0555466529806.issue1635741@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
pull_requests:  -18728

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

From report at bugs.python.org  Sat Apr  4 14:31:34 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 04 Apr 2020 18:31:34 +0000
Subject: [issue36517] typing.NamedTuple does not support mixins
In-Reply-To: <1554296850.04.0.71784053328.issue36517@roundup.psfhosted.org>
Message-ID: <1586025094.18.0.468904556046.issue36517@roundup.psfhosted.org>


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


New changeset a94e6272f16381349dbed74cdb738ec8ae23b4fe by Serhiy Storchaka in branch 'master':
bpo-36517: Raise error on multiple inheritance with NamedTuple (GH-19363)
https://github.com/python/cpython/commit/a94e6272f16381349dbed74cdb738ec8ae23b4fe


----------

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

From report at bugs.python.org  Sat Apr  4 15:07:34 2020
From: report at bugs.python.org (Larry Hastings)
Date: Sat, 04 Apr 2020 19:07:34 +0000
Subject: [issue40179] Argument Clinic incorretly translates #elif
In-Reply-To: <1586017601.68.0.788293930127.issue40179@roundup.psfhosted.org>
Message-ID: <1586027254.62.0.251351452967.issue40179@roundup.psfhosted.org>


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

Good catch, and thanks for submitting a patch too!  I want to play with your patch a little before I just say "yes of course".

----------

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

From report at bugs.python.org  Sat Apr  4 15:24:23 2020
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 04 Apr 2020 19:24:23 +0000
Subject: [issue40077] Convert static types to PyType_FromSpec()
In-Reply-To: <1585238684.65.0.246012172449.issue40077@roundup.psfhosted.org>
Message-ID: <1586028263.83.0.582358184658.issue40077@roundup.psfhosted.org>


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


New changeset b709302f3125622986bd458dfb2954fda5e8366d by Hai Shi in branch 'master':
bpo-40077: Fix potential refleaks of _json: traverse memo (GH-19344)
https://github.com/python/cpython/commit/b709302f3125622986bd458dfb2954fda5e8366d


----------

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

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: [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 15:35:49 2020
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 04 Apr 2020 19:35:49 +0000
Subject: [issue40174] HAVE_CLOCK_GETTIME not repected in pytime.c
In-Reply-To: <1585927809.98.0.29079570836.issue40174@roundup.psfhosted.org>
Message-ID: <1586028949.65.0.056795132209.issue40174@roundup.psfhosted.org>


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

Python has a long history (30 years). time.time() had multiple implementations. When I added time.monotonic() in Python 3.3, it was optional. I changed that in Python 3.5: time.monotonic() is now always available.
https://docs.python.org/dev/library/time.html#time.monotonic

time.monotonic() has multiple implementations:

* Windows: GetTickCount64()
* macOS (Darwin): mach_absolute_time()
* HP-UX: gethrtime()
* Solaris: clock_gettime(CLOCK_HIGHRES)
* Otherwise: clock_gettime(CLOCK_MONOTONIC)

So far (since Python 3.5), no one complained about build error on any platform. It looks safe in practice to expect clock_gettime() to be available.

I suggest to close this issue, and only change the code is Python fails to build on a specific platform.

By the way, glibc 2.31 release notes: "We plan to remove the obsolete function ftime, and the header <sys/timeb.h>, in a future version of glibc."

----------

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

From report at bugs.python.org  Sat Apr  4 15:43:47 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Sat, 04 Apr 2020 19:43:47 +0000
Subject: [issue40180] isinstance(cls_with_metaclass, non_type) raises KeyError
In-Reply-To: <1586028529.92.0.773288395215.issue40180@roundup.psfhosted.org>
Message-ID: <1586029427.62.0.43223683032.issue40180@roundup.psfhosted.org>


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

What would you expect in this case? Objects/abstract.c:2429 is where the isinstance code. If only returning False would be enough, something like this (untested) would be enough

--- a/Objects/abstract.c
+++ b/Objects/abstract.c
@@ -2436,6 +2436,10 @@ object_isinstance(PyObject *inst, PyObject *cls)
         retval = PyObject_TypeCheck(inst, (PyTypeObject *)cls);
         if (retval == 0) {
             retval = _PyObject_LookupAttrId(inst, &PyId___class__, &icls);
+            if (retval == NULL && PyErr_Occurred()) {
+                PyErr_Clear();
+                retval = 0;
+            }

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

_______________________________________
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: [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:35:35 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 04 Apr 2020 20:35:35 +0000
Subject: [issue40181] IDLE: remove positional-only note from calltips
In-Reply-To: <1586032094.19.0.965319984529.issue40181@roundup.psfhosted.org>
Message-ID: <1586032535.41.0.285189248077.issue40181@roundup.psfhosted.org>


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

#35763 reduced the footprint of the note.
#35764 is about revising the calltip doc.  Part of the intention was to add something about '/'.  Maybe no need now, but if I did, I might remove the calltip note in 3.7.

----------

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

From report at bugs.python.org  Sat Apr  4 16:37:09 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 04 Apr 2020 20:37:09 +0000
Subject: [issue38689] IDLE crashes when KeyError is raised during calltip
 generation
In-Reply-To: <1572911156.46.0.933839006151.issue38689@roundup.psfhosted.org>
Message-ID: <1586032629.44.0.44066312897.issue38689@roundup.psfhosted.org>


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

get_argspec accesses the user object 3 times.  The first, ob.__call__ was already wrapped in try-except.  The second, signature(ob or ob.__call) is wrapped by this issue.  It also adds a new test based on Dan's example. The third is (ob or ob.__call__).__doc__.  I did not wrap this because I could not create an example for which this fails.  There seems to be some special casing of this special attribute so that its default is None.

I opened #40180 for the isinstance bug and #40181 for further get_argspec changes, in particular, removing the positional-only '/' note.

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

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

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: [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: [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:46:55 2020
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 04 Apr 2020 20:46:55 +0000
Subject: [issue40183] AC_COMPILE_IFELSE doesn't work in all cases
In-Reply-To: <1586033148.57.0.987289402861.issue40183@roundup.psfhosted.org>
Message-ID: <1586033215.03.0.405168637819.issue40183@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch
nosy: +python-dev
nosy_count: 1.0 -> 2.0
pull_requests: +18729
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19367

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

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


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


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

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

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: [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 16:54:56 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Sat, 04 Apr 2020 20:54:56 +0000
Subject: [issue40184] Compiler warnings under sparc64
In-Reply-To: <1586033576.89.0.798054068129.issue40184@roundup.psfhosted.org>
Message-ID: <1586033696.51.0.30588395293.issue40184@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Sat Apr  4 16:56:21 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 04 Apr 2020 20:56:21 +0000
Subject: [issue36320] typing.NamedTuple to switch from OrderedDict to regular
 dict
In-Reply-To: <1552767001.87.0.278808375525.issue36320@roundup.psfhosted.org>
Message-ID: <1586033781.57.0.584968217334.issue36320@roundup.psfhosted.org>


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


----------
nosy: +serhiy.storchaka
nosy_count: 4.0 -> 5.0
pull_requests: +18732
pull_request: https://github.com/python/cpython/pull/19370

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

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: [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: [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:12:52 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 04 Apr 2020 21:12:52 +0000
Subject: [issue40185] Refactor typing.NamedTuple
In-Reply-To: <1586034525.17.0.360408189871.issue40185@roundup.psfhosted.org>
Message-ID: <1586034772.98.0.499620426698.issue40185@roundup.psfhosted.org>


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


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

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

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


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

This behavior looks random, for 10 run it hangs 2 times.

----------

_______________________________________
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: [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 17:21:13 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 04 Apr 2020 21:21:13 +0000
Subject: [issue40187] Refactor typing.TypedDict
In-Reply-To: <1586035239.71.0.90938203594.issue40187@roundup.psfhosted.org>
Message-ID: <1586035273.71.0.520500894247.issue40187@roundup.psfhosted.org>


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

See also issue40185.

----------

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

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


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

See also issue40187.

----------

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

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


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


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40187>
_______________________________________

From report at bugs.python.org  Sat Apr  4 17:25:19 2020
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 04 Apr 2020 21:25:19 +0000
Subject: [issue40184] Compiler warnings under sparc64
In-Reply-To: <1586033576.89.0.798054068129.issue40184@roundup.psfhosted.org>
Message-ID: <1586035519.62.0.975586143154.issue40184@roundup.psfhosted.org>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset 1b21573a89632356737a24302dd64c9eb1457a7b by Batuhan Ta?kaya in branch 'master':
closes bpo-40184: Only define pysiphash if the hash algorithm is SIPHASH24. (GH-19369)
https://github.com/python/cpython/commit/1b21573a89632356737a24302dd64c9eb1457a7b


----------
nosy: +benjamin.peterson
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40184>
_______________________________________

From report at bugs.python.org  Sat Apr  4 17:26:14 2020
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 04 Apr 2020 21:26:14 +0000
Subject: [issue40184] Compiler warnings under sparc64
In-Reply-To: <1586033576.89.0.798054068129.issue40184@roundup.psfhosted.org>
Message-ID: <1586035574.92.0.941506469404.issue40184@roundup.psfhosted.org>


Change by Benjamin Peterson <benjamin at python.org>:


----------
pull_requests: +18735
pull_request: https://github.com/python/cpython/pull/19373

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40184>
_______________________________________

From report at bugs.python.org  Sat Apr  4 17:29:27 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 04 Apr 2020 21:29:27 +0000
Subject: [issue40179] Argument Clinic incorretly translates #elif
In-Reply-To: <1586017601.68.0.788293930127.issue40179@roundup.psfhosted.org>
Message-ID: <1586035767.42.0.888328085411.issue40179@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

See PR 19360 for real example.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40179>
_______________________________________

From report at bugs.python.org  Sat Apr  4 17:33:34 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Sat, 04 Apr 2020 21:33:34 +0000
Subject: [issue36630] failure of test_colors_funcs in test_curses with ncurses
 6.1
In-Reply-To: <1555270378.07.0.766030130411.issue36630@roundup.psfhosted.org>
Message-ID: <1586036014.77.0.306712952038.issue36630@roundup.psfhosted.org>


Change by Batuhan Taskaya <batuhanosmantaskaya at gmail.com>:


----------
nosy: +BTaskaya

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36630>
_______________________________________

From report at bugs.python.org  Sat Apr  4 17:36:29 2020
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 04 Apr 2020 21:36:29 +0000
Subject: [issue40174] HAVE_CLOCK_GETTIME not repected in pytime.c
In-Reply-To: <1585927809.98.0.29079570836.issue40174@roundup.psfhosted.org>
Message-ID: <1586036189.39.0.0062356738147.issue40174@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch
nosy: +python-dev
nosy_count: 3.0 -> 4.0
pull_requests: +18736
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19374

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40174>
_______________________________________

From report at bugs.python.org  Sat Apr  4 17:41:52 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 04 Apr 2020 21:41:52 +0000
Subject: [issue40180] isinstance(cls_with_metaclass, non_type) raises KeyError
In-Reply-To: <1586028529.92.0.773288395215.issue40180@roundup.psfhosted.org>
Message-ID: <1586036512.46.0.653185542559.issue40180@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

All works as expected to me. Your __class__ attribute raise an arbitrary exception, and it is expected, that the code which uses it passes it to you.

I am against silencing all exceptions. It may hide bugs.

It is even documented. See What's New in Python 3.8:

* The CPython interpreter can swallow exceptions in some circumstances.
  In Python 3.8 this happens in fewer cases.  In particular, exceptions
  raised when getting the attribute from the type dictionary are no longer
  ignored. (Contributed by Serhiy Storchaka in :issue:`35459`.)

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40180>
_______________________________________

From report at bugs.python.org  Sat Apr  4 17:43:10 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 04 Apr 2020 21:43:10 +0000
Subject: [issue36320] typing.NamedTuple to switch from OrderedDict to regular
 dict
In-Reply-To: <1552767001.87.0.278808375525.issue36320@roundup.psfhosted.org>
Message-ID: <1586036590.57.0.357564072869.issue36320@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 0d1d7c8bae3f9fe9e937d2931dcbbd3555d1a9f1 by Serhiy Storchaka in branch '3.8':
bpo-36320: Use the deprecated-removed directive for _field_types (GH-19370)
https://github.com/python/cpython/commit/0d1d7c8bae3f9fe9e937d2931dcbbd3555d1a9f1


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36320>
_______________________________________

From report at bugs.python.org  Sat Apr  4 17:43:24 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 04 Apr 2020 21:43:24 +0000
Subject: [issue40182] Remove the _field_types attribute of NamedTuple
In-Reply-To: <1586032921.73.0.44858415086.issue40182@roundup.psfhosted.org>
Message-ID: <1586036604.03.0.155489026357.issue40182@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 6fed3c85402c5ca704eb3f3189ca3f5c67a08d19 by Serhiy Storchaka in branch 'master':
bpo-40182: Remove the _field_types attribute of the NamedTuple class (GH-19368)
https://github.com/python/cpython/commit/6fed3c85402c5ca704eb3f3189ca3f5c67a08d19


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40182>
_______________________________________

From report at bugs.python.org  Sat Apr  4 17:44:44 2020
From: report at bugs.python.org (=?utf-8?b?SsOpcsO0bWU=?=)
Date: Sat, 04 Apr 2020 21:44:44 +0000
Subject: [issue40174] HAVE_CLOCK_GETTIME not repected in pytime.c
In-Reply-To: <1585927809.98.0.29079570836.issue40174@roundup.psfhosted.org>
Message-ID: <1586036684.87.0.323576100807.issue40174@roundup.psfhosted.org>


J?r?me <jerome.hamm at gmail.com> added the comment:

Hi,

I think it is nice to inform the user that clock_gettime is mandatory (just like pthreads, see PR). Can be nice for someone trying to port it to a new platform.

"It's no particularly silly, is it?"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40174>
_______________________________________

From report at bugs.python.org  Sat Apr  4 17:45:49 2020
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 04 Apr 2020 21:45:49 +0000
Subject: [issue40170] [C API] Make PyTypeObject structure an opaque structure
 in the public C API
In-Reply-To: <1585915023.07.0.846808236133.issue40170@roundup.psfhosted.org>
Message-ID: <1586036749.45.0.667886765597.issue40170@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Macros and static inline functions of the public C API which access directly PyTypeObject fields. There may be more.

#define _PyObject_SIZE(typeobj) ( (typeobj)->tp_basicsize )

static inline vectorcallfunc
PyVectorcall_Function(PyObject *callable)
{
    ...
    tp = Py_TYPE(callable);
    offset = tp->tp_vectorcall_offset;
    ...
}

#define PyObject_CheckBuffer(obj) \
    ((Py_TYPE(obj)->tp_as_buffer != NULL) &&  \
     (Py_TYPE(obj)->tp_as_buffer->bf_getbuffer != NULL))

#define PyIndex_Check(obj)                              \
    (Py_TYPE(obj)->tp_as_number != NULL &&            \
     Py_TYPE(obj)->tp_as_number->nb_index != NULL)

#define PyObject_GET_WEAKREFS_LISTPTR(o) \
    ((PyObject **) (((char *) (o)) + Py_TYPE(o)->tp_weaklistoffset))

static inline int
PyType_HasFeature(PyTypeObject *type, unsigned long feature) {
#ifdef Py_LIMITED_API
    return ((PyType_GetFlags(type) & feature) != 0);
#else
    return ((type->tp_flags & feature) != 0);
#endif
}

#define _PyObject_SIZE(typeobj) ( (typeobj)->tp_basicsize )

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40170>
_______________________________________

From report at bugs.python.org  Sat Apr  4 17:46:57 2020
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 04 Apr 2020 21:46:57 +0000
Subject: [issue40184] Compiler warnings under sparc64
In-Reply-To: <1586033576.89.0.798054068129.issue40184@roundup.psfhosted.org>
Message-ID: <1586036817.93.0.168046192605.issue40184@roundup.psfhosted.org>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset 411555075401aa831a2228196c2d8f9a54b6f577 by Benjamin Peterson in branch '3.8':
[3.8] closes bpo-40184: Only define pysiphash if the hash algorithm is SIPHASH24. (GH-19373)
https://github.com/python/cpython/commit/411555075401aa831a2228196c2d8f9a54b6f577


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40184>
_______________________________________

From report at bugs.python.org  Sat Apr  4 17:54:03 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 04 Apr 2020 21:54:03 +0000
Subject: [issue40182] Remove the _field_types attribute of NamedTuple
In-Reply-To: <1586032921.73.0.44858415086.issue40182@roundup.psfhosted.org>
Message-ID: <1586037243.07.0.7344209249.issue40182@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40182>
_______________________________________

From report at bugs.python.org  Sat Apr  4 17:58:13 2020
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 04 Apr 2020 21:58:13 +0000
Subject: [issue40170] [C API] Make PyTypeObject structure an opaque structure
 in the public C API
In-Reply-To: <1585915023.07.0.846808236133.issue40170@roundup.psfhosted.org>
Message-ID: <1586037493.16.0.982169657071.issue40170@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
keywords: +patch
pull_requests: +18737
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19375

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40170>
_______________________________________

From report at bugs.python.org  Sat Apr  4 17:58:22 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 04 Apr 2020 21:58:22 +0000
Subject: [issue40180] isinstance(cls_with_metaclass, non_type) raises KeyError
In-Reply-To: <1586028529.92.0.773288395215.issue40180@roundup.psfhosted.org>
Message-ID: <1586037502.75.0.762130276473.issue40180@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

(Serhiy posted while I wrote this.)
Sorry, I should have quoted the doc.  " If object is not an object of the given type, the function always returns False."  Raising instead is a bug -- even of the object itself is somewhat buggy.

My knowledge of the C codebase is insufficient to review, let alone write, non-trivial changes.  But I was curious where and why Object itself was being used as a key. I presume
  retval = _PyObject_LookupAttrId(inst, &PyId___class__, &icls);
is roughly equivalent to Object.__class__ and indeed, that raises the KeyError.  I presume the why has something to do with the interaction between metaclasses, properties, and slots.  So if the details are correct, your patch should plug this hole.  Can you submit a PR with added test?

Issue background.  The example is from Dan Snider, OP of #38689.  When he typed 'Object(' into IDLE, IDLE tried to pop up a calltip.  But inspect.signature(Object) failed with the (unexpected and undocumented) KeyError when it called isinstance(Object, types.MethodTypes), and IDLE froze.  Given Python's flexibility, it can be hard to write code that works with any user code thrown at it.

----------
nosy:  -serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40180>
_______________________________________

From report at bugs.python.org  Sat Apr  4 17:58:52 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 04 Apr 2020 21:58:52 +0000
Subject: [issue40180] isinstance(cls_with_metaclass, non_type) raises KeyError
In-Reply-To: <1586028529.92.0.773288395215.issue40180@roundup.psfhosted.org>
Message-ID: <1586037532.84.0.292321322774.issue40180@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40180>
_______________________________________

From report at bugs.python.org  Sat Apr  4 18:02:59 2020
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 04 Apr 2020 22:02:59 +0000
Subject: [issue40170] [C API] Make PyTypeObject structure an opaque structure
 in the public C API
In-Reply-To: <1585915023.07.0.846808236133.issue40170@roundup.psfhosted.org>
Message-ID: <1586037779.35.0.67489822363.issue40170@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +18738
pull_request: https://github.com/python/cpython/pull/19376

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40170>
_______________________________________

From report at bugs.python.org  Sat Apr  4 18:13:13 2020
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 04 Apr 2020 22:13:13 +0000
Subject: [issue40170] [C API] Make PyTypeObject structure an opaque structure
 in the public C API
In-Reply-To: <1585915023.07.0.846808236133.issue40170@roundup.psfhosted.org>
Message-ID: <1586038393.09.0.782528593544.issue40170@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +18739
pull_request: https://github.com/python/cpython/pull/19377

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40170>
_______________________________________

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: [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 18:20:36 2020
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 04 Apr 2020 22:20:36 +0000
Subject: [issue40188] Azure Pipelines jobs failing randomly with: Unable to
 connect to azure.archive.ubuntu.com
In-Reply-To: <1586038783.25.0.595016433162.issue40188@roundup.psfhosted.org>
Message-ID: <1586038836.92.0.230339150019.issue40188@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
title: Azure Pipelines jobs failing randomy with: Unable to connect to azure.archive.ubuntu.com -> Azure Pipelines jobs failing randomly with: Unable to connect to azure.archive.ubuntu.com

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40188>
_______________________________________

From report at bugs.python.org  Sat Apr  4 18:20:43 2020
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 04 Apr 2020 22:20:43 +0000
Subject: [issue39837] Remove Azure Pipelines from GitHub PRs
In-Reply-To: <1583255119.77.0.277327127951.issue39837@roundup.psfhosted.org>
Message-ID: <1586038843.84.0.151979253313.issue39837@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> There is another issue: sometimes, the Ubuntu VM fails to download .deb from azure.archive.ubuntu.com.

I created bpo-40188: "Azure Pipelines jobs failing randomly with: Unable to connect to azure.archive.ubuntu.com".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39837>
_______________________________________

From report at bugs.python.org  Sat Apr  4 18:23:21 2020
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 04 Apr 2020 22:23:21 +0000
Subject: [issue40170] [C API] Make PyTypeObject structure an opaque structure
 in the public C API
In-Reply-To: <1585915023.07.0.846808236133.issue40170@roundup.psfhosted.org>
Message-ID: <1586039001.64.0.345870769731.issue40170@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +18740
pull_request: https://github.com/python/cpython/pull/19378

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40170>
_______________________________________

From report at bugs.python.org  Sat Apr  4 18:38:49 2020
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 04 Apr 2020 22:38:49 +0000
Subject: [issue40170] [C API] Make PyTypeObject structure an opaque structure
 in the public C API
In-Reply-To: <1585915023.07.0.846808236133.issue40170@roundup.psfhosted.org>
Message-ID: <1586039929.76.0.553312613702.issue40170@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +18741
pull_request: https://github.com/python/cpython/pull/19379

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40170>
_______________________________________

From report at bugs.python.org  Sat Apr  4 18:42:33 2020
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 04 Apr 2020 22:42:33 +0000
Subject: [issue40174] HAVE_CLOCK_GETTIME not repected in pytime.c
In-Reply-To: <1585927809.98.0.29079570836.issue40174@roundup.psfhosted.org>
Message-ID: <1586040153.48.0.494823148227.issue40174@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Usually, what I did to use #error in the C code. Something like:

#ifdef MS_WINDOWS
...
#elif defined(...)
...
#else
#  error "your platform doesn't support monotonic clock"
#endif

I dislike relying on configure for that, it's too far from the actual implementation (like pymonotonic()).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40174>
_______________________________________

From report at bugs.python.org  Sat Apr  4 18:54:24 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 04 Apr 2020 22:54:24 +0000
Subject: [issue40180] isinstance(cls_with_metaclass, non_type) raises KeyError
In-Reply-To: <1586028529.92.0.773288395215.issue40180@roundup.psfhosted.org>
Message-ID: <1586040864.6.0.479972009257.issue40180@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

> Sorry, I should have quoted the doc.  " If object is not an object of the given type, the function always returns False."  Raising instead is a bug -- even of the object itself is somewhat buggy.

You take it too literally. It does not mean that the function always returns a value. It can also raise an exception. If you press Ctrl-C it may raise an exception. If there is no memory to create some temporary objects, it may raise an exception. If you turn of the computer, it may neither return a value nor raise an exception.

You created a class whose __class__ attribute always raises an exception. What do you expect to get when you use this attribute? {}.__getitem__ always raise a KeyError, because an empty dict does not contain any key.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40180>
_______________________________________

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: [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:29:44 2020
From: report at bugs.python.org (Guy Kogan)
Date: Sat, 04 Apr 2020 23:29:44 +0000
Subject: [issue40189] MultiProcessing Subclass - overrides run method issue
In-Reply-To: <1586041256.49.0.0315110613604.issue40189@roundup.psfhosted.org>
Message-ID: <1586042984.63.0.0648480787316.issue40189@roundup.psfhosted.org>


Guy Kogan <Guy.kogan14 at gmail.com> added the comment:

I have fixed the issue

----------
resolution:  -> fixed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40189>
_______________________________________

From report at bugs.python.org  Sat Apr  4 19:29:53 2020
From: report at bugs.python.org (Guy Kogan)
Date: Sat, 04 Apr 2020 23:29:53 +0000
Subject: [issue40189] MultiProcessing Subclass - overrides run method issue
In-Reply-To: <1586041256.49.0.0315110613604.issue40189@roundup.psfhosted.org>
Message-ID: <1586042993.54.0.351999686139.issue40189@roundup.psfhosted.org>


Change by Guy Kogan <Guy.kogan14 at gmail.com>:


----------
stage:  -> resolved
status: open -> closed

_______________________________________
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: [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 19:59:27 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Sat, 04 Apr 2020 23:59:27 +0000
Subject: [issue40190] Add support for _SC_AIX_REALMEM in posix.sysconf
In-Reply-To: <1586044639.69.0.554430267599.issue40190@roundup.psfhosted.org>
Message-ID: <1586044767.93.0.885839901774.issue40190@roundup.psfhosted.org>


Change by Batuhan Taskaya <batuhanosmantaskaya at gmail.com>:


----------
keywords: +patch
pull_requests: +18742
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19380

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40190>
_______________________________________

From report at bugs.python.org  Sat Apr  4 20:04:49 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Sun, 05 Apr 2020 00:04:49 +0000
Subject: [issue40188] Azure Pipelines jobs failing randomly with: Unable to
 connect to azure.archive.ubuntu.com
In-Reply-To: <1586038783.25.0.595016433162.issue40188@roundup.psfhosted.org>
Message-ID: <1586045089.46.0.903477182248.issue40188@roundup.psfhosted.org>


Change by Batuhan Taskaya <batuhanosmantaskaya at gmail.com>:


----------
keywords: +patch
nosy: +BTaskaya
nosy_count: 2.0 -> 3.0
pull_requests: +18743
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19380

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40188>
_______________________________________

From report at bugs.python.org  Sat Apr  4 20:05:22 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Sun, 05 Apr 2020 00:05:22 +0000
Subject: [issue40188] Azure Pipelines jobs failing randomly with: Unable to
 connect to azure.archive.ubuntu.com
In-Reply-To: <1586038783.25.0.595016433162.issue40188@roundup.psfhosted.org>
Message-ID: <1586045122.08.0.993513062272.issue40188@roundup.psfhosted.org>


Change by Batuhan Taskaya <batuhanosmantaskaya at gmail.com>:


----------
keywords:  -patch
stage: patch review -> 

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40188>
_______________________________________

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: [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 20:40:56 2020
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 05 Apr 2020 00:40:56 +0000
Subject: [issue40190] Add support for _SC_AIX_REALMEM in posix.sysconf
In-Reply-To: <1586044639.69.0.554430267599.issue40190@roundup.psfhosted.org>
Message-ID: <1586047256.2.0.0235832519555.issue40190@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 909f4a30093f74d409711e564f93a43167ca0919 by Batuhan Ta?kaya in branch 'master':
bpo-40190: Add support for _SC_AIX_REALMEM in sysconf (GH-19380)
https://github.com/python/cpython/commit/909f4a30093f74d409711e564f93a43167ca0919


----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40190>
_______________________________________

From report at bugs.python.org  Sat Apr  4 20:41:06 2020
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 05 Apr 2020 00:41:06 +0000
Subject: [issue40190] Add support for _SC_AIX_REALMEM in posix.sysconf
In-Reply-To: <1586044639.69.0.554430267599.issue40190@roundup.psfhosted.org>
Message-ID: <1586047266.54.0.857581306913.issue40190@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40190>
_______________________________________

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: [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:19:33 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Sun, 05 Apr 2020 01:19:33 +0000
Subject: [issue40192] time.thread_time isn't outputting in nanoseconds in AIX
In-Reply-To: <1586049332.22.0.327858503775.issue40192@roundup.psfhosted.org>
Message-ID: <1586049573.72.0.410305014504.issue40192@roundup.psfhosted.org>


Change by Batuhan Taskaya <batuhanosmantaskaya at gmail.com>:


----------
keywords: +patch
pull_requests: +18744
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19381

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40192>
_______________________________________

From report at bugs.python.org  Sat Apr  4 21:23:19 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Sun, 05 Apr 2020 01:23:19 +0000
Subject: [issue40192] time.thread_time isn't outputting in nanoseconds in AIX
In-Reply-To: <1586049332.22.0.327858503775.issue40192@roundup.psfhosted.org>
Message-ID: <1586049799.6.0.510201160264.issue40192@roundup.psfhosted.org>


Change by Batuhan Taskaya <batuhanosmantaskaya at gmail.com>:


----------
nosy: +belopolsky, p-ganssle

_______________________________________
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: [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  Sat Apr  4 21:52:15 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Sun, 05 Apr 2020 01:52:15 +0000
Subject: [issue40191] tempfile.mkstemp() | Documentation Error
In-Reply-To: <1586047164.62.0.92715958345.issue40191@roundup.psfhosted.org>
Message-ID: <1586051535.72.0.0376755907342.issue40191@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

I think you may have misread the documentation. It says:

"an OS-level handle to an open file"

which is what you call a file descriptor. Not a file object, which is what you get by calling the builtin `open`, but a file handle like you get from calling `os.open` (as stated).

So I believe that the documentation is correct, but given that at least one person misunderstood it, perhaps it could do with improvement.

Do you have any suggestion for improvement?

----------
nosy: +steven.daprano

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40191>
_______________________________________

From report at bugs.python.org  Sat Apr  4 22:03:18 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Sun, 05 Apr 2020 02:03:18 +0000
Subject: [issue40193] thread.get_native_id() support for solaris
In-Reply-To: <1586051404.09.0.572439986747.issue40193@roundup.psfhosted.org>
Message-ID: <1586052198.09.0.268824550624.issue40193@roundup.psfhosted.org>


Batuhan Taskaya <batuhanosmantaskaya at gmail.com> added the comment:

Looks like neither pthread_self nor thr_self gives the native id. Closing the issue...

----------
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40193>
_______________________________________

From report at bugs.python.org  Sat Apr  4 23:34:49 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Sun, 05 Apr 2020 03:34:49 +0000
Subject: [issue1635741] Py_Finalize() doesn't clear all Python objects at exit
Message-ID: <1586057689.27.0.646153976512.issue1635741@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
pull_requests: +18745
pull_request: https://github.com/python/cpython/pull/19382

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1635741>
_______________________________________

From report at bugs.python.org  Sun Apr  5 01:15:46 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Sun, 05 Apr 2020 05:15:46 +0000
Subject: [issue37207] Use PEP 590 vectorcall to speed up calls to range(),
 list() and dict()
In-Reply-To: <1560072227.25.0.180298594259.issue37207@roundup.psfhosted.org>
Message-ID: <1586063746.34.0.572836200331.issue37207@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

IMHO, we can close this PR.

Summary:
The PEP 590 vectorcall is applied to list, tuple, dict, set, frozenset and range

If someone wants to apply PEP 590 to other cases.
Please open a new issue for it!

Thank you, Mark, Jeroen, Petr and everyone who works for this issue.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37207>
_______________________________________

From report at bugs.python.org  Sun Apr  5 03:05:22 2020
From: report at bugs.python.org (Dennis Sweeney)
Date: Sun, 05 Apr 2020 07:05:22 +0000
Subject: [issue40085] Argument parsing option c should accept int between -128
 to 255 ?
In-Reply-To: <1585295142.15.0.400379676659.issue40085@roundup.psfhosted.org>
Message-ID: <1586070322.91.0.073650566932.issue40085@roundup.psfhosted.org>


Dennis Sweeney <sweeney.dennis650 at gmail.com> added the comment:

I think this question is about types in c, apart from any Python c API. 

According to https://docs.python.org/3/c-api/arg.html#numbers, the specifier is

    c: (bytes or bytearray of length 1) -> [char]

so you should be able to write to a c variable of type "char". In c, "signed char"s are signed, with values in [-128..127]. C also has an "unsigned char" type, with values in [0..255]. Both types of variables contain eight bits of information, but they are interpreted in different ways. As such, we can write something like this:

    signed char c1;
    unsigned char c2;
    PyObject *tup = Py_BuildValue("(c)", 0xff);

    PyArg_ParseTuple(tup, "c", &c1);
    PyArg_ParseTuple(tup, "c", &c2);

    if (c1 < 0) {
        printf("First is signed.\n");
    }
    else {
        printf("First is unsigned.\n");
    }

    if (c2 < 0) {
        printf("Second is signed.\n");
    }
    else {
        printf("Second is unsigned.\n");
    }

and get back:

    First is signed.
    Second is unsigned.

Here, c1 and c2 each store nothing but the eight bits 0b11111111 (a.k.a. 0xff), but the compiler interprets c1 in two's-complement as -1 whereas it interprets c2 as 255, simply based on variable types.

If you just care about which eight bits you have, using "char" is good enough, and comparing "char"s for equality is all well and good. But if you're doing arithmetic or numerical comparisons on chars, I believe it's best practice to explicitly declare "signed" or "unsigned", since it's implementation-defined which one the compiler will do if you don't specify.

Note that if you replace 0xff with -1 in the c code above, the result will probably be the same, since the int -1 will be cast to the the same least significant byte as 0xff (the upper bytes are thrown away).

(A technicality: even the bounds for the number of bits in a char are implementation-specific, but unsigned chars must support *at least* [-127..127] and signed chars must support *at least* [0..255], and implementation using more than 8 bits are quite rare. If you wanted to be totally sure about exactly the types you're using, you could technically use uint8_t or int8_t.)

----------
nosy: +Dennis Sweeney

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40085>
_______________________________________

From report at bugs.python.org  Sun Apr  5 03:19:28 2020
From: report at bugs.python.org (Kjell Braden)
Date: Sun, 05 Apr 2020 07:19:28 +0000
Subject: [issue39148] DatagramProtocol + IPv6 does not work with
 ProactorEventLoop
In-Reply-To: <1577530511.62.0.532247879973.issue39148@roundup.psfhosted.org>
Message-ID: <1586071168.99.0.0218990275082.issue39148@roundup.psfhosted.org>


Kjell Braden <k.python at brdn.eu> added the comment:

PR is up. Any chance we get this reviewed for inclusion in 3.9.0a6 / 3.8.3rc1?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39148>
_______________________________________

From report at bugs.python.org  Sun Apr  5 05:30:43 2020
From: report at bugs.python.org (miss-islington)
Date: Sun, 05 Apr 2020 09:30:43 +0000
Subject: [issue40177] Python Language Reference Documentation
In-Reply-To: <1585971365.58.0.193657354587.issue40177@roundup.psfhosted.org>
Message-ID: <1586079043.79.0.577379775764.issue40177@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
nosy: +miss-islington
nosy_count: 6.0 -> 7.0
pull_requests: +18746
pull_request: https://github.com/python/cpython/pull/19383

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40177>
_______________________________________

From report at bugs.python.org  Sun Apr  5 05:31:04 2020
From: report at bugs.python.org (miss-islington)
Date: Sun, 05 Apr 2020 09:31:04 +0000
Subject: [issue40177] Python Language Reference Documentation
In-Reply-To: <1585971365.58.0.193657354587.issue40177@roundup.psfhosted.org>
Message-ID: <1586079064.45.0.882146374687.issue40177@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +18747
pull_request: https://github.com/python/cpython/pull/19384

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40177>
_______________________________________

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: [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 05:57:57 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 05 Apr 2020 09:57:57 +0000
Subject: [issue40177] Python Language Reference Documentation
In-Reply-To: <1585971365.58.0.193657354587.issue40177@roundup.psfhosted.org>
Message-ID: <1586080677.38.0.49283545608.issue40177@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks for the report! Now fixed.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
type: enhancement -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40177>
_______________________________________

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: [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 07:43:50 2020
From: report at bugs.python.org (SilentGhost)
Date: Sun, 05 Apr 2020 11:43:50 +0000
Subject: [issue40194] Document special meanings of a single underscore
In-Reply-To: <1586080214.54.0.704924875033.issue40194@roundup.psfhosted.org>
Message-ID: <1586087030.36.0.434752704635.issue40194@roundup.psfhosted.org>


SilentGhost <ghost.adh at runbox.com> added the comment:

Various meanings are documented in appropriate sections, ignoring and use in loops is a misunderstanding on part of the author - using underscore there is convention and doesn't have special meaning on the language level.

----------
nosy: +SilentGhost
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40194>
_______________________________________

From report at bugs.python.org  Sun Apr  5 08:47:13 2020
From: report at bugs.python.org (cripitone)
Date: Sun, 05 Apr 2020 12:47:13 +0000
Subject: [issue40194] Document special meanings of a single underscore
In-Reply-To: <1586080214.54.0.704924875033.issue40194@roundup.psfhosted.org>
Message-ID: <1586090833.99.0.715966671978.issue40194@roundup.psfhosted.org>


cripitone <cri at fsfe.org> added the comment:

> Various meanings are documented in appropriate sections

Uhm, you're right, though some of them are not that easy to find using the searchbar in the doc website, for example the meaning of "_" in https://docs.python.org/3.7/tutorial/introduction.html

Maybe it would help adding "(a single underscore)" at the end of the sentence "In interactive mode, the last printed expression is assigned to the variable _". This way one would get it by searching for "single underscore" or even "underscore".
(and maybe it could also be mentioned in https://docs.python.org/3.7/tutorial/interpreter.html and/or https://docs.python.org/3.7/tutorial/appendix.html which deal specifically with the interactive interpreter)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40194>
_______________________________________

From report at bugs.python.org  Sun Apr  5 09:21:09 2020
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 05 Apr 2020 13:21:09 +0000
Subject: [issue40174] HAVE_CLOCK_GETTIME not repected in pytime.c
In-Reply-To: <1585927809.98.0.29079570836.issue40174@roundup.psfhosted.org>
Message-ID: <1586092869.02.0.897520242765.issue40174@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
pull_requests: +18748
pull_request: https://github.com/python/cpython/pull/19385

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40174>
_______________________________________

From report at bugs.python.org  Sun Apr  5 09:26:41 2020
From: report at bugs.python.org (Juris Kaminskis)
Date: Sun, 05 Apr 2020 13:26:41 +0000
Subject: [issue22598] Add mUTF-7 codec (UTF-7 modified for IMAP)
In-Reply-To: <1412936657.2.0.48984767576.issue22598@psf.upfronthosting.co.za>
Message-ID: <1586093201.16.0.204019023303.issue22598@roundup.psfhosted.org>


Juris Kaminskis <juris.kaminskis at gmail.com> added the comment:

Would be good to have solution for this out-of-box in Python3. Any news?

----------
nosy: +juris

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22598>
_______________________________________

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: [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 09:34:28 2020
From: report at bugs.python.org (=?utf-8?q?Wolfgang_St=C3=B6cher?=)
Date: Sun, 05 Apr 2020 13:34:28 +0000
Subject: [issue40196] symtable.Symbol.is_local() can be True for global symbols
In-Reply-To: <1586093426.2.0.0805536970057.issue40196@roundup.psfhosted.org>
Message-ID: <1586093668.29.0.569470787959.issue40196@roundup.psfhosted.org>


Wolfgang St?cher <wolfgang at stoecher.com> added the comment:

see https://stackoverflow.com/a/61040435/1725562 for a proposed fix

----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40196>
_______________________________________

From report at bugs.python.org  Sun Apr  5 10:37:00 2020
From: report at bugs.python.org (=?utf-8?b?SsOpcsO0bWU=?=)
Date: Sun, 05 Apr 2020 14:37:00 +0000
Subject: [issue40174] HAVE_CLOCK_GETTIME not repected in pytime.c
In-Reply-To: <1585927809.98.0.29079570836.issue40174@roundup.psfhosted.org>
Message-ID: <1586097420.08.0.530172689469.issue40174@roundup.psfhosted.org>


J?r?me <jerome.hamm at gmail.com> added the comment:

Yes, I get your meaning, and I totally agree with it, I was wondering what was the best way to do it, stay close to the cause, which would allow to more easily go along with changes, or put it in the configure file and warn the user as soon as possible... It was kind of a flip a coin decision in the end.

For my information, is there a kind of committee or someone taking these kinds of decisions or at least expressing rules as to the spirit in which they should be made?

On the same track, how can I find why someone wrote "
/* Various compilers have only certain posix functions */
/* XXX Gosh I wish these were all moved into pyconfig.h */
" in posixmodule.c? Is it just because no-one had the opportunity to do it and it is OK for me to do it?

"Fetchez la vache"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40174>
_______________________________________

From report at bugs.python.org  Sun Apr  5 10:39:50 2020
From: report at bugs.python.org (pmp-p)
Date: Sun, 05 Apr 2020 14:39:50 +0000
Subject: [issue40174] HAVE_CLOCK_GETTIME not repected in pytime.c
In-Reply-To: <1585927809.98.0.29079570836.issue40174@roundup.psfhosted.org>
Message-ID: <1586097590.68.0.548244826393.issue40174@roundup.psfhosted.org>


Change by pmp-p <pmpp.pub at gmail.com>:


----------
nosy: +pmpp

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40174>
_______________________________________

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: [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 12:35:08 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Sun, 05 Apr 2020 16:35:08 +0000
Subject: [issue39511] [subinterpreters] Per-interpreter singletons (None, True,
 False, etc.)
In-Reply-To: <1580484815.27.0.407070570821.issue39511@roundup.psfhosted.org>
Message-ID: <1586104508.89.0.215890115774.issue39511@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
nosy: +corona10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39511>
_______________________________________

From report at bugs.python.org  Sun Apr  5 12:37:36 2020
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 05 Apr 2020 16:37:36 +0000
Subject: [issue40197] Add microseconds to timing table in What's new python 3.8
In-Reply-To: <1586102648.92.0.310451381261.issue40197@roundup.psfhosted.org>
Message-ID: <1586104656.55.0.671000141638.issue40197@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
assignee: docs at python -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40197>
_______________________________________

From report at bugs.python.org  Sun Apr  5 14:24:43 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 05 Apr 2020 18:24:43 +0000
Subject: [issue40197] Add microseconds to timing table in What's new python 3.8
In-Reply-To: <1586102648.92.0.310451381261.issue40197@roundup.psfhosted.org>
Message-ID: <1586111083.71.0.36005003225.issue40197@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
keywords: +patch
pull_requests: +18749
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19386

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40197>
_______________________________________

From report at bugs.python.org  Sun Apr  5 14:26:34 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 05 Apr 2020 18:26:34 +0000
Subject: [issue40197] Add nanoseconds to timing table in What's new python 3.8
In-Reply-To: <1586102648.92.0.310451381261.issue40197@roundup.psfhosted.org>
Message-ID: <1586111194.25.0.482655520631.issue40197@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
title: Add microseconds to timing table in What's new python 3.8 -> Add nanoseconds to timing table in What's new 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: [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: [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:11:42 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 05 Apr 2020 22:11:42 +0000
Subject: [issue40199] Invalid escape sequence DeprecationWarnings don't
 trigger by default
In-Reply-To: <1586118564.22.0.0408193741044.issue40199@roundup.psfhosted.org>
Message-ID: <1586124702.2.0.566295848853.issue40199@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I get it printed two times.

Actually I get it printed four times: two time when compile the test script (use r"'\d'" or "'\\d'" to get rid of them), and other two times when call compile() inside a script.

$ ./python issue40199.py 
issue40199.py:3: DeprecationWarning: invalid escape sequence \d
  compile("'\d'", "<string>", "eval")
issue40199.py:5: DeprecationWarning: invalid escape sequence \d
  compile("'\d'", "<string>", "eval")
<string>:1: DeprecationWarning: invalid escape sequence \d
<string>:1: DeprecationWarning: invalid escape sequence \d

----------
nosy: +serhiy.storchaka

_______________________________________
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: [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 19:06:23 2020
From: report at bugs.python.org (Furkan Onder)
Date: Sun, 05 Apr 2020 23:06:23 +0000
Subject: [issue40200] count 0 crash
In-Reply-To: <1586126677.48.0.798770412189.issue40200@roundup.psfhosted.org>
Message-ID: <1586127983.54.0.546308296459.issue40200@roundup.psfhosted.org>


Furkan Onder <furkanonder at protonmail.com> added the comment:

Can i see the program code?

----------
nosy: +furkanonder

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40200>
_______________________________________

From report at bugs.python.org  Sun Apr  5 19:07:42 2020
From: report at bugs.python.org (Talha Demirsoy)
Date: Sun, 05 Apr 2020 23:07:42 +0000
Subject: [issue40200] count 0 crash
In-Reply-To: <1586126677.48.0.798770412189.issue40200@roundup.psfhosted.org>
Message-ID: <1586128062.7.0.106189303658.issue40200@roundup.psfhosted.org>


Talha Demirsoy <talhademirsoy at gmail.com> added the comment:

I shared but I write again.

sayac = 0
fakto = 10000000000000000000000
while True:
    if fakto % 10 == 0:
        sayac += 1
        fakto = fakto / 10
    elif fakto % 10 > 0:
        break
print(sayac)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40200>
_______________________________________

From report at bugs.python.org  Sun Apr  5 19:13:04 2020
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Sun, 05 Apr 2020 23:13:04 +0000
Subject: [issue40200] count 0 crash
In-Reply-To: <1586126677.48.0.798770412189.issue40200@roundup.psfhosted.org>
Message-ID: <1586128384.99.0.205573172775.issue40200@roundup.psfhosted.org>


R?mi Lapeyre <remi.lapeyre at henki.fr> added the comment:

Hi Talha, you are using floating points division which convert its operands to floats so it loose precision for large numbers. The syntax for integer division in Python 3 is // and it will not change the type of its operands. Notice the difference below:

>>> 100000000000000000000000000/10 % 10
4.0
>>> 100000000000000000000000000.0//10 % 10
4.0
>>> 100000000000000000000000000//10 % 10
0

As you can see, in the first example the operand got changed to float which caused a loss of precision and we get the same result when we try directly with a float. Using // gives the expected result.

Python use perfect arithmetic for integers but IEEE 754 for floating point calculations. You will find that there is a lot of those "quirks" when using either very large or very small numbers and will need to be mindful of them.

In the program you linked, changing '/' to '//' should gives the result you are expecting.

----------
nosy: +remi.lapeyre -furkanonder

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40200>
_______________________________________

From report at bugs.python.org  Sun Apr  5 19:19:35 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Sun, 05 Apr 2020 23:19:35 +0000
Subject: [issue40200] count 0 crash
In-Reply-To: <1586126677.48.0.798770412189.issue40200@roundup.psfhosted.org>
Message-ID: <1586128775.86.0.862079642485.issue40200@roundup.psfhosted.org>


Batuhan Taskaya <batuhanosmantaskaya at gmail.com> added the comment:

Closing issue since it is not a bug, at least a bug of python itself. Feel free to post any questions to python-list mailing list. https://mail.python.org/mailman/listinfo/python-list

----------
nosy: +BTaskaya
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed
type: crash -> 

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40200>
_______________________________________

From report at bugs.python.org  Sun Apr  5 21:05:35 2020
From: report at bugs.python.org (Numerlor)
Date: Mon, 06 Apr 2020 01:05:35 +0000
Subject: [issue40199] Invalid escape sequence DeprecationWarnings don't
 trigger by default
In-Reply-To: <1586118564.22.0.0408193741044.issue40199@roundup.psfhosted.org>
Message-ID: <1586135135.67.0.30286890302.issue40199@roundup.psfhosted.org>


Numerlor <miso1038 at gmail.com> added the comment:

In what environment was that ran in?
The issue seems to exist in all the different environments that are easily available to me (win7, win10, linux under docker and on repl.it)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40199>
_______________________________________

From report at bugs.python.org  Sun Apr  5 21:53:34 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 06 Apr 2020 01:53:34 +0000
Subject: [issue40197] Add nanoseconds to timing table in What's new python 3.8
In-Reply-To: <1586102648.92.0.310451381261.issue40197@roundup.psfhosted.org>
Message-ID: <1586138014.41.0.661269695043.issue40197@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
nosy: +miss-islington
nosy_count: 3.0 -> 4.0
pull_requests: +18750
pull_request: https://github.com/python/cpython/pull/19387

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40197>
_______________________________________

From report at bugs.python.org  Sun Apr  5 21:53:10 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 06 Apr 2020 01:53:10 +0000
Subject: [issue40197] Add nanoseconds to timing table in What's new python 3.8
In-Reply-To: <1586102648.92.0.310451381261.issue40197@roundup.psfhosted.org>
Message-ID: <1586137990.3.0.462090501104.issue40197@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:


New changeset c63629e7c09da80a6b7d0253d04a9b3f57f88eff by Raymond Hettinger in branch 'master':
bpo-40197: Better describe the benchmark results table (GH-19386)
https://github.com/python/cpython/commit/c63629e7c09da80a6b7d0253d04a9b3f57f88eff


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40197>
_______________________________________

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: [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  Sun Apr  5 22:05:48 2020
From: report at bugs.python.org (Talha Demirsoy)
Date: Mon, 06 Apr 2020 02:05:48 +0000
Subject: [issue40201] Last digit count error
In-Reply-To: <1586138570.61.0.875101081918.issue40201@roundup.psfhosted.org>
Message-ID: <1586138748.18.0.151103134249.issue40201@roundup.psfhosted.org>


Talha Demirsoy <talhademirsoy at gmail.com> added the comment:

sorry delete pls

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40201>
_______________________________________

From report at bugs.python.org  Sun Apr  5 22:06:54 2020
From: report at bugs.python.org (Josh Rosenberg)
Date: Mon, 06 Apr 2020 02:06:54 +0000
Subject: [issue40201] Last digit count error
In-Reply-To: <1586138570.61.0.875101081918.issue40201@roundup.psfhosted.org>
Message-ID: <1586138814.54.0.80481291689.issue40201@roundup.psfhosted.org>


Josh Rosenberg <shadowranger+python at gmail.com> added the comment:

Your script is using "true" division with / , (that produces potentially inaccurate float results) not floor division with // , (which gets int results). When the inputs vastly exceed the integer representational capabilities of floats (52-53 bits, where 10 ** 24 is 80 bits), you'll have problems.

This is a bug in your script, not Python.

----------
nosy: +josh.r
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40201>
_______________________________________

From report at bugs.python.org  Sun Apr  5 22:07:03 2020
From: report at bugs.python.org (Talha Demirsoy)
Date: Mon, 06 Apr 2020 02:07:03 +0000
Subject: [issue40201] Last digit count error
In-Reply-To: <1586138570.61.0.875101081918.issue40201@roundup.psfhosted.org>
Message-ID: <1586138823.76.0.899778968781.issue40201@roundup.psfhosted.org>


Change by Talha Demirsoy <talhademirsoy at gmail.com>:


Removed 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  Sun Apr  5 22:10:17 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 06 Apr 2020 02:10:17 +0000
Subject: [issue40197] Add nanoseconds to timing table in What's new python 3.8
In-Reply-To: <1586102648.92.0.310451381261.issue40197@roundup.psfhosted.org>
Message-ID: <1586139017.02.0.656433400033.issue40197@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +18751
pull_request: https://github.com/python/cpython/pull/19388

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40197>
_______________________________________

From report at bugs.python.org  Sun Apr  5 22:45:54 2020
From: report at bugs.python.org (Talley Lambert)
Date: Mon, 06 Apr 2020 02:45:54 +0000
Subject: [issue39414] Multiprocessing resolving object as None
In-Reply-To: <1579626467.92.0.021176656048.issue39414@roundup.psfhosted.org>
Message-ID: <1586141154.87.0.369922240224.issue39414@roundup.psfhosted.org>


Talley Lambert <talley.lambert at gmail.com> added the comment:

FYI, this bug was an issue with dask: https://github.com/dask/dask/issues/5806
and has been fixed in dask as of (I believe) v2.11.0

----------
nosy: +Talley Lambert

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39414>
_______________________________________

From report at bugs.python.org  Sun Apr  5 23:18:22 2020
From: report at bugs.python.org (Ned Deily)
Date: Mon, 06 Apr 2020 03:18:22 +0000
Subject: [issue40198] macOS Python builds from Python.org ignore
 DYLD_LIBRARY_PATH due to hardened runtime
In-Reply-To: <1586118049.02.0.786646499236.issue40198@roundup.psfhosted.org>
Message-ID: <1586143102.2.0.888450116103.issue40198@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


----------
assignee:  -> ned.deily
versions: +Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40198>
_______________________________________

From report at bugs.python.org  Mon Apr  6 01:38:31 2020
From: report at bugs.python.org (Zackery Spytz)
Date: Mon, 06 Apr 2020 05:38:31 +0000
Subject: [issue40147] Move checking for duplicated keywords to the compiler
In-Reply-To: <1585786944.89.0.491246758826.issue40147@roundup.psfhosted.org>
Message-ID: <1586151511.23.0.60460105959.issue40147@roundup.psfhosted.org>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
nosy: +ZackerySpytz
nosy_count: 2.0 -> 3.0
pull_requests: +18752
pull_request: https://github.com/python/cpython/pull/19389

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40147>
_______________________________________

From report at bugs.python.org  Mon Apr  6 02:03:29 2020
From: report at bugs.python.org (Stub)
Date: Mon, 06 Apr 2020 06:03:29 +0000
Subject: [issue34972] json dump silently converts int keys to string
In-Reply-To: <1539426263.62.0.788709270274.issue34972@psf.upfronthosting.co.za>
Message-ID: <1586153009.6.0.746303580757.issue34972@roundup.psfhosted.org>


Stub <stubish at gmail.com> added the comment:

Similarly, keys can be lost entirely:

>>> json.dumps({1:2, 1.0:3})
'{"1": 3}'

----------
nosy: +Stub2

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34972>
_______________________________________

From report at bugs.python.org  Mon Apr  6 02:12:26 2020
From: report at bugs.python.org (Morten Hels)
Date: Mon, 06 Apr 2020 06:12:26 +0000
Subject: [issue40197] Add nanoseconds to timing table in What's new python 3.8
In-Reply-To: <1586102648.92.0.310451381261.issue40197@roundup.psfhosted.org>
Message-ID: <1586153546.62.0.15957293018.issue40197@roundup.psfhosted.org>


Morten Hels <morten at hels.dk> added the comment:

It turns out I was wrong about microseconds. The output in https://bugs.python.org/issue35884 does show microseconds, but the output is before this commit https://github.com/python/cpython/commit/9da3583e78603a81b1839e17a420079f734a75b0 that fixes a typo (that's my best guess anyway).

Thank you for clearing this up, rhettinger.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40197>
_______________________________________

From report at bugs.python.org  Mon Apr  6 02:14:52 2020
From: report at bugs.python.org (Stuart Bishop)
Date: Mon, 06 Apr 2020 06:14:52 +0000
Subject: [issue34972] json dump silently converts int keys to string
In-Reply-To: <1539426263.62.0.788709270274.issue34972@psf.upfronthosting.co.za>
Message-ID: <1586153692.11.0.561484612318.issue34972@roundup.psfhosted.org>


Stuart Bishop <stuart at stuartbishop.net> added the comment:

(sorry, my example is normal Python behavior. {1:1, 1.0:2} == {1:2} , {1.0:1} == {1:1} )

----------
nosy: +stub

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34972>
_______________________________________

From report at bugs.python.org  Mon Apr  6 02:48:03 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 06 Apr 2020 06:48:03 +0000
Subject: [issue40147] Move checking for duplicated keywords to the compiler
In-Reply-To: <1585786944.89.0.491246758826.issue40147@roundup.psfhosted.org>
Message-ID: <1586155683.54.0.343103363715.issue40147@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset 08050e959e6c40839cd2c9e5f6a4fd1513e3d605 by Zackery Spytz in branch 'master':
bpo-40147: Fix a compiler warning on Windows in Python/compile.c (GH-19389)
https://github.com/python/cpython/commit/08050e959e6c40839cd2c9e5f6a4fd1513e3d605


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40147>
_______________________________________

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: [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 04:33:27 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 06 Apr 2020 08:33:27 +0000
Subject: [issue40196] symtable.Symbol.is_local() can be True for global symbols
In-Reply-To: <1586093426.2.0.0805536970057.issue40196@roundup.psfhosted.org>
Message-ID: <1586162007.01.0.479400079613.issue40196@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
assignee:  -> pablogsal
nosy: +pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40196>
_______________________________________

From report at bugs.python.org  Mon Apr  6 05:49:57 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 06 Apr 2020 09:49:57 +0000
Subject: [issue40196] symtable.Symbol.is_local() can be True for global symbols
In-Reply-To: <1586093426.2.0.0805536970057.issue40196@roundup.psfhosted.org>
Message-ID: <1586166596.99.0.53523285954.issue40196@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

>>> code2 = """\
... def foo():
...    x = 42
...    def bar():
...       return -1
... """
>>> top.get_children()[0]
<Function SymbolTable for foo in ?>
>>> top = symtable.symtable(code2, "?", "exec")
>>> top.get_children()[0].lookup('x')._Symbol__scope == symtable.LOCAL
True

but if we return x from bar:

That fix is not correct. For instance consider:

>>> code = """\
... def foo():
...    x = 42
...    def bar():
...       return x
... """
>>> import symtable
>>> top = symtable.symtable(code, "?", "exec")
>>> top.get_children()[0].lookup('x')._Symbol__scope == symtable.LOCAL
False

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40196>
_______________________________________

From report at bugs.python.org  Mon Apr  6 05:51:57 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Mon, 06 Apr 2020 09:51:57 +0000
Subject: [issue40202] Misleading grammatically of ValueError Message?
In-Reply-To: <1586160974.41.0.711704681431.issue40202@roundup.psfhosted.org>
Message-ID: <1586166717.15.0.36997173033.issue40202@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

I think the error messages could be improved.

In the first example: `f,x, a, b = [1,2,3]`

you are unpacking three values, but you need to unpack 4. The error message is not very helpful: 5 values is "more than 3" but it would be too many, you need not "more than 3" but exactly 4.

In the second example `a, b = [1,2,3]` it would be nice if it would tell you how many values you need to unpack.

Ideally, the message would say something like:

    Need to unpack 4 values but got 3  # first example
    Need to unpack 2 values but got 3  # second example

However I don't know if this is possible with the current parser, it might not be possible until the parser is changed (maybe in 3.9?)

----------
nosy: +steven.daprano

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40202>
_______________________________________

From report at bugs.python.org  Mon Apr  6 06:06:05 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 06 Apr 2020 10:06:05 +0000
Subject: [issue40196] symtable.Symbol.is_local() can be True for global symbols
In-Reply-To: <1586093426.2.0.0805536970057.issue40196@roundup.psfhosted.org>
Message-ID: <1586167565.36.0.0085645850716.issue40196@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
keywords: +patch
pull_requests: +18753
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19391

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40196>
_______________________________________

From report at bugs.python.org  Mon Apr  6 06:06:55 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 06 Apr 2020 10:06:55 +0000
Subject: [issue40196] symtable.Symbol.is_local() can be True for global symbols
In-Reply-To: <1586093426.2.0.0805536970057.issue40196@roundup.psfhosted.org>
Message-ID: <1586167615.47.0.9965619477.issue40196@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
Removed message: https://bugs.python.org/msg365843

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40196>
_______________________________________

From report at bugs.python.org  Mon Apr  6 06:07:07 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 06 Apr 2020 10:07:07 +0000
Subject: [issue40196] symtable.Symbol.is_local() can be True for global symbols
In-Reply-To: <1586093426.2.0.0805536970057.issue40196@roundup.psfhosted.org>
Message-ID: <1586167627.29.0.39456036631.issue40196@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

That fix is not correct. For instance consider:

>>> code2 = """\
... def foo():
...    x = 42
...    def bar():
...       return -1
... """
>>> top.get_children()[0]
<Function SymbolTable for foo in ?>
>>> top = symtable.symtable(code2, "?", "exec")
>>> top.get_children()[0].lookup('x')._Symbol__scope == symtable.LOCAL
True

but if we return x from bar:

>>> code = """\
... def foo():
...    x = 42
...    def bar():
...       return x
... """
>>> import symtable
>>> top = symtable.symtable(code, "?", "exec")
>>> top.get_children()[0].lookup('x')._Symbol__scope == symtable.LOCAL
False

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40196>
_______________________________________

From report at bugs.python.org  Mon Apr  6 06:21:02 2020
From: report at bugs.python.org (hai shi)
Date: Mon, 06 Apr 2020 10:21:02 +0000
Subject: [issue40173] test.support.import_fresh_module fails to correctly
 block submodules when fresh is specified
In-Reply-To: <1585927123.84.0.0735169096885.issue40173@roundup.psfhosted.org>
Message-ID: <1586168462.67.0.859268554279.issue40173@roundup.psfhosted.org>


Change by hai shi <shihai1991 at 126.com>:


----------
keywords: +patch
pull_requests: +18754
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19390

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40173>
_______________________________________

From report at bugs.python.org  Mon Apr  6 06:23:01 2020
From: report at bugs.python.org (hai shi)
Date: Mon, 06 Apr 2020 10:23:01 +0000
Subject: [issue40173] test.support.import_fresh_module fails to correctly
 block submodules when fresh is specified
In-Reply-To: <1585927123.84.0.0735169096885.issue40173@roundup.psfhosted.org>
Message-ID: <1586168581.4.0.929021098263.issue40173@roundup.psfhosted.org>


hai shi <shihai1991 at 126.com> added the comment:

> 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)

Looks like deleting a module name after `__import__(name)` is not good enought in https://github.com/python/cpython/blob/master/Lib/test/support/__init__.py#L244.(some redundant submodules should be removed, no?)

paul's example can be passed in PR19390.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40173>
_______________________________________

From report at bugs.python.org  Mon Apr  6 07:47:47 2020
From: report at bugs.python.org (Dima Tisnek)
Date: Mon, 06 Apr 2020 11:47:47 +0000
Subject: [issue40060] socket.TCP_NOTSENT_LOWAT is missing in official macOS
 builds
In-Reply-To: <1585120826.63.0.863724436073.issue40060@roundup.psfhosted.org>
Message-ID: <1586173667.93.0.530238616313.issue40060@roundup.psfhosted.org>


Dima Tisnek <dimaqq at gmail.com> added the comment:

+macos team, because I can't for the life of me figure out how official builds are made ??

In short: my local build has socket.TCP_NOTSENT_LOWAT but the official build does not.

----------
nosy: +ned.deily, ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40060>
_______________________________________

From report at bugs.python.org  Mon Apr  6 08:07:10 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 06 Apr 2020 12:07:10 +0000
Subject: [issue40170] [C API] Make PyTypeObject structure an opaque structure
 in the public C API
In-Reply-To: <1585915023.07.0.846808236133.issue40170@roundup.psfhosted.org>
Message-ID: <1586174830.75.0.6735914544.issue40170@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 38aefc585f60a77d66f4fbe5a37594a488b53474 by Victor Stinner in branch 'master':
bpo-40170: PyObject_GET_WEAKREFS_LISTPTR() becomes a function (GH-19377)
https://github.com/python/cpython/commit/38aefc585f60a77d66f4fbe5a37594a488b53474


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40170>
_______________________________________

From report at bugs.python.org  Mon Apr  6 08:28:18 2020
From: report at bugs.python.org (Ronald Oussoren)
Date: Mon, 06 Apr 2020 12:28:18 +0000
Subject: [issue40060] socket.TCP_NOTSENT_LOWAT is missing in official macOS
 builds
In-Reply-To: <1585120826.63.0.863724436073.issue40060@roundup.psfhosted.org>
Message-ID: <1586176098.12.0.545528456279.issue40060@roundup.psfhosted.org>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

AFAIK the macOS builds are still build on the oldest macOS release supported by the installer (that is, a macOS 10.9 system). This means the build won't use macOS APIs introduced in macOS 10.10 or later.

----

It would be nice to build the installer using the latest compiler and SDK (more APIs available, better compiler, ...), but that requires work to explicitly avoid using APIs that aren't available on the system the binary is running on.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40060>
_______________________________________

From report at bugs.python.org  Mon Apr  6 08:55:56 2020
From: report at bugs.python.org (Michael Felt)
Date: Mon, 06 Apr 2020 12:55:56 +0000
Subject: [issue40170] [C API] Make PyTypeObject structure an opaque structure
 in the public C API
In-Reply-To: <1585915023.07.0.846808236133.issue40170@roundup.psfhosted.org>
Message-ID: <1586177756.9.0.902703730052.issue40170@roundup.psfhosted.org>


Michael Felt <aixtools at felt.demon.nl> added the comment:

Just manually verified that PR19377, when compiled against xlc - crashes during make:

	rm -f libpython3.9d.a
	ar rcs libpython3.9d.a Modules/getbuildinfo.o  Parser/acceler.o  Parser/grammar1.o  Parser/listnode.o  Parser/node.o  Parser/parser.o  Parser/token.o   Parser/myreadline.o Parser/parsetok.o Parser/tokenizer.o  Objects/abstract.o  Objects/accu.o  Objects/boolobject.o  Objects/bytes_methods.o  Objects/bytearrayobject.o  Objects/bytesobject.o  Objects/call.o  Objects/capsule.o  Objects/cellobject.o  Objects/classobject.o  Objects/codeobject.o  Objects/complexobject.o  Objects/descrobject.o  Objects/enumobject.o  Objects/exceptions.o  Objects/genobject.o  Objects/fileobject.o  Objects/floatobject.o  Objects/frameobject.o  Objects/funcobject.o  Objects/interpreteridobject.o  Objects/iterobject.o  Objects/listobject.o  Objects/longobject.o  Objects/dictobject.o  Objects/odictobject.o  Objects/memoryobject.o  Objects/methodobject.o  Objects/moduleobject.o  Objects/namespaceobject.o  Objects/object.o  Objects/obmalloc.o  Objects/picklebufobject.o  Objects/rangeobject.o  Objects/setobject.o  Objects/sliceobject.o  Objects/structseq.o  Objects/tupleobject.o  Objects/typeobject.o  Objects/unicodeobject.o  Objects/unicodectype.o  Objects/weakrefobject.o  Python/_warnings.o  Python/Python-ast.o  Python/asdl.o  Python/ast.o  Python/ast_opt.o  Python/ast_unparse.o  Python/bltinmodule.o  Python/ceval.o  Python/codecs.o  Python/compile.o  Python/context.o  Python/dynamic_annotations.o  Python/errors.o  Python/frozenmain.o  Python/future.o  Python/getargs.o  Python/getcompiler.o  Python/getcopyright.o  Python/getplatform.o  Python/getversion.o  Python/graminit.o  Python/hamt.o  Python/import.o  Python/importdl.o  Python/initconfig.o  Python/marshal.o  Python/modsupport.o  Python/mysnprintf.o  Python/mystrtoul.o  Python/pathconfig.o  Python/peephole.o  Python/preconfig.o  Python/pyarena.o  Python/pyctype.o  Python/pyfpe.o  Python/pyhash.o  Python/pylifecycle.o  Python/pymath.o  Python/pystate.o  Python/pythonrun.o  Python/pytime.o  Python/bootstrap_hash.o  Python/structmember.o  Python/symtable.o  Python/sysmodule.o  Python/thread.o  Python/traceback.o  Python/getopt.o  Python/pystrcmp.o  Python/pystrtod.o  Python/pystrhex.o  Python/dtoa.o  Python/formatter_unicode.o  Python/fileutils.o  Python/dynload_shlib.o        Modules/config.o  Modules/getpath.o  Modules/main.o  Modules/gcmodule.o  Modules/posixmodule.o  Modules/errnomodule.o  Modules/pwdmodule.o  Modules/_sre.o  Modules/_codecsmodule.o  Modules/_weakref.o  Modules/_functoolsmodule.o  Modules/_operator.o  Modules/_collectionsmodule.o  Modules/_abc.o  Modules/itertoolsmodule.o  Modules/atexitmodule.o  Modules/signalmodule.o  Modules/_stat.o  Modules/timemodule.o  Modules/_threadmodule.o  Modules/_localemodule.o  Modules/_iomodule.o Modules/iobase.o Modules/fileio.o Modules/bytesio.o Modules/bufferedio.o Modules/textio.o Modules/stringio.o  Modules/faulthandler.o  Modules/_tracemalloc.o Modules/hashtable.o  Modules/symtablemodule.o  Modules/xxsubtype.o  Python/frozen.o
	./Modules/makexp_aix Modules/python.exp . libpython3.9d.a;  xlc_r     -Wl,-bE:Modules/python.exp -lld -o python Programs/python.o libpython3.9d.a -lintl -ldl  -lm   -lm 
	 ./python -E -S -m sysconfig --generate-posix-vars ; if test $? -ne 0 ; then  echo "generate-posix-vars failed" ;  rm -f ./pybuilddir.txt ;  exit 1 ;  fi
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  : 30084150
object refcount : 0
object type     : 20013aa8
object type name: generator
object repr     : <refcnt 0 at 30084150>
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
/bin/sh: 24117648 IOT/Abort trap(coredump)
make: 1254-004 The error code from the last command is 134.
Stop.

FYI: about two hours ago I verified that xlc and 08050e959e6c40839cd2c9e5f6a4fd1513e3d605 : bpo-40147: Fix a compiler warning on Windows in Python/compile.c (GH-19389)

all was green.

----------
nosy: +Michael.Felt

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40170>
_______________________________________

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: [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 09:22:48 2020
From: report at bugs.python.org (Michael Felt)
Date: Mon, 06 Apr 2020 13:22:48 +0000
Subject: [issue40170] [C API] Make PyTypeObject structure an opaque structure
 in the public C API
In-Reply-To: <1585915023.07.0.846808236133.issue40170@roundup.psfhosted.org>
Message-ID: <1586179368.52.0.816728932762.issue40170@roundup.psfhosted.org>


Michael Felt <aixtools at felt.demon.nl> added the comment:

Just checked - seems to be SPECIFIC to xlc-v16 as neither xlv-v11 nor xlc-v13 have any issues building.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40170>
_______________________________________

From report at bugs.python.org  Mon Apr  6 09:28:36 2020
From: report at bugs.python.org (=?utf-8?q?Wolfgang_St=C3=B6cher?=)
Date: Mon, 06 Apr 2020 13:28:36 +0000
Subject: [issue40196] symtable.Symbol.is_local() can be True for global symbols
In-Reply-To: <1586093426.2.0.0805536970057.issue40196@roundup.psfhosted.org>
Message-ID: <1586179716.12.0.202649731569.issue40196@roundup.psfhosted.org>


Wolfgang St?cher <wolfgang at stoecher.com> added the comment:

In symtable.Function.get_locals() symbols with scopes in (LOCAL, CELL) are selected. Also

>>> code = """\
... def foo():
...    x = 42
...    def bar():
...       return x
... """
>>> import symtable
>>> top = symtable.symtable(code, "?", "exec")
>>> top.get_children()[0].lookup('x')._Symbol__scope == symtable.CELL
True

So I guess this would be the correct fix then:

def is_local(self):
    return self.__scope in (LOCAL, CELL)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40196>
_______________________________________

From report at bugs.python.org  Mon Apr  6 09:33:08 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 06 Apr 2020 13:33:08 +0000
Subject: [issue40196] symtable.Symbol.is_local() can be True for global symbols
In-Reply-To: <1586093426.2.0.0805536970057.issue40196@roundup.psfhosted.org>
Message-ID: <1586179988.44.0.89894060406.issue40196@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

I prefer to explicitly check for absence of the global scope as in PR 19391

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40196>
_______________________________________

From report at bugs.python.org  Mon Apr  6 09:33:56 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 06 Apr 2020 13:33:56 +0000
Subject: [issue40196] symtable.Symbol.is_local() can be True for global symbols
In-Reply-To: <1586093426.2.0.0805536970057.issue40196@roundup.psfhosted.org>
Message-ID: <1586180036.14.0.0611202563828.issue40196@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
Removed message: https://bugs.python.org/msg365854

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40196>
_______________________________________

From report at bugs.python.org  Mon Apr  6 09:35:19 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 06 Apr 2020 13:35:19 +0000
Subject: [issue40196] symtable.Symbol.is_local() can be True for global symbols
In-Reply-To: <1586093426.2.0.0805536970057.issue40196@roundup.psfhosted.org>
Message-ID: <1586180119.75.0.257186161942.issue40196@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

> In symtable.Function.get_locals() symbols with scopes in (LOCAL, CELL) are selected.

Thanks for pointing that out. I will simplify PR 19391.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40196>
_______________________________________

From report at bugs.python.org  Mon Apr  6 09:35:40 2020
From: report at bugs.python.org (Steve Dower)
Date: Mon, 06 Apr 2020 13:35:40 +0000
Subject: [issue40188] Azure Pipelines jobs failing randomly with: Unable to
 connect to azure.archive.ubuntu.com
In-Reply-To: <1586038783.25.0.595016433162.issue40188@roundup.psfhosted.org>
Message-ID: <1586180140.51.0.987925565376.issue40188@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
pull_requests:  -18743

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40188>
_______________________________________

From report at bugs.python.org  Mon Apr  6 09:38:04 2020
From: report at bugs.python.org (Steve Dower)
Date: Mon, 06 Apr 2020 13:38:04 +0000
Subject: [issue40188] Azure Pipelines jobs failing randomly with: Unable to
 connect to azure.archive.ubuntu.com
In-Reply-To: <1586038783.25.0.595016433162.issue40188@roundup.psfhosted.org>
Message-ID: <1586180284.21.0.9957172543.issue40188@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

I wonder why the "install wamerican" didn't go into the script? It should at least get the same options as in the script to make sure it doesn't break the install.

Maybe we should make our own mirror of Ubuntu so that we don't have to depend on a massive company with billions of users to get it right for us? :o)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40188>
_______________________________________

From report at bugs.python.org  Mon Apr  6 09:56:56 2020
From: report at bugs.python.org (=?utf-8?q?Volker_Wei=C3=9Fmann?=)
Date: Mon, 06 Apr 2020 13:56:56 +0000
Subject: [issue40203] Warn about invalid PYTHONUSERBASE
In-Reply-To: <1586177955.41.0.354760283694.issue40203@roundup.psfhosted.org>
Message-ID: <1586181416.54.0.668766557.issue40203@roundup.psfhosted.org>


Volker Wei?mann <volker.weissmann at gmx.de> added the comment:

Forget the thing I said about "invalid//path", but my argument still stands for non existing paths or paths to something else than a directory.

----------

_______________________________________
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: [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: [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: [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:22:55 2020
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Mon, 06 Apr 2020 15:22:55 +0000
Subject: [issue40206] Multiplying 4.6*100 will result in 459.99999999999994
In-Reply-To: <1586186268.64.0.709905151161.issue40206@roundup.psfhosted.org>
Message-ID: <1586186575.31.0.470434133988.issue40206@roundup.psfhosted.org>


R?mi Lapeyre <remi.lapeyre at henki.fr> added the comment:

Hi ahmad, calculation with floating points in Python uses the IEE 754 (https://fr.wikipedia.org/wiki/IEEE_754) standard and will result in such quirks.

If you want to not loose precision you can use the decimal module:

>>> from decimal import Decimal
>>> Decimal('4.6')*100
Decimal('460.0')

Since this is not a bug if you have other questions when working with floats, try to ask on python-list or a forum.

----------
nosy: +remi.lapeyre

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40206>
_______________________________________

From report at bugs.python.org  Mon Apr  6 11:24:18 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 06 Apr 2020 15:24:18 +0000
Subject: [issue40170] [C API] Make PyTypeObject structure an opaque structure
 in the public C API
In-Reply-To: <1585915023.07.0.846808236133.issue40170@roundup.psfhosted.org>
Message-ID: <1586186658.17.0.944393147126.issue40170@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Py_TRASHCAN_BEGIN() access directly PyTypeObject.tp_dealloc:

#define Py_TRASHCAN_BEGIN(op, dealloc) \
    Py_TRASHCAN_BEGIN_CONDITION(op, \
        Py_TYPE(op)->tp_dealloc == (destructor)(dealloc))

It should use PyType_GetSlot() or a new getter function (to read PyTypeObject.tp_dealloc) should be added.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40170>
_______________________________________

From report at bugs.python.org  Mon Apr  6 11:25:55 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 06 Apr 2020 15:25:55 +0000
Subject: [issue40170] [C API] Make PyTypeObject structure an opaque structure
 in the public C API
In-Reply-To: <1585915023.07.0.846808236133.issue40170@roundup.psfhosted.org>
Message-ID: <1586186755.78.0.0977013607679.issue40170@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> It should use PyType_GetSlot()

Oh. It seems like currently, PyType_GetSlot() can only be used on a heap allocated types :-( The function starts with:

    if (!PyType_HasFeature(type, Py_TPFLAGS_HEAPTYPE) || slot < 0) {
        PyErr_BadInternalCall();
        return NULL;
    }

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40170>
_______________________________________

From report at bugs.python.org  Mon Apr  6 11:35:23 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 06 Apr 2020 15:35:23 +0000
Subject: [issue40206] Multiplying 4.6*100 will result in 459.99999999999994
In-Reply-To: <1586186268.64.0.709905151161.issue40206@roundup.psfhosted.org>
Message-ID: <1586187323.12.0.499404817259.issue40206@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

See https://docs.python.org/3.8/tutorial/floatingpoint.html

----------
nosy: +eric.smith
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40206>
_______________________________________

From report at bugs.python.org  Mon Apr  6 11:51:16 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Mon, 06 Apr 2020 15:51:16 +0000
Subject: [issue40206] Multiplying 4.6*100 will result in 459.99999999999994
In-Reply-To: <1586186268.64.0.709905151161.issue40206@roundup.psfhosted.org>
Message-ID: <1586188276.87.0.357381176875.issue40206@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

R?mi, it is not true that the Decimal module won't lose precision. It will. Decimal is not exact either, it is still a floating point format similar to float.

py> Decimal(1)/3*3
Decimal('0.9999999999999999999999999999')

The two major advantages of Decimal are: it matches the number you type more closely, and you can choose how much precision to use. (At the cost of memory and speed.) But there are also disadvantages: rounding errors with Decimal tend to be larger on average than for binary floats.

If you want exact calculations that will never lose precision, you have to use Fractions, but that is slower and less convenient.

----------
nosy: +steven.daprano

_______________________________________
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: [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 11:58:31 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Mon, 06 Apr 2020 15:58:31 +0000
Subject: [issue40207] Expose NCURSES_EXT_FUNCS under curses
In-Reply-To: <1586188512.46.0.148388356677.issue40207@roundup.psfhosted.org>
Message-ID: <1586188711.82.0.377208356827.issue40207@roundup.psfhosted.org>


Change by Batuhan Taskaya <batuhanosmantaskaya at gmail.com>:


----------
keywords: +patch
pull_requests: +18755
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19392

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40207>
_______________________________________

From report at bugs.python.org  Mon Apr  6 12:00:53 2020
From: report at bugs.python.org (ahmad dana)
Date: Mon, 06 Apr 2020 16:00:53 +0000
Subject: [issue40206] Multiplying 4.6*100 will result in 459.99999999999994
In-Reply-To: <1586186268.64.0.709905151161.issue40206@roundup.psfhosted.org>
Message-ID: <1586188853.66.0.544554195114.issue40206@roundup.psfhosted.org>


ahmad dana <ahmadjd94 at gmail.com> added the comment:

Regarding the comment about the decimal point precision , and solving the issue with the decimal library, the following attachment shows you that the decimal Library did exactly the same behaviour

----------
Added file: https://bugs.python.org/file49040/Screen Shot 2020-04-06 at 6.56.48 PM.png

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40206>
_______________________________________

From report at bugs.python.org  Mon Apr  6 12:06:04 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 06 Apr 2020 16:06:04 +0000
Subject: [issue40196] symtable.Symbol.is_local() can be True for global symbols
In-Reply-To: <1586093426.2.0.0805536970057.issue40196@roundup.psfhosted.org>
Message-ID: <1586189164.03.0.258528470977.issue40196@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset 799d7d61a91eb0ad3256ef9a45a90029cef93b7c by Pablo Galindo in branch 'master':
bpo-40196: Fix a bug in the symtable when reporting inspecting global variables (GH-19391)
https://github.com/python/cpython/commit/799d7d61a91eb0ad3256ef9a45a90029cef93b7c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40196>
_______________________________________

From report at bugs.python.org  Mon Apr  6 12:06:41 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 06 Apr 2020 16:06:41 +0000
Subject: [issue40196] symtable.Symbol.is_local() can be True for global symbols
In-Reply-To: <1586093426.2.0.0805536970057.issue40196@roundup.psfhosted.org>
Message-ID: <1586189201.44.0.366740328539.issue40196@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
nosy: +miss-islington
nosy_count: 2.0 -> 3.0
pull_requests: +18756
pull_request: https://github.com/python/cpython/pull/19394

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40196>
_______________________________________

From report at bugs.python.org  Mon Apr  6 12:06:50 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 06 Apr 2020 16:06:50 +0000
Subject: [issue40196] symtable.Symbol.is_local() can be True for global symbols
In-Reply-To: <1586093426.2.0.0805536970057.issue40196@roundup.psfhosted.org>
Message-ID: <1586189210.87.0.476983203918.issue40196@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +18757
pull_request: https://github.com/python/cpython/pull/19395

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40196>
_______________________________________

From report at bugs.python.org  Mon Apr  6 12:08:25 2020
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Mon, 06 Apr 2020 16:08:25 +0000
Subject: [issue40206] Multiplying 4.6*100 will result in 459.99999999999994
In-Reply-To: <1586186268.64.0.709905151161.issue40206@roundup.psfhosted.org>
Message-ID: <1586189305.3.0.501167285768.issue40206@roundup.psfhosted.org>


R?mi Lapeyre <remi.lapeyre at henki.fr> added the comment:

@Steven Yes that's true, I only meant that in the context of the issue where only the multiplication is used. FWIW Fraction also would have issues with e.g. trigonometric functions right?


@ahmad, that's because you did Decimal(4.6) which first parse 4.6 as a float then call Decimal() with the result. You need to use Decimal('4.6') to avoid the parser reading 4.6 as a float. Have a look at the tutorial Eric Smith linked, the documentation of decimal and the response from Steven D'Aprano for more information.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40206>
_______________________________________

From report at bugs.python.org  Mon Apr  6 12:41:32 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 06 Apr 2020 16:41:32 +0000
Subject: [issue40196] symtable.Symbol.is_local() can be True for global symbols
In-Reply-To: <1586093426.2.0.0805536970057.issue40196@roundup.psfhosted.org>
Message-ID: <1586191292.37.0.54134013837.issue40196@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 717f1668b3455b498424577e194719f9beae13a1 by Miss Islington (bot) in branch '3.7':
bpo-40196: Fix a bug in the symtable when reporting inspecting global variables (GH-19391)
https://github.com/python/cpython/commit/717f1668b3455b498424577e194719f9beae13a1


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40196>
_______________________________________

From report at bugs.python.org  Mon Apr  6 12:42:07 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 06 Apr 2020 16:42:07 +0000
Subject: [issue40196] symtable.Symbol.is_local() can be True for global symbols
In-Reply-To: <1586093426.2.0.0805536970057.issue40196@roundup.psfhosted.org>
Message-ID: <1586191327.7.0.127787362112.issue40196@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40196>
_______________________________________

From report at bugs.python.org  Mon Apr  6 12:41:59 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 06 Apr 2020 16:41:59 +0000
Subject: [issue40196] symtable.Symbol.is_local() can be True for global symbols
In-Reply-To: <1586093426.2.0.0805536970057.issue40196@roundup.psfhosted.org>
Message-ID: <1586191319.14.0.206921994731.issue40196@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset 8bd84e7f79a6cc7670a89a92edba3015aa781758 by Miss Islington (bot) in branch '3.8':
bpo-40196: Fix a bug in the symtable when reporting inspecting global variables (GH-19391) (GH-19394)
https://github.com/python/cpython/commit/8bd84e7f79a6cc7670a89a92edba3015aa781758


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40196>
_______________________________________

From report at bugs.python.org  Mon Apr  6 12:48:21 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 06 Apr 2020 16:48:21 +0000
Subject: [issue40204] Docs build error with Sphinx 3.0 due to invalid C
 declaration
In-Reply-To: <1586183568.2.0.322929459864.issue40204@roundup.psfhosted.org>
Message-ID: <1586191701.98.0.0919400558148.issue40204@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

It sounds dangerous to not pin the Sphinx version in our CI :-/ Another issue caused by CI configuration stored at the same place than the code:
https://mail.python.org/archives/list/python-committers at python.org/thread/WEU5CQKIA4LIHWHT53YA7HHNUY5H2FUT/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40204>
_______________________________________

From report at bugs.python.org  Mon Apr  6 12:52:08 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 06 Apr 2020 16:52:08 +0000
Subject: [issue40170] [C API] Make PyTypeObject structure an opaque structure
 in the public C API
In-Reply-To: <1585915023.07.0.846808236133.issue40170@roundup.psfhosted.org>
Message-ID: <1586191928.02.0.799713808734.issue40170@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> Just checked - seems to be SPECIFIC to xlc-v16 as neither xlv-v11 nor xlc-v13 have any issues building.

That sounds like an AIX specific issue. Please open a separated issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40170>
_______________________________________

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: [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 13:12:23 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Mon, 06 Apr 2020 17:12:23 +0000
Subject: [issue40208] Remove deprecated SymbolTable.has_exec
In-Reply-To: <1586192722.9.0.88612242995.issue40208@roundup.psfhosted.org>
Message-ID: <1586193143.04.0.435444078593.issue40208@roundup.psfhosted.org>


Change by Batuhan Taskaya <batuhanosmantaskaya at gmail.com>:


----------
keywords: +patch
pull_requests: +18758
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19396

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40208>
_______________________________________

From report at bugs.python.org  Mon Apr  6 13:41:11 2020
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 06 Apr 2020 17:41:11 +0000
Subject: [issue40204] Docs build error with Sphinx 3.0 due to invalid C
 declaration
In-Reply-To: <1586183568.2.0.322929459864.issue40204@roundup.psfhosted.org>
Message-ID: <1586194871.32.0.398195770531.issue40204@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch
nosy: +python-dev
nosy_count: 8.0 -> 9.0
pull_requests: +18759
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19397

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40204>
_______________________________________

From report at bugs.python.org  Mon Apr  6 14:20:31 2020
From: report at bugs.python.org (yang)
Date: Mon, 06 Apr 2020 18:20:31 +0000
Subject: [issue35212] Expressions with format specifiers in f-strings give
 wrong code position in AST
In-Reply-To: <1541939640.9.0.788709270274.issue35212@psf.upfronthosting.co.za>
Message-ID: <1586197231.37.0.0372551571652.issue35212@roundup.psfhosted.org>


Change by yang <fhsxfhsx at 126.com>:


----------
keywords: +patch
nosy: +fhsxfhsx
nosy_count: 2.0 -> 3.0
pull_requests: +18760
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19398

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35212>
_______________________________________

From report at bugs.python.org  Mon Apr  6 14:30:47 2020
From: report at bugs.python.org (Hakan)
Date: Mon, 06 Apr 2020 18:30:47 +0000
Subject: [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 14:34:25 2020
From: report at bugs.python.org (Hakan)
Date: Mon, 06 Apr 2020 18:34:25 +0000
Subject: [issue40209] read_pyfile function refactor in Lib/test/test_unparse.py
In-Reply-To: <1586197846.97.0.19099018734.issue40209@roundup.psfhosted.org>
Message-ID: <1586198065.76.0.567646511666.issue40209@roundup.psfhosted.org>


Change by Hakan <hakancelik96 at outlook.com>:


----------
keywords: +patch
pull_requests: +18761
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19399

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40209>
_______________________________________

From report at bugs.python.org  Mon Apr  6 15:22:17 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 06 Apr 2020 19:22:17 +0000
Subject: [issue40204] Docs build error with Sphinx 3.0 due to invalid C
 declaration
In-Reply-To: <1586183568.2.0.322929459864.issue40204@roundup.psfhosted.org>
Message-ID: <1586200937.88.0.531133968858.issue40204@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Maybe copy the code for deprecated and removed features to Doc/tools/extensions?

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40204>
_______________________________________

From report at bugs.python.org  Mon Apr  6 15:38:45 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 06 Apr 2020 19:38:45 +0000
Subject: [issue40209] read_pyfile function refactor in Lib/test/test_unparse.py
In-Reply-To: <1586197846.97.0.19099018734.issue40209@roundup.psfhosted.org>
Message-ID: <1586201925.88.0.991712639083.issue40209@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

You can just use open() in binary mode.

----------
nosy: +serhiy.storchaka

_______________________________________
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: [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 17:04:38 2020
From: report at bugs.python.org (neonene)
Date: Mon, 06 Apr 2020 21:04:38 +0000
Subject: [issue40082] Assertion failure in trip_signal
In-Reply-To: <1585289232.05.0.154553792707.issue40082@roundup.psfhosted.org>
Message-ID: <1586207078.43.0.960364015714.issue40082@roundup.psfhosted.org>


neonene <nicesalmon at gmail.com> added the comment:

On Windows, PyGILState_GetThisThreadState() returns NULL when ^C-interrupt occurs. It is from TlsGetValue() winAPI and I don't think the os's behevior is wrong. 
In trip_signal(), crash can be avoided by skipping PyEval_SignalReceived()  if tstate is invalid. But I'm not sure the skip itself is ok.

----------
nosy: +neonene

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40082>
_______________________________________

From report at bugs.python.org  Mon Apr  6 17:10:23 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 06 Apr 2020 21:10:23 +0000
Subject: [issue40082] Assertion failure in trip_signal
In-Reply-To: <1585289232.05.0.154553792707.issue40082@roundup.psfhosted.org>
Message-ID: <1586207423.97.0.869415915126.issue40082@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40082>
_______________________________________

From report at bugs.python.org  Mon Apr  6 17:57:11 2020
From: report at bugs.python.org (Joshua Merchant)
Date: Mon, 06 Apr 2020 21:57:11 +0000
Subject: [issue36753] Python modules not linking to libpython causes issues
 for RTLD_LOCAL system-wide
In-Reply-To: <1556554560.81.0.844742203447.issue36753@roundup.psfhosted.org>
Message-ID: <1586210231.34.0.258036156166.issue36753@roundup.psfhosted.org>


Change by Joshua Merchant <jbmercha at gmail.com>:


----------
nosy: +Joshua Merchant

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36753>
_______________________________________

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: [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 18:02:41 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Mon, 06 Apr 2020 22:02:41 +0000
Subject: [issue40211] Clarify preadv and pwritev is supported AIX 7.1 and
 newer.
In-Reply-To: <1586210459.59.0.898970260057.issue40211@roundup.psfhosted.org>
Message-ID: <1586210561.25.0.819251072032.issue40211@roundup.psfhosted.org>


Change by Batuhan Taskaya <batuhanosmantaskaya at gmail.com>:


----------
keywords: +patch
pull_requests: +18762
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19401

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40211>
_______________________________________

From report at bugs.python.org  Mon Apr  6 18:34:56 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Mon, 06 Apr 2020 22:34:56 +0000
Subject: [issue39562] Asynchronous comprehensions don't work in asyncio REPL
In-Reply-To: <1580923705.71.0.29233909242.issue39562@roundup.psfhosted.org>
Message-ID: <1586212496.82.0.820454115248.issue39562@roundup.psfhosted.org>


Batuhan Taskaya <batuhanosmantaskaya at gmail.com> added the comment:

#define IS_COMPILER_FLAG_ENABLED(c, flag) printf("%s: %d\n", #flag, c->c_flags->cf_flags & flag)

> If CO_FUTURE_DIVISION conflicts with PyCF_ALLOW_TOP_LEVEL_AWAIT, does not CO_ITERABLE_COROUTINE conflict with PyCF_SOURCE_IS_UTF8 and CO_ASYNC_GENERATOR with PyCF_DONT_IMPLY_DEDENT?

Yes, they do.

Compiling without anything
PyCF_SOURCE_IS_UTF8: 256
CO_ITERABLE_COROUTINE: 256
PyCF_DONT_IMPLY_DEDENT: 0
CO_ASYNC_GENERATOR: 0
Compiling with CO_ASYNC_GENERATOR
PyCF_SOURCE_IS_UTF8: 256
CO_ITERABLE_COROUTINE: 256
PyCF_DONT_IMPLY_DEDENT: 512
CO_ASYNC_GENERATOR: 512

This result is a side affect of merging future flags with compiler flags. Even if we access from cf_flags (or the other way around, ff_features) it doesnt change anything because we are merging both flags before we start the process. 

Two ways of escaping this is changing flags to not to conlict with each other or not merging. Not merging is out of this box because it will break user level compile function (it takes both flags in a single parameter, flags). The most reasonable solution I thought was making this flags not to conflict with each other.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39562>
_______________________________________

From report at bugs.python.org  Mon Apr  6 19:11:22 2020
From: report at bugs.python.org (Liubomyr Popil)
Date: Mon, 06 Apr 2020 23:11:22 +0000
Subject: [issue34951] cookielib/cookiejar cookies' Expires date parse fails
 with long month names
In-Reply-To: <1539158741.03.0.788709270274.issue34951@psf.upfronthosting.co.za>
Message-ID: <1586214682.49.0.973281324959.issue34951@roundup.psfhosted.org>


Liubomyr Popil <lubapopil at gmail.com> added the comment:

Hello,
I found this issue as most related to problem I was discovered:
a long name of day doesn't parsed.
According to https://tools.ietf.org/html/rfc2616#section-3.3.1:

      Sun, 06 Nov 1994 08:49:37 GMT  ; RFC 822, updated by RFC 1123
      Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036
      Sun Nov  6 08:49:37 1994       ; ANSI C's asctime() format

HTTP/1.1 clients and servers that parse the date value MUST accept
   all three formats (for compatibility with HTTP/1.0), though they MUST
   only generate the RFC 1123 format for representing HTTP-date values
   in header fields.

month format is correct, but for day part should be a both types.

Thanks,
 - Liubomyr

----------
keywords: +patch
message_count: 6.0 -> 7.0
nosy: +lpopil
nosy_count: 3.0 -> 4.0
pull_requests: +18763
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19393

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34951>
_______________________________________

From report at bugs.python.org  Mon Apr  6 20:05:01 2020
From: report at bugs.python.org (Dima Tisnek)
Date: Tue, 07 Apr 2020 00:05:01 +0000
Subject: [issue40060] socket.TCP_NOTSENT_LOWAT is missing in official macOS
 builds
In-Reply-To: <1585120826.63.0.863724436073.issue40060@roundup.psfhosted.org>
Message-ID: <1586217901.2.0.246453778422.issue40060@roundup.psfhosted.org>


Dima Tisnek <dimaqq at gmail.com> added the comment:

Thank you for the explanation, Ronald.

`socket.TCP_NOTSENT_LOWAT` is just a constant though, to be passed to `setsockopt`. 

What do you think of `ifndef ... define ...` work-around, akin to a few other constants in socket module?
https://github.com/python/cpython/blob/799d7d61a91eb0ad3256ef9a45a90029cef93b7c/Modules/socketmodule.h#L162-L168

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40060>
_______________________________________

From report at bugs.python.org  Mon Apr  6 21:38:44 2020
From: report at bugs.python.org (Dima Tisnek)
Date: Tue, 07 Apr 2020 01:38:44 +0000
Subject: [issue40060] socket.TCP_NOTSENT_LOWAT is missing in official macOS
 builds
In-Reply-To: <1585120826.63.0.863724436073.issue40060@roundup.psfhosted.org>
Message-ID: <1586223524.78.0.431028468992.issue40060@roundup.psfhosted.org>


Change by Dima Tisnek <dimaqq at gmail.com>:


----------
keywords: +patch
pull_requests: +18764
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19402

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40060>
_______________________________________

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: [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:10:36 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Tue, 07 Apr 2020 02:10:36 +0000
Subject: [issue40212] Re-enable posix_fallocate and posix_fadvise on AIX
In-Reply-To: <1586224221.66.0.805239264306.issue40212@roundup.psfhosted.org>
Message-ID: <1586225436.77.0.499072990196.issue40212@roundup.psfhosted.org>


Change by Batuhan Taskaya <batuhanosmantaskaya at gmail.com>:


----------
keywords: +patch
pull_requests: +18765
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19403

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40212>
_______________________________________

From report at bugs.python.org  Mon Apr  6 22:12:10 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Tue, 07 Apr 2020 02:12:10 +0000
Subject: [issue40212] Re-enable posix_fallocate and posix_fadvise on AIX
In-Reply-To: <1586224221.66.0.805239264306.issue40212@roundup.psfhosted.org>
Message-ID: <1586225530.32.0.201536085672.issue40212@roundup.psfhosted.org>


Change by Batuhan Taskaya <batuhanosmantaskaya at gmail.com>:


----------
nosy: +Michael.Felt

_______________________________________
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: [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 22:14:59 2020
From: report at bugs.python.org (Nathaniel Smith)
Date: Tue, 07 Apr 2020 02:14:59 +0000
Subject: [issue40213] contextlib.aclosing()
In-Reply-To: <1586225612.65.0.881233882976.issue40213@roundup.psfhosted.org>
Message-ID: <1586225699.18.0.471822702825.issue40213@roundup.psfhosted.org>


Change by Nathaniel Smith <njs at pobox.com>:


----------
nosy: +ncoghlan, yselivanov

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40213>
_______________________________________

From report at bugs.python.org  Mon Apr  6 23:01:49 2020
From: report at bugs.python.org (Mike Hommey)
Date: Tue, 07 Apr 2020 03:01:49 +0000
Subject: [issue26903] ProcessPoolExecutor(max_workers=64) crashes on Windows
In-Reply-To: <1462135538.41.0.857077084248.issue26903@psf.upfronthosting.co.za>
Message-ID: <1586228509.18.0.914875681356.issue26903@roundup.psfhosted.org>


Mike Hommey <glandium at gmail.com> added the comment:

This is still a problem in python 3.7 (and, I guess 3.8).

When not even giving a max_workers, it fails with a ValueError exception on _winapi.WaitForMultipleObjects, with the message "need at most 63 handles, got a sequence of length 63"

That happens with max_workers=None and max_workers=61 ; not max_workers=60.

I wonder if there's an off-by-one in this test: https://github.com/python/cpython/blob/7668a8bc93c2bd573716d1bea0f52ea520502b28/Modules/_winapi.c#L1708

----------
nosy: +Mike Hommey

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26903>
_______________________________________

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: [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  Mon Apr  6 23:38:40 2020
From: report at bugs.python.org (Andy Lester)
Date: Tue, 07 Apr 2020 03:38:40 +0000
Subject: [issue39943] Meta: Clean up various issues in C internals
In-Reply-To: <1583983387.49.0.277830283994.issue39943@roundup.psfhosted.org>
Message-ID: <1586230720.02.0.681262577335.issue39943@roundup.psfhosted.org>


Change by Andy Lester <andy at petdance.com>:


----------
pull_requests: +18766
pull_request: https://github.com/python/cpython/pull/19405

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39943>
_______________________________________

From report at bugs.python.org  Tue Apr  7 00:16:08 2020
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 07 Apr 2020 04:16:08 +0000
Subject: [issue40166] UNICODE HOWTO: Change the total number of code points in
 the introduction section
In-Reply-To: <1585882870.71.0.612117283125.issue40166@roundup.psfhosted.org>
Message-ID: <1586232968.45.0.166286833575.issue40166@roundup.psfhosted.org>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset 8ea10a94463f1ea217bcaef86f2ebd9d43240b4e by amaajemyfren in branch 'master':
closes bpo-40166: Change Unicode Howto so that it does not have a specific number of assigned code points. (GH-19328)
https://github.com/python/cpython/commit/8ea10a94463f1ea217bcaef86f2ebd9d43240b4e


----------
nosy: +benjamin.peterson
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40166>
_______________________________________

From report at bugs.python.org  Tue Apr  7 00:16:23 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 07 Apr 2020 04:16:23 +0000
Subject: [issue40166] UNICODE HOWTO: Change the total number of code points in
 the introduction section
In-Reply-To: <1585882870.71.0.612117283125.issue40166@roundup.psfhosted.org>
Message-ID: <1586232983.9.0.530107789973.issue40166@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
nosy: +miss-islington
nosy_count: 3.0 -> 4.0
pull_requests: +18767
pull_request: https://github.com/python/cpython/pull/19406

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40166>
_______________________________________

From report at bugs.python.org  Tue Apr  7 02:00:06 2020
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 07 Apr 2020 06:00:06 +0000
Subject: [issue40060] socket.TCP_NOTSENT_LOWAT is missing in official macOS
 builds
In-Reply-To: <1585120826.63.0.863724436073.issue40060@roundup.psfhosted.org>
Message-ID: <1586239206.62.0.0599565085015.issue40060@roundup.psfhosted.org>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I don't like that workaround. I'm also not sure if the value of these constants is the same on macOS and iOS (I do know that some constants higher up in the stack are not the same).

This issue is a duplicate of an earlier bug about missing functions that I can't find at the moment. That issue can only be solved by building on a recent enough version of macOS.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40060>
_______________________________________

From report at bugs.python.org  Tue Apr  7 02:07:37 2020
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 07 Apr 2020 06:07:37 +0000
Subject: [issue40214] test_ctypes.test_load_dll_with_flags Windows failure
In-Reply-To: <1586230066.46.0.791582618244.issue40214@roundup.psfhosted.org>
Message-ID: <1586239657.5.0.516257690864.issue40214@roundup.psfhosted.org>


Change by Zachary Ware <zachary.ware at gmail.com>:


----------
keywords: +patch
nosy: +zach.ware
nosy_count: 1.0 -> 2.0
pull_requests: +18768
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19404

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40214>
_______________________________________

From report at bugs.python.org  Tue Apr  7 02:09:28 2020
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 07 Apr 2020 06:09:28 +0000
Subject: [issue40214] test_ctypes.test_load_dll_with_flags Windows failure
In-Reply-To: <1586230066.46.0.791582618244.issue40214@roundup.psfhosted.org>
Message-ID: <1586239768.96.0.854949904652.issue40214@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

My best guess at the moment is that something changed in the underlying Windows image, particularly given the comment above the failing line that "insecure load flags should succeed" (though that could easily be a red herring).  Until someone who actually does understand what's going on here (Steve? :)) can deal with it properly, I have a PR to disable the problematic part of the test that I'll merge shortly.

----------
components: +Tests, Windows, ctypes -Library (Lib)
keywords:  -3.9regression
nosy: +paul.moore, steve.dower, tim.golden
stage: patch review -> 

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40214>
_______________________________________

From report at bugs.python.org  Tue Apr  7 02:09:53 2020
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 07 Apr 2020 06:09:53 +0000
Subject: [issue40214] test_ctypes.test_load_dll_with_flags Windows failure
In-Reply-To: <1586230066.46.0.791582618244.issue40214@roundup.psfhosted.org>
Message-ID: <1586239793.02.0.141959439483.issue40214@roundup.psfhosted.org>


Change by Zachary Ware <zachary.ware at gmail.com>:


----------
stage:  -> patch review
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40214>
_______________________________________

From report at bugs.python.org  Tue Apr  7 02:26:31 2020
From: report at bugs.python.org (Dima Tisnek)
Date: Tue, 07 Apr 2020 06:26:31 +0000
Subject: [issue40060] socket.TCP_NOTSENT_LOWAT is missing in official macOS
 builds
In-Reply-To: <1585120826.63.0.863724436073.issue40060@roundup.psfhosted.org>
Message-ID: <1586240791.43.0.776262447023.issue40060@roundup.psfhosted.org>


Dima Tisnek <dimaqq at gmail.com> added the comment:

The constant value is the same for macOS and iOS: iphone, watch, tv:

~ > locate netinet/tcp.h | xargs grep LOWAT
/Applications/Xcode.app/Contents/Developer/Platforms/AppleTVOS.platform/Developer/SDKs/AppleTVOS.sdk/usr/include/netinet/tcp.h:#define TCP_NOTSENT_LOWAT       0x201   /* Low water mark for TCP unsent data */
/Applications/Xcode.app/Contents/Developer/Platforms/AppleTVSimulator.platform/Developer/SDKs/AppleTVSimulator.sdk/usr/include/netinet/tcp.h:#define TCP_NOTSENT_LOWAT       0x201   /* Low water mark for TCP unsent data */
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/Kernel.framework/Versions/A/Headers/netinet/tcp.h:#define TCP_NOTSENT_LOWAT       0x201   /* Low water mark for TCP unsent data */
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/netinet/tcp.h:#define TCP_NOTSENT_LOWAT       0x201   /* Low water mark for TCP unsent data */
/Applications/Xcode.app/Contents/Developer/Platforms/WatchOS.platform/Developer/SDKs/WatchOS.sdk/usr/include/netinet/tcp.h:#define TCP_NOTSENT_LOWAT       0x201   /* Low water mark for TCP unsent data */
/Applications/Xcode.app/Contents/Developer/Platforms/WatchSimulator.platform/Developer/SDKs/WatchSimulator.sdk/usr/include/netinet/tcp.h:#define TCP_NOTSENT_LOWAT       0x201   /* Low water mark for TCP unsent data */
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk/usr/include/netinet/tcp.h:#define TCP_NOTSENT_LOWAT       0x201   /* Low water mark for TCP unsent data */
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk/usr/include/netinet/tcp.h:#define TCP_NOTSENT_LOWAT       0x201   /* Low water mark for TCP unsent data */
/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/System/Library/Frameworks/Kernel.framework/Versions/A/Headers/netinet/tcp.h:#define TCP_NOTSENT_LOWAT       0x201   /* Low water mark for TCP unsent data */
/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/usr/include/netinet/tcp.h:#define TCP_NOTSENT_LOWAT       0x201   /* Low water mark for TCP unsent data */
/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/System/Library/Frameworks/Kernel.framework/Versions/A/Headers/netinet/tcp.h:#define TCP_NOTSENT_LOWAT       0x201   /* Low water mark for TCP unsent data */
/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/include/netinet/tcp.h:#define TCP_NOTSENT_LOWAT       0x201   /* Low water mark for TCP unsent data */

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40060>
_______________________________________

From report at bugs.python.org  Tue Apr  7 02:40:04 2020
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 07 Apr 2020 06:40:04 +0000
Subject: [issue40214] test_ctypes.test_load_dll_with_flags Windows failure
In-Reply-To: <1586230066.46.0.791582618244.issue40214@roundup.psfhosted.org>
Message-ID: <1586241604.46.0.275201765739.issue40214@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:


New changeset f407e209c1e35b64835f73e7e7ca23e33817e9fe by Zachary Ware in branch 'master':
bpo-40214: Temporarily disable a ctypes test (GH-19404)
https://github.com/python/cpython/commit/f407e209c1e35b64835f73e7e7ca23e33817e9fe


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40214>
_______________________________________

From report at bugs.python.org  Tue Apr  7 02:40:23 2020
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 07 Apr 2020 06:40:23 +0000
Subject: [issue40214] test_ctypes.test_load_dll_with_flags Windows failure
In-Reply-To: <1586230066.46.0.791582618244.issue40214@roundup.psfhosted.org>
Message-ID: <1586241623.36.0.145719117972.issue40214@roundup.psfhosted.org>


Change by Zachary Ware <zachary.ware at gmail.com>:


----------
stage: patch review -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40214>
_______________________________________

From report at bugs.python.org  Tue Apr  7 02:54:10 2020
From: report at bugs.python.org (Ma Lin)
Date: Tue, 07 Apr 2020 06:54:10 +0000
Subject: [issue40060] socket.TCP_NOTSENT_LOWAT is missing in official macOS
 builds
In-Reply-To: <1585120826.63.0.863724436073.issue40060@roundup.psfhosted.org>
Message-ID: <1586242450.97.0.468172484753.issue40060@roundup.psfhosted.org>


Ma Lin <malincns at 163.com> added the comment:

Windows build encountered a similar problem, see issue32394.
The solution is to check the runtime system version when importing socket module, if it is an older system, delete the constants. [1]

issue32394 has a small script (winsdk_watchdog.py) to help find such constants, usage:
1, build a CPython build with old SDK.
2, use winsdk_watchdog.py, dump possible affected constants to a file `winsdk_dump.json`.
3, build a CPython build with new SDK.
4, use winsdk_watchdog.py, compare constants between two builds .

If a new constant is introduced by new SDK/API, we remove it on older system during runtime.
Otherwise we can ignore this new constant, this means it has nothing to do with the new SDK.
(msg311858 is a demo.)

We don't need to use winsdk_watchdog.py routinely, just use it when updating the building SDK, this process only takes about 10~20 minutes.

I think macOS build can also uses this process.

[1]
The commit:
https://github.com/python/cpython/commit/19e7d48ce89422091f9af93038b9fee075d46e9e

Note that there was a minor fix later:
https://github.com/python/cpython/commit/8905fcc85a6fc3ac394bc89b0bbf40897e9497a#diff-a47fd74731aeb547ad780900bb8e6953

----------
nosy: +Ma Lin

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40060>
_______________________________________

From report at bugs.python.org  Tue Apr  7 03:28:30 2020
From: report at bugs.python.org (=?utf-8?q?Alex_Gr=C3=B6nholm?=)
Date: Tue, 07 Apr 2020 07:28:30 +0000
Subject: [issue40213] contextlib.aclosing()
In-Reply-To: <1586225612.65.0.881233882976.issue40213@roundup.psfhosted.org>
Message-ID: <1586244510.79.0.0793541970576.issue40213@roundup.psfhosted.org>


Alex Gr?nholm <alex.gronholm at nextday.fi> added the comment:

Seconded.

----------
nosy: +alex.gronholm

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40213>
_______________________________________

From report at bugs.python.org  Tue Apr  7 03:45:27 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 07 Apr 2020 07:45:27 +0000
Subject: [issue40213] contextlib.aclosing()
In-Reply-To: <1586225612.65.0.881233882976.issue40213@roundup.psfhosted.org>
Message-ID: <1586245527.71.0.894427318535.issue40213@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +asvetlov

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40213>
_______________________________________

From report at bugs.python.org  Tue Apr  7 04:22:33 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 07 Apr 2020 08:22:33 +0000
Subject: [issue40204] Docs build error with Sphinx 3.0 due to invalid C
 declaration
In-Reply-To: <1586183568.2.0.322929459864.issue40204@roundup.psfhosted.org>
Message-ID: <1586247753.88.0.955725220858.issue40204@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

The sphinx version is not pinned in 3.7, 3.6, 3.5 and 2.7 branches too for Doc/Makefile that can cause error on someone trying it out locally. They are pinned in .travis.yml and .azure-pipelines configurations.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40204>
_______________________________________

From report at bugs.python.org  Tue Apr  7 04:26:15 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 07 Apr 2020 08:26:15 +0000
Subject: [issue39966] mock 3.9 bug: Wrapped objects without __bool__ raise
 exception
In-Reply-To: <1584254384.28.0.0187140133308.issue39966@roundup.psfhosted.org>
Message-ID: <1586247975.73.0.486181560895.issue39966@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39966>
_______________________________________

From report at bugs.python.org  Tue Apr  7 04:41:21 2020
From: report at bugs.python.org (Dima Tisnek)
Date: Tue, 07 Apr 2020 08:41:21 +0000
Subject: [issue40060] socket.TCP_NOTSENT_LOWAT is missing in official macOS
 builds
In-Reply-To: <1585120826.63.0.863724436073.issue40060@roundup.psfhosted.org>
Message-ID: <1586248881.17.0.35696600075.issue40060@roundup.psfhosted.org>


Dima Tisnek <dimaqq at gmail.com> added the comment:

Wow, very curious.

Yes, it's very much like `socket.TCP_KEEPCNT` in that respect, though, admittedly I don't have a very old Mac to test this right now. I think there were VMs for that maybe? ?



I wonder, what failure would be best for a naive code below, a NameError or OSError(errno=42)?

sock.setsockopt(socket.SOL_TCP, socket.TCP_NOTSENT_LOWAT, 42)

I guess the question is, at what level should the users catch exceptions...
After all, we don't delete this constant on Linux, and surely someone somewhere runs a very old kernel...



Oddly according to https://github.com/search?l=Python&q=%22socket.TCP_NOTSENT_LOWAT%22&type=Code none (in the OSS community) appears to be using this feature yet?

The search without `socket.` prefix yields a bunch of vendored mypy pyi's, but no actual code either.

And some even work around the constant being optional: https://github.com/python-trio/trio/blob/5b91edb2a860d024ab057e2be55fb34f311bf8ed/trio/socket.py#L170-L178



So, would this be a "not a regression" if none appears to use this constant yet?

Or do we take "don't break existing code" so seriously, that in this case too, we ought to assume that there's someone out there who has private code like below which we must not break?:

if code := getattr(socket, "TCP_NOTSENT_LOWAT", None):
    sock.setsockopt(socket.SOL_TCP, code, 42)



P.S.
If someone wants to take https://github.com/python/cpython/pull/19402 forward, by all means :)
Or I can try to hack up delete-at-runtime...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40060>
_______________________________________

From report at bugs.python.org  Tue Apr  7 04:57:12 2020
From: report at bugs.python.org (Michael Felt)
Date: Tue, 07 Apr 2020 08:57:12 +0000
Subject: [issue40112] AIX: xlc - default path changed and no longer recognized
In-Reply-To: <1585567095.85.0.705098258477.issue40112@roundup.psfhosted.org>
Message-ID: <1586249832.83.0.716719792209.issue40112@roundup.psfhosted.org>


Michael Felt <aixtools at felt.demon.nl> added the comment:

requesting backport of PR19225.

After switching my bot to xlc-v13 it fails this test.

See botstatus mail excerpt:

The Buildbot has detected a failed build on builder POWER6 AIX 3.8 while building python/cpython.
Full details are available at:
    https://buildbot.python.org/all/#builders/181/builds/216

Buildbot URL: https://buildbot.python.org/all/

Worker for this Build: aixtools-aix-power6

Build Reason: <unknown>
Blamelist: Miss Islington (bot) <31488909+miss-islington at users.noreply.github.com>

BUILD FAILED: failed test (failure)


Summary of the results of the build (if available):
===================================================

== Tests result: FAILURE then FAILURE ==

404 tests OK.

10 slowest tests:
- test_multiprocessing_spawn: 2 min 49 sec
- test_concurrent_futures: 2 min 46 sec
- test_bufio: 2 min 18 sec
- test_subprocess: 2 min 4 sec
- test_tokenize: 1 min 43 sec
- test_multiprocessing_forkserver: 1 min 41 sec
- test_tools: 1 min 39 sec
- test_pathlib: 1 min 35 sec
- test_multiprocessing_fork: 1 min 31 sec
- test_ssl: 1 min 23 sec

1 test failed:
    test_distutils

----------
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40112>
_______________________________________

From report at bugs.python.org  Tue Apr  7 04:58:51 2020
From: report at bugs.python.org (Michael Felt)
Date: Tue, 07 Apr 2020 08:58:51 +0000
Subject: [issue37009] Threading and THREAD_SAFE for AIX
In-Reply-To: <1558526469.21.0.552690908728.issue37009@roundup.psfhosted.org>
Message-ID: <1586249931.02.0.0916697728792.issue37009@roundup.psfhosted.org>


Michael Felt <aixtools at felt.demon.nl> added the comment:

Yes, looks like I need to find that. thx for the reminder.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37009>
_______________________________________

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: [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 06:04:51 2020
From: report at bugs.python.org (Kyle Stanley)
Date: Tue, 07 Apr 2020 10:04:51 +0000
Subject: [issue40214] test_ctypes.test_load_dll_with_flags Windows failure
In-Reply-To: <1586230066.46.0.791582618244.issue40214@roundup.psfhosted.org>
Message-ID: <1586253891.51.0.743503066108.issue40214@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:

Zachary Ware wrote:
> My best guess at the moment is that something changed in the underlying Windows image, particularly given the comment above the failing line that "insecure load flags should succeed" (though that could easily be a red herring).

Also, now that I think about it, the the test failure has only specifically occurred on Azure Pipelines and not on the GitHub Actions Windows PR tests (as far as I have seen), which does further increase the likelihood that it's an issue with the Windows image being used in Azure for the PR tests.

Regardless of the cause though, thanks for applying a temporary fix/skip in the meantime, these types of issues can be troublesome for CPython's workflow when it occurs on required CI checks. Hopefully Steve Dower or someone similarly knowledgeable in the area can definitively figure out the cause.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40214>
_______________________________________

From report at bugs.python.org  Tue Apr  7 06:25:16 2020
From: report at bugs.python.org (Steve Dower)
Date: Tue, 07 Apr 2020 10:25:16 +0000
Subject: [issue26903] ProcessPoolExecutor(max_workers=64) crashes on Windows
In-Reply-To: <1462135538.41.0.857077084248.issue26903@psf.upfronthosting.co.za>
Message-ID: <1586255116.5.0.62462723477.issue26903@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

More likely there's been another change to the events that are listened to by multiprocessing, which didn't update the overall limit.

File a new bug, please.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26903>
_______________________________________

From report at bugs.python.org  Tue Apr  7 06:29:24 2020
From: report at bugs.python.org (Steve Dower)
Date: Tue, 07 Apr 2020 10:29:24 +0000
Subject: [issue40214] test_ctypes.test_load_dll_with_flags Windows failure
In-Reply-To: <1586230066.46.0.791582618244.issue40214@roundup.psfhosted.org>
Message-ID: <1586255364.5.0.712132326305.issue40214@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Maybe something else was installed that put an incompatible _sqlite3.dll on PATH? Thereby proving the inherent risk of using unsafe DLL load settings :)

If we're not already overriding PATH for the subprocess in this test (should only need "%SystemRoot%;%SystemRoot%\System32"), we may have to. Though if someone is installing an incompatible _sqlite3.dll into a system directory then we're in a bit of trouble.

Disabling this part of the test as inherently untestable because it's an inherently unsafe operation is fine by me :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40214>
_______________________________________

From report at bugs.python.org  Tue Apr  7 06:44:05 2020
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 07 Apr 2020 10:44:05 +0000
Subject: [issue40206] Multiplying 4.6*100 will result in 459.99999999999994
In-Reply-To: <1586186268.64.0.709905151161.issue40206@roundup.psfhosted.org>
Message-ID: <1586256245.07.0.189420595344.issue40206@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:

You can also set the decimal.FloatOperation trap to avoid accidental
errors:

>>> from decimal import *
>>> c = getcontext()
>>> Decimal(4.6) * 100
Decimal('459.9999999999999644728632120')

>>> c.traps[FloatOperation] = True
>>> Decimal(4.6) * 100
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
decimal.FloatOperation: [<class 'decimal.FloatOperation'>]

>>> Decimal("4.6") * 100
Decimal('460.0')
>>>

----------
nosy: +skrah

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40206>
_______________________________________

From report at bugs.python.org  Tue Apr  7 07:10:46 2020
From: report at bugs.python.org (Maciej Olko)
Date: Tue, 07 Apr 2020 11:10:46 +0000
Subject: [issue40204] Docs build error with Sphinx 3.0 due to invalid C
 declaration
In-Reply-To: <1586183568.2.0.322929459864.issue40204@roundup.psfhosted.org>
Message-ID: <1586257846.41.0.371872040433.issue40204@roundup.psfhosted.org>


Change by Maciej Olko <maciej.olko at gmail.com>:


----------
nosy: +Maciej Olko

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40204>
_______________________________________

From report at bugs.python.org  Tue Apr  7 08:02:16 2020
From: report at bugs.python.org (Piotr Dobrogost)
Date: Tue, 07 Apr 2020 12:02:16 +0000
Subject: [issue5654] Add C hook in PyDict_SetItem for debuggers
In-Reply-To: <1238604905.42.0.578461685574.issue5654@psf.upfronthosting.co.za>
Message-ID: <1586260936.89.0.813599482132.issue5654@roundup.psfhosted.org>


Change by Piotr Dobrogost <bugs.python.org at p.dobrogost.net>:


----------
nosy: +piotr.dobrogost

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue5654>
_______________________________________

From report at bugs.python.org  Tue Apr  7 08:59:46 2020
From: report at bugs.python.org (Mats Wichmann)
Date: Tue, 07 Apr 2020 12:59:46 +0000
Subject: [issue26628] Undefined behavior calling C functions with ctypes.Union
 arguments
In-Reply-To: <1458766336.13.0.0388960184699.issue26628@psf.upfronthosting.co.za>
Message-ID: <1586264386.57.0.760713962221.issue26628@roundup.psfhosted.org>


Mats Wichmann <mats at python.org> added the comment:

For readers who got here via a search after hitting the new traceback, note the fix in bpo-16575 was reverted. It's still a duplicate issue, so follow the progress there.

----------
nosy: +mwichmann

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26628>
_______________________________________

From report at bugs.python.org  Tue Apr  7 09:26:04 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 07 Apr 2020 13:26:04 +0000
Subject: [issue40112] AIX: xlc - default path changed and no longer recognized
In-Reply-To: <1585567095.85.0.705098258477.issue40112@roundup.psfhosted.org>
Message-ID: <1586265964.45.0.415025956419.issue40112@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
nosy: +miss-islington
nosy_count: 4.0 -> 5.0
pull_requests: +18769
pull_request: https://github.com/python/cpython/pull/19408

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40112>
_______________________________________

From report at bugs.python.org  Tue Apr  7 09:28:52 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 07 Apr 2020 13:28:52 +0000
Subject: [issue5654] Add C hook in PyDict_SetItem for debuggers
In-Reply-To: <1238604905.42.0.578461685574.issue5654@psf.upfronthosting.co.za>
Message-ID: <1586266132.52.0.522405028962.issue5654@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

No activity for 9 years, I close the issue.

----------
resolution:  -> rejected
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue5654>
_______________________________________

From report at bugs.python.org  Tue Apr  7 09:45:24 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 07 Apr 2020 13:45:24 +0000
Subject: [issue37388] unknown error handlers should be reported early
In-Reply-To: <1561385452.16.0.600106929179.issue37388@roundup.psfhosted.org>
Message-ID: <1586267124.33.0.389770500055.issue37388@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +18770
pull_request: https://github.com/python/cpython/pull/19409

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37388>
_______________________________________

From report at bugs.python.org  Tue Apr  7 10:07:50 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 07 Apr 2020 14:07:50 +0000
Subject: [issue37388] unknown error handlers should be reported early
In-Reply-To: <1561385452.16.0.600106929179.issue37388@roundup.psfhosted.org>
Message-ID: <1586268470.68.0.512742657604.issue37388@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset d8acf0d9aae71d1897e8f91989bd8bfb4a9ef9c6 by Victor Stinner in branch 'master':
bpo-37388: Don't check encoding/errors during finalization (GH-19409)
https://github.com/python/cpython/commit/d8acf0d9aae71d1897e8f91989bd8bfb4a9ef9c6


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37388>
_______________________________________

From report at bugs.python.org  Tue Apr  7 10:44:27 2020
From: report at bugs.python.org (Petr Viktorin)
Date: Tue, 07 Apr 2020 14:44:27 +0000
Subject: [issue37207] Use PEP 590 vectorcall to speed up calls to range(),
 list() and dict()
In-Reply-To: <1560072227.25.0.180298594259.issue37207@roundup.psfhosted.org>
Message-ID: <1586270667.14.0.746343251704.issue37207@roundup.psfhosted.org>


Petr Viktorin <encukou at gmail.com> added the comment:

As discussed briefly in Mark's PR, benchmarks like this are now slower:

    ret = dict(**{'a': 2, 'b': 4, 'c': 6, 'd': 8})


Python 3.8: Mean +- std dev: 281 ns +- 9 ns
    master: Mean +- std dev: 456 ns +- 14 ns

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37207>
_______________________________________

From report at bugs.python.org  Tue Apr  7 10:45:54 2020
From: report at bugs.python.org (Ma Lin)
Date: Tue, 07 Apr 2020 14:45:54 +0000
Subject: [issue40060] socket.TCP_NOTSENT_LOWAT is missing in official macOS
 builds
In-Reply-To: <1585120826.63.0.863724436073.issue40060@roundup.psfhosted.org>
Message-ID: <1586270754.65.0.121620772153.issue40060@roundup.psfhosted.org>


Ma Lin <malincns at 163.com> added the comment:

It seems that people usually use the socket module like this, I think it's safe to respect this habit:

    if hasattr(socket, "FLAG_NAME"):
        do_something

If use PR19402, your program will have problem on the older version system, not only "don't break existing code".

So I think delete-at-runtime is a suitable way.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40060>
_______________________________________

From report at bugs.python.org  Tue Apr  7 11:12:29 2020
From: report at bugs.python.org (Petr Viktorin)
Date: Tue, 07 Apr 2020 15:12:29 +0000
Subject: [issue39689] struct and memoryview tests rely on undefined behavior
 (as revealed by clang 9)
In-Reply-To: <1582124509.96.0.385275594117.issue39689@roundup.psfhosted.org>
Message-ID: <1586272349.8.0.90823238823.issue39689@roundup.psfhosted.org>


Change by Petr Viktorin <encukou at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39689>
_______________________________________

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: [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 11:28:13 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Tue, 07 Apr 2020 15:28:13 +0000
Subject: [issue40216] Support --runstatedir in configure
In-Reply-To: <1586273076.51.0.57389457106.issue40216@roundup.psfhosted.org>
Message-ID: <1586273293.01.0.344570521549.issue40216@roundup.psfhosted.org>


Change by Batuhan Taskaya <batuhanosmantaskaya at gmail.com>:


----------
keywords: +patch
pull_requests: +18771
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19411

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40216>
_______________________________________

From report at bugs.python.org  Tue Apr  7 11:42:56 2020
From: report at bugs.python.org (Eryk Sun)
Date: Tue, 07 Apr 2020 15:42:56 +0000
Subject: [issue40214] test_ctypes.test_load_dll_with_flags Windows failure
In-Reply-To: <1586230066.46.0.791582618244.issue40214@roundup.psfhosted.org>
Message-ID: <1586274176.76.0.847832233735.issue40214@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> Maybe something else was installed that put an incompatible 
> _sqlite3.dll on PATH? Thereby proving the inherent risk of 
> using unsafe DLL load settings 

should_pass() sets the working directory of the test process to the `tmp` directory. The loader normally checks the working directory before PATH. But maybe the system itself is configured to disallow loading DLLs from the working directory. There's a registry setting for that, but it's little known and rarely used because it's disruptive in general.

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40214>
_______________________________________

From report at bugs.python.org  Tue Apr  7 12:05:55 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 07 Apr 2020 16:05:55 +0000
Subject: [issue40149] test_threading leaked [38, 38, 38] references, sum=114
In-Reply-To: <1585792445.62.0.0518463995906.issue40149@roundup.psfhosted.org>
Message-ID: <1586275555.67.0.86486493604.issue40149@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
keywords: +patch
pull_requests: +18772
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19412

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40149>
_______________________________________

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: [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 12:30:03 2020
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 07 Apr 2020 16:30:03 +0000
Subject: [issue40214] test_ctypes.test_load_dll_with_flags Windows failure
In-Reply-To: <1586230066.46.0.791582618244.issue40214@roundup.psfhosted.org>
Message-ID: <1586277003.38.0.771846009903.issue40214@roundup.psfhosted.org>


Change by Zachary Ware <zachary.ware at gmail.com>:


----------
pull_requests: +18773
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/19413

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40214>
_______________________________________

From report at bugs.python.org  Tue Apr  7 12:30:43 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Tue, 07 Apr 2020 16:30:43 +0000
Subject: [issue40217] The garbage collector doesn't take in account that
 objects of heap allocated types hold a strong reference to their type
In-Reply-To: <1586276621.78.0.843757244355.issue40217@roundup.psfhosted.org>
Message-ID: <1586277043.97.0.930315069175.issue40217@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
nosy: +corona10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40217>
_______________________________________

From report at bugs.python.org  Tue Apr  7 12:36:11 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 07 Apr 2020 16:36:11 +0000
Subject: [issue40149] test_threading leaked [38, 38, 38] references, sum=114
In-Reply-To: <1585792445.62.0.0518463995906.issue40149@roundup.psfhosted.org>
Message-ID: <1586277371.01.0.0384868214564.issue40149@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 9cc3ebd7e04cb645ac7b2f372eaafa7464e16b9c by Victor Stinner in branch 'master':
bpo-40149: Implement traverse in _abc._abc_data (GH-19412)
https://github.com/python/cpython/commit/9cc3ebd7e04cb645ac7b2f372eaafa7464e16b9c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40149>
_______________________________________

From report at bugs.python.org  Tue Apr  7 12:49:45 2020
From: report at bugs.python.org (hai shi)
Date: Tue, 07 Apr 2020 16:49:45 +0000
Subject: [issue40217] The garbage collector doesn't take in account that
 objects of heap allocated types hold a strong reference to their type
In-Reply-To: <1586276621.78.0.843757244355.issue40217@roundup.psfhosted.org>
Message-ID: <1586278185.41.0.917000692615.issue40217@roundup.psfhosted.org>


Change by hai shi <shihai1991 at 126.com>:


----------
nosy: +shihai1991

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40217>
_______________________________________

From report at bugs.python.org  Tue Apr  7 12:50:05 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 07 Apr 2020 16:50:05 +0000
Subject: [issue40149] test_threading leaked [38, 38, 38] references, sum=114
In-Reply-To: <1585792445.62.0.0518463995906.issue40149@roundup.psfhosted.org>
Message-ID: <1586278205.49.0.505383041785.issue40149@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

In _abcmodule_exec(), when _abc_data type is created, it's created with refcnt=3:
* 1 strong reference (normal)
* +1 ref from tp_dict['__new__'] slot
* +1 ref from tp_mro

type_traverse() visits tp_dict and tp_mro, so it's fine.

In Py_EndInterpreter(), PyInterpreterState_Clear() clears os.register_atfork() callbacks which were one of the last references to _abc_data type. The first call to _PyGC_CollectNoFail() destroys _abc_data *instances* but not the _abc_data type.

The following patch works around the issue:

diff --git a/Modules/_abc.c b/Modules/_abc.c
index 1efc98bf72..410dbcf96a 100644
--- a/Modules/_abc.c
+++ b/Modules/_abc.c
@@ -54,6 +54,7 @@ typedef struct {
 static int
 abc_data_traverse(_abc_data *self, visitproc visit, void *arg)
 {
+    Py_VISIT(Py_TYPE(self));
     Py_VISIT(self->_abc_registry);
     Py_VISIT(self->_abc_cache);
     Py_VISIT(self->_abc_negative_cache);


$ ./python -m test -R 3:3 test_threading -m test.test_threading.SubinterpThreadingTests.test_threads_join_2
(...)
Tests result: SUCCESS


I'm not sure why Py_VISIT(Py_TYPE(self)) is needed. Maybe it's a regression caused by commit 364f0b0f19cc3f0d5e63f571ec9163cf41c62958 of bpo-35810.

It sems like the GC doesn't take in account that instances of types allocated on the heap (if type->tp_flags has the Py_TPFLAGS_HEAPTYPE flag) hold a strong refeference to the type (PyObject.ob_type).

I created bpo-40217: "The garbage collector doesn't take in account that objects of heap allocated types hold a strong reference to their type".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40149>
_______________________________________

From report at bugs.python.org  Tue Apr  7 12:50:09 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 07 Apr 2020 16:50:09 +0000
Subject: [issue39481] Implement PEP 585 (Type Hinting Generics In Standard
 Collections)
In-Reply-To: <1580231817.93.0.47144630055.issue39481@roundup.psfhosted.org>
Message-ID: <1586278209.45.0.675927746295.issue39481@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:


New changeset 48b069a003ba6c684a9ba78493fbbec5e89f10b8 by Guido van Rossum in branch 'master':
bpo-39481: Implementation for PEP 585 (#18239)
https://github.com/python/cpython/commit/48b069a003ba6c684a9ba78493fbbec5e89f10b8


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39481>
_______________________________________

From report at bugs.python.org  Tue Apr  7 12:51:35 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Tue, 07 Apr 2020 16:51:35 +0000
Subject: [issue40149] test_threading leaked [38, 38, 38] references, sum=114
In-Reply-To: <1585792445.62.0.0518463995906.issue40149@roundup.psfhosted.org>
Message-ID: <1586278295.88.0.464582869183.issue40149@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

Wow Thank you for the summary :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40149>
_______________________________________

From report at bugs.python.org  Tue Apr  7 12:51:56 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 07 Apr 2020 16:51:56 +0000
Subject: [issue39481] Implement PEP 585 (Type Hinting Generics In Standard
 Collections)
In-Reply-To: <1580231817.93.0.47144630055.issue39481@roundup.psfhosted.org>
Message-ID: <1586278316.06.0.987674049873.issue39481@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

The base implementation has landed. We still need docs, and I'm sure that the alpha and beta release cycle will find small things that need to be improved.

Perhaps the next priority is an update for Doc/whatsnew/3.9.rst.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39481>
_______________________________________

From report at bugs.python.org  Tue Apr  7 12:53:23 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 07 Apr 2020 16:53:23 +0000
Subject: [issue40112] AIX: xlc - default path changed and no longer recognized
In-Reply-To: <1585567095.85.0.705098258477.issue40112@roundup.psfhosted.org>
Message-ID: <1586278403.75.0.0869724119686.issue40112@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

The CI failed on my backport to 3.8: PR 19408.

The CI failed because of bpo-40204.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40112>
_______________________________________

From report at bugs.python.org  Tue Apr  7 12:54:33 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 07 Apr 2020 16:54:33 +0000
Subject: [issue40217] The garbage collector doesn't take in account that
 objects of heap allocated types hold a strong reference to their type
In-Reply-To: <1586276621.78.0.843757244355.issue40217@roundup.psfhosted.org>
Message-ID: <1586278473.59.0.118485211714.issue40217@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

> I propose to modify the GC to take bpo-35810 in account.

What? The GC is agnostic of what it receives. It works with objects in general that implement the gc support, but it does not care about what those objects are. The only specal case are weakreferences and because those have inherit GC semantics.

I am not sure about what you are proposing, could you elaborate?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40217>
_______________________________________

From report at bugs.python.org  Tue Apr  7 12:58:08 2020
From: report at bugs.python.org (hai shi)
Date: Tue, 07 Apr 2020 16:58:08 +0000
Subject: [issue40149] test_threading leaked [38, 38, 38] references, sum=114
In-Reply-To: <1585792445.62.0.0518463995906.issue40149@roundup.psfhosted.org>
Message-ID: <1586278688.23.0.0284870969241.issue40149@roundup.psfhosted.org>


Change by hai shi <shihai1991 at 126.com>:


----------
nosy: +shihai1991

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40149>
_______________________________________

From report at bugs.python.org  Tue Apr  7 13:03:29 2020
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 07 Apr 2020 17:03:29 +0000
Subject: [issue40214] test_ctypes.test_load_dll_with_flags Windows failure
In-Reply-To: <1586230066.46.0.791582618244.issue40214@roundup.psfhosted.org>
Message-ID: <1586279009.53.0.692454166635.issue40214@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

Assuming I implemented my checks correctly (see PR19413), I think I've just debunked both of our leading theories.

Results here: https://dev.azure.com/Python/cpython/_build/results?buildId=60764&view=logs&j=d554cd63-f8f4-5b2d-871b-33e4ea76e915&t=5a14d0eb-dbd4-5b80-f5d0-7909f950a1cc

----------
stage: patch review -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40214>
_______________________________________

From report at bugs.python.org  Tue Apr  7 13:18:25 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Tue, 07 Apr 2020 17:18:25 +0000
Subject: [issue23224] bz2/lzma: Compressor/Decompressor objects are only
 initialized in __init__
In-Reply-To: <1421024308.33.0.868171678499.issue23224@psf.upfronthosting.co.za>
Message-ID: <1586279905.04.0.740617705143.issue23224@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
nosy: +corona10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23224>
_______________________________________

From report at bugs.python.org  Tue Apr  7 13:18:57 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Tue, 07 Apr 2020 17:18:57 +0000
Subject: [issue23224] bz2/lzma: Compressor/Decompressor objects are only
 initialized in __init__
In-Reply-To: <1421024308.33.0.868171678499.issue23224@psf.upfronthosting.co.za>
Message-ID: <1586279937.05.0.0651884754838.issue23224@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
versions: +Python 3.9 -Python 2.7, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23224>
_______________________________________

From report at bugs.python.org  Tue Apr  7 13:20:19 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Tue, 07 Apr 2020 17:20:19 +0000
Subject: [issue23224] bz2/lzma: Compressor/Decompressor objects are only
 initialized in __init__
In-Reply-To: <1421024308.33.0.868171678499.issue23224@psf.upfronthosting.co.za>
Message-ID: <1586280019.64.0.0235816018436.issue23224@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

The issue is not solved yet.
@ZackerySpytz would you like to finalize this issue?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23224>
_______________________________________

From report at bugs.python.org  Tue Apr  7 13:20:27 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 07 Apr 2020 17:20:27 +0000
Subject: [issue40217] The garbage collector doesn't take in account that
 objects of heap allocated types hold a strong reference to their type
In-Reply-To: <1586276621.78.0.843757244355.issue40217@roundup.psfhosted.org>
Message-ID: <1586280027.99.0.10843733759.issue40217@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Also, heap types (created with type_new()) are already taking into account the type when visiting references:

https://github.com/python/cpython/blob/master/Objects/typeobject.c#L1111

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40217>
_______________________________________

From report at bugs.python.org  Tue Apr  7 13:22:39 2020
From: report at bugs.python.org (Tim Peters)
Date: Tue, 07 Apr 2020 17:22:39 +0000
Subject: [issue40217] The garbage collector doesn't take in account that
 objects of heap allocated types hold a strong reference to their type
In-Reply-To: <1586276621.78.0.843757244355.issue40217@roundup.psfhosted.org>
Message-ID: <1586280159.79.0.950758508198.issue40217@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

If object A owns a strong reference to object B, and A participates in cyclic gc, and B may be part of a cycle, then it's necessary and sufficient that A's type's tp_traverse implementation invoke Py_VISIT() passing A's pointer to B.

It would be a Really Bad Idea to add special cases to the gc module to spare some specific type(s) from following that (currently) utterly uniform rule.

----------
nosy: +tim.peters

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40217>
_______________________________________

From report at bugs.python.org  Tue Apr  7 13:28:47 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 07 Apr 2020 17:28:47 +0000
Subject: [issue40217] The garbage collector doesn't take in account that
 objects of heap allocated types hold a strong reference to their type
In-Reply-To: <1586276621.78.0.843757244355.issue40217@roundup.psfhosted.org>
Message-ID: <1586280527.82.0.160056104493.issue40217@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

It would be inconvenient to require adding Py_VISIT(Py_TYPE(self)) in all tp_visit implementations of heap allocated types (including third-party extensions). Since tp_visit is GC specific thing, I think it wold be more convenient make a special case for object types.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40217>
_______________________________________

From report at bugs.python.org  Tue Apr  7 13:35:41 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 07 Apr 2020 17:35:41 +0000
Subject: [issue40217] The garbage collector doesn't take in account that
 objects of heap allocated types hold a strong reference to their type
In-Reply-To: <1586276621.78.0.843757244355.issue40217@roundup.psfhosted.org>
Message-ID: <1586280941.83.0.314086783833.issue40217@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

>>> Since tp_visit is GC specific thing, I think it wold be more convenient make a special case for object types.

I don't think that follows: The gc defers the logic of what and what should not be visited to the tp_traverse implementation of every object. The GC must be agnostic of the types it receives and heap types here are not special.

--

Also, if we make an exception in the GC for this special case, all tp_traverse of all those functions will be incorrect. Someone reading those tp_traverse can say "Oh, why these functions do not visit the type if they own s reference to it, this looks incorrect" and then we need to explain that that is an exception in the GC just because we were lazy to implement them correctly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40217>
_______________________________________

From report at bugs.python.org  Tue Apr  7 13:36:01 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 07 Apr 2020 17:36:01 +0000
Subject: [issue40217] The garbage collector doesn't take in account that
 objects of heap allocated types hold a strong reference to their type
In-Reply-To: <1586276621.78.0.843757244355.issue40217@roundup.psfhosted.org>
Message-ID: <1586280961.21.0.981951407608.issue40217@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Interesting, this issue may be related to issue24379. The problem with the proposed implementation of subscript was that it created a reference loop, and not all links in this loop were visible by GC.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40217>
_______________________________________

From report at bugs.python.org  Tue Apr  7 13:37:32 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 07 Apr 2020 17:37:32 +0000
Subject: [issue40217] The garbage collector doesn't take in account that
 objects of heap allocated types hold a strong reference to their type
In-Reply-To: <1586276621.78.0.843757244355.issue40217@roundup.psfhosted.org>
Message-ID: <1586281052.1.0.332976977998.issue40217@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Also, as I mentioned, you don't need to modify all objects tp_traverse, only it's type.tp_traverse slot. For instance, all python objects know how to traverse stuff because they share the same tp_traverse:

https://github.com/python/cpython/blob/master/Objects/typeobject.c#L1082

So unless I am missing something, if you want to affect all heap types you just need to modify one tp_traverse in one place: the superclass.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40217>
_______________________________________

From report at bugs.python.org  Tue Apr  7 13:41:28 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 07 Apr 2020 17:41:28 +0000
Subject: [issue40217] The garbage collector doesn't take in account that
 objects of heap allocated types hold a strong reference to their type
In-Reply-To: <1586276621.78.0.843757244355.issue40217@roundup.psfhosted.org>
Message-ID: <1586281288.12.0.877372072663.issue40217@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Hummm, I think we may just be missing a Py_VISIT(Py_TYPE(self))here:

https://github.com/python/cpython/blob/master/Objects/typeobject.c#L3562

A class owns references to its type (type) or another metaclass

Tim, could you confirm that that is the case?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40217>
_______________________________________

From report at bugs.python.org  Tue Apr  7 13:47:11 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 07 Apr 2020 17:47:11 +0000
Subject: [issue40217] The garbage collector doesn't take in account that
 objects of heap allocated types hold a strong reference to their type
In-Reply-To: <1586276621.78.0.843757244355.issue40217@roundup.psfhosted.org>
Message-ID: <1586281631.98.0.0138809988953.issue40217@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

> Hummm, I think we may just be missing a Py_VISIT(Py_TYPE(self))here:

Checking it more closely, that is incorrect, so we are not missing that visitation :(

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40217>
_______________________________________

From report at bugs.python.org  Tue Apr  7 13:48:08 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 07 Apr 2020 17:48:08 +0000
Subject: [issue40217] The garbage collector doesn't take in account that
 objects of heap allocated types hold a strong reference to their type
In-Reply-To: <1586276621.78.0.843757244355.issue40217@roundup.psfhosted.org>
Message-ID: <1586281688.26.0.0176945304853.issue40217@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Recently many static allocated types were converted to heap allocated types (using PyType_FromSpec). Now you need to add Py_VISIT(Py_TYPE(self)) in all corresponding tp_visit implementations.

And since even official example for heap allocated types do not contain it (and it was not needed before 3.9), I am sure that all existing code do not contain it.

We cannot change all user code, so we should change the interpreter code so that it will work correctly with existing user code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40217>
_______________________________________

From report at bugs.python.org  Tue Apr  7 13:52:01 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 07 Apr 2020 17:52:01 +0000
Subject: [issue40217] The garbage collector doesn't take in account that
 objects of heap allocated types hold a strong reference to their type
In-Reply-To: <1586276621.78.0.843757244355.issue40217@roundup.psfhosted.org>
Message-ID: <1586281921.36.0.0264609208243.issue40217@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

> We cannot change all user code, so we should change the interpreter code so that it will work correctly with existing user code.

If we made a change that make all user code suddenly incorrect, that change should be reverted. The GC has clear rules about what tp_traverse should and should not do, and we should not violate those rules and make special cases in the gc just because we forced some classes to be incorrect. This will make much more difficult to reason about GC bugs, the tp_traverse implementation of classes and much difficult to maintain the GC itself.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40217>
_______________________________________

From report at bugs.python.org  Tue Apr  7 14:03:58 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 07 Apr 2020 18:03:58 +0000
Subject: [issue40217] The garbage collector doesn't take in account that
 objects of heap allocated types hold a strong reference to their type
In-Reply-To: <1586276621.78.0.843757244355.issue40217@roundup.psfhosted.org>
Message-ID: <1586282638.67.0.297684829548.issue40217@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

The problem is that we suddenly changed rules. It was not required that the object's type should be visited in tp_visit. It was incorrect to visit it, because object did not have strong reference to its type. User never created it, and it was not created implicitly.

Now we changed rules. A strong reference is created implicitly. Who is responsible to manage a strong reference? Whose who created it, ant it is the interpreter, not the user. User does not know anything about it. If we pass the responsibility for the strong reference to the type on the user, we makes all user code incorrect, and we add a burden of fixing it and maintaining compatibility with incompatible Python versions on the user. I think it is very bad.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40217>
_______________________________________

From report at bugs.python.org  Tue Apr  7 14:15:28 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 07 Apr 2020 18:15:28 +0000
Subject: [issue40217] The garbage collector doesn't take in account that
 objects of heap allocated types hold a strong reference to their type
In-Reply-To: <1586276621.78.0.843757244355.issue40217@roundup.psfhosted.org>
Message-ID: <1586283328.97.0.26511764093.issue40217@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

> Now we changed rules. A strong reference is created implicitly. Who is responsible to manage a strong reference? Whose who created it, ant it is the interpreter, not the user.

Even if we decide that the patch that introduced the new rules should not be reverted, then what we should do is wrap the tp_traverse of the user in something that also calls Py_VISIT(Py_TYPE(self)) so basically the tp_traverse of the type created by PyType_FromSpec will do

static int
PyType_FromSpec_tp_traverse(_abc_data *self, visitproc visit, void *arg)
{
    Py_VISIT(Py_TYPE(self))
    return self->user_provided_tp_traverse(self, visit, arg);
}

That way, we can still reason about what the tp_traverse should do, we don't break more rules and we don't need to make maintaining the GC even more difficult.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40217>
_______________________________________

From report at bugs.python.org  Tue Apr  7 15:16:32 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 07 Apr 2020 19:16:32 +0000
Subject: [issue40217] The garbage collector doesn't take in account that
 objects of heap allocated types hold a strong reference to their type
In-Reply-To: <1586276621.78.0.843757244355.issue40217@roundup.psfhosted.org>
Message-ID: <1586286992.13.0.698807938355.issue40217@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
keywords: +patch
pull_requests: +18774
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19414

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40217>
_______________________________________

From report at bugs.python.org  Tue Apr  7 15:17:48 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 07 Apr 2020 19:17:48 +0000
Subject: [issue40217] The garbage collector doesn't take in account that
 objects of heap allocated types hold a strong reference to their type
In-Reply-To: <1586276621.78.0.843757244355.issue40217@roundup.psfhosted.org>
Message-ID: <1586287068.19.0.157377622003.issue40217@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

In https://github.com/python/cpython/pull/19414 I have attached a proof of concept of a wrapper for tp_traverse that only affects types created by PyType_FromSpec that will call Py_VISIT(Py_TYPE(self)) and then the user function.

----------

_______________________________________
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: [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:20:42 2020
From: report at bugs.python.org (=?utf-8?q?Volker_Wei=C3=9Fmann?=)
Date: Tue, 07 Apr 2020 20:20:42 +0000
Subject: [issue40218] sys.executable is a non existing path if python is
 executed from gdb
In-Reply-To: <1586290599.79.0.960995339825.issue40218@roundup.psfhosted.org>
Message-ID: <1586290842.52.0.804481060554.issue40218@roundup.psfhosted.org>


Volker Wei?mann <volker.weissmann at gmx.de> added the comment:

The gdb issue is here: https://sourceware.org/bugzilla/show_bug.cgi?id=25800

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40218>
_______________________________________

From report at bugs.python.org  Tue Apr  7 16:35:46 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Tue, 07 Apr 2020 20:35:46 +0000
Subject: [issue39481] Implement PEP 585 (Type Hinting Generics In Standard
 Collections)
In-Reply-To: <1580231817.93.0.47144630055.issue39481@roundup.psfhosted.org>
Message-ID: <1586291746.04.0.671745261256.issue39481@roundup.psfhosted.org>


Batuhan Taskaya <batuhanosmantaskaya at gmail.com> added the comment:

@gvanrossum is new types going to support generic alias protocol or this subset will be kept? Like typeshed uses os.DirEntry as a generic, but in reality it is not. (https://github.com/python/cpython/pull/17561)

----------
nosy: +BTaskaya

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39481>
_______________________________________

From report at bugs.python.org  Tue Apr  7 16:36:51 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Tue, 07 Apr 2020 20:36:51 +0000
Subject: [issue39019] Missing class getitems in standard library classes
In-Reply-To: <1576000554.09.0.555887969918.issue39019@roundup.psfhosted.org>
Message-ID: <1586291811.71.0.934010223108.issue39019@roundup.psfhosted.org>


Batuhan Taskaya <batuhanosmantaskaya at gmail.com> added the comment:

PEP 585 is landed, closing the issue (and linked PRs)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39019>
_______________________________________

From report at bugs.python.org  Tue Apr  7 16:37:14 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Tue, 07 Apr 2020 20:37:14 +0000
Subject: [issue39019] Missing class getitems in standard library classes
In-Reply-To: <1576000554.09.0.555887969918.issue39019@roundup.psfhosted.org>
Message-ID: <1586291834.18.0.351559622534.issue39019@roundup.psfhosted.org>


Change by Batuhan Taskaya <batuhanosmantaskaya at gmail.com>:


----------
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39019>
_______________________________________

From report at bugs.python.org  Tue Apr  7 16:41:21 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 07 Apr 2020 20:41:21 +0000
Subject: [issue39481] Implement PEP 585 (Type Hinting Generics In Standard
 Collections)
In-Reply-To: <1580231817.93.0.47144630055.issue39481@roundup.psfhosted.org>
Message-ID: <1586292081.86.0.398519470204.issue39481@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39481>
_______________________________________

From report at bugs.python.org  Tue Apr  7 16:41:47 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 07 Apr 2020 20:41:47 +0000
Subject: [issue40149] test_threading leaked [38, 38, 38] references, sum=114
In-Reply-To: <1585792445.62.0.0518463995906.issue40149@roundup.psfhosted.org>
Message-ID: <1586292107.54.0.669541558685.issue40149@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> bpo-40149: Implement traverse in _abc._abc_data (GH-19412)

Pablo told me that this change is not correct: the overriden traverse function must call PyType_Type.tp_traverse (parent method).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40149>
_______________________________________

From report at bugs.python.org  Tue Apr  7 16:42:45 2020
From: report at bugs.python.org (=?utf-8?b?VmVkcmFuIMSMYcSNacSH?=)
Date: Tue, 07 Apr 2020 20:42:45 +0000
Subject: [issue40153] json dump with repeated key
In-Reply-To: <1585829958.79.0.134366704668.issue40153@roundup.psfhosted.org>
Message-ID: <1586292165.89.0.871746855591.issue40153@roundup.psfhosted.org>


Vedran ?a?i? <vedgar at gmail.com> added the comment:

JSON is JavaScript Object Notation, that is, a notation for JS Objects. Python dicts are much more general than that (not only in keys, but in values too: JSON keys must be strings, and values must be Strings, Numbers, Booleans, Arrays, (JS) Objects, or nulls -- both are restricted compared to Python dicts). There is really no reason to expect full embedding.

----------
nosy: +veky

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40153>
_______________________________________

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: [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 16:47:54 2020
From: report at bugs.python.org (Stephen Bell)
Date: Tue, 07 Apr 2020 20:47:54 +0000
Subject: [issue40219] ttk LabeledScale: label covered by hidden element
In-Reply-To: <1586292175.49.0.452846630354.issue40219@roundup.psfhosted.org>
Message-ID: <1586292474.54.0.494990351642.issue40219@roundup.psfhosted.org>


Change by Stephen Bell <bahejlbell at gmail.com>:


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40219>
_______________________________________

From report at bugs.python.org  Tue Apr  7 16:53:15 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 07 Apr 2020 20:53:15 +0000
Subject: [issue39019] Missing class getitems in standard library classes
In-Reply-To: <1576000554.09.0.555887969918.issue39019@roundup.psfhosted.org>
Message-ID: <1586292795.43.0.993639136277.issue39019@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

Hold on, os.DirEntry[str] still doesn't work.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39019>
_______________________________________

From report at bugs.python.org  Tue Apr  7 16:55:44 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Tue, 07 Apr 2020 20:55:44 +0000
Subject: [issue39019] Missing class getitems in standard library classes
In-Reply-To: <1576000554.09.0.555887969918.issue39019@roundup.psfhosted.org>
Message-ID: <1586292944.25.0.935499844767.issue39019@roundup.psfhosted.org>


Batuhan Taskaya <batuhanosmantaskaya at gmail.com> added the comment:

> Hold on, os.DirEntry[str] still doesn't work.

That is what I asked on the issue 39481. I couldn't find anything about its cover on PEP 585.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39019>
_______________________________________

From report at bugs.python.org  Tue Apr  7 16:56:37 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Tue, 07 Apr 2020 20:56:37 +0000
Subject: [issue39481] Implement PEP 585 (Type Hinting Generics In Standard
 Collections)
In-Reply-To: <1580231817.93.0.47144630055.issue39481@roundup.psfhosted.org>
Message-ID: <1586292997.56.0.000694211602136.issue39481@roundup.psfhosted.org>


Change by Batuhan Taskaya <batuhanosmantaskaya at gmail.com>:


----------
pull_requests: +18775
pull_request: https://github.com/python/cpython/pull/19415

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39481>
_______________________________________

From report at bugs.python.org  Tue Apr  7 16:57:51 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 07 Apr 2020 20:57:51 +0000
Subject: [issue39481] Implement PEP 585 (Type Hinting Generics In Standard
 Collections)
In-Reply-To: <1580231817.93.0.47144630055.issue39481@roundup.psfhosted.org>
Message-ID: <1586293071.07.0.151835772133.issue39481@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

Ethan Smith produced a list of types that are Generic in typeshed but not in the stdlib. So these could be added.

https://github.com/gvanrossum/cpython/pull/1#issuecomment-582781121

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39481>
_______________________________________

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: [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 17:11:56 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 07 Apr 2020 21:11:56 +0000
Subject: [issue40089] Add _at_fork_reinit() method to locks
In-Reply-To: <1585324297.97.0.65509955463.issue40089@roundup.psfhosted.org>
Message-ID: <1586293916.15.0.933902431172.issue40089@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 87255be6964979b5abdc4b9dcf81cdcfdad6e753 by Victor Stinner in branch 'master':
bpo-40089: Add _at_fork_reinit() method to locks (GH-19195)
https://github.com/python/cpython/commit/87255be6964979b5abdc4b9dcf81cdcfdad6e753


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40089>
_______________________________________

From report at bugs.python.org  Tue Apr  7 17:25:18 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 07 Apr 2020 21:25:18 +0000
Subject: [issue40220] Modules/gcmodule.c:434: update_refs: Assertion
 "gc_get_refs(gc) != 0" failed
In-Reply-To: <1586293740.28.0.163587748948.issue40220@roundup.psfhosted.org>
Message-ID: <1586294718.24.0.664219752961.issue40220@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Other errors in the same build:

0:14:10 load avg: 7.70 [392/420/2] test_http_cookiejar crashed (Exit code -6) -- running: test_buffer (1 min 9 sec), test_pickle (57.5 sec), test_asyncio (3 min 47 sec), test_tarfile (36.8 sec), test_unparse (46.4 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  : 0xb53dddc0
object refcount : -1
object type     : 0x772950
object type name: str
object repr     : <refcnt -1 at 0xb53dddc0>

Fatal Python error: _PyObject_AssertFailed: _PyObject_AssertFailed
Python runtime state: initialized

Current thread 0xb6f1b010 (most recent call first):
  File "/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/test/libregrtest/runtest.py", line 193 in runtest
  File "/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/test/libregrtest/runtest_mp.py", line 80 in run_tests_worker
  File "/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/test/libregrtest/main.py", line 654 in _main
  File "/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/test/libregrtest/main.py", line 634 in main
  File "/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/test/libregrtest/main.py", line 712 in main
  File "/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/test/regrtest.py", line 43 in _main
  File "/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/test/regrtest.py", line 47 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 197 in _run_module_as_main

(...)

0:14:26 load avg: 7.84 [402/420/3] test_unicode crashed (Exit code -6) -- running: test_buffer (1 min 25 sec), test_pickle (1 min 13 sec), test_asyncio (4 min 3 sec), test_unparse (1 min 2 sec)
Objects/unicodeobject.c:559: _PyUnicode_CheckConsistency: Assertion failed: compact->wstr_length == ascii->length
Enable tracemalloc to get the memory block allocation traceback

object address  : 0xb12af060
object refcount : 1
object type     : 0x76d950
object type name: str
object repr     : Objects/unicodeobject.c:559: _PyUnicode_CheckConsistency: Assertion failed: compact->wstr_length == ascii->length
Enable tracemalloc to get the memory block allocation traceback

object address  : 0xb12af060
object refcount : 1
object type     : 0x76d950
object type name: str
object repr     : Objects/unicodeobject.c:559: _PyUnicode_CheckConsistency: Assertion failed: compact->wstr_length == ascii->length
Enable tracemalloc to get the memory block allocation traceback

(... same error dozens of times ...)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40220>
_______________________________________

From report at bugs.python.org  Tue Apr  7 17:31:10 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 07 Apr 2020 21:31:10 +0000
Subject: [issue40091] Crash in logging._after_at_fork_child_reinit_locks()
In-Reply-To: <1585328563.49.0.978667613959.issue40091@roundup.psfhosted.org>
Message-ID: <1586295070.66.0.397971165986.issue40091@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +18776
pull_request: https://github.com/python/cpython/pull/19416

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40091>
_______________________________________

From report at bugs.python.org  Tue Apr  7 17:35:55 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 07 Apr 2020 21:35:55 +0000
Subject: [issue40089] Add _at_fork_reinit() method to locks
In-Reply-To: <1585324297.97.0.65509955463.issue40089@roundup.psfhosted.org>
Message-ID: <1586295355.78.0.821897599433.issue40089@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 6318e45bda6c37d5497f33a6039cdb65aa494c93 by Miss Islington (bot) in branch '3.8':
bpo-40089: Fix threading._after_fork() (GH-19191) (GH-19194)
https://github.com/python/cpython/commit/6318e45bda6c37d5497f33a6039cdb65aa494c93


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40089>
_______________________________________

From report at bugs.python.org  Tue Apr  7 17:36:10 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 07 Apr 2020 21:36:10 +0000
Subject: [issue40089] Add _at_fork_reinit() method to locks
In-Reply-To: <1585324297.97.0.65509955463.issue40089@roundup.psfhosted.org>
Message-ID: <1586295370.74.0.68805965996.issue40089@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset a514ccb3ea6f01fef850d9465b82a1670d5ace44 by Miss Islington (bot) in branch '3.7':
bpo-40089: Fix threading._after_fork() (GH-19191) (GH-19193)
https://github.com/python/cpython/commit/a514ccb3ea6f01fef850d9465b82a1670d5ace44


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40089>
_______________________________________

From report at bugs.python.org  Tue Apr  7 17:37:22 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 07 Apr 2020 21:37:22 +0000
Subject: [issue39481] Implement PEP 585 (Type Hinting Generics In Standard
 Collections)
In-Reply-To: <1580231817.93.0.47144630055.issue39481@roundup.psfhosted.org>
Message-ID: <1586295442.8.0.563449325544.issue39481@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:


New changeset f9dd51e7db27d04e0b716d41a2804d5acbf145d1 by Batuhan Ta?kaya in branch 'master':
bpo-39481: Make os.DirEntry generic (GH-19415)
https://github.com/python/cpython/commit/f9dd51e7db27d04e0b716d41a2804d5acbf145d1


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39481>
_______________________________________

From report at bugs.python.org  Tue Apr  7 17:38:38 2020
From: report at bugs.python.org (Ethan Smith)
Date: Tue, 07 Apr 2020 21:38:38 +0000
Subject: [issue39481] Implement PEP 585 (Type Hinting Generics In Standard
 Collections)
In-Reply-To: <1580231817.93.0.47144630055.issue39481@roundup.psfhosted.org>
Message-ID: <1586295518.08.0.30408087118.issue39481@roundup.psfhosted.org>


Change by Ethan Smith <ethan at ethanhs.me>:


----------
nosy: +ethan smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39481>
_______________________________________

From report at bugs.python.org  Tue Apr  7 17:40:00 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 07 Apr 2020 21:40:00 +0000
Subject: [issue40220] Modules/gcmodule.c:434: update_refs: Assertion
 "gc_get_refs(gc) != 0" failed
In-Reply-To: <1586293740.28.0.163587748948.issue40220@roundup.psfhosted.org>
Message-ID: <1586295600.98.0.453660197421.issue40220@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Gregory: is this worker sick? Does it always rebuild from scratch?

----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40220>
_______________________________________

From report at bugs.python.org  Tue Apr  7 17:46:40 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 07 Apr 2020 21:46:40 +0000
Subject: [issue39983] test.regrtest: test marked as failed (env changed),
 but no warning: test_multiprocessing_forkserver
In-Reply-To: <1584397271.26.0.591205335177.issue39983@roundup.psfhosted.org>
Message-ID: <1586296000.01.0.848990185044.issue39983@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Another example with test_asyncio on s390x RHEL7 3.x:
https://buildbot.python.org/all/#/builders/320/builds/410

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39983>
_______________________________________

From report at bugs.python.org  Tue Apr  7 17:55:13 2020
From: report at bugs.python.org (Ethan Smith)
Date: Tue, 07 Apr 2020 21:55:13 +0000
Subject: [issue39481] Implement PEP 585 (Type Hinting Generics In Standard
 Collections)
In-Reply-To: <1580231817.93.0.47144630055.issue39481@roundup.psfhosted.org>
Message-ID: <1586296513.39.0.615364269277.issue39481@roundup.psfhosted.org>


Change by Ethan Smith <ethan at ethanhs.me>:


----------
pull_requests: +18777
pull_request: https://github.com/python/cpython/pull/19417

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39481>
_______________________________________

From report at bugs.python.org  Tue Apr  7 18:13:17 2020
From: report at bugs.python.org (melwitt)
Date: Tue, 07 Apr 2020 22:13:17 +0000
Subject: [issue40091] Crash in logging._after_at_fork_child_reinit_locks()
In-Reply-To: <1585328563.49.0.978667613959.issue40091@roundup.psfhosted.org>
Message-ID: <1586297597.24.0.350352157542.issue40091@roundup.psfhosted.org>


melwitt <melwittt at gmail.com> added the comment:

Hi, I've been following the work related to:

https://bugs.python.org/issue6721
https://bugs.python.org/issue40089

because I encountered a problem where a standard library lock was held by a parent process at the time that child processes were forked, so the child processes got stuck behind the inherited held locks.

But, if I'm understanding correctly, this issue is fixing something in python logging specifically and not all standard library locks in general.

My question is, will there be a way to reinit standard library locks in general using _at_fork_reinit()? That is, should we expect a future fix in python to do this or is the recommendation to continue to ensure the application reinits locks during process start if we know the process could be a child?

Thanks for your advice.

----------
nosy: +melwitt

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40091>
_______________________________________

From report at bugs.python.org  Tue Apr  7 18:14:47 2020
From: report at bugs.python.org (Steve Dower)
Date: Tue, 07 Apr 2020 22:14:47 +0000
Subject: [issue40214] test_ctypes.test_load_dll_with_flags Windows failure
In-Reply-To: <1586230066.46.0.791582618244.issue40214@roundup.psfhosted.org>
Message-ID: <1586297687.55.0.913346103895.issue40214@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

It's probably the sqlite3.dll dependency that's failing, not the _sqlite3.dll (originally _sqlite3.pyd) one.

The test is verifying that dependent DLLs are loaded correctly. So I assume in this case the _sqlite3.dll is being loaded, but it's finding the wrong sqlite3.dll.

Since I could, I updated Zach's PR to check for other sqlite3.dll files. The new build should be at https://dev.azure.com/Python/cpython/_build/results?buildId=60785&view=logs&j=c83831cd-3752-5cc7-2f01-8276919eb334 in a few minutes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40214>
_______________________________________

From report at bugs.python.org  Tue Apr  7 18:16:57 2020
From: report at bugs.python.org (Steve Dower)
Date: Tue, 07 Apr 2020 22:16:57 +0000
Subject: [issue40214] test_ctypes.test_load_dll_with_flags Windows failure
In-Reply-To: <1586230066.46.0.791582618244.issue40214@roundup.psfhosted.org>
Message-ID: <1586297817.64.0.0610780328317.issue40214@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

It might also be a "sqlite3_d.dll". Updated build is https://dev.azure.com/Python/cpython/_build/results?buildId=60787&view=results

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40214>
_______________________________________

From report at bugs.python.org  Tue Apr  7 18:24:31 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Tue, 07 Apr 2020 22:24:31 +0000
Subject: [issue39481] Implement PEP 585 (Type Hinting Generics In Standard
 Collections)
In-Reply-To: <1580231817.93.0.47144630055.issue39481@roundup.psfhosted.org>
Message-ID: <1586298271.54.0.280324113552.issue39481@roundup.psfhosted.org>


Change by Batuhan Taskaya <batuhanosmantaskaya at gmail.com>:


----------
pull_requests: +18778
pull_request: https://github.com/python/cpython/pull/19418

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39481>
_______________________________________

From report at bugs.python.org  Tue Apr  7 18:34:32 2020
From: report at bugs.python.org (Steve Dower)
Date: Tue, 07 Apr 2020 22:34:32 +0000
Subject: [issue40214] test_ctypes.test_load_dll_with_flags Windows failure
In-Reply-To: <1586230066.46.0.791582618244.issue40214@roundup.psfhosted.org>
Message-ID: <1586298872.24.0.0204444704996.issue40214@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Found it (and it's kind-of us):

Checking C:\Program Files\Amazon\AWSCLIV2\
*** Found at C:\Program Files\Amazon\AWSCLIV2\sqlite3.dll
*** Found at C:\Program Files\Amazon\AWSCLIV2\_sqlite3.pyd

But I'm not sure why that is getting loaded earlier than the current directory. Is that the behaviour we went for here?

(FWIW, we build and test a release build, not a debug build, which is why we're not looking for sqlite3_d.dll... but perhaps we should be using a debug build? That might be slower, but the extra validation is probably worthwhile...)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40214>
_______________________________________

From report at bugs.python.org  Tue Apr  7 18:38:19 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 07 Apr 2020 22:38:19 +0000
Subject: [issue40170] [C API] Make PyTypeObject structure an opaque structure
 in the public C API
In-Reply-To: <1585915023.07.0.846808236133.issue40170@roundup.psfhosted.org>
Message-ID: <1586299099.01.0.493876725386.issue40170@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 9205520d8c43488696d66cbdd9aefbb21871c508 by Victor Stinner in branch 'master':
bpo-40170: PyObject_NEW() becomes an alias to PyObject_New() (GH-19379)
https://github.com/python/cpython/commit/9205520d8c43488696d66cbdd9aefbb21871c508


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40170>
_______________________________________

From report at bugs.python.org  Tue Apr  7 18:46:11 2020
From: report at bugs.python.org (Ethan Smith)
Date: Tue, 07 Apr 2020 22:46:11 +0000
Subject: [issue39481] Implement PEP 585 (Type Hinting Generics In Standard
 Collections)
In-Reply-To: <1580231817.93.0.47144630055.issue39481@roundup.psfhosted.org>
Message-ID: <1586299571.38.0.568547439461.issue39481@roundup.psfhosted.org>


Change by Ethan Smith <ethan at ethanhs.me>:


----------
pull_requests: +18779
pull_request: https://github.com/python/cpython/pull/19421

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39481>
_______________________________________

From report at bugs.python.org  Tue Apr  7 18:59:05 2020
From: report at bugs.python.org (Ethan Smith)
Date: Tue, 07 Apr 2020 22:59:05 +0000
Subject: [issue39481] Implement PEP 585 (Type Hinting Generics In Standard
 Collections)
In-Reply-To: <1580231817.93.0.47144630055.issue39481@roundup.psfhosted.org>
Message-ID: <1586300345.57.0.22270328963.issue39481@roundup.psfhosted.org>


Change by Ethan Smith <ethan at ethanhs.me>:


----------
pull_requests: +18780
pull_request: https://github.com/python/cpython/pull/19422

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39481>
_______________________________________

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: [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  Tue Apr  7 19:07:10 2020
From: report at bugs.python.org (Facundo Batista)
Date: Tue, 07 Apr 2020 23:07:10 +0000
Subject: [issue40153] json dump with repeated key
In-Reply-To: <1585829958.79.0.134366704668.issue40153@roundup.psfhosted.org>
Message-ID: <1586300830.04.0.296879209401.issue40153@roundup.psfhosted.org>


Facundo Batista <facundo at taniquetil.com.ar> added the comment:

It's a theoretical issue, I didn't hit it myself.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40153>
_______________________________________

From report at bugs.python.org  Tue Apr  7 19:12:37 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 07 Apr 2020 23:12:37 +0000
Subject: [issue40091] Crash in logging._after_at_fork_child_reinit_locks()
In-Reply-To: <1585328563.49.0.978667613959.issue40091@roundup.psfhosted.org>
Message-ID: <1586301157.31.0.715065478746.issue40091@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> because I encountered a problem where a standard library lock was held by a parent process at the time that child processes were forked, so the child processes got stuck behind the inherited held locks.

Which lock from which module? You wrote details at:
https://github.com/python/cpython/pull/19195#issuecomment-609583084

According to your comment #28 at https://bugs.launchpad.net/nova/+bug/1844929 the lock involved in the issue comes from _TransactionFactory of oslo.db:
https://github.com/openstack/oslo.db/blob/b903d4e1ee07ef2ec454daa5b8418b3039e02774/oslo_db/sqlalchemy/enginefacade.py#L189

So it's a bug in oslo.db, not in Python. Python doesn't provide any machinery to automatically reinitialize all locks created in Python at fork in the child process. os.register_at_fork() must be used explicitly.


> But, if I'm understanding correctly, this issue is fixing something in python logging specifically and not all standard library locks in general.

This issue is specific to logging.


> My question is, will there be a way to reinit standard library locks in general using _at_fork_reinit()? That is, should we expect a future fix in python to do this or is the recommendation to continue to ensure the application reinits locks during process start if we know the process could be a child?

Each module has to setup an os.register_at_fork() callback to reinitialize its locks. It's done by threading and logging modules for example. The multiprocessing has its own util.register_after_fork() machinery (see bpo-40221)..

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40091>
_______________________________________

From report at bugs.python.org  Tue Apr  7 19:13:57 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 07 Apr 2020 23:13:57 +0000
Subject: [issue40170] [C API] Make PyTypeObject structure an opaque structure
 in the public C API
In-Reply-To: <1585915023.07.0.846808236133.issue40170@roundup.psfhosted.org>
Message-ID: <1586301237.08.0.793909691836.issue40170@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset ef5c615f5ae72c4f6979159c94da46afefbfab9a by Victor Stinner in branch 'master':
bpo-40170: Convert PyObject_CheckBuffer() macro to a function (GH-19376)
https://github.com/python/cpython/commit/ef5c615f5ae72c4f6979159c94da46afefbfab9a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40170>
_______________________________________

From report at bugs.python.org  Tue Apr  7 19:26:16 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Tue, 07 Apr 2020 23:26:16 +0000
Subject: [issue39481] Implement PEP 585 (Type Hinting Generics In Standard
 Collections)
In-Reply-To: <1580231817.93.0.47144630055.issue39481@roundup.psfhosted.org>
Message-ID: <1586301976.1.0.963493897805.issue39481@roundup.psfhosted.org>


Change by Batuhan Taskaya <batuhanosmantaskaya at gmail.com>:


----------
pull_requests: +18781
pull_request: https://github.com/python/cpython/pull/19423

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39481>
_______________________________________

From report at bugs.python.org  Tue Apr  7 19:34:04 2020
From: report at bugs.python.org (Ethan Smith)
Date: Tue, 07 Apr 2020 23:34:04 +0000
Subject: [issue39481] Implement PEP 585 (Type Hinting Generics In Standard
 Collections)
In-Reply-To: <1580231817.93.0.47144630055.issue39481@roundup.psfhosted.org>
Message-ID: <1586302444.5.0.350940572688.issue39481@roundup.psfhosted.org>


Change by Ethan Smith <ethan at ethanhs.me>:


----------
pull_requests: +18782
pull_request: https://github.com/python/cpython/pull/19425

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39481>
_______________________________________

From report at bugs.python.org  Tue Apr  7 19:34:30 2020
From: report at bugs.python.org (Furkan Onder)
Date: Tue, 07 Apr 2020 23:34:30 +0000
Subject: [issue19468] Relax the type restriction on reloaded modules
In-Reply-To: <1383275813.81.0.924128062775.issue19468@psf.upfronthosting.co.za>
Message-ID: <1586302470.07.0.562198460143.issue19468@roundup.psfhosted.org>


Change by Furkan Onder <furkanonder at protonmail.com>:


----------
keywords: +patch
nosy: +furkanonder
nosy_count: 3.0 -> 4.0
pull_requests: +18783
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/19424

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19468>
_______________________________________

From report at bugs.python.org  Tue Apr  7 19:39:40 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 07 Apr 2020 23:39:40 +0000
Subject: [issue40170] [C API] Make PyTypeObject structure an opaque structure
 in the public C API
In-Reply-To: <1585915023.07.0.846808236133.issue40170@roundup.psfhosted.org>
Message-ID: <1586302780.82.0.0830190772796.issue40170@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +18784
pull_request: https://github.com/python/cpython/pull/19426

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40170>
_______________________________________

From report at bugs.python.org  Tue Apr  7 19:42:30 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 07 Apr 2020 23:42:30 +0000
Subject: [issue40170] [C API] Make PyTypeObject structure an opaque structure
 in the public C API
In-Reply-To: <1585915023.07.0.846808236133.issue40170@roundup.psfhosted.org>
Message-ID: <1586302950.82.0.573850605592.issue40170@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 45ec5b99aefa54552947049086e87ec01bc2fc9a by Victor Stinner in branch 'master':
bpo-40170: PyType_HasFeature() now always calls PyType_GetFlags() (GH-19378)
https://github.com/python/cpython/commit/45ec5b99aefa54552947049086e87ec01bc2fc9a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40170>
_______________________________________

From report at bugs.python.org  Tue Apr  7 20:02:04 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 08 Apr 2020 00:02:04 +0000
Subject: [issue40170] [C API] Make PyTypeObject structure an opaque structure
 in the public C API
In-Reply-To: <1585915023.07.0.846808236133.issue40170@roundup.psfhosted.org>
Message-ID: <1586304124.8.0.101058417732.issue40170@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset a15e260b708a98edaba86a2aa663c3f6b2abc964 by Victor Stinner in branch 'master':
bpo-40170: Add _PyIndex_Check() internal function (GH-19426)
https://github.com/python/cpython/commit/a15e260b708a98edaba86a2aa663c3f6b2abc964


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40170>
_______________________________________

From report at bugs.python.org  Tue Apr  7 20:02:11 2020
From: report at bugs.python.org (Ethan Smith)
Date: Wed, 08 Apr 2020 00:02:11 +0000
Subject: [issue39481] Implement PEP 585 (Type Hinting Generics In Standard
 Collections)
In-Reply-To: <1580231817.93.0.47144630055.issue39481@roundup.psfhosted.org>
Message-ID: <1586304131.36.0.247408385721.issue39481@roundup.psfhosted.org>


Change by Ethan Smith <ethan at ethanhs.me>:


----------
pull_requests: +18785
pull_request: https://github.com/python/cpython/pull/19427

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39481>
_______________________________________

From report at bugs.python.org  Tue Apr  7 20:03:48 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 08 Apr 2020 00:03:48 +0000
Subject: [issue40217] The garbage collector doesn't take in account that
 objects of heap allocated types hold a strong reference to their type
In-Reply-To: <1586276621.78.0.843757244355.issue40217@roundup.psfhosted.org>
Message-ID: <1586304228.76.0.881261217097.issue40217@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

I have made some investigation, and I think a form of this bug was there from a long time and does not really relate to heap types.
For instance consider this code on Python3.7 (so commit 364f0b0f19cc3f0d5e63f571ec9163cf41c62958 is not present). 

If you consider the more simple heap type:

>>> class A:
...    ...
... 
>>> A().__class__
<class '__main__.A'>

As the class instance refers to its type, it must visit it in the gc and we can see that indeed, that is the case:

>>> import gc
>>> gc.get_referents(A())
[<class '__main__.A'>]

But for instance, consider ast.AST, which in 3.7 is a static type created with PyType_Ready:


>>> import ast
>>> x = ast.AST()
>>> x.__class__
<class '_ast.AST'>

we can see that the object refers to its type as the other one but....oh no, the gc does not know about that link:

>>> import gc
>>> gc.get_referents(x)
[]

This is because its traverse function does not visit the type:

static int
ast_traverse(AST_object *self, visitproc visit, void *arg)
{
     Py_VISIT(self->dict);
     return 0;
}


This is not a problem if the type is *static* because __although is technically an error__ because the GC cannot resolve
cycles that go through the type, as the type is eternal those cycles will never be collected. 

The problem appears when the type is not eternal and can be destroyed. For instance, to understand this consider a function
in the _testcapi that creates a heap type using PyType_FromSpec:

>>> import gc, _testcapi
>>> import weakref
>>> import sys

# Create a new heap type with custom traverse function
>>> x = _testcapi.construct_new_gc_type()
>>> sys.getrefcount(x)
5
>>> new_obj = x()
>>> sys.getrefcount(x)
6
# We know that now there should be a link between new_obj and x because one points to the other
>>> x in gc.get_referents(new_obj)
False
# Oh no, there is no link
>>> class A:
...    def __del__(self):
...       print("Ouch")
... 
>>> x_w = weakref.ref(x)
# Create a reference cycle  a -> new_obj -> x -> a
>>> a = A()
>>> 
>>> x.a = a
>>> a.y = new_obj
>>> a.x = x
>>> gc.collect()
0
>>> del x,a
>>> gc.collect()
0
>>> sys.getrefcount(x_w())
6
>>> del new_obj
# At this point all variables are gone and the collector should clean everything
>>> gc.collect()
0
# Oh, no! The type is still alive
>>> sys.getrefcount(x_w())
6


If we do the same experiment after PR19314:

>>> import sys, gc, _testcapi
>>> import weakref
>>> x = _testcapi.construct_new_gc_type()
>>> sys.getrefcount(x)
5
>>> new_obj = x()
>>> sys.getrefcount(x)
6
# We know that now there should be a link between new_obj and x because one points to the other
>>> x in gc.get_referents(new_obj)
True
# Good!
>>> class A:
...   def __del__(self):
...      print("Ouch")
... 

>>> x_w = weakref.ref(x)
# Create a reference cycle  a -> new_obj -> x -> a
>>> a = A()
>>> x.a = a
>>> a.y = new_obj
>>> a.x = x
>>> gc.collect()
Traversed!
Traversed!
36
>>> del x,a
>>> gc.collect()
Traversed!
Traversed!
0
>>> sys.getrefcount(x_w())
6
>>> del new_obj
# At this point all variables are gone and the collector should clean everything
>>> gc.collect()
Ouch
8
# Nice, the collector cleaned the cycle


-------

So the conclusion:

* This bug affects all types but is only really relevant for types that are not eternal (because eternal types are already "leaked").
* The only real problem and leaks will appear for heap types that are not eternal with custom traverse functions.
* After commit 364f0b0f19cc3f0d5e63f571ec9163cf41c62958 now all heap types that are not eternal, for instance 
  the ones created with PyType_FromSpec, need to traverse the type because they own it. Falining to do this can create leaks in the GC.
* The *correct* thing to do is modify the tp_traverse of all non-eternal heap types, but sadly the only way to do this in a backwards-compatible
  without modifying all user functions is injecting automatically the behaviour as PR 19414 is doing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40217>
_______________________________________

From report at bugs.python.org  Tue Apr  7 20:03:59 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 08 Apr 2020 00:03:59 +0000
Subject: [issue40170] [C API] Make PyTypeObject structure an opaque structure
 in the public C API
In-Reply-To: <1585915023.07.0.846808236133.issue40170@roundup.psfhosted.org>
Message-ID: <1586304239.55.0.199167853997.issue40170@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Hum, once most changes will land, maybe it would be worth it to document them at:
https://docs.python.org/dev/whatsnew/3.9.html#build-and-c-api-changes

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40170>
_______________________________________

From report at bugs.python.org  Tue Apr  7 20:04:05 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 08 Apr 2020 00:04:05 +0000
Subject: [issue40170] [C API] Make PyTypeObject structure an opaque structure
 in the public C API
In-Reply-To: <1585915023.07.0.846808236133.issue40170@roundup.psfhosted.org>
Message-ID: <1586304245.42.0.290074004398.issue40170@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +18786
pull_request: https://github.com/python/cpython/pull/19428

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40170>
_______________________________________

From report at bugs.python.org  Tue Apr  7 20:05:40 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 08 Apr 2020 00:05:40 +0000
Subject: [issue40217] The garbage collector doesn't take in account that
 objects of heap allocated types hold a strong reference to their type
In-Reply-To: <1586276621.78.0.843757244355.issue40217@roundup.psfhosted.org>
Message-ID: <1586304340.78.0.559691673511.issue40217@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Sorry when I said:

> If we do the same experiment after PR19314:

I meant:

If we do the same experiment after PR 19414:

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40217>
_______________________________________

From report at bugs.python.org  Tue Apr  7 20:26:48 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 08 Apr 2020 00:26:48 +0000
Subject: [issue40170] [C API] Make PyTypeObject structure an opaque structure
 in the public C API
In-Reply-To: <1585915023.07.0.846808236133.issue40170@roundup.psfhosted.org>
Message-ID: <1586305608.62.0.918208174627.issue40170@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 307b9d0144e719b016a47fcc43397c070615e01e by Victor Stinner in branch 'master':
bpo-40170: Remove PyIndex_Check() macro (GH-19428)
https://github.com/python/cpython/commit/307b9d0144e719b016a47fcc43397c070615e01e


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40170>
_______________________________________

From report at bugs.python.org  Tue Apr  7 20:39:03 2020
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 08 Apr 2020 00:39:03 +0000
Subject: [issue40220] Modules/gcmodule.c:434: update_refs: Assertion
 "gc_get_refs(gc) != 0" failed
In-Reply-To: <1586293740.28.0.163587748948.issue40220@roundup.psfhosted.org>
Message-ID: <1586306343.89.0.517647968732.issue40220@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:

While I did a general apt update on that worker, I suspect I may have knocked the heatsink loose over the weekend while dealing with an upcoming bot sitting behind it on the shelf.  That'd explain why it is alternately crashing and making mystery results.  I'll figure it out.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40220>
_______________________________________

From report at bugs.python.org  Tue Apr  7 21:58:43 2020
From: report at bugs.python.org (melwitt)
Date: Wed, 08 Apr 2020 01:58:43 +0000
Subject: [issue40091] Crash in logging._after_at_fork_child_reinit_locks()
In-Reply-To: <1585328563.49.0.978667613959.issue40091@roundup.psfhosted.org>
Message-ID: <1586311123.56.0.95451660113.issue40091@roundup.psfhosted.org>


melwitt <melwittt at gmail.com> added the comment:

Thank you for explaining those details and pointing me in the right direction about the proper way to solve the problem in oslo.db.

We still have to support python 3.6, so for now we will still need to do something different (in nova) to handle this (clear our cache of oslo.db _TransactionContextManager during oslo.service start(), is what I have proposed).

For those running python 3.7 and newer, I will try to fix the situation more generally in oslo.db with os.register_at_fork() using the examples you gave.

Thank you again for your help, I have learned a lot.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40091>
_______________________________________

From report at bugs.python.org  Tue Apr  7 22:35:57 2020
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 08 Apr 2020 02:35:57 +0000
Subject: [issue40220] Modules/gcmodule.c:434: update_refs: Assertion
 "gc_get_refs(gc) != 0" failed
In-Reply-To: <1586293740.28.0.163587748948.issue40220@roundup.psfhosted.org>
Message-ID: <1586313357.56.0.547972620529.issue40220@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:

bad buildbot hardware.  i've taken that bot offline.

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed
type:  -> crash

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40220>
_______________________________________

From report at bugs.python.org  Wed Apr  8 00:05:49 2020
From: report at bugs.python.org (Kyle Stanley)
Date: Wed, 08 Apr 2020 04:05:49 +0000
Subject: [issue40214] test_ctypes.test_load_dll_with_flags Windows failure
In-Reply-To: <1586230066.46.0.791582618244.issue40214@roundup.psfhosted.org>
Message-ID: <1586318749.61.0.678467779138.issue40214@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:

Steve Dower wrote:
> (FWIW, we build and test a release build, not a debug build, which is why we're not looking for sqlite3_d.dll... but perhaps we should be using a debug build? That might be slower, but the extra validation is probably worthwhile...)

In general, I think a debug build instead of a release would make more sense for the PR tests. Do you have a general estimate or rough idea as to how much slower it would be in comparison?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40214>
_______________________________________

From report at bugs.python.org  Wed Apr  8 00:28:54 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 08 Apr 2020 04:28:54 +0000
Subject: [issue40214] test_ctypes.test_load_dll_with_flags Windows failure
In-Reply-To: <1586230066.46.0.791582618244.issue40214@roundup.psfhosted.org>
Message-ID: <1586320134.66.0.263283160923.issue40214@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Is this going to be backported? It seems backports also use the same build and have this error. Sample 3.8 backport build that seems to be related to this issue : https://dev.azure.com/Python/cpython/_build/results?buildId=60753&view=logs&j=d554cd63-f8f4-5b2d-871b-33e4ea76e915&t=5a14d0eb-dbd4-5b80-f5d0-7909f950a1cc&l=1570

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40214>
_______________________________________

From report at bugs.python.org  Wed Apr  8 01:45:46 2020
From: report at bugs.python.org (Zackery Spytz)
Date: Wed, 08 Apr 2020 05:45:46 +0000
Subject: [issue39075] types.SimpleNamespace should preserve attribute ordering
 (?)
In-Reply-To: <1576599681.13.0.0769751822925.issue39075@roundup.psfhosted.org>
Message-ID: <1586324746.22.0.935234641571.issue39075@roundup.psfhosted.org>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
keywords: +patch
nosy: +ZackerySpytz
nosy_count: 6.0 -> 7.0
pull_requests: +18787
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/19430

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39075>
_______________________________________

From report at bugs.python.org  Wed Apr  8 03:59:20 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 08 Apr 2020 07:59:20 +0000
Subject: [issue40185] Refactor typing.NamedTuple
In-Reply-To: <1586034525.17.0.360408189871.issue40185@roundup.psfhosted.org>
Message-ID: <1586332760.45.0.00519065127594.issue40185@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset a2ec06938f46683e33692615aca3875d8b8e110c by Serhiy Storchaka in branch 'master':
bpo-40185: Refactor typing.NamedTuple (GH-19371)
https://github.com/python/cpython/commit/a2ec06938f46683e33692615aca3875d8b8e110c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40185>
_______________________________________

From report at bugs.python.org  Wed Apr  8 04:03:32 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 08 Apr 2020 08:03:32 +0000
Subject: [issue40187] Refactor typing.TypedDict
In-Reply-To: <1586035239.71.0.90938203594.issue40187@roundup.psfhosted.org>
Message-ID: <1586333012.45.0.95561354348.issue40187@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset f228bf2300a9d3bf833b1a89336581822e864ae5 by Serhiy Storchaka in branch 'master':
bpo-40187: Refactor typing.TypedDict. (GH-19372)
https://github.com/python/cpython/commit/f228bf2300a9d3bf833b1a89336581822e864ae5


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40187>
_______________________________________

From report at bugs.python.org  Wed Apr  8 04:05:31 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 08 Apr 2020 08:05:31 +0000
Subject: [issue40185] Refactor typing.NamedTuple
In-Reply-To: <1586034525.17.0.360408189871.issue40185@roundup.psfhosted.org>
Message-ID: <1586333131.45.0.440684374334.issue40185@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40185>
_______________________________________

From report at bugs.python.org  Wed Apr  8 04:05:53 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 08 Apr 2020 08:05:53 +0000
Subject: [issue40187] Refactor typing.TypedDict
In-Reply-To: <1586035239.71.0.90938203594.issue40187@roundup.psfhosted.org>
Message-ID: <1586333153.12.0.038707503845.issue40187@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40187>
_______________________________________

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: [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:23:55 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 08 Apr 2020 10:23:55 +0000
Subject: [issue40222] "Zero cost" exception handling
In-Reply-To: <1586338863.3.0.393749013734.issue40222@roundup.psfhosted.org>
Message-ID: <1586341435.36.0.923862844443.issue40222@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

+1! I was going to implement this, but first I wanted to implement support of line number ranges instead of just line numbers (co_lineno). We need to design some compact portable format for address to address mapping (or address range to address mapping if it is more efficient).

Are you already working on this Mark? I would be glad to make a review.

----------
nosy: +serhiy.storchaka

_______________________________________
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: [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: [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 07:49:19 2020
From: report at bugs.python.org (keyboardAnt)
Date: Wed, 08 Apr 2020 11:49:19 +0000
Subject: [issue40224] Execute a @staticmethod (Python 3.8.2)
In-Reply-To: <1586346310.43.0.266820060566.issue40224@roundup.psfhosted.org>
Message-ID: <1586346559.72.0.552800027215.issue40224@roundup.psfhosted.org>


Change by keyboardAnt <nadav0012 at gmail.com>:


Removed 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 07:49:58 2020
From: report at bugs.python.org (keyboardAnt)
Date: Wed, 08 Apr 2020 11:49:58 +0000
Subject: [issue40224] delete_me
In-Reply-To: <1586346310.43.0.266820060566.issue40224@roundup.psfhosted.org>
Message-ID: <1586346598.75.0.646938563978.issue40224@roundup.psfhosted.org>


Change by keyboardAnt <nadav0012 at gmail.com>:


----------
components:  -macOS
title: Execute a @staticmethod (Python 3.8.2) -> delete_me
versions:  -Python 3.8

_______________________________________
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: [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:15:02 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Wed, 08 Apr 2020 12:15:02 +0000
Subject: [issue39481] Implement PEP 585 (Type Hinting Generics In Standard
 Collections)
In-Reply-To: <1580231817.93.0.47144630055.issue39481@roundup.psfhosted.org>
Message-ID: <1586348102.71.0.693059414759.issue39481@roundup.psfhosted.org>


Change by Batuhan Taskaya <batuhanosmantaskaya at gmail.com>:


----------
pull_requests: +18788
pull_request: https://github.com/python/cpython/pull/19434

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39481>
_______________________________________

From report at bugs.python.org  Wed Apr  8 08:18:50 2020
From: report at bugs.python.org (brendon zhang)
Date: Wed, 08 Apr 2020 12:18:50 +0000
Subject: [issue40225] max() performance regression (quadratic time)
In-Reply-To: <1586347827.41.0.754437002794.issue40225@roundup.psfhosted.org>
Message-ID: <1586348330.81.0.933400447381.issue40225@roundup.psfhosted.org>


brendon zhang <brendon-zhang at hotmail.com> added the comment:

Something about calling max() in deeply nested recursion context appears to make the overall complexity O(n^2) instead of O(n)

----------

_______________________________________
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: [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 08:20:46 2020
From: report at bugs.python.org (brendon zhang)
Date: Wed, 08 Apr 2020 12:20:46 +0000
Subject: [issue40225] max() performance regression (quadratic time)
In-Reply-To: <1586347827.41.0.754437002794.issue40225@roundup.psfhosted.org>
Message-ID: <1586348446.35.0.0688171425519.issue40225@roundup.psfhosted.org>


brendon zhang <brendon-zhang at hotmail.com> added the comment:

You can get the replicate this issue even when removing lru_cache(None) and calling max with iterable of size 1.

eg.
best = max(solve(j) for j in [i-1])

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40225>
_______________________________________

From report at bugs.python.org  Wed Apr  8 08:23:36 2020
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 08 Apr 2020 12:23:36 +0000
Subject: [issue40224] delete_me
In-Reply-To: <1586346310.43.0.266820060566.issue40224@roundup.psfhosted.org>
Message-ID: <1586348616.93.0.170545280099.issue40224@roundup.psfhosted.org>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

This is expected behavior, the call to "C.sm()" happens before "C" is created.

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40224>
_______________________________________

From report at bugs.python.org  Wed Apr  8 08:45:42 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Wed, 08 Apr 2020 12:45:42 +0000
Subject: [issue39481] Implement PEP 585 (Type Hinting Generics In Standard
 Collections)
In-Reply-To: <1580231817.93.0.47144630055.issue39481@roundup.psfhosted.org>
Message-ID: <1586349942.82.0.332686283667.issue39481@roundup.psfhosted.org>


Change by Batuhan Taskaya <batuhanosmantaskaya at gmail.com>:


----------
pull_requests: +18789
pull_request: https://github.com/python/cpython/pull/19435

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39481>
_______________________________________

From report at bugs.python.org  Wed Apr  8 08:47:20 2020
From: report at bugs.python.org (Jeffery To)
Date: Wed, 08 Apr 2020 12:47:20 +0000
Subject: [issue37596] Reproducible pyc: frozenset is not serialized in a
 deterministic order
In-Reply-To: <1563203111.95.0.786255267379.issue37596@roundup.psfhosted.org>
Message-ID: <1586350040.67.0.946863455104.issue37596@roundup.psfhosted.org>


Change by Jeffery To <jeffery.to at gmail.com>:


----------
nosy: +jefferyto

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37596>
_______________________________________

From report at bugs.python.org  Wed Apr  8 08:49:01 2020
From: report at bugs.python.org (Jeffery To)
Date: Wed, 08 Apr 2020 12:49:01 +0000
Subject: [issue29708] support reproducible Python builds
In-Reply-To: <1488540966.18.0.904677570473.issue29708@psf.upfronthosting.co.za>
Message-ID: <1586350141.7.0.83750403372.issue29708@roundup.psfhosted.org>


Change by Jeffery To <jeffery.to at gmail.com>:


----------
nosy: +jefferyto

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29708>
_______________________________________

From report at bugs.python.org  Wed Apr  8 08:50:37 2020
From: report at bugs.python.org (Jeffery To)
Date: Wed, 08 Apr 2020 12:50:37 +0000
Subject: [issue34033] distutils is not reproducible
In-Reply-To: <1530632785.81.0.56676864532.issue34033@psf.upfronthosting.co.za>
Message-ID: <1586350237.03.0.25981062899.issue34033@roundup.psfhosted.org>


Change by Jeffery To <jeffery.to at gmail.com>:


----------
nosy: +jefferyto

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34033>
_______________________________________

From report at bugs.python.org  Wed Apr  8 08:50:29 2020
From: report at bugs.python.org (brendon zhang)
Date: Wed, 08 Apr 2020 12:50:29 +0000
Subject: [issue40225] max() performance regression (quadratic time)
In-Reply-To: <1586347827.41.0.754437002794.issue40225@roundup.psfhosted.org>
Message-ID: <1586350229.88.0.159010004176.issue40225@roundup.psfhosted.org>


brendon zhang <brendon-zhang at hotmail.com> added the comment:

update:
it is specifically caused by passing in a generator expression to max(), where the generator invokes recursive function.

I added another file to demonstrate this

----------
Added file: https://bugs.python.org/file49044/maxbug2.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40225>
_______________________________________

From report at bugs.python.org  Wed Apr  8 09:05:08 2020
From: report at bugs.python.org (brendon zhang)
Date: Wed, 08 Apr 2020 13:05:08 +0000
Subject: [issue40225] max() performance regression (quadratic time)
In-Reply-To: <1586347827.41.0.754437002794.issue40225@roundup.psfhosted.org>
Message-ID: <1586351108.01.0.850103345706.issue40225@roundup.psfhosted.org>


brendon zhang <brendon-zhang at hotmail.com> added the comment:

this affects ALL builtin functions (eg all(), any(), sum(), sorted(), etc...) that accept generator as input and exhaust it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40225>
_______________________________________

From report at bugs.python.org  Wed Apr  8 09:07:39 2020
From: report at bugs.python.org (brendon zhang)
Date: Wed, 08 Apr 2020 13:07:39 +0000
Subject: [issue40225] generator exhaustion for builtin functions in recursion
 is O(depth)
In-Reply-To: <1586347827.41.0.754437002794.issue40225@roundup.psfhosted.org>
Message-ID: <1586351259.04.0.690815387362.issue40225@roundup.psfhosted.org>


Change by brendon zhang <brendon-zhang at hotmail.com>:


----------
title: max() performance regression (quadratic time) -> generator exhaustion for builtin functions in recursion is O(depth)

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40225>
_______________________________________

From report at bugs.python.org  Wed Apr  8 09:08:44 2020
From: report at bugs.python.org (brendon zhang)
Date: Wed, 08 Apr 2020 13:08:44 +0000
Subject: [issue40225] generator exhaustion for builtin functions in nested
 call is O(depth)
In-Reply-To: <1586347827.41.0.754437002794.issue40225@roundup.psfhosted.org>
Message-ID: <1586351324.41.0.578046734827.issue40225@roundup.psfhosted.org>


Change by brendon zhang <brendon-zhang at hotmail.com>:


----------
title: generator exhaustion for builtin functions in recursion is O(depth) -> generator exhaustion for builtin functions in nested call is O(depth)

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40225>
_______________________________________

From report at bugs.python.org  Wed Apr  8 09:44:43 2020
From: report at bugs.python.org (Fernando)
Date: Wed, 08 Apr 2020 13:44:43 +0000
Subject: [issue40154] embedded null byte when connecting to sqlite database
 using a bytes object
In-Reply-To: <1585830183.65.0.52883821516.issue40154@roundup.psfhosted.org>
Message-ID: <1586353483.9.0.143173685034.issue40154@roundup.psfhosted.org>


Fernando <ferferga.fer at gmail.com> added the comment:

bump?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40154>
_______________________________________

From report at bugs.python.org  Wed Apr  8 09:49:48 2020
From: report at bugs.python.org (Fernando)
Date: Wed, 08 Apr 2020 13:49:48 +0000
Subject: [issue40154] embedded null byte when connecting to sqlite database
 using a bytes object
In-Reply-To: <1585830183.65.0.52883821516.issue40154@roundup.psfhosted.org>
Message-ID: <1586353788.08.0.877601975391.issue40154@roundup.psfhosted.org>


Change by Fernando <ferferga.fer at gmail.com>:


----------
components: +Extension Modules -IO

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40154>
_______________________________________

From report at bugs.python.org  Wed Apr  8 09:50:08 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Wed, 08 Apr 2020 13:50:08 +0000
Subject: [issue39851] tarfile: Exception ignored in (... stdout ...)
 BrokenPipeError
In-Reply-To: <1583344986.43.0.320216561528.issue39851@roundup.psfhosted.org>
Message-ID: <1586353808.65.0.372115643566.issue39851@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

Victor,
I found a way how to deal with it.
The submitted file will show how it can be handled.

If you remove the try: finally statement.
You can see the same stdout which occurred from tarfile

But I'd like to listen to your opinion before submitting the patch. :)

?  cpython git:(master) ? set -o pipefail
?  cpython git:(master) ? ./python.exe ttt.py
test
hi
?  cpython git:(master) ? ./python.exe ttt.py | true
?  cpython git:(master) ? echo $?
32

----------
Added file: https://bugs.python.org/file49045/approach.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39851>
_______________________________________

From report at bugs.python.org  Wed Apr  8 10:28:27 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Wed, 08 Apr 2020 14:28:27 +0000
Subject: [issue36287] Make ast.dump() not output optional default fields
In-Reply-To: <1552556885.52.0.772295389158.issue36287@roundup.psfhosted.org>
Message-ID: <1586356107.42.0.273995903296.issue36287@roundup.psfhosted.org>


Batuhan Taskaya <batuhanosmantaskaya at gmail.com> added the comment:

Adding issue 39981 as a dependency.

----------
dependencies: +Default values for AST Nodes

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36287>
_______________________________________

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: [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 10:49:28 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Wed, 08 Apr 2020 14:49:28 +0000
Subject: [issue39851] tarfile: Exception ignored in (... stdout ...)
 BrokenPipeError
In-Reply-To: <1583344986.43.0.320216561528.issue39851@roundup.psfhosted.org>
Message-ID: <1586357368.71.0.997608383644.issue39851@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
keywords: +patch
Added file: https://bugs.python.org/file49046/bpo-39851.patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39851>
_______________________________________

From report at bugs.python.org  Wed Apr  8 11:27:17 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 08 Apr 2020 15:27:17 +0000
Subject: [issue40226] Leak in tstate->interp->ceval.pending
In-Reply-To: <1586348371.36.0.292575347676.issue40226@roundup.psfhosted.org>
Message-ID: <1586359637.37.0.863531735172.issue40226@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
keywords: +patch
pull_requests: +18790
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/19436

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40226>
_______________________________________

From report at bugs.python.org  Wed Apr  8 11:29:02 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 08 Apr 2020 15:29:02 +0000
Subject: [issue40226] Leak in tstate->interp->ceval.pending
In-Reply-To: <1586348371.36.0.292575347676.issue40226@roundup.psfhosted.org>
Message-ID: <1586359742.68.0.863388586694.issue40226@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I confirm that I'm able to reproduce the issue on the master branch:

$ PYTHONMALLOC=malloc valgrind --leak-check=full --log-file=valgrind.log --num-callers=20 ./python -c pass

==44052== 32 bytes in 1 blocks are definitely lost in loss record 187 of 2,264
==44052==    at 0x483980B: malloc (vg_replace_malloc.c:309)
==44052==    by 0x46DA1E: _PyMem_RawMalloc (obmalloc.c:99)
==44052==    by 0x46EBE1: PyMem_RawMalloc (obmalloc.c:572)
==44052==    by 0x5475C7: PyThread_allocate_lock (thread_pthread.h:379)
==44052==    by 0x4ED6EF: _PyEval_InitThreads (ceval.c:296)
==44052==    by 0x52FE87: pycore_create_interpreter (pylifecycle.c:561)
==44052==    by 0x5316B3: pyinit_config (pylifecycle.c:757)
==44052==    by 0x532D38: pyinit_core (pylifecycle.c:924)
==44052==    by 0x5338F5: Py_InitializeFromConfig (pylifecycle.c:1134)
==44052==    by 0x41DA88: pymain_init (main.c:66)
==44052==    by 0x41EAAC: pymain_main (main.c:653)
==44052==    by 0x41EB39: Py_BytesMain (main.c:686)
==44052==    by 0x41D6CE: main (python.c:16)

> 50e6e991781db761c496561a995541ca8d83ff87 causes or exposes a
leak. Possibly the leak was there before but showed up under
"still reachable".

Python freed pending calls at exit. It's just that Valgrind decided to complain about them :-)

=> Attached PR fix the issue.

Note: the GIL is still leaked at exit. See "Don't destroy the GIL at exit" section of https://vstinner.github.io/daemon-threads-python-finalization-python32.html for the rationale.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40226>
_______________________________________

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: [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 11:55:06 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 08 Apr 2020 15:55:06 +0000
Subject: [issue40226] Leak in tstate->interp->ceval.pending
In-Reply-To: <1586348371.36.0.292575347676.issue40226@roundup.psfhosted.org>
Message-ID: <1586361306.57.0.926575921129.issue40226@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset dda5d6e071c6a9d65993d45b90232565cfad2cde by Victor Stinner in branch 'master':
bpo-40226: PyInterpreterState_Delete() deletes pending calls (GH-19436)
https://github.com/python/cpython/commit/dda5d6e071c6a9d65993d45b90232565cfad2cde


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40226>
_______________________________________

From report at bugs.python.org  Wed Apr  8 11:55:23 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 08 Apr 2020 15:55:23 +0000
Subject: [issue40226] Leak in tstate->interp->ceval.pending
In-Reply-To: <1586348371.36.0.292575347676.issue40226@roundup.psfhosted.org>
Message-ID: <1586361323.13.0.978715929497.issue40226@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Fixed, thanks for the bug report Stefan ;-)

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40226>
_______________________________________

From report at bugs.python.org  Wed Apr  8 11:59:37 2020
From: report at bugs.python.org (Mark Shannon)
Date: Wed, 08 Apr 2020 15:59:37 +0000
Subject: [issue40228] Make setting line number in frame more robust.
In-Reply-To: <1586360855.72.0.434652598832.issue40228@roundup.psfhosted.org>
Message-ID: <1586361577.76.0.80739370082.issue40228@roundup.psfhosted.org>


Change by Mark Shannon <mark at hotpy.org>:


----------
keywords: +patch
pull_requests: +18791
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19437

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40228>
_______________________________________

From report at bugs.python.org  Wed Apr  8 12:02:40 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 08 Apr 2020 16:02:40 +0000
Subject: [issue40228] Make setting line number in frame more robust.
In-Reply-To: <1586360855.72.0.434652598832.issue40228@roundup.psfhosted.org>
Message-ID: <1586361760.58.0.928779927394.issue40228@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40228>
_______________________________________

From report at bugs.python.org  Wed Apr  8 12:14:02 2020
From: report at bugs.python.org (Zachary Ware)
Date: Wed, 08 Apr 2020 16:14:02 +0000
Subject: [issue40214] test_ctypes.test_load_dll_with_flags Windows failure
In-Reply-To: <1586230066.46.0.791582618244.issue40214@roundup.psfhosted.org>
Message-ID: <1586362442.22.0.948793379207.issue40214@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

Feel free to backport PR19404 as needed, but mark versions here appropriately to make sure the *real* fix makes it where it needs to go.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40214>
_______________________________________

From report at bugs.python.org  Wed Apr  8 13:00:41 2020
From: report at bugs.python.org (hai shi)
Date: Wed, 08 Apr 2020 17:00:41 +0000
Subject: [issue40077] Convert static types to PyType_FromSpec()
In-Reply-To: <1585238684.65.0.246012172449.issue40077@roundup.psfhosted.org>
Message-ID: <1586365241.22.0.195108082262.issue40077@roundup.psfhosted.org>


Change by hai shi <shihai1991 at 126.com>:


----------
pull_requests: +18792
pull_request: https://github.com/python/cpython/pull/19438

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40077>
_______________________________________

From report at bugs.python.org  Wed Apr  8 13:12:53 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 08 Apr 2020 17:12:53 +0000
Subject: [issue37127] Handling pending calls during runtime finalization may
 cause problems.
In-Reply-To: <1559416306.37.0.716771519489.issue37127@roundup.psfhosted.org>
Message-ID: <1586365973.01.0.370464047417.issue37127@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +18793
pull_request: https://github.com/python/cpython/pull/19439

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37127>
_______________________________________

From report at bugs.python.org  Wed Apr  8 13:43:34 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 08 Apr 2020 17:43:34 +0000
Subject: [issue40082] Assertion failure in trip_signal
In-Reply-To: <1585289232.05.0.154553792707.issue40082@roundup.psfhosted.org>
Message-ID: <1586367814.69.0.112164698898.issue40082@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Oh oh. This issue is quite annoying for my work on subinterpreters.

I introduced this bug when I moved pending calls from _PyRuntimeState to PyInterpreterState in bpo-39984. _PyEval_AddPendingCall() now requires tstate to add a function to pending calls of the proper interpreter.

The problem on Windows is that each CTRL+c is executed in a different thread. Here is a modified Python 3.8 which dumps the thread identifier ("tid") at startup and when trip_signal() is triggered by CTRL+C:

vstinner at WIN C:\vstinner\python\3.8>python
Running Release|x64 interpreter...
pymain_main: tid=1788
Python 3.8.1+ (heads/3.8-dirty:19be85c765, Apr  8 2020, 19:35:20) [MSC v.1916 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> ^C
trip_signal: tid=6996 tstate=0000000000000000
KeyboardInterrupt

>>> ^C
trip_signal: tid=2384 tstate=0000000000000000
KeyboardInterrupt

>>> ^C
trip_signal: tid=32 tstate=0000000000000000
KeyboardInterrupt

When trip_signal() is called, PyGILState_GetThisThreadState() returns NULL.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40082>
_______________________________________

From report at bugs.python.org  Wed Apr  8 13:43:28 2020
From: report at bugs.python.org (SilentGhost)
Date: Wed, 08 Apr 2020 17:43:28 +0000
Subject: [issue40154] embedded null byte when connecting to sqlite database
 using a bytes object
In-Reply-To: <1585830183.65.0.52883821516.issue40154@roundup.psfhosted.org>
Message-ID: <1586367808.13.0.146544727183.issue40154@roundup.psfhosted.org>


SilentGhost <ghost.adh at runbox.com> added the comment:

Hi Fernando,

the first parameter of the connect function is described in documentation as follows: 

> database is a path-like object giving the pathname (absolute or relative to the current working directory) of the database file to be opened. You can use ":memory:" to open a database connection to a database that resides in RAM instead of on disk.

So, while it can be a bytes object, it's still would be a bytes object representing a file-path. It's not bytes object representing a file content of the database.

Hope that helps.

----------
nosy: +SilentGhost
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40154>
_______________________________________

From report at bugs.python.org  Wed Apr  8 13:43:53 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 08 Apr 2020 17:43:53 +0000
Subject: [issue40082] trip_signal() gets NULL tstate on Windows on CTRL+C
In-Reply-To: <1585289232.05.0.154553792707.issue40082@roundup.psfhosted.org>
Message-ID: <1586367833.57.0.3474096442.issue40082@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
title: Assertion failure in trip_signal -> trip_signal() gets NULL tstate on Windows on CTRL+C

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40082>
_______________________________________

From report at bugs.python.org  Wed Apr  8 13:44:08 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 08 Apr 2020 17:44:08 +0000
Subject: [issue37127] Handling pending calls during runtime finalization may
 cause problems.
In-Reply-To: <1559416306.37.0.716771519489.issue37127@roundup.psfhosted.org>
Message-ID: <1586367848.8.0.588123104546.issue37127@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

See also bpo-40082: trip_signal() gets NULL tstate on Windows on CTRL+C.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37127>
_______________________________________

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: [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 13:44:39 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 08 Apr 2020 17:44:39 +0000
Subject: [issue39984] Move pending calls from _PyRuntime to PyInterpreterState
In-Reply-To: <1584406401.63.0.604728519645.issue39984@roundup.psfhosted.org>
Message-ID: <1586367879.85.0.443568981862.issue39984@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I reopen the issue because of bpo-40082 "trip_signal() gets NULL tstate on Windows on CTRL+C" regression.

----------
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39984>
_______________________________________

From report at bugs.python.org  Wed Apr  8 13:47:31 2020
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 08 Apr 2020 17:47:31 +0000
Subject: [issue40229] tty unblocking setraw and save-restore features
In-Reply-To: <1586367846.83.0.241676972691.issue40229@roundup.psfhosted.org>
Message-ID: <1586368051.83.0.452929824935.issue40229@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch
nosy: +python-dev
nosy_count: 1.0 -> 2.0
pull_requests: +18794
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19440

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40229>
_______________________________________

From report at bugs.python.org  Wed Apr  8 14:31:23 2020
From: report at bugs.python.org (Steve Dower)
Date: Wed, 08 Apr 2020 18:31:23 +0000
Subject: [issue40214] test_ctypes.test_load_dll_with_flags Windows failure
In-Reply-To: <1586230066.46.0.791582618244.issue40214@roundup.psfhosted.org>
Message-ID: <1586370683.94.0.955829713719.issue40214@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

> Do you have a general estimate or rough idea as to how much slower it would be in comparison?

It's one sample point, but compare https://buildbot.python.org/all/#/builders/129/builds/708 to https://github.com/python/cpython/runs/571497886

Compile time: 3:32 (release) -> 1:10 (debug)
Test time: 12:28 (release) -> 15:31 (debug)

Though the test timing vary wildly, as some tests cause more contention than others and they run in a random order.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40214>
_______________________________________

From report at bugs.python.org  Wed Apr  8 14:33:07 2020
From: report at bugs.python.org (Jakub Kulik)
Date: Wed, 08 Apr 2020 18:33:07 +0000
Subject: [issue35455] Solaris thread_time doesn't work with current
 implementation
In-Reply-To: <1544452341.93.0.788709270274.issue35455@psf.upfronthosting.co.za>
Message-ID: <1586370787.89.0.210151618978.issue35455@roundup.psfhosted.org>


Jakub Kulik <kulikjak at gmail.com> added the comment:

I was speaking for Oracle Solaris 11.4, where CLOCK_THREAD_CPUTIME_ID is now implemented (and we don't need it in older releases). But you are right that other Solaris/SunOS versions might not have this and hence would find this useful.

I can rebase and reopen the original PR, but I cannot test it that well now that our Solaris doesn't use that part of the code (I can change the #define for testing, that should be sufficient).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35455>
_______________________________________

From report at bugs.python.org  Wed Apr  8 14:38:35 2020
From: report at bugs.python.org (Jakub Kulik)
Date: Wed, 08 Apr 2020 18:38:35 +0000
Subject: [issue35455] Solaris thread_time doesn't work with current
 implementation
In-Reply-To: <1544452341.93.0.788709270274.issue35455@psf.upfronthosting.co.za>
Message-ID: <1586371115.8.0.85320788877.issue35455@roundup.psfhosted.org>


Jakub Kulik <kulikjak at gmail.com> added the comment:

Correction: looking at the PR, I made it so that it checks for SunOS, so even with CLOCK_THREAD_CPUTIME_ID available, new code would be executed. 

So if you believe that this should be implemented for other SunOSes, I can do it ;).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35455>
_______________________________________

From report at bugs.python.org  Wed Apr  8 15:12:07 2020
From: report at bugs.python.org (Rustam S.)
Date: Wed, 08 Apr 2020 19:12:07 +0000
Subject: [issue39010] ProactorEventLoop raises unhandled ConnectionResetError
In-Reply-To: <1575924458.67.0.403977169674.issue39010@roundup.psfhosted.org>
Message-ID: <1586373127.81.0.452892227753.issue39010@roundup.psfhosted.org>


Rustam S. <mreightfive at gmail.com> added the comment:

Please take a look at this as well:
(ipython #12049 'Unhandled exception in event loop' (WinError 995))
https://github.com/ipython/ipython/issues/12049#issuecomment-586544339 and below

----------
nosy: +Rustam S.

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39010>
_______________________________________

From report at bugs.python.org  Wed Apr  8 16:03:27 2020
From: report at bugs.python.org (Kyle Stanley)
Date: Wed, 08 Apr 2020 20:03:27 +0000
Subject: [issue40214] test_ctypes.test_load_dll_with_flags Windows failure
In-Reply-To: <1586230066.46.0.791582618244.issue40214@roundup.psfhosted.org>
Message-ID: <1586376207.86.0.17688445772.issue40214@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:

Steve Dower wrote:
> It's one sample point, but compare https://buildbot.python.org/all/#/builders/129/builds/708 to https://github.com/python/cpython/runs/571497886

FWIW, I'd be +1 in favor for using the debug build then. A few additional minutes would be well worth having more thorough PR tests IMO. If it becomes an issue, we can always revert it back, but it seems that there's little to no harm in trying it out.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40214>
_______________________________________

From report at bugs.python.org  Wed Apr  8 16:10:59 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 08 Apr 2020 20:10:59 +0000
Subject: [issue37127] Handling pending calls during runtime finalization may
 cause problems.
In-Reply-To: <1559416306.37.0.716771519489.issue37127@roundup.psfhosted.org>
Message-ID: <1586376659.81.0.884662358617.issue37127@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset cfc3c2f8b34d3864717ab584c5b6c260014ba55a by Victor Stinner in branch 'master':
bpo-37127: Remove _pending_calls.finishing (GH-19439)
https://github.com/python/cpython/commit/cfc3c2f8b34d3864717ab584c5b6c260014ba55a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37127>
_______________________________________

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: [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 16:38:18 2020
From: report at bugs.python.org (Zachary Ware)
Date: Wed, 08 Apr 2020 20:38:18 +0000
Subject: [issue40230] Itertools.product() Out of Memory Errors
In-Reply-To: <1586376726.21.0.0873613535989.issue40230@roundup.psfhosted.org>
Message-ID: <1586378298.65.0.481859375737.issue40230@roundup.psfhosted.org>


Change by Zachary Ware <zachary.ware at gmail.com>:


----------
components: +Library (Lib) -Distutils
nosy: +rhettinger -dstufft, eric.araujo
stage:  -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40230>
_______________________________________

From report at bugs.python.org  Wed Apr  8 16:55:41 2020
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 08 Apr 2020 20:55:41 +0000
Subject: [issue40216] Support --runstatedir in configure
In-Reply-To: <1586273076.51.0.57389457106.issue40216@roundup.psfhosted.org>
Message-ID: <1586379341.49.0.105485782558.issue40216@roundup.psfhosted.org>


Benjamin Peterson <benjamin at python.org> added the comment:

Upstream autoconf has not had a release in many years. Ubuntu packages a unreleased upstream version that adds runstatedir. Absent a more rigorous process for the regeneration of configure, this change is not useful; it will just get overwritten the next time someone with an older autoconf regenerates it.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40216>
_______________________________________

From report at bugs.python.org  Wed Apr  8 16:58:08 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 08 Apr 2020 20:58:08 +0000
Subject: [issue40082] trip_signal() gets NULL tstate on Windows on CTRL+C
In-Reply-To: <1585289232.05.0.154553792707.issue40082@roundup.psfhosted.org>
Message-ID: <1586379488.88.0.0834071815734.issue40082@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
keywords: +patch
pull_requests: +18795
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19441

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40082>
_______________________________________

From report at bugs.python.org  Wed Apr  8 17:18:03 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 08 Apr 2020 21:18:03 +0000
Subject: [issue37127] Handling pending calls during runtime finalization may
 cause problems.
In-Reply-To: <1559416306.37.0.716771519489.issue37127@roundup.psfhosted.org>
Message-ID: <1586380683.2.0.159862469845.issue37127@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I removed _pending_calls.finishing for multiple reasons:

* _PyEval_AddPendingCall() used the C API whereas the caller may not hold the GIL.
* bpo-40082: trip_signal() can be called from a thread which has no Python thread state. On Windows, CTRL+C calls trip_signal() in a new thread a each call.

I rewrote trip_signal() to only use the PyInterpreterState ("interp") and avoid PyThreadState ("tstate") in PR 19441 to fix bpo-40082.

trip_signal() should read and set atomtic variables: don't modify globals without a lock. _PyEval_AddPendingCall() is not fully async-signal safe yet :-/ Using a lock is unsafe in a signal handler.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37127>
_______________________________________

From report at bugs.python.org  Wed Apr  8 17:19:44 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 08 Apr 2020 21:19:44 +0000
Subject: [issue37127] Handling pending calls during runtime finalization may
 cause problems.
In-Reply-To: <1559416306.37.0.716771519489.issue37127@roundup.psfhosted.org>
Message-ID: <1586380784.17.0.586088439887.issue37127@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> Also, someone did manage to investigate and identify a likely cause:
> https://bugs.python.org/issue33608#msg342791

I made many changes in Python internals since bpo-33608 was reported. I am not aware of any recent issue with pending calls and so close the issue.

If you get new crashes/hangs with pending calls during Python finalization, please open a new issue.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37127>
_______________________________________

From report at bugs.python.org  Wed Apr  8 17:20:10 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 08 Apr 2020 21:20:10 +0000
Subject: [issue33608] Add a cross-interpreter-safe mechanism to indicate that
 an object may be destroyed.
In-Reply-To: <1527017681.69.0.682650639539.issue33608@psf.upfronthosting.co.za>
Message-ID: <1586380810.22.0.42481116647.issue33608@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

New changeset cfc3c2f8b34d3864717ab584c5b6c260014ba55a by Victor Stinner in branch 'master':
bpo-37127: Remove _pending_calls.finishing (GH-19439)
https://github.com/python/cpython/commit/cfc3c2f8b34d3864717ab584c5b6c260014ba55a

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33608>
_______________________________________

From report at bugs.python.org  Wed Apr  8 17:30:24 2020
From: report at bugs.python.org (David Bolen)
Date: Wed, 08 Apr 2020 21:30:24 +0000
Subject: [issue33608] Add a cross-interpreter-safe mechanism to indicate that
 an object may be destroyed.
In-Reply-To: <1527017681.69.0.682650639539.issue33608@psf.upfronthosting.co.za>
Message-ID: <1586381424.58.0.170188802128.issue33608@roundup.psfhosted.org>


Change by David Bolen <db3l.net at gmail.com>:


----------
nosy:  -db3l

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33608>
_______________________________________

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: [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:35:11 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 08 Apr 2020 21:35:11 +0000
Subject: [issue40082] trip_signal() gets NULL tstate on Windows on CTRL+C
In-Reply-To: <1585289232.05.0.154553792707.issue40082@roundup.psfhosted.org>
Message-ID: <1586381711.51.0.57504953796.issue40082@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset b54a99d6432de93de85be2b42a63774f8b4581a0 by Victor Stinner in branch 'master':
bpo-40082: trip_signal() uses the main interpreter (GH-19441)
https://github.com/python/cpython/commit/b54a99d6432de93de85be2b42a63774f8b4581a0


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40082>
_______________________________________

From report at bugs.python.org  Wed Apr  8 17:36:15 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 08 Apr 2020 21:36:15 +0000
Subject: [issue40082] trip_signal() gets NULL tstate on Windows on CTRL+C
In-Reply-To: <1585289232.05.0.154553792707.issue40082@roundup.psfhosted.org>
Message-ID: <1586381775.47.0.397196593844.issue40082@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Thanks for the bug report Alexander Riccio. I fixed bug in master. Python 3.8 is not affected.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40082>
_______________________________________

From report at bugs.python.org  Wed Apr  8 17:37:51 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 08 Apr 2020 21:37:51 +0000
Subject: [issue33608] Add a cross-interpreter-safe mechanism to indicate that
 an object may be destroyed.
In-Reply-To: <1527017681.69.0.682650639539.issue33608@psf.upfronthosting.co.za>
Message-ID: <1586381871.72.0.130012290705.issue33608@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I created bpo-40231: Fix pending calls in subinterpreters.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33608>
_______________________________________

From report at bugs.python.org  Wed Apr  8 17:38:04 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 08 Apr 2020 21:38:04 +0000
Subject: [issue40231] Fix pending calls in subinterpreters
In-Reply-To: <1586381605.22.0.272292107555.issue40231@roundup.psfhosted.org>
Message-ID: <1586381884.92.0.554828853308.issue40231@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I modified _PyEval_AddPendingCall() to accept interp rather than tstate to fix bpo-40082:

New changeset b54a99d6432de93de85be2b42a63774f8b4581a0 by Victor Stinner in branch 'master':
bpo-40082: trip_signal() uses the main interpreter (GH-19441)
https://github.com/python/cpython/commit/b54a99d6432de93de85be2b42a63774f8b4581a0

----------

_______________________________________
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: [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 17:48:47 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 08 Apr 2020 21:48:47 +0000
Subject: [issue33608] Add a cross-interpreter-safe mechanism to indicate that
 an object may be destroyed.
In-Reply-To: <1527017681.69.0.682650639539.issue33608@psf.upfronthosting.co.za>
Message-ID: <1586382527.52.0.804278229546.issue33608@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Pavel Kostyuchenko:
> (...) The error seems to be caused not by those changes, but by lack of synchronization in the multiprocessing.managers.Server.

Pavel: would you mind to open a separated issue to suggest to add synchronization and/or avoid daemon thread in multiprocessing?

The concurrent.futures module was recently modified to avoid daemon threads in bpo-39812.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33608>
_______________________________________

From report at bugs.python.org  Wed Apr  8 17:50:36 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 08 Apr 2020 21:50:36 +0000
Subject: [issue33608] Add a cross-interpreter-safe mechanism to indicate that
 an object may be destroyed.
In-Reply-To: <1527017681.69.0.682650639539.issue33608@psf.upfronthosting.co.za>
Message-ID: <1586382636.95.0.495613595267.issue33608@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> FYI, after merging that PR I realized that the COMPUTE_EVAL_BREAKER macro isn't quite right.

I reworked this function in bpo-40010.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33608>
_______________________________________

From report at bugs.python.org  Wed Apr  8 17:53:48 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 08 Apr 2020 21:53:48 +0000
Subject: [issue39984] Move pending calls from _PyRuntime to PyInterpreterState
In-Reply-To: <1584406401.63.0.604728519645.issue39984@roundup.psfhosted.org>
Message-ID: <1586382828.84.0.483505434208.issue39984@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> I reopen the issue because of bpo-40082 "trip_signal() gets NULL tstate on Windows on CTRL+C" regression.

bpo-40082 is fixed, so I close the issue again.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39984>
_______________________________________

From report at bugs.python.org  Wed Apr  8 17:58:41 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 08 Apr 2020 21:58:41 +0000
Subject: [issue33608] Add a cross-interpreter-safe mechanism to indicate that
 an object may be destroyed.
In-Reply-To: <1527017681.69.0.682650639539.issue33608@psf.upfronthosting.co.za>
Message-ID: <1586383121.75.0.951313702985.issue33608@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

This issue has a long history. A change has been applied and then reverted three times in a row. Pending calls are now per-interpreter.

The issue title is "Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed." but I don't understand if pending calls are expected to be used to communicate between two interpreters. Why not using a UNIX pipe and exchange bytes through it? Py_AddPendingCall() is a weird concept. I would prefer to not abuse it.

Moreover, it's unclear if this issue attempts to *share* a same object between two interpreters. I would prefer to avoid that by any possible way.

I close this issue with a complex history.

If someone wants to continue to work on this topic, please open an issue with a very clear description of what should be done and how it is supposed to be used.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.9 -Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33608>
_______________________________________

From report at bugs.python.org  Wed Apr  8 18:03:07 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 08 Apr 2020 22:03:07 +0000
Subject: [issue40216] Support --runstatedir in configure
In-Reply-To: <1586273076.51.0.57389457106.issue40216@roundup.psfhosted.org>
Message-ID: <1586383387.18.0.854356040324.issue40216@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

When a core developer updates configure.ac, they use their local version of autoconf. It may or may not generate --runstatedir. It doesn't seem common to co-install multiple versions of autoconf, and so we cannot require all core developers to have one specific autoconf version, or a minimum version.

I close the issue. Reopen it or open a new issue if you would like to experiment a different approach.

Fedora always regenerates the configure script from configure.ac. Maybe other Linux distributions do something similar.

The configure script is tracked by Git since it's more convenient for core developers. It's uncommon to update configure.ac, and it avoids a dependency on autoconf to quickly hack CPython.

----------
nosy: +vstinner
resolution:  -> wont fix
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40216>
_______________________________________

From report at bugs.python.org  Wed Apr  8 18:14:26 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 08 Apr 2020 22:14:26 +0000
Subject: [issue40204] Docs build error with Sphinx 3.0 due to invalid C
 declaration
In-Reply-To: <1586183568.2.0.322929459864.issue40204@roundup.psfhosted.org>
Message-ID: <1586384066.88.0.251039705229.issue40204@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> Python 3.8 and Python 3.7 doesn't have Sphinx pinned to 2.2.0 while master does.

In 3.8, .azure-pipelines/docs-steps.yml contains:

- script: python -m pip install sphinx==1.8.2 blurb python-docs-theme

and .travis.yml contains:

- python -m pip install sphinx==1.8.2 blurb python-docs-theme

For example, the Sphinx version was changed from 1.8.1 to 1.8.2 in the CI configuration by:

commit 7f4ba4afd47f21f61de9035544809fc67d136f35
Author: Julien Palard <julien at palard.fr>
Date:   Sat Nov 24 11:35:21 2018 +0100

    Doc: Bump sphinx. (GH-10676)

--

I guess that you're talking about Doc/Makefile which uses "Sphinx" in 3.8 but "Sphinx==2.2.0" in master. Code in 3.8:

venv:
	$(PYTHON) -m venv $(VENVDIR)
	$(VENVDIR)/bin/python3 -m pip install -U pip setuptools
	$(VENVDIR)/bin/python3 -m pip install -U Sphinx blurb python-docs-theme
	@echo "The venv has been created in the $(VENVDIR) directory"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40204>
_______________________________________

From report at bugs.python.org  Wed Apr  8 18:19:48 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 08 Apr 2020 22:19:48 +0000
Subject: [issue40204] Docs build error with Sphinx 3.0 due to invalid C
 declaration
In-Reply-To: <1586183568.2.0.322929459864.issue40204@roundup.psfhosted.org>
Message-ID: <1586384388.16.0.377049499149.issue40204@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +18796
pull_request: https://github.com/python/cpython/pull/19442

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40204>
_______________________________________

From report at bugs.python.org  Wed Apr  8 18:21:40 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 08 Apr 2020 22:21:40 +0000
Subject: [issue40204] Docs build error with Sphinx 3.0 due to invalid C
 declaration
In-Reply-To: <1586183568.2.0.322929459864.issue40204@roundup.psfhosted.org>
Message-ID: <1586384500.68.0.0483740339576.issue40204@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> I guess that you're talking about Doc/Makefile which uses "Sphinx" in 3.8 but "Sphinx==2.2.0" in master.

I wrote PR 19442 to pin Sphinx version to 1.8.2 in Doc/Makefile.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40204>
_______________________________________

From report at bugs.python.org  Wed Apr  8 18:23:11 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 08 Apr 2020 22:23:11 +0000
Subject: [issue22598] Add mUTF-7 codec (UTF-7 modified for IMAP)
In-Reply-To: <1412936657.2.0.48984767576.issue22598@psf.upfronthosting.co.za>
Message-ID: <1586384591.1.0.0911793611446.issue22598@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy:  -vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22598>
_______________________________________

From report at bugs.python.org  Wed Apr  8 18:36:19 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 08 Apr 2020 22:36:19 +0000
Subject: [issue40204] Docs build error with Sphinx 3.0 due to invalid C
 declaration
In-Reply-To: <1586183568.2.0.322929459864.issue40204@roundup.psfhosted.org>
Message-ID: <1586385379.66.0.497736919353.issue40204@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 37a257c0ae0d4ba746397ae7584db887b175ab24 by Victor Stinner in branch '3.8':
bpo-40204: Pin Sphinx version to 1.8.2 in Doc/Makefile (GH-19442)
https://github.com/python/cpython/commit/37a257c0ae0d4ba746397ae7584db887b175ab24


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40204>
_______________________________________

From report at bugs.python.org  Wed Apr  8 18:38:17 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 08 Apr 2020 22:38:17 +0000
Subject: [issue40204] Docs build error with Sphinx 3.0 due to invalid C
 declaration
In-Reply-To: <1586183568.2.0.322929459864.issue40204@roundup.psfhosted.org>
Message-ID: <1586385497.65.0.975480984175.issue40204@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +18797
pull_request: https://github.com/python/cpython/pull/19443

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40204>
_______________________________________

From report at bugs.python.org  Wed Apr  8 18:39:48 2020
From: report at bugs.python.org (Eric Snow)
Date: Wed, 08 Apr 2020 22:39:48 +0000
Subject: [issue40077] Convert static types to PyType_FromSpec()
In-Reply-To: <1585309613.36.0.628110760271.issue40077@roundup.psfhosted.org>
Message-ID: <CALFfu7CHDGCmdF=+hGcAywCuH09NZ6eEzXFLu8B_n_ZKb1hFng@mail.gmail.com>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

> Wouldn't having less static types slow down startup time?

FWIW, I've been considering an approach where the main interpreter
keeps using static types but subinterpreters use heap types.  If it
isn't too much effort (or too hacky) then it might be a sufficient
solution for now.

----------
nosy: +eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40077>
_______________________________________

From report at bugs.python.org  Wed Apr  8 18:40:39 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 08 Apr 2020 22:40:39 +0000
Subject: [issue40112] AIX: xlc - default path changed and no longer recognized
In-Reply-To: <1585567095.85.0.705098258477.issue40112@roundup.psfhosted.org>
Message-ID: <1586385639.69.0.56357122235.issue40112@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +18798
pull_request: https://github.com/python/cpython/pull/19444

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40112>
_______________________________________

From report at bugs.python.org  Wed Apr  8 18:44:00 2020
From: report at bugs.python.org (brian.gallagher)
Date: Wed, 08 Apr 2020 22:44:00 +0000
Subject: [issue39891] [difflib] Improve get_close_matches() to better match
 when casing of words are different
In-Reply-To: <1583623675.84.0.678348320324.issue39891@roundup.psfhosted.org>
Message-ID: <1586385840.65.0.713814737141.issue39891@roundup.psfhosted.org>


brian.gallagher <oss.brnglr at gmail.com> added the comment:

Just giving this a bump, in case it has been forgotten about.

I've posted a patch at https://github.com/python/cpython/pull/18983.

It adds a new parameter "ignorecase" to get_close_matches() that, if set to True, will result in the SequenceMatcher treating any character case insensitively (as determined by str.lower()).

The benefit to using this keyword, as opposed to letting the application handle the normalization, is that it saves on memory. If the application has to normalize and supply a separate list to get_close_matches(), then it ends up having to maintain a mapping between the original string and the normalized string. As an example:

>>> from difflib import get_close_matches
>>> word = 'apple'
>>> possibilities = ['apPLE', 'APPLE', 'APE', 'Banana', 'Fruit', 'PEAR', 'CoCoNuT']
>>> normalized_possibilities = {p.lower(): p for p in possibilities}
>>> result = get_close_matches(word, normalized_possibilities.keys())
>>> result
['apple', 'ape']
>>> normalized_result = [normalized_possibilities[r] for r in result]
>>> normalized_result
['APPLE', 'APE']

By letting the SequenceMatcher handle the casing on the fly, we could potentially save large amounts of memory if someone was providing a huge list to get_close_matches.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39891>
_______________________________________

From report at bugs.python.org  Wed Apr  8 19:04:28 2020
From: report at bugs.python.org (Eric Snow)
Date: Wed, 08 Apr 2020 23:04:28 +0000
Subject: [issue33608] Add a cross-interpreter-safe mechanism to indicate that
 an object may be destroyed.
In-Reply-To: <1586383121.75.0.951313702985.issue33608@roundup.psfhosted.org>
Message-ID: <CALFfu7AmbAd0wXKyygbHKFkFBBgyoccv6MJHDbmjHoU6d81FQg@mail.gmail.com>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

> I close this issue with a complex history.
>
> If someone wants to continue to work on this topic, please open an issue with a very clear description of what should be done and how it is supposed to be used.

Yeah, there is more to do.  I'll create a new issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33608>
_______________________________________

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: [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: [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 19:18:43 2020
From: report at bugs.python.org (Eric Snow)
Date: Wed, 08 Apr 2020 23:18:43 +0000
Subject: [issue37266] Daemon threads must be forbidden in subinterpreters
In-Reply-To: <1583144987.31.0.43615589197.issue37266@roundup.psfhosted.org>
Message-ID: <CALFfu7A2zUXbT6LDVXGMrAdm-J+=1-hsDvUnfQks7_3+nqt7FA@mail.gmail.com>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

I've opened bpo-40234 to address backward incompatibility from this
change (e.g. affecting mod-wsgi).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37266>
_______________________________________

From report at bugs.python.org  Wed Apr  8 20:42:21 2020
From: report at bugs.python.org (Peter Lovett)
Date: Thu, 09 Apr 2020 00:42:21 +0000
Subject: [issue39010] ProactorEventLoop raises unhandled ConnectionResetError
In-Reply-To: <1575924458.67.0.403977169674.issue39010@roundup.psfhosted.org>
Message-ID: <1586392941.03.0.799291895516.issue39010@roundup.psfhosted.org>


Change by Peter Lovett <pacqa100 at yahoo.com.au>:


----------
nosy: +PeterL777

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39010>
_______________________________________

From report at bugs.python.org  Wed Apr  8 21:49:09 2020
From: report at bugs.python.org (Dennis Sweeney)
Date: Thu, 09 Apr 2020 01:49:09 +0000
Subject: [issue40230] Itertools.product() Out of Memory Errors
In-Reply-To: <1586376726.21.0.0873613535989.issue40230@roundup.psfhosted.org>
Message-ID: <1586396949.55.0.719669231764.issue40230@roundup.psfhosted.org>


Dennis Sweeney <sweeney.dennis650 at gmail.com> added the comment:

The trouble is that itertools.product accepts iterators, and there is no guaranteed way of "restarting" an arbitrary iterator in Python. Consider:

    >>> a = iter([1,2,3])
    >>> b = iter([4,5,6])
    >>> next(a)
    1
    >>> next(b)
    4
    >>> from itertools import product
    >>> list(product(a, b))
    [(2, 5), (2, 6), (3, 5), (3, 6)]

Since there's no way to get back to items you've already consumed, the current approach is to consume all of the iterators to begin with and store their items in arrays, then lazily produce tuples of the items at the right indices of those arrays.

Perhaps one could consume lazily from the iterators, say, only filling up the pools as they're needed and not storing the contents of the first iterator, but this would mean sometimes producing a product iterator that was doomed to cause a memory error eventually. If you really need this behavior you could do this in Python:

    def lazy_product(*iterables):
        if not iterables:
            yield ()
            return
        it0 = iterables[0]
        for x in it0:
            print(f"{x=}")
            for rest in lazy_product(*iterables[1:]):
                print(f"{rest=}")
                yield (x,) + rest

The above could surely be optimized as maybe you're suggesting, but this would be a backward-incompatible change for itertools.product.

----------
nosy: +Dennis Sweeney

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40230>
_______________________________________

From report at bugs.python.org  Wed Apr  8 21:51:40 2020
From: report at bugs.python.org (Dennis Sweeney)
Date: Thu, 09 Apr 2020 01:51:40 +0000
Subject: [issue40230] Itertools.product() Out of Memory Errors
In-Reply-To: <1586376726.21.0.0873613535989.issue40230@roundup.psfhosted.org>
Message-ID: <1586397100.26.0.471354882583.issue40230@roundup.psfhosted.org>


Change by Dennis Sweeney <sweeney.dennis650 at gmail.com>:


----------
versions: +Python 3.9 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40230>
_______________________________________

From report at bugs.python.org  Wed Apr  8 21:52:45 2020
From: report at bugs.python.org (Andrew Nelson)
Date: Thu, 09 Apr 2020 01:52:45 +0000
Subject: [issue38501] multiprocessing.Pool hangs atexit (and garbage
 collection sometimes)
In-Reply-To: <1571250674.69.0.928369483471.issue38501@roundup.psfhosted.org>
Message-ID: <1586397165.99.0.743154834056.issue38501@roundup.psfhosted.org>


Change by Andrew Nelson <andyfaff at gmail.com>:


----------
nosy: +Andrew Nelson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38501>
_______________________________________

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: [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  Wed Apr  8 23:53:45 2020
From: report at bugs.python.org (Tim Peters)
Date: Thu, 09 Apr 2020 03:53:45 +0000
Subject: [issue40230] Itertools.product() Out of Memory Errors
In-Reply-To: <1586376726.21.0.0873613535989.issue40230@roundup.psfhosted.org>
Message-ID: <1586404425.76.0.14463504296.issue40230@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

Possibly related:

    https://bugs.python.org/issue10109

Henry, I'm not clear at all about what you're saying.  Please give at least one specific, concrete example of the behavior you're objecting to, and specify the behavior you want to see instead.

----------
nosy: +tim.peters

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40230>
_______________________________________

From report at bugs.python.org  Wed Apr  8 23:56:29 2020
From: report at bugs.python.org (Andy Lester)
Date: Thu, 09 Apr 2020 03:56:29 +0000
Subject: [issue39943] Meta: Clean up various issues in C internals
In-Reply-To: <1583983387.49.0.277830283994.issue39943@roundup.psfhosted.org>
Message-ID: <1586404589.34.0.0318097632556.issue39943@roundup.psfhosted.org>


Change by Andy Lester <andy at petdance.com>:


----------
pull_requests: +18800
pull_request: https://github.com/python/cpython/pull/19445

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39943>
_______________________________________

From report at bugs.python.org  Thu Apr  9 00:12:42 2020
From: report at bugs.python.org (Daniel Holth)
Date: Thu, 09 Apr 2020 04:12:42 +0000
Subject: [issue40233] Awkward to set compression on writeable ZipFile.open()
In-Reply-To: <1586387645.18.0.880885386366.issue40233@roundup.psfhosted.org>
Message-ID: <1586405562.17.0.627926396993.issue40233@roundup.psfhosted.org>


Daniel Holth <dholth at fastmail.fm> added the comment:

My mistake. It honors ZipInfo if passed.

----------
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40233>
_______________________________________

From report at bugs.python.org  Thu Apr  9 00:56:36 2020
From: report at bugs.python.org (Daniel Holth)
Date: Thu, 09 Apr 2020 04:56:36 +0000
Subject: [issue36129] io documentation unclear about flush() and close()
 semantics for wrapped streams
In-Reply-To: <1551217633.94.0.247260600398.issue36129@roundup.psfhosted.org>
Message-ID: <1586408196.07.0.221406203886.issue36129@roundup.psfhosted.org>


Change by Daniel Holth <dholth at fastmail.fm>:


----------
nosy: +dholth

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36129>
_______________________________________

From report at bugs.python.org  Thu Apr  9 02:47:47 2020
From: report at bugs.python.org (Ammar Askar)
Date: Thu, 09 Apr 2020 06:47:47 +0000
Subject: [issue40202] Misleading grammatically of ValueError Message?
In-Reply-To: <1586160974.41.0.711704681431.issue40202@roundup.psfhosted.org>
Message-ID: <1586414867.66.0.484489467409.issue40202@roundup.psfhosted.org>


Ammar Askar <ammar at ammaraskar.com> added the comment:

Jacob, let's skip the 2.7 part of the report since that is EOL now. For reference, the full error on the latest Python is:

>>> a, b, c, d = [1, 2, 3]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: not enough values to unpack (expected 4, got 3)

>>> a, b = [1, 2, 3]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: too many values to unpack (expected 2)


The first example already behaves as Steven describes, it gives the expected and actual count. In the second example it's difficult to calculate the x for "expected 2, got x" in general. This is because the iterable being unpacked could be a generator. For example, consider:

>>> a, b = itertools.repeat(42)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: too many values to unpack (expected 2)

However, we could improve the message if the object being unpacked does expose a length. I've attached a PR that does this, it makes the error look like:

>>> a, b = [1, 2, 3]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: too many values to unpack (expected 2, got 3)

Hopefully showing the amounts should help clarify why the error was thrown even if the wording seems a bit iffy.

----------
nosy: +ammar2

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40202>
_______________________________________

From report at bugs.python.org  Thu Apr  9 02:47:57 2020
From: report at bugs.python.org (Ammar Askar)
Date: Thu, 09 Apr 2020 06:47:57 +0000
Subject: [issue40202] Misleading grammatically of ValueError Message?
In-Reply-To: <1586160974.41.0.711704681431.issue40202@roundup.psfhosted.org>
Message-ID: <1586414877.09.0.578744345019.issue40202@roundup.psfhosted.org>


Change by Ammar Askar <ammar at ammaraskar.com>:


----------
keywords: +patch
pull_requests: +18801
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19446

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40202>
_______________________________________

From report at bugs.python.org  Thu Apr  9 03:46:22 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 09 Apr 2020 07:46:22 +0000
Subject: [issue40176] unterminated string literal tokenization error messages
 could be better
In-Reply-To: <1585936724.82.0.54480834244.issue40176@roundup.psfhosted.org>
Message-ID: <1586418382.72.0.421211435207.issue40176@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I afraid there may be confusion between triple, double and single quoted string literals. So I suggest to change error messages to just "unterminated triple-quoted string literal" and "unterminated string literal" (or "unterminated single-quoted string literal"). Terms "triple-quoted" and "single-quoted" are used several times in the documentation. Term "double-quoted" is used only once, and I suppose in different meaning.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40176>
_______________________________________

From report at bugs.python.org  Thu Apr  9 04:08:30 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 09 Apr 2020 08:08:30 +0000
Subject: [issue40202] Misleading grammatically of ValueError Message?
In-Reply-To: <1586160974.41.0.711704681431.issue40202@roundup.psfhosted.org>
Message-ID: <1586419710.71.0.38139626192.issue40202@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

It was discussed in issue39816.

I do not think that calling len() and ignoring any exception is a good idea.

1. This may silence some exceptions (errors in the __len__ implementation, MemoryError, RecursionError, KeyboardInterrupt) which should not be silenced.

2. __len__() may have side effect.

3. __next__() may affects the result of __len__() (for example __next__() pops a value of the queue, and __len__() returns the size of the queue), so using the result of __len__() after calling __next__() may be misleading.

Since the original report was about 2.7 which is no longer maintained, I propose to close this issue as outdated.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40202>
_______________________________________

From report at bugs.python.org  Thu Apr  9 04:08:48 2020
From: report at bugs.python.org (Peixing Xin)
Date: Thu, 09 Apr 2020 08:08:48 +0000
Subject: [issue31904] Python should support VxWorks RTOS
In-Reply-To: <1509393393.78.0.213398074469.issue31904@psf.upfronthosting.co.za>
Message-ID: <1586419728.73.0.945709511026.issue31904@roundup.psfhosted.org>


Change by Peixing Xin <peixing.xin at windriver.com>:


----------
pull_requests: +18802
pull_request: https://github.com/python/cpython/pull/19447

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31904>
_______________________________________

From report at bugs.python.org  Thu Apr  9 04:34:06 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Thu, 09 Apr 2020 08:34:06 +0000
Subject: [issue40202] Misleading grammatically of ValueError Message?
In-Reply-To: <1586419710.71.0.38139626192.issue40202@roundup.psfhosted.org>
Message-ID: <20200409083114.GR16830@ando.pearwood.info>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

> Since the original report was about 2.7 which is no longer maintained, 
> I propose to close this issue as outdated.

For what it's worth, I'm okay with closing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40202>
_______________________________________

From report at bugs.python.org  Thu Apr  9 04:38:42 2020
From: report at bugs.python.org (Peixing Xin)
Date: Thu, 09 Apr 2020 08:38:42 +0000
Subject: [issue31904] Python should support VxWorks RTOS
In-Reply-To: <1509393393.78.0.213398074469.issue31904@psf.upfronthosting.co.za>
Message-ID: <1586421522.5.0.547658487672.issue31904@roundup.psfhosted.org>


Change by Peixing Xin <peixing.xin at windriver.com>:


----------
pull_requests: +18803
pull_request: https://github.com/python/cpython/pull/19448

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31904>
_______________________________________

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: [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 07:08:17 2020
From: report at bugs.python.org (brendon zhang)
Date: Thu, 09 Apr 2020 11:08:17 +0000
Subject: [issue40225] recursive call within generator expression is O(depth)
In-Reply-To: <1586347827.41.0.754437002794.issue40225@roundup.psfhosted.org>
Message-ID: <1586430497.19.0.312240457142.issue40225@roundup.psfhosted.org>


Change by brendon zhang <brendon-zhang at hotmail.com>:


----------
title: generator exhaustion for builtin functions in nested call is O(depth) -> recursive call within generator expression is O(depth)

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40225>
_______________________________________

From report at bugs.python.org  Thu Apr  9 07:15:03 2020
From: report at bugs.python.org (brendon zhang)
Date: Thu, 09 Apr 2020 11:15:03 +0000
Subject: [issue40225] recursive call within generator expression is O(depth)
In-Reply-To: <1586347827.41.0.754437002794.issue40225@roundup.psfhosted.org>
Message-ID: <1586430903.81.0.547247714006.issue40225@roundup.psfhosted.org>


brendon zhang <brendon-zhang at hotmail.com> added the comment:

update 2:
This affects ALL functions which exhaust a generator expression. If that generator expression makes a recursive call, then the cost of evaluating it is O(depth), when it should be only O(1).

You can see demonstrate that this doesn't just affect builtins, by replacing max() with a custom implementation such as,

def custommax(it):
    best = -9999999
    for x in it:
        if x > best:
            best = x
    return best

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40225>
_______________________________________

From report at bugs.python.org  Thu Apr  9 07:17:55 2020
From: report at bugs.python.org (brendon zhang)
Date: Thu, 09 Apr 2020 11:17:55 +0000
Subject: [issue40225] recursive call within generator expression is O(depth)
In-Reply-To: <1586347827.41.0.754437002794.issue40225@roundup.psfhosted.org>
Message-ID: <1586431075.9.0.0133708017472.issue40225@roundup.psfhosted.org>


Change by brendon zhang <brendon-zhang at hotmail.com>:


----------
nosy: +rhettinger, vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40225>
_______________________________________

From report at bugs.python.org  Thu Apr  9 07:25:23 2020
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Thu, 09 Apr 2020 11:25:23 +0000
Subject: [issue40225] recursive call within generator expression is O(depth)
In-Reply-To: <1586347827.41.0.754437002794.issue40225@roundup.psfhosted.org>
Message-ID: <1586431523.34.0.521129448881.issue40225@roundup.psfhosted.org>


R?mi Lapeyre <remi.lapeyre at henki.fr> added the comment:

Hi brendon, can you write a complete minimal example that shows the issue, it seems that you are heving an issue when consuming recursive generators and that it's actually not related to max().

I'm confused about the details and have not been able to write an example that exposes the issue from the various pieces of code you posted.

----------
nosy: +remi.lapeyre

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40225>
_______________________________________

From report at bugs.python.org  Thu Apr  9 07:42:38 2020
From: report at bugs.python.org (E)
Date: Thu, 09 Apr 2020 11:42:38 +0000
Subject: [issue27054] Python installation problem: No module named 'encodings'
In-Reply-To: <45B64D1540141C4AA0F8F3974D714AEA64D3D93D@S197.admin.wpi.edu>
Message-ID: <1586432558.2.0.268245867071.issue27054@roundup.psfhosted.org>


E <ergun920 at live.com> added the comment:

python3 gave the error but I could sudo python3. To solve:
export PYTHONHOME=
export PYTHONPATH=

----------
nosy: +ergun

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27054>
_______________________________________

From report at bugs.python.org  Thu Apr  9 08:03:53 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 09 Apr 2020 12:03:53 +0000
Subject: [issue25780] Add support for CAN_RAW_JOIN_FILTERS
In-Reply-To: <1449074447.29.0.213464499345.issue25780@psf.upfronthosting.co.za>
Message-ID: <1586433833.18.0.498200259898.issue25780@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset 97e0de04b8cd44474e452a028761e34407192041 by Zackery Spytz in branch 'master':
bpo-25780: Expose CAN_RAW_JOIN_FILTERS in the socket module (GH-19190)
https://github.com/python/cpython/commit/97e0de04b8cd44474e452a028761e34407192041


----------
nosy: +pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25780>
_______________________________________

From report at bugs.python.org  Thu Apr  9 08:04:19 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 09 Apr 2020 12:04:19 +0000
Subject: [issue25780] Add support for CAN_RAW_JOIN_FILTERS
In-Reply-To: <1449074447.29.0.213464499345.issue25780@psf.upfronthosting.co.za>
Message-ID: <1586433859.24.0.98687579615.issue25780@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25780>
_______________________________________

From report at bugs.python.org  Thu Apr  9 08:13:27 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 09 Apr 2020 12:13:27 +0000
Subject: [issue40214] test_ctypes.test_load_dll_with_flags Windows failure
In-Reply-To: <1586230066.46.0.791582618244.issue40214@roundup.psfhosted.org>
Message-ID: <1586434407.22.0.161109542292.issue40214@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
nosy: +miss-islington
nosy_count: 7.0 -> 8.0
pull_requests: +18804
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/19449

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40214>
_______________________________________

From report at bugs.python.org  Thu Apr  9 08:27:15 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 09 Apr 2020 12:27:15 +0000
Subject: [issue40214] test_ctypes.test_load_dll_with_flags Windows failure
In-Reply-To: <1586230066.46.0.791582618244.issue40214@roundup.psfhosted.org>
Message-ID: <1586435235.54.0.731751513434.issue40214@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Python 3.8 is also affected. Example:
https://github.com/python/cpython/pull/19444#issuecomment-611499825

I backported the change to skip the test until it's fixed: PR 19449.

----------
nosy: +vstinner
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40214>
_______________________________________

From report at bugs.python.org  Thu Apr  9 08:31:56 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 09 Apr 2020 12:31:56 +0000
Subject: [issue40214] test_ctypes.test_load_dll_with_flags Windows failure
In-Reply-To: <1586230066.46.0.791582618244.issue40214@roundup.psfhosted.org>
Message-ID: <1586435516.96.0.568280850418.issue40214@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset c83f003ee5398e9c27a0c634329420003d607d46 by Miss Islington (bot) in branch '3.8':
bpo-40214: Temporarily disable a ctypes test (GH-19404)
https://github.com/python/cpython/commit/c83f003ee5398e9c27a0c634329420003d607d46


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40214>
_______________________________________

From report at bugs.python.org  Thu Apr  9 08:45:51 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Thu, 09 Apr 2020 12:45:51 +0000
Subject: [issue40236] datetime.datetime.strptime get day error
In-Reply-To: <1586426131.65.0.158262640104.issue40236@roundup.psfhosted.org>
Message-ID: <1586436351.53.0.765877217301.issue40236@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

Can you tell us what platform you're on? Also, please include the header that's printed out when you run python from the command line. For example, mine shows:

$ python3
Python 3.7.6 (default, Jan 30 2020, 10:29:04) 
[GCC 9.2.1 20190827 (Red Hat 9.2.1-1)] on linux

----------
components: +Library (Lib)
nosy: +eric.smith

_______________________________________
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: [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 09:02:14 2020
From: report at bugs.python.org (brendon zhang)
Date: Thu, 09 Apr 2020 13:02:14 +0000
Subject: [issue40225] recursive call within generator expression is O(depth)
In-Reply-To: <1586347827.41.0.754437002794.issue40225@roundup.psfhosted.org>
Message-ID: <1586437334.18.0.611738977196.issue40225@roundup.psfhosted.org>


brendon zhang <brendon-zhang at hotmail.com> added the comment:

Okay, I attached a complete minimal example below.

In your shell, run 
ulimit -S -s unlimited

Then try executing with various python versions 3.6 and 3.7
python3.6 benchbug.py
python3.7 benchbug.py

You will notice that python 3.7 has a significant performance regression. It is likely a bug.

----------
Added file: https://bugs.python.org/file49047/consumerbug.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40225>
_______________________________________

From report at bugs.python.org  Thu Apr  9 09:03:44 2020
From: report at bugs.python.org (brendon zhang)
Date: Thu, 09 Apr 2020 13:03:44 +0000
Subject: [issue40225] recursive call within generator expression is O(depth)
In-Reply-To: <1586347827.41.0.754437002794.issue40225@roundup.psfhosted.org>
Message-ID: <1586437424.16.0.0857829546805.issue40225@roundup.psfhosted.org>


brendon zhang <brendon-zhang at hotmail.com> added the comment:

hmm, I can't edit my previous posts. I meant to say

python3.6 consumerbug.py
python3.7 consumerbug.py

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40225>
_______________________________________

From report at bugs.python.org  Thu Apr  9 09:21:31 2020
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Thu, 09 Apr 2020 13:21:31 +0000
Subject: [issue40225] recursive call within generator expression is O(depth)
In-Reply-To: <1586347827.41.0.754437002794.issue40225@roundup.psfhosted.org>
Message-ID: <1586438491.95.0.894221600941.issue40225@roundup.psfhosted.org>


R?mi Lapeyre <remi.lapeyre at henki.fr> added the comment:

I'm unable to run the example as it segfaults on my computer because of the linear recursion but do you notice the same behavior with:

from time import time
from sys import setrecursionlimit

setrecursionlimit(10000000)

def recurse(i):
    if i < 0:
        return
    recurse(i-1)

if __name__ == '__main__':
    lo = 8
    hi = 16
    t = {}

    for sh in range(lo, hi):
        b4 = time()
        x = 1 << sh
        ret = recurse(x)
        after = time()
        t[sh] = after - b4

    for sh in range(lo+1, hi):
        print(t[sh] / t[sh-1])

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40225>
_______________________________________

From report at bugs.python.org  Thu Apr  9 09:36:38 2020
From: report at bugs.python.org (brendon zhang)
Date: Thu, 09 Apr 2020 13:36:38 +0000
Subject: [issue40225] recursive call within generator expression is O(depth)
In-Reply-To: <1586347827.41.0.754437002794.issue40225@roundup.psfhosted.org>
Message-ID: <1586439398.66.0.775709853493.issue40225@roundup.psfhosted.org>


brendon zhang <brendon-zhang at hotmail.com> added the comment:

No, the example you provided does not trigger the same bug. It is explicitly to do with calling recursively from within the generator expression.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40225>
_______________________________________

From report at bugs.python.org  Thu Apr  9 09:37:19 2020
From: report at bugs.python.org (brendon zhang)
Date: Thu, 09 Apr 2020 13:37:19 +0000
Subject: [issue40225] recursive call within generator expression is O(depth)
In-Reply-To: <1586347827.41.0.754437002794.issue40225@roundup.psfhosted.org>
Message-ID: <1586439439.37.0.471487513237.issue40225@roundup.psfhosted.org>


brendon zhang <brendon-zhang at hotmail.com> added the comment:

reduce the upper bound for the recursion depth until it does not segfault

eg
hi = 12

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40225>
_______________________________________

From report at bugs.python.org  Thu Apr  9 09:40:28 2020
From: report at bugs.python.org (brendon zhang)
Date: Thu, 09 Apr 2020 13:40:28 +0000
Subject: [issue40225] recursive call within generator expression is O(depth)
In-Reply-To: <1586347827.41.0.754437002794.issue40225@roundup.psfhosted.org>
Message-ID: <1586439628.56.0.294683479336.issue40225@roundup.psfhosted.org>


brendon zhang <brendon-zhang at hotmail.com> added the comment:

did you remember to run `ulimit -S -s unlimited`? If you don't increase the soft stack limit, your OS will kill the program.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40225>
_______________________________________

From report at bugs.python.org  Thu Apr  9 10:09:54 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 09 Apr 2020 14:09:54 +0000
Subject: [issue40236] datetime.datetime.strptime get day error
In-Reply-To: <1586426131.65.0.158262640104.issue40236@roundup.psfhosted.org>
Message-ID: <1586441394.03.0.453889789064.issue40236@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +belopolsky, p-ganssle

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40236>
_______________________________________

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: [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:40:49 2020
From: report at bugs.python.org (Paul Ganssle)
Date: Thu, 09 Apr 2020 14:40:49 +0000
Subject: [issue40236] datetime.datetime.strptime get day error
In-Reply-To: <1586426131.65.0.158262640104.issue40236@roundup.psfhosted.org>
Message-ID: <1586443249.85.0.307816589992.issue40236@roundup.psfhosted.org>


Paul Ganssle <p.ganssle at gmail.com> added the comment:

I can reproduce this on Linux with Python 3.8.2.

I think this may be a bug, but it may also just be platform-specific weirdness. Either way it's very curious behavior:


>>> datetime.strptime("2023-0-0", "%Y-%W-%w")                         
datetime.datetime(2023, 1, 1, 0, 0)
>>> datetime.strptime("2023-0-1", "%Y-%W-%w")                         
datetime.datetime(2022, 12, 26, 0, 0)

The definition for %W (and %U, which is related) goes like this:


> Week number of the year (Monday as the first day of the week) as a decimal number. All days in a new year preceding the first Monday are considered to be in week 0.

2024 starts on a Monday, so there should be no Week 0 in that year at all. Seems to me like it's undefined what happens when you put in a string that puts in an invalid value for "%Y-%W-%w".

Seems to me that we are just passing through the behavior of `time.strptime` in this case (which just calls out to what the platform does):

>>> time.strptime("2024-0-3", "%Y-%W-%w")                             
time.struct_time(tm_year=2024, tm_mon=1, tm_mday=3, tm_hour=0, tm_min=0, tm_sec=0, tm_wday=2, tm_yday=3, tm_isdst=-1)


I am open to discussion about trying to rationalize this behavior - it would be a bit tricky but if we moved to our own implementation of the algorithm to calculate %W we could detect this situation and throw an exception. I'd rather see if this is intended behavior in the underlying C implementation first, though. If this is consistent across platforms and not just some random implementation detail, people may be relying on it.

I propose that we:

1. Determine what happens on different platforms (might be easy to just make a PR that asserts the current behavior and see if/how it breaks on any of the supported platforms).
2. Determine why it works the way it does.


After that, at the very least we should document the behavior with a warning or a footnote or something. If we make any changes to the behavior they would be 3.9+, but the documentation changes can be backported.

Thanks for the bug report zhanying! Very interesting!

----------
versions: +Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40236>
_______________________________________

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: [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 10:42:59 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 09 Apr 2020 14:42:59 +0000
Subject: [issue40238] os.stat() on Windows succeeds for nonexistent paths with
 trailing spaces
In-Reply-To: <1586442330.4.0.896715206677.issue40238@roundup.psfhosted.org>
Message-ID: <1586443379.51.0.820335899101.issue40238@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40238>
_______________________________________

From report at bugs.python.org  Thu Apr  9 10:55:48 2020
From: report at bugs.python.org (Eric Cousineau)
Date: Thu, 09 Apr 2020 14:55:48 +0000
Subject: [issue32377] Difference in ressurrection behavior with __del__ in py2
 vs. py3
In-Reply-To: <1513700999.05.0.213398074469.issue32377@psf.upfronthosting.co.za>
Message-ID: <1586444148.18.0.625815694597.issue32377@roundup.psfhosted.org>


Eric Cousineau <eric.cousineau at tri.global> added the comment:

Super late response, but for this part:

> Well... perhaps you could create another PyObject (it's just a wrapper,
> right?) since the old one doesn't have any outside references to it
> remaining.

In certain cases, yes, that would be the case. I do have unittests that
(hackily) check `id(o)` before and after resurrection by using a `weakref`,
so I could relax that contract.

However, in other cases, the "wrapper" object in Python is actually a C++
base class that has been derived from in Python. If ownership of the C++
instance (which should more-or-less own the Python portion) goes solely to C++,
then the Python portion could be garbage collected, and you get a sort-of
slicing effect:
https://github.com/pybind/pybind11/issues/1145

Granted, within this web of issues, one alternative is to always extend the
lifetime of the Python object by the C++ portion. However, that creates a
(opaque?) reference cycle between C++ and CPython, so I am a bit afraid of what
that would do. I would prefer to make memory management conservative if
possible.

Or rather: It's something cool to try out, but I have not yet had time to dig
in :(

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32377>
_______________________________________

From report at bugs.python.org  Thu Apr  9 10:56:23 2020
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Thu, 09 Apr 2020 14:56:23 +0000
Subject: [issue40239] Add a function for merging sorted iterables
In-Reply-To: <1586443349.52.0.011091886017.issue40239@roundup.psfhosted.org>
Message-ID: <1586444183.73.0.680794608574.issue40239@roundup.psfhosted.org>


R?mi Lapeyre <remi.lapeyre at henki.fr> added the comment:

Hi Serhiy, do you plan on writing a PR for this feature?

If not I would love to have a go at it.

----------
nosy: +remi.lapeyre

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40239>
_______________________________________

From report at bugs.python.org  Thu Apr  9 11:03:17 2020
From: report at bugs.python.org (Tim Peters)
Date: Thu, 09 Apr 2020 15:03:17 +0000
Subject: [issue40239] Add a function for merging sorted iterables
In-Reply-To: <1586443349.52.0.011091886017.issue40239@roundup.psfhosted.org>
Message-ID: <1586444597.64.0.697865479489.issue40239@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

Serhiy, are you aware of heapq.merge()?  If not, look it up.  And then if you still think merge_sorted() would differ in some way, please spell out how it would differ.

Based on what you wrote, you threw an invalid invocation of tee() into the mix for some reason, which heapq.merge() certainly doesn't do.

And it's impossible to keep a small bound on memory use when reverse=True if you want it return the same sequence as sorted(... reverse=True).  Instead, for heapq.merge().

"""
reverse is a boolean value. If set to True, then the input elements are merged as if each comparison were reversed. To achieve behavior similar to sorted(itertools.chain(*iterables), reverse=True), all iterables must be sorted from largest to smallest.
"""

----------

_______________________________________
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: [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:10:36 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Thu, 09 Apr 2020 15:10:36 +0000
Subject: [issue40077] Convert static types to PyType_FromSpec()
In-Reply-To: <1585238684.65.0.246012172449.issue40077@roundup.psfhosted.org>
Message-ID: <1586445036.71.0.0355719245438.issue40077@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:


New changeset dcb04d9c6dd6f31449ade6765fa4d26a305e7381 by Hai Shi in branch 'master':
bpo-40077: Remove redundant cast in json module (GH-19438)
https://github.com/python/cpython/commit/dcb04d9c6dd6f31449ade6765fa4d26a305e7381


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40077>
_______________________________________

From report at bugs.python.org  Thu Apr  9 11:10:43 2020
From: report at bugs.python.org (Paul Ganssle)
Date: Thu, 09 Apr 2020 15:10:43 +0000
Subject: [issue40236] datetime.datetime.strptime get day error
In-Reply-To: <1586426131.65.0.158262640104.issue40236@roundup.psfhosted.org>
Message-ID: <1586445043.49.0.615234565193.issue40236@roundup.psfhosted.org>


Paul Ganssle <p.ganssle at gmail.com> added the comment:

Likely relevant is bpo-23136, where they dealt with similar issues in the past.

I don't see any explicit test for this behavior, but it seems that the solution is to try to be consistent and to not raise a ValueError.

Looking at this issue, I think it's a manifestation of a similar bug that hits when a year starts with a Monday.

It seems like the behavior is that the following days (%W-%w) should be sequential in any year: 00-1, 00-2, 00-3, 00-4, 00-5, 00-6, 00-0, 01-1, 01-2, ...

Since 2024 starts in a Monday, the first day of the year should be 2024-01-1, and the 2024-00-1 week should start 2023-12-25 rather than duplicating the following week.

I think there's an equivalent issue with dates of the form "%Y-%U-%w", but happening on years that start with a Sunday.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40236>
_______________________________________

From report at bugs.python.org  Thu Apr  9 11:18:54 2020
From: report at bugs.python.org (hai shi)
Date: Thu, 09 Apr 2020 15:18:54 +0000
Subject: [issue40237] Test code coverage (C) job of Travis CI fails on
 test_distutils which creates _configtest.gcno file
In-Reply-To: <1586436730.26.0.786791148526.issue40237@roundup.psfhosted.org>
Message-ID: <1586445534.4.0.183665628058.issue40237@roundup.psfhosted.org>


Change by hai shi <shihai1991 at 126.com>:


----------
nosy: +shihai1991

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40237>
_______________________________________

From report at bugs.python.org  Thu Apr  9 11:19:47 2020
From: report at bugs.python.org (Eryk Sun)
Date: Thu, 09 Apr 2020 15:19:47 +0000
Subject: [issue40238] os.stat() on Windows succeeds for nonexistent paths with
 trailing spaces
In-Reply-To: <1586442330.4.0.896715206677.issue40238@roundup.psfhosted.org>
Message-ID: <1586445587.88.0.252945434595.issue40238@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> os.stat() seems to be striping significant trailing spaces off 
> the path argument

The Windows file API normalizes paths to replace forward slashes with backslashes; resolve relative paths and "." and ".." components; strip trailing spaces and dots from the final component; and map reserved DOS device names in the final component of non-UNC paths to device paths (e.g. "C:/Temp/con " -> r"\\.\con").

Use a "\\?\" extended device path to bypass normalization, e.g. r"\\?\C:\Program Files     ". Because an extended path doesn't get normalized in an open or create context, it should only use backslash as the path separator and should be fully qualified, without any "." and ".." components. Also, a non-device UNC path has to explicitly use the "UNC" device, e.g. "//server/share/spam... " -> r"\\?\UNC\server\share\spam... ".

That said, I strongly advise against using an extended path to create or rename files to use reserved DOS device names or trailing dots and spaces. Such filenames will be inaccessible by most applications.

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed
versions: +Python 3.9 -Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40238>
_______________________________________

From report at bugs.python.org  Thu Apr  9 11:20:21 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 09 Apr 2020 15:20:21 +0000
Subject: [issue40240] Expose public spelling of _PyGC_FINALIZED and
 _PyGC_SET_FINALIZED?
In-Reply-To: <1586444432.56.0.946879588514.issue40240@roundup.psfhosted.org>
Message-ID: <1586445621.45.0.199593651532.issue40240@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

See also bpo-40241: "[C API] Make PyGC_Head structure opaque, or even more it to the internal C API".

----------
nosy: +pablogsal, pitrou, vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40240>
_______________________________________

From report at bugs.python.org  Thu Apr  9 11:20:32 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 09 Apr 2020 15:20:32 +0000
Subject: [issue40241] [C API] Make PyGC_Head structure opaque,
 or even more it to the internal C API
In-Reply-To: <1586445596.83.0.583225080007.issue40241@roundup.psfhosted.org>
Message-ID: <1586445632.13.0.606193223611.issue40241@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

See also bpo-40240: "Expose public spelling of _PyGC_FINALIZED and _PyGC_SET_FINALIZED?".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40241>
_______________________________________

From report at bugs.python.org  Thu Apr  9 11:33:41 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 09 Apr 2020 15:33:41 +0000
Subject: [issue40112] AIX: xlc - default path changed and no longer recognized
In-Reply-To: <1585567095.85.0.705098258477.issue40112@roundup.psfhosted.org>
Message-ID: <1586446421.54.0.830057470257.issue40112@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I backported the fix to 3.8 to fix AIX 3.8 buildbots.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40112>
_______________________________________

From report at bugs.python.org  Thu Apr  9 11:34:32 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Thu, 09 Apr 2020 15:34:32 +0000
Subject: [issue40232] PyOS_AfterFork_Child() should use
 _PyThread_at_fork_reinit()
In-Reply-To: <1586382203.52.0.537965691861.issue40232@roundup.psfhosted.org>
Message-ID: <1586446472.61.0.966735221352.issue40232@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
nosy: +corona10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40232>
_______________________________________

From report at bugs.python.org  Thu Apr  9 11:32:29 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 09 Apr 2020 15:32:29 +0000
Subject: [issue40112] AIX: xlc - default path changed and no longer recognized
In-Reply-To: <1585567095.85.0.705098258477.issue40112@roundup.psfhosted.org>
Message-ID: <1586446349.41.0.488062652588.issue40112@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset cd8e1da3eaf1b39cc0897def3845da2d793a9e4c by Victor Stinner in branch '3.8':
bpo-40112: distutils test_search_cpp: Fix logic to determine if C compiler is xlc on AIX (GH-19225) (GH-19444)
https://github.com/python/cpython/commit/cd8e1da3eaf1b39cc0897def3845da2d793a9e4c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40112>
_______________________________________

From report at bugs.python.org  Thu Apr  9 11:30:23 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Thu, 09 Apr 2020 15:30:23 +0000
Subject: [issue40236] datetime.datetime.strptime get day error
In-Reply-To: <1586426131.65.0.158262640104.issue40236@roundup.psfhosted.org>
Message-ID: <1586446223.78.0.379705358116.issue40236@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

I thought that strptime is platform specific (which is why I asked for the platform info). But, looking at the existing docs https://docs.python.org/3.5/library/time.html#time.strptime

"But strptime() is independent of any platform and thus does not necessarily support all directives available that are not documented as supported."

I'm not exactly sure what that means overall, with the double negative. But it say it's not platform specific.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40236>
_______________________________________

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: [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 11:25:33 2020
From: report at bugs.python.org (Eric Cousineau)
Date: Thu, 09 Apr 2020 15:25:33 +0000
Subject: [issue32377] Difference in ressurrection behavior with __del__ in py2
 vs. py3
In-Reply-To: <1513700999.05.0.213398074469.issue32377@psf.upfronthosting.co.za>
Message-ID: <1586445933.82.0.233062598364.issue32377@roundup.psfhosted.org>


Eric Cousineau <eric.cousineau at tri.global> added the comment:

See also bpo-40240: "Expose public spelling of _PyGC_FINALIZED and _PyGC_SET_FINALIZED?"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32377>
_______________________________________

From report at bugs.python.org  Thu Apr  9 12:01:40 2020
From: report at bugs.python.org (Eric Cousineau)
Date: Thu, 09 Apr 2020 16:01:40 +0000
Subject: [issue40240] Expose public spelling of _PyGC_FINALIZED and
 _PyGC_SET_FINALIZED?
In-Reply-To: <1586444432.56.0.946879588514.issue40240@roundup.psfhosted.org>
Message-ID: <1586448100.96.0.27768090389.issue40240@roundup.psfhosted.org>


Eric Cousineau <eric.cousineau at tri.global> added the comment:

C functions sound great!

I am certainly not wed to the macros (nor do I love them), as I do not have intense performance requirements where inlining (and spilling implementation guts) is necessary.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40240>
_______________________________________

From report at bugs.python.org  Thu Apr  9 11:54:37 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Thu, 09 Apr 2020 15:54:37 +0000
Subject: [issue40232] PyOS_AfterFork_Child() should use
 _PyThread_at_fork_reinit()
In-Reply-To: <1586382203.52.0.537965691861.issue40232@roundup.psfhosted.org>
Message-ID: <1586447677.97.0.342519457478.issue40232@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

I am going to take a look at this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40232>
_______________________________________

From report at bugs.python.org  Thu Apr  9 11:57:25 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 09 Apr 2020 15:57:25 +0000
Subject: [issue27054] Python installation problem: No module named 'encodings'
In-Reply-To: <45B64D1540141C4AA0F8F3974D714AEA64D3D93D@S197.admin.wpi.edu>
Message-ID: <1586447845.34.0.341721710014.issue27054@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> I continually get the error
> "Fatal Python error: Py_Initialize: unable to load the file system codec
> ImportError: No module named 'encodings'"

FYI I enhanced this error in Python 3.8 to "dump the Python path configuration". Example:

$ PYTHONHOME=x PYTHONPATH=y python3.8
Python path configuration:
  PYTHONHOME = 'x'
  PYTHONPATH = 'y'
  program name = 'python3.8'
  isolated = 0
  environment = 1
  user site = 1
  import site = 1
  sys._base_executable = '/usr/bin/python3.8'
  sys.base_prefix = 'x'
  sys.base_exec_prefix = 'x'
  sys.executable = '/usr/bin/python3.8'
  sys.prefix = 'x'
  sys.exec_prefix = 'x'
  sys.path = [
    'y',
    'x/lib64/python38.zip',
    'x/lib64/python3.8',
    'x/lib64/python3.8/lib-dynload',
  ]
Fatal Python error: init_fs_encoding: failed to get the Python codec of the filesystem encoding
Python runtime state: core initialized
ModuleNotFoundError: No module named 'encodings'

Current thread 0x00007f50aaad8740 (most recent call first):
<no Python frame>

It should be easier for users to understand their mistake.

In general, leave PYTHONHOME empty/unset unless you understand very well what you are doing ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27054>
_______________________________________

From report at bugs.python.org  Thu Apr  9 11:53:29 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 09 Apr 2020 15:53:29 +0000
Subject: [issue40225] recursive call within generator expression is O(depth)
In-Reply-To: <1586347827.41.0.754437002794.issue40225@roundup.psfhosted.org>
Message-ID: <1586447609.82.0.367088633754.issue40225@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy:  -vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40225>
_______________________________________

From report at bugs.python.org  Thu Apr  9 11:46:29 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 09 Apr 2020 15:46:29 +0000
Subject: [issue31904] Python should support VxWorks RTOS
In-Reply-To: <1509393393.78.0.213398074469.issue31904@psf.upfronthosting.co.za>
Message-ID: <1586447189.83.0.976575607045.issue31904@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 5cd28030092eaa8eb9223afd733974fd2afc8e2c by pxinwr in branch 'master':
bpo-31904: Fix test_c_locale_coercion encodings for VxWorks RTOS (GH-19448)
https://github.com/python/cpython/commit/5cd28030092eaa8eb9223afd733974fd2afc8e2c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31904>
_______________________________________

From report at bugs.python.org  Thu Apr  9 12:23:46 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 09 Apr 2020 16:23:46 +0000
Subject: [issue40240] Expose public spelling of _PyGC_FINALIZED and
 _PyGC_SET_FINALIZED?
In-Reply-To: <1586444432.56.0.946879588514.issue40240@roundup.psfhosted.org>
Message-ID: <1586449426.48.0.113092251787.issue40240@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

There is a specific Python function in 3.9 for it:

https://docs.python.org/3.9/library/gc.html#gc.is_finalized

So it may sense to add a function to query if an object is finalized, but I am not sure it makes sense to allow to mark an object as finalized because that could mess with the GC algorithm.

Certainly exposing the macros per se may be a bad idea because there are too many implementation details there (like where the flags are stored) so at least a new function will be needed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40240>
_______________________________________

From report at bugs.python.org  Thu Apr  9 12:25:50 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 09 Apr 2020 16:25:50 +0000
Subject: [issue40240] Expose public spelling of _PyGC_FINALIZED and
 _PyGC_SET_FINALIZED?
In-Reply-To: <1586444432.56.0.946879588514.issue40240@roundup.psfhosted.org>
Message-ID: <1586449550.13.0.273397545205.issue40240@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

I will make a PR for exposing function to query if an object is finalized as for sure there is value on having that in the public API.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40240>
_______________________________________

From report at bugs.python.org  Thu Apr  9 11:20:16 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 09 Apr 2020 15:20:16 +0000
Subject: [issue39599] ABI breakage between Python 3.7.4 and 3.7.5: change in
 PyGC_Head structure
In-Reply-To: <1581339256.79.0.552474006467.issue39599@roundup.psfhosted.org>
Message-ID: <1586445616.72.0.233835373057.issue39599@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

See also bpo-40241: "[C API] Make PyGC_Head structure opaque, or even more it to the internal C API".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39599>
_______________________________________

From report at bugs.python.org  Thu Apr  9 12:33:51 2020
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 09 Apr 2020 16:33:51 +0000
Subject: [issue39943] Meta: Clean up various issues in C internals
In-Reply-To: <1583983387.49.0.277830283994.issue39943@roundup.psfhosted.org>
Message-ID: <1586450031.87.0.613810960878.issue39943@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


----------
nosy:  -brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39943>
_______________________________________

From report at bugs.python.org  Thu Apr  9 11:27:51 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 09 Apr 2020 15:27:51 +0000
Subject: [issue40240] Expose public spelling of _PyGC_FINALIZED and
 _PyGC_SET_FINALIZED?
In-Reply-To: <1586444432.56.0.946879588514.issue40240@roundup.psfhosted.org>
Message-ID: <1586446071.53.0.288125605669.issue40240@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> Is it at all possible to considering making some of this public API?

In bpo-35081, I wanted to move PyGC macros to the internal C API because they are private functions, but also because they expose implementation details. Example:

#define _PyGC_PREV_MASK_FINALIZED  (1)
#define _PyGCHead_FINALIZED(g) \
    (((g)->_gc_prev & _PyGC_PREV_MASK_FINALIZED) != 0)
#define _Py_AS_GC(o) ((PyGC_Head *)(o)-1)
#define _PyGC_FINALIZED(o) \
    _PyGCHead_FINALIZED(_Py_AS_GC(o))

_Py_AS_GC(o) emits machine code which hardcodes the size and alignment of the PyGC_Head structure. If PyGC_Head is changed, machine code will crash or misbehave at least. And that happened recently: bpo-27987 changed PyGC_Head between Python 3.7.4 and 3.7.5 with commit 8766cb74e186d3820db0a855ccd780d6d84461f7.

I'm not against exposing the "feature" in the public C API. I'm only against exposing macros which "leak" implementation details. What I did recently is to add regular functions in the public C API, and keep macros and static inline functions for the internal C API.

We can for example add "int PyGC_Finalized(PyObject *obj);" function which would be opaque in term of ABI.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40240>
_______________________________________

From report at bugs.python.org  Thu Apr  9 12:52:44 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 09 Apr 2020 16:52:44 +0000
Subject: [issue40234] Disallow daemon threads in subinterpreters optionally.
In-Reply-To: <1586387812.86.0.0296012569674.issue40234@roundup.psfhosted.org>
Message-ID: <1586451164.72.0.515762112408.issue40234@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

First of all, I know that mod_wsgi uses subinterpreters, but I didn't know that it uses daemon threads. When I hack Python to better isolate subinterpreters, I keep mod_wsgi in mind ;-)


My commit 066e5b1a917ec2134e8997d2cadd815724314252 message says: "Daemon threads were never supported in subinterpreters." That's inaccurate. Only the second sentence is correct: "Previously, the subinterpreter finalization crashed with a Pyton fatal error if a daemon thread was still running."

In Python 3.8, it is possible to use daemon thread but only if they complete before Py_EndInterpreter() is called.

I'm not comfortable with Python "crashing" (call Py_FatalError() which calls abort() which may generate a coredump) depending if all daemon threads complete or not. I'm trying to make Python finalization more deterministic.


My concern is this Py_EndInterpreter() check:

    if (tstate != interp->tstate_head || tstate->next != NULL) {
        Py_FatalError("not the last thread");
    }


This check is as old as subinterpreters, it was added at the same time than the Py_EndInterpreter() function:

commit 25ce566661c1b7446b3ddb4076513a62f93ce08d
Author: Guido van Rossum <guido at python.org>
Date:   Sat Aug 2 03:10:38 1997 +0000

    The last of the mass checkins for separate (sub)interpreters.
    Everything should now work again.
    
    See the comments for the .h files mass checkin (e.g. pystate.h) for
    more detail.


My concern is that Py_FatalError() exits the whole process, not only the thread calling Py_EndInterpreter(). The caller cannot catch Py_FatalError() call and decide how to handle it :-( That doesn't seem like a good API when Python is embedded in an application.


Recently, I had to deal  with (fix) many bugs related to daemon threads in Python finalization:

* https://vstinner.github.io/gil-bugfixes-daemon-threads-python39.html
* https://vstinner.github.io/threading-shutdown-race-condition.html
* https://vstinner.github.io/daemon-threads-python-finalization-python32.html

Simply denying daemon threads in subinterpreters is the safest and simplest option. But it's also a backward incompatible change.

I'm open to allow again daemon threads in subinterpreter in Python 3.9 but emit a DeprecationWarning to announce that this feature is going to be remove "later" (ex: Python 3.11) since it's "broken by design" (in my opinion).


> We could also deprecate use of daemon threads in *all* subinterpreters, with the goal of dropping support after a while.

It sounds like a good idea to make Python finalization more reliable. But daemon threads are still widely used in the Python standard library. For example, by the multiprocessing module.

concurrent.futures was only modified recently to stop using daemon threads, after I denied spawned daemon threads in subinterpreters:

* bpo-39812
* commit b61b818d916942aad1f8f3e33181801c4a1ed14b

So if someone wants to ban daemon threads, we should start by modifying the stdlib to avoid them, then deprecate the feature, and then we can start talking about removing the feature.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40234>
_______________________________________

From report at bugs.python.org  Thu Apr  9 12:55:44 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 09 Apr 2020 16:55:44 +0000
Subject: [issue40234] Disallow daemon threads in subinterpreters optionally.
In-Reply-To: <1586387812.86.0.0296012569674.issue40234@roundup.psfhosted.org>
Message-ID: <1586451344.16.0.716647057601.issue40234@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Graham Dumpleton started a discussion about bpo-37266 on Twitter:
https://twitter.com/GrahamDumpleton/status/1246374493267701760
https://twitter.com/GrahamDumpleton/status/1246373855532216320

I dislike discussion threads on Twitter. For an unknown reason, I always fail to see all replies. I only see them in Mentions, not in the thread!?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40234>
_______________________________________

From report at bugs.python.org  Thu Apr  9 12:59:00 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 09 Apr 2020 16:59:00 +0000
Subject: [issue40239] Add a function for merging sorted iterables
In-Reply-To: <1586443349.52.0.011091886017.issue40239@roundup.psfhosted.org>
Message-ID: <1586451540.26.0.515037469158.issue40239@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Thank you Tim, it is exactly what I need!

I got this search result, but I rejected it because it looked obvious that the function from the heapq module cannot have any relation to this. :(

I meant chain() instead of tee(), sorry.

----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40239>
_______________________________________

From report at bugs.python.org  Thu Apr  9 12:59:11 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Thu, 09 Apr 2020 16:59:11 +0000
Subject: [issue40232] PyOS_AfterFork_Child() should use
 _PyThread_at_fork_reinit()
In-Reply-To: <1586382203.52.0.537965691861.issue40232@roundup.psfhosted.org>
Message-ID: <1586451551.17.0.860808034829.issue40232@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
keywords: +patch
pull_requests: +18805
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19450

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40232>
_______________________________________

From report at bugs.python.org  Thu Apr  9 13:18:21 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 09 Apr 2020 17:18:21 +0000
Subject: [issue40225] recursive call within generator expression is O(depth)
In-Reply-To: <1586347827.41.0.754437002794.issue40225@roundup.psfhosted.org>
Message-ID: <1586452701.52.0.306259993332.issue40225@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
nosy: +Mark.Shannon, serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40225>
_______________________________________

From report at bugs.python.org  Thu Apr  9 13:28:18 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 09 Apr 2020 17:28:18 +0000
Subject: [issue40204] Docs build error with Sphinx 3.0 due to invalid C
 declaration
In-Reply-To: <1586183568.2.0.322929459864.issue40204@roundup.psfhosted.org>
Message-ID: <1586453298.13.0.864901092252.issue40204@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

I have filed an issue upstream and it's fixed. The release of 3.0.1 is planned in few days and could help for other branches. But it would be nice to see the version pinned to avoid these problems in future. Upstream report : https://github.com/sphinx-doc/sphinx/issues/7423#event-3218761694

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40204>
_______________________________________

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: [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 14:23:42 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Thu, 09 Apr 2020 18:23:42 +0000
Subject: [issue40242] zmq mysql core dump
In-Reply-To: <1586455195.03.0.155128936869.issue40242@roundup.psfhosted.org>
Message-ID: <1586456622.73.0.137932619305.issue40242@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

This looks like a problem in zmq, pyzmq, or mysql-connector-python, not in python itself. I'd suggest asking in a mysql-connector-python specific location for starters.

You should also try to duplicate the problem without importing zmq, which doesn't seem to be used by your example.

A stack trace of the segfault might also shed more light. As it is, there's not a lot to go on here.

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40242>
_______________________________________

From report at bugs.python.org  Thu Apr  9 16:13:05 2020
From: report at bugs.python.org (=?utf-8?b?VmVkcmFuIMSMYcSNacSH?=)
Date: Thu, 09 Apr 2020 20:13:05 +0000
Subject: [issue40202] Misleading grammatically of ValueError Message?
In-Reply-To: <1586160974.41.0.711704681431.issue40202@roundup.psfhosted.org>
Message-ID: <1586463185.23.0.64039866872.issue40202@roundup.psfhosted.org>


Vedran ?a?i? <vedgar at gmail.com> added the comment:

> It says **too many** but I assign a few than the size of the list. am I the one who wrong here?

Yes. The same as here:

> Should said something else because it received less values and expected should say 3 and not 2, correct?

You probably don't understand _values_. a,b and x,y on the left side are not values. They are names. The 1,2,3 on the right side are values. Those are counted.

----------
nosy: +veky

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40202>
_______________________________________

From report at bugs.python.org  Thu Apr  9 16:26:21 2020
From: report at bugs.python.org (Eric Cousineau)
Date: Thu, 09 Apr 2020 20:26:21 +0000
Subject: [issue40240] Expose public spelling of _PyGC_FINALIZED and
 _PyGC_SET_FINALIZED?
In-Reply-To: <1586444432.56.0.946879588514.issue40240@roundup.psfhosted.org>
Message-ID: <1586463981.2.0.621416914688.issue40240@roundup.psfhosted.org>


Eric Cousineau <eric.cousineau at tri.global> added the comment:

> [...] but I am not sure it makes sense to allow to mark an object as finalized because that could mess with the GC algorithm.

Actually, I would like the opposite, to mark it unfinalized to resurrect the object more than once. PEP 442 from a ways back had this effect (per bpo-32377), and Antoine updated the docs after I filed the issue.

I didn't chime in early enough to snag the "more-than-once" functionality, so I guess this is what I get for dipping into private API without asking to make it public until 2 years later... d'oh!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40240>
_______________________________________

From report at bugs.python.org  Thu Apr  9 16:27:13 2020
From: report at bugs.python.org (Eric Cousineau)
Date: Thu, 09 Apr 2020 20:27:13 +0000
Subject: [issue40240] Expose public spelling of _PyGC_FINALIZED and
 _PyGC_SET_FINALIZED?
In-Reply-To: <1586444432.56.0.946879588514.issue40240@roundup.psfhosted.org>
Message-ID: <1586464033.56.0.226840400175.issue40240@roundup.psfhosted.org>


Eric Cousineau <eric.cousineau at tri.global> added the comment:

Er, to clarify: "PEP 442 had that effect" => "PEP 442 had the effect of making it resurrectable only once, but not more than that."

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40240>
_______________________________________

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: [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  Thu Apr  9 17:06:35 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 09 Apr 2020 21:06:35 +0000
Subject: [issue40240] Expose public spelling of _PyGC_FINALIZED and
 _PyGC_SET_FINALIZED?
In-Reply-To: <1586444432.56.0.946879588514.issue40240@roundup.psfhosted.org>
Message-ID: <1586466395.26.0.333274670924.issue40240@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

> Actually, I would like the opposite, to mark it unfinalized to resurrect the object more than once.

That is out of contract and goes against the guarantees on the GC and can (will) cause the finalizer of the object to be executed more than once. I don't think is a good idea to expose an API that allows breaking the guarantees that we give: every object is finalized once.

Also, taking into account that someone could mark externally objects as not finalized can make things more complicated for us to maintain in the collector.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40240>
_______________________________________

From report at bugs.python.org  Thu Apr  9 18:38:37 2020
From: report at bugs.python.org (Graham Dumpleton)
Date: Thu, 09 Apr 2020 22:38:37 +0000
Subject: [issue40234] Disallow daemon threads in subinterpreters optionally.
In-Reply-To: <1586387812.86.0.0296012569674.issue40234@roundup.psfhosted.org>
Message-ID: <1586471917.87.0.183581981457.issue40234@roundup.psfhosted.org>


Graham Dumpleton <Graham.Dumpleton at gmail.com> added the comment:

Just to make few things clear. It isn't mod_wsgi itself that relies on daemon threads, it is going to be users WSGI applications (or the things they need) that do.

As a concrete example of things that would stop working are monitoring systems such as New Relic, DataDog, Elastic APM etc. These all fire off a background thread to handle aggregation of data collected from the application, with that data then being sent off once a minute to the backend servers.

It isn't just these though. Over the years have see many instances of people using background threads to off load small tasks to be done in process rather than using full blown queuing system such as Celery etc. So I don't believe it is a rare use case. Monitoring systems are a big use case though.

These would all usually use a daemon thread so they can be started and effectively forgotten, with no need to do anything to shut them down when the process is exiting.

Some (such as New Relic, which I wrote so know how it works), will register an atexit callback in order to flush data out before a process stops, but it may not actually exit the thread. Even if it does exit the thread, you can't just switch it to use a non daemon thread as that will not work.

The problem here is that atexit callbacks are only called after the (sub)interpreter shutdown code has waited on non daemon threads. Thus there is no current standard way I know of to notify a non daemon thread to shutdown. The result would be that if these were switched to non daemon thread, the process would hang on shutdown at the point of waiting for non daemon threads.

So if you are going to eliminate daemon threads (even if only in sub interpreters at this point), you are going to have to introduce a way to register something similar to an atexit callback which would be invoked before waiting on non daemon threads, so an attempt can be made to notify them that they need to shutdown. Use of this mechanism is going to have to be added to any code out there currently using daemon threads if they are going to be forced to use non daemon threads. This includes stuff in the stdlib such as the multiprocessing thread pools. They can't just switch to non daemon threads, they have to add the capability to register and be notified of (sub)interpreter shutdown so they can exit the thread else process hangs will occur.

Now a few other things about history and usage of mod_wsgi to give context.

Once upon a time mod_wsgi did try and delete sub interpreters and replace them in the life of a process. This as you can probably imagine now was very buggy because of issues in CPython sub interpreter support. As a result mod_wsgi discarded that ability and so a sub interpreter always persisted and was used for the life of the process. That way problems with clean up of sub interpreters wasn't a big issue.

During cleanup of (sub)interpreters on process shutdown, although crashes could sometimes occur (usually quite rare), what usually happened was that a Python exception would occur. The reason for this would be in cleaning up a (sub)interpreter, sys.modules was cleared up with everything appearing to be set to None. You would therefore get a Python exception because some code trying to access a class instance found the instance replaced by None and so it failed. Even this was rare and not a big deal.

Now although a crash or Python exception could in rare cases occur, for mod_wsgi it didn't really matter since we were talking about sub process of the Apache master process, and the master process didn't care. If Apache was stopping anyway, it just stopped normally. If Apache was doing a restart and child process were told to stop because of that, or if a maximum request threshold was reach and so process was being recycled, then Apache was going to replace the process anyway, so everything just carried on normally and a new process started in its place.

In the case where a process lockup managed to occur on process shutdown, for example if non daemon thread were used explicitly, then process shutdown timeouts applied by mod_wsgi on daemon processes would kick in and the process would be force killed anyway. So all up it was quite resilient and kept working. If embedded mode of mod_wsgi was used, it would though lock up the Apache process indefinitely if something used non daemon threads explicitly.

On the issue of non daemon threads, usually these would never arise. This is because usually people don't explicitly say a thread is non daemon. Where nothing is done to say that, a thread actually inherits the mode of the thread it was created in. Since all request handler threads in mod_wsgi are actually externally created threads which call into Python, they get assigned the DummyThread object to track them. These are treated as non daemon threads. As a result any new threads created which don't explicitly say they are non daemon, get marked as daemon threads anyway. The consequence of this is that they never get waited upon on shutdown and everything works.

Anyway, going forward, if use of daemon threads is blocked in sub interpreters to satisfy the new envisioned use case for them, of using them to run sub tasks out of another interpreter, then first thing would be that mod_wsgi would deprecate use of sub interpreters, disabling them by default and requiring people to explicitly enable ability to use them. This would be just an interim measure in a transition period.

In a followup version mod_wsgi would then discard support for sub interpreters, as well as likely also disable embedded mode (except for specific case of Apache access control hooks, would mean Windows support would still be dropped though). Thus people would be forced to use daemon mode of mod_wsgi where separate processes are used to the Apache child processes to run a WSGI application. This is actually was mod_wsgi-express effectively enforces already. If separation were need for separate applications, or if a single application needed to be split, separate groups of daemon processes would be used with requests redirected to the appropriate instance in a daemon process group.

This use of daemon processes, recommendation to not use sub interpreters and use the main interpreter context has existed for many years due to many third party packages not working in sub interpreters anyway due to simplified GIL API restrictions. So this isn't new, it just hasn't been required and enforced (except in mod_wsgi-express). So these steps just force people in the direction which has been recommended for a long time.

As to the question of why disable/discard sub interpreter support in mod_wsgi, that comes down to support burden. This is not support burden in mod_wsgi, but the effort it will take to deal with all those people out there whose applications will stop working if run in sub interpreters were daemon thread usage prevented. I don't have time to be hand holding all these people and educate or help them to fix their applications or tell them how some third party package they use needs to be changed. Will be easier and less impact on me as the only person who supports mod_wsgi to discard sub interpreter support and document how people need to move to use of daemon mode and main interpreter as has been recommended for a long time anyway but which couldn't be made the default purely because of history of how mod_wsgi was developed and features added over time.

Now later on if someone decides to eliminate daemon threads for the main interpreter context, or changes stdlib so everything uses non daemon threads, then at that point I would stop supporting mod_wsgi in those Python versions. I just feel that is going to have a huge impact on user code at that point and create lots of problems so don't even want to go there. The impact of dropping daemon threads from the main interpreter will likely have affects way beyond mod_wsgi as well, so right now I can't see how you could even make that decision.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40234>
_______________________________________

From report at bugs.python.org  Thu Apr  9 19:41:06 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 09 Apr 2020 23:41:06 +0000
Subject: [issue40204] Docs build error with Sphinx 3.0 due to invalid C
 declaration
In-Reply-To: <1586183568.2.0.322929459864.issue40204@roundup.psfhosted.org>
Message-ID: <1586475666.38.0.814250437466.issue40204@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 9e5f159d3279a6b476d588010d529cfdbb8c8803 by Victor Stinner in branch '3.7':
bpo-40204: Pin Sphinx version to 1.8.2 in Doc/Makefile (GH-19442) (GH-19443)
https://github.com/python/cpython/commit/9e5f159d3279a6b476d588010d529cfdbb8c8803


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40204>
_______________________________________

From report at bugs.python.org  Thu Apr  9 20:03:27 2020
From: report at bugs.python.org (Ned Deily)
Date: Fri, 10 Apr 2020 00:03:27 +0000
Subject: [issue40204] Docs build error with Sphinx 3.0 due to invalid C
 declaration
In-Reply-To: <1586183568.2.0.322929459864.issue40204@roundup.psfhosted.org>
Message-ID: <1586477007.92.0.202602112943.issue40204@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

Why are we pinning to 1.8.2 when the official docs builds for all releases are currently using 2.3.1?  (see, for example, https://docs.python.org/3.8/ at bottom right corner)

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40204>
_______________________________________

From report at bugs.python.org  Thu Apr  9 20:06:57 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 10 Apr 2020 00:06:57 +0000
Subject: [issue40241] [C API] Make PyGC_Head structure opaque,
 or even more it to the internal C API
In-Reply-To: <1586445596.83.0.583225080007.issue40241@roundup.psfhosted.org>
Message-ID: <1586477217.84.0.636524531783.issue40241@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

The following macros rely on PyGC_Head:

* _PyGCHead_FINALIZED()
* _PyGCHead_NEXT()
* _PyGCHead_PREV()
* _PyGCHead_SET_FINALIZED()
* _PyGCHead_SET_NEXT()
* _PyGCHead_SET_PREV()
* _PyGC_FINALIZED()
* _PyGC_PREV_MASK
* _PyGC_PREV_MASK_COLLECTING
* _PyGC_PREV_MASK_FINALIZED
* _PyGC_PREV_SHIFT
* _PyGC_SET_FINALIZED()
* _PyObject_GC_IS_TRACKED()
* _PyObject_GC_MAY_BE_TRACKED()
* _Py_AS_GC()

_testcapi uses _PyObject_GC_IS_TRACKED() and sizeof(PyGC_Head).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40241>
_______________________________________

From report at bugs.python.org  Thu Apr  9 20:16:12 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 10 Apr 2020 00:16:12 +0000
Subject: [issue40241] [C API] Make PyGC_Head structure opaque,
 or even more it to the internal C API
In-Reply-To: <1586445596.83.0.583225080007.issue40241@roundup.psfhosted.org>
Message-ID: <1586477772.31.0.733172361553.issue40241@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
keywords: +patch
pull_requests: +18806
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19452

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40241>
_______________________________________

From report at bugs.python.org  Thu Apr  9 20:16:19 2020
From: report at bugs.python.org (Eric Cousineau)
Date: Fri, 10 Apr 2020 00:16:19 +0000
Subject: [issue40240] Expose public spelling of _PyGC_FINALIZED and
 _PyGC_SET_FINALIZED?
In-Reply-To: <1586444432.56.0.946879588514.issue40240@roundup.psfhosted.org>
Message-ID: <1586477779.89.0.509798896945.issue40240@roundup.psfhosted.org>


Eric Cousineau <eric.cousineau at tri.global> added the comment:

Aye. Using a workaround for now ("leak" the object by incrementing the refcount on first resurrection):
https://github.com/RobotLocomotion/pybind11/pull/39

I may try Antoine's suggestion later on, but will definitely reformulate this to use the public API version of `gc.is_finalized()` when it comes about.

Thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40240>
_______________________________________

From report at bugs.python.org  Thu Apr  9 20:18:59 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 10 Apr 2020 00:18:59 +0000
Subject: [issue40241] [C API] Make PyGC_Head structure opaque,
 or even more it to the internal C API
In-Reply-To: <1586445596.83.0.583225080007.issue40241@roundup.psfhosted.org>
Message-ID: <1586477939.23.0.270435463457.issue40241@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> The following macros rely on PyGC_Head: (...)

I already moved them to the internal C API in commit  1a6be91e6fd65ce9cb88cbbbb193db7e92ec6076 of bpo-35081.

But Stefan Behnel reported that it breaks Cython:

"Making _PyGC_FINALIZED() internal broke Cython (https://github.com/cython/cython/issues/2721). It's used in the finaliser implementation (https://github.com/cython/cython/blob/da657c8e326a419cde8ae6ea91be9661b9622504/Cython/Compiler/ModuleNode.py#L1442-L1456), to determine if an object for which tp_dealloc() is called has already been finalised or whether we have to do it. I'm not sure how to deal with this on our side now. Any clue?"

https://bugs.python.org/issue35081#msg330045

So I simply reverted (partially) this change: commit 3e21ad1a254cc33e8d4920ad7f026254ec728bee.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40241>
_______________________________________

From report at bugs.python.org  Thu Apr  9 20:23:41 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 10 Apr 2020 00:23:41 +0000
Subject: [issue40241] [C API] Make PyGC_Head structure opaque,
 or even more it to the internal C API
In-Reply-To: <1586445596.83.0.583225080007.issue40241@roundup.psfhosted.org>
Message-ID: <1586478221.73.0.0856454790294.issue40241@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

_testcapi uses _PyObject_GC_IS_TRACKED(). This macro is exposed in Python as gc.is_tracked(). IMO the function should be available in the public C API. For example, PyObject_GC_IsTracked(obj).

Cython uses _PyGC_FINALIZED(). This macro is exposed in Python as gc.is_finalized(). So again, I consider that it should be exposed in a public C function as well, like PyObject_GC_IsFinalized(obj).

----------
nosy: +pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40241>
_______________________________________

From report at bugs.python.org  Thu Apr  9 20:39:50 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 10 Apr 2020 00:39:50 +0000
Subject: [issue40204] Docs build error with Sphinx 3.0 due to invalid C
 declaration
In-Reply-To: <1586183568.2.0.322929459864.issue40204@roundup.psfhosted.org>
Message-ID: <1586479190.05.0.738911431003.issue40204@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> Why are we pinning to 1.8.2 when the official docs builds for all releases are currently using 2.3.1?  (see, for example, https://docs.python.org/3.8/ at bottom right corner)

First of all, to repair the CI :-) Before my change, it was no longer possible to merge any change in 3.8! (I didn't check for 3.7, but I expect that it wasn't possible neither).

Second, 1.8.2 version comes from the CI configuration:

$ grep -i sphinx== .travis.yml .azure-pipelines/* Doc/Makefile 
.travis.yml:        - python -m pip install sphinx==1.8.2 blurb
.azure-pipelines/docs-steps.yml:- script: python -m pip install sphinx==1.8.2 blurb python-docs-theme
Doc/Makefile:	$(VENVDIR)/bin/python3 -m pip install -U Sphinx==1.8.2 blurb

If Sphinx version is changed in Doc/Makefile, I would prefer to also update the version in the CI configuration.

I also vaguely recall discussions about issues with newer Sphinx. I don't recall if it was 2.0 or another version. Julien Palard may recall that better than me! Was it bpo-35472?

--

I don't really care of the Sphinx version, I only care about working CI and consistency between all pinned versions ;-)

--

By the way, maybe Doc/Makefile could use the latest Sphinx version by default, and the Python CI could use a pinned version. The problem is that the Sphinx version cannot be configured currently when running "make venv".

Oh, .travis.yml is differecen between 3.7 and 3.8.

3.8 and master use "make -C Doc/ PYTHON=../python venv".

3.7 doesn't use "make venv" but:

  before_script:
    - cd Doc
    # Sphinx is pinned so that new versions that introduce new warnings won't suddenly cause build failures.
    # (Updating the version is fine as long as no warnings are raised by doing so.)
    - python -m pip install sphinx==1.8.2 blurb
  script:
    - make check suspicious html SPHINXOPTS="-q -W -j4"


Maybe 3.7 should mimick what is done in 3.8 and master to ease maintenance. I don't know.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40204>
_______________________________________

From report at bugs.python.org  Thu Apr  9 20:42:10 2020
From: report at bugs.python.org (Kyle Stanley)
Date: Fri, 10 Apr 2020 00:42:10 +0000
Subject: [issue39207] concurrent.futures.ProcessPoolExecutor does not properly
 reap jobs and spawns too many workers
In-Reply-To: <1578087844.56.0.81762061225.issue39207@roundup.psfhosted.org>
Message-ID: <1586479330.31.0.607631140211.issue39207@roundup.psfhosted.org>


Change by Kyle Stanley <aeros167 at gmail.com>:


----------
keywords: +patch
pull_requests: +18807
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/19453

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39207>
_______________________________________

From report at bugs.python.org  Thu Apr  9 20:48:05 2020
From: report at bugs.python.org (Ned Deily)
Date: Fri, 10 Apr 2020 00:48:05 +0000
Subject: [issue40204] Docs build error with Sphinx 3.0 due to invalid C
 declaration
In-Reply-To: <1586183568.2.0.322929459864.issue40204@roundup.psfhosted.org>
Message-ID: <1586479685.17.0.52495404871.issue40204@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

I agree that it should be easier to keep them all in sync.  But my point is that the on-going official doc builds (some multi[ple times per day) for all of the active versions (2.7 and 3.6 through 3.9) are using 2.3.1 so we should be doing CI against that version as well.  The docs builds are configured in https://github.com/python/docsbuild-scripts.  So whenever requirements.in is update there, the CI versions should be updated as well. Even better would be someway to auto sync them.

Julien, any ideas on this?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40204>
_______________________________________

From report at bugs.python.org  Thu Apr  9 21:05:45 2020
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 10 Apr 2020 01:05:45 +0000
Subject: [issue39943] Meta: Clean up various issues in C internals
In-Reply-To: <1583983387.49.0.277830283994.issue39943@roundup.psfhosted.org>
Message-ID: <1586480745.17.0.298746804091.issue39943@roundup.psfhosted.org>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset 38ada3bac8205a7690d573d715b0e84e60297c4c by Andy Lester in branch 'master':
bpo-39943: Keep constness of pointer objects. (19405)
https://github.com/python/cpython/commit/38ada3bac8205a7690d573d715b0e84e60297c4c


----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39943>
_______________________________________

From report at bugs.python.org  Thu Apr  9 22:06:18 2020
From: report at bugs.python.org (Sahurkhan)
Date: Fri, 10 Apr 2020 02:06:18 +0000
Subject: [issue39598] ERR_CACHE_MISS
In-Reply-To: <1581337438.53.0.0366477237465.issue39598@roundup.psfhosted.org>
Message-ID: <1586484378.04.0.94797935569.issue39598@roundup.psfhosted.org>


Sahurkhan <mail.dendy13 at gmail.com> added the comment:

Solved, check here https://pcheckup.com/

----------
nosy: +Sahurkhan

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39598>
_______________________________________

From report at bugs.python.org  Thu Apr  9 22:47:53 2020
From: report at bugs.python.org (zhanying)
Date: Fri, 10 Apr 2020 02:47:53 +0000
Subject: [issue40236] datetime.datetime.strptime get day error
In-Reply-To: <1586436351.53.0.765877217301.issue40236@roundup.psfhosted.org>
Message-ID: <25377f97.227e.17161fc74ce.Coremail.python82@126.com>


zhanying <python82 at 126.com> added the comment:

My platform is this.

#python
Python 3.6.9 |Anaconda, Inc.| (default, Jul 30 2019, 19:07:31)
[GCC 7.3.0] on linux

Type "help", "copyright", "credits" or "license" for more information.

At 2020-04-09 20:45:51, "Eric V. Smith" <report at bugs.python.org> wrote:
>
>Eric V. Smith <eric at trueblade.com> added the comment:
>
>Can you tell us what platform you're on? Also, please include the header that's printed out when you run python from the command line. For example, mine shows:
>
>$ python3
>Python 3.7.6 (default, Jan 30 2020, 10:29:04) 
>[GCC 9.2.1 20190827 (Red Hat 9.2.1-1)] on linux
>
>----------
>components: +Library (Lib)
>nosy: +eric.smith
>
>_______________________________________
>Python tracker <report at bugs.python.org>
><https://bugs.python.org/issue40236>
>_______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40236>
_______________________________________

From report at bugs.python.org  Thu Apr  9 23:05:38 2020
From: report at bugs.python.org (zhanying)
Date: Fri, 10 Apr 2020 03:05:38 +0000
Subject: [issue40236] datetime.datetime.strptime get day error
In-Reply-To: <1586436351.53.0.765877217301.issue40236@roundup.psfhosted.org>
Message-ID: <2699b179.26b5.171620cb9b1.Coremail.python82@126.com>


zhanying <python82 at 126.com> added the comment:

i read the source code, in this part

def _calc_julian_from_U_or_W(year, week_of_year, day_of_week, week_starts_Mon):
"""Calculate the Julian day based on the year, week of the year, and day of
    the week, with week_start_day representing whether the week of the year
    assumes the week starts on Sunday or Monday (6 or 0)."""
first_weekday = datetime_date(year, 1, 1).weekday()
# If we are dealing with the %U directive (week starts on Sunday), it's
    # easier to just shift the view to Sunday being the first day of the
    # week.
if not week_starts_Mon:
        first_weekday = (first_weekday + 1) % 7
day_of_week = (day_of_week + 1) % 7
# Need to watch out for a week 0 (when the first day of the year is not
    # the same as that specified by %U or %W).
week_0_length = (7 - first_weekday) % 7
if week_of_year == 0:
return 1 + day_of_week - first_weekday
else:
        days_to_week = week_0_length + (7 * (week_of_year - 1))
return 1 + days_to_week + day_of_week

when first_weekday is 0, that year start with Monday, week_of_year equar 0 or 1, this func return same value

At 2020-04-09 20:45:51, "Eric V. Smith" <report at bugs.python.org> wrote:
>
>Eric V. Smith <eric at trueblade.com> added the comment:
>
>Can you tell us what platform you're on? Also, please include the header that's printed out when you run python from the command line. For example, mine shows:
>
>$ python3
>Python 3.7.6 (default, Jan 30 2020, 10:29:04) 
>[GCC 9.2.1 20190827 (Red Hat 9.2.1-1)] on linux
>
>----------
>components: +Library (Lib)
>nosy: +eric.smith
>
>_______________________________________
>Python tracker <report at bugs.python.org>
><https://bugs.python.org/issue40236>
>_______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40236>
_______________________________________

From report at bugs.python.org  Thu Apr  9 23:42:17 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 10 Apr 2020 03:42:17 +0000
Subject: [issue40230] Itertools.product() Out of Memory Errors
In-Reply-To: <1586376726.21.0.0873613535989.issue40230@roundup.psfhosted.org>
Message-ID: <1586490137.86.0.255772737983.issue40230@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee:  -> rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40230>
_______________________________________

From report at bugs.python.org  Fri Apr 10 00:05:01 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 10 Apr 2020 04:05:01 +0000
Subject: [issue39481] Implement PEP 585 (Type Hinting Generics In Standard
 Collections)
In-Reply-To: <1580231817.93.0.47144630055.issue39481@roundup.psfhosted.org>
Message-ID: <1586491501.52.0.841733105517.issue39481@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:


New changeset 2fa67df605e4b0803e7e3aac0b85d851b4b4e09a by Batuhan Ta?kaya in branch 'master':
bpo-39481: PEP 585 for ipaddress.py (GH-19418)
https://github.com/python/cpython/commit/2fa67df605e4b0803e7e3aac0b85d851b4b4e09a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39481>
_______________________________________

From report at bugs.python.org  Fri Apr 10 00:10:15 2020
From: report at bugs.python.org (Henry Carscadden)
Date: Fri, 10 Apr 2020 04:10:15 +0000
Subject: [issue40230] Itertools.product() Out of Memory Errors
In-Reply-To: <1586376726.21.0.0873613535989.issue40230@roundup.psfhosted.org>
Message-ID: <1586491815.75.0.176154052275.issue40230@roundup.psfhosted.org>


Henry Carscadden <hlc5v at virginia.edu> added the comment:

Hey, Tim, I just wanted a note of clarification. I was working on an approximation algorithm for a network science tool that is being released soon. Initially, I relied on itertools.product(), but when I moved to testing on non-trivial graphs, I immediately had Out of Memory Errors. This was even on the nodes with large memories on the computing cluster that I was using. The issue is a lot of extra lists are added as the number of iterables passed product grows although the actual number of elements in the iterables is relatively small. 
Here is the workaround that I used to handle many arguments:

def product(*args) -> Iterable:
    '''
    Takes in several iterables and returns a generator
    that yields the cartesian product of the elements in the iterables
    :param args: sets which you would like the cartesian product of
    :return: generator
    '''
    if len(args) == 1 and type(args) == list:
        return args
    numArgs = len(args)
    indices = np.zeros(numArgs, dtype=np.uint)
    checkLen = len(args[0])
    while indices[0] < checkLen:
        curr_term = [args[0][indices[0]]]
        for i in range(1, numArgs):
            curr_term.append(args[i][indices[i]])
        indices[-1] += np.uint(1)
        for i in range(1, numArgs):
            updated = False
            if indices[-i] >= len(args[-i]):
                indices[-i] = np.uint(0)
                indices[-i - 1] += np.uint(1)
                updated = True
            if not updated:
                break
        yield curr_term

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40230>
_______________________________________

From report at bugs.python.org  Fri Apr 10 00:22:12 2020
From: report at bugs.python.org (ppperry)
Date: Fri, 10 Apr 2020 04:22:12 +0000
Subject: [issue40241] [C API] Make PyGC_Head structure opaque,
 or even move it to the internal C API
In-Reply-To: <1586445596.83.0.583225080007.issue40241@roundup.psfhosted.org>
Message-ID: <1586492532.56.0.911933786352.issue40241@roundup.psfhosted.org>


Change by ppperry <mapreader at olum.org>:


----------
title: [C API] Make PyGC_Head structure opaque, or even more it to the internal C API -> [C API] Make PyGC_Head structure opaque, or even move it to the internal C API

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40241>
_______________________________________

From report at bugs.python.org  Fri Apr 10 00:25:59 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 10 Apr 2020 04:25:59 +0000
Subject: [issue39481] Implement PEP 585 (Type Hinting Generics In Standard
 Collections)
In-Reply-To: <1580231817.93.0.47144630055.issue39481@roundup.psfhosted.org>
Message-ID: <1586492759.77.0.235523484341.issue39481@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:


New changeset 7c4185d62d4aec486d82c3ad02acd878db2d3537 by Ethan Smith in branch 'master':
bpo-39481: PEP 585 for enumerate, AsyncGeneratorType, mmap (GH-19421)
https://github.com/python/cpython/commit/7c4185d62d4aec486d82c3ad02acd878db2d3537


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39481>
_______________________________________

From report at bugs.python.org  Fri Apr 10 00:34:18 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 10 Apr 2020 04:34:18 +0000
Subject: [issue39481] Implement PEP 585 (Type Hinting Generics In Standard
 Collections)
In-Reply-To: <1580231817.93.0.47144630055.issue39481@roundup.psfhosted.org>
Message-ID: <1586493258.18.0.963644976405.issue39481@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

At this speed I can merge about 3 PRs per hour. I'll be back tomorrow.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39481>
_______________________________________

From report at bugs.python.org  Fri Apr 10 00:47:38 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 10 Apr 2020 04:47:38 +0000
Subject: [issue39481] Implement PEP 585 (Type Hinting Generics In Standard
 Collections)
In-Reply-To: <1580231817.93.0.47144630055.issue39481@roundup.psfhosted.org>
Message-ID: <1586494058.05.0.576847869772.issue39481@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:


New changeset e3ec44d692d9442e640cf5b2d8708157a65cec3e by Ethan Smith in branch 'master':
bpo-39481: PEP 585 for difflib, filecmp, fileinput (#19422)
https://github.com/python/cpython/commit/e3ec44d692d9442e640cf5b2d8708157a65cec3e


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39481>
_______________________________________

From report at bugs.python.org  Fri Apr 10 00:51:44 2020
From: report at bugs.python.org (Tim Peters)
Date: Fri, 10 Apr 2020 04:51:44 +0000
Subject: [issue40230] Itertools.product() Out of Memory Errors
In-Reply-To: <1586376726.21.0.0873613535989.issue40230@roundup.psfhosted.org>
Message-ID: <1586494304.62.0.39700204379.issue40230@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

Henry, I have to ask again:  please give at least one specific, concrete example of the behavior you're objecting to.  English isn't helping, and I still have no idea what your complaint is.

What I'm looking for:

    for i in itertools.product(???):
        pass
 
where you replace the ??? with executable code (preferably not using numpy or any other extension package) that provokes the MemoryError you're talking about.

For example, here I'm constructing a case with a million arguments.  There's no problem at all:

>>> import itertools
>>> args = [range(100) for i in range(1_000_000)]
>>> for i in itertools.product(*args):
...     print(len(i))
[and it prints 1000000 over & over until I get bored and kill it]

Note if it _did_ provoke a problem, we probably wouldn't care - there are no plausible realistic use cases for passing a million arguments to product().

You haven't given us a way to reproduce your complaint, or even a clue as to the number of arguments you're talking about.  The above code was my best guess as to what you _might_ be talking about.  But since there's no MemoryError in sight, apparently not.

I'm suspecting this may be an XY problem[1], and especially because you posted "a solution" instead of an actual problem ;-)

[1] https://meta.stackexchange.com/questions/66377/what-is-the-xy-problem

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40230>
_______________________________________

From report at bugs.python.org  Fri Apr 10 01:08:53 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 10 Apr 2020 05:08:53 +0000
Subject: [issue39481] Implement PEP 585 (Type Hinting Generics In Standard
 Collections)
In-Reply-To: <1580231817.93.0.47144630055.issue39481@roundup.psfhosted.org>
Message-ID: <1586495333.35.0.593965805236.issue39481@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

How are ipaddress and mmap generic?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39481>
_______________________________________

From report at bugs.python.org  Fri Apr 10 01:10:20 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 10 Apr 2020 05:10:20 +0000
Subject: [issue39481] Implement PEP 585 (Type Hinting Generics In Standard
 Collections)
In-Reply-To: <1580231817.93.0.47144630055.issue39481@roundup.psfhosted.org>
Message-ID: <1586495420.63.0.743495789701.issue39481@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

Check typeshed

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39481>
_______________________________________

From report at bugs.python.org  Fri Apr 10 02:27:09 2020
From: report at bugs.python.org (Rohit Gupta)
Date: Fri, 10 Apr 2020 06:27:09 +0000
Subject: [issue40242] zmq mysql core dump
In-Reply-To: <1586455195.03.0.155128936869.issue40242@roundup.psfhosted.org>
Message-ID: <1586500029.48.0.971475976771.issue40242@roundup.psfhosted.org>


Rohit Gupta <rohit_gupta at amperehourenergy.com> added the comment:

For the time being, changing the order of import is solving the problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40242>
_______________________________________

From report at bugs.python.org  Fri Apr 10 02:37:44 2020
From: report at bugs.python.org (SilentGhost)
Date: Fri, 10 Apr 2020 06:37:44 +0000
Subject: [issue39598] ERR_CACHE_MISS
In-Reply-To: <1581337438.53.0.0366477237465.issue39598@roundup.psfhosted.org>
Message-ID: <1586500664.27.0.661018996104.issue39598@roundup.psfhosted.org>


Change by SilentGhost <ghost.adh at runbox.com>:


----------
Removed message: https://bugs.python.org/msg362378

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39598>
_______________________________________

From report at bugs.python.org  Fri Apr 10 02:37:52 2020
From: report at bugs.python.org (SilentGhost)
Date: Fri, 10 Apr 2020 06:37:52 +0000
Subject: [issue39598] ERR_CACHE_MISS
In-Reply-To: <1581337438.53.0.0366477237465.issue39598@roundup.psfhosted.org>
Message-ID: <1586500672.19.0.259641986947.issue39598@roundup.psfhosted.org>


Change by SilentGhost <ghost.adh at runbox.com>:


----------
Removed message: https://bugs.python.org/msg366099

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39598>
_______________________________________

From report at bugs.python.org  Fri Apr 10 02:38:01 2020
From: report at bugs.python.org (SilentGhost)
Date: Fri, 10 Apr 2020 06:38:01 +0000
Subject: [issue39598] ERR_CACHE_MISS
In-Reply-To: <1581337438.53.0.0366477237465.issue39598@roundup.psfhosted.org>
Message-ID: <1586500681.43.0.516012813071.issue39598@roundup.psfhosted.org>


Change by SilentGhost <ghost.adh at runbox.com>:


----------
Removed message: https://bugs.python.org/msg361686

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39598>
_______________________________________

From report at bugs.python.org  Fri Apr 10 02:45:11 2020
From: report at bugs.python.org (SilentGhost)
Date: Fri, 10 Apr 2020 06:45:11 +0000
Subject: [issue36199] libzmq.dll causes uncontrollable screen flickering when
 accessing windows 2012 R2 server through remote desktop
In-Reply-To: <1551804211.97.0.598936212645.issue36199@roundup.psfhosted.org>
Message-ID: <1586501111.73.0.974578313767.issue36199@roundup.psfhosted.org>


Change by SilentGhost <ghost.adh at runbox.com>:


----------
Removed message: https://bugs.python.org/msg361403

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36199>
_______________________________________

From report at bugs.python.org  Fri Apr 10 02:46:10 2020
From: report at bugs.python.org (SilentGhost)
Date: Fri, 10 Apr 2020 06:46:10 +0000
Subject: [issue32545] Unable to install Python 3.7.0a4 on Windows 10 - Error
 0x80070643: Failed to install MSI package.
In-Reply-To: <1515875653.34.0.467229070634.issue32545@psf.upfronthosting.co.za>
Message-ID: <1586501170.02.0.843403771713.issue32545@roundup.psfhosted.org>


Change by SilentGhost <ghost.adh at runbox.com>:


----------
Removed message: https://bugs.python.org/msg356223

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32545>
_______________________________________

From report at bugs.python.org  Fri Apr 10 04:13:46 2020
From: report at bugs.python.org (gaborbernat)
Date: Fri, 10 Apr 2020 08:13:46 +0000
Subject: [issue40238] os.stat() on Windows succeeds for nonexistent paths with
 trailing spaces
In-Reply-To: <1586442330.4.0.896715206677.issue40238@roundup.psfhosted.org>
Message-ID: <1586506426.97.0.564101851968.issue40238@roundup.psfhosted.org>


gaborbernat <gaborjbernat at gmail.com> added the comment:

While I agree that Windows is safe to transform paths as he wishes to, the bug reported here is that os.stat/os.path.isdir behaves differently than os.scandir. Can we make them behave the same?

----------
nosy: +gaborbernat

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40238>
_______________________________________

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: [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 04:37:26 2020
From: report at bugs.python.org (slow franklin)
Date: Fri, 10 Apr 2020 08:37:26 +0000
Subject: [issue39533] Use `statx(2)` system call on Linux for extended
 `os.stat` information
In-Reply-To: <1580703962.85.0.294314145935.issue39533@roundup.psfhosted.org>
Message-ID: <1586507846.7.0.330560903653.issue39533@roundup.psfhosted.org>


Change by slow franklin <sloowfranklin at gmail.com>:


----------
nosy: +slow franklin

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39533>
_______________________________________

From report at bugs.python.org  Fri Apr 10 06:27:12 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 10 Apr 2020 10:27:12 +0000
Subject: [issue40230] Itertools.product() Out of Memory Errors
In-Reply-To: <1586376726.21.0.0873613535989.issue40230@roundup.psfhosted.org>
Message-ID: <1586514432.88.0.224518537639.issue40230@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> when I moved to testing on non-trivial graphs, I immediately had 
> Out of Memory Errors.

I'm going to hazard a guess that the input to product() was a graph traversal iterator that got trapped in an undetected cycle.  Feeding an infinite iterator into product() would eat all available memory, just as it would with list().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40230>
_______________________________________

From report at bugs.python.org  Fri Apr 10 06:35:11 2020
From: report at bugs.python.org (Michael Felt)
Date: Fri, 10 Apr 2020 10:35:11 +0000
Subject: [issue40244] AIX: build: _PyObject_GC_TRACK Asstertion failure
In-Reply-To: <1586507316.69.0.786578254213.issue40244@roundup.psfhosted.org>
Message-ID: <1586514911.36.0.258009050681.issue40244@roundup.psfhosted.org>


Michael Felt <aixtools at felt.demon.nl> added the comment:

dbx output:

Again: help appreciated.

(dbx) run  -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     : 20014188
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 in pthread_kill at 0xd057a02c ($t1)
0xd057a02c (pthread_kill+0xac) 80410014            lwz   r2,0x14(r1)
(dbx) where
pthread_kill(??, ??) at 0xd057a02c
_p_raise(??) at 0xd0579408
raise.raise(??) at 0xd0123344
abort() at 0xd0189918
IPRA.$fatal_error(stream = 0x2006e370, header = 805397344, prefix = (nil), msg = (nil), status = 0), line 2183 in "pylifecycle.c"
_Py_FatalErrorFunc(func = "", msg = "\n"), line 2283 in "pylifecycle.c"
_PyObject_AssertFailed(obj = 0x30086038, expr = "", msg = (nil), file = "\177\200", line = 537322352, function = ""), line 2195 in "object.c"
gen_dealloc(gen = 0x2004af44), line 65532 in "pycore_object.h"
_Py_Dealloc(op = 0x00000013), line 2206 in "object.c"
unnamed block in _PyEval_EvalFrameDefault(tstate = 0x2006e370, f = 0x30023b0c, throwflag = 804397120), line 1046 in "object.h"
_PyEval_EvalFrameDefault(tstate = 0x2006e370, f = 0x30023b0c, throwflag = 804397120), line 1046 in "object.h"
unnamed block in IPRA.$function_code_fastcall(tstate = 0x2004af44, co = 0x20030848, args = 0x30066f7c, nargs = 805735610, globals = 0x30068cb8), line 40 in "pycore_ceval.h"
IPRA.$function_code_fastcall(tstate = 0x2004af44, co = 0x20030848, args = 0x30066f7c, nargs = 805735610, globals = 0x30068cb8), line 40 in "pycore_ceval.h"
_PyFunction_Vectorcall(func = 0x00000006, stack = 0x30083898, nargsf = 804397328, kwnames = 0x3006e110), line 366 in "call.c"
unnamed block in _PyEval_EvalFrameDefault(tstate = 0x2004af44, f = 0xffffffe2, throwflag = 804397584), line 739 in "abstract.h"
_PyEval_EvalFrameDefault(tstate = 0x2004af44, f = 0xffffffe2, throwflag = 804397584), line 739 in "abstract.h"
unnamed block in IPRA.$function_code_fastcall(tstate = 0x2004af44, co = 0x20030848, args = 0x30023b14, nargs = 805682254, globals = 0x3005bc38), line 40 in "pycore_ceval.h"
IPRA.$function_code_fastcall(tstate = 0x2004af44, co = 0x20030848, args = 0x30023b14, nargs = 805682254, globals = 0x3005bc38), line 40 in "pycore_ceval.h"
_PyFunction_Vectorcall(func = 0x00000005, stack = 0x3005da78, nargsf = 804397856, kwnames = 0xdeadbeef), line 366 in "call.c"
unnamed block in _PyEval_EvalFrameDefault(tstate = 0x100fbeb8, f = 0x2006e370, throwflag = 804398128), line 739 in "abstract.h"
_PyEval_EvalFrameDefault(tstate = 0x100fbeb8, f = 0x2006e370, throwflag = 804398128), line 739 in "abstract.h"
unnamed block in IPRA.$function_code_fastcall(tstate = 0x10073f50, co = 0x2000a350, args = 0x20011a58, nargs = 537167132, globals = 0x30049118), line 40 in "pycore_ceval.h"
IPRA.$function_code_fastcall(tstate = 0x10073f50, co = 0x2000a350, args = 0x20011a58, nargs = 537167132, globals = 0x30049118), line 40 in "pycore_ceval.h"
_PyFunction_Vectorcall(func = 0xd98069bf, stack = 0x00000008, nargsf = 4029698048, kwnames = 0x2006e370), line 366 in "call.c"
IPRA.$_PyObject_CallFunctionVa(tstate = 0x100f6cb0, callable = (nil), format = "/\362%\340-zj\244^P^O\242\234/\362&\340^\220K\250 ^D\205^\^PCl\243/\362&\340", va = "", is_size_t = 272852043), line 62 in "abstract.h"
IPRA.$callmethod(tstate = 0x100fa29c, callable = 0x2ff226e0, format = (invalid char ptr (0x5e904ba8)), va = "", is_size_t = 272854179), line 614 in "call.c"
PyObject_CallMethod(obj = 0x102c266c, name = "", format = "", ... = 0x20077748, 0xffff, 0x20077748, 0x20, 0x10), line 634 in "call.c"
init_importlib_external(tstate = 0xdeadbeef), line 209 in "pylifecycle.c"
IPRA.$init_interp_main(tstate = 0x00000001), line 993 in "pylifecycle.c"
pyinit_main(tstate = 0x2003c984), line 1097 in "pylifecycle.c"
Py_InitializeFromConfig(config = 0xf078b380), line 1141 in "pylifecycle.c"
pymain_init(args = 0x00000001), line 66 in "main.c"
pymain_main(args = 0x00000003), line 653 in "main.c"
Py_BytesMain(argc = -559038737, argv = 0xdeadbeef), line 686 in "main.c"
python.main(argc = 0, argv = (nil)), line 16 in "python.c"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40244>
_______________________________________

From report at bugs.python.org  Fri Apr 10 06:46:53 2020
From: report at bugs.python.org (pavlix)
Date: Fri, 10 Apr 2020 10:46:53 +0000
Subject: [issue20074] open() of read-write non-seekable streams broken
In-Reply-To: <1388088109.09.0.0894725958863.issue20074@psf.upfronthosting.co.za>
Message-ID: <1586515613.08.0.61939231686.issue20074@roundup.psfhosted.org>


pavlix <pavlix at pavlix.net> added the comment:

> A non-seekable read/write stream doesn't really make sense (think about
it).

How does it help the issue to ask the reporter to "think" when the have already provided an easily reproducable use case?

> What purpose does that constraint serve? Is there any reason it shouldn't be relaxed?

Can we *please* get an answer to this question? 

> Antoine already answered that question: it does not make sense to have a single stream that is open for *update* if it is not seekable.

How does this statement, already refuted by the reporter, bring us any closer to the answer to the question above?

Was this an arbitrary decision of someone who didn't think about character devices? Or is there any particular reason to prevent the use of "r+", "w+", "rb+" and "wb+" with readable-writable character devices?

----------
nosy: +pavlix

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20074>
_______________________________________

From report at bugs.python.org  Fri Apr 10 06:58:09 2020
From: report at bugs.python.org (Bas Nijholt)
Date: Fri, 10 Apr 2020 10:58:09 +0000
Subject: [issue36281] OSError: handle is closed for ProcessPoolExecutor and
 run_in_executor
In-Reply-To: <1552498582.24.0.716871849164.issue36281@roundup.psfhosted.org>
Message-ID: <1586516289.91.0.119336557864.issue36281@roundup.psfhosted.org>


Bas Nijholt <basnijholt at gmail.com> added the comment:

Using `git bisect` I've discovered the commit (b713adf27a) (https://github.com/python/cpython/commit/b713adf27a) that broke the code.

I've used one script:
```test.py
import sys
sys.path.append("/Users/basnijholt/Downloads/cpython/Lib/concurrent/futures/")
from random import random
from process import ProcessPoolExecutor
import asyncio

ioloop = asyncio.get_event_loop()

async def func(ioloop, executor):
    result = await ioloop.run_in_executor(executor, random)
    executor.shutdown(wait=False)  # bug doesn't occur when `wait=True`

if __name__ == "__main__":
    executor = ProcessPoolExecutor()
    task = ioloop.run_until_complete(func(ioloop, executor))
```
and `test2.py`
```
import pexpect
import sys

child = pexpect.spawn("python /Users/basnijholt/Downloads/cpython/test.py")
try:
    child.expect(["OSError", "AssertionError"], timeout=1)
    raise Exception
except pexpect.EOF as e:
    sys.exit(0)
```

Then did
```
git checkout master
git reset --hard 9b6c60cbce  # bad commit
git bisect start
git bisect bad
git bisect good ad2c2d380e  # good commit
git bisect run python test2.py
```

I will see if I can fix it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36281>
_______________________________________

From report at bugs.python.org  Fri Apr 10 07:03:43 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 10 Apr 2020 11:03:43 +0000
Subject: [issue38501] multiprocessing.Pool hangs atexit (and garbage
 collection sometimes)
In-Reply-To: <1571250674.69.0.928369483471.issue38501@roundup.psfhosted.org>
Message-ID: <1586516623.4.0.856096148753.issue38501@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
keywords: +patch
nosy: +pablogsal
nosy_count: 6.0 -> 7.0
pull_requests: +18808
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/11488

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38501>
_______________________________________

From report at bugs.python.org  Fri Apr 10 07:37:56 2020
From: report at bugs.python.org (pavlix)
Date: Fri, 10 Apr 2020 11:37:56 +0000
Subject: [issue20074] open() of read-write non-seekable streams broken
In-Reply-To: <1388088109.09.0.0894725958863.issue20074@psf.upfronthosting.co.za>
Message-ID: <1586518676.07.0.99745318358.issue20074@roundup.psfhosted.org>


pavlix <pavlix at pavlix.net> added the comment:

Okay, let me help the situation a bit. The ?workaround? of using `buffering=0` works perfect with `rb+` and `wb+` and I'm pretty sure I used this in the past. I don't know how well this is documented.

I would usually need to disable buffering for any real-time binary communication anyway, so for me the workaround is reasonable. As for buffered I/O and `r+`/`b+` where you cannot disable buffering, I don't know.

It would be useful to have a good reason behind the limitation of Python and have it documented, or have the limitation lifted if there's none, so this issue can be closed.

Could anyone please explain why binary streams default to buffered I/O in the first place? Does it make any sense or it's just historical cruft?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20074>
_______________________________________

From report at bugs.python.org  Fri Apr 10 07:45:06 2020
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 10 Apr 2020 11:45:06 +0000
Subject: [issue40244] AIX: build: _PyObject_GC_TRACK Asstertion failure
In-Reply-To: <1586507316.69.0.786578254213.issue40244@roundup.psfhosted.org>
Message-ID: <1586519106.49.0.991707077297.issue40244@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:

Since I just had a similar incident with the Intel compiler, I just
want to point out that compiling CPython still requires -fwrapv.

I've mentioned this before in AIX issues, and no one has pointed
out the corresponding xlc flag.


https://gcc.gnu.org/legacy-ml/gcc/2007-01/msg00062.html

"Dan Berlin says that xlc assumes signed overflow never occurs"

----------
nosy: +skrah

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40244>
_______________________________________

From report at bugs.python.org  Fri Apr 10 08:01:00 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 10 Apr 2020 12:01:00 +0000
Subject: [issue40244] AIX: build: _PyObject_GC_TRACK Asstertion failure
In-Reply-To: <1586507316.69.0.786578254213.issue40244@roundup.psfhosted.org>
Message-ID: <1586520060.04.0.792331001042.issue40244@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

The assertion failure occurs in _PyObject_GC_TRACK() at:

static void
gen_dealloc(PyGenObject *gen)
{
    PyObject *self = (PyObject *) gen;

    _PyObject_GC_UNTRACK(gen);

    if (gen->gi_weakreflist != NULL)
        PyObject_ClearWeakRefs(self);

    _PyObject_GC_TRACK(self);  // <==== HERE

    ...
}

It's surprising that the generator is still tracked by the GC after _PyObject_GC_UNTRACK().


> Calling this a compile error - as it seems to be compiler dependent.

Do you reproduce the bug if you build Python with GCC?

Which ./configure command did you use? What are the compiler and linker flags?

You can try:

./python -m test.pythoninfo|grep -E 'CFLAGS|CC|OPT|LDFLAGS'

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40244>
_______________________________________

From report at bugs.python.org  Fri Apr 10 08:06:33 2020
From: report at bugs.python.org (Eryk Sun)
Date: Fri, 10 Apr 2020 12:06:33 +0000
Subject: [issue40238] os.stat() on Windows succeeds for nonexistent paths with
 trailing spaces
In-Reply-To: <1586442330.4.0.896715206677.issue40238@roundup.psfhosted.org>
Message-ID: <1586520393.38.0.918211518701.issue40238@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> While I agree that Windows is safe to transform paths as he wishes to, 
> the bug reported here is that os.stat/os.path.isdir behaves 
> differently than os.scandir. Can we make them behave the same?

os.listdir and os.scandir can be modified to behave like os.stat, but not the other way around. They differ because a "*.*" wildcard component is appended to the path that's passed to FindFirstFileW, and trailing spaces and dots only get stripped in the final path component. 

To implement this without hard-coding Windows filename rules, the path needs to be normalized via WINAPI GetFullPathNameW before appending the "*.*" component (or just "*"; the ".*" is superfluous) -- but only for normal paths, i.e. paths that do not begin with exactly "\\\\?\\". The functions that would need to be updated are _listdir_windows_no_opendir and os_scandir_impl in Modules/posixmodule.c.

Another option would be to rewrite listdir and scandir to use CreateFileW and GetFileInformationByHandleEx: FileIdBothDirectoryInfo [1]. This query provides two additional fields in comparison to the classic find data: ChangeTime (Unix st_ctime) and FileId (Unix st_ino). If the file is flagged as a reparse point in its attributes, then the reparse tag is set in the EaSize field of the directory info, since extended attributes can't be set on a reparse point; see [MS-FSCC] 2.4.17 [2].

[1]: https://docs.microsoft.com/en-us/windows/win32/api/winbase/ns-winbase-file_id_both_dir_info
[2]: https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-fscc/1e144bff-c056-45aa-bd29-c13d214ee2ba

----------
resolution: not a bug -> 
stage: resolved -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40238>
_______________________________________

From report at bugs.python.org  Fri Apr 10 08:59:27 2020
From: report at bugs.python.org (Michael Felt)
Date: Fri, 10 Apr 2020 12:59:27 +0000
Subject: [issue40244] AIX: build: _PyObject_GC_TRACK Asstertion failure
In-Reply-To: <1586507316.69.0.786578254213.issue40244@roundup.psfhosted.org>
Message-ID: <1586523567.25.0.276361783094.issue40244@roundup.psfhosted.org>


Michael Felt <aixtools at felt.demon.nl> added the comment:

After git bisect - comes down to:

Bisecting: 0 revisions left to test after this (roughly 0 steps)
[0003c2dc1d4cf5b122e73e83177fd274fa9a9913] bpo-40096: Support __attribute__((__noreturn__)) on xlc (GH-19204)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40244>
_______________________________________

From report at bugs.python.org  Fri Apr 10 09:04:02 2020
From: report at bugs.python.org (Michael Felt)
Date: Fri, 10 Apr 2020 13:04:02 +0000
Subject: [issue40244] AIX: build: _PyObject_GC_TRACK Asstertion failure
In-Reply-To: <1586507316.69.0.786578254213.issue40244@roundup.psfhosted.org>
Message-ID: <1586523842.83.0.744905956308.issue40244@roundup.psfhosted.org>


Michael Felt <aixtools at felt.demon.nl> added the comment:

It is only XLC-v16 that fails. XLC-v11 and XLC-v13 work fine. Am digging to see which version (< v16, or >= v16) is not working as expected.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40244>
_______________________________________

From report at bugs.python.org  Fri Apr 10 09:06:46 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 10 Apr 2020 13:06:46 +0000
Subject: [issue39939] PEP 616: Add str methods to remove prefix or suffix
In-Reply-To: <1583953898.19.0.613718077904.issue39939@roundup.psfhosted.org>
Message-ID: <1586524006.09.0.74421454577.issue39939@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +18809
pull_request: https://github.com/python/cpython/pull/19455

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39939>
_______________________________________

From report at bugs.python.org  Fri Apr 10 09:18:28 2020
From: report at bugs.python.org (David Strobach)
Date: Fri, 10 Apr 2020 13:18:28 +0000
Subject: [issue40238] os.stat() on Windows succeeds for nonexistent paths with
 trailing spaces
In-Reply-To: <1586442330.4.0.896715206677.issue40238@roundup.psfhosted.org>
Message-ID: <1586524708.7.0.997628891426.issue40238@roundup.psfhosted.org>


David Strobach <lalochcz at gmail.com> added the comment:

Hi Eryk, thanks for your time and for the explanation.

> The Windows file API normalizes paths to replace forward slashes with backslashes; resolve relative paths and "." and ".." components; strip trailing spaces and dots from the final component; and map reserved DOS device names in the final component of non-UNC paths to device paths (e.g. "C:/Temp/con " -> r"\\.\con").

OK, I understand. I know that Win32 documentation suggests to avoid using paths with trailing spaces and that the paths are subject to normalization. Then I'd say os.path.normpath() should  perform the same (GetFullPathNameW?) normalization as os.stat() and friends do.

Currently:

>>> import os
>>> path = r"c:\Program Files "
>>> os.path.normpath(path)
'c:\\Program Files '
>>> os.path.realpath(path)
'C:\\Program Files'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40238>
_______________________________________

From report at bugs.python.org  Fri Apr 10 09:22:03 2020
From: report at bugs.python.org (Chih-Hsuan Yen)
Date: Fri, 10 Apr 2020 13:22:03 +0000
Subject: [issue37596] Reproducible pyc: frozenset is not serialized in a
 deterministic order
In-Reply-To: <1563203111.95.0.786255267379.issue37596@roundup.psfhosted.org>
Message-ID: <1586524923.51.0.199470591308.issue37596@roundup.psfhosted.org>


Chih-Hsuan Yen <yan12125 at gmail.com> added the comment:

issue34722 also talks about frozenset, nondeterministic order and sorting. Maybe this ticket and that one are for the same issue?

----------
nosy: +yan12125

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37596>
_______________________________________

From report at bugs.python.org  Fri Apr 10 09:23:09 2020
From: report at bugs.python.org (Chih-Hsuan Yen)
Date: Fri, 10 Apr 2020 13:23:09 +0000
Subject: [issue34033] distutils is not reproducible
In-Reply-To: <1530632785.81.0.56676864532.issue34033@psf.upfronthosting.co.za>
Message-ID: <1586524989.72.0.0732960083892.issue34033@roundup.psfhosted.org>


Change by Chih-Hsuan Yen <yan12125 at gmail.com>:


----------
nosy: +yan12125

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34033>
_______________________________________

From report at bugs.python.org  Fri Apr 10 09:26:52 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Fri, 10 Apr 2020 13:26:52 +0000
Subject: [issue40237] Test code coverage (C) job of Travis CI fails on
 test_distutils which creates _configtest.gcno file
In-Reply-To: <1586436730.26.0.786791148526.issue40237@roundup.psfhosted.org>
Message-ID: <1586525212.8.0.749456480814.issue40237@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
nosy: +corona10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40237>
_______________________________________

From report at bugs.python.org  Fri Apr 10 09:35:40 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 10 Apr 2020 13:35:40 +0000
Subject: [issue39943] Meta: Clean up various issues in C internals
In-Reply-To: <1583983387.49.0.277830283994.issue39943@roundup.psfhosted.org>
Message-ID: <1586525740.8.0.360456413526.issue39943@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy:  -vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39943>
_______________________________________

From report at bugs.python.org  Fri Apr 10 09:41:40 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Fri, 10 Apr 2020 13:41:40 +0000
Subject: [issue40221] Use new _at_fork_reinit() lock method in multiprocessing
In-Reply-To: <1586300633.14.0.457029058496.issue40221@roundup.psfhosted.org>
Message-ID: <1586526100.61.0.378133805888.issue40221@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
nosy: +corona10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40221>
_______________________________________

From report at bugs.python.org  Fri Apr 10 09:57:20 2020
From: report at bugs.python.org (Eryk Sun)
Date: Fri, 10 Apr 2020 13:57:20 +0000
Subject: [issue40238] os.stat() on Windows succeeds for nonexistent paths with
 trailing spaces
In-Reply-To: <1586442330.4.0.896715206677.issue40238@roundup.psfhosted.org>
Message-ID: <1586527040.43.0.674700785863.issue40238@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> I'd say os.path.normpath() should  perform the same (GetFullPathNameW?)
> normalization as os.stat() and friends do.

ntpath.abspath calls GetFullPathNameW (i.e. nt._getfullpathname) in Windows, but ntpath.normpath is pure Python. I agree that normpath should trim trailing spaces and dots from the last component. It should also normalize device paths and extended paths that start with "\\\\.\\" and "\\\\?\\". An extended path only skips normalization in an open or create context.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40238>
_______________________________________

From report at bugs.python.org  Fri Apr 10 10:00:15 2020
From: report at bugs.python.org (Zachary Ware)
Date: Fri, 10 Apr 2020 14:00:15 +0000
Subject: [issue39598] Spam magnet
In-Reply-To: <1581337438.53.0.0366477237465.issue39598@roundup.psfhosted.org>
Message-ID: <1586527215.57.0.516595096858.issue39598@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

Maybe I'm just paranoid, but this whole issue reads like spam to me.  It's at least a spam magnet; changing the title accordingly and clearing the nosy list.

----------
nosy:  -Sahurkhan, gustavoxo, judiction, nows, paul.moore, steve.dower, tim.golden, xtreak
title: ERR_CACHE_MISS -> Spam magnet

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39598>
_______________________________________

From report at bugs.python.org  Fri Apr 10 10:01:23 2020
From: report at bugs.python.org (Michael Felt)
Date: Fri, 10 Apr 2020 14:01:23 +0000
Subject: [issue40244] AIX: build: _PyObject_GC_TRACK Asstertion failure
In-Reply-To: <1586520060.04.0.792331001042.issue40244@roundup.psfhosted.org>
Message-ID: <51476d3d-4d92-de49-8f8a-870bcd019aa2@felt.demon.nl>


Michael Felt <aixtools at felt.demon.nl> added the comment:

On 10/04/2020 14:01, STINNER Victor wrote:
> STINNER Victor <vstinner at python.org> added the comment:
>
> The assertion failure occurs in _PyObject_GC_TRACK() at:
>
> static void
> gen_dealloc(PyGenObject *gen)
> {
>     PyObject *self = (PyObject *) gen;
>
>     _PyObject_GC_UNTRACK(gen);
>
>     if (gen->gi_weakreflist != NULL)
>         PyObject_ClearWeakRefs(self);
>
>     _PyObject_GC_TRACK(self);  // <==== HERE
>
>     ...
> }
>
> It's surprising that the generator is still tracked by the GC after _PyObject_GC_UNTRACK().
>
>
>> Calling this a compile error - as it seems to be compiler dependent.
> Do you reproduce the bug if you build Python with GCC?

To be clear - gcc does not not have an issue. As I stated elsewhere - it
is specific to xlc-v16, so likely it is a compiler error.

See also the result of `git bisect` study.

>
> Which ./configure command did you use? What are the compiler and linker flags?
>
> You can try:
>
> ./python -m test.pythoninfo|grep -E 'CFLAGS|CC|OPT|LDFLAGS'

With:

$ ./python -m test.pythoninfo|grep -E 'CFLAGS|CC|OPT|LDFLAGS'
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? : 30084150
object refcount : 0
object type???? : 200144a8
object type name: generator
object repr???? : <refcnt 0 at 30084150>

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
ksh: 27328848 IOT/Abort trap(coredump)

Without error:

$ ./python -m test.pythoninfo|grep -E 'CFLAGS|CC|OPT|LDFLAGS'
os.environ[CC]: xlc_r
sysconfig[CC]: xlc_r
sysconfig[CFLAGS]: -O
sysconfig[CONFIG_ARGS]: '--with-openssl=/opt/aixtools'
'--without-computed-gotos' '--with-pydebug' 'CC=xlc_r'
sysconfig[OPT]: -O
sysconfig[PY_CFLAGS]: -O
sysconfig[PY_CFLAGS_NODIST]: -I./Include/internal
sysconfig[PY_STDMODULE_CFLAGS]: -O -I./Include/internal -I. -I./Include

> ----------
> nosy: +vstinner
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue40244>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40244>
_______________________________________

From report at bugs.python.org  Fri Apr 10 10:06:00 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 10 Apr 2020 14:06:00 +0000
Subject: [issue40242] zmq mysql core dump
In-Reply-To: <1586455195.03.0.155128936869.issue40242@roundup.psfhosted.org>
Message-ID: <1586527560.95.0.0419995815516.issue40242@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

I'm going to close this. If you can provide information on how to reproduce this and/or what you observe in the segfault dump, we will happily reopen it.

I think the best "resolution" tag is to call this "third party", but I'm not sure it matters too much.

----------
resolution:  -> third party
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40242>
_______________________________________

From report at bugs.python.org  Fri Apr 10 10:14:17 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 10 Apr 2020 14:14:17 +0000
Subject: [issue37266] Daemon threads must be forbidden in subinterpreters
In-Reply-To: <1560418565.72.0.288239825756.issue37266@roundup.psfhosted.org>
Message-ID: <1586528057.89.0.212189754194.issue37266@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +18811
pull_request: https://github.com/python/cpython/pull/19456

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37266>
_______________________________________

From report at bugs.python.org  Fri Apr 10 10:14:17 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 10 Apr 2020 14:14:17 +0000
Subject: [issue40234] Disallow daemon threads in subinterpreters optionally.
In-Reply-To: <1586387812.86.0.0296012569674.issue40234@roundup.psfhosted.org>
Message-ID: <1586528057.82.0.403455759646.issue40234@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
keywords: +patch
pull_requests: +18810
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/19456

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40234>
_______________________________________

From report at bugs.python.org  Fri Apr 10 10:16:31 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 10 Apr 2020 14:16:31 +0000
Subject: [issue40234] Disallow daemon threads in subinterpreters optionally.
In-Reply-To: <1586387812.86.0.0296012569674.issue40234@roundup.psfhosted.org>
Message-ID: <1586528191.63.0.576837609783.issue40234@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Well, this large problem sounds very complex and is made of multiple small issues. Let's start with something simple: revert my commit 066e5b1a917ec2134e8997d2cadd815724314252.

When I wrote it, I expected that nobody was spawning daemon threads in subinterpreters. I was wrong.

Once PR 19456 will be merged (allow again to spawn daemon threads in subinterpreters), we can start to investigate every single issue listed by Graham, like atexit callbacks which are called too late.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40234>
_______________________________________

From report at bugs.python.org  Fri Apr 10 10:17:04 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 10 Apr 2020 14:17:04 +0000
Subject: [issue40244] AIX: build: _PyObject_GC_TRACK Asstertion failure
In-Reply-To: <1586507316.69.0.786578254213.issue40244@roundup.psfhosted.org>
Message-ID: <1586528224.97.0.838321619884.issue40244@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> [0003c2dc1d4cf5b122e73e83177fd274fa9a9913] bpo-40096: Support __attribute__((__noreturn__)) on xlc (GH-19204)

The fix looks simple: revert this change, no?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40244>
_______________________________________

From report at bugs.python.org  Fri Apr 10 10:24:22 2020
From: report at bugs.python.org (William Meehan)
Date: Fri, 10 Apr 2020 14:24:22 +0000
Subject: [issue40243] Unicode 3.2 numeric uses decimal_changed instead of
 numeric_changed
Message-ID: <1586528662.38.0.595306924569.issue40243@roundup.psfhosted.org>


Change by William Meehan <wmeehan at fb.com>:


----------
keywords: +patch
pull_requests: +18812
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19457

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40243>
_______________________________________

From report at bugs.python.org  Fri Apr 10 10:40:37 2020
From: report at bugs.python.org (Tim Lo)
Date: Fri, 10 Apr 2020 14:40:37 +0000
Subject: [issue39285] PurePath.match indicates case-sensitive nature and
 presents a case-insensitive example
In-Reply-To: <1578650816.04.0.399157633818.issue39285@roundup.psfhosted.org>
Message-ID: <1586529637.84.0.957869877784.issue39285@roundup.psfhosted.org>


Change by Tim Lo <timlo604 at gmail.com>:


----------
keywords: +patch
nosy: +timlo
nosy_count: 4.0 -> 5.0
pull_requests: +18814
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19458

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39285>
_______________________________________

From report at bugs.python.org  Fri Apr 10 10:46:43 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 10 Apr 2020 14:46:43 +0000
Subject: [issue39481] Implement PEP 585 (Type Hinting Generics In Standard
 Collections)
In-Reply-To: <1580231817.93.0.47144630055.issue39481@roundup.psfhosted.org>
Message-ID: <1586530003.53.0.405066773954.issue39481@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:


New changeset 0361556537686f857f1025ead75e6af4ca7cc94a by Batuhan Ta?kaya in branch 'master':
bpo-39481: PEP 585 for a variety of modules (GH-19423)
https://github.com/python/cpython/commit/0361556537686f857f1025ead75e6af4ca7cc94a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39481>
_______________________________________

From report at bugs.python.org  Fri Apr 10 11:09:27 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Fri, 10 Apr 2020 15:09:27 +0000
Subject: [issue1635741] Py_Finalize() doesn't clear all Python objects at exit
Message-ID: <1586531367.02.0.690881744805.issue1635741@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
pull_requests: +18815
pull_request: https://github.com/python/cpython/pull/19459

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1635741>
_______________________________________

From report at bugs.python.org  Fri Apr 10 11:13:02 2020
From: report at bugs.python.org (Zachary Ware)
Date: Fri, 10 Apr 2020 15:13:02 +0000
Subject: [issue39598] Spam magnet
In-Reply-To: <1581337438.53.0.0366477237465.issue39598@roundup.psfhosted.org>
Message-ID: <1586531582.13.0.0214107509762.issue39598@roundup.psfhosted.org>


Change by Zachary Ware <zachary.ware at gmail.com>:


----------
nosy:  -zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39598>
_______________________________________

From report at bugs.python.org  Fri Apr 10 11:13:50 2020
From: report at bugs.python.org (Henry Carscadden)
Date: Fri, 10 Apr 2020 15:13:50 +0000
Subject: [issue40230] Itertools.product() Out of Memory Errors
In-Reply-To: <1586376726.21.0.0873613535989.issue40230@roundup.psfhosted.org>
Message-ID: <1586531630.97.0.924279274023.issue40230@roundup.psfhosted.org>


Henry Carscadden <hlc5v at virginia.edu> added the comment:

@Tim Peters
For example,
the following should reproduce the error:
many_arguments = [[1,2] for i in range(50)]
for term in product(*many_arguments):
    print(term)
In my application, I was taking the Cartesian product of the sets of all simple path to several nodes. This regularly produced a lot of arguments and crashed the compute nodes on which my jobs were running. Perhaps, this is not a salient concern for most uses, but I just wanted to make you aware of the issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40230>
_______________________________________

From report at bugs.python.org  Fri Apr 10 11:54:00 2020
From: report at bugs.python.org (Stefano Rivera)
Date: Fri, 10 Apr 2020 15:54:00 +0000
Subject: [issue38501] multiprocessing.Pool hangs atexit (and garbage
 collection sometimes)
In-Reply-To: <1571250674.69.0.928369483471.issue38501@roundup.psfhosted.org>
Message-ID: <1586534040.99.0.568029923217.issue38501@roundup.psfhosted.org>


Stefano Rivera <python at rivera.za.net> added the comment:

Looks like it was fixed by PR 19009 (bpo-39360)).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38501>
_______________________________________

From report at bugs.python.org  Fri Apr 10 11:57:36 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 10 Apr 2020 15:57:36 +0000
Subject: [issue38501] multiprocessing.Pool hangs atexit (and garbage
 collection sometimes)
In-Reply-To: <1571250674.69.0.928369483471.issue38501@roundup.psfhosted.org>
Message-ID: <1586534256.67.0.877147307792.issue38501@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

>Looks like it was fixed by PR 19009 (bpo-39360)).

Can we close the issue then? If not, could yo provide a reproducer and also check if the big is fixed on master or 3.8 HEAD? Thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38501>
_______________________________________

From report at bugs.python.org  Fri Apr 10 12:00:53 2020
From: report at bugs.python.org (Stefano Rivera)
Date: Fri, 10 Apr 2020 16:00:53 +0000
Subject: [issue38501] multiprocessing.Pool hangs atexit (and garbage
 collection sometimes)
In-Reply-To: <1571250674.69.0.928369483471.issue38501@roundup.psfhosted.org>
Message-ID: <1586534453.13.0.39183283174.issue38501@roundup.psfhosted.org>


Stefano Rivera <python at rivera.za.net> added the comment:

On Linux, the reproducer in https://bugs.python.org/issue38501#msg354813 fails on ac10e0c93218627d1a639db0b7b41714c5f6a883^ and passes on ac10e0c93218627d1a639db0b7b41714c5f6a883, which is why I say PR 19009 fixes it.

Not sure if there are any special considerations for Windows here.

HEAD is good too. So from my PoV, good to close this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38501>
_______________________________________

From report at bugs.python.org  Fri Apr 10 12:10:33 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 10 Apr 2020 16:10:33 +0000
Subject: [issue38501] multiprocessing.Pool hangs atexit (and garbage
 collection sometimes)
In-Reply-To: <1571250674.69.0.928369483471.issue38501@roundup.psfhosted.org>
Message-ID: <1586535033.87.0.0731353439809.issue38501@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

> Not sure if there are any special considerations for Windows here.

It should not be anything windows specific here.

Also notice that although "it works", the reproducer in https://bugs.python.org/issue38501#msg354813 is out of contract because is not closing or terminating the pool correctly and is not using it with the context manager so if you are dealing with code equivalent to that I would suggest to take a look to properly finalize/finalize the pool to about similar problems (or other problems related to late finalization).

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38501>
_______________________________________

From report at bugs.python.org  Fri Apr 10 12:31:07 2020
From: report at bugs.python.org (Eric Larson)
Date: Fri, 10 Apr 2020 16:31:07 +0000
Subject: [issue38501] multiprocessing.Pool hangs atexit (and garbage
 collection sometimes)
In-Reply-To: <1571250674.69.0.928369483471.issue38501@roundup.psfhosted.org>
Message-ID: <1586536267.98.0.687204639937.issue38501@roundup.psfhosted.org>


Eric Larson <larson.eric.d at gmail.com> added the comment:

If that's out of contract, perhaps there should probably a big, visible warning at the top of the multiprocessning docs stating that creating one of these objects requires either using a context manager or ensuring manual `.close()`ing?

1. It either used to be in contract not to close it manually or was wrongly represented, the first Python 2.7 example in the docs (https://docs.python.org/2/library/multiprocessing.html#introduction) is:

from multiprocessing import Pool

def f(x):
    return x*x

if __name__ == '__main__':
    p = Pool(5)
    print(p.map(f, [1, 2, 3]))

So I suspect this (difficult to track down) problem might hit users without more adequate warning.


2. I'm surprised it's actually out of contract when the 3.8 docs state that close will be automatically called:

> close()
>
> Indicate that no more data will be put on this queue by the current process. The background thread will quit once it has flushed all buffered data to the pipe. This is called automatically when the queue is garbage collected.

and

> terminate()
>
> Stops the worker processes immediately without completing outstanding work. When the pool object is garbage collected terminate() will be called immediately.

Or perhaps I misunderstand what this is saying?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38501>
_______________________________________

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: [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 12:43:50 2020
From: report at bugs.python.org (Tim Peters)
Date: Fri, 10 Apr 2020 16:43:50 +0000
Subject: [issue40230] Itertools.product() Out of Memory Errors
In-Reply-To: <1586376726.21.0.0873613535989.issue40230@roundup.psfhosted.org>
Message-ID: <1586537030.77.0.670801476785.issue40230@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

Henry, no, I see no problem while running your example.  It's been running on my box for over 5 minutes now, and memory use remains trivial.

Note that in the code I posted for you, instead of [1, 2] I used range(100), and instead of 50 I used a million:  the same kind of thing, but I used _far_ larger numbers.  And still didn't have a problem.  Although, yes, that did consume about a gigabyte to materialize a million instances of tuple(range(100)) under the covers.

The code you posted also works fine for me, and with minor memory consumption, if I replace your "50" with "1000000":

>>> many_arguments = [[1,2] for i in range(1000000)]
>>> for term in product(*many_arguments):
...     pass

100% of a CPU is used for as long as I let it run, but memory use jumps just a little at the start.  Which is what I expected.  It just doesn't take all that much memory to create a million 2-tuples - which is what the `product()` implementation does.

I believe you saw a MemoryError, but at this point I have to guess you misdiagnosed the cause.  In any case, if you can't supply an example that reproduces the problem, we're going to have to close this.

Perhaps there's some weird memory-allocation flaw on the _platform_ you're using?  Extreme fragmentation?  Without an example that exhibits a problem, there's just no way to guess from here :-(

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40230>
_______________________________________

From report at bugs.python.org  Fri Apr 10 12:49:36 2020
From: report at bugs.python.org (hai shi)
Date: Fri, 10 Apr 2020 16:49:36 +0000
Subject: [issue40237] Test code coverage (C) job of Travis CI fails on
 test_distutils which creates _configtest.gcno file
In-Reply-To: <1586436730.26.0.786791148526.issue40237@roundup.psfhosted.org>
Message-ID: <1586537376.81.0.00654552824757.issue40237@roundup.psfhosted.org>


Change by hai shi <shihai1991 at 126.com>:


----------
keywords: +patch
pull_requests: +18816
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19460

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40237>
_______________________________________

From report at bugs.python.org  Fri Apr 10 12:55:38 2020
From: report at bugs.python.org (hai shi)
Date: Fri, 10 Apr 2020 16:55:38 +0000
Subject: [issue40237] Test code coverage (C) job of Travis CI fails on
 test_distutils which creates _configtest.gcno file
In-Reply-To: <1586436730.26.0.786791148526.issue40237@roundup.psfhosted.org>
Message-ID: <1586537738.8.0.666477508312.issue40237@roundup.psfhosted.org>


hai shi <shihai1991 at 126.com> added the comment:

> Maybe CFLAGS_NODIST should be used instead of CFLAGS.
Looks like it worked.

> Python is built GCC with -ftest-coverage option.
More exact description is: Python is built GCC with --coverage option, --coverage option including -ftest-coverage option.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40237>
_______________________________________

From report at bugs.python.org  Fri Apr 10 12:58:14 2020
From: report at bugs.python.org (hai shi)
Date: Fri, 10 Apr 2020 16:58:14 +0000
Subject: [issue40237] Test code coverage (C) job of Travis CI fails on
 test_distutils which creates _configtest.gcno file
In-Reply-To: <1586436730.26.0.786791148526.issue40237@roundup.psfhosted.org>
Message-ID: <1586537894.08.0.0182109779674.issue40237@roundup.psfhosted.org>


hai shi <shihai1991 at 126.com> added the comment:

> Looks like it worked.
Oh, sorry, I checked the wrong gate.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40237>
_______________________________________

From report at bugs.python.org  Fri Apr 10 13:46:14 2020
From: report at bugs.python.org (Andy Lester)
Date: Fri, 10 Apr 2020 17:46:14 +0000
Subject: [issue40245] Add description meta tags to docs.python.org
In-Reply-To: <1586536705.62.0.749935364813.issue40245@roundup.psfhosted.org>
Message-ID: <1586540774.72.0.266198152871.issue40245@roundup.psfhosted.org>


Change by Andy Lester <andy at petdance.com>:


----------
nosy: +petdance

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40245>
_______________________________________

From report at bugs.python.org  Fri Apr 10 13:54:06 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 10 Apr 2020 17:54:06 +0000
Subject: [issue38501] multiprocessing.Pool hangs atexit (and garbage
 collection sometimes)
In-Reply-To: <1571250674.69.0.928369483471.issue38501@roundup.psfhosted.org>
Message-ID: <1586541246.67.0.487531483042.issue38501@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

> If that's out of contract, perhaps there should probably a big, visible warning at the top of the multiprocessning docs stating that creating one of these objects requires either using a context manager or ensuring manual `.close()`ing?

Why? This is a resource like any other and it requires proper resource management. Would you also put a big warning on "open()" stating that opening a file requires either using a context manager or ensure a manual close()?

>  the first Python 2.7 example in the docs 

Python 2.7 is not supported and the pool has changed *a lot* since Python 2. For instance, the pool now does more correct resource management, it does not leak threads and it supports more safe mechanisms as a context manager. The reason it didn't hang that much in Python2.7 is likely because some threads were being leaked.

> This is called automatically when the queue is garbage collected.

Yeah, and CPython does not promise that the __del__ method of any object will be called, so is not assured that the finalized will call close():

https://docs.python.org/3/reference/datamodel.html#object.__del__

"It is not guaranteed that __del__() methods are called for objects that still exist when the interpreter exits"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38501>
_______________________________________

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: [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 14:08:45 2020
From: report at bugs.python.org (Henry Carscadden)
Date: Fri, 10 Apr 2020 18:08:45 +0000
Subject: [issue40230] Itertools.product() Out of Memory Errors
In-Reply-To: <1586376726.21.0.0873613535989.issue40230@roundup.psfhosted.org>
Message-ID: <1586542125.18.0.821397923389.issue40230@roundup.psfhosted.org>


Henry Carscadden <hlc5v at virginia.edu> added the comment:

Tim, I'm guessing it was a misdiagnosis then. In any case, something changed about my codebase that alleviated the problem. Thanks for looking into it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40230>
_______________________________________

From report at bugs.python.org  Fri Apr 10 14:14:30 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 10 Apr 2020 18:14:30 +0000
Subject: [issue40246] Different error messages for same error - invalid string
 prefixes
In-Reply-To: <1586541958.33.0.891000303304.issue40246@roundup.psfhosted.org>
Message-ID: <1586542470.64.0.138517228191.issue40246@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40246>
_______________________________________

From report at bugs.python.org  Fri Apr 10 14:20:13 2020
From: report at bugs.python.org (Lysandros Nikolaou)
Date: Fri, 10 Apr 2020 18:20:13 +0000
Subject: [issue40246] Different error messages for same error - invalid string
 prefixes
In-Reply-To: <1586541958.33.0.891000303304.issue40246@roundup.psfhosted.org>
Message-ID: <1586542813.51.0.296297613994.issue40246@roundup.psfhosted.org>


Change by Lysandros Nikolaou <lisandrosnik at gmail.com>:


----------
nosy: +gvanrossum, pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40246>
_______________________________________

From report at bugs.python.org  Fri Apr 10 14:21:32 2020
From: report at bugs.python.org (Eric Larson)
Date: Fri, 10 Apr 2020 18:21:32 +0000
Subject: [issue38501] multiprocessing.Pool hangs atexit (and garbage
 collection sometimes)
In-Reply-To: <1571250674.69.0.928369483471.issue38501@roundup.psfhosted.org>
Message-ID: <1586542892.67.0.255577044729.issue38501@roundup.psfhosted.org>


Eric Larson <larson.eric.d at gmail.com> added the comment:

> Why? This is a resource like any other and it requires proper resource management. Would you also put a big warning on "open()" stating that opening a file requires either using a context manager or ensure a manual close()?

One potential reason would be that the consequences of bad resource management in this case are different than in the open() case, i.e., here the interpreter hangs -- or Travis runs for your repo (SciPy) get stuck with over-50-minute errors, which is how we started looking for how to track it down.

> > the first Python 2.7 example in the docs 

> Python 2.7 is not supported and the pool has changed *a lot* since Python 2. 

Indeed, my point is more about potential prevalence: this (now incorrect) problematic usage pattern was the first example in the docs for multiprocessing for a long time, indicating that there might be a lot of code in the wild that might (still) make use of it.

> Yeah, and CPython does not promise that the __del__ method of any object will be called, so is not assured that the finalized will call close():

Ahh, I didn't know that. This might be another good reason to add a warning about the risks of not ensuring closure yourself: others might have the same gap in knowledge I had, and assume the docs are saying that things will be taken care of by garbage collection on exit when they will not.

But you of course cannot document every possible problematic situation users could put themselves in, so I leave it up to your judgment whether or not it's worth it in this case.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38501>
_______________________________________

From report at bugs.python.org  Fri Apr 10 14:39:35 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 10 Apr 2020 18:39:35 +0000
Subject: [issue40230] Itertools.product() Out of Memory Errors
In-Reply-To: <1586376726.21.0.0873613535989.issue40230@roundup.psfhosted.org>
Message-ID: <1586543975.52.0.257689137765.issue40230@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
resolution:  -> not a bug
stage: test needed -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40230>
_______________________________________

From report at bugs.python.org  Fri Apr 10 14:44:30 2020
From: report at bugs.python.org (Lysandros Nikolaou)
Date: Fri, 10 Apr 2020 18:44:30 +0000
Subject: [issue40246] Different error messages for same error - invalid string
 prefixes
In-Reply-To: <1586541958.33.0.891000303304.issue40246@roundup.psfhosted.org>
Message-ID: <1586544270.41.0.780468065972.issue40246@roundup.psfhosted.org>


Lysandros Nikolaou <lisandrosnik at gmail.com> added the comment:

After some investigating, I found out that this is happening because when we execute `fur''` in the interactive interpreter there is an implicit newline, which means that EOF does not get reached.

OTOH there is no newline when passing it as a string inside an `eval` call. After the tokenizer encounters the first quote, it calls `tok_nextc` twice more, in order to differentiate between a single-quoted and a triple-quoted string, thus reaching EOF and proapgating an EOF error up through the `perrdetail` struct.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40246>
_______________________________________

From report at bugs.python.org  Fri Apr 10 14:46:35 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 10 Apr 2020 18:46:35 +0000
Subject: [issue40241] [C API] Make PyGC_Head structure opaque,
 or even move it to the internal C API
In-Reply-To: <1586445596.83.0.583225080007.issue40241@roundup.psfhosted.org>
Message-ID: <1586544395.15.0.525529754586.issue40241@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
pull_requests: +18817
pull_request: https://github.com/python/cpython/pull/19461

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40241>
_______________________________________

From report at bugs.python.org  Fri Apr 10 14:53:20 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 10 Apr 2020 18:53:20 +0000
Subject: [issue38501] multiprocessing.Pool hangs atexit (and garbage
 collection sometimes)
In-Reply-To: <1571250674.69.0.928369483471.issue38501@roundup.psfhosted.org>
Message-ID: <1586544800.15.0.897275076118.issue38501@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

> One potential reason would be that the consequences of bad resource management in this case are different than in the open() case, i.e., here the interpreter hangs -- or Travis runs for your repo (SciPy) get stuck with over-50-minute errors, which is how we started looking for how to track it down.

Agreed, but is the same problem: resources need to be managed. I am although ok if you want to add some targeted warning to the multiprocessing pool docs indicating what can happen if the resource is not properly managed.

> Indeed, my point is more about potential prevalence: this (now incorrect) problematic usage pattern was the first example in the docs for multiprocessing for a long time, indicating that there might be a lot of code in the wild that might (still) make use of it.

Right, we put great efforts to make the code such that even incorrect usages do not hang (and believe me, is *very* challenging) but we cannot sacrifice correct usage fixes or big improvements so incorrect usages keep working even if they are leaking resources. Hopefully, more and more people start using the context manager or are aware that are doing something wrong leaking the pool.

----

In conclusion, I agree that maybe adding some targetted warning to the pool docs about this is in place. When I prepare the PR, would you like to review the message to confirm that is clear enough and that makes sense?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38501>
_______________________________________

From report at bugs.python.org  Fri Apr 10 15:48:18 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 10 Apr 2020 19:48:18 +0000
Subject: [issue40178] Convert the remaining os funtions to Argument Clinic
In-Reply-To: <1586003108.43.0.643087706293.issue40178@roundup.psfhosted.org>
Message-ID: <1586548098.71.0.337797019277.issue40178@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

#37206 changed the signature "pop(self, key, default=None, /)" back to "D.pop(k[,d]) -> v", taken from dict.pop.__doc__.  However, the incorrect version that got reverted correctly added the positional-only indicator '/'.  Docstrings with signatures for such cases may need updating.

Unlike most objects with invalid signatures (as seen by inspect.signature), the current docstring for os.get_terminal_size does not have a backup signature for help (and IDLE) to present.  I cannot tell if the patch adds it.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40178>
_______________________________________

From report at bugs.python.org  Fri Apr 10 15:54:25 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 10 Apr 2020 19:54:25 +0000
Subject: [issue40197] Add nanoseconds to timing table in What's new python 3.8
In-Reply-To: <1586102648.92.0.310451381261.issue40197@roundup.psfhosted.org>
Message-ID: <1586548465.73.0.995049594414.issue40197@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +18818
pull_request: https://github.com/python/cpython/pull/19462

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40197>
_______________________________________

From report at bugs.python.org  Fri Apr 10 16:00:22 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 10 Apr 2020 20:00:22 +0000
Subject: [issue40197] Add nanoseconds to timing table in What's new python 3.8
In-Reply-To: <1586102648.92.0.310451381261.issue40197@roundup.psfhosted.org>
Message-ID: <1586548822.4.0.964657534645.issue40197@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 1bf7dee8d35cb19db7ee98229dd2e5726e6c7606 by Miss Islington (bot) in branch '3.8':
bpo-40197: Better describe the benchmark results table (GH-19386)
https://github.com/python/cpython/commit/1bf7dee8d35cb19db7ee98229dd2e5726e6c7606


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40197>
_______________________________________

From report at bugs.python.org  Fri Apr 10 16:09:27 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 10 Apr 2020 20:09:27 +0000
Subject: [issue40199] Invalid escape sequence DeprecationWarnings don't
 trigger by default
In-Reply-To: <1586118564.22.0.0408193741044.issue40199@roundup.psfhosted.org>
Message-ID: <1586549367.95.0.316735623596.issue40199@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

On Win 10, with recently compiled 3.7.7+ and 3.9.0a5+, I get 4 warnings also.

>>> import warnings
>>> compile("'\d'", "<string>", "eval")
<stdin>:1: DeprecationWarning: invalid escape sequence \d
<string>:1: DeprecationWarning: invalid escape sequence \d
<code object <module> at 0x00A65DC0, file "<string>", line 1>
>>> warnings.resetwarnings()
>>> compile("'\d'", "<string>", "eval")
<stdin>:1: DeprecationWarning: invalid escape sequence \d
<string>:1: DeprecationWarning: invalid escape sequence \d
<code object <module> at 0x00A66190, file "<string>", line 1>

Numerior, what 3.8 binaries are you running?  I suspect that this should be closed as 'out of date'.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40199>
_______________________________________

From report at bugs.python.org  Fri Apr 10 16:14:17 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 10 Apr 2020 20:14:17 +0000
Subject: [issue40197] Add nanoseconds to timing table in What's new python 3.8
In-Reply-To: <1586102648.92.0.310451381261.issue40197@roundup.psfhosted.org>
Message-ID: <1586549657.41.0.626805509559.issue40197@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40197>
_______________________________________

From report at bugs.python.org  Fri Apr 10 16:32:37 2020
From: report at bugs.python.org (Numerlor)
Date: Fri, 10 Apr 2020 20:32:37 +0000
Subject: [issue40199] Invalid escape sequence DeprecationWarnings don't
 trigger by default
In-Reply-To: <1586118564.22.0.0408193741044.issue40199@roundup.psfhosted.org>
Message-ID: <1586550757.94.0.289040996493.issue40199@roundup.psfhosted.org>


Numerlor <miso1038 at gmail.com> added the comment:

The newest 64 bit release from python.org via the executable installer.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40199>
_______________________________________

From report at bugs.python.org  Fri Apr 10 16:41:48 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 10 Apr 2020 20:41:48 +0000
Subject: [issue40170] [C API] Make PyTypeObject structure an opaque structure
 in the public C API
In-Reply-To: <1585915023.07.0.846808236133.issue40170@roundup.psfhosted.org>
Message-ID: <1586551308.59.0.223480955136.issue40170@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

/* Test if an object has a GC head */
#define PyObject_IS_GC(o) \
    (PyType_IS_GC(Py_TYPE(o)) \
     && (Py_TYPE(o)->tp_is_gc == NULL || Py_TYPE(o)->tp_is_gc(o)))

This macro should be converted to an opaque function.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40170>
_______________________________________

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: [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:00:05 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 10 Apr 2020 21:00:05 +0000
Subject: [issue40197] Add nanoseconds to timing table in What's new python 3.8
In-Reply-To: <1586102648.92.0.310451381261.issue40197@roundup.psfhosted.org>
Message-ID: <1586552405.54.0.931487470852.issue40197@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Raymond, I finished the backporting and assume that your patch was meant to be a complete fix.

----------
nosy: +terry.reedy
versions: +Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40197>
_______________________________________

From report at bugs.python.org  Fri Apr 10 17:09:19 2020
From: report at bugs.python.org (hai shi)
Date: Fri, 10 Apr 2020 21:09:19 +0000
Subject: [issue40170] [C API] Make PyTypeObject structure an opaque structure
 in the public C API
In-Reply-To: <1585915023.07.0.846808236133.issue40170@roundup.psfhosted.org>
Message-ID: <1586552959.61.0.217500271787.issue40170@roundup.psfhosted.org>


hai shi <shihai1991 at 126.com> added the comment:

> This macro should be converted to an opaque function
Can I try it?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40170>
_______________________________________

From report at bugs.python.org  Fri Apr 10 17:17:41 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 10 Apr 2020 21:17:41 +0000
Subject: [issue40203] Warn about invalid PYTHONUSERBASE
In-Reply-To: <1586177955.41.0.354760283694.issue40203@roundup.psfhosted.org>
Message-ID: <1586553461.08.0.434630807957.issue40203@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I marked this for 'interpreter Core' because it affects imports and nothing else seemed better.

I marked this for 3.9 because it is too late to change 2.7.  But I don't know whether PYTHONUSERBASE is still treated (or not treated) the same.

Volker, I assume that you meant 'no good reason to not do so'.  A possible reason is that checking the validity of all environmental variables at startup would slow down startup, whereas we have been trying to speed it up.  Also, if PYTHONUSERBASE, in particular, is ever used for an import, a bad value will result in an import error.

----------
components: +Interpreter Core
nosy: +terry.reedy
versions: +Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40203>
_______________________________________

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: [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 17:58:12 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 10 Apr 2020 21:58:12 +0000
Subject: [issue40248] Proposed class for collections: dynamicdict
In-Reply-To: <1586553586.38.0.834422539726.issue40248@roundup.psfhosted.org>
Message-ID: <1586555892.41.0.996912846536.issue40248@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

You probably want to bring this up on the python-ideas mailing list for discussion. Features like this typically get discussed there first.

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40248>
_______________________________________

From report at bugs.python.org  Fri Apr 10 18:03:55 2020
From: report at bugs.python.org (Steele Farnsworth)
Date: Fri, 10 Apr 2020 22:03:55 +0000
Subject: [issue40248] Proposed class for collections: dynamicdict
In-Reply-To: <1586553586.38.0.834422539726.issue40248@roundup.psfhosted.org>
Message-ID: <1586556235.15.0.260573266174.issue40248@roundup.psfhosted.org>


Steele Farnsworth <swfarnsworth at gmail.com> added the comment:

Thank you, I have done so.

----------

_______________________________________
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: [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 18:35:49 2020
From: report at bugs.python.org (hai shi)
Date: Fri, 10 Apr 2020 22:35:49 +0000
Subject: [issue40170] [C API] Make PyTypeObject structure an opaque structure
 in the public C API
In-Reply-To: <1585915023.07.0.846808236133.issue40170@roundup.psfhosted.org>
Message-ID: <1586558149.92.0.568568506506.issue40170@roundup.psfhosted.org>


Change by hai shi <shihai1991 at 126.com>:


----------
pull_requests: +18819
pull_request: https://github.com/python/cpython/pull/19464

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40170>
_______________________________________

From report at bugs.python.org  Fri Apr 10 18:50:25 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 10 Apr 2020 22:50:25 +0000
Subject: [issue40249] __import__ doesn't honour globals
In-Reply-To: <1586558028.61.0.331520667517.issue40249@roundup.psfhosted.org>
Message-ID: <1586559025.37.0.49290609216.issue40249@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

globals is only used when level > 0, to resolve relative names like in `import ..foo`. You have to set keys __package__ and __spec__ or __name__ and __path__ in this case.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40249>
_______________________________________

From report at bugs.python.org  Fri Apr 10 18:52:55 2020
From: report at bugs.python.org (Russell Davis)
Date: Fri, 10 Apr 2020 22:52:55 +0000
Subject: [issue29255] selects.KqueueSelector behaves incorrectly when no fds
 are registered
In-Reply-To: <1484264107.13.0.0489042381572.issue29255@psf.upfronthosting.co.za>
Message-ID: <1586559175.21.0.846886610873.issue29255@roundup.psfhosted.org>


Russell Davis <russell.davis at gmail.com> added the comment:

This looks like it's the cause of https://bugs.python.org/issue25680

----------
nosy: +russelldavis

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29255>
_______________________________________

From report at bugs.python.org  Fri Apr 10 18:55:17 2020
From: report at bugs.python.org (Russell Davis)
Date: Fri, 10 Apr 2020 22:55:17 +0000
Subject: [issue25680] Selector.select() hangs when there is nothing to select
In-Reply-To: <1448029102.96.0.470819036773.issue25680@psf.upfronthosting.co.za>
Message-ID: <1586559317.34.0.440127121077.issue25680@roundup.psfhosted.org>


Russell Davis <russell.davis at gmail.com> added the comment:

Looks like this is caused by #29255

----------
nosy: +russelldavis

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25680>
_______________________________________

From report at bugs.python.org  Fri Apr 10 18:56:13 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 10 Apr 2020 22:56:13 +0000
Subject: [issue40246] Different error messages for same error - invalid string
 prefixes
In-Reply-To: <1586541958.33.0.891000303304.issue40246@roundup.psfhosted.org>
Message-ID: <1586559373.61.0.680571181381.issue40246@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

So a slightly shorter example uses ru''. This is an error because you can't combine the r prefix and the u prefix (in fact you can't combine anything with the r prefix).

I declare that this is a bug to report EOF here and the code should *first* check for a valid combination (e.g. fr'' or rf'') and only *then* try to distinguish between single and triple quotes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40246>
_______________________________________

From report at bugs.python.org  Fri Apr 10 19:01:31 2020
From: report at bugs.python.org (Lysandros Nikolaou)
Date: Fri, 10 Apr 2020 23:01:31 +0000
Subject: [issue40246] Different error messages for same error - invalid string
 prefixes
In-Reply-To: <1586541958.33.0.891000303304.issue40246@roundup.psfhosted.org>
Message-ID: <1586559691.81.0.857739000475.issue40246@roundup.psfhosted.org>


Lysandros Nikolaou <lisandrosnik at gmail.com> added the comment:

At the moment, if the prefix is invalid, it gets tokenized as a NAME node and the string following is tokenized as a STRING node with no prefix.

?? echo "ur''" | ./python -m tokenize
1,0-1,2:            NAME           'ur'           
1,2-1,4:            STRING         "''"           
1,4-1,5:            NEWLINE        '\n'           
2,0-2,0:            ENDMARKER      ''

?? echo "f''" | ./python -m tokenize  
1,0-1,3:            STRING         "f''"          
1,3-1,4:            NEWLINE        '\n'           
2,0-2,0:            ENDMARKER      ''

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40246>
_______________________________________

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: [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:06:14 2020
From: report at bugs.python.org (Furkan Onder)
Date: Fri, 10 Apr 2020 23:06:14 +0000
Subject: [issue26571] turtle regression in 3.5
In-Reply-To: <1458104355.45.0.620158354917.issue26571@psf.upfronthosting.co.za>
Message-ID: <1586559974.5.0.426159002189.issue26571@roundup.psfhosted.org>


Change by Furkan Onder <furkanonder at protonmail.com>:


----------
keywords: +patch
nosy: +furkanonder
nosy_count: 4.0 -> 5.0
pull_requests: +18820
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/19465

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26571>
_______________________________________

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: [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: [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  Fri Apr 10 19:24:41 2020
From: report at bugs.python.org (Elmar Bucher)
Date: Fri, 10 Apr 2020 23:24:41 +0000
Subject: [issue40250] unable to comment out r'\u' string with triple quote
 marks
In-Reply-To: <1586559791.68.0.297747169601.issue40250@roundup.psfhosted.org>
Message-ID: <1586561081.16.0.860622607855.issue40250@roundup.psfhosted.org>


Change by Elmar Bucher <elmbeech at gmail.com>:


----------
type:  -> compile error

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40250>
_______________________________________

From report at bugs.python.org  Fri Apr 10 19:44:37 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 10 Apr 2020 23:44:37 +0000
Subject: [issue40250] unable to comment out r'\u' string with triple quote
 marks
In-Reply-To: <1586559791.68.0.297747169601.issue40250@roundup.psfhosted.org>
Message-ID: <1586562277.71.0.384236015441.issue40250@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

This basically comes down to """\u""" not being a valid string.

I'm not sure why you'd expect this to work: triple quoted strings are not designed as a general purpose "comment out" facility, and as you've discovered, they don't work that way. What's inside a triple quoted string must be interpretable as a python string, which in this case it is not.

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40250>
_______________________________________

From report at bugs.python.org  Fri Apr 10 20:22:06 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sat, 11 Apr 2020 00:22:06 +0000
Subject: [issue40241] [C API] Make PyGC_Head structure opaque,
 or even move it to the internal C API
In-Reply-To: <1586445596.83.0.583225080007.issue40241@roundup.psfhosted.org>
Message-ID: <1586564526.18.0.263682102201.issue40241@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset f13072b8a89a922285737988b086beb4b06c6648 by Pablo Galindo in branch 'master':
bpo-40241: Add PyObject_GC_IsTracked and PyObject_GC_IsFinalized to the public C-API (GH-19461)
https://github.com/python/cpython/commit/f13072b8a89a922285737988b086beb4b06c6648


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40241>
_______________________________________

From report at bugs.python.org  Fri Apr 10 20:25:22 2020
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 11 Apr 2020 00:25:22 +0000
Subject: [issue40240] Expose public spelling of _PyGC_FINALIZED and
 _PyGC_SET_FINALIZED?
In-Reply-To: <1586444432.56.0.946879588514.issue40240@roundup.psfhosted.org>
Message-ID: <1586564722.12.0.424350872549.issue40240@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

New changeset f13072b8a89a922285737988b086beb4b06c6648 by Pablo Galindo in branch 'master':
bpo-40241: Add PyObject_GC_IsTracked and PyObject_GC_IsFinalized to the public C-API (GH-19461)
https://github.com/python/cpython/commit/f13072b8a89a922285737988b086beb4b06c6648

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40240>
_______________________________________

From report at bugs.python.org  Fri Apr 10 20:52:59 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sat, 11 Apr 2020 00:52:59 +0000
Subject: [issue38501] multiprocessing.Pool hangs atexit (and garbage
 collection sometimes)
In-Reply-To: <1571250674.69.0.928369483471.issue38501@roundup.psfhosted.org>
Message-ID: <1586566379.38.0.114076602471.issue38501@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
pull_requests: +18821
pull_request: https://github.com/python/cpython/pull/19466

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38501>
_______________________________________

From report at bugs.python.org  Fri Apr 10 21:06:18 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 11 Apr 2020 01:06:18 +0000
Subject: [issue40204] Docs build error with Sphinx 3.0 due to invalid C
 declaration
In-Reply-To: <1586183568.2.0.322929459864.issue40204@roundup.psfhosted.org>
Message-ID: <1586567178.01.0.112442512168.issue40204@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

A few days ago, 3.8 backports failed while 3.7 backports merged. Thank you for the fix, even if temporary.

I just noticed that the doc main page ends with "Created using Sphinx 2.3.1."  I plan to switch my local sphinx to that version.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40204>
_______________________________________

From report at bugs.python.org  Fri Apr 10 21:16:06 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 11 Apr 2020 01:16:06 +0000
Subject: [issue40205] Profile 'builtins' parameter documentation missing
In-Reply-To: <1586184213.23.0.0753500955635.issue40205@roundup.psfhosted.org>
Message-ID: <1586567766.07.0.189750176415.issue40205@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I verified the statements and notice that profile.Profile has many methods not in cProfile.Profile.  Neither is a complete replacement for the other.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40205>
_______________________________________

From report at bugs.python.org  Fri Apr 10 21:17:09 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 11 Apr 2020 01:17:09 +0000
Subject: [issue40207] Expose NCURSES_EXT_FUNCS under curses
In-Reply-To: <1586188512.46.0.148388356677.issue40207@roundup.psfhosted.org>
Message-ID: <1586567829.38.0.751461646825.issue40207@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +twouters

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40207>
_______________________________________

From report at bugs.python.org  Fri Apr 10 21:30:21 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Sat, 11 Apr 2020 01:30:21 +0000
Subject: [issue40248] Proposed class for collections: dynamicdict
In-Reply-To: <1586553586.38.0.834422539726.issue40248@roundup.psfhosted.org>
Message-ID: <1586568621.11.0.5783416988.issue40248@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

This feature is already provided by just supplying a `__missing__` dunder:

py> class MyDict(dict):
...     def __missing__(self, key):
...             return "The key is {}".format(key)
...
py> d = MyDict()
py> d[1234]
'The key is 1234'


I'm closing this ticket, but if the discussion on Python-Ideas reaches consensus that your class is necessary, feel free to re-open it.

----------
nosy: +steven.daprano
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40248>
_______________________________________

From report at bugs.python.org  Fri Apr 10 21:33:04 2020
From: report at bugs.python.org (=?utf-8?b?VmVkcmFuIMSMYcSNacSH?=)
Date: Sat, 11 Apr 2020 01:33:04 +0000
Subject: [issue40250] unable to comment out r'\u' string with triple quote
 marks
In-Reply-To: <1586559791.68.0.297747169601.issue40250@roundup.psfhosted.org>
Message-ID: <1586568784.58.0.741873703611.issue40250@roundup.psfhosted.org>


Vedran ?a?i? <vedgar at gmail.com> added the comment:

This "bug" is reported at least once a year, by different people. Maybe we should put something in the documentation, to the effect that

a) as Eric said, triple-quoted strings are not (meant to be used as) comments

b) if you nonetheless really want to use them that way, in most cases you _can_ get away with using r'''...'''.

----------
nosy: +veky

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40250>
_______________________________________

From report at bugs.python.org  Fri Apr 10 21:35:53 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 11 Apr 2020 01:35:53 +0000
Subject: [issue40208] Remove deprecated symtable.SymbolTable.has_exec
In-Reply-To: <1586192722.9.0.88612242995.issue40208@roundup.psfhosted.org>
Message-ID: <1586568953.49.0.0208430689718.issue40208@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

https://docs.python.org/3/library/symtable.html#symtable.SymbolTable.has_exec
merely says "Return True if the block uses exec."  This never happens since
https://github.com/python/cpython/blob/3.8/Lib/symtable.py#L87
is "return False".  I presume 'exec' refers to 2.x statement, not the 3.x function.  The docstring on line 86 does say "Deprecated method."

Guido, you changed these lines in 2006, in 2def557aba1aaa42b638f9bf95624b7e6929191c  I presume you left them for the benefit of ported 2.7 code.  Should the function be removed for 3.9 or left until 3.10?  Your commit message referred to 'dead EXEC related constants'.  Is there anything else that should be removed?

----------
nosy: +gvanrossum, terry.reedy
title: Remove deprecated SymbolTable.has_exec -> Remove deprecated symtable.SymbolTable.has_exec

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40208>
_______________________________________

From report at bugs.python.org  Fri Apr 10 21:37:17 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 11 Apr 2020 01:37:17 +0000
Subject: [issue40208] Remove deprecated symtable.SymbolTable.has_exec
In-Reply-To: <1586192722.9.0.88612242995.issue40208@roundup.psfhosted.org>
Message-ID: <1586569037.42.0.60176270318.issue40208@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Answer: no.  The 2006 patch already removed OPT_EXEC and OPT_BARE_EXEC.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40208>
_______________________________________

From report at bugs.python.org  Fri Apr 10 22:05:43 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sat, 11 Apr 2020 02:05:43 +0000
Subject: [issue38501] multiprocessing.Pool hangs atexit (and garbage
 collection sometimes)
In-Reply-To: <1571250674.69.0.928369483471.issue38501@roundup.psfhosted.org>
Message-ID: <1586570743.53.0.0758189859362.issue38501@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset 7ec43a73092d43c6c95e7dd2669f49d54b57966f by Pablo Galindo in branch 'master':
bpo-38501: Add a warning section to multiprocessing.Pool docs about resource managing (GH-19466)
https://github.com/python/cpython/commit/7ec43a73092d43c6c95e7dd2669f49d54b57966f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38501>
_______________________________________

From report at bugs.python.org  Fri Apr 10 22:05:59 2020
From: report at bugs.python.org (miss-islington)
Date: Sat, 11 Apr 2020 02:05:59 +0000
Subject: [issue38501] multiprocessing.Pool hangs atexit (and garbage
 collection sometimes)
In-Reply-To: <1571250674.69.0.928369483471.issue38501@roundup.psfhosted.org>
Message-ID: <1586570759.75.0.834291960457.issue38501@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +18823
pull_request: https://github.com/python/cpython/pull/19468

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38501>
_______________________________________

From report at bugs.python.org  Fri Apr 10 22:05:52 2020
From: report at bugs.python.org (miss-islington)
Date: Sat, 11 Apr 2020 02:05:52 +0000
Subject: [issue38501] multiprocessing.Pool hangs atexit (and garbage
 collection sometimes)
In-Reply-To: <1571250674.69.0.928369483471.issue38501@roundup.psfhosted.org>
Message-ID: <1586570752.45.0.460752802455.issue38501@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
nosy: +miss-islington
nosy_count: 7.0 -> 8.0
pull_requests: +18822
pull_request: https://github.com/python/cpython/pull/19467

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38501>
_______________________________________

From report at bugs.python.org  Fri Apr 10 22:11:19 2020
From: report at bugs.python.org (miss-islington)
Date: Sat, 11 Apr 2020 02:11:19 +0000
Subject: [issue38501] multiprocessing.Pool hangs atexit (and garbage
 collection sometimes)
In-Reply-To: <1571250674.69.0.928369483471.issue38501@roundup.psfhosted.org>
Message-ID: <1586571079.33.0.00652806098371.issue38501@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 2e49b5254aa0888dd21a7929be14b6cfe03d56ef by Miss Islington (bot) in branch '3.7':
bpo-38501: Add a warning section to multiprocessing.Pool docs about resource managing (GH-19466)
https://github.com/python/cpython/commit/2e49b5254aa0888dd21a7929be14b6cfe03d56ef


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38501>
_______________________________________

From report at bugs.python.org  Fri Apr 10 22:11:20 2020
From: report at bugs.python.org (miss-islington)
Date: Sat, 11 Apr 2020 02:11:20 +0000
Subject: [issue38501] multiprocessing.Pool hangs atexit (and garbage
 collection sometimes)
In-Reply-To: <1571250674.69.0.928369483471.issue38501@roundup.psfhosted.org>
Message-ID: <1586571080.74.0.664224458158.issue38501@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset ceba0648d70524ec4ebb7a46d5d1162d4938c7ba by Miss Islington (bot) in branch '3.8':
bpo-38501: Add a warning section to multiprocessing.Pool docs about resource managing (GH-19466)
https://github.com/python/cpython/commit/ceba0648d70524ec4ebb7a46d5d1162d4938c7ba


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38501>
_______________________________________

From report at bugs.python.org  Fri Apr 10 22:22:06 2020
From: report at bugs.python.org (Stefan Seefeld)
Date: Sat, 11 Apr 2020 02:22:06 +0000
Subject: [issue40249] __import__ doesn't honour globals
In-Reply-To: <1586558028.61.0.331520667517.issue40249@roundup.psfhosted.org>
Message-ID: <1586571726.39.0.704221697114.issue40249@roundup.psfhosted.org>


Stefan Seefeld <stefan at seefeld.name> added the comment:

OK, thanks for the clarification. I think this is obscure enough to warrant at least a paragraph or two to clarify the semantics of these arguments.
I changed the issue "components" and "type" to reflect that.

----------
assignee:  -> docs at python
components: +Documentation -Interpreter Core
nosy: +docs at python
type: behavior -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40249>
_______________________________________

From report at bugs.python.org  Fri Apr 10 22:23:26 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 11 Apr 2020 02:23:26 +0000
Subject: [issue40210] ttk.Combobox focus-out event inheritage
In-Reply-To: <1586204301.95.0.352088098712.issue40210@roundup.psfhosted.org>
Message-ID: <1586571806.7.0.462931847957.issue40210@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

What OS and what tcl/tk patch version? (IDLE Help => About IDLE will show this).  3.5 only gets security patches.  On Windows, it came with a slightly older version of tk.  That might possibly be a problem.

One cannot place widgets 'in a treeview', so you are actually placing the entries or comboboxes *over* a cell of the treeview.  You are placing them, I presume, *in* the toplevel or frame also containing the treeview.  Try passing that container, instead of the treeview, as the parent.  Does the that fix your problem?  If so, please close as 'not a bug'.

Your example is too short.  It cannot be run as is.  And I do not understand the problem from your description.  If the treeview parent is not the problem, then your example is likely too long, as the treeview stuff is likely irrelevant noise.  Please repost or attach a minimal, complete and verifiable example as described in
https://stackoverflow.com/help/minimal-reproducible-example

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40210>
_______________________________________

From report at bugs.python.org  Fri Apr 10 22:37:02 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 11 Apr 2020 02:37:02 +0000
Subject: [issue40218] sys.executable is a false path if python is executed
 from gdb
In-Reply-To: <1586290599.79.0.960995339825.issue40218@roundup.psfhosted.org>
Message-ID: <1586572622.0.0.982560783102.issue40218@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I shortened the title so that 'gdb' shows.  I have never used gdb, but I am curious what *is* the path to the python running the python code after 'python'?  Is it part of or included with gdb?  If so, this seems a gdb bug, as it is the responsibility of the running python to correctly locate itself.  We are only responsible for the binaries we provide (Windows and macOS) or binaries compiled from the unpatched codebase.  (I said 'seems' because it could be that gdb compiles with an untested combination of supported compile switches.)

----------
nosy: +terry.reedy
title: sys.executable is a non existing path if python is executed from gdb -> sys.executable is a false 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  Fri Apr 10 22:57:15 2020
From: report at bugs.python.org (Chih-Hsuan Yen)
Date: Sat, 11 Apr 2020 02:57:15 +0000
Subject: [issue39481] Implement PEP 585 (Type Hinting Generics In Standard
 Collections)
In-Reply-To: <1580231817.93.0.47144630055.issue39481@roundup.psfhosted.org>
Message-ID: <1586573835.81.0.276261302283.issue39481@roundup.psfhosted.org>


Change by Chih-Hsuan Yen <yan12125 at gmail.com>:


----------
nosy: +yan12125
nosy_count: 5.0 -> 6.0
pull_requests: +18824
pull_request: https://github.com/python/cpython/pull/19469

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39481>
_______________________________________

From report at bugs.python.org  Fri Apr 10 23:02:43 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 11 Apr 2020 03:02:43 +0000
Subject: [issue40219] ttk LabeledScale: label covered by hidden element
In-Reply-To: <1586292175.49.0.452846630354.issue40219@roundup.psfhosted.org>
Message-ID: <1586574163.24.0.531986152078.issue40219@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

3.6 only get security fixes, but your nice minimal, complete verifiable example let me verify easily on 3.9a5 with tk 8.6.9 and 3.6 with 8.6.6 and 2.7.17 with 8.5.19. The hidden element appears to be something like'||' with only part visible, depending on the scale value.  It at least partly obscures from -20 to 15.  (Clicking the bar moves 1 unit at a time.)  This should be tested on other systems, but I suspect that this is an upstream tcl/tk issue.

----------
nosy: +serhiy.storchaka, terry.reedy
versions: +Python 3.7, Python 3.8, Python 3.9 -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40219>
_______________________________________

From report at bugs.python.org  Fri Apr 10 23:33:09 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 11 Apr 2020 03:33:09 +0000
Subject: [issue40208] Remove deprecated symtable.SymbolTable.has_exec
In-Reply-To: <1586192722.9.0.88612242995.issue40208@roundup.psfhosted.org>
Message-ID: <1586575989.78.0.476185511594.issue40208@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

Yeah, this seems safe to remove. If somebody's code breaks, that will just help them remove some dead code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40208>
_______________________________________

From report at bugs.python.org  Fri Apr 10 23:38:55 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 11 Apr 2020 03:38:55 +0000
Subject: [issue30140] Binary arithmetic does not always call subclasses first
In-Reply-To: <1492921304.69.0.401017078402.issue30140@psf.upfronthosting.co.za>
Message-ID: <1586576335.97.0.0764773748447.issue30140@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

Let's give up on this one.

----------
resolution:  -> wont fix
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30140>
_______________________________________

From report at bugs.python.org  Fri Apr 10 23:42:01 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 11 Apr 2020 03:42:01 +0000
Subject: [issue40246] Different error messages for same error - invalid string
 prefixes
In-Reply-To: <1586541958.33.0.891000303304.issue40246@roundup.psfhosted.org>
Message-ID: <1586576521.37.0.806250202865.issue40246@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

But that is the tokenize.py module. It does not have 100% the same behavior as the builtin tokenizer.c module. In this case it probably doesn't.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40246>
_______________________________________

From report at bugs.python.org  Fri Apr 10 23:46:33 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 11 Apr 2020 03:46:33 +0000
Subject: [issue25680] Selector.select() hangs when there is nothing to select
In-Reply-To: <1448029102.96.0.470819036773.issue25680@psf.upfronthosting.co.za>
Message-ID: <1586576793.1.0.904052712223.issue25680@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

That may well be correct. Do you want to submit a PR to fix it?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25680>
_______________________________________

From report at bugs.python.org  Fri Apr 10 23:47:42 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sat, 11 Apr 2020 03:47:42 +0000
Subject: [issue40244] AIX: build: _PyObject_GC_TRACK Asstertion failure
In-Reply-To: <1586507316.69.0.786578254213.issue40244@roundup.psfhosted.org>
Message-ID: <1586576862.08.0.176362727479.issue40244@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
nosy: +BTaskaya, pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40244>
_______________________________________

From report at bugs.python.org  Fri Apr 10 23:48:02 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 11 Apr 2020 03:48:02 +0000
Subject: [issue40235] confusing documentation for IOBase.__exit__
In-Reply-To: <1586404042.0.0.215231917986.issue40235@roundup.psfhosted.org>
Message-ID: <1586576882.55.0.027758713373.issue40235@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Please post or attach *minimal* and complete (runnable as is) code that does not do what you expect.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40235>
_______________________________________

From report at bugs.python.org  Fri Apr 10 23:49:21 2020
From: report at bugs.python.org (=?utf-8?b?VmVkcmFuIMSMYcSNacSH?=)
Date: Sat, 11 Apr 2020 03:49:21 +0000
Subject: [issue40066] Enum._convert should change __repr__ and/or __str__ to
 use module name instead of class name
In-Reply-To: <1585165738.23.0.618463548627.issue40066@roundup.psfhosted.org>
Message-ID: <1586576961.65.0.723979094572.issue40066@roundup.psfhosted.org>


Vedran ?a?i? <vedgar at gmail.com> added the comment:

> _in some cases when enum instances are exposed as module globals_

Yes. And repr should be inverse of eval, but it's probably too late for that. :-/

----------
nosy: +veky

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40066>
_______________________________________

From report at bugs.python.org  Sat Apr 11 00:49:56 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 11 Apr 2020 04:49:56 +0000
Subject: [issue40199] Invalid escape sequence DeprecationWarnings don't
 trigger by default
In-Reply-To: <1586118564.22.0.0408193741044.issue40199@roundup.psfhosted.org>
Message-ID: <1586580596.32.0.243783315939.issue40199@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

OK, verified issue with installed 3.9.0a5, which must have different warning settings.

>From a file, 1 warning.
<string>:1: DeprecationWarning: invalid escape sequence \d

Interactively, no warning.

>>> compile("'\d'", "<string>", "eval")
<code object <module> at 0x00000263842DFC90, file "<string>", line 1>
>>>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40199>
_______________________________________

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: [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 03:36:09 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 11 Apr 2020 07:36:09 +0000
Subject: [issue40199] Invalid escape sequence DeprecationWarnings don't
 trigger by default
In-Reply-To: <1586118564.22.0.0408193741044.issue40199@roundup.psfhosted.org>
Message-ID: <1586590569.49.0.919848644198.issue40199@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
components: +Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40199>
_______________________________________

From report at bugs.python.org  Sat Apr 11 03:43:49 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 11 Apr 2020 07:43:49 +0000
Subject: [issue40235] confusing documentation for IOBase.__exit__
In-Reply-To: <1586404042.0.0.215231917986.issue40235@roundup.psfhosted.org>
Message-ID: <1586591029.85.0.787622983848.issue40235@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I cannot reproduce the issue. __exit__() calls close().

>>> import io
>>> class F(io.IOBase):
...     def close(self):
...         print('close')
...         super().close()  # set closed = True
... 
>>> with F(): pass
... 
close

----------
nosy: +serhiy.storchaka
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40235>
_______________________________________

From report at bugs.python.org  Sat Apr 11 03:48:46 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 11 Apr 2020 07:48:46 +0000
Subject: [issue39943] Meta: Clean up various issues in C internals
In-Reply-To: <1583983387.49.0.277830283994.issue39943@roundup.psfhosted.org>
Message-ID: <1586591326.7.0.95079638632.issue39943@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset cd8295ff758891f21084a6a5ad3403d35dda38f7 by Serhiy Storchaka in branch 'master':
bpo-39943: Add the const qualifier to pointers on non-mutable PyUnicode data. (GH-19345)
https://github.com/python/cpython/commit/cd8295ff758891f21084a6a5ad3403d35dda38f7


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39943>
_______________________________________

From report at bugs.python.org  Sat Apr 11 03:59:31 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 11 Apr 2020 07:59:31 +0000
Subject: [issue40126] Incorrect error handling in unittest.mock
In-Reply-To: <1585670844.45.0.631660598637.issue40126@roundup.psfhosted.org>
Message-ID: <1586591971.17.0.810891348221.issue40126@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 4b222c9491d1700e9bdd98e6889b8d0ea1c7321e by Serhiy Storchaka in branch 'master':
bpo-40126: Fix reverting multiple patches in unittest.mock. (GH-19351)
https://github.com/python/cpython/commit/4b222c9491d1700e9bdd98e6889b8d0ea1c7321e


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40126>
_______________________________________

From report at bugs.python.org  Sat Apr 11 04:00:46 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 11 Apr 2020 08:00:46 +0000
Subject: [issue40129] Add test classes for custom __index__, __int__,
 __float__ and __complex__
In-Reply-To: <1585687064.58.0.0478382370232.issue40129@roundup.psfhosted.org>
Message-ID: <1586592046.29.0.852326401534.issue40129@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
resolution:  -> rejected
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40129>
_______________________________________

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: [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 05:00:52 2020
From: report at bugs.python.org (Tomohiko Kinebuchi)
Date: Sat, 11 Apr 2020 09:00:52 +0000
Subject: [issue40254] pyspecific directives are not translatable
In-Reply-To: <1586595169.2.0.635960834529.issue40254@roundup.psfhosted.org>
Message-ID: <1586595652.9.0.933030622253.issue40254@roundup.psfhosted.org>


Change by Tomohiko Kinebuchi <cocoatomo77 at gmail.com>:


----------
keywords: +patch
pull_requests: +18825
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19470

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40254>
_______________________________________

From report at bugs.python.org  Sat Apr 11 06:12:34 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 11 Apr 2020 10:12:34 +0000
Subject: [issue39943] Meta: Clean up various issues in C internals
In-Reply-To: <1583983387.49.0.277830283994.issue39943@roundup.psfhosted.org>
Message-ID: <1586599954.21.0.383892623978.issue39943@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +18827
pull_request: https://github.com/python/cpython/pull/19472

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39943>
_______________________________________

From report at bugs.python.org  Sat Apr 11 06:35:41 2020
From: report at bugs.python.org (Lysandros Nikolaou)
Date: Sat, 11 Apr 2020 10:35:41 +0000
Subject: [issue40246] Different error messages for same error - invalid string
 prefixes
In-Reply-To: <1586541958.33.0.891000303304.issue40246@roundup.psfhosted.org>
Message-ID: <1586601341.05.0.137897249537.issue40246@roundup.psfhosted.org>


Lysandros Nikolaou <lisandrosnik at gmail.com> added the comment:

In my understanding of the C code that's what the C tokenizer is doing as well.

Here's the relevant snippet of the tokenizer (https://github.com/python/cpython/blob/4b222c9491d1700e9bdd98e6889b8d0ea1c7321e/Parser/tokenizer.c#L1358): When the tokenizer sees a valid identifier start, it goes into a loop that checks for a valid combination of string prefixes. If the combination is valid and it sees a quote directly after that, it goto's to the STRING-handling code. If not, then it breaks out of the loop and returns a NAME node.

Am I missing something?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40246>
_______________________________________

From report at bugs.python.org  Sat Apr 11 06:41:23 2020
From: report at bugs.python.org (hai shi)
Date: Sat, 11 Apr 2020 10:41:23 +0000
Subject: [issue40237] Test code coverage (C) job of Travis CI fails on
 test_distutils which creates _configtest.gcno file
In-Reply-To: <1586436730.26.0.786791148526.issue40237@roundup.psfhosted.org>
Message-ID: <1586601683.99.0.516157578745.issue40237@roundup.psfhosted.org>


hai shi <shihai1991 at 126.com> added the comment:

After `CFLAGS` replcaced by `CFLAGS_NODIST`, some extension module built failed, some info like:
*** WARNING: renaming "_struct" since importing it failed: build/lib.linux-x86_64-3.9/_struct.cpython-39-x86_64-linux-gnu.so: undefined symbol: __gcov_merge_add

the possible reason:
building '_struct' extension
gcc -pthread -fPIC -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -std=c99 -Wextra -Wno-unused-result -Wno-unused-parameter -Wno-missing-field-initializers -Werror=implicit-function-declaration -fvisibility=hidden -O0 -pg --coverage -I./Include/internal -I./Include -I. -I/usr/local/include -I/temp/shihai/cpython/Include -I/temp/shihai/cpython -c /temp/shihai/cpython/Modules/_struct.c -o build/temp.linux-x86_64-3.9/temp/shihai/cpython/Modules/_struct.o
gcc -pthread -shared (xxxxxxxxxxlacking --coverage in here xxxxxxxxx) build/temp.linux-x86_64-3.9/temp/shihai/cpython/Modules/_struct.o -L/usr/local/lib -o build/lib.linux-x86_64-3.9/_struct.cpython-39-x86_64-linux-gnu.so

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40237>
_______________________________________

From report at bugs.python.org  Sat Apr 11 06:51:39 2020
From: report at bugs.python.org (hai shi)
Date: Sat, 11 Apr 2020 10:51:39 +0000
Subject: [issue40237] Test code coverage (C) job of Travis CI fails on
 test_distutils which creates _configtest.gcno file
In-Reply-To: <1586436730.26.0.786791148526.issue40237@roundup.psfhosted.org>
Message-ID: <1586602299.1.0.147137924439.issue40237@roundup.psfhosted.org>


hai shi <shihai1991 at 126.com> added the comment:

FWIW, gcc Instrumentation Options in https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40237>
_______________________________________

From report at bugs.python.org  Sat Apr 11 06:53:25 2020
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Sat, 11 Apr 2020 10:53:25 +0000
Subject: [issue40225] recursive call within generator expression is O(depth)
In-Reply-To: <1586347827.41.0.754437002794.issue40225@roundup.psfhosted.org>
Message-ID: <1586602405.26.0.953780583443.issue40225@roundup.psfhosted.org>


R?mi Lapeyre <remi.lapeyre at henki.fr> added the comment:

I've been looking at this, I find the effect more visible when you don't do the division in the last print().

After bisecting, it looks like ae3087c6382011c47db82fea4d05f8bbf514265d may account for most of the performance gap between 3.6 and 3.7.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40225>
_______________________________________

From report at bugs.python.org  Sat Apr 11 07:41:42 2020
From: report at bugs.python.org (Eryk Sun)
Date: Sat, 11 Apr 2020 11:41:42 +0000
Subject: [issue40253] Fix .py(w) file association with Pyhon 3 Windows
 installer
In-Reply-To: <1586590189.16.0.270400617976.issue40253@roundup.psfhosted.org>
Message-ID: <1586605302.45.0.0911440617874.issue40253@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

An "Applications\python.exe" progid gets created by browsing for "python.exe" when configuring the file association. For example, it gets created by the Windows shell (Explorer) via "open with" -> "choose another app" -> "look for another app on this PC". The shell has no option in this case to indicate that the filetype is a script that needs command-line arguments via "%*", so the "shell\open\command" template that it assigns is incorrect.

If the user also selects to "always use this app", the shell sets a "UserChoice" key in a key named for the file extension under "HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts". The user choice overrides the default association computed via HKCR settings. Applications are not supposed to meddle with the "UserChoice" key. Its contents are doubly protected by the key's security and a hash value.

The shell key for the file extension usually has two other subkeys: "OpenWithList" and "OpenWithProgids". These can also override the HKCR file association. The "OpenWithList" key lists executables that have been used to open the filetype via the "open with" menu, and it also contains an "MRUList" value that sorts the list by order of most recently used. The "OpenWithProgids" key caches progids that are used to open the program. Usually there's just one cached progid. But if there's more than one, in my experience the shell selects the progid that's associated with the first exectuable in the "OpenWithList", by order of the "MRUList" value. In this particular and peculiar case, the current file association follows whichever program was most recently selected in the "open with" list.

> I found this report which fixed the problem: 
> https://stackoverflow.com/questions/15281951

Continuing to use the shell-generated "Applications\python.exe" progid means that you won't have shebang support provided by the py.exe launcher (e.g. for associating scripts with particular virtual environments), the "Edit with IDLE" menu, or the shell-extension drop handler. 

I recommend selecting the installed "Python.File" progid instead. It's the "Python" app with the launcher icon that has a rocket on it. If you use the "open with" menu to select this progid, also select the option to always use the selected app. This sets the shell's "UserChoice" key to lock down the file association.

FYI, never modify the HKCR merged view as suggested by the linked SO answer. Modify the source hive in "HKCU\Software\Classes" or "HKLM\Software\Classes". If you modify HKCR directly, the key(s) that you end up modifying could be in one or the other hive depending on what's already present (e.g. you could modify a value just for the current user, though your intent is to modify it for all users). You should know whether you need to modify system settings, user settings, or both. If you don't know, you need to do more research before proceeding.

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40253>
_______________________________________

From report at bugs.python.org  Sat Apr 11 07:46:26 2020
From: report at bugs.python.org (Lysandros Nikolaou)
Date: Sat, 11 Apr 2020 11:46:26 +0000
Subject: [issue40246] Different error messages for same error - invalid string
 prefixes
In-Reply-To: <1586541958.33.0.891000303304.issue40246@roundup.psfhosted.org>
Message-ID: <1586605586.68.0.782490466179.issue40246@roundup.psfhosted.org>


Lysandros Nikolaou <lisandrosnik at gmail.com> added the comment:

I have working code that checks if there is a quotation mark right after an identifier. Here is an example:

?? ./python
Python 3.9.0a5+ (heads/pegen-dirty:502dfb719e, Apr 11 2020, 14:43:12) 
[GCC 9.2.1 20191008] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> ur''
  File "<stdin>", line 1
    ur''
     ^
SyntaxError: invalid string prefix

One observation about this is that it has precedence over an EOL error:

>>> ur'
  File "<stdin>", line 1
    ur'
     ^
SyntaxError: invalid string prefix

Would that be acceptable?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40246>
_______________________________________

From report at bugs.python.org  Sat Apr 11 07:54:27 2020
From: report at bugs.python.org (=?utf-8?q?Volker_Wei=C3=9Fmann?=)
Date: Sat, 11 Apr 2020 11:54:27 +0000
Subject: [issue40203] Warn about invalid PYTHONUSERBASE
In-Reply-To: <1586177955.41.0.354760283694.issue40203@roundup.psfhosted.org>
Message-ID: <1586606067.41.0.359292774604.issue40203@roundup.psfhosted.org>


Volker Wei?mann <volker.weissmann at gmx.de> added the comment:

"there is no good reason to do so" meant that there is no good reason to set PYTHONUSERBASE to non existing path or a path that is not a directory.

The history behind this bug report is that I used a program that, because of a bug in this program, set PYTHONUSERBASE to a non existing path, and I wondered why "import cython" raised a ModuleNotFoundError even though I had installed cython.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40203>
_______________________________________

From report at bugs.python.org  Sat Apr 11 07:59:10 2020
From: report at bugs.python.org (Mark Shannon)
Date: Sat, 11 Apr 2020 11:59:10 +0000
Subject: [issue40225] recursive call within generator expression is O(depth)
In-Reply-To: <1586347827.41.0.754437002794.issue40225@roundup.psfhosted.org>
Message-ID: <1586606350.65.0.972914877116.issue40225@roundup.psfhosted.org>


Mark Shannon <mark at hotpy.org> added the comment:

The problem is that generators always raise an exception, even when they terminate normally.
They don't in 2.7 and didn't prior to https://github.com/python/cpython/commit/1f7ce62bd61488d5d721896a36a1b43befab88b5#diff-23c87bfada1d01335a3019b9321502a0

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40225>
_______________________________________

From report at bugs.python.org  Sat Apr 11 08:09:18 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Sat, 11 Apr 2020 12:09:18 +0000
Subject: [issue40221] Use new _at_fork_reinit() lock method in multiprocessing
In-Reply-To: <1586300633.14.0.457029058496.issue40221@roundup.psfhosted.org>
Message-ID: <1586606958.09.0.278997465415.issue40221@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

I am going to take a look

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40221>
_______________________________________

From report at bugs.python.org  Sat Apr 11 08:09:29 2020
From: report at bugs.python.org (Mark Shannon)
Date: Sat, 11 Apr 2020 12:09:29 +0000
Subject: [issue40225] recursive call within generator expression is O(depth)
In-Reply-To: <1586347827.41.0.754437002794.issue40225@roundup.psfhosted.org>
Message-ID: <1586606969.72.0.0818474373791.issue40225@roundup.psfhosted.org>


Change by Mark Shannon <mark at hotpy.org>:


----------
keywords: +patch
pull_requests: +18828
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19473

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40225>
_______________________________________

From report at bugs.python.org  Sat Apr 11 08:09:38 2020
From: report at bugs.python.org (=?utf-8?q?Volker_Wei=C3=9Fmann?=)
Date: Sat, 11 Apr 2020 12:09:38 +0000
Subject: [issue40218] sys.executable is a false path if python is executed
 from gdb
In-Reply-To: <1586290599.79.0.960995339825.issue40218@roundup.psfhosted.org>
Message-ID: <1586606978.21.0.990947858079.issue40218@roundup.psfhosted.org>


Volker Wei?mann <volker.weissmann at gmx.de> added the comment:

"I have never used gdb, but I am curious what *is* the path to the python running the python code after 'python'? Is it part of or included with gdb?"
I honestly don't know. I think the python interpreter gets compiled into the python binary, because as a test, I removed every python interpreter on my system that I could find and the "python" command inside gdb still worked. But it uses some of pythons shared libraries that get installed when you install python.

I also suspect that it is a bug in gdb.
I think the only thing you can do is take a look at python's source code on how it finds sys.executable and check if it looks fishy or if it looks like it should never point to a non existing file. And we can wait if the gdb programmers will respond.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40218>
_______________________________________

From report at bugs.python.org  Sat Apr 11 08:10:03 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Sat, 11 Apr 2020 12:10:03 +0000
Subject: [issue40221] Use new _at_fork_reinit() lock method in multiprocessing
In-Reply-To: <1586300633.14.0.457029058496.issue40221@roundup.psfhosted.org>
Message-ID: <1586607003.4.0.00161479289672.issue40221@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

we should find all usages from Lib/multiprocessing/*.py

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40221>
_______________________________________

From report at bugs.python.org  Sat Apr 11 08:27:21 2020
From: report at bugs.python.org (Daniel Holth)
Date: Sat, 11 Apr 2020 12:27:21 +0000
Subject: [issue40235] confusing documentation for IOBase.__exit__
In-Reply-To: <1586404042.0.0.215231917986.issue40235@roundup.psfhosted.org>
Message-ID: <1586608041.53.0.399252554539.issue40235@roundup.psfhosted.org>


Daniel Holth <dholth at fastmail.fm> added the comment:

Thanks, I'm sorry I didn't save when I was having my strange problem.

The io module is still practically undocumented. It should have examples subclasses for each class, perhaps a link to the PEP and a link to a Python implementation of the module.

----------
stage:  -> resolved
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40235>
_______________________________________

From report at bugs.python.org  Sat Apr 11 09:13:48 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Sat, 11 Apr 2020 13:13:48 +0000
Subject: [issue40244] AIX: build: _PyObject_GC_TRACK Asstertion failure
In-Reply-To: <1586507316.69.0.786578254213.issue40244@roundup.psfhosted.org>
Message-ID: <1586610828.43.0.531844167992.issue40244@roundup.psfhosted.org>


Batuhan Taskaya <batuhanosmantaskaya at gmail.com> added the comment:

I've just compiled python with (xlc 16.1.0, debug build) and can't experience that compile failure, can you give a specific spot that failure happens?

-bash-4.4$ ./python -m test.pythoninfo|grep -E 'CFLAGS|CC|OPT|LDFLAGS'
sysconfig[CC]: /opt/IBM/xlc/16.1.0/bin/xlc_r
sysconfig[CFLAGS]: -DNDEBUG -O
sysconfig[CONFIG_ARGS]: 'CC=/opt/IBM/xlc/16.1.0/bin/xlc_r'
sysconfig[OPT]: -DNDEBUG -O
sysconfig[PY_CFLAGS]: -DNDEBUG -O
sysconfig[PY_CFLAGS_NODIST]: -I./Include/internal
sysconfig[PY_STDMODULE_CFLAGS]: -DNDEBUG -O -I./Include/internal -I. -I./Include

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40244>
_______________________________________

From report at bugs.python.org  Sat Apr 11 09:19:15 2020
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 11 Apr 2020 13:19:15 +0000
Subject: [issue40244] AIX: build: _PyObject_GC_TRACK Asstertion failure
In-Reply-To: <1586507316.69.0.786578254213.issue40244@roundup.psfhosted.org>
Message-ID: <1586611155.12.0.416575947839.issue40244@roundup.psfhosted.org>


Change by Stefan Krah <stefan at bytereef.org>:


----------
nosy:  -skrah

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40244>
_______________________________________

From report at bugs.python.org  Sat Apr 11 09:31:40 2020
From: report at bugs.python.org (Furkan Onder)
Date: Sat, 11 Apr 2020 13:31:40 +0000
Subject: [issue21760] inspect documentation describes module type inaccurately
In-Reply-To: <1402775893.22.0.955121317915.issue21760@psf.upfronthosting.co.za>
Message-ID: <1586611900.19.0.721500830123.issue21760@roundup.psfhosted.org>


Furkan Onder <furkanonder at protonmail.com> added the comment:

PR has been sent.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21760>
_______________________________________

From report at bugs.python.org  Sat Apr 11 09:31:45 2020
From: report at bugs.python.org (Furkan Onder)
Date: Sat, 11 Apr 2020 13:31:45 +0000
Subject: [issue19468] Relax the type restriction on reloaded modules
In-Reply-To: <1383275813.81.0.924128062775.issue19468@psf.upfronthosting.co.za>
Message-ID: <1586611905.59.0.914562245223.issue19468@roundup.psfhosted.org>


Furkan Onder <furkanonder at protonmail.com> added the comment:

PR has been sent.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19468>
_______________________________________

From report at bugs.python.org  Sat Apr 11 09:31:54 2020
From: report at bugs.python.org (Furkan Onder)
Date: Sat, 11 Apr 2020 13:31:54 +0000
Subject: [issue26571] turtle regression in 3.5
In-Reply-To: <1458104355.45.0.620158354917.issue26571@psf.upfronthosting.co.za>
Message-ID: <1586611914.46.0.0178425021327.issue26571@roundup.psfhosted.org>


Furkan Onder <furkanonder at protonmail.com> added the comment:

PR has been sent.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26571>
_______________________________________

From report at bugs.python.org  Sat Apr 11 09:32:16 2020
From: report at bugs.python.org (virtualnobi)
Date: Sat, 11 Apr 2020 13:32:16 +0000
Subject: [issue40253] Fix .py(w) file association with Pyhon 3 Windows
 installer
In-Reply-To: <1586590189.16.0.270400617976.issue40253@roundup.psfhosted.org>
Message-ID: <1586611936.48.0.924827204821.issue40253@roundup.psfhosted.org>


virtualnobi <virtualnobi at zoho.com> added the comment:

Eryk - thanks for your response. 

> I recommend selecting the installed "Python.File" progid instead. 
> It's the "Python" app with the launcher icon that has a rocket on it.

I don't have a Python with rocket launcher. When I use "Open With" on Windows Explorer, I only have two Python icons with the yin-yan snakes, one with white background (I presume that's still 2.7, as the  file icons were white before), and one with black background (which is available since I installed 3.8). If I select "Choose default program" (or similar - I have a German Windows), the list still only contains these two Python icons, and lot of unrelated stuff (zip, thunderbird, etc.). Initially, the black-background Python was not in this list at all, and I continued by "Further Options" and used the resulting browser to pick the 3.8 version. Since then, I have white and black Pythons. 

How do I get to the "rocket" launcher? 

Danke & Gr??e von nobi

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40253>
_______________________________________

From report at bugs.python.org  Sat Apr 11 09:49:19 2020
From: report at bugs.python.org (Eryk Sun)
Date: Sat, 11 Apr 2020 13:49:19 +0000
Subject: [issue40253] Fix .py(w) file association with Pyhon 3 Windows
 installer
In-Reply-To: <1586590189.16.0.270400617976.issue40253@roundup.psfhosted.org>
Message-ID: <1586612959.0.0.220541220099.issue40253@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> How do I get to the "rocket" launcher? 

The py.exe launcher is installed by default with the Python 3 distribution from python.org. Did you install that, or did you install the app distribution from the Microsoft Store?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40253>
_______________________________________

From report at bugs.python.org  Sat Apr 11 11:13:24 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 11 Apr 2020 15:13:24 +0000
Subject: [issue40246] Different error messages for same error - invalid string
 prefixes
In-Reply-To: <1586605586.68.0.782490466179.issue40246@roundup.psfhosted.org>
Message-ID: <CAP7+vJJhV7WDbdUkrq-PYuzjdYKy4XEs2Xwit1wv_DZvdd=SVw@mail.gmail.com>


Guido van Rossum <guido at python.org> added the comment:

yes

On Sat, Apr 11, 2020 at 04:46 Lysandros Nikolaou <report at bugs.python.org>
wrote:

>
> Lysandros Nikolaou <lisandrosnik at gmail.com> added the comment:
>
> I have working code that checks if there is a quotation mark right after
> an identifier. Here is an example:
>
> ?? ./python
> Python 3.9.0a5+ (heads/pegen-dirty:502dfb719e, Apr 11 2020, 14:43:12)
> [GCC 9.2.1 20191008] on linux
> Type "help", "copyright", "credits" or "license" for more information.
> >>> ur''
>   File "<stdin>", line 1
>     ur''
>      ^
> SyntaxError: invalid string prefix
>
> One observation about this is that it has precedence over an EOL error:
>
> >>> ur'
>   File "<stdin>", line 1
>     ur'
>      ^
> SyntaxError: invalid string prefix
>
> Would that be acceptable?
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue40246>
> _______________________________________
>
-- 
--Guido (mobile)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40246>
_______________________________________

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: [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 12:51:07 2020
From: report at bugs.python.org (Eddie Elizondo)
Date: Sat, 11 Apr 2020 16:51:07 +0000
Subject: [issue40255] Fixing Copy on Writes from reference counting
In-Reply-To: <1586619621.82.0.553262088399.issue40255@roundup.psfhosted.org>
Message-ID: <1586623867.99.0.996168489267.issue40255@roundup.psfhosted.org>


Change by Eddie Elizondo <eduardo.elizondorueda at gmail.com>:


----------
keywords: +patch
pull_requests: +18829
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19474

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40255>
_______________________________________

From report at bugs.python.org  Sat Apr 11 13:48:16 2020
From: report at bugs.python.org (Lysandros Nikolaou)
Date: Sat, 11 Apr 2020 17:48:16 +0000
Subject: [issue40246] Different error messages for same error - invalid string
 prefixes
In-Reply-To: <1586541958.33.0.891000303304.issue40246@roundup.psfhosted.org>
Message-ID: <1586627296.18.0.351001086953.issue40246@roundup.psfhosted.org>


Change by Lysandros Nikolaou <lisandrosnik at gmail.com>:


----------
keywords: +patch
pull_requests: +18830
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19476

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40246>
_______________________________________

From report at bugs.python.org  Sat Apr 11 14:01:03 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sat, 11 Apr 2020 18:01:03 +0000
Subject: [issue40255] Fixing Copy on Writes from reference counting
In-Reply-To: <1586619621.82.0.553262088399.issue40255@roundup.psfhosted.org>
Message-ID: <1586628063.74.0.581002164706.issue40255@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
nosy: +nascheme, pitrou, tim.peters

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40255>
_______________________________________

From report at bugs.python.org  Sat Apr 11 14:03:35 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Sat, 11 Apr 2020 18:03:35 +0000
Subject: [issue40255] Fixing Copy on Writes from reference counting
In-Reply-To: <1586619621.82.0.553262088399.issue40255@roundup.psfhosted.org>
Message-ID: <1586628215.3.0.0859856438215.issue40255@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
nosy: +pablogsal

_______________________________________
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: [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 14:05:17 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Sat, 11 Apr 2020 18:05:17 +0000
Subject: [issue40221] Use new _at_fork_reinit() lock method in multiprocessing
In-Reply-To: <1586300633.14.0.457029058496.issue40221@roundup.psfhosted.org>
Message-ID: <1586628317.84.0.775042713476.issue40221@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
keywords: +patch
pull_requests: +18831
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19477

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40221>
_______________________________________

From report at bugs.python.org  Sat Apr 11 14:08:22 2020
From: report at bugs.python.org (SilentGhost)
Date: Sat, 11 Apr 2020 18:08:22 +0000
Subject: [issue40256] Python 3.8 Not Launching on Bootcamp Windows 10.
In-Reply-To: <1586628271.16.0.0390251857061.issue40256@roundup.psfhosted.org>
Message-ID: <1586628502.27.0.359768295491.issue40256@roundup.psfhosted.org>


Change by SilentGhost <ghost.adh at runbox.com>:


----------
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40256>
_______________________________________

From report at bugs.python.org  Sat Apr 11 16:36:27 2020
From: report at bugs.python.org (miss-islington)
Date: Sat, 11 Apr 2020 20:36:27 +0000
Subject: [issue39953] Let's update ssl error codes
In-Reply-To: <1584072470.83.0.437860249809.issue39953@roundup.psfhosted.org>
Message-ID: <1586637387.37.0.0879210884113.issue39953@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
nosy: +miss-islington
nosy_count: 7.0 -> 8.0
pull_requests: +18832
pull_request: https://github.com/python/cpython/pull/19478

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39953>
_______________________________________

From report at bugs.python.org  Sat Apr 11 16:36:18 2020
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 11 Apr 2020 20:36:18 +0000
Subject: [issue39953] Let's update ssl error codes
In-Reply-To: <1584072470.83.0.437860249809.issue39953@roundup.psfhosted.org>
Message-ID: <1586637378.74.0.212141297007.issue39953@roundup.psfhosted.org>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset 3e0dd3730b5eff7e9ae6fb921aa77cd26efc9e3a by Benjamin Peterson in branch 'master':
closes bpo-39953: Update OpenSSL error codes table. (GH-19082)
https://github.com/python/cpython/commit/3e0dd3730b5eff7e9ae6fb921aa77cd26efc9e3a


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39953>
_______________________________________

From report at bugs.python.org  Sat Apr 11 16:53:06 2020
From: report at bugs.python.org (miss-islington)
Date: Sat, 11 Apr 2020 20:53:06 +0000
Subject: [issue39953] Let's update ssl error codes
In-Reply-To: <1584072470.83.0.437860249809.issue39953@roundup.psfhosted.org>
Message-ID: <1586638386.76.0.383350129644.issue39953@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 2714c907df7cfe97911df6ce90364001270d9a43 by Miss Islington (bot) in branch '3.8':
closes bpo-39953: Update OpenSSL error codes table. (GH-19082)
https://github.com/python/cpython/commit/2714c907df7cfe97911df6ce90364001270d9a43


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39953>
_______________________________________

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: [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 16:56:54 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 11 Apr 2020 20:56:54 +0000
Subject: [issue40257] Improve the use of __doc__ in pydoc
In-Reply-To: <1586638478.83.0.463728061154.issue40257@roundup.psfhosted.org>
Message-ID: <1586638614.49.0.42503926084.issue40257@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch
pull_requests: +18833
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19479

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40257>
_______________________________________

From report at bugs.python.org  Sat Apr 11 17:17:43 2020
From: report at bugs.python.org (SilentGhost)
Date: Sat, 11 Apr 2020 21:17:43 +0000
Subject: [issue39951] Ignore specific errors when closing ssl connections
In-Reply-To: <1584070801.03.0.867475481059.issue39951@roundup.psfhosted.org>
Message-ID: <1586639863.41.0.573355041855.issue39951@roundup.psfhosted.org>


Change by SilentGhost <ghost.adh at runbox.com>:


----------
nosy: +christian.heimes

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39951>
_______________________________________

From report at bugs.python.org  Sat Apr 11 18:37:58 2020
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 11 Apr 2020 22:37:58 +0000
Subject: [issue40255] Fixing Copy on Writes from reference counting
In-Reply-To: <1586619621.82.0.553262088399.issue40255@roundup.psfhosted.org>
Message-ID: <1586644678.08.0.0845575954584.issue40255@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:

Thanks for sharing!  It's good to have a patch implementing for others who might need it to try out.

We experimented with an implementation of this on CPython 2.7 that we called Eternal Refcounts for YouTube many years ago.  For the same reason (saving memory in forked workers by not dirtying pages of known needed objects via refcount changes).

I don't have that old patch handy right now, but looking at yours it was the same concept: A magic refcount value to branch based on.

We wound up not deploying it or pushing for it in CPython because the CPU performance implications of adding a branch instruction to Py_INCREC and Py_DECREF were, unsurprisingly, quite high.  I'd have to go digging to find numbers but it _believe_ it was on the order of a 10% slowdown on real world application code.  (microbenchmarks don't tell a good story, the python performance test suite should)

Given that most people's applications don't fork workers, I do not expect to see such an implementation ever become the default.  It is a very appropriate hack, but the use case is limited to applications that don't use threads, are on POSIX, and always fork() many workers.

Also note that this is an ABI change as those INCREF and DECREF definitions are intentionally public .h file macros or inlines and thus included within any compiledcode rather than being an expensive function call elsewhere (vstinner's new alternate higher level API proposal presumably changes this).  If an interpreter with this loaded a binary using the CPython API built against headers without it, your refcounts could get messed up.

----------
nosy: +gregory.p.smith
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40255>
_______________________________________

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: [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  Sat Apr 11 19:21:54 2020
From: report at bugs.python.org (Barry McLarnon)
Date: Sat, 11 Apr 2020 23:21:54 +0000
Subject: [issue40126] Incorrect error handling in unittest.mock
In-Reply-To: <1585670844.45.0.631660598637.issue40126@roundup.psfhosted.org>
Message-ID: <1586647314.17.0.679051315147.issue40126@roundup.psfhosted.org>


Barry McLarnon <bmclarnon at hotmail.co.uk> added the comment:

Issue still exists in 3.7 and below, as it was part of a different function before. Current PR doesn't resolve the original issue that was raised.

----------
versions: +Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40126>
_______________________________________

From report at bugs.python.org  Sat Apr 11 19:22:43 2020
From: report at bugs.python.org (Nik Vaessen)
Date: Sat, 11 Apr 2020 23:22:43 +0000
Subject: [issue40258] random module does not have type hints
Message-ID: <1586647363.11.0.104306324188.issue40258@roundup.psfhosted.org>


Change by Nik Vaessen <nik at vaessen.tech>:


----------
keywords: +patch
pull_requests: +18834
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19480

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40258>
_______________________________________

From report at bugs.python.org  Sat Apr 11 19:45:36 2020
From: report at bugs.python.org (Ammar Askar)
Date: Sat, 11 Apr 2020 23:45:36 +0000
Subject: [issue40218] sys.executable is a false path if python is executed
 from gdb
In-Reply-To: <1586290599.79.0.960995339825.issue40218@roundup.psfhosted.org>
Message-ID: <1586648736.09.0.896106459803.issue40218@roundup.psfhosted.org>


Ammar Askar <ammar at ammaraskar.com> added the comment:

The reason you're seeing gdb still work even when all Pythons are deleted is because it embeds a Python interpreter in itself (https://docs.python.org/3/extending/embedding.html).

This issue is thus out of scope here and belongs on the gdb tracker, but I can tell you it's caused by these lines: https://github.com/bminor/binutils-gdb/blob/de7ac122a7f98c181c1ec175b0560bb48eabc6ea/gdb/python/python.c#L1668-L1694

The Py_SetProgramName() is what informs the sys.executable value.

----------
nosy: +ammar2

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40218>
_______________________________________

From report at bugs.python.org  Sat Apr 11 19:50:38 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 11 Apr 2020 23:50:38 +0000
Subject: [issue40218] sys.executable is a false path if python is executed
 from gdb
In-Reply-To: <1586290599.79.0.960995339825.issue40218@roundup.psfhosted.org>
Message-ID: <1586649038.06.0.221328595518.issue40218@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
resolution:  -> third party
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40218>
_______________________________________

From report at bugs.python.org  Sat Apr 11 21:01:33 2020
From: report at bugs.python.org (Eddie Elizondo)
Date: Sun, 12 Apr 2020 01:01:33 +0000
Subject: [issue40255] Fixing Copy on Writes from reference counting
In-Reply-To: <1586619621.82.0.553262088399.issue40255@roundup.psfhosted.org>
Message-ID: <1586653293.47.0.652328879867.issue40255@roundup.psfhosted.org>


Eddie Elizondo <eduardo.elizondorueda at gmail.com> added the comment:

> the CPU performance implications of adding a branch instruction to Py_INCREC and Py_DECREF were, unsurprisingly, quite high.

Yeah, makes sense. I guess it really depends on the specific profile of your application.

For Instagram this was an overall net positive change and we still have it in prod. The amount of page faults from Copy on Writes was so large that reducing it resulted in a net CPU win (even with the added branching). And of course, a huge reduction in memory usage.


> Microbenchmarks don't tell a good story, the python performance test suite should

Agreed. I only added the Richards benchmark as a reference. I'm hoping someone can pick it up and have more concrete numbers on an average Python workload.


> Given that most people's applications don't fork workers, I do not expect to see such an implementation ever become the default.

In any case, I gated this change with ifdefs. In case we don't have it by default, we can always can easily enable it with a simple `-DPy_IMMORTAL_INSTANCES` flag to the compiler.

> Also note that this is an ABI change as those INCREF and DECREF definitions are intentionally public .h file

This has indeed been a bit of a pain for us as well. Due to how our tooling is set-up, there's a small number of third party libraries that are still causing Copy on Writes. Fortunately, that's the only drawback. Even if your immortalized object goes through an extension that has a different Py_{DECREF,INCREF} implementation, the reference count will still be so large that it will never be deallocated.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40255>
_______________________________________

From report at bugs.python.org  Sat Apr 11 21:28:26 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 12 Apr 2020 01:28:26 +0000
Subject: [issue40258] random module does not have type hints
Message-ID: <1586654906.76.0.704163967514.issue40258@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
resolution:  -> rejected
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40258>
_______________________________________

From report at bugs.python.org  Sun Apr 12 01:16:07 2020
From: report at bugs.python.org (=?utf-8?b?VmVkcmFuIMSMYcSNacSH?=)
Date: Sun, 12 Apr 2020 05:16:07 +0000
Subject: [issue40257] Improve the use of __doc__ in pydoc
In-Reply-To: <1586638478.83.0.463728061154.issue40257@roundup.psfhosted.org>
Message-ID: <1586668567.45.0.510309162163.issue40257@roundup.psfhosted.org>


Vedran ?a?i? <vedgar at gmail.com> added the comment:

I don't agree with 1. I use that feature a lot, I write a base class which my students must subclass to their liking, but they still expect that help(TheirClass) will give them the documentation they need.

I agree that in _some_ cases it is not helpful (but even when the base is abstract, it might be helpful). How about: we keep the current behavior, but make it clear that the docstring applies to a superclass? It might be subtle, as just changing the first line of help() output (currently it says "Help on class Derived in module ...", change it to "Help on class Base in module ..."), or write a longer message such as "Documentation for Derived not found, showing the documentation for Base". But just removing it in all cases is really a wrong thing to do.

----------
nosy: +veky

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40257>
_______________________________________

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: [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:03:36 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 12 Apr 2020 08:03:36 +0000
Subject: [issue40259] re.Scanner groups
Message-ID: <1586678616.71.0.822734616794.issue40259@roundup.psfhosted.org>


New submission from Karthikeyan Singaravelan <tir.karthi at gmail.com>:

Please add a description of the issue you are facing with a simple script of the behavior.

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40259>
_______________________________________

From report at bugs.python.org  Sun Apr 12 04:07:40 2020
From: report at bugs.python.org (Dennis Chronopoulos)
Date: Sun, 12 Apr 2020 08:07:40 +0000
Subject: [issue40259] re.Scanner groups
In-Reply-To: <1586678616.71.0.822734616794.issue40259@roundup.psfhosted.org>
Message-ID: <1586678860.79.0.959020048258.issue40259@roundup.psfhosted.org>


Change by Dennis Chronopoulos <denchron at gmail.com>:


Added file: https://bugs.python.org/file49049/re.Scanner.txt

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40259>
_______________________________________

From report at bugs.python.org  Sun Apr 12 04:37:01 2020
From: report at bugs.python.org (Barry Alan Scott)
Date: Sun, 12 Apr 2020 08:37:01 +0000
Subject: [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 04:38:21 2020
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Sun, 12 Apr 2020 08:38:21 +0000
Subject: [issue40257] Improve the use of __doc__ in pydoc
In-Reply-To: <1586638478.83.0.463728061154.issue40257@roundup.psfhosted.org>
Message-ID: <1586680701.08.0.535804970285.issue40257@roundup.psfhosted.org>


Ivan Levkivskyi <levkivskyi at gmail.com> added the comment:

FWIW I like the idea. There are many objects in typing module that are not classes, it would be great to display docs for them.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40257>
_______________________________________

From report at bugs.python.org  Sun Apr 12 04:43:10 2020
From: report at bugs.python.org (hai shi)
Date: Sun, 12 Apr 2020 08:43:10 +0000
Subject: [issue39953] Let's update ssl error codes
In-Reply-To: <1584072470.83.0.437860249809.issue39953@roundup.psfhosted.org>
Message-ID: <1586680990.8.0.887079027576.issue39953@roundup.psfhosted.org>


hai shi <shihai1991 at 126.com> added the comment:

Got some compiling error of _ssl extension module in my vm after PR19082 merged:
building '_ssl' extension
gcc -pthread -Wno-unused-result -Wsign-compare -g -Og -Wall -fPIC -I./Include -I. -I/usr/local/include -I/temp/shihai/cpython/Include -I/temp/shihai/cpython -c /temp/shihai/cpython/Modules/_ssl.c -o build/temp.linux-x86_64-3.9-pydebug/temp/shihai/cpython/Modules/_ssl.o
In file included from /temp/shihai/cpython/Modules/_ssl.c:136:
/temp/shihai/cpython/Modules/_ssl_data.h:6:15: error: ?ERR_LIB_ASYNC? undeclared here (not in a function); did you mean ?ERR_LIB_ASN1??
    6 |     {"ASYNC", ERR_LIB_ASYNC},
      |               ^~~~~~~~~~~~~
      |               ERR_LIB_ASN1
/temp/shihai/cpython/Modules/_ssl_data.h:13:12: error: ?ERR_LIB_CT? undeclared here (not in a function); did you mean ?ERR_LIB_CMS??
   13 |     {"CT", ERR_LIB_CT},
      |            ^~~~~~~~~~
      |            ERR_LIB_CMS
/temp/shihai/cpython/Modules/_ssl_data.h:19:13: error: ?ERR_LIB_KDF? undeclared here (not in a function); did you mean ?ERR_LIB_BUF??
   19 |     {"KDF", ERR_LIB_KDF},
      |             ^~~~~~~~~~~
      |             ERR_LIB_BUF
In file included from /temp/shihai/cpython/Modules/_ssl.c:136:
/temp/shihai/cpython/Modules/_ssl_data.h:598:28: warning: initialization of ?int? from ?struct py_ssl_library_code *? makes integer from pointer without a cast [-Wint-conversion]
  598 |     {"FAILED_TO_SET_POOL", ERR_LIB_ASYNC, 101},
      |                            ^~~~~~~~~~~~~
/temp/shihai/cpython/Modules/_ssl_data.h:598:28: note: (near initialization for ?error_codes[112].library?)
/temp/shihai/cpython/Modules/_ssl_data.h:598:28: error: initializer element is not constant
/temp/shihai/cpython/Modules/_ssl_data.h:598:28: note: (near initialization for ?error_codes[112].library?)
/temp/shihai/cpython/Modules/_ssl_data.h:603:32: warning: initialization of ?int? from ?struct py_ssl_library_code *? makes integer from pointer without a cast [-Wint-conversion]
  603 |     {"FAILED_TO_SWAP_CONTEXT", ERR_LIB_ASYNC, 102},

----------
nosy: +shihai1991

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39953>
_______________________________________

From report at bugs.python.org  Sun Apr 12 05:27:19 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 12 Apr 2020 09:27:19 +0000
Subject: [issue40257] Improve the use of __doc__ in pydoc
In-Reply-To: <1586638478.83.0.463728061154.issue40257@roundup.psfhosted.org>
Message-ID: <1586683639.13.0.935800516029.issue40257@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Inheritance of docstrings was added in issue15582. It works good for class members, but I now realized that doing it for class itself was a mistake. For example:

>>> import wave
>>> help(wave.Error)
Help on class Error in module wave:

class Error(builtins.Exception)
 |  Common base class for all non-exit exceptions.
 |  
 |  Method resolution order:
 |      Error
 |      builtins.Exception
 |      builtins.BaseException
 |      builtins.object
 |  
...

I fixed many similar issues by adding docstrings to classes, but there are even more exception classes and other classes in the stdlib for which help() gives incorrect description. I don't remember a single case when inheritance of the docstring was helpful.

Note that help() outputs the list of base class right after the docstring, so it is not hard to give an additional information, especially in interactive browser mode. If you want to inherit a docstring, you can do it explicitly:

    __doc__ = BaseClass.__doc__

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40257>
_______________________________________

From report at bugs.python.org  Sun Apr 12 06:19:28 2020
From: report at bugs.python.org (SilentGhost)
Date: Sun, 12 Apr 2020 10:19:28 +0000
Subject: [issue40260] modulefinder traceback regression starting on Windows
In-Reply-To: <1586680620.99.0.514402715757.issue40260@roundup.psfhosted.org>
Message-ID: <1586686768.38.0.386570011427.issue40260@roundup.psfhosted.org>


Change by SilentGhost <ghost.adh at runbox.com>:


----------
nosy: +brandtbucher
stage:  -> needs patch
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40260>
_______________________________________

From report at bugs.python.org  Sun Apr 12 06:49:41 2020
From: report at bugs.python.org (virtualnobi)
Date: Sun, 12 Apr 2020 10:49:41 +0000
Subject: [issue40253] Fix .py(w) file association with Pyhon 3 Windows
 installer
In-Reply-To: <1586590189.16.0.270400617976.issue40253@roundup.psfhosted.org>
Message-ID: <1586688581.21.0.407642607395.issue40253@roundup.psfhosted.org>


virtualnobi <virtualnobi at zoho.com> added the comment:

Eryk, I installed from python.org (didn't even know that it would be available from Microsoft Store). 

Nevertheless, I don't find py.exe. Should it be installed besides python.exe? If not, where else? 

I understand that py.exe is at least in part used to make handling multiple python versions easier. As I planned to only have one version (which might have been a bad idea in hindsight :-(  I might have unchecked any option that sounded like this... 

Danke & Gr??e von nobi

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40253>
_______________________________________

From report at bugs.python.org  Sun Apr 12 06:58:55 2020
From: report at bugs.python.org (hai shi)
Date: Sun, 12 Apr 2020 10:58:55 +0000
Subject: [issue40221] Use new _at_fork_reinit() lock method in multiprocessing
In-Reply-To: <1586300633.14.0.457029058496.issue40221@roundup.psfhosted.org>
Message-ID: <1586689135.11.0.0231755374012.issue40221@roundup.psfhosted.org>


Change by hai shi <shihai1991 at 126.com>:


----------
nosy: +shihai1991

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40221>
_______________________________________

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: [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 07:05:39 2020
From: report at bugs.python.org (Ruben)
Date: Sun, 12 Apr 2020 11:05:39 +0000
Subject: [issue40261] Build of Python where make is called from subprocess,
 within a virtualenv, breaks on macOS
In-Reply-To: <1586689461.86.0.934526151918.issue40261@roundup.psfhosted.org>
Message-ID: <1586689539.23.0.404806029426.issue40261@roundup.psfhosted.org>


Change by Ruben <rubendibattista at gmail.com>:


Added file: https://bugs.python.org/file49051/make.py.venv2.log.gz

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40261>
_______________________________________

From report at bugs.python.org  Sun Apr 12 07:06:32 2020
From: report at bugs.python.org (Ruben)
Date: Sun, 12 Apr 2020 11:06:32 +0000
Subject: [issue40261] Build of Python where make is called from subprocess,
 within a virtualenv, breaks on macOS
In-Reply-To: <1586689461.86.0.934526151918.issue40261@roundup.psfhosted.org>
Message-ID: <1586689592.43.0.30632270931.issue40261@roundup.psfhosted.org>


Change by Ruben <rubendibattista at gmail.com>:


Added file: https://bugs.python.org/file49052/make.venv.log.gz

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40261>
_______________________________________

From report at bugs.python.org  Sun Apr 12 07:06:57 2020
From: report at bugs.python.org (Ruben)
Date: Sun, 12 Apr 2020 11:06:57 +0000
Subject: [issue40261] Build of Python where make is called from subprocess,
 within a virtualenv, breaks on macOS
In-Reply-To: <1586689461.86.0.934526151918.issue40261@roundup.psfhosted.org>
Message-ID: <1586689617.6.0.0198796367745.issue40261@roundup.psfhosted.org>


Change by Ruben <rubendibattista at gmail.com>:


Added file: https://bugs.python.org/file49053/make.log.gz

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40261>
_______________________________________

From report at bugs.python.org  Sun Apr 12 07:07:32 2020
From: report at bugs.python.org (Ruben)
Date: Sun, 12 Apr 2020 11:07:32 +0000
Subject: [issue40261] Build of Python where make is called from subprocess,
 within a virtualenv, breaks on macOS
In-Reply-To: <1586689461.86.0.934526151918.issue40261@roundup.psfhosted.org>
Message-ID: <1586689652.23.0.494368379741.issue40261@roundup.psfhosted.org>


Change by Ruben <rubendibattista at gmail.com>:


Added file: https://bugs.python.org/file49054/make.venv.log.gz

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40261>
_______________________________________

From report at bugs.python.org  Sun Apr 12 07:14:44 2020
From: report at bugs.python.org (Ruben)
Date: Sun, 12 Apr 2020 11:14:44 +0000
Subject: [issue40261] Build of Python where make is called from subprocess,
 within a virtualenv, breaks on macOS
In-Reply-To: <1586689461.86.0.934526151918.issue40261@roundup.psfhosted.org>
Message-ID: <1586690084.24.0.127142094395.issue40261@roundup.psfhosted.org>


Ruben <rubendibattista at gmail.com> added the comment:

Sorry, the error was missing, well, the actual 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
running build
running build_ext
error: [Errno 2] No such file or directory: '/usr/local/include/python3.8/pyconfig.h'
```

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40261>
_______________________________________

From report at bugs.python.org  Sun Apr 12 07:18:29 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 12 Apr 2020 11:18:29 +0000
Subject: [issue40126] Incorrect error handling in unittest.mock
In-Reply-To: <1585670844.45.0.631660598637.issue40126@roundup.psfhosted.org>
Message-ID: <1586690309.63.0.876495789485.issue40126@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +18835
pull_request: https://github.com/python/cpython/pull/19483

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40126>
_______________________________________

From report at bugs.python.org  Sun Apr 12 07:22:13 2020
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 12 Apr 2020 11:22:13 +0000
Subject: [issue39953] Let's update ssl error codes
In-Reply-To: <1584072470.83.0.437860249809.issue39953@roundup.psfhosted.org>
Message-ID: <1586690533.34.0.571350480854.issue39953@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

The PR broke backwards compatibility with OpenSSL 1.0.2 and LibreSSL. OpenSSL 1.1.x introduced new error codes or reused existing numbers for different errors codes.

Although OpenSSL 1.0.2 has reached EOL we should keep keep Python 3.8 and 3.9 compatible with the API.

----------
nosy: +lukasz.langa
priority: normal -> release blocker
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39953>
_______________________________________

From report at bugs.python.org  Sun Apr 12 07:26:15 2020
From: report at bugs.python.org (hai shi)
Date: Sun, 12 Apr 2020 11:26:15 +0000
Subject: [issue37985] WFERR_UNMARSHALLABLE breaks recursion limit
In-Reply-To: <1567123477.95.0.275651611674.issue37985@roundup.psfhosted.org>
Message-ID: <1586690775.76.0.943324353115.issue37985@roundup.psfhosted.org>


Change by hai shi <shihai1991 at 126.com>:


----------
keywords: +patch
nosy: +shihai1991
nosy_count: 2.0 -> 3.0
pull_requests: +18836
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19482

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37985>
_______________________________________

From report at bugs.python.org  Sun Apr 12 07:31:56 2020
From: report at bugs.python.org (hai shi)
Date: Sun, 12 Apr 2020 11:31:56 +0000
Subject: [issue37985] WFERR_UNMARSHALLABLE breaks recursion limit
In-Reply-To: <1567123477.95.0.275651611674.issue37985@roundup.psfhosted.org>
Message-ID: <1586691116.29.0.399738632994.issue37985@roundup.psfhosted.org>


hai shi <shihai1991 at 126.com> added the comment:

If I understand correctly, `p->depth--` associated with `p->error` could be removed?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37985>
_______________________________________

From report at bugs.python.org  Sun Apr 12 07:36:08 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 12 Apr 2020 11:36:08 +0000
Subject: [issue40126] Incorrect error handling in unittest.mock
In-Reply-To: <1585670844.45.0.631660598637.issue40126@roundup.psfhosted.org>
Message-ID: <1586691368.64.0.861395337509.issue40126@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +18837
pull_request: https://github.com/python/cpython/pull/19484

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40126>
_______________________________________

From report at bugs.python.org  Sun Apr 12 07:45:28 2020
From: report at bugs.python.org (Eryk Sun)
Date: Sun, 12 Apr 2020 11:45:28 +0000
Subject: [issue40253] Fix .py(w) file association with Pyhon 3 Windows
 installer
In-Reply-To: <1586590189.16.0.270400617976.issue40253@roundup.psfhosted.org>
Message-ID: <1586691928.53.0.936655040884.issue40253@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> I understand that py.exe is at least in part used to make handling 
> multiple python versions easier. 

On the command line the launcher supports multiple installed versions via the "-X[.Y][-32|-64]" option. In scripts it supports multiple versions via virtual shebangs, e.g. "#!python3.8-32". But shebangs can also use fully-qualified Windows paths, which allows directly running a script in a particular virtual environment, e.g. "#!C:\VEnv\SparkEnv\Scripts\python.exe". Without the launcher, the .py file association is locked on a single Python installation.

> I don't find py.exe. Should it be installed besides python.exe? 
> If not, where else? 

If installed for all users, the py launcher is in the Windows directory. Otherwise it's in the user's local application data in the directory "%LocalAppData%\Programs\Python\Launcher".

Try repairing the installation to ensure the py launcher is installed, preferably for all users if you have admin access.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40253>
_______________________________________

From report at bugs.python.org  Sun Apr 12 07:45:39 2020
From: report at bugs.python.org (=?utf-8?q?Adam_Barto=C5=A1?=)
Date: Sun, 12 Apr 2020 11:45:39 +0000
Subject: [issue11395] print(s) fails on Windows with long strings
In-Reply-To: <1299217663.52.0.355409591746.issue11395@psf.upfronthosting.co.za>
Message-ID: <1586691939.37.0.664502589991.issue11395@roundup.psfhosted.org>


Adam Barto? <drekin at gmail.com> added the comment:

I've been hit by this issue recently. On my configuration, print("a" * 10215) fails with an infinite loop of OSErrors (WinError 8). This even cannot by interrupted with Ctrl-C nor the exception can be catched.

- print("a" * 10214) is fine
- print("a" * 10215) is fine when preceeded by print("b" * 2701), but not when preceeded by print("b" * 2700)
- the problem (or at least with these numbers) occurs only when the code is saved in a script, and this is run by double-clicking the file (i.e. run by Windows ShellExecute I guess), not by "py test.py" or interactively.

My configuration is Python 3.7.3 64 bit on Windows Vista 64 bit. I wonder if anyone is able to reproduce this on their configuration.

----------
nosy: +Drekin

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue11395>
_______________________________________

From report at bugs.python.org  Sun Apr 12 07:53:49 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 12 Apr 2020 11:53:49 +0000
Subject: [issue40126] Incorrect error handling in unittest.mock
In-Reply-To: <1585670844.45.0.631660598637.issue40126@roundup.psfhosted.org>
Message-ID: <1586692429.87.0.0705745132183.issue40126@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset ee249d798ba08f065efbf4f450880a446c6ca49d by Serhiy Storchaka in branch '3.8':
[3.8] bpo-40126: Fix reverting multiple patches in unittest.mock. (GH-19351) (GH-19483)
https://github.com/python/cpython/commit/ee249d798ba08f065efbf4f450880a446c6ca49d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40126>
_______________________________________

From report at bugs.python.org  Sun Apr 12 07:54:06 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 12 Apr 2020 11:54:06 +0000
Subject: [issue40126] Incorrect error handling in unittest.mock
In-Reply-To: <1585670844.45.0.631660598637.issue40126@roundup.psfhosted.org>
Message-ID: <1586692446.52.0.260292153365.issue40126@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 4057e8f9b56789223a1e691d7601003aceb84ad1 by Serhiy Storchaka in branch '3.7':
[3.7] bpo-40126: Fix reverting multiple patches in unittest.mock. (GH-19351) (GH-19484)
https://github.com/python/cpython/commit/4057e8f9b56789223a1e691d7601003aceb84ad1


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40126>
_______________________________________

From report at bugs.python.org  Sun Apr 12 07:57:17 2020
From: report at bugs.python.org (Cajetan Rodrigues)
Date: Sun, 12 Apr 2020 11:57:17 +0000
Subject: [issue40065] py39: remove deprecation note for xml.etree.cElementTree
In-Reply-To: <1585163379.04.0.795433622529.issue40065@roundup.psfhosted.org>
Message-ID: <1586692637.34.0.517781271366.issue40065@roundup.psfhosted.org>


Cajetan Rodrigues <caje731 at gmail.com> added the comment:

For the record, I submitted a fix to the dependent:

https://github.com/boto/botocore/pull/2015

----------
nosy: +Cajetan Rodrigues

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40065>
_______________________________________

From report at bugs.python.org  Sun Apr 12 07:57:36 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 12 Apr 2020 11:57:36 +0000
Subject: [issue40126] Incorrect error handling in unittest.mock
In-Reply-To: <1585670844.45.0.631660598637.issue40126@roundup.psfhosted.org>
Message-ID: <1586692656.11.0.395400864833.issue40126@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

3.5 and 3.6 are in security fixes only mode, and this issue is not a security issue. After merging PR 19484 I cannot reproduce the original issue anymore.

I left this issue open for the case if I find a way to write tests for the merged changes.

----------
versions:  -Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40126>
_______________________________________

From report at bugs.python.org  Sun Apr 12 07:58:30 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 12 Apr 2020 11:58:30 +0000
Subject: [issue39943] Meta: Clean up various issues in C internals
In-Reply-To: <1583983387.49.0.277830283994.issue39943@roundup.psfhosted.org>
Message-ID: <1586692710.46.0.670717413852.issue39943@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 8f87eefe7f0576c05c488874eb9601a7a87c7312 by Serhiy Storchaka in branch 'master':
bpo-39943: Add the const qualifier to pointers on non-mutable PyBytes data. (GH-19472)
https://github.com/python/cpython/commit/8f87eefe7f0576c05c488874eb9601a7a87c7312


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39943>
_______________________________________

From report at bugs.python.org  Sun Apr 12 08:25:29 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Sun, 12 Apr 2020 12:25:29 +0000
Subject: [issue37985] WFERR_UNMARSHALLABLE breaks recursion limit
In-Reply-To: <1567123477.95.0.275651611674.issue37985@roundup.psfhosted.org>
Message-ID: <1586694329.46.0.916331340689.issue37985@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
versions:  -Python 2.7, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37985>
_______________________________________

From report at bugs.python.org  Sun Apr 12 08:35:30 2020
From: report at bugs.python.org (Eryk Sun)
Date: Sun, 12 Apr 2020 12:35:30 +0000
Subject: [issue11395] print(s) fails on Windows with long strings
In-Reply-To: <1299217663.52.0.355409591746.issue11395@psf.upfronthosting.co.za>
Message-ID: <1586694930.89.0.613828306104.issue11395@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> the problem (or at least with these numbers) occurs only when 
> the code is saved in a script, and this is run by double-
> clicking the file

The .py file association is probably using a different version of Python, or it's associated with the py launcher and there's a shebang in the file that runs 2.7. Verify the version that's executing the script. If it's running in 3.7, follow up in a new issue or on python-list. Please do not follow up on this resolved issue. Also, please try to reproduce the issue on a supported, updated system. Windows Vista is not supported by 3.7, and the latest 3.7 release is 3.7.7.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue11395>
_______________________________________

From report at bugs.python.org  Sun Apr 12 08:52:18 2020
From: report at bugs.python.org (Stefan Behnel)
Date: Sun, 12 Apr 2020 12:52:18 +0000
Subject: [issue39011] ElementTree attributes replace "\r" with "\n"
In-Reply-To: <1575934850.24.0.848331688216.issue39011@roundup.psfhosted.org>
Message-ID: <1586695938.05.0.0582892625776.issue39011@roundup.psfhosted.org>


Stefan Behnel <stefan_ml at behnel.de> added the comment:


New changeset 5fd8123dfdf6df0a9c29363c8327ccfa0c1d41ac by mefistotelis in branch 'master':
bpo-39011: Preserve line endings within ElementTree attributes (GH-18468)
https://github.com/python/cpython/commit/5fd8123dfdf6df0a9c29363c8327ccfa0c1d41ac


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39011>
_______________________________________

From report at bugs.python.org  Sun Apr 12 08:52:57 2020
From: report at bugs.python.org (Stefan Behnel)
Date: Sun, 12 Apr 2020 12:52:57 +0000
Subject: [issue39011] ElementTree attributes replace "\r" with "\n"
In-Reply-To: <1575934850.24.0.848331688216.issue39011@roundup.psfhosted.org>
Message-ID: <1586695977.76.0.345993923319.issue39011@roundup.psfhosted.org>


Change by Stefan Behnel <stefan_ml at behnel.de>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39011>
_______________________________________

From report at bugs.python.org  Sun Apr 12 08:55:44 2020
From: report at bugs.python.org (Stefan Behnel)
Date: Sun, 12 Apr 2020 12:55:44 +0000
Subject: [issue17582] xml.etree.ElementTree does not preserve whitespaces in
 attributes
In-Reply-To: <1364660794.69.0.883579635559.issue17582@psf.upfronthosting.co.za>
Message-ID: <1586696144.29.0.93185342789.issue17582@roundup.psfhosted.org>


Stefan Behnel <stefan_ml at behnel.de> added the comment:

Also see the later fix in issue 39011, where the EOL normalisation in attribute text was removed again. This change was applied in Py3.9.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17582>
_______________________________________

From report at bugs.python.org  Sun Apr 12 09:18:55 2020
From: report at bugs.python.org (Zackery Spytz)
Date: Sun, 12 Apr 2020 13:18:55 +0000
Subject: [issue24341] Test suite emits many DeprecationWarnings about
 sys.exc_clear() when -3 is enabled
In-Reply-To: <1433098290.5.0.721765999777.issue24341@psf.upfronthosting.co.za>
Message-ID: <1586697535.6.0.107832810614.issue24341@roundup.psfhosted.org>


Zackery Spytz <zspytz at gmail.com> added the comment:

Python 2 is EOL.

----------
nosy: +ZackerySpytz

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24341>
_______________________________________

From report at bugs.python.org  Sun Apr 12 09:29:36 2020
From: report at bugs.python.org (Stefan Behnel)
Date: Sun, 12 Apr 2020 13:29:36 +0000
Subject: [issue32476] Add concat functionality to ElementTree xpath find
In-Reply-To: <1514834346.9.0.467229070634.issue32476@psf.upfronthosting.co.za>
Message-ID: <1586698176.05.0.518345862101.issue32476@roundup.psfhosted.org>


Stefan Behnel <stefan_ml at behnel.de> added the comment:

I think the use case of quote escaping is too niche for a feature like concat(), where I (at least) would expect to be able to dynamically concatenate text content, not just constant strings.

There seem to be at least a few alternatives to the usage of concat():

https://stackoverflow.com/questions/12403870/how-to-escape-single-quote-in-xslt-substring-function

https://sqa.stackexchange.com/questions/26341/how-to-write-xpath-if-i-have-apostrophe-in-my-xpath-element

I think we should either implement concat() completely, or provide a different way to solve the concrete problem at hand.

----------
versions: +Python 3.9 -Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32476>
_______________________________________

From report at bugs.python.org  Sun Apr 12 09:52:37 2020
From: report at bugs.python.org (Stefan Behnel)
Date: Sun, 12 Apr 2020 13:52:37 +0000
Subject: [issue31758] various refleaks in _elementtree,
 and crashes when using an uninitialized XMLParser object
In-Reply-To: <1507733619.97.0.213398074469.issue31758@psf.upfronthosting.co.za>
Message-ID: <1586699557.83.0.110860662927.issue31758@roundup.psfhosted.org>


Stefan Behnel <stefan_ml at behnel.de> added the comment:

This has been pending for a while too long, but the fixes look good to me. They should still go at least into Py3.8 and later.

----------
versions: +Python 3.8, Python 3.9 -Python 2.7, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31758>
_______________________________________

From report at bugs.python.org  Sun Apr 12 10:06:10 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 12 Apr 2020 14:06:10 +0000
Subject: [issue40259] re.Scanner groups
In-Reply-To: <1586678616.71.0.822734616794.issue40259@roundup.psfhosted.org>
Message-ID: <1586700370.84.0.386015289897.issue40259@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Copy paste of the contents in the text file

In the re module there is an experimental feature called Scanner.
Some unexpected behavior was found while working with it.
Here is an example:

>>> re.Scanner([('\w+=(\d+);', lambda s,g: s.match.group(1))]).scan('x=5;')
(['5;'], '')

The obvious error is the semicolon returned via capturing group 1.

Adding a dummy rule at the beginning, seems to solve that issue:

>>> re.Scanner([('z', None), ('\w+=(\d+);', lambda s,g: s.match.group(1))]).scan('x=5;')
(['5'], '')

Adding a capturing group around \w+ also returns the correct answer:

>>> re.Scanner([('z', None), ('(\w+)=(\d+);', lambda s,g: s.match.group(1))]).scan('x=5;')
(['x'], '')

But then, if I ask for the second group, the problem appears again:

>>> re.Scanner([('z', None), ('(\w+)=(\d+);', lambda s,g: s.match.group(2))]).scan('x=5;')
(['5;'], '')

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40259>
_______________________________________

From report at bugs.python.org  Sun Apr 12 10:22:05 2020
From: report at bugs.python.org (Stefan Behnel)
Date: Sun, 12 Apr 2020 14:22:05 +0000
Subject: [issue13743] xml.dom.minidom.Document class is not documented
In-Reply-To: <1326114378.06.0.424770823698.issue13743@psf.upfronthosting.co.za>
Message-ID: <1586701325.13.0.431156379451.issue13743@roundup.psfhosted.org>


Stefan Behnel <stefan_ml at behnel.de> added the comment:


New changeset 63e5b59c06fc99f95d274e7f181296e094cc3ee7 by Alex Itkes in branch 'master':
bpo-13743: Add some documentation strings to xml.dom.minidom (GH-16355)
https://github.com/python/cpython/commit/63e5b59c06fc99f95d274e7f181296e094cc3ee7


----------
nosy: +scoder

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13743>
_______________________________________

From report at bugs.python.org  Sun Apr 12 10:22:59 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Sun, 12 Apr 2020 14:22:59 +0000
Subject: [issue40255] Fixing Copy on Writes from reference counting
In-Reply-To: <1586619621.82.0.553262088399.issue40255@roundup.psfhosted.org>
Message-ID: <1586701379.06.0.328337679683.issue40255@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
nosy: +corona10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40255>
_______________________________________

From report at bugs.python.org  Sun Apr 12 10:23:13 2020
From: report at bugs.python.org (Stefan Behnel)
Date: Sun, 12 Apr 2020 14:23:13 +0000
Subject: [issue13743] xml.dom.minidom.Document class is not documented
In-Reply-To: <1326114378.06.0.424770823698.issue13743@psf.upfronthosting.co.za>
Message-ID: <1586701393.19.0.389733841433.issue13743@roundup.psfhosted.org>


Stefan Behnel <stefan_ml at behnel.de> added the comment:

A first PR was applied, but I'll leave this ticket open since it changes nothing for the "Document" class. :)

----------
versions:  -Python 2.7, Python 3.2, Python 3.3, Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13743>
_______________________________________

From report at bugs.python.org  Sun Apr 12 10:36:48 2020
From: report at bugs.python.org (Stefan Behnel)
Date: Sun, 12 Apr 2020 14:36:48 +0000
Subject: [issue31758] various refleaks in _elementtree,
 and crashes when using an uninitialized XMLParser object
In-Reply-To: <1507733619.97.0.213398074469.issue31758@psf.upfronthosting.co.za>
Message-ID: <1586702208.09.0.593181934311.issue31758@roundup.psfhosted.org>


Stefan Behnel <stefan_ml at behnel.de> added the comment:


New changeset 402e1cdb132f384e4dcde7a3d7ec7ea1fc7ab527 by Oren Milman in branch 'master':
bpo-31758: Prevent crashes when using an uninitialized _elementtree.XMLParser object (GH-3997)
https://github.com/python/cpython/commit/402e1cdb132f384e4dcde7a3d7ec7ea1fc7ab527


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31758>
_______________________________________

From report at bugs.python.org  Sun Apr 12 10:37:01 2020
From: report at bugs.python.org (miss-islington)
Date: Sun, 12 Apr 2020 14:37:01 +0000
Subject: [issue31758] various refleaks in _elementtree,
 and crashes when using an uninitialized XMLParser object
In-Reply-To: <1507733619.97.0.213398074469.issue31758@psf.upfronthosting.co.za>
Message-ID: <1586702221.81.0.70076531908.issue31758@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
nosy: +miss-islington
nosy_count: 4.0 -> 5.0
pull_requests: +18838
pull_request: https://github.com/python/cpython/pull/19485

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31758>
_______________________________________

From report at bugs.python.org  Sun Apr 12 11:19:01 2020
From: report at bugs.python.org (Stefan Behnel)
Date: Sun, 12 Apr 2020 15:19:01 +0000
Subject: [issue31758] various refleaks in _elementtree,
 and crashes when using an uninitialized XMLParser object
In-Reply-To: <1507733619.97.0.213398074469.issue31758@psf.upfronthosting.co.za>
Message-ID: <1586704741.56.0.795725772105.issue31758@roundup.psfhosted.org>


Stefan Behnel <stefan_ml at behnel.de> added the comment:


New changeset 61511488cf4e7a1cb57a38efba7e0a84a387fe58 by Miss Islington (bot) in branch '3.8':
bpo-31758: Prevent crashes when using an uninitialized _elementtree.XMLParser object (GH-3997) (GH-19485)
https://github.com/python/cpython/commit/61511488cf4e7a1cb57a38efba7e0a84a387fe58


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31758>
_______________________________________

From report at bugs.python.org  Sun Apr 12 11:20:24 2020
From: report at bugs.python.org (miss-islington)
Date: Sun, 12 Apr 2020 15:20:24 +0000
Subject: [issue31758] various refleaks in _elementtree,
 and crashes when using an uninitialized XMLParser object
In-Reply-To: <1507733619.97.0.213398074469.issue31758@psf.upfronthosting.co.za>
Message-ID: <1586704824.4.0.744084466281.issue31758@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +18839
pull_request: https://github.com/python/cpython/pull/19486

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31758>
_______________________________________

From report at bugs.python.org  Sun Apr 12 11:22:10 2020
From: report at bugs.python.org (Stefan Behnel)
Date: Sun, 12 Apr 2020 15:22:10 +0000
Subject: [issue31758] various refleaks in _elementtree,
 and crashes when using an uninitialized XMLParser object
In-Reply-To: <1507733619.97.0.213398074469.issue31758@psf.upfronthosting.co.za>
Message-ID: <1586704930.3.0.653455385016.issue31758@roundup.psfhosted.org>


Stefan Behnel <stefan_ml at behnel.de> added the comment:

Let's add it to the last bug fix release of 3.7 as well. It fixes a crash bug, after all.

----------
stage: patch review -> backport needed
versions: +Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31758>
_______________________________________

From report at bugs.python.org  Sun Apr 12 11:57:20 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 12 Apr 2020 15:57:20 +0000
Subject: [issue40204] Docs build error with Sphinx 3.0 due to invalid C
 declaration
In-Reply-To: <1586183568.2.0.322929459864.issue40204@roundup.psfhosted.org>
Message-ID: <1586707040.37.0.81459680505.issue40204@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40204>
_______________________________________

From report at bugs.python.org  Sun Apr 12 12:10:53 2020
From: report at bugs.python.org (miss-islington)
Date: Sun, 12 Apr 2020 16:10:53 +0000
Subject: [issue31758] various refleaks in _elementtree,
 and crashes when using an uninitialized XMLParser object
In-Reply-To: <1507733619.97.0.213398074469.issue31758@psf.upfronthosting.co.za>
Message-ID: <1586707853.73.0.545122703953.issue31758@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +18840
stage: backport needed -> patch review
pull_request: https://github.com/python/cpython/pull/19487

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31758>
_______________________________________

From report at bugs.python.org  Sun Apr 12 12:46:23 2020
From: report at bugs.python.org (Jeffery To)
Date: Sun, 12 Apr 2020 16:46:23 +0000
Subject: [issue34722] Non-deterministic bytecode generation
In-Reply-To: <1537278827.47.0.956365154283.issue34722@psf.upfronthosting.co.za>
Message-ID: <1586709983.44.0.232245801477.issue34722@roundup.psfhosted.org>


Change by Jeffery To <jeffery.to at gmail.com>:


----------
nosy: +jefferyto

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34722>
_______________________________________

From report at bugs.python.org  Sun Apr 12 13:15:41 2020
From: report at bugs.python.org (Stefan Behnel)
Date: Sun, 12 Apr 2020 17:15:41 +0000
Subject: [issue31758] various refleaks in _elementtree,
 and crashes when using an uninitialized XMLParser object
In-Reply-To: <1507733619.97.0.213398074469.issue31758@psf.upfronthosting.co.za>
Message-ID: <1586711741.7.0.867275609391.issue31758@roundup.psfhosted.org>


Stefan Behnel <stefan_ml at behnel.de> added the comment:


New changeset 096e41aa4e558b28b7260fe01eb21414b1458b20 by Miss Islington (bot) in branch '3.7':
[3.7] bpo-31758: Prevent crashes when using an uninitialized _elementtree.XMLParser object (GH-3997) (GH-19487)
https://github.com/python/cpython/commit/096e41aa4e558b28b7260fe01eb21414b1458b20


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31758>
_______________________________________

From report at bugs.python.org  Sun Apr 12 13:16:54 2020
From: report at bugs.python.org (Stefan Behnel)
Date: Sun, 12 Apr 2020 17:16:54 +0000
Subject: [issue31758] various refleaks in _elementtree,
 and crashes when using an uninitialized XMLParser object
In-Reply-To: <1507733619.97.0.213398074469.issue31758@psf.upfronthosting.co.za>
Message-ID: <1586711814.4.0.391709053145.issue31758@roundup.psfhosted.org>


Stefan Behnel <stefan_ml at behnel.de> added the comment:

Thanks for the fix, Oren!

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31758>
_______________________________________

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: [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 13:31:33 2020
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 12 Apr 2020 17:31:33 +0000
Subject: [issue40260] modulefinder traceback regression starting on Windows
In-Reply-To: <1586680620.99.0.514402715757.issue40260@roundup.psfhosted.org>
Message-ID: <1586712693.85.0.267097460007.issue40260@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch
nosy: +python-dev
nosy_count: 2.0 -> 3.0
pull_requests: +18841
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/19488

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40260>
_______________________________________

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: [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 14:20:40 2020
From: report at bugs.python.org (Ray Donnelly)
Date: Sun, 12 Apr 2020 18:20:40 +0000
Subject: [issue40263] Follow on bug from https://bugs.python.org/issue26903
 (ValueError exception on _winapi.WaitForMultipleObjects)
In-Reply-To: <1586715582.96.0.679053084097.issue40263@roundup.psfhosted.org>
Message-ID: <1586715640.56.0.854753132271.issue40263@roundup.psfhosted.org>


Ray Donnelly <rdonnelly at anaconda.com> added the comment:

See my proposed patch. I am happy to make a PR on github for this too if people agree it's the right fix.

----------
Added file: https://bugs.python.org/file49056/0000-bpo-26903-Limit-ProcessPoolExecutor-to-61-workers-on-Windows.patch.ref

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40263>
_______________________________________

From report at bugs.python.org  Sun Apr 12 14:21:06 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 12 Apr 2020 18:21:06 +0000
Subject: [issue40246] Different error messages for same error - invalid string
 prefixes
In-Reply-To: <1586541958.33.0.891000303304.issue40246@roundup.psfhosted.org>
Message-ID: <1586715666.82.0.534361374653.issue40246@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset 41d5b94af44e34ac05d4cd57460ed104ccf96628 by Lysandros Nikolaou in branch 'master':
bpo-40246: Report a better error message for invalid string prefixes (GH-19476)
https://github.com/python/cpython/commit/41d5b94af44e34ac05d4cd57460ed104ccf96628


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40246>
_______________________________________

From report at bugs.python.org  Sun Apr 12 14:21:58 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 12 Apr 2020 18:21:58 +0000
Subject: [issue40246] Different error messages for same error - invalid string
 prefixes
In-Reply-To: <1586541958.33.0.891000303304.issue40246@roundup.psfhosted.org>
Message-ID: <1586715718.12.0.543447497583.issue40246@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40246>
_______________________________________

From report at bugs.python.org  Sun Apr 12 14:37:39 2020
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 12 Apr 2020 18:37:39 +0000
Subject: [issue39953] Let's update ssl error codes
In-Reply-To: <1586690533.34.0.571350480854.issue39953@roundup.psfhosted.org>
Message-ID: <ecd5755f-69f0-421f-872a-56f425b8c534@www.fastmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

Sorry, I thought I had tested with multissl.

On Sun, Apr 12, 2020, at 06:22, Christian Heimes wrote:
> 
> Christian Heimes <lists at cheimes.de> added the comment:
> 
> The PR broke backwards compatibility with OpenSSL 1.0.2 and LibreSSL. 
> OpenSSL 1.1.x introduced new error codes or reused existing numbers for 
> different errors codes.
> 
> Although OpenSSL 1.0.2 has reached EOL we should keep keep Python 3.8 
> and 3.9 compatible with the API.
> 
> ----------
> nosy: +lukasz.langa
> priority: normal -> release blocker
> resolution: fixed -> 
> status: closed -> open
> 
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue39953>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39953>
_______________________________________

From report at bugs.python.org  Sun Apr 12 14:40:02 2020
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 12 Apr 2020 18:40:02 +0000
Subject: [issue39953] Let's update ssl error codes
In-Reply-To: <1584072470.83.0.437860249809.issue39953@roundup.psfhosted.org>
Message-ID: <1586716802.65.0.627270815477.issue39953@roundup.psfhosted.org>


Change by Benjamin Peterson <benjamin at python.org>:


----------
pull_requests: +18842
stage: resolved -> patch review
pull_request: https://github.com/python/cpython/pull/19490

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39953>
_______________________________________

From report at bugs.python.org  Sun Apr 12 14:59:34 2020
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 12 Apr 2020 18:59:34 +0000
Subject: [issue39953] Let's update ssl error codes
In-Reply-To: <1584072470.83.0.437860249809.issue39953@roundup.psfhosted.org>
Message-ID: <1586717974.57.0.0136429348053.issue39953@roundup.psfhosted.org>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset 909b87d2bb3d6330d39c48e43f7f50f4d086cc41 by Benjamin Peterson in branch 'master':
closes bpo-39953: Generate ifdefs around library code definitions. (GH-19490)
https://github.com/python/cpython/commit/909b87d2bb3d6330d39c48e43f7f50f4d086cc41


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39953>
_______________________________________

From report at bugs.python.org  Sun Apr 12 14:59:47 2020
From: report at bugs.python.org (miss-islington)
Date: Sun, 12 Apr 2020 18:59:47 +0000
Subject: [issue39953] Let's update ssl error codes
In-Reply-To: <1584072470.83.0.437860249809.issue39953@roundup.psfhosted.org>
Message-ID: <1586717987.5.0.83625426583.issue39953@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +18843
pull_request: https://github.com/python/cpython/pull/19491

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39953>
_______________________________________

From report at bugs.python.org  Sun Apr 12 15:17:38 2020
From: report at bugs.python.org (miss-islington)
Date: Sun, 12 Apr 2020 19:17:38 +0000
Subject: [issue39953] Let's update ssl error codes
In-Reply-To: <1584072470.83.0.437860249809.issue39953@roundup.psfhosted.org>
Message-ID: <1586719058.52.0.608605944627.issue39953@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset f35e7d3bb0488a15cbb45ff10f02be558a3777cd by Miss Islington (bot) in branch '3.8':
closes bpo-39953: Generate ifdefs around library code definitions. (GH-19490)
https://github.com/python/cpython/commit/f35e7d3bb0488a15cbb45ff10f02be558a3777cd


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39953>
_______________________________________

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: [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: [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 15:47:04 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 12 Apr 2020 19:47:04 +0000
Subject: [issue40264] List item inside tuple seemingly allows for item
 assignment even after throwing error
In-Reply-To: <1586720489.25.0.970851417478.issue40264@roundup.psfhosted.org>
Message-ID: <1586720824.92.0.0803364377087.issue40264@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40264>
_______________________________________

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: [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 16:46:31 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Sun, 12 Apr 2020 20:46:31 +0000
Subject: [issue40264] List item inside tuple seemingly allows for item
 assignment even after throwing error
In-Reply-To: <1586720489.25.0.970851417478.issue40264@roundup.psfhosted.org>
Message-ID: <1586724391.52.0.855664062485.issue40264@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

This isn't a bug. See the FAQ:
https://docs.python.org/3/faq/programming.html#why-does-a-tuple-i-item-raise-an-exception-when-the-addition-works

----------
nosy: +eric.smith
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40264>
_______________________________________

From report at bugs.python.org  Sun Apr 12 16:56:37 2020
From: report at bugs.python.org (=?utf-8?q?Volker_Wei=C3=9Fmann?=)
Date: Sun, 12 Apr 2020 20:56:37 +0000
Subject: [issue40218] sys.executable is a false path if python is executed
 from gdb
In-Reply-To: <1586290599.79.0.960995339825.issue40218@roundup.psfhosted.org>
Message-ID: <1586724997.6.0.513051581066.issue40218@roundup.psfhosted.org>


Volker Wei?mann <volker.weissmann at gmx.de> added the comment:

Ok, thank you. I hope that the gdb guys will respon

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40218>
_______________________________________

From report at bugs.python.org  Sun Apr 12 16:59:53 2020
From: report at bugs.python.org (Ray Donnelly)
Date: Sun, 12 Apr 2020 20:59:53 +0000
Subject: [issue40263] Follow on bug from https://bugs.python.org/issue26903
 (ValueError exception on _winapi.WaitForMultipleObjects)
In-Reply-To: <1586715582.96.0.679053084097.issue40263@roundup.psfhosted.org>
Message-ID: <1586725193.35.0.28309294159.issue40263@roundup.psfhosted.org>


Change by Ray Donnelly <rdonnelly at anaconda.com>:


Removed file: https://bugs.python.org/file49056/0000-bpo-26903-Limit-ProcessPoolExecutor-to-61-workers-on-Windows.patch.ref

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40263>
_______________________________________

From report at bugs.python.org  Sun Apr 12 17:00:09 2020
From: report at bugs.python.org (Ray Donnelly)
Date: Sun, 12 Apr 2020 21:00:09 +0000
Subject: [issue40263] Follow on bug from https://bugs.python.org/issue26903
 (ValueError exception on _winapi.WaitForMultipleObjects)
In-Reply-To: <1586715582.96.0.679053084097.issue40263@roundup.psfhosted.org>
Message-ID: <1586725209.26.0.94436635358.issue40263@roundup.psfhosted.org>


Change by Ray Donnelly <rdonnelly at anaconda.com>:


----------
keywords: +patch
Added file: https://bugs.python.org/file49057/0000-Fix-off-by-one-error-in-_winapi_WaitForMultipleObjec.patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40263>
_______________________________________

From report at bugs.python.org  Sun Apr 12 17:45:20 2020
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 12 Apr 2020 21:45:20 +0000
Subject: [issue40234] Disallow daemon threads in subinterpreters optionally.
In-Reply-To: <1586387812.86.0.0296012569674.issue40234@roundup.psfhosted.org>
Message-ID: <1586727920.61.0.970527797212.issue40234@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 14d5331eb5e6c38be12bad421bd59ad0fac9e448 by Victor Stinner in branch 'master':
bpo-40234: Revert "bpo-37266: Daemon threads are now denied in subinterpreters (GH-14049)" (GH-19456)
https://github.com/python/cpython/commit/14d5331eb5e6c38be12bad421bd59ad0fac9e448


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40234>
_______________________________________

From report at bugs.python.org  Sun Apr 12 17:45:20 2020
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 12 Apr 2020 21:45:20 +0000
Subject: [issue37266] Daemon threads must be forbidden in subinterpreters
In-Reply-To: <1560418565.72.0.288239825756.issue37266@roundup.psfhosted.org>
Message-ID: <1586727920.5.0.961122712975.issue37266@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 14d5331eb5e6c38be12bad421bd59ad0fac9e448 by Victor Stinner in branch 'master':
bpo-40234: Revert "bpo-37266: Daemon threads are now denied in subinterpreters (GH-14049)" (GH-19456)
https://github.com/python/cpython/commit/14d5331eb5e6c38be12bad421bd59ad0fac9e448


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37266>
_______________________________________

From report at bugs.python.org  Sun Apr 12 17:49:51 2020
From: report at bugs.python.org (Kyle Stanley)
Date: Sun, 12 Apr 2020 21:49:51 +0000
Subject: [issue40234] Disallow daemon threads in subinterpreters optionally.
In-Reply-To: <1586387812.86.0.0296012569674.issue40234@roundup.psfhosted.org>
Message-ID: <1586728191.69.0.472201072962.issue40234@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:

> So if you are going to eliminate daemon threads (even if only in sub interpreters at this point), you are going to have to introduce a way to register something similar to an atexit callback which would be invoked before waiting on non daemon threads, so an attempt can be made to notify them that they need to shutdown.

I'm not 100% certain if it fully covers the above use cases, but I recently added a fairly minimal internal `threading._register_atexit()` function that works similar to atexit: it schedules the callbacks to be invoked just before all non-daemon threads are joined, rather than upon interpreter finalization. The primary use case was to remove the reliance of daemon threads in concurrent.futures, for ThreadPoolExecutor and ProcessPoolExecutor. Their management threads relied fully upon daemon threads and `atexit.register()`, but the above provided an alternative means to accomplish the same goal; and also has the benefit of a more predictable shutdown process. See https://github.com/python/cpython/pull/19149 for details.

Should we consider making `threading._register_atexit()` public, and if we did, would it provide a reasonable transition for users that were previously relying upon daemon threads if they were to be deprecated in subinterpreters? If it were to be made public, there may also be a need to be able to unregister the threading atexit callbacks, similar to `atexit.unregister()` (that should be rather straightforward though).

(I added Antoine Pitrou to the nosy list, to see if he has an opinion on any of this as the maintainer of the threading module.)

----------
nosy: +aeros, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40234>
_______________________________________

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: [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 18:41:03 2020
From: report at bugs.python.org (Lysandros Nikolaou)
Date: Sun, 12 Apr 2020 22:41:03 +0000
Subject: [issue40267] Error message differs when an expression is in an fstring
In-Reply-To: <1586728764.59.0.587923723315.issue40267@roundup.psfhosted.org>
Message-ID: <1586731263.95.0.913848599113.issue40267@roundup.psfhosted.org>


Lysandros Nikolaou <lisandrosnik at gmail.com> added the comment:

It seems that this is actually a bit bigger than this and it is not specific to f-strings. 

The error message *always* changes to `unexpected EOF while parsing` if there is an error with the last character of the input and no newline follows. For example, as made clear to me by Guido, there are even differences in error messages between exec'ing and eval'ing something:

>>> exec('x+')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<string>", line 1
    x+
     ^
SyntaxError: invalid syntax
>>> eval('x+')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<string>", line 1
    x+
     ^
SyntaxError: unexpected EOF while parsing

That's because the tokenizer adds an implicit newline to the input string, before tokenizing it, when the input comes from an exec call. (see https://github.com/python/cpython/blob/14d5331eb5e6c38be12bad421bd59ad0fac9e448/Parser/tokenizer.c#L648)

And that's not limited to a character missing, as suggested by the error message. Even when the last character itself generates a SyntaxError, the error message remains "unexpcted EOF while parsing":

>>> x+@
  File "<stdin>", line 1
    x+@
      ^
SyntaxError: invalid syntax
>>> eval('x+@')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<string>", line 1
    x+@
      ^
SyntaxError: unexpected EOF while parsing

Thus, a very simple fix to the specific fstring problem of this issue would be to add a newline to the string that gets parsed to the parser in fstring_compile_expr in ast.c, but I guess it'd be better to fix the tokenizer itself, if this is considered a bug.

----------

_______________________________________
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: [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 19:07:32 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 12 Apr 2020 23:07:32 +0000
Subject: [issue39865] getattr silences an unrelated AttributeError
In-Reply-To: <1583436241.07.0.803311507701.issue39865@roundup.psfhosted.org>
Message-ID: <1586732852.42.0.625253900114.issue39865@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

My instincts are to leave this alone and not gum up heavily trafficked core business logic.  I don't like the external calls, the extra increfs and decrefs (and possible rentrancy issues), performance impact, or the pattern of holding the exception across a call that can invoke arbitrary code.   The code for slot_tp_getattr_hook() is currently very clean and it would be nice to keep it that way.

ISTM that the problem is better addressed by unittesting, linting, and static type checking rather than by gumming-up runtime.

----------
nosy: +tim.peters
versions:  -Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39865>
_______________________________________

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: [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  Sun Apr 12 20:22:54 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 13 Apr 2020 00:22:54 +0000
Subject: [issue40234] Disallow daemon threads in subinterpreters optionally.
In-Reply-To: <1586387812.86.0.0296012569674.issue40234@roundup.psfhosted.org>
Message-ID: <1586737374.24.0.470584286024.issue40234@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Victor (me!):
> Well, this large problem sounds very complex and is made of multiple small issues.

Kyle:
> (...) Should we consider making `threading._register_atexit()` public?

It seems like there is an use case for calling callbacks before Python calls threading._shutdown() in Py_Finalize(). We should either change when atexit callbacks are called, or add something new.

I suggest to open a separated issue for that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40234>
_______________________________________

From report at bugs.python.org  Sun Apr 12 20:29:03 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 13 Apr 2020 00:29:03 +0000
Subject: [issue40268] Reorganize pycore_pystate.h header
In-Reply-To: <1586732467.85.0.974458317268.issue40268@roundup.psfhosted.org>
Message-ID: <1586737743.82.0.371477057935.issue40268@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
keywords: +patch
pull_requests: +18845
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19492

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40268>
_______________________________________

From report at bugs.python.org  Sun Apr 12 20:38:23 2020
From: report at bugs.python.org (Josh Rosenberg)
Date: Mon, 13 Apr 2020 00:38:23 +0000
Subject: [issue40269] Inconsistent complex behavior with (-1j)
In-Reply-To: <1586736208.71.0.129112794549.issue40269@roundup.psfhosted.org>
Message-ID: <1586738303.39.0.454315062627.issue40269@roundup.psfhosted.org>


Josh Rosenberg <shadowranger+python at gmail.com> added the comment:

The final entry is identical to the second to last, because ints have no concept of -0. If you used a float literal, it would match the first two:

>>> -0.-1j
(-0-1j)

I suspect the behavior here is due to -1j not actually being a literal on its own; it's interpreted as the negation of 1j, where 1j is actually 0.0+1.0j, and negating it flips the sign on both the real and imaginary component.

>From what I can read of the grammar rules, this is expected; the negation isn't ever part of the literal (minus signs aren't part of the grammar aside from exponents in scientific notation). https://docs.python.org/3/reference/lexical_analysis.html#floating-point-literals

If this is a bug, it's a bug in the grammar. I suspect the correct solution here is to include the real part explicitly, as 0.0-1j works just fine.

----------
nosy: +josh.r

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40269>
_______________________________________

From report at bugs.python.org  Sun Apr 12 20:39:21 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 13 Apr 2020 00:39:21 +0000
Subject: [issue40268] Reorganize pycore_pystate.h header
In-Reply-To: <1586732467.85.0.974458317268.issue40268@roundup.psfhosted.org>
Message-ID: <1586738361.68.0.212174442412.issue40268@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +18846
pull_request: https://github.com/python/cpython/pull/19493

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40268>
_______________________________________

From report at bugs.python.org  Sun Apr 12 21:00:41 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 13 Apr 2020 01:00:41 +0000
Subject: [issue40241] [C API] Make PyGC_Head structure opaque,
 or even move it to the internal C API
In-Reply-To: <1586445596.83.0.583225080007.issue40241@roundup.psfhosted.org>
Message-ID: <1586739641.32.0.177699914739.issue40241@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +18847
pull_request: https://github.com/python/cpython/pull/19494

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40241>
_______________________________________

From report at bugs.python.org  Sun Apr 12 21:04:32 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 13 Apr 2020 01:04:32 +0000
Subject: [issue40268] Reorganize pycore_pystate.h header
In-Reply-To: <1586732467.85.0.974458317268.issue40268@roundup.psfhosted.org>
Message-ID: <1586739872.05.0.878014595379.issue40268@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset da7933ecc30e37b119756cb02b89a6ad99db22e0 by Victor Stinner in branch 'master':
bpo-40268: Add _PyInterpreterState_GetConfig() (GH-19492)
https://github.com/python/cpython/commit/da7933ecc30e37b119756cb02b89a6ad99db22e0


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40268>
_______________________________________

From report at bugs.python.org  Sun Apr 12 21:23:10 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 13 Apr 2020 01:23:10 +0000
Subject: [issue40269] Inconsistent complex behavior with (-1j)
In-Reply-To: <1586736208.71.0.129112794549.issue40269@roundup.psfhosted.org>
Message-ID: <1586740990.65.0.942125077233.issue40269@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40269>
_______________________________________

From report at bugs.python.org  Sun Apr 12 21:46:55 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 13 Apr 2020 01:46:55 +0000
Subject: [issue40269] Inconsistent complex behavior with (-1j)
In-Reply-To: <1586736208.71.0.129112794549.issue40269@roundup.psfhosted.org>
Message-ID: <1586742415.87.0.104476192401.issue40269@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

The docs for complex literals? could be improved to show that:

    -1j is interpreted as -complex(0.0, 1.0)
    giving a real component of -0.0
    and an imaginary component of -1.0

and that:

   0-1j  is interpreted as 0.0-complex(0.0, 1.0)
    giving a real component of 0.0
    and an imaginary component of -1.0

It is unfortunate the repr for complex numbers uses integers at all.  That hides what is going on.

? https://docs.python.org/3/reference/lexical_analysis.html#imaginary-literals

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40269>
_______________________________________

From report at bugs.python.org  Sun Apr 12 21:53:25 2020
From: report at bugs.python.org (Ruben)
Date: Mon, 13 Apr 2020 01:53:25 +0000
Subject: [issue40261] Build of Python where make is called from subprocess,
 within a virtualenv, breaks on macOS
In-Reply-To: <1586689461.86.0.934526151918.issue40261@roundup.psfhosted.org>
Message-ID: <1586742805.53.0.206731869461.issue40261@roundup.psfhosted.org>


Ruben <rubendibattista at gmail.com> added the comment:

I just tested on a fresh macOS 10.15.3 Virtual Machine (on the same host machine as the one of previous messages) and I can reproduce the problem: 

1. Install Command Line Tools (xcode-build --install)
2. Download Python 3.8.1
3. Extract tarball
4. Create a file make.py with the following python code
```
import subprocess

subprocess.run(["./configure"])
subprocess.run(["make", "-j4"])
```
and save it in the Python-3.8.1 source tree
6. Create a venv doing `python -m venv venv` in the source tree
7. Activate the virtual env `source venv/bin/activate`
5. Run it doing `python3 make.py`

The build fails with the error described before. 

If you now, instead, run the make directly `make -j8` the buids proceeds as expected.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40261>
_______________________________________

From report at bugs.python.org  Sun Apr 12 21:55:29 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 13 Apr 2020 01:55:29 +0000
Subject: [issue40265] argparse.Namespace __repr__ does not handle reserved
 keywords
In-Reply-To: <1586720778.53.0.603692808459.issue40265@roundup.psfhosted.org>
Message-ID: <1586742929.36.0.0382645840428.issue40265@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

ISTM this a purely theoretical problem since "ns.return" is already a syntax error.

The primary function of the Namespace class is to hold valid attributes and to allow the dot operator to access those attributes.  Handling invalid attribute names is beyond its scope.

----------
assignee:  -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40265>
_______________________________________

From report at bugs.python.org  Sun Apr 12 23:22:41 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Mon, 13 Apr 2020 03:22:41 +0000
Subject: [issue40269] Inconsistent complex behavior with (-1j)
In-Reply-To: <1586736208.71.0.129112794549.issue40269@roundup.psfhosted.org>
Message-ID: <1586748161.06.0.543862650584.issue40269@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

Would we be willing to consider an enhancement to have complex numbers always display using float format rather than ints?

    1+1j --> 1.0+1.0j

We could still suppress an unsigned real zero:

    1j --> 1.0j

but negative zero would show:

    -(1j) --> -0.0-1.0j

I daresay this would break some doctests (CC'ing Tim, as he is a heavy user of doctests) but perhaps it would be worthwhile.

Aside from the backwards-compatibility issue, going against this suggestion we have the popular Texas Instruments Nspire calculator, which shows complex numbers as ints when possible.

On the other hand, the imaginary unit is shown as the symbolic constant i with no coefficient, and it also shows complex numbers with an explicit multiplication sign: 2?i rather than 2i.

Similarly, Julia shows complex numbers with integer coefficients when possible:

https://docs.julialang.org/en/v1/manual/complex-and-rational-numbers/

----------
nosy: +steven.daprano, tim.peters

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40269>
_______________________________________

From report at bugs.python.org  Mon Apr 13 01:39:37 2020
From: report at bugs.python.org (Saiyang Gou)
Date: Mon, 13 Apr 2020 05:39:37 +0000
Subject: [issue40265] argparse.Namespace __repr__ does not handle reserved
 keywords
In-Reply-To: <1586720778.53.0.603692808459.issue40265@roundup.psfhosted.org>
Message-ID: <1586756377.52.0.208393303298.issue40265@roundup.psfhosted.org>


Saiyang Gou <gousaiyang223 at gmail.com> added the comment:

> The primary function of the Namespace class is to hold valid attributes and to allow the dot operator to access those attributes.

I acknowledge this. Invalid attribute names are not useful in production. However, some crazy people like me would define arguments like these, producing an repr string that does not round-trip:

>>> from argparse import ArgumentParser
>>> parser = ArgumentParser()
>>> parser.add_argument('-8')
>>> parser.add_argument('-@')
>>> parser.add_argument('--return')
>>> parser.parse_args(['-8', 'y', '-@', 'a.com', '--return', 'foo'])
Namespace(return='foo', **{'8': 'y', '@': 'a.com'})

(I know I can use the `dest` argument to define an alternative name to store in the namespace.)

The reason why I open this issue is that I see issue 24360 already tried to improve the repr string for invalid names by using the `isidentifier` check. (Which is almost "as unuseful as this issue" for production use, since repr is almost only used for development instead of production.) The original author thought the improvement was enough to be round-trippable but missed the special case of keywords, and my patch will fix this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40265>
_______________________________________

From report at bugs.python.org  Mon Apr 13 02:13:30 2020
From: report at bugs.python.org (SilentGhost)
Date: Mon, 13 Apr 2020 06:13:30 +0000
Subject: [issue40266] Failure to build _ssl module on ubuntu xenial
In-Reply-To: <1586722609.26.0.314965536558.issue40266@roundup.psfhosted.org>
Message-ID: <1586758410.17.0.916665585177.issue40266@roundup.psfhosted.org>


SilentGhost <ghost.adh at runbox.com> added the comment:

This should have been fixed already in #39953. Do re-open, if you can reproduce this with the latest checkouts.

----------
nosy: +SilentGhost
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Let's update ssl error codes

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40266>
_______________________________________

From report at bugs.python.org  Mon Apr 13 03:00:41 2020
From: report at bugs.python.org (Ethan Smith)
Date: Mon, 13 Apr 2020 07:00:41 +0000
Subject: [issue39481] Implement PEP 585 (Type Hinting Generics In Standard
 Collections)
In-Reply-To: <1580231817.93.0.47144630055.issue39481@roundup.psfhosted.org>
Message-ID: <1586761241.66.0.30549284495.issue39481@roundup.psfhosted.org>


Change by Ethan Smith <ethan at ethanhs.me>:


----------
pull_requests: +18848
pull_request: https://github.com/python/cpython/pull/19497

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39481>
_______________________________________

From report at bugs.python.org  Mon Apr 13 04:06:48 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 13 Apr 2020 08:06:48 +0000
Subject: [issue40265] argparse.Namespace __repr__ does not handle reserved
 keywords
In-Reply-To: <1586720778.53.0.603692808459.issue40265@roundup.psfhosted.org>
Message-ID: <1586765208.26.0.335829212472.issue40265@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Saiyang, thank you for the suggestion, but I'm going to decline.  The other referenced issue had to do with readability of otherwise incomprehensible output and that's what made it worthwhile.  In this issue, you're prioritizing round-tripping at the expense of readability.  To me, that is a step backwards.  Since people don't normally run eval() on the repr() of a Namespace, round-tripping should take a backseat to readability.  And, as you noted, there is already an option to set *dest* if needed.

----------
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40265>
_______________________________________

From report at bugs.python.org  Mon Apr 13 04:48:55 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 13 Apr 2020 08:48:55 +0000
Subject: [issue40269] Inconsistent complex behavior with (-1j)
In-Reply-To: <1586736208.71.0.129112794549.issue40269@roundup.psfhosted.org>
Message-ID: <1586767735.82.0.866340668711.issue40269@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

It is a known issue, but I have no references to previous discussions. Outputting numbers with decimal point will not help in case of complex(-0.0, 1.0). Maybe the only way to solve this problem is to implement special Imaginary type (as a subclass of complex).

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40269>
_______________________________________

From report at bugs.python.org  Mon Apr 13 04:50:05 2020
From: report at bugs.python.org (Lysandros Nikolaou)
Date: Mon, 13 Apr 2020 08:50:05 +0000
Subject: [issue40267] Error message differs when an expression is in an fstring
In-Reply-To: <1586728764.59.0.587923723315.issue40267@roundup.psfhosted.org>
Message-ID: <1586767805.03.0.96858089925.issue40267@roundup.psfhosted.org>


Change by Lysandros Nikolaou <lisandrosnik at gmail.com>:


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40267>
_______________________________________

From report at bugs.python.org  Mon Apr 13 05:01:32 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 13 Apr 2020 09:01:32 +0000
Subject: [issue40267] Error message differs when an expression is in an fstring
In-Reply-To: <1586728764.59.0.587923723315.issue40267@roundup.psfhosted.org>
Message-ID: <1586768492.55.0.501310384754.issue40267@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40267>
_______________________________________

From report at bugs.python.org  Mon Apr 13 05:12:29 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 13 Apr 2020 09:12:29 +0000
Subject: [issue39481] Implement PEP 585 (Type Hinting Generics In Standard
 Collections)
In-Reply-To: <1580231817.93.0.47144630055.issue39481@roundup.psfhosted.org>
Message-ID: <1586769149.87.0.335309517977.issue39481@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I tested the following example:

import ipaddress, mmap

x: ipaddress.IPv4Network[int]
y: mmap.mmap[int]

MyPy produces errors:

t.py:4: error: "IPv4Network" expects no type arguments, but 1 given
t.py:5: error: "mmap" expects no type arguments, but 1 given

This is because mmap and IPv4Network are not generic types in typeshed. _BaseNetwork and _mmap are generic types, but IPv4Network and mmap are normal classes. The former are implementation detail of typeshed. _mmap does not exist in the stdlib, and _BaseNetwork in typeshed and the stdlib are different things.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39481>
_______________________________________

From report at bugs.python.org  Mon Apr 13 05:29:58 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 13 Apr 2020 09:29:58 +0000
Subject: [issue40269] Inconsistent complex behavior with (-1j)
In-Reply-To: <1586736208.71.0.129112794549.issue40269@roundup.psfhosted.org>
Message-ID: <1586770198.85.0.187426247241.issue40269@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

See also #25839, #22548; there's lot of discussion of the core issue on those tickets. As Serhiy says, the only reasonable "true" fix would be to have 1j be a genuine imaginary literal, but that's a lot of work and potential disruption (not just to core Python, but to 3rd party libraries that care about complex numbers) for not a lot of gain.

A documentation improvement as suggested by Raymond sounds good.

I'm not keen on messing with the complex __repr__ again, but if we did, I'd propose not only representing real and imaginary parts in a way that's consistent with floats (so with both real and imaginary parts having either decimal points or exponents), but also showing _both_ the real and imaginary parts in all complex numbers. That is:

    >>> 1j
    0.0 + 1.0j

Or if we're willing to accept more backwards compatibility breakage, there's a case for having the __repr__ (but not the __str__) of a complex number take the form

    >>> 1j
    complex(0.0, 1.0)

since this the only way that allows easy round-tripping. Otherwise you still have this problem:

    >>> complex(-0.0, 1.0)
    (-0+1j)
    >>> -0 + 1j
    1j

BTW, I still dislike the parentheses around the current complex repr.

Let's keep this issue open for potential documentation improvements. If we want to change the repr of complex, let's open another issue for that.

----------
assignee:  -> docs at python
components: +Documentation -Interpreter Core
nosy: +docs at python
type: behavior -> enhancement

_______________________________________
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: [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 05:38:23 2020
From: report at bugs.python.org (Big Stone)
Date: Mon, 13 Apr 2020 09:38:23 +0000
Subject: [issue40270] activate json1 extension in sqlite
In-Reply-To: <1586770672.18.0.207799300786.issue40270@roundup.psfhosted.org>
Message-ID: <1586770703.6.0.346883174165.issue40270@roundup.psfhosted.org>


Change by Big Stone <stonebig34 at gmail.com>:


----------
title: activation json1 extension in sqlite -> activate 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 05:38:37 2020
From: report at bugs.python.org (Big Stone)
Date: Mon, 13 Apr 2020 09:38:37 +0000
Subject: [issue40270] activate (or include) json1 extension in sqlite
In-Reply-To: <1586770672.18.0.207799300786.issue40270@roundup.psfhosted.org>
Message-ID: <1586770717.6.0.69898753482.issue40270@roundup.psfhosted.org>


Change by Big Stone <stonebig34 at gmail.com>:


----------
title: activate json1 extension in sqlite -> activate (or include) 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 05:38:46 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 13 Apr 2020 09:38:46 +0000
Subject: [issue40241] [C API] Make PyGC_Head structure opaque,
 or even move it to the internal C API
In-Reply-To: <1586445596.83.0.583225080007.issue40241@roundup.psfhosted.org>
Message-ID: <1586770726.28.0.748103381274.issue40241@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 0135598d729d01f35ce08d47160adaa095a6149f by Victor Stinner in branch 'master':
bpo-40241: Add pycore_gc.h header file (GH-19494)
https://github.com/python/cpython/commit/0135598d729d01f35ce08d47160adaa095a6149f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40241>
_______________________________________

From report at bugs.python.org  Mon Apr 13 05:45:24 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 13 Apr 2020 09:45:24 +0000
Subject: [issue40268] Reorganize pycore_pystate.h header
In-Reply-To: <1586732467.85.0.974458317268.issue40268@roundup.psfhosted.org>
Message-ID: <1586771124.69.0.115574040112.issue40268@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 1c4cbdf94dbb4a6ac1093d2fa7a75efa802b25bc by Victor Stinner in branch 'master':
bpo-40268: Add pycore_runtime.h header file (GH-19493)
https://github.com/python/cpython/commit/1c4cbdf94dbb4a6ac1093d2fa7a75efa802b25bc


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40268>
_______________________________________

From report at bugs.python.org  Mon Apr 13 05:48:03 2020
From: report at bugs.python.org (SilentGhost)
Date: Mon, 13 Apr 2020 09:48:03 +0000
Subject: [issue40270] activate (or include) json1 extension in sqlite
In-Reply-To: <1586770672.18.0.207799300786.issue40270@roundup.psfhosted.org>
Message-ID: <1586771283.07.0.00959215307932.issue40270@roundup.psfhosted.org>


Change by SilentGhost <ghost.adh at runbox.com>:


----------
components: +Extension Modules, Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware
stage:  -> test needed
type:  -> behavior
versions: +Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40270>
_______________________________________

From report at bugs.python.org  Mon Apr 13 05:49:20 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 13 Apr 2020 09:49:20 +0000
Subject: [issue40269] Inconsistent complex behavior with (-1j)
In-Reply-To: <1586736208.71.0.129112794549.issue40269@roundup.psfhosted.org>
Message-ID: <1586771360.12.0.600538901732.issue40269@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

The Imaginary type could help to solve other "gotchas". For example, in Python

>>> complex(0, float('inf')) * 1
(nan+infj)

But in C++ you will get the real component 0, because multiplication of complex and real numbers is component wise.

With the Imaginary type we could get that 1j * x == complex(0, x) for all float x, including infinity and NaN.

Returning to the repr, the other way to correctly represent the repr of complex(-0.0, 1.0) is writing it as "-(0.0-1j)", but it looks unnatural to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40269>
_______________________________________

From report at bugs.python.org  Mon Apr 13 06:04:58 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 13 Apr 2020 10:04:58 +0000
Subject: [issue40269] Inconsistent complex behavior with (-1j)
In-Reply-To: <1586736208.71.0.129112794549.issue40269@roundup.psfhosted.org>
Message-ID: <1586772298.49.0.278267356001.issue40269@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> The Imaginary type could help to solve other "gotchas".

Yes, it's an attractive proposition from many angles: e.g., multiplying by 1j could do the correct quarter-turn rotation in the complex plane, keeping all signs correct, so that multiplying a complex number z by 1j 4 times exactly recovers z, regardless of nans, infinities and signed zeros.

C99's specification of (optional) imaginary types was supposed to solve exactly this problem, but it doesn't look as though it received widespread adoption, and I suspect it would have difficult getting traction in Python world, too.

I'll have a PR with a documentation update shortly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40269>
_______________________________________

From report at bugs.python.org  Mon Apr 13 06:09:14 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Mon, 13 Apr 2020 10:09:14 +0000
Subject: [issue40267] Error message differs when an expression is in an fstring
In-Reply-To: <1586728764.59.0.587923723315.issue40267@roundup.psfhosted.org>
Message-ID: <1586772554.89.0.160728653025.issue40267@roundup.psfhosted.org>


Change by Batuhan Taskaya <batuhanosmantaskaya at gmail.com>:


----------
nosy: +BTaskaya

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40267>
_______________________________________

From report at bugs.python.org  Mon Apr 13 06:11:59 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 13 Apr 2020 10:11:59 +0000
Subject: [issue40269] Inconsistent complex behavior with (-1j)
In-Reply-To: <1586736208.71.0.129112794549.issue40269@roundup.psfhosted.org>
Message-ID: <1586772719.34.0.985260713637.issue40269@roundup.psfhosted.org>


Change by Mark Dickinson <dickinsm at gmail.com>:


----------
keywords: +patch
pull_requests: +18849
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19498

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40269>
_______________________________________

From report at bugs.python.org  Mon Apr 13 06:15:07 2020
From: report at bugs.python.org (Steve Dower)
Date: Mon, 13 Apr 2020 10:15:07 +0000
Subject: [issue40260] modulefinder traceback regression starting on Windows
In-Reply-To: <1586680620.99.0.514402715757.issue40260@roundup.psfhosted.org>
Message-ID: <1586772907.33.0.0307554535438.issue40260@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

(+Windows tag)

These should use io.open_code() these days anyway, which always opens in 'rb'.

Could you make that change?

----------
components: +Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40260>
_______________________________________

From report at bugs.python.org  Mon Apr 13 06:20:38 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 13 Apr 2020 10:20:38 +0000
Subject: [issue40241] [C API] Make PyGC_Head structure opaque,
 or even move it to the internal C API
In-Reply-To: <1586445596.83.0.583225080007.issue40241@roundup.psfhosted.org>
Message-ID: <1586773238.33.0.946651708466.issue40241@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Ok, this issue should now be closed. It was easier than expected ;-)

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40241>
_______________________________________

From report at bugs.python.org  Mon Apr 13 06:27:30 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 13 Apr 2020 10:27:30 +0000
Subject: [issue40241] [C API] Make PyGC_Head structure opaque,
 or even move it to the internal C API
In-Reply-To: <1586445596.83.0.583225080007.issue40241@roundup.psfhosted.org>
Message-ID: <1586773650.23.0.78814216841.issue40241@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +18850
pull_request: https://github.com/python/cpython/pull/19499

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40241>
_______________________________________

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: [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:36:09 2020
From: report at bugs.python.org (Steve Dower)
Date: Mon, 13 Apr 2020 10:36:09 +0000
Subject: [issue40255] Fixing Copy on Writes from reference counting
In-Reply-To: <1586619621.82.0.553262088399.issue40255@roundup.psfhosted.org>
Message-ID: <1586774169.33.0.593207151283.issue40255@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
nosy: +steve.dower

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40255>
_______________________________________

From report at bugs.python.org  Mon Apr 13 06:40:14 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 13 Apr 2020 10:40:14 +0000
Subject: [issue40269] Inconsistent complex behavior with (-1j)
In-Reply-To: <1586736208.71.0.129112794549.issue40269@roundup.psfhosted.org>
Message-ID: <1586774414.48.0.629789559394.issue40269@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Another related issue is #23229, where Guido says (in msg233963):

> BTW I don't want repr() of a complex number to use the
> complex(..., ...) notation -- it's too verbose.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40269>
_______________________________________

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: [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 06:47:21 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 13 Apr 2020 10:47:21 +0000
Subject: [issue40241] [C API] Make PyGC_Head structure opaque,
 or even move it to the internal C API
In-Reply-To: <1586445596.83.0.583225080007.issue40241@roundup.psfhosted.org>
Message-ID: <1586774841.3.0.613378900676.issue40241@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 0c13e1f96a9487e0efe63c3d3a05ff9738bd7dac by Victor Stinner in branch 'master':
bpo-40241: Add pycore_interp.h header (GH-19499)
https://github.com/python/cpython/commit/0c13e1f96a9487e0efe63c3d3a05ff9738bd7dac


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40241>
_______________________________________

From report at bugs.python.org  Mon Apr 13 06:47:24 2020
From: report at bugs.python.org (Steve Dower)
Date: Mon, 13 Apr 2020 10:47:24 +0000
Subject: [issue40263] ValueError exception on _winapi.WaitForMultipleObjects
In-Reply-To: <1586715582.96.0.679053084097.issue40263@roundup.psfhosted.org>
Message-ID: <1586774844.75.0.573867358448.issue40263@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

(Created from issue26903)

Yeah, that looks like a reasonable fix :)

----------
title: Follow on bug from https://bugs.python.org/issue26903 (ValueError exception on _winapi.WaitForMultipleObjects) -> ValueError exception on _winapi.WaitForMultipleObjects

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40263>
_______________________________________

From report at bugs.python.org  Mon Apr 13 06:50:48 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 13 Apr 2020 10:50:48 +0000
Subject: [issue40271] Allow shell like paths in
In-Reply-To: <1586774030.36.0.315208521295.issue40271@roundup.psfhosted.org>
Message-ID: <1586775048.1.0.898229310883.issue40271@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

You can use os.path.expanduser to expand tilde. Other os functions don't do it implicitly.

>>> import os
>>> os.path.exists("~/stuff")
False
>>> os.path.exists(os.path.expanduser("~/stuff"))
True

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40271>
_______________________________________

From report at bugs.python.org  Mon Apr 13 07:00:32 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Mon, 13 Apr 2020 11:00:32 +0000
Subject: [issue40176] unterminated string literal tokenization error messages
 could be better
In-Reply-To: <1585936724.82.0.54480834244.issue40176@roundup.psfhosted.org>
Message-ID: <1586775632.34.0.484914062965.issue40176@roundup.psfhosted.org>


Batuhan Taskaya <batuhanosmantaskaya at gmail.com> added the comment:

Fair point. I changed error messages to what you suggested

>>> (300) * 6 + ca(e, 2 +    "dsadsa)
  File "<stdin>", line 1
    (300) * 6 + ca(e, 2 +    "dsadsa)
                             ^
SyntaxError: unterminated string literal

>>> (300) * 6 + ca(e, 2 +    'dsadsa)
  File "<stdin>", line 1
    (300) * 6 + ca(e, 2 +    'dsadsa)
                             ^
SyntaxError: unterminated string literal


>>> (300) * 6 + ca(e, 2 +    """dsadsa
... 
  File "<stdin>", line 1
    (300) * 6 + ca(e, 2 +    """dsadsa
                             ^
SyntaxError: unterminated triple-quoted string literal

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40176>
_______________________________________

From report at bugs.python.org  Mon Apr 13 07:39:24 2020
From: report at bugs.python.org (Steve Dower)
Date: Mon, 13 Apr 2020 11:39:24 +0000
Subject: [issue40214] test_ctypes.test_load_dll_with_flags Windows failure
In-Reply-To: <1586230066.46.0.791582618244.issue40214@roundup.psfhosted.org>
Message-ID: <1586777964.85.0.117614868928.issue40214@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
pull_requests: +18851
pull_request: https://github.com/python/cpython/pull/19500

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40214>
_______________________________________

From report at bugs.python.org  Mon Apr 13 07:49:57 2020
From: report at bugs.python.org (Michael Felt)
Date: Mon, 13 Apr 2020 11:49:57 +0000
Subject: [issue40112] AIX: xlc - default path changed and no longer recognized
In-Reply-To: <1586446421.54.0.830057470257.issue40112@roundup.psfhosted.org>
Message-ID: <5d11b57b-6153-18de-3819-e6ce6dd06683@felt.demon.nl>


Michael Felt <aixtools at felt.demon.nl> added the comment:

Thank you!

On 09/04/2020 17:33, STINNER Victor wrote:
> STINNER Victor <vstinner at python.org> added the comment:
>
> I backported the fix to 3.8 to fix AIX 3.8 buildbots.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue40112>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40112>
_______________________________________

From report at bugs.python.org  Mon Apr 13 07:57:21 2020
From: report at bugs.python.org (Gavin D'souza)
Date: Mon, 13 Apr 2020 11:57:21 +0000
Subject: [issue40271] Allow shell like paths in
In-Reply-To: <1586774030.36.0.315208521295.issue40271@roundup.psfhosted.org>
Message-ID: <1586779041.94.0.64156519685.issue40271@roundup.psfhosted.org>


Gavin D'souza <gavin18d at gmail.com> added the comment:

Thank you @xtreak, I'm aware of "os.path.expanduser" and have used it extensively; I created this issue if we could do something about handling this internally in zipfile too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40271>
_______________________________________

From report at bugs.python.org  Mon Apr 13 08:02:10 2020
From: report at bugs.python.org (Eryk Sun)
Date: Mon, 13 Apr 2020 12:02:10 +0000
Subject: [issue40214] test_ctypes.test_load_dll_with_flags Windows failure
In-Reply-To: <1586230066.46.0.791582618244.issue40214@roundup.psfhosted.org>
Message-ID: <1586779330.85.0.439269631347.issue40214@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> But I'm not sure why that is getting loaded earlier than the 
> current directory. Is that the behaviour we went for here?

I don't understand what's going on here if %PATH% is interfering. The current directory (%__CD__%) should be checked before %PATH% with the standard DLL search order for desktop applcations. That's what I've observed in practice and how it's documented [1]:

    SafeDllSearchMode enabled:

    1. %__APPDIR__%
    2. %SystemRoot%\System32
    3. %SystemRoot%\System
    4. %SystemRoot%
    5. %__CD__%
    6. %PATH%

    SafeDllSearchMode disabled:

    1. %__APPDIR__%
    2. %__CD__%
    3. %SystemRoot%\System32
    4. %SystemRoot%\System
    5. %SystemRoot%
    6. %PATH%

[1]: https://docs.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-search-order#search-order-for-desktop-applications

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40214>
_______________________________________

From report at bugs.python.org  Mon Apr 13 08:07:49 2020
From: report at bugs.python.org (Fran Boon)
Date: Mon, 13 Apr 2020 12:07:49 +0000
Subject: [issue27777] cgi.FieldStorage can't parse simple body with
 Content-Length and no Content-Disposition
In-Reply-To: <1471355745.98.0.805545529346.issue27777@psf.upfronthosting.co.za>
Message-ID: <1586779669.31.0.963788895348.issue27777@roundup.psfhosted.org>


Fran Boon <fran at sahanafoundation.org> added the comment:

What is happening with this bug?
I am amazed that nearly 4 years on it doesn't seem to have been resolved.
The issue took me a fairly long time to debug the cause of, but once known the issue seems relatively simple to resolve & there are a couple of Pull Requests which fix the issue. This is my first time looking into the core of Python's own development (which I guess is a testament to how well this normally works), so I may be being naive, but what is the blocker here? Is there anything I can do to help? Test/Review existing PRs? (They both look good to me)
Create a new PR? (Seems unnecessary)

I really am genuinely keen to help resolve this for at least Python 3.7+ (Am aware that 3.6 is security fixes only)

----------
nosy: +Fran Boon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27777>
_______________________________________

From report at bugs.python.org  Mon Apr 13 08:36:57 2020
From: report at bugs.python.org (Ethan Smith)
Date: Mon, 13 Apr 2020 12:36:57 +0000
Subject: [issue39481] Implement PEP 585 (Type Hinting Generics In Standard
 Collections)
In-Reply-To: <1586769149.87.0.335309517977.issue39481@roundup.psfhosted.org>
Message-ID: <CAMzjp8HyaMihV6iU0J92Mw55aqYvWr2aAuTWGRCVW4Vf1zxoXA@mail.gmail.com>


Ethan Smith <ethan at ethanhs.me> added the comment:

Hm, yeah it appears my methodology was too loose. Thank you for catching
these. I will go through and test the rest (if you haven't yet) later today
and make a PR to revert anything that needs it. Thanks! (and sorry)

On Mon, Apr 13, 2020 at 2:12 AM Serhiy Storchaka <report at bugs.python.org>
wrote:

>
> Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:
>
> I tested the following example:
>
> import ipaddress, mmap
>
> x: ipaddress.IPv4Network[int]
> y: mmap.mmap[int]
>
> MyPy produces errors:
>
> t.py:4: error: "IPv4Network" expects no type arguments, but 1 given
> t.py:5: error: "mmap" expects no type arguments, but 1 given
>
> This is because mmap and IPv4Network are not generic types in typeshed.
> _BaseNetwork and _mmap are generic types, but IPv4Network and mmap are
> normal classes. The former are implementation detail of typeshed. _mmap
> does not exist in the stdlib, and _BaseNetwork in typeshed and the stdlib
> are different things.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue39481>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39481>
_______________________________________

From report at bugs.python.org  Mon Apr 13 08:43:07 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 13 Apr 2020 12:43:07 +0000
Subject: [issue40271] Allow shell like paths in
In-Reply-To: <1586774030.36.0.315208521295.issue40271@roundup.psfhosted.org>
Message-ID: <1586781787.22.0.197525159974.issue40271@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

How would you work with a file in the "~" directory?

Python is a programming language. It provides you builtin blocks which you can combine to get the desired behavior. If you what "~" at the start of the path be expanded to your home directory, you call os.path.expanduser() explicitly. If you want it mean the literal "~" directory, you do not call os.path.expanduser(). Calling it implicitly would break existing code, require you to use ugly workarounds if you don't want to expand "~", and introduce possible security issues.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40271>
_______________________________________

From report at bugs.python.org  Mon Apr 13 08:52:36 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 13 Apr 2020 12:52:36 +0000
Subject: [issue39481] Implement PEP 585 (Type Hinting Generics In Standard
 Collections)
In-Reply-To: <1580231817.93.0.47144630055.issue39481@roundup.psfhosted.org>
Message-ID: <1586782356.53.0.618215234161.issue39481@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

No, I did not check other changes. These two just looked too suspicious.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39481>
_______________________________________

From report at bugs.python.org  Mon Apr 13 09:14:20 2020
From: report at bugs.python.org (Ray Donnelly)
Date: Mon, 13 Apr 2020 13:14:20 +0000
Subject: [issue40263] ValueError exception on _winapi.WaitForMultipleObjects
In-Reply-To: <1586715582.96.0.679053084097.issue40263@roundup.psfhosted.org>
Message-ID: <1586783660.01.0.874704083408.issue40263@roundup.psfhosted.org>


Change by Ray Donnelly <mingw.android at gmail.com>:


----------
nosy: +Ray.Donnelly
nosy_count: 5.0 -> 6.0
pull_requests: +18852
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19501

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40263>
_______________________________________

From report at bugs.python.org  Mon Apr 13 09:27:13 2020
From: report at bugs.python.org (Ray Donnelly)
Date: Mon, 13 Apr 2020 13:27:13 +0000
Subject: [issue40263] ValueError exception on _winapi.WaitForMultipleObjects
In-Reply-To: <1586715582.96.0.679053084097.issue40263@roundup.psfhosted.org>
Message-ID: <1586784433.62.0.746786471415.issue40263@roundup.psfhosted.org>


Ray Donnelly <rdonnelly at anaconda.com> added the comment:

https://github.com/python/cpython/pull/19501

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40263>
_______________________________________

From report at bugs.python.org  Mon Apr 13 09:34:03 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Mon, 13 Apr 2020 13:34:03 +0000
Subject: [issue40244] AIX: build: _PyObject_GC_TRACK Asstertion failure
In-Reply-To: <1586507316.69.0.786578254213.issue40244@roundup.psfhosted.org>
Message-ID: <1586784843.29.0.485644534769.issue40244@roundup.psfhosted.org>


Batuhan Taskaya <batuhanosmantaskaya at gmail.com> added the comment:

Oh, looks like the problem is --without-computed-gotos, I just tried 2 times one is with --without-computed-gotos and one is not. I could successfully reproduce the problem with it. I'll continue triaging.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40244>
_______________________________________

From report at bugs.python.org  Mon Apr 13 09:36:26 2020
From: report at bugs.python.org (Ray Donnelly)
Date: Mon, 13 Apr 2020 13:36:26 +0000
Subject: [issue26903] ProcessPoolExecutor(max_workers=64) crashes on Windows
In-Reply-To: <1462135538.41.0.857077084248.issue26903@psf.upfronthosting.co.za>
Message-ID: <1586784986.8.0.707752213317.issue26903@roundup.psfhosted.org>


Ray Donnelly <rdonnelly at anaconda.com> added the comment:

I took the liberty of filing this: https://bugs.python.org/issue40263

Cheers.

----------
nosy: +Ray Donnelly

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26903>
_______________________________________

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: [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 09:57:05 2020
From: report at bugs.python.org (jack1142)
Date: Mon, 13 Apr 2020 13:57:05 +0000
Subject: [issue40273] mappingproxy isn't reversible
In-Reply-To: <1586786082.33.0.84219610791.issue40273@roundup.psfhosted.org>
Message-ID: <1586786225.86.0.767064222764.issue40273@roundup.psfhosted.org>


Change by jack1142 <kuba.kuczys at gmail.com>:


----------
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40273>
_______________________________________

From report at bugs.python.org  Mon Apr 13 10:39:42 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 13 Apr 2020 14:39:42 +0000
Subject: [issue40273] mappingproxy isn't reversible
In-Reply-To: <1586786082.33.0.84219610791.issue40273@roundup.psfhosted.org>
Message-ID: <1586788782.73.0.45688747593.issue40273@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40273>
_______________________________________

From report at bugs.python.org  Mon Apr 13 10:47:03 2020
From: report at bugs.python.org (Steve Dower)
Date: Mon, 13 Apr 2020 14:47:03 +0000
Subject: [issue40214] test_ctypes.test_load_dll_with_flags Windows failure
In-Reply-To: <1586230066.46.0.791582618244.issue40214@roundup.psfhosted.org>
Message-ID: <1586789223.8.0.19580790411.issue40214@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

> I don't understand what's going on here if %PATH% is interfering.

Yeah, as shown by the fact my fix didn't fix it :)

I'm going to try adding some more diagnostics around this to find out exactly where it's failing. I suspect it's a dependency, rather than the direct file.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40214>
_______________________________________

From report at bugs.python.org  Mon Apr 13 10:47:33 2020
From: report at bugs.python.org (Zackery Spytz)
Date: Mon, 13 Apr 2020 14:47:33 +0000
Subject: [issue32033] The pwd module implementation incorrectly sets some
 attributes to None
In-Reply-To: <1510742059.52.0.213398074469.issue32033@psf.upfronthosting.co.za>
Message-ID: <1586789253.39.0.611173169903.issue32033@roundup.psfhosted.org>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
keywords: +patch
nosy: +ZackerySpytz
nosy_count: 3.0 -> 4.0
pull_requests: +18853
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/19502

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32033>
_______________________________________

From report at bugs.python.org  Mon Apr 13 10:49:04 2020
From: report at bugs.python.org (Zackery Spytz)
Date: Mon, 13 Apr 2020 14:49:04 +0000
Subject: [issue32033] The pwd module implementation incorrectly sets some
 attributes to None
In-Reply-To: <1510742059.52.0.213398074469.issue32033@psf.upfronthosting.co.za>
Message-ID: <1586789344.94.0.591721167946.issue32033@roundup.psfhosted.org>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
versions: +Python 3.8, Python 3.9 -Python 2.7, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32033>
_______________________________________

From report at bugs.python.org  Mon Apr 13 07:46:43 2020
From: report at bugs.python.org (Michael Felt)
Date: Mon, 13 Apr 2020 11:46:43 +0000
Subject: [issue40244] AIX: build: _PyObject_GC_TRACK Asstertion failure
In-Reply-To: <1586610828.43.0.531844167992.issue40244@roundup.psfhosted.org>
Message-ID: <95fdda4b-4484-e002-551a-c38a9441d74f@felt.demon.nl>


Michael Felt <aixtools at felt.demon.nl> added the comment:

After my build I have the following:

$ ./python -m test.pythoninfo|grep -E 'CFLAGS|CC|OPT|LDFLAGS'
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? : 30084150
object refcount : 0
object type???? : 20013710
object type name: generator
object repr???? : <refcnt 0 at 30084150>

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
ksh: 22151670 IOT/Abort trap(coredump)

See attached file for the script capture.

On 11/04/2020 15:13, Batuhan Taskaya wrote:
> Batuhan Taskaya <batuhanosmantaskaya at gmail.com> added the comment:
>
> I've just compiled python with (xlc 16.1.0, debug build) and can't experience that compile failure, can you give a specific spot that failure happens?
>
> -bash-4.4$ ./python -m test.pythoninfo|grep -E 'CFLAGS|CC|OPT|LDFLAGS'
> sysconfig[CC]: /opt/IBM/xlc/16.1.0/bin/xlc_r
> sysconfig[CFLAGS]: -DNDEBUG -O
> sysconfig[CONFIG_ARGS]: 'CC=/opt/IBM/xlc/16.1.0/bin/xlc_r'
> sysconfig[OPT]: -DNDEBUG -O
> sysconfig[PY_CFLAGS]: -DNDEBUG -O
> sysconfig[PY_CFLAGS_NODIST]: -I./Include/internal
> sysconfig[PY_STDMODULE_CFLAGS]: -DNDEBUG -O -I./Include/internal -I. -I./Include
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue40244>
> _______________________________________
>

----------
Added file: https://bugs.python.org/file49058/issue40170.txt

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40244>
_______________________________________
-------------- next part --------------
Script command is started on Mon Apr 13	06:29:37 CDT 2020.
$ .kxlc16-envc166xlc16
$ echo $PATH $CC
/opt/IBM/xlc/16.1.0/bin:/usr/bin:/etc:/usr/sbin:/usr/ucb:/usr/bin/X11:/sbin:/usr/java7_64/jre/bin:/usr/java7_64/bin:/home/aixtools/bin xlc_r
$ updategit
Checking out files: 100% (160/160), done.
Previous HEAD position was 0003c2d... bpo-40096: Support __attribute__((__noreturn__)) on xlc (GH-19204)
Switched to branch 'master'
Your branch is up-to-date with 'upstream/master'.
remote:	Enumerating objects: 610, done.K
remote:	Counting objects: 100% (610/610), done.K
remote:	Compressing objects: 100% (2/2), done.K
remote:nTotale775:(delta(608),7reused 609 (delta 608), pack-reused 165K
Receiving objects: 100%	(775/775), 533.45 KiB |	0 bytes/s, done.
Resolving deltas: 100% (645/645), completed with 287 local objects.
>From https://github.com/python/cpython
   38aefc5..0c13e1f  master	-> upstream/master
   8a0a500..7a41638  2.7	-> upstream/2.7
   44c1cdd..0a9ec9f  3.7	-> upstream/3.7
   f7b0259..ee691b0  3.8	-> upstream/3.8
 * [new	tag]	     v2.7.18rc1	-> v2.7.18rc1
>From https://github.com/python/cpython
 * branch	     master	-> FETCH_HEAD
Updating 38aefc5..0c13e1f
Checking out files: 100% (195/195), done.
Fast-forward
 Doc/c-api/gcsupport.rst						     |	 18 
 Doc/howto/unicode.rst							     |	  5 
 Doc/library/dis.rst							     |	  6 
 Doc/library/multiprocessing.rst					     |	 13 
 Doc/library/socket.rst							     |	 11 
 Doc/library/ssl.rst							     |	  3 
 Doc/library/threading.rst						     |	  8 -
 Doc/whatsnew/3.9.rst							     |	 28 
 Include/Python.h							     |	  1 
 Include/cpython/abstract.h						     |	 10 
 Include/cpython/objimpl.h						     |	111 
 Include/cpython/pystate.h						     |	  7 
 Include/errcode.h							     |	  1 
 Include/genericaliasobject.h						     |	 14 
 Include/internal/pycore_abstract.h					     |	 22 
 Include/internal/pycore_ceval.h					     |	 11 
 Include/internal/pycore_gc.h						     |	 69 ++
 Include/internal/pycore_interp.h					     |	183 ++++
 Include/internal/pycore_object.h					     |	 11 
 Include/internal/pycore_pymem.h					     |	  3 
 Include/internal/pycore_pystate.h					     |	298 -----
 Include/internal/pycore_runtime.h					     |	143 +++
 Include/object.h							     |	  6 
 Include/objimpl.h							     |	 72 
 Include/pythread.h							     |	  9 
 Lib/_collections_abc.py						     |	 27 
 Lib/concurrent/futures/_base.py					     |	  3 
 Lib/concurrent/futures/thread.py					     |	  3 
 Lib/contextlib.py							     |	  6 
 Lib/ctypes/__init__.py							     |	  3 
 Lib/ctypes/test/test_loading.py					     |	  7 
 Lib/difflib.py								     |	  4 
 Lib/filecmp.py								     |	  4 
 Lib/fileinput.py							     |	  3 
 Lib/http/cookies.py							     |	  3 
 Lib/ipaddress.py							     |	  6 
 Lib/multiprocessing/managers.py					     |	  3 
 Lib/multiprocessing/pool.py						     |	  3 
 Lib/multiprocessing/queues.py						     |	  3 
 Lib/multiprocessing/shared_memory.py					     |	  3 
 Lib/os.py								     |	  5 
 Lib/queue.py								     |	  5 
 Lib/subprocess.py							     |	 24 
 Lib/symtable.py							     |	  2 
 Lib/tempfile.py							     |	 15 
 Lib/test/lock_tests.py							     |	 30 
 Lib/test/support/__init__.py						     |	  4 
 Lib/test/test_c_locale_coercion.py					     |	  4 
 Lib/test/test_descrtut.py						     |	  1 
 Lib/test/test_doctest.py						     |	  2 
 Lib/test/test_fstring.py						     |	  9 
 Lib/test/test_genericalias.py						     |	249 +++++
 Lib/test/test_os.py							     |	  3 
 Lib/test/test_subprocess.py						     |	  5 
 Lib/test/test_symtable.py						     |	  6 
 Lib/test/test_sys.py							     |	  4 
 Lib/test/test_tempfile.py						     |	  5 
 Lib/test/test_threading.py						     |	 42 
 Lib/test/test_types.py							     |	  1 
 Lib/test/test_typing.py						     |	 47 
 Lib/test/test_xml_etree.py						     |	  5 
 Lib/test/test_xml_etree_c.py						     |	 15 
 Lib/threading.py							     |	 25 
 Lib/types.py								     |	  3 
 Lib/typing.py								     |	145 --
 Lib/unittest/case.py							     |	  2 
 Lib/unittest/mock.py							     |	 74 
 Lib/unittest/test/testmock/testpatch.py				     |	  2 
 Lib/urllib/parse.py							     |	  3 
 Lib/xml/dom/minidom.py							     |	 23 
 Lib/xml/etree/ElementTree.py						     |	 14 
 Makefile.pre.in							     |	  4 
 Misc/ACKS								     |	  1 
 Misc/NEWS.d/next/C API/2020-04-04-23-51-59.bpo-40170.uXQ701.rst	     |	  3 
 Misc/NEWS.d/next/C API/2020-04-05-00-02-13.bpo-40170.IFsGZ-.rst	     |	  3 
 Misc/NEWS.d/next/C API/2020-04-05-00-21-38.bpo-40170.Tx0vy6.rst	     |	  4 
 Misc/NEWS.d/next/C API/2020-04-05-00-37-34.bpo-40170.Seuh3D.rst	     |	  4 
 Misc/NEWS.d/next/C API/2020-04-10-19-43-04.bpo-40241.Xm3w-1.rst	     |	  4 
 Misc/NEWS.d/next/C API/2020-04-13-02-56-24.bpo-40241._FOf7E.rst	     |	  1 
 Misc/NEWS.d/next/Core and Builtins/2020-01-28-17-19-18.bpo-39481.rqSeGl.rst |	  1 
 Misc/NEWS.d/next/Core and Builtins/2020-04-07-15-44-29.bpo-37388.stlxBq.rst |	  4 
 Misc/NEWS.d/next/Core and Builtins/2020-04-08-22-33-24.bpo-40082.WI3-lu.rst |	  2 
 Misc/NEWS.d/next/Core and Builtins/2020-04-11-17-52-03.bpo-40246.vXPze5.rst |	  1 
 Misc/NEWS.d/next/Documentation/2019-09-25-23-20-55.bpo-13743.5ToLDy.rst     |	  1 
 Misc/NEWS.d/next/Library/2017-10-14-21-02-40.bpo-31758.563ZZb.rst	     |	  2 
 Misc/NEWS.d/next/Library/2020-02-12-01-48-51.bpo-39011.hGve_t.rst	     |	  3 
 Misc/NEWS.d/next/Library/2020-03-19-16-33-03.bpo-39953.yy5lC_.rst	     |	  1 
 Misc/NEWS.d/next/Library/2020-03-27-08-57-46.bpo-25780.kIjVge.rst	     |	  1 
 Misc/NEWS.d/next/Library/2020-03-27-16-54-29.bpo-40089.VTq_8s.rst	     |	  6 
 Misc/NEWS.d/next/Library/2020-04-04-00-47-40.bpo-40126.Y-bTNP.rst	     |	  3 
 Misc/NEWS.d/next/Library/2020-04-06-11-05-13.bpo-40196.Jqowse.rst	     |	  2 
 Misc/NEWS.d/next/Library/2020-04-07-18-06-38.bpo-40149.mMU2iu.rst	     |	  1 
 Misc/NEWS.d/next/Library/2020-04-10-16-13-47.bpo-40234.tar4d_.rst	     |	  2 
 Misc/NEWS.d/next/Tests/2020-04-09-16-29-18.bpo-31904.ej348T.rst	     |	  1 
 Modules/_abc.c								     |	 26 
 Modules/_collectionsmodule.c						     |	  4 
 Modules/_csv.c								     |	  8 
 Modules/_ctypes/_ctypes.c						     |	 10 
 Modules/_ctypes/callproc.c						     |	  2 
 Modules/_ctypes/cfield.c						     |	  4 
 Modules/_curses_panel.c						     |	  2 
 Modules/_cursesmodule.c						     |	 10 
 Modules/_decimal/_decimal.c						     |	  4 
 Modules/_elementtree.c							     |	 28 
 Modules/_io/_iomodule.c						     |	  3 
 Modules/_io/bytesio.c							     |	  4 
 Modules/_io/iobase.c							     |	  3 
 Modules/_io/textio.c							     |	 15 
 Modules/_json.c							     |	 18 
 Modules/_localemodule.c						     |	  2 
 Modules/_operator.c							     |	  2 
 Modules/_pickle.c							     |	  2 
 Modules/_queuemodule.c							     |	  2 
 Modules/_sqlite/connection.c						     |	  4 
 Modules/_sre.c								     |	 24 
 Modules/_ssl.c								     |	  2 
 Modules/_ssl_data.h							     | 6499 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-------------------
 Modules/_struct.c							     |	  4 
 Modules/_testcapimodule.c						     |	  3 
 Modules/_testinternalcapi.c						     |	 17 
 Modules/_threadmodule.c						     |	 91 
 Modules/_tkinter.c							     |	  4 
 Modules/cjkcodecs/cjkcodecs.h						     |	  2 
 Modules/cjkcodecs/multibytecodec.c					     |	  6 
 Modules/cjkcodecs/multibytecodec.h					     |	  2 
 Modules/clinic/_threadmodule.c.h					     |	 22 -
 Modules/gcmodule.c							     |	 18 
 Modules/itertoolsmodule.c						     |	  2 
 Modules/main.c								     |	  4 
 Modules/mmapmodule.c							     |	  2 
 Modules/posixmodule.c							     |	  5 
 Modules/pyexpat.c							     |	  2 
 Modules/readline.c							     |	  4 
 Modules/signalmodule.c							     |	 27 
 Modules/socketmodule.c							     |	  3 
 Modules/sre.h								     |	 14 
 Modules/sre_lib.h							     |	 28 
 Modules/unicodedata.c							     |	  6 
 Objects/abstract.c							     |	 34 
 Objects/bytearrayobject.c						     |	 14 
 Objects/bytes_methods.c						     |	  3 
 Objects/bytesobject.c							     |	 37 
 Objects/capsule.c							     |	  2 
 Objects/codeobject.c							     |	  2 
 Objects/descrobject.c							     |	  2 
 Objects/dictobject.c							     |	  1 
 Objects/enumobject.c							     |	  2 
 Objects/exceptions.c							     |	  4 
 Objects/fileobject.c							     |	  2 
 Objects/genericaliasobject.c						     |	507 +++++++++
 Objects/genobject.c							     |	  2 
 Objects/interpreteridobject.c						     |	  5 
 Objects/listobject.c							     |	  6 
 Objects/longobject.c							     |	  2 
 Objects/memoryobject.c							     |	  8 
 Objects/moduleobject.c							     |	  4 
 Objects/object.c							     |	 19 
 Objects/rangeobject.c							     |	  5 
 Objects/setobject.c							     |	  2 
 Objects/sliceobject.c							     |	  3 
 Objects/stringlib/codecs.h						     |	  2 
 Objects/stringlib/join.h						     |	  4 
 Objects/tupleobject.c							     |	  4 
 Objects/typeobject.c							     |	 60 
 Objects/unicodeobject.c						     |	326 +++---
 PC/_msi.c								     |	  8 
 PC/python3.def								     |	  2 
 PC/winreg.c								     |	  2 
 PCbuild/pythoncore.vcxproj						     |	  4 
 PCbuild/pythoncore.vcxproj.filters					     |	  9 
 Parser/tokenizer.c							     |	  4 
 Python/_warnings.c							     |	  4 
 Python/ast.c								     |	  2 
 Python/bltinmodule.c							     |	  2 
 Python/ceval.c								     |	219 ++--
 Python/ceval_gil.h							     |	 16 
 Python/codecs.c							     |	 26 
 Python/compile.c							     |	  4 
 Python/dynload_hpux.c							     |	  3 
 Python/fileutils.c							     |	  2 
 Python/formatter_unicode.c						     |	  6 
 Python/getargs.c							     |	  2 
 Python/import.c							     |	 12 
 Python/initconfig.c							     |	  4 
 Python/modsupport.c							     |	  3 
 Python/pylifecycle.c							     |	 78 
 Python/pystate.c							     |	 54 
 Python/pythonrun.c							     |	  7 
 Python/sysmodule.c							     |	 15 
 Python/thread_pthread.h						     |	 20 
 Python/traceback.c							     |	  4 
 Tools/ssl/make_ssl_data.py						     |	 27 
 configure								     |	 30 
 configure.ac								     |	 10 
 pyconfig.h.in								     |	  3 
 195 files changed, 8182 insertions(+),	2379 deletions(-)
 create	mode 100644 Include/genericaliasobject.h
 create	mode 100644 Include/internal/pycore_abstract.h
 create	mode 100644 Include/internal/pycore_gc.h
 create	mode 100644 Include/internal/pycore_interp.h
 create	mode 100644 Include/internal/pycore_runtime.h
 create	mode 100644 Lib/test/test_genericalias.py
 create	mode 100644 Misc/NEWS.d/next/C API/2020-04-04-23-51-59.bpo-40170.uXQ701.rst
 create	mode 100644 Misc/NEWS.d/next/C API/2020-04-05-00-02-13.bpo-40170.IFsGZ-.rst
 create	mode 100644 Misc/NEWS.d/next/C API/2020-04-05-00-21-38.bpo-40170.Tx0vy6.rst
 create	mode 100644 Misc/NEWS.d/next/C API/2020-04-05-00-37-34.bpo-40170.Seuh3D.rst
 create	mode 100644 Misc/NEWS.d/next/C API/2020-04-10-19-43-04.bpo-40241.Xm3w-1.rst
 create	mode 100644 Misc/NEWS.d/next/C API/2020-04-13-02-56-24.bpo-40241._FOf7E.rst
 create	mode 100644 Misc/NEWS.d/next/Core and Builtins/2020-01-28-17-19-18.bpo-39481.rqSeGl.rst
 create	mode 100644 Misc/NEWS.d/next/Core and Builtins/2020-04-07-15-44-29.bpo-37388.stlxBq.rst
 create	mode 100644 Misc/NEWS.d/next/Core and Builtins/2020-04-08-22-33-24.bpo-40082.WI3-lu.rst
 create	mode 100644 Misc/NEWS.d/next/Core and Builtins/2020-04-11-17-52-03.bpo-40246.vXPze5.rst
 create	mode 100644 Misc/NEWS.d/next/Documentation/2019-09-25-23-20-55.bpo-13743.5ToLDy.rst
 create	mode 100644 Misc/NEWS.d/next/Library/2017-10-14-21-02-40.bpo-31758.563ZZb.rst
 create	mode 100644 Misc/NEWS.d/next/Library/2020-02-12-01-48-51.bpo-39011.hGve_t.rst
 create	mode 100644 Misc/NEWS.d/next/Library/2020-03-19-16-33-03.bpo-39953.yy5lC_.rst
 create	mode 100644 Misc/NEWS.d/next/Library/2020-03-27-08-57-46.bpo-25780.kIjVge.rst
 create	mode 100644 Misc/NEWS.d/next/Library/2020-03-27-16-54-29.bpo-40089.VTq_8s.rst
 create	mode 100644 Misc/NEWS.d/next/Library/2020-04-04-00-47-40.bpo-40126.Y-bTNP.rst
 create	mode 100644 Misc/NEWS.d/next/Library/2020-04-06-11-05-13.bpo-40196.Jqowse.rst
 create	mode 100644 Misc/NEWS.d/next/Library/2020-04-07-18-06-38.bpo-40149.mMU2iu.rst
 create	mode 100644 Misc/NEWS.d/next/Library/2020-04-10-16-13-47.bpo-40234.tar4d_.rst
 create	mode 100644 Misc/NEWS.d/next/Tests/2020-04-09-16-29-18.bpo-31904.ej348T.rst
 delete	mode 100644 Modules/clinic/_threadmodule.c.h
 create	mode 100644 Objects/genericaliasobject.c
$ make distclean
make: 1254-002 Cannot find a rule to create target distclean from dependencies.
Stop.
$ ls -l	Makefile
ls: 0653-341 The file Makefile does not	exist.
$ pwd
/home/aixtools/python/cpython-master
$ ./configuree--without-computed-gotoso--with-pydebugc&&ptime-makes-j10ith-pydebugg&&&timeemakee-j10000000000000000000000
checking for git... found
checking build system type... powerpc-ibm-aix7.2.0.0
checking host system type... powerpc-ibm-aix7.2.0.0
checking for python3.9... no
checking for python3...	python3
checking for --enable-universalsdk... no
checking for --with-universal-archs... no
checking MACHDEP... "aix"
checking for gcc... xlc_r
checking whether the C compiler	works... yes
checking for C compiler	default	output file name... a.out
checking for suffix of executables...
checking whether we are	cross compiling... no
checking for suffix of object files... o
checking whether we are	using the GNU C	compiler... no
checking whether xlc_r accepts -g... yes
checking for xlc_r option to accept ISO	C89... none needed
checking how to	run the	C preprocessor... xlc_r	-E
checking for grep that handles long lines and -e... /usr/bin/grep
checking for a sed that	does not truncate output... /usr/bin/sed
checking for --with-cxx-main=<compiler>... no
checking for c++... c++
configure:

  By default, distutils	will build C++ extension modules with "c++".
  If this is not intended, then	set CXX	on the configure command line.

checking for the platform triplet based	on compiler characteristics... none
checking for -Wl,--no-as-needed... no
checking for egrep... /usr/bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking minix/config.h	usability... no
checking minix/config.h	presence... no
checking for minix/config.h... no
checking whether it is safe to define __EXTENSIONS__...	yes
checking for the Android API level... not Android
checking for --with-suffix...
checking for case-insensitive build directory... no
checking LIBRARY... libpython$(VERSION)$(ABIFLAGS).a
checking LINKCC... $(srcdir)/Modules/makexp_aix	Modules/python.exp . $(LIBRARY); $(PURIFY) $(MAINCC)
checking for GNU ld... no
checking for --enable-shared...	no
checking for --enable-profiling... no
checking LDLIBRARY... libpython$(VERSION)$(ABIFLAGS).a
checking for ar... ar
checking for readelf...	no
checking for a BSD-compatible install... ./install-sh -c
checking for a thread-safe mkdir -p... ./install-sh -c -d
checking for --with-pydebug... yes
checking for --with-trace-refs... no
checking for --with-assertions... implied by --with-pydebug
checking for --enable-optimizations... no
checking PROFILE_TASK... -m test --pgo
checking for --with-lto... no
checking for llvm-profdata... no
checking whether pthreads are available	without	options... yes
checking whether c++ also accepts flags	for thread support... no
checking for ANSI C header files... (cached) yes
checking asm/types.h usability... no
checking asm/types.h presence... no
checking for asm/types.h... no
checking crypt.h usability... yes
checking crypt.h presence... yes
checking for crypt.h...	yes
checking conio.h usability... no
checking conio.h presence... no
checking for conio.h...	no
checking direct.h usability... no
checking direct.h presence... no
checking for direct.h... no
checking dlfcn.h usability... yes
checking dlfcn.h presence... yes
checking for dlfcn.h...	yes
checking errno.h usability... yes
checking errno.h presence... yes
checking for errno.h...	yes
checking fcntl.h usability... yes
checking fcntl.h presence... yes
checking for fcntl.h...	yes
checking grp.h usability... yes
checking grp.h presence... yes
checking for grp.h... yes
checking ieeefp.h usability... no
checking ieeefp.h presence... no
checking for ieeefp.h... no
checking io.h usability... no
checking io.h presence... no
checking for io.h... no
checking langinfo.h usability... yes
checking langinfo.h presence...	yes
checking for langinfo.h... yes
checking libintl.h usability...	yes
checking libintl.h presence... yes
checking for libintl.h... yes
checking process.h usability...	no
checking process.h presence... no
checking for process.h... no
checking pthread.h usability...	yes
checking pthread.h presence... yes
checking for pthread.h... yes
checking sched.h usability... yes
checking sched.h presence... yes
checking for sched.h...	yes
checking shadow.h usability... no
checking shadow.h presence... no
checking for shadow.h... no
checking signal.h usability... yes
checking signal.h presence... yes
checking for signal.h... yes
checking stropts.h usability...	yes
checking stropts.h presence... yes
checking for stropts.h... yes
checking termios.h usability...	yes
checking termios.h presence... yes
checking for termios.h... yes
checking utime.h usability... yes
checking utime.h presence... yes
checking for utime.h...	yes
checking poll.h	usability... yes
checking poll.h	presence... yes
checking for poll.h... yes
checking sys/devpoll.h usability... no
checking sys/devpoll.h presence... no
checking for sys/devpoll.h... no
checking sys/epoll.h usability... no
checking sys/epoll.h presence... no
checking for sys/epoll.h... no
checking sys/poll.h usability... yes
checking sys/poll.h presence...	yes
checking for sys/poll.h... yes
checking sys/audioio.h usability... no
checking sys/audioio.h presence... no
checking for sys/audioio.h... no
checking sys/xattr.h usability... no
checking sys/xattr.h presence... no
checking for sys/xattr.h... no
checking sys/bsdtty.h usability... no
checking sys/bsdtty.h presence... no
checking for sys/bsdtty.h... no
checking sys/event.h usability... no
checking sys/event.h presence... no
checking for sys/event.h... no
checking sys/file.h usability... yes
checking sys/file.h presence...	yes
checking for sys/file.h... yes
checking sys/ioctl.h usability... yes
checking sys/ioctl.h presence... yes
checking for sys/ioctl.h... yes
checking sys/kern_control.h usability... no
checking sys/kern_control.h presence...	no
checking for sys/kern_control.h... no
checking sys/loadavg.h usability... no
checking sys/loadavg.h presence... no
checking for sys/loadavg.h... no
checking sys/lock.h usability... yes
checking sys/lock.h presence...	yes
checking for sys/lock.h... yes
checking sys/mkdev.h usability... no
checking sys/mkdev.h presence... no
checking for sys/mkdev.h... no
checking sys/modem.h usability... no
checking sys/modem.h presence... no
checking for sys/modem.h... no
checking sys/param.h usability... yes
checking sys/param.h presence... yes
checking for sys/param.h... yes
checking sys/random.h usability... no
checking sys/random.h presence... no
checking for sys/random.h... no
checking sys/select.h usability... yes
checking sys/select.h presence... yes
checking for sys/select.h... yes
checking sys/sendfile.h	usability... no
checking sys/sendfile.h	presence... no
checking for sys/sendfile.h... no
checking sys/socket.h usability... yes
checking sys/socket.h presence... yes
checking for sys/socket.h... yes
checking sys/statvfs.h usability... yes
checking sys/statvfs.h presence... yes
checking for sys/statvfs.h... yes
checking for sys/stat.h... (cached) yes
checking sys/syscall.h usability... no
checking sys/syscall.h presence... no
checking for sys/syscall.h... no
checking sys/sys_domain.h usability... no
checking sys/sys_domain.h presence... no
checking for sys/sys_domain.h... no
checking sys/termio.h usability... yes
checking sys/termio.h presence... yes
checking for sys/termio.h... yes
checking sys/time.h usability... yes
checking sys/time.h presence...	yes
checking for sys/time.h... yes
checking sys/times.h usability... yes
checking sys/times.h presence... yes
checking for sys/times.h... yes
checking for sys/types.h... (cached) yes
checking sys/uio.h usability...	yes
checking sys/uio.h presence... yes
checking for sys/uio.h... yes
checking sys/un.h usability... yes
checking sys/un.h presence... yes
checking for sys/un.h... yes
checking sys/utsname.h usability... yes
checking sys/utsname.h presence... yes
checking for sys/utsname.h... yes
checking sys/wait.h usability... yes
checking sys/wait.h presence...	yes
checking for sys/wait.h... yes
checking pty.h usability... no
checking pty.h presence... no
checking for pty.h... no
checking libutil.h usability...	no
checking libutil.h presence... no
checking for libutil.h... no
checking sys/resource.h	usability... yes
checking sys/resource.h	presence... yes
checking for sys/resource.h... yes
checking netpacket/packet.h usability... no
checking netpacket/packet.h presence...	no
checking for netpacket/packet.h... no
checking sysexits.h usability... yes
checking sysexits.h presence...	yes
checking for sysexits.h... yes
checking bluetooth.h usability... no
checking bluetooth.h presence... no
checking for bluetooth.h... no
checking linux/tipc.h usability... no
checking linux/tipc.h presence... no
checking for linux/tipc.h... no
checking linux/random.h	usability... no
checking linux/random.h	presence... no
checking for linux/random.h... no
checking spawn.h usability... yes
checking spawn.h presence... yes
checking for spawn.h...	yes
checking util.h	usability... no
checking util.h	presence... no
checking for util.h... no
checking alloca.h usability... yes
checking alloca.h presence... yes
checking for alloca.h... yes
checking endian.h usability... no
checking endian.h presence... no
checking for endian.h... no
checking sys/endian.h usability... no
checking sys/endian.h presence... no
checking for sys/endian.h... no
checking sys/sysmacros.h usability... yes
checking sys/sysmacros.h presence... yes
checking for sys/sysmacros.h...	yes
checking linux/memfd.h usability... no
checking linux/memfd.h presence... no
checking for linux/memfd.h... no
checking linux/wait.h usability... no
checking linux/wait.h presence... no
checking for linux/wait.h... no
checking sys/memfd.h usability... no
checking sys/memfd.h presence... no
checking for sys/memfd.h... no
checking sys/mman.h usability... yes
checking sys/mman.h presence...	yes
checking for sys/mman.h... yes
checking for dirent.h that defines DIR... yes
checking for library containing	opendir... none	required
checking whether sys/types.h defines makedev...	no
checking for sys/mkdev.h... (cached) no
checking for sys/sysmacros.h...	(cached) yes
checking bluetooth/bluetooth.h usability... no
checking bluetooth/bluetooth.h presence... no
checking for bluetooth/bluetooth.h... no
checking for net/if.h... yes
checking for linux/netlink.h...	no
checking for linux/qrtr.h... no
checking for linux/vm_sockets.h... no
checking for linux/can.h... no
checking for linux/can/raw.h...	no
checking for linux/can/bcm.h...	no
checking for clock_t in	time.h... yes
checking for makedev...	yes
checking for le64toh...	no
checking for mode_t... yes
checking for off_t... yes
checking for pid_t... yes
checking for size_t... yes
checking for uid_t in sys/types.h... yes
checking for ssize_t...	yes
checking for __uint128_t... no
checking size of int...	4
checking size of long... 4
checking size of long long... 8
checking size of void *... 4
checking size of short... 2
checking size of float... 4
checking size of double... 8
checking size of fpos_t... 8
checking size of size_t... 4
checking size of pid_t... 4
checking size of uintptr_t... 4
checking for long double... yes
checking size of long double...	8
checking size of _Bool... 1
checking size of off_t... 8
checking whether to enable large file support... yes
checking size of time_t... 4
checking for pthread_t... yes
checking size of pthread_t... 4
checking size of pthread_key_t... 4
checking whether pthread_key_t is compatible with int... yes
checking for --enable-framework... no
checking for dyld... no
checking the extension of shared libraries... .so
checking LDSHARED... $(LIBPL)/ld_so_aix	$(CC) -bI:$(LIBPL)/python.exp
checking CCSHARED...
checking LINKFORSHARED... -Wl,-bE:Modules/python.exp -lld
checking CFLAGSFORSHARED...
checking SHLIBS... $(LIBS)
checking for sendfile in -lsendfile... no
checking for dlopen in -ldl... yes
checking for shl_load in -ldld... no
checking uuid/uuid.h usability... no
checking uuid/uuid.h presence... no
checking for uuid/uuid.h... no
checking uuid.h	usability... yes
checking uuid.h	presence... yes
checking for uuid.h... yes
checking for uuid_generate_time_safe...	no
checking for uuid_create... yes
checking for uuid_enc_be... no
checking for library containing	sem_init... none required
checking for textdomain	in -lintl... yes
checking for genuine AIX C++ extensions	support... yes
checking for the system	builddate... 1543
checking aligned memory	access is required... no
checking for --with-hash-algorithm... default
checking for --with-address-sanitizer... no
checking for --with-memory-sanitizer...	no
checking for --with-undefined-behavior-sanitizer... no
checking for t_open in -lnsl...	no
checking for socket in -lsocket... no
checking for --with-libs... no
checking for pkg-config... /usr/bin/pkg-config
checking pkg-config is at least	version	0.9.0... yes
checking for --with-system-expat... no
checking for --with-system-ffi... yes
checking for --with-system-libmpdec... no
checking for --with-decimal-contextvar... yes
checking for --enable-loadable-sqlite-extensions... no
checking for --with-tcltk-includes... default
checking for --with-tcltk-libs... default
checking for --with-dbmliborder...
checking if PTHREAD_SCOPE_SYSTEM is supported... yes
checking for pthread_sigmask...	yes
checking for pthread_getcpuclockid... yes
checking if --enable-ipv6 is specified... yes
checking if RFC2553 API	is available...	yes
checking ipv6 stack type... unknown
checking for CAN_RAW_FD_FRAMES... no
checking for CAN_RAW_JOIN_FILTERS... no
checking for --with-doc-strings... yes
checking for --with-pymalloc...	yes
checking for --with-c-locale-coercion... yes
checking for --with-valgrind...	no
checking for --with-dtrace... no
checking for dlopen... yes
checking DYNLOADFILE...	dynload_shlib.o
checking MACHDEP_OBJS... none
checking for alarm... yes
checking for accept4...	no
checking for setitimer... yes
checking for getitimer... yes
checking for bind_textdomain_codeset...	yes
checking for chown... yes
checking for clock... yes
checking for confstr...	yes
checking for copy_file_range...	no
checking for ctermid...	yes
checking for dup3... no
checking for execv... yes
checking for explicit_bzero... no
checking for explicit_memset...	no
checking for faccessat... yes
checking for fchmod... yes
checking for fchmodat... yes
checking for fchown... yes
checking for fchownat... yes
checking for fdwalk... no
checking for fexecve...	yes
checking for fdopendir... yes
checking for fork... yes
checking for fpathconf... yes
checking for fstatat...	yes
checking for ftime... yes
checking for ftruncate... yes
checking for futimesat... no
checking for futimens... yes
checking for futimes...	no
checking for gai_strerror... yes
checking for getentropy... no
checking for getgrgid_r... yes
checking for getgrnam_r... yes
checking for getgrouplist... no
checking for getgroups... yes
checking for getlogin... yes
checking for getloadavg... no
checking for getpeername... yes
checking for getpgid...	yes
checking for getpid... yes
checking for getpriority... yes
checking for getresuid... no
checking for getresgid... no
checking for getpwent... yes
checking for getpwnam_r... yes
checking for getpwuid_r... yes
checking for getspnam... no
checking for getspent... no
checking for getsid... yes
checking for getwd... yes
checking for if_nameindex... yes
checking for initgroups... yes
checking for kill... yes
checking for killpg... yes
checking for lchown... yes
checking for lockf... yes
checking for linkat... yes
checking for lstat... yes
checking for lutimes...	no
checking for mmap... yes
checking for memrchr...	no
checking for mbrtowc...	yes
checking for mkdirat...	yes
checking for mkfifo... yes
checking for madvise...	yes
checking for mkfifoat... yes
checking for mknod... yes
checking for mknodat...	yes
checking for mktime... yes
checking for mremap... no
checking for nice... yes
checking for openat... yes
checking for pathconf... yes
checking for pause... yes
checking for pipe2... no
checking for plock... yes
checking for poll... yes
checking for posix_fallocate...	yes
checking for posix_fadvise... yes
checking for posix_spawn... yes
checking for posix_spawnp... yes
checking for pread... yes
checking for preadv... yes
checking for preadv2...	no
checking for pthread_condattr_setclock... yes
checking for pthread_init... yes
checking for pthread_kill... yes
checking for pwrite... yes
checking for pwritev...	yes
checking for pwritev2... no
checking for readlink... yes
checking for readlinkat... yes
checking for readv... yes
checking for realpath... yes
checking for renameat... yes
checking for sem_open... yes
checking for sem_timedwait... yes
checking for sem_getvalue... yes
checking for sem_unlink... yes
checking for sendfile... no
checking for setegid...	yes
checking for seteuid...	yes
checking for setgid... yes
checking for sethostname... yes
checking for setlocale... yes
checking for setregid... yes
checking for setreuid... yes
checking for setresuid... no
checking for setresgid... no
checking for setsid... yes
checking for setpgid...	yes
checking for setpgrp...	yes
checking for setpriority... yes
checking for setuid... yes
checking for setvbuf...	yes
checking for sched_get_priority_max... yes
checking for sched_setaffinity... no
checking for sched_setscheduler... yes
checking for sched_setparam... yes
checking for sched_rr_get_interval... yes
checking for sigaction... yes
checking for sigaltstack... yes
checking for sigfillset... yes
checking for siginterrupt... yes
checking for sigpending... yes
checking for sigrelse... yes
checking for sigtimedwait... yes
checking for sigwait...	yes
checking for sigwaitinfo... yes
checking for snprintf... yes
checking for strftime... yes
checking for strlcpy...	no
checking for strsignal... yes
checking for symlinkat... yes
checking for sync... yes
checking for sysconf...	yes
checking for tcgetpgrp... yes
checking for tcsetpgrp... yes
checking for tempnam...	yes
checking for timegm... no
checking for times... yes
checking for tmpfile...	yes
checking for tmpnam... yes
checking for tmpnam_r... no
checking for truncate... yes
checking for uname... yes
checking for unlinkat... yes
checking for utimensat... yes
checking for utimes... yes
checking for waitid... yes
checking for waitpid...	yes
checking for wait3... yes
checking for wait4... yes
checking for wcscoll...	yes
checking for wcsftime... yes
checking for wcsxfrm...	yes
checking for wmemcmp...	yes
checking for writev... yes
checking for _getpty...	no
checking for rtpSpawn... no
checking for lchmod... no
checking whether dirfd is declared... yes
checking for chroot... yes
checking for link... yes
checking for symlink...	yes
checking for fchdir... yes
checking for fsync... yes
checking for fdatasync... yes
checking for epoll... no
checking for epoll_create1... no
checking for kqueue... no
checking for prlimit...	no
checking for memfd_create... no
checking for ctermid_r... no
checking for flock declaration... yes
checking for flock... no
checking for flock in -lbsd... yes
checking for getpagesize... yes
checking for broken unsetenv...	no
checking for true... true
checking for inet_aton in -lc... yes
checking for chflags...	no
checking for lchflags... no
checking for inflateCopy in -lz... yes
checking for hstrerror... no
checking for inet_aton... yes
checking for inet_pton... yes
checking for setgroups... yes
checking for openpty...	no
checking for openpty in	-lutil... no
checking for openpty in	-lbsd... no
checking for forkpty...	no
checking for forkpty in	-lutil... no
checking for forkpty in	-lbsd... no
checking for fseek64...	no
checking for fseeko... yes
checking for fstatvfs... yes
checking for ftell64...	no
checking for ftello... yes
checking for statvfs...	yes
checking for dup2... yes
checking for strdup... yes
checking for getpgrp...	yes
checking for setpgrp...	(cached) yes
checking for library containing	crypt... none required
checking for library containing	crypt_r... none	required
checking for crypt_r...	yes
checking for clock_gettime... yes
checking for clock_getres... yes
checking for clock_settime... yes
checking for major... yes
checking for getaddrinfo... yes
checking getaddrinfo bug... no
checking for getnameinfo... yes
checking whether time.h	and sys/time.h may both	be included... yes
checking whether struct	tm is in sys/time.h or time.h... time.h
checking for struct tm.tm_zone... no
checking whether tzname	is declared... yes
checking for tzname... yes
checking for struct stat.st_rdev... yes
checking for struct stat.st_blksize... yes
checking for struct stat.st_flags... no
checking for struct stat.st_gen... yes
checking for struct stat.st_birthtime... no
checking for struct stat.st_blocks... yes
checking for struct passwd.pw_gecos... yes
checking for struct passwd.pw_passwd...	yes
checking for siginfo_t.si_band... yes
checking for time.h that defines altzone... no
checking whether sys/select.h and sys/time.h may both be included... yes
checking for addrinfo... yes
checking for sockaddr_storage... yes
checking for sockaddr_alg... no
checking whether char is unsigned... yes
checking for an	ANSI C-conforming const... yes
checking for working signed char... yes
checking for prototypes... yes
checking for variable length prototypes	and stdarg.h...	yes
checking for socketpair... yes
checking if sockaddr has sa_len	member... yes
checking for gethostbyname_r...	yes
checking gethostbyname_r with 6	args...	no
checking gethostbyname_r with 5	args...	no
checking gethostbyname_r with 3	args...	yes
checking for __fpu_control... no
checking for __fpu_control in -lieee...	no
checking for --with-libm=STRING... default LIBM="-lm"
checking for --with-libc=STRING... default LIBC=""
checking for x64 gcc inline assembler... no
checking whether float word ordering is	bigendian... yes
checking whether we can	use gcc	inline assembler to get	and set	x87 control word... no
checking whether we can	use gcc	inline assembler to get	and set	mc68881	fpcr...	no
checking for x87-style double rounding... no
checking for acosh... yes
checking for asinh... yes
checking for atanh... yes
checking for copysign... yes
checking for erf... yes
checking for erfc... yes
checking for expm1... yes
checking for finite... yes
checking for gamma... yes
checking for hypot... yes
checking for lgamma... yes
checking for log1p... yes
checking for log2... yes
checking for round... yes
checking for tgamma... yes
checking whether isinf is declared... yes
checking whether isnan is declared... yes
checking whether isfinite is declared... yes
checking whether POSIX semaphores are enabled... yes
checking for broken sem_getvalue... no
checking whether RTLD_LAZY is declared... yes
checking whether RTLD_NOW is declared... yes
checking whether RTLD_GLOBAL is	declared... yes
checking whether RTLD_LOCAL is declared... yes
checking whether RTLD_NODELETE is declared... no
checking whether RTLD_NOLOAD is	declared... no
checking whether RTLD_DEEPBIND is declared... no
checking whether RTLD_MEMBER is	declared... yes
checking digit size for	Python's longs... no value specified
checking wchar.h usability... yes
checking wchar.h presence... yes
checking for wchar.h...	yes
checking size of wchar_t... 2
checking for UCS-4 tcl... no
checking whether wchar_t is signed... no
checking whether wchar_t is usable... yes
checking whether byte ordering is bigendian... yes
checking ABIFLAGS... d
checking SOABI... cpython-39d
checking LDVERSION... $(VERSION)$(ABIFLAGS)
checking for --with-platlibdir... no
checking whether right shift extends the sign bit... yes
checking for getc_unlocked() and friends... yes
checking how to	link readline libs... -lreadline
checking for rl_pre_input_hook in -lreadline...	no
checking for rl_completion_display_matches_hook	in -lreadline... no
checking for rl_resize_terminal	in -lreadline... yes
checking for rl_completion_matches in -lreadline... yes
checking for append_history in -lreadline... yes
checking for broken nice()... no
checking for broken poll()... no
checking for working tzset()...	yes
checking for tv_nsec in	struct stat... yes
checking for tv_nsec2 in struct	stat...	no
checking curses.h usability... yes
checking curses.h presence... yes
checking for curses.h... yes
checking ncurses.h usability...	no
checking ncurses.h presence... no
checking for ncurses.h... no
checking for term.h... yes
checking whether mvwdelch is an	expression... yes
checking whether WINDOW	has _flags... yes
checking for is_pad... no
checking for is_term_resized...	no
checking for resize_term... no
checking for resizeterm... no
checking for immedok...	yes
checking for syncok... yes
checking for wchgat... yes
checking for filter... yes
checking for has_key...	no
checking for typeahead... yes
checking for use_env...	yes
configure: checking for	device files
checking for /dev/ptmx... no
checking for /dev/ptc... yes
checking for %zd printf() format support... yes
checking for socklen_t... yes
checking for broken mbstowcs...	no
checking for --with-computed-gotos... no
checking whether xlc_r supports	computed gotos... yes
checking for build directories... done
checking for -O2... yes
checking for glibc _FORTIFY_SOURCE/memmove bug... no
checking for stdatomic.h... no
checking for GCC >= 4.7	__atomic builtins... no
checking for ensurepip... upgrade
checking if the	dirent structure of a d_type field... no
checking for the Linux getrandom() syscall... no
checking for the getrandom() function... no
checking for library containing	shm_open... none required
checking for sys/mman.h... (cached) yes
checking for shm_open... yes
checking for shm_unlink... yes
checking for pkg-config... /usr/bin/pkg-config
checking whether compiling and linking against OpenSSL works...	yes
checking for X509_VERIFY_PARAM_set1_host in libssl... yes
checking for --with-ssl-default-suites... python
configure: creating ./config.status
config.status: creating	Makefile.pre
config.status: creating	Misc/python.pc
config.status: creating	Misc/python-embed.pc
config.status: creating	Misc/python-config.sh
config.status: creating	Modules/ld_so_aix
config.status: creating	pyconfig.h
creating Modules/Setup.local
creating Makefile
$ make
	xlc_r -c  -O  -O    -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o	Programs/python.o ./Programs/python.c
	xlc_r -c  -O  -O    -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o	Parser/acceler.o Parser/acceler.c
	xlc_r -c  -O  -O    -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o	Parser/grammar1.o Parser/grammar1.c
	xlc_r -c  -O  -O    -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o	Parser/listnode.o Parser/listnode.c
	xlc_r -c  -O  -O    -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o	Parser/node.o Parser/node.c
	xlc_r -c  -O  -O    -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o	Parser/parser.o	Parser/parser.c
	xlc_r -c  -O  -O    -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o	Parser/token.o Parser/token.c
	xlc_r -c  -O  -O    -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o	Parser/myreadline.o Parser/myreadline.c
	xlc_r -c  -O  -O    -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o	Parser/parsetok.o Parser/parsetok.c
	xlc_r -c  -O  -O    -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o	Parser/tokenizer.o Parser/tokenizer.c
	xlc_r -c  -O  -O    -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o	Objects/abstract.o Objects/abstract.c
	xlc_r -c  -O  -O    -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o	Objects/accu.o Objects/accu.c
	xlc_r -c  -O  -O    -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o	Objects/boolobject.o Objects/boolobject.c
	xlc_r -c  -O  -O    -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o	Objects/bytes_methods.o	Objects/bytes_methods.c
	xlc_r -c  -O  -O    -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o	Objects/bytearrayobject.o Objects/bytearrayobject.c
	xlc_r -c  -O  -O    -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o	Objects/bytesobject.o Objects/bytesobject.c
	xlc_r -c  -O  -O    -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o	Objects/call.o Objects/call.c
	xlc_r -c  -O  -O    -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o	Objects/capsule.o Objects/capsule.c
	xlc_r -c  -O  -O    -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o	Objects/cellobject.o Objects/cellobject.c
	xlc_r -c  -O  -O    -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o	Objects/classobject.o Objects/classobject.c
	xlc_r -c  -O  -O    -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o	Objects/codeobject.o Objects/codeobject.c
	xlc_r -c  -O  -O    -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o	Objects/complexobject.o	Objects/complexobject.c
	xlc_r -c  -O  -O    -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o	Objects/descrobject.o Objects/descrobject.c
	xlc_r -c  -O  -O    -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o	Objects/enumobject.o Objects/enumobject.c
	xlc_r -c  -O  -O    -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o	Objects/exceptions.o Objects/exceptions.c
    1500-030: (I) INFORMATION: _PyExc_Init: Additional optimization may	be attained by recompiling and specifying MAXMEM option	with a value greater than 8192.
	xlc_r -c  -O  -O    -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o	Objects/genericaliasobject.o Objects/genericaliasobject.c
	xlc_r -c  -O  -O    -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o	Objects/genobject.o Objects/genobject.c
	xlc_r -c  -O  -O    -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o	Objects/fileobject.o Objects/fileobject.c
	xlc_r -c  -O  -O    -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o	Objects/floatobject.o Objects/floatobject.c
	xlc_r -c  -O  -O    -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o	Objects/frameobject.o Objects/frameobject.c
	xlc_r -c  -O  -O    -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o	Objects/funcobject.o Objects/funcobject.c
	xlc_r -c  -O  -O    -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o	Objects/interpreteridobject.o Objects/interpreteridobject.c
	xlc_r -c  -O  -O    -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o	Objects/iterobject.o Objects/iterobject.c
	xlc_r -c  -O  -O    -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o	Objects/listobject.o Objects/listobject.c
	xlc_r -c  -O  -O    -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o	Objects/longobject.o Objects/longobject.c
    1500-030: (I) INFORMATION: long_to_decimal_string_internal:	Additional optimization	may be attained	by recompiling and specifying MAXMEM option with a value greater than 8192.
	xlc_r -c  -O  -O    -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o	Objects/dictobject.o Objects/dictobject.c
	xlc_r -c  -O  -O    -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o	Objects/odictobject.o Objects/odictobject.c
	xlc_r -c  -O  -O    -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o	Objects/memoryobject.o Objects/memoryobject.c
	xlc_r -c  -O  -O    -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o	Objects/methodobject.o Objects/methodobject.c
	xlc_r -c  -O  -O    -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o	Objects/moduleobject.o Objects/moduleobject.c
"Objects/moduleobject.c", line 281.20: 1506-068	(W) Operation between types "struct _object*(*)(struct _object*,struct PyModuleDef*)" and "void*" is not allowed.
	xlc_r -c  -O  -O    -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o	Objects/namespaceobject.o Objects/namespaceobject.c
	xlc_r -c  -O  -O    -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o	Objects/object.o Objects/object.c
	xlc_r -c  -O  -O    -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o	Objects/obmalloc.o Objects/obmalloc.c
	xlc_r -c  -O  -O    -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o	Objects/picklebufobject.o Objects/picklebufobject.c
	xlc_r -c  -O  -O    -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o	Objects/rangeobject.o Objects/rangeobject.c
	xlc_r -c  -O  -O    -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o	Objects/setobject.o Objects/setobject.c
    1500-030: (I) INFORMATION: test_c_api: Additional optimization may be attained by recompiling and specifying MAXMEM	option with a value greater than 8192.
	xlc_r -c  -O  -O    -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o	Objects/sliceobject.o Objects/sliceobject.c
	xlc_r -c  -O  -O    -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o	Objects/structseq.o Objects/structseq.c
"Objects/structseq.c", line 465.45: 1506-196 (W) Initialization	between	types "void*" and "void(*)(struct _object*)" is	not allowed.
"Objects/structseq.c", line 466.42: 1506-196 (W) Initialization	between	types "void*" and "struct _object*(*)(struct _object*)"	is not allowed.
"Objects/structseq.c", line 469.41: 1506-196 (W) Initialization	between	types "void*" and "struct _object*(*)(struct _typeobject*,struct _object*,struct _object*)" is not allowed.
"Objects/structseq.c", line 471.46: 1506-196 (W) Initialization	between	types "void*" and "int(*)(struct _object*,int(*)(struct	_object*,void*),void*)"	is not allowed.
	xlc_r -c  -O  -O    -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o	Objects/tupleobject.o Objects/tupleobject.c
	xlc_r -c  -O  -O    -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o	Objects/typeobject.o Objects/typeobject.c
    1500-030: (I) INFORMATION: type_new: Additional optimization may be	attained by recompiling	and specifying MAXMEM option with a value greater than 8192.
	xlc_r -c  -O  -O    -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o	Objects/unicodeobject.o	Objects/unicodeobject.c
    1500-030: (I) INFORMATION: _copy_characters: Additional optimization may be	attained by recompiling	and specifying MAXMEM option with a value greater than 8192.
	xlc_r -c  -O  -O    -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o	Objects/unicodectype.o Objects/unicodectype.c
	xlc_r -c  -O  -O    -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o	Objects/weakrefobject.o	Objects/weakrefobject.c
	xlc_r -c  -O  -O    -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o	Python/_warnings.o Python/_warnings.c
	xlc_r -c  -O  -O    -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o	Python/Python-ast.o Python/Python-ast.c
"Python/Python-ast.c", line 1103.24: 1506-196 (W) Initialization between types "void(*)(void*)"	and "void*" is not allowed.
"Python/Python-ast.c", line 1202.21: 1506-196 (W) Initialization between types "void*" and "void(*)(struct {...}*)" is not allowed.
"Python/Python-ast.c", line 1203.22: 1506-196 (W) Initialization between types "void*" and "struct _object*(*)(struct _object*,struct _object*)" is not	allowed.
"Python/Python-ast.c", line 1204.22: 1506-196 (W) Initialization between types "void*" and "int(*)(struct _object*,struct _object*,struct _object*)" is	not allowed.
"Python/Python-ast.c", line 1205.22: 1506-196 (W) Initialization between types "void*" and "int(*)(struct {...}*,int(*)(struct _object*,void*),void*)" is not allowed.
"Python/Python-ast.c", line 1206.19: 1506-196 (W) Initialization between types "void*" and "int(*)(struct {...}*)" is not allowed.
"Python/Python-ast.c", line 1210.18: 1506-196 (W) Initialization between types "void*" and "int(*)(struct _object*,struct _object*,struct _object*)" is	not allowed.
"Python/Python-ast.c", line 1211.19: 1506-196 (W) Initialization between types "void*" and "struct _object*(*)(struct _typeobject*,long)" is not allowed.
"Python/Python-ast.c", line 1212.17: 1506-196 (W) Initialization between types "void*" and "struct _object*(*)(struct _typeobject*,struct _object*,struct _object*)" is	not allowed.
"Python/Python-ast.c", line 1213.18: 1506-196 (W) Initialization between types "void*" and "void(*)(void*)" is not allowed.
    1500-030: (I) INFORMATION: init_identifiers: Additional optimization may be	attained by recompiling	and specifying MAXMEM option with a value greater than 8192.
	xlc_r -c  -O  -O    -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o	Python/asdl.o Python/asdl.c
	xlc_r -c  -O  -O    -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o	Python/ast.o Python/ast.c
	xlc_r -c  -O  -O    -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o	Python/ast_opt.o Python/ast_opt.c
	xlc_r -c  -O  -O    -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o	Python/ast_unparse.o Python/ast_unparse.c
	xlc_r -c  -O  -O    -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o	Python/bltinmodule.o Python/bltinmodule.c
	xlc_r -c  -O  -O    -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o	Python/ceval.o Python/ceval.c
    1500-030: (I) INFORMATION: _PyEval_EvalFrameDefault: Additional optimization may be	attained by recompiling	and specifying MAXMEM option with a value greater than 8192.
	xlc_r -c  -O  -O    -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o	Python/codecs.o	Python/codecs.c
	xlc_r -c  -O  -O    -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o	Python/compile.o Python/compile.c
    1500-030: (I) INFORMATION: _Py_Mangle: Additional optimization may be attained by recompiling and specifying MAXMEM	option with a value greater than 8192.
	xlc_r -c  -O  -O    -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o	Python/context.o Python/context.c
	xlc_r -c  -O  -O    -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o	Python/dynamic_annotations.o Python/dynamic_annotations.c
	xlc_r -c  -O  -O    -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o	Python/errors.o	Python/errors.c
	xlc_r -c  -O  -O    -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o	Python/frozenmain.o Python/frozenmain.c
	xlc_r -c  -O  -O    -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o	Python/future.o	Python/future.c
	xlc_r -c  -O  -O    -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o	Python/getargs.o Python/getargs.c
    1500-030: (I) INFORMATION: convertsimple: Additional optimization may be attained by recompiling and specifying MAXMEM option with a value greater than 8192.
	xlc_r -c  -O  -O    -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o	Python/getcompiler.o Python/getcompiler.c
	xlc_r -c  -O  -O    -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o	Python/getcopyright.o Python/getcopyright.c
	xlc_r -c  -O  -O    -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -DPLATFORM='"aix"'	-o Python/getplatform.o	./Python/getplatform.c
	xlc_r -c  -O  -O    -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o	Python/getversion.o Python/getversion.c
	xlc_r -c  -O  -O    -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o	Python/graminit.o Python/graminit.c
	xlc_r -c  -O  -O    -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o	Python/hamt.o Python/hamt.c
	xlc_r -c  -O  -O    -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o	Python/import.o	Python/import.c
	xlc_r -c  -O  -O    -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -I. -o Python/importdl.o ./Python/importdl.c
	xlc_r -c  -O  -O    -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o	Python/initconfig.o Python/initconfig.c
    1500-030: (I) INFORMATION: config_as_dict: Additional optimization may be attained by recompiling and specifying MAXMEM option with	a value	greater	than 8192.
	xlc_r -c  -O  -O    -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o	Python/marshal.o Python/marshal.c
    1500-030: (I) INFORMATION: r_object: Additional optimization may be	attained by recompiling	and specifying MAXMEM option with a value greater than 8192.
	xlc_r -c  -O  -O    -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o	Python/modsupport.o Python/modsupport.c
	xlc_r -c  -O  -O    -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o	Python/mysnprintf.o Python/mysnprintf.c
	xlc_r -c  -O  -O    -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o	Python/mystrtoul.o Python/mystrtoul.c
	xlc_r -c  -O  -O    -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o	Python/pathconfig.o Python/pathconfig.c
	xlc_r -c  -O  -O    -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o	Python/peephole.o Python/peephole.c
	xlc_r -c  -O  -O    -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o	Python/preconfig.o Python/preconfig.c
	xlc_r -c  -O  -O    -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o	Python/pyarena.o Python/pyarena.c
	xlc_r -c  -O  -O    -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o	Python/pyctype.o Python/pyctype.c
	xlc_r -c  -O  -O    -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o	Python/pyfpe.o Python/pyfpe.c
	xlc_r -c  -O  -O    -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o	Python/pyhash.o	Python/pyhash.c
	xlc_r -c  -O  -O    -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o	Python/pylifecycle.o Python/pylifecycle.c
	xlc_r -c  -O  -O    -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o	Python/pymath.o	Python/pymath.c
	xlc_r -c  -O  -O    -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o	Python/pystate.o Python/pystate.c
"Python/pystate.c", line 63.26:	1506-196 (W) Initialization between types "void*" and "struct _object*(*)(struct _object*,void*)" is not allowed.
"Python/pystate.c", line 69.29:	1506-068 (W) Operation between types "struct _object*(*)(struct	_object*,void*)" and "void*" is	not allowed.
	xlc_r -c  -O  -O    -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o	Python/pythonrun.o Python/pythonrun.c
	xlc_r -c  -O  -O    -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o	Python/pytime.o	Python/pytime.c
	xlc_r -c  -O  -O    -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o	Python/bootstrap_hash.o	Python/bootstrap_hash.c
	xlc_r -c  -O  -O    -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o	Python/structmember.o Python/structmember.c
	xlc_r -c  -O  -O    -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o	Python/symtable.o Python/symtable.c
    1500-030: (I) INFORMATION: symtable_visit_stmt: Additional optimization may	be attained by recompiling and specifying MAXMEM option	with a value greater than 8192.
	xlc_r -c  -O  -O    -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE  -DABIFLAGS='"d"'	-DPLATLIBDIR='"lib"'	-o Python/sysmodule.o ./Python/sysmodule.c
    1500-030: (I) INFORMATION: _PySys_InitCore:	Additional optimization	may be attained	by recompiling and specifying MAXMEM option with a value greater than 8192.
	xlc_r -c  -O  -O    -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o	Python/thread.o	Python/thread.c
	xlc_r -c  -O  -O    -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o	Python/traceback.o Python/traceback.c
	xlc_r -c  -O  -O    -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o	Python/getopt.o	Python/getopt.c
	xlc_r -c  -O  -O    -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o	Python/pystrcmp.o Python/pystrcmp.c
	xlc_r -c  -O  -O    -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o	Python/pystrtod.o Python/pystrtod.c
	xlc_r -c  -O  -O    -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o	Python/pystrhex.o Python/pystrhex.c
	xlc_r -c  -O  -O    -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE  -o Python/dtoa.o Python/dtoa.c
	xlc_r -c  -O  -O    -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o	Python/formatter_unicode.o Python/formatter_unicode.c
    1500-030: (I) INFORMATION: format_complex_internal:	Additional optimization	may be attained	by recompiling and specifying MAXMEM option with a value greater than 8192.
	xlc_r -c  -O  -O    -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o	Python/fileutils.o Python/fileutils.c
	xlc_r -c  -O  -O    -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE  -DSOABI='"cpython-39d"'  -o Python/dynload_shlib.o ./Python/dynload_shlib.c
	xlc_r -c  -O  -O    -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o	Modules/config.o Modules/config.c
	xlc_r -c  -O  -O    -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -DPYTHONPATH='""'	-DPREFIX='"/usr/local"'	 -DEXEC_PREFIX='"/usr/local"'  -DVERSION='"3.9"'  -DVPATH='""'	-DPLATLIBDIR='"lib"'  -o Modules/getpath.o ./Modules/getpath.c
	xlc_r -c  -O  -O    -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o	Modules/main.o Modules/main.c
	xlc_r -c  -O  -O    -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o	Modules/gcmodule.o Modules/gcmodule.c
	xlc_r  -O  -O	 -I./Include/internal  -I. -I./Include	  -DPy_BUILD_CORE_BUILTIN  -DPy_BUILD_CORE_BUILTIN -I./Include/internal	-c ./Modules/posixmodule.c -o Modules/posixmodule.o
"./Modules/posixmodule.c", line	6372.11: 1506-131 (W) Explicit dimension specification or initializer required for an auto or static array.
"./Modules/posixmodule.c", line	12681.24: 1506-196 (W) Initialization between types "void(*)(void*)" and "void*" is not	allowed.
"./Modules/posixmodule.c", line	12985.17: 1506-196 (W) Initialization between types "void*" and	"struct	_object*(*)(struct _typeobject*,struct _object*,struct _object*)" is not allowed.
"./Modules/posixmodule.c", line	12986.21: 1506-196 (W) Initialization between types "void*" and	"void(*)(struct	{...}*)" is not	allowed.
"./Modules/posixmodule.c", line	12987.18: 1506-196 (W) Initialization between types "void*" and	"struct	_object*(*)(struct {...}*)" is not allowed.
"./Modules/posixmodule.c", line	13400.24: 1506-196 (W) Initialization between types "void(*)(void*)" and "void*" is not	allowed.
"./Modules/posixmodule.c", line	13413.17: 1506-196 (W) Initialization between types "void*" and	"struct	_object*(*)(struct _typeobject*,struct _object*,struct _object*)" is not allowed.
"./Modules/posixmodule.c", line	13414.21: 1506-196 (W) Initialization between types "void*" and	"void(*)(struct	{...}*)" is not	allowed.
"./Modules/posixmodule.c", line	13415.22: 1506-196 (W) Initialization between types "void*" and	"void(*)(struct	{...}*)" is not	allowed.
"./Modules/posixmodule.c", line	13416.18: 1506-196 (W) Initialization between types "void*" and	"struct	_object*(*)(struct _object*)" is not allowed.
"./Modules/posixmodule.c", line	13417.22: 1506-196 (W) Initialization between types "void*" and	"struct	_object*(*)(struct {...}*)" is not allowed.
	xlc_r  -O  -O	 -I./Include/internal  -I. -I./Include	  -DPy_BUILD_CORE_BUILTIN  -c ./Modules/errnomodule.c -o Modules/errnomodule.o
	xlc_r  -O  -O	 -I./Include/internal  -I. -I./Include	  -DPy_BUILD_CORE_BUILTIN  -c ./Modules/pwdmodule.c -o Modules/pwdmodule.o
	xlc_r  -O  -O	 -I./Include/internal  -I. -I./Include	  -DPy_BUILD_CORE_BUILTIN  -c ./Modules/_sre.c -o Modules/_sre.o
    1500-030: (I) INFORMATION: sre_ucs1_count: Additional optimization may be attained by recompiling and specifying MAXMEM option with	a value	greater	than 8192.
	xlc_r  -O  -O	 -I./Include/internal  -I. -I./Include	  -DPy_BUILD_CORE_BUILTIN  -c ./Modules/_codecsmodule.c	-o Modules/_codecsmodule.o
	xlc_r  -O  -O	 -I./Include/internal  -I. -I./Include	  -DPy_BUILD_CORE_BUILTIN  -c ./Modules/_weakref.c -o Modules/_weakref.o
"./Modules/_weakref.c",	line 171.19: 1506-196 (W) Initialization between types "void*" and "int(*)(struct _object*)" is	not allowed.
	xlc_r  -O  -O	 -I./Include/internal  -I. -I./Include	  -DPy_BUILD_CORE_BUILTIN  -DPy_BUILD_CORE_BUILTIN -I./Include/internal	-c ./Modules/_functoolsmodule.c	-o Modules/_functoolsmodule.o
"./Modules/_functoolsmodule.c",	line 1446.19: 1506-196 (W) Initialization between types	"void*"	and "int(*)(struct _object*)" is not allowed.
	xlc_r  -O  -O	 -I./Include/internal  -I. -I./Include	  -DPy_BUILD_CORE_BUILTIN  -c ./Modules/_operator.c -o Modules/_operator.o
"./Modules/_operator.c", line 1769.19: 1506-196	(W) Initialization between types "void*" and "int(*)(struct _object*)" is not allowed.
	xlc_r  -O  -O	 -I./Include/internal  -I. -I./Include	  -DPy_BUILD_CORE_BUILTIN  -c ./Modules/_collectionsmodule.c -o	Modules/_collectionsmodule.o
"./Modules/_collectionsmodule.c", line 2587.19:	1506-196 (W) Initialization between types "void*" and "int(*)(struct _object*)"	is not allowed.
	xlc_r  -O  -O	 -I./Include/internal  -I. -I./Include	  -DPy_BUILD_CORE_BUILTIN  -c ./Modules/_abc.c -o Modules/_abc.o
"./Modules/_abc.c", line 101.17: 1506-196 (W) Initialization between types "void*" and "struct _object*(*)(struct _typeobject*,struct _object*,struct _object*)" is not	allowed.
"./Modules/_abc.c", line 102.21: 1506-196 (W) Initialization between types "void*" and "void(*)(struct {...}*)"	is not allowed.
"./Modules/_abc.c", line 103.22: 1506-196 (W) Initialization between types "void*" and "int(*)(struct {...}*,int(*)(struct _object*,void*),void*)" is not allowed.
"./Modules/_abc.c", line 104.19: 1506-196 (W) Initialization between types "void*" and "int(*)(struct {...}*)" is not allowed.
"./Modules/_abc.c", line 884.19: 1506-196 (W) Initialization between types "void*" and "int(*)(struct _object*)" is not	allowed.
	xlc_r  -O  -O	 -I./Include/internal  -I. -I./Include	  -DPy_BUILD_CORE_BUILTIN  -c ./Modules/itertoolsmodule.c -o Modules/itertoolsmodule.o
"./Modules/itertoolsmodule.c", line 4718.19: 1506-196 (W) Initialization between types "void*" and "int(*)(struct _object*)" is	not allowed.
	xlc_r  -O  -O	 -I./Include/internal  -I. -I./Include	  -DPy_BUILD_CORE_BUILTIN  -c ./Modules/atexitmodule.c -o Modules/atexitmodule.o
"./Modules/atexitmodule.c", line 335.19: 1506-196 (W) Initialization between types "void*" and "int(*)(struct _object*)" is not	allowed.
	xlc_r  -O  -O	 -I./Include/internal  -I. -I./Include	  -DPy_BUILD_CORE_BUILTIN  -DPy_BUILD_CORE_BUILTIN -I./Include/internal	-c ./Modules/signalmodule.c -o Modules/signalmodule.o
	xlc_r  -O  -O	 -I./Include/internal  -I. -I./Include	  -DPy_BUILD_CORE_BUILTIN  -c ./Modules/_stat.c	-o Modules/_stat.o
	xlc_r  -O  -O	 -I./Include/internal  -I. -I./Include	  -DPy_BUILD_CORE_BUILTIN  -DPy_BUILD_CORE_BUILTIN -I./Include/internal	-c ./Modules/timemodule.c -o Modules/timemodule.o
"./Modules/timemodule.c", line 1834.19:	1506-196 (W) Initialization between types "void*" and "int(*)(struct _object*)"	is not allowed.
	xlc_r  -O  -O	 -I./Include/internal  -I. -I./Include	  -DPy_BUILD_CORE_BUILTIN  -DPy_BUILD_CORE_BUILTIN -I./Include/internal	-c ./Modules/_threadmodule.c -o	Modules/_threadmodule.o
	xlc_r  -O  -O	 -I./Include/internal  -I. -I./Include	  -DPy_BUILD_CORE_BUILTIN  -DPy_BUILD_CORE_BUILTIN -c ./Modules/_localemodule.c	-o Modules/_localemodule.o
"./Modules/_localemodule.c", line 784.19: 1506-196 (W) Initialization between types "void*" and	"int(*)(struct _object*)" is not allowed.
	xlc_r  -O  -O	 -I./Include/internal  -I. -I./Include	  -DPy_BUILD_CORE_BUILTIN  -DPy_BUILD_CORE_BUILTIN -I./Include/internal	-I./Modules/_io	-c ./Modules/_io/_iomodule.c -o	Modules/_iomodule.o
	xlc_r  -O  -O	 -I./Include/internal  -I. -I./Include	  -DPy_BUILD_CORE_BUILTIN  -DPy_BUILD_CORE_BUILTIN -I./Include/internal	-I./Modules/_io	-c ./Modules/_io/iobase.c -o Modules/iobase.o
	xlc_r  -O  -O	 -I./Include/internal  -I. -I./Include	  -DPy_BUILD_CORE_BUILTIN  -DPy_BUILD_CORE_BUILTIN -I./Include/internal	-I./Modules/_io	-c ./Modules/_io/fileio.c -o Modules/fileio.o
	xlc_r  -O  -O	 -I./Include/internal  -I. -I./Include	  -DPy_BUILD_CORE_BUILTIN  -DPy_BUILD_CORE_BUILTIN -I./Include/internal	-I./Modules/_io	-c ./Modules/_io/bytesio.c -o Modules/bytesio.o
	xlc_r  -O  -O	 -I./Include/internal  -I. -I./Include	  -DPy_BUILD_CORE_BUILTIN  -DPy_BUILD_CORE_BUILTIN -I./Include/internal	-I./Modules/_io	-c ./Modules/_io/bufferedio.c -o Modules/bufferedio.o
	xlc_r  -O  -O	 -I./Include/internal  -I. -I./Include	  -DPy_BUILD_CORE_BUILTIN  -DPy_BUILD_CORE_BUILTIN -I./Include/internal	-I./Modules/_io	-c ./Modules/_io/textio.c -o Modules/textio.o
    1500-030: (I) INFORMATION: _io_TextIOWrapper_tell_impl: Additional optimization may	be attained by recompiling and specifying MAXMEM option	with a value greater than 8192.
	xlc_r  -O  -O	 -I./Include/internal  -I. -I./Include	  -DPy_BUILD_CORE_BUILTIN  -DPy_BUILD_CORE_BUILTIN -I./Include/internal	-I./Modules/_io	-c ./Modules/_io/stringio.c -o Modules/stringio.o
	xlc_r  -O  -O	 -I./Include/internal  -I. -I./Include	  -DPy_BUILD_CORE_BUILTIN  -c ./Modules/faulthandler.c -o Modules/faulthandler.o
	xlc_r  -O  -O	 -I./Include/internal  -I. -I./Include	  -DPy_BUILD_CORE_BUILTIN  -c ./Modules/_tracemalloc.c -o Modules/_tracemalloc.o
	xlc_r  -O  -O	 -I./Include/internal  -I. -I./Include	  -DPy_BUILD_CORE_BUILTIN  -c ./Modules/hashtable.c -o Modules/hashtable.o
	xlc_r  -O  -O	 -I./Include/internal  -I. -I./Include	  -DPy_BUILD_CORE_BUILTIN  -c ./Modules/symtablemodule.c -o Modules/symtablemodule.o
	xlc_r  -O  -O	 -I./Include/internal  -I. -I./Include	  -DPy_BUILD_CORE_BUILTIN  -c ./Modules/xxsubtype.c -o Modules/xxsubtype.o
"./Modules/xxsubtype.c", line 293.19: 1506-196 (W) Initialization between types	"void*"	and "int(*)(struct _object*)" is not allowed.
	xlc_r -c  -O  -O    -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE  -DGITVERSION="\"`LC_ALL=C	git --git-dir ./.git rev-parse --short HEAD`\""	 -DGITTAG="\"`LC_ALL=C git --git-dir ./.git describe --all --always --dirty`\""	 -DGITBRANCH="\"`LC_ALL=C git --git-dir	./.git name-rev	--name-only HEAD`\""  -o Modules/getbuildinfo.o	./Modules/getbuildinfo.c
	xlc_r -c  -O  -O    -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o	Python/frozen.o	Python/frozen.c
	rm -f libpython3.9d.a
	ar rcs libpython3.9d.a Modules/getbuildinfo.o  Parser/acceler.o	 Parser/grammar1.o  Parser/listnode.o  Parser/node.o  Parser/parser.o  Parser/token.o	Parser/myreadline.o Parser/parsetok.o Parser/tokenizer.o  Objects/abstract.o  Objects/accu.o  Objects/boolobject.o  Objects/bytes_methods.o  Objects/bytearrayobject.o	Objects/bytesobject.o  Objects/call.o  Objects/capsule.o  Objects/cellobject.o	Objects/classobject.o  Objects/codeobject.o  Objects/complexobject.o  Objects/descrobject.o  Objects/enumobject.o  Objects/exceptions.o	 Objects/genericaliasobject.o  Objects/genobject.o  Objects/fileobject.o  Objects/floatobject.o	 Objects/frameobject.o	Objects/funcobject.o  Objects/interpreteridobject.o  Objects/iterobject.o  Objects/listobject.o	 Objects/longobject.o  Objects/dictobject.o  Objects/odictobject.o  Objects/memoryobject.o  Objects/methodobject.o  Objects/moduleobject.o  Objects/namespaceobject.o  Objects/object.o	 Objects/obmalloc.o  Objects/picklebufobject.o	Objects/rangeobject
 .o  Objects/setobject.o  Objects/sliceobject.o  Objects/structseq.o	Objects/tupleobject.o  Objects/typeobject.o  Objects/unicodeobject.o  Objects/unicodectype.o  Objects/weakrefobject.o  Python/_warnings.o  Python/Python-ast.o	Python/asdl.o  Python/ast.o  Python/ast_opt.o  Python/ast_unparse.o  Python/bltinmodule.o  Python/ceval.o  Python/codecs.o  Python/compile.o  Python/context.o	Python/dynamic_annotations.o  Python/errors.o  Python/frozenmain.o  Python/future.o  Python/getargs.o  Python/getcompiler.o  Python/getcopyright.o  Python/getplatform.o  Python/getversion.o  Python/graminit.o  Python/hamt.o	 Python/import.o  Python/importdl.o  Python/initconfig.o  Python/marshal.o  Python/modsupport.o	 Python/mysnprintf.o  Python/mystrtoul.o  Python/pathconfig.o  Python/peephole.o  Python/preconfig.o  Python/pyarena.o	Python/pyctype.o  Python/pyfpe.o  Python/pyhash.o  Python/pylifecycle.o	 Python/pymath.o  Python/pystate.o  Python/pythonrun.o	Python/pytime.o	 Python/bootstrap_hash.o  Pyt
 hon/structmember.o	 Python/symtable.o  Python/sysmodule.o	Python/thread.o	 Python/traceback.o  Python/getopt.o  Python/pystrcmp.o	 Python/pystrtod.o  Python/pystrhex.o  Python/dtoa.o  Python/formatter_unicode.o  Python/fileutils.o  Python/dynload_shlib.o	    Modules/config.o  Modules/getpath.o	 Modules/main.o	 Modules/gcmodule.o  Modules/posixmodule.o  Modules/errnomodule.o  Modules/pwdmodule.o	Modules/_sre.o	Modules/_codecsmodule.o	 Modules/_weakref.o  Modules/_functoolsmodule.o	 Modules/_operator.o  Modules/_collectionsmodule.o  Modules/_abc.o  Modules/itertoolsmodule.o  Modules/atexitmodule.o  Modules/signalmodule.o  Modules/_stat.o	Modules/timemodule.o  Modules/_threadmodule.o  Modules/_localemodule.o	Modules/_iomodule.o Modules/iobase.o Modules/fileio.o Modules/bytesio.o	Modules/bufferedio.o Modules/textio.o Modules/stringio.o  Modules/faulthandler.o  Modules/_tracemalloc.o Modules/hashtable.o  Modules/symtablemodule.o	Modules/xxsubtype.o  Python/frozen.o
	./Modules/makexp_aix Modules/python.exp	. libpython3.9d.a;  xlc_r     -Wl,-bE:Modules/python.exp -lld -o python	Programs/python.o libpython3.9d.a -lintl -ldl  -lm   -l
	 ./python -E -S	-m sysconfig --generate-posix-vars ; if	test $?	-ne 0 ;	then  echo "generate-posix-vars	failed"	;  rm -f ./pybuilddir.txt ;  exit 1 ;  fi
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	: 30084150
object refcount	: 0
object type	: 20013710
object type name: generator
object repr	: <refcnt 0 at 30084150>

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
/bin/sh: 26542810 IOT/Abort trap(coredump)
make: 1254-004 The error code from the last command is 134.


Stop.
$

Script command is complete on Mon Apr 13 06:38:26 CDT 2020.

From report at bugs.python.org  Mon Apr 13 12:57:13 2020
From: report at bugs.python.org (Anthony Sottile)
Date: Mon, 13 Apr 2020 16:57:13 +0000
Subject: [issue40266] Failure to build _ssl module on ubuntu xenial
In-Reply-To: <1586722609.26.0.314965536558.issue40266@roundup.psfhosted.org>
Message-ID: <1586797033.9.0.133647407658.issue40266@roundup.psfhosted.org>


Anthony Sottile <asottile at umich.edu> added the comment:

yes, it is still broken, now with fewer errors:

2020-04-13T15:06:34.7330649Z 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 -fvisibility=hidden -I../Include/internal -I../Include -IObjects -IPython -I. -I/usr/include/x86_64-linux-gnu -I/tmp/code/Include -I/tmp/code/build-static -c /tmp/code/Modules/_ssl.c -o build/temp.linux-x86_64-3.9/tmp/code/Modules/_ssl.o
2020-04-13T15:06:34.8649844Z In file included from /tmp/code/Modules/_ssl.c:136:0:
2020-04-13T15:06:34.8651190Z /tmp/code/Modules/_ssl_data.h:650:28: error: ???ERR_LIB_ASYNC??? undeclared here (not in a function)
2020-04-13T15:06:34.8651651Z      {"FAILED_TO_SET_POOL", ERR_LIB_ASYNC, 101},
2020-04-13T15:06:34.8651920Z                             ^
2020-04-13T15:06:34.8661090Z /tmp/code/Modules/_ssl_data.h:1510:29: error: ???ERR_LIB_CT??? undeclared here (not in a function)
2020-04-13T15:06:34.8661535Z      {"BASE64_DECODE_ERROR", ERR_LIB_CT, 108},
2020-04-13T15:06:34.8661802Z                              ^
2020-04-13T15:06:34.8676472Z /tmp/code/Modules/_ssl_data.h:2650:24: error: ???ERR_LIB_KDF??? undeclared here (not in a function)
2020-04-13T15:06:34.8676957Z      {"INVALID_DIGEST", ERR_LIB_KDF, 100},
2020-04-13T15:06:34.8677361Z                         ^

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40266>
_______________________________________

From report at bugs.python.org  Mon Apr 13 12:57:56 2020
From: report at bugs.python.org (Anthony Sottile)
Date: Mon, 13 Apr 2020 16:57:56 +0000
Subject: [issue39953] Let's update ssl error codes
In-Reply-To: <1584072470.83.0.437860249809.issue39953@roundup.psfhosted.org>
Message-ID: <1586797076.81.0.800040402813.issue39953@roundup.psfhosted.org>


Anthony Sottile <asottile at umich.edu> added the comment:

this is still broken even with the latest patch: https://bugs.python.org/issue40266

----------
nosy: +Anthony Sottile

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39953>
_______________________________________

From report at bugs.python.org  Mon Apr 13 13:41:34 2020
From: report at bugs.python.org (Steve Dower)
Date: Mon, 13 Apr 2020 17:41:34 +0000
Subject: [issue40214] test_ctypes.test_load_dll_with_flags Windows failure
In-Reply-To: <1586230066.46.0.791582618244.issue40214@roundup.psfhosted.org>
Message-ID: <1586799694.4.0.502161039523.issue40214@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

So I collected more info, and it seems the search order we're getting for _sqlite3.dll (.pyd) is:

* app directory
* SQL server install directory (?)
* Windows/System32
* Windows
* %PATH% (which is truncated at 2190 chars)

And then we never look in CWD. I wonder if it's being excluded because it's under %TEMP%?

I can't reproduce it either with a long PATH or with it in TEMP, so there may be a policy setting involved. Trying again with the test not using TEMP (it shouldn't be using the real TEMP anyway...)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40214>
_______________________________________

From report at bugs.python.org  Mon Apr 13 14:07:12 2020
From: report at bugs.python.org (Steve Dower)
Date: Mon, 13 Apr 2020 18:07:12 +0000
Subject: [issue40214] test_ctypes.test_load_dll_with_flags Windows failure
In-Reply-To: <1586230066.46.0.791582618244.issue40214@roundup.psfhosted.org>
Message-ID: <1586801232.53.0.734196973867.issue40214@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Okay, I've wasted enough time on this. Let's just disable the test permanently and say that the winmode=0 behaviour is system-specific and is not tested.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40214>
_______________________________________

From report at bugs.python.org  Mon Apr 13 14:14:01 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 13 Apr 2020 18:14:01 +0000
Subject: [issue40273] mappingproxy isn't reversible
In-Reply-To: <1586786082.33.0.84219610791.issue40273@roundup.psfhosted.org>
Message-ID: <1586801641.82.0.3429227954.issue40273@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

This seems reasonable.

+1

----------
keywords: +easy (C)
versions:  -Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40273>
_______________________________________

From report at bugs.python.org  Mon Apr 13 14:44:55 2020
From: report at bugs.python.org (Eryk Sun)
Date: Mon, 13 Apr 2020 18:44:55 +0000
Subject: [issue40214] test_ctypes.test_load_dll_with_flags Windows failure
In-Reply-To: <1586230066.46.0.791582618244.issue40214@roundup.psfhosted.org>
Message-ID: <1586803495.06.0.195541453007.issue40214@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> it seems the search order we're getting for _sqlite3.dll (.pyd) is:
>
> * app directory
> * SQL server install directory (?)
> * Windows/System32
> * Windows
> * %PATH% (which is truncated at 2190 chars)

Thank you. It finally makes sense. The parent process is calling SetDllDirectoryW [1], which also replaces the current working directory in the DLL search path of child processes (inherited via the PEB ProcessParameters->DllPath) [2]: 

    Note: The standard search order of the process will also be 
    affected by calling the SetDllDirectory function in the parent
    process before start of the current process.

In that case, all we have to do is restore the original search path by calling SetDllDirectoryW(NULL). For example:

    import ctypes
    kernel32 = ctypes.WinDLL('kernel32', use_last_error=True)
    if not kernel32.SetDllDirectoryW(None):
        raise ctypes.WinError(ctypes.get_last_error())


[1]: https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-setdlldirectoryw
[2]: https://docs.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-search-order#alternate-search-order-for-desktop-applications

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40214>
_______________________________________

From report at bugs.python.org  Mon Apr 13 14:58:59 2020
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Mon, 13 Apr 2020 18:58:59 +0000
Subject: [issue35569] OSX: Enable IPV6_RECVPKTINFO
In-Reply-To: <1545566447.14.0.0770528567349.issue35569@roundup.psfhosted.org>
Message-ID: <1586804339.24.0.993000836577.issue35569@roundup.psfhosted.org>


Erlend Egeberg Aasland <erlend.aasland at innova.no> added the comment:

Added (Mac OS specific) unit tests.

----------
Added file: https://bugs.python.org/file49059/0002-bpo-35569-Add-unit-tests.patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35569>
_______________________________________

From report at bugs.python.org  Mon Apr 13 15:02:14 2020
From: report at bugs.python.org (Steve Dower)
Date: Mon, 13 Apr 2020 19:02:14 +0000
Subject: [issue40214] test_ctypes.test_load_dll_with_flags Windows failure
In-Reply-To: <1586230066.46.0.791582618244.issue40214@roundup.psfhosted.org>
Message-ID: <1586804534.43.0.301749949201.issue40214@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

You mean the CI agent is doing it? Because there's nowhere in Python that should be doing it.

I'd rather not blanket change this option in the test suite (except to turn it on :) ), so that code snippet probably needs to shrink down into a one-liner that can go with the "-c" just for these tests.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40214>
_______________________________________

From report at bugs.python.org  Mon Apr 13 15:23:28 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 13 Apr 2020 19:23:28 +0000
Subject: [issue40255] Fixing Copy on Writes from reference counting
In-Reply-To: <1586619621.82.0.553262088399.issue40255@roundup.psfhosted.org>
Message-ID: <1586805807.99.0.939110069246.issue40255@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

I run the pyperformance test suite with PGO + LTO + full cpu isolation in the speed.python.org machine and these were the results:

+-------------------------+--------------------------------------+---------------------------------------+
| Benchmark               | master                               | immortal_refs_patch                   |
+=========================+======================================+=======================================+
| pidigits                | 289 ms                               | 290 ms: 1.01x slower (+1%)            |
+-------------------------+--------------------------------------+---------------------------------------+
| pickle                  | 20.2 us                              | 20.3 us: 1.01x slower (+1%)           |
+-------------------------+--------------------------------------+---------------------------------------+
| xml_etree_parse         | 253 ms                               | 258 ms: 1.02x slower (+2%)            |
+-------------------------+--------------------------------------+---------------------------------------+
| json_loads              | 52.0 us                              | 53.1 us: 1.02x slower (+2%)           |
+-------------------------+--------------------------------------+---------------------------------------+
| scimark_fft             | 708 ms                               | 723 ms: 1.02x slower (+2%)            |
+-------------------------+--------------------------------------+---------------------------------------+
| python_startup_no_site  | 7.83 ms                              | 8.04 ms: 1.03x slower (+3%)           |
+-------------------------+--------------------------------------+---------------------------------------+
| scimark_sparse_mat_mult | 9.28 ms                              | 9.57 ms: 1.03x slower (+3%)           |
+-------------------------+--------------------------------------+---------------------------------------+
| unpickle                | 28.0 us                              | 28.9 us: 1.03x slower (+3%)           |
+-------------------------+--------------------------------------+---------------------------------------+
| regex_effbot            | 4.70 ms                              | 4.86 ms: 1.03x slower (+3%)           |
+-------------------------+--------------------------------------+---------------------------------------+
| xml_etree_iterparse     | 178 ms                               | 184 ms: 1.04x slower (+4%)            |
+-------------------------+--------------------------------------+---------------------------------------+
| python_startup          | 11.5 ms                              | 12.0 ms: 1.04x slower (+4%)           |
+-------------------------+--------------------------------------+---------------------------------------+
| scimark_monte_carlo     | 212 ms                               | 221 ms: 1.04x slower (+4%)            |
+-------------------------+--------------------------------------+---------------------------------------+
| pathlib                 | 38.6 ms                              | 40.5 ms: 1.05x slower (+5%)           |
+-------------------------+--------------------------------------+---------------------------------------+
| sqlite_synth            | 7.85 us                              | 8.26 us: 1.05x slower (+5%)           |
+-------------------------+--------------------------------------+---------------------------------------+
| sqlalchemy_imperative   | 62.9 ms                              | 66.2 ms: 1.05x slower (+5%)           |
+-------------------------+--------------------------------------+---------------------------------------+
| richards                | 138 ms                               | 145 ms: 1.05x slower (+5%)            |
+-------------------------+--------------------------------------+---------------------------------------+
| crypto_pyaes            | 199 ms                               | 210 ms: 1.06x slower (+6%)            |
+-------------------------+--------------------------------------+---------------------------------------+
| nbody                   | 249 ms                               | 265 ms: 1.06x slower (+6%)            |
+-------------------------+--------------------------------------+---------------------------------------+
| raytrace                | 937 ms                               | 995 ms: 1.06x slower (+6%)            |
+-------------------------+--------------------------------------+---------------------------------------+
| deltablue               | 13.4 ms                              | 14.2 ms: 1.06x slower (+6%)           |
+-------------------------+--------------------------------------+---------------------------------------+
| tornado_http            | 276 ms                               | 295 ms: 1.07x slower (+7%)            |
+-------------------------+--------------------------------------+---------------------------------------+
| scimark_lu              | 247 ms                               | 264 ms: 1.07x slower (+7%)            |
+-------------------------+--------------------------------------+---------------------------------------+
| sqlalchemy_declarative  | 280 ms                               | 300 ms: 1.07x slower (+7%)            |
+-------------------------+--------------------------------------+---------------------------------------+
| dulwich_log             | 143 ms                               | 153 ms: 1.07x slower (+7%)            |
+-------------------------+--------------------------------------+---------------------------------------+
| chaos                   | 210 ms                               | 226 ms: 1.07x slower (+7%)            |
+-------------------------+--------------------------------------+---------------------------------------+
| 2to3                    | 594 ms                               | 639 ms: 1.08x slower (+8%)            |
+-------------------------+--------------------------------------+---------------------------------------+
| unpickle_list           | 6.60 us                              | 7.10 us: 1.08x slower (+8%)           |
+-------------------------+--------------------------------------+---------------------------------------+
| float                   | 213 ms                               | 229 ms: 1.08x slower (+8%)            |
+-------------------------+--------------------------------------+---------------------------------------+
| pyflate                 | 1.27 sec                             | 1.37 sec: 1.08x slower (+8%)          |
+-------------------------+--------------------------------------+---------------------------------------+
| go                      | 481 ms                               | 522 ms: 1.09x slower (+9%)            |
+-------------------------+--------------------------------------+---------------------------------------+
| pickle_pure_python      | 966 us                               | 1.05 ms: 1.09x slower (+9%)           |
+-------------------------+--------------------------------------+---------------------------------------+
| meteor_contest          | 175 ms                               | 191 ms: 1.09x slower (+9%)            |
+-------------------------+--------------------------------------+---------------------------------------+
| genshi_xml              | 148 ms                               | 161 ms: 1.09x slower (+9%)            |
+-------------------------+--------------------------------------+---------------------------------------+
| chameleon               | 20.6 ms                              | 22.5 ms: 1.09x slower (+9%)           |
+-------------------------+--------------------------------------+---------------------------------------+
| nqueens                 | 191 ms                               | 208 ms: 1.09x slower (+9%)            |
+-------------------------+--------------------------------------+---------------------------------------+
| telco                   | 14.6 ms                              | 16.0 ms: 1.09x slower (+9%)           |
+-------------------------+--------------------------------------+---------------------------------------+
| logging_format          | 22.1 us                              | 24.2 us: 1.10x slower (+10%)          |
+-------------------------+--------------------------------------+---------------------------------------+
| regex_compile           | 322 ms                               | 355 ms: 1.10x slower (+10%)           |
+-------------------------+--------------------------------------+---------------------------------------+
| hexiom                  | 16.4 ms                              | 18.1 ms: 1.10x slower (+10%)          |
+-------------------------+--------------------------------------+---------------------------------------+
| json_dumps              | 25.6 ms                              | 28.3 ms: 1.10x slower (+10%)          |
+-------------------------+--------------------------------------+---------------------------------------+
| sympy_sum               | 397 ms                               | 439 ms: 1.11x slower (+11%)           |
+-------------------------+--------------------------------------+---------------------------------------+
| sympy_integrate         | 42.7 ms                              | 47.2 ms: 1.11x slower (+11%)          |
+-------------------------+--------------------------------------+---------------------------------------+
| django_template         | 120 ms                               | 133 ms: 1.11x slower (+11%)           |
+-------------------------+--------------------------------------+---------------------------------------+
| sympy_str               | 633 ms                               | 702 ms: 1.11x slower (+11%)           |
+-------------------------+--------------------------------------+---------------------------------------+
| xml_etree_generate      | 162 ms                               | 180 ms: 1.11x slower (+11%)           |
+-------------------------+--------------------------------------+---------------------------------------+
| spectral_norm           | 244 ms                               | 272 ms: 1.11x slower (+11%)           |
+-------------------------+--------------------------------------+---------------------------------------+
| xml_etree_process       | 134 ms                               | 149 ms: 1.11x slower (+11%)           |
+-------------------------+--------------------------------------+---------------------------------------+
| logging_simple          | 19.3 us                              | 21.5 us: 1.11x slower (+11%)          |
+-------------------------+--------------------------------------+---------------------------------------+
| mako                    | 28.2 ms                              | 31.5 ms: 1.12x slower (+12%)          |
+-------------------------+--------------------------------------+---------------------------------------+
| fannkuch                | 853 ms                               | 954 ms: 1.12x slower (+12%)           |
+-------------------------+--------------------------------------+---------------------------------------+
| sympy_expand            | 983 ms                               | 1.11 sec: 1.13x slower (+13%)         |
+-------------------------+--------------------------------------+---------------------------------------+
| genshi_text             | 64.0 ms                              | 72.9 ms: 1.14x slower (+14%)          |
+-------------------------+--------------------------------------+---------------------------------------+
| unpack_sequence         | 123 ns                               | 142 ns: 1.16x slower (+16%)           |
+-------------------------+--------------------------------------+---------------------------------------+
| logging_silent          | 311 ns                               | 364 ns: 1.17x slower (+17%)           |
+-------------------------+--------------------------------------+---------------------------------------+
| unpickle_pure_python    | 581 us                               | 683 us: 1.17x slower (+17%)           |
+-------------------------+--------------------------------------+---------------------------------------+

Not significant (2): pickle_list; regex_dna; pickle_dict; scimark_sor; regex_v8

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40255>
_______________________________________

From report at bugs.python.org  Mon Apr 13 15:31:50 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 13 Apr 2020 19:31:50 +0000
Subject: [issue40255] Fixing Copy on Writes from reference counting
In-Reply-To: <1586619621.82.0.553262088399.issue40255@roundup.psfhosted.org>
Message-ID: <1586806310.23.0.248459655367.issue40255@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

System state
============

CPU: use 12 logical CPUs: 1,3,5,7,9,11,13,15,17,19,21,23
Perf event: Maximum sample rate: 1 per second
ASLR: Full randomization
Linux scheduler: Isolated CPUs (12/24): 1,3,5,7,9,11,13,15,17,19,21,23
Linux scheduler: RCU disabled on CPUs (12/24): 1,3,5,7,9,11,13,15,17,19,21,23
CPU Frequency: 0,2,4,6,8,10,12,14,16,18,20,22=min=1600 MHz, max=3333 MHz; 1,3,5,7,9,13,15,17,19,21,23=min=max=3333 MHz
Turbo Boost (MSR): CPU 1,3,5,7,9,11,13,15,17,19,21,23: disabled
IRQ affinity: irqbalance service: inactive
IRQ affinity: Default IRQ affinity: CPU 0,2,4,6,8,10,12,14,16,18,20,22
IRQ affinity: IRQ affinity: IRQ 0,2=CPU 0-23; IRQ 1,3-15,17,20,22-23,28-51=CPU 0,2,4,6,8,10,12,14,16,18,20,22

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40255>
_______________________________________

From report at bugs.python.org  Mon Apr 13 15:33:15 2020
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Mon, 13 Apr 2020 19:33:15 +0000
Subject: [issue35569] OSX: Enable IPV6_RECVPKTINFO
In-Reply-To: <1545566447.14.0.0770528567349.issue35569@roundup.psfhosted.org>
Message-ID: <1586806395.35.0.179694168121.issue35569@roundup.psfhosted.org>


Change by Erlend Egeberg Aasland <erlend.aasland at innova.no>:


----------
versions: +Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35569>
_______________________________________

From report at bugs.python.org  Mon Apr 13 15:35:07 2020
From: report at bugs.python.org (Eryk Sun)
Date: Mon, 13 Apr 2020 19:35:07 +0000
Subject: [issue40214] test_ctypes.test_load_dll_with_flags Windows failure
In-Reply-To: <1586230066.46.0.791582618244.issue40214@roundup.psfhosted.org>
Message-ID: <1586806507.83.0.918119325398.issue40214@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> You mean the CI agent is doing it? Because there's nowhere in 
> Python that should be doing it.

The ProcessParameters->DllPath value is inherited until a process in the tree reverts to the original search path via SetDllDirectoryW(NULL), so it can be any ancestor process, not just the immediate parent process.

> I'd rather not blanket change this option in the test suite (except to 
> turn it on :) ), so that code snippet probably needs to shrink down 
> into a one-liner that can go with the "-c" just for these tests.

The test could call GetDllDirectoryW [1] to save and restore the previous value. Unfortunately, GetDllDirectoryW returns 0 for both the default case (NULL) and when the working directory is disabled by setting an empty string (""). It would have to assume one or the other.

Otherwise if you just want a one-liner: "import ctypes; ctypes.windll.kernel32.SetDllDirectoryW(None)".

[1]: https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-getdlldirectoryw

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40214>
_______________________________________

From report at bugs.python.org  Mon Apr 13 15:35:15 2020
From: report at bugs.python.org (Steve Dower)
Date: Mon, 13 Apr 2020 19:35:15 +0000
Subject: [issue40255] Fixing Copy on Writes from reference counting
In-Reply-To: <1586619621.82.0.553262088399.issue40255@roundup.psfhosted.org>
Message-ID: <1586806515.59.0.700073669071.issue40255@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

If it's easy to set up, it might be interesting to see if there's a difference if (e.g.) all interned strings are marked as immortal, or all small ints. Or type objects. Maybe set a flag during initialization and treat everything created before that as immortal.

There's definitely going to be overhead, but assuming the branch is there we may as well use it to optimise our own operations.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40255>
_______________________________________

From report at bugs.python.org  Mon Apr 13 16:06:53 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 13 Apr 2020 20:06:53 +0000
Subject: [issue40255] Fixing Copy on Writes from reference counting
In-Reply-To: <1586619621.82.0.553262088399.issue40255@roundup.psfhosted.org>
Message-ID: <1586808413.09.0.577049159243.issue40255@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Thanks, Eddie for sharing the patch. I think this is an interesting discussion: for instance, in the core dev sprint at Microsoft I recall that we had a quick discussion about having immortal references. 

After analyzing the patch, and even assuming that we add conditional compilation, here are some of the things I feel uneasy about:

- Anything that is touched by the immortal object will be leaked. This can also happen in obscure ways
  if reference cycles are created.

- As Eddie mentions in the PR, this does not fully cover all cases as objects that become tracked by the GC
  after they are modified (for instance, dicts and tuples that only contain immutable objects). Those objects will
  still, participate in reference counting after they start to be tracked.

- As Gregory mentions, if immortal objects are handed to extension modules compiled with the other version of the
  macros, the reference count can be corrupted. This may break the garbage collector algorithm that relies on the
  the balance between strong references between objects and its reference count to do the calculation of the isolated cycles.
  This without mentioning that this defies the purpose of the patch in those cases, as a single modification of the reference 
  the count will trigger the copy of the whole memory page where the object lives.

- The patch modifies very core mechanics of Python for the benefit of a restricted set of users (as Gregory mentions): no 
  threads, POSIX and forking.

- Is not clear to me that leaking memory is the best way to solve this problem compared to other solutions (like having the 
  the reference count of the objects separated from them).
  objects separated from them.

There is a trend right now to try to remove immortal objects (started by Victor and others) like static types and transforming them to heap types. I am afraid that having the restriction that the interpreter and the gc needs to be aware
of immortal types can raise considerably the maintenance costs of already complicated pieces of the CPython VM.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40255>
_______________________________________

From report at bugs.python.org  Mon Apr 13 16:10:08 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 13 Apr 2020 20:10:08 +0000
Subject: [issue40255] Fixing Copy on Writes from reference counting
In-Reply-To: <1586619621.82.0.553262088399.issue40255@roundup.psfhosted.org>
Message-ID: <1586808608.65.0.0337134490662.issue40255@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

> If it's easy to set up, it might be interesting to see if there's a difference if (e.g.) all interned strings are marked as immortal, or all small ints. Or type objects. Maybe set a flag during initialization and treat everything created before that as immortal.

I can look into it, the main problem is that every run of the pyperformance test suite takes several hours, even more with --full-pgo :(  I will try to set up some automation for that when I have some free cycles

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40255>
_______________________________________

From report at bugs.python.org  Mon Apr 13 16:27:52 2020
From: report at bugs.python.org (Steve Dower)
Date: Mon, 13 Apr 2020 20:27:52 +0000
Subject: [issue40255] Fixing Copy on Writes from reference counting
In-Reply-To: <1586619621.82.0.553262088399.issue40255@roundup.psfhosted.org>
Message-ID: <1586809672.3.0.118338991337.issue40255@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

> There is a trend right now to try to remove immortal objects (started by Victor and others) like static types and transforming them to heap types.

This isn't actually about removing immortal objects, but removing *mutable* objects that would be shared between subinterpreters. Making some objects immortal, such as interned strings or stateless singletons, would actually benefit this work, as they could then be safely shared between subinterpreters.

But as you say, the added complexity here is starting to seem like it'll cost more than it's worth...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40255>
_______________________________________

From report at bugs.python.org  Mon Apr 13 17:19:13 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Mon, 13 Apr 2020 21:19:13 +0000
Subject: [issue40244] AIX: build: _PyObject_GC_TRACK Asstertion failure
In-Reply-To: <1586507316.69.0.786578254213.issue40244@roundup.psfhosted.org>
Message-ID: <1586812753.29.0.127360360341.issue40244@roundup.psfhosted.org>


Batuhan Taskaya <batuhanosmantaskaya at gmail.com> added the comment:

@Michael.Felt can you just insert some prints between these 3 to see what is going on (and re-compile)

static void
gen_dealloc(PyGenObject *gen)
{
    PyObject *self = (PyObject *) gen;
<<<<
    _PyObject_GC_UNTRACK(gen);
<<<<
    if (gen->gi_weakreflist != NULL)
        PyObject_ClearWeakRefs(self);
<<<<
    _PyObject_GC_TRACK(self);


something like this should work: printf("%ld\n", _Py_AS_GC(self)->_gc_next);

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40244>
_______________________________________

From report at bugs.python.org  Mon Apr 13 17:34:11 2020
From: report at bugs.python.org (Ned Deily)
Date: Mon, 13 Apr 2020 21:34:11 +0000
Subject: [issue40106] multiprocessor spawn
In-Reply-To: <1585518578.2.0.0489480686513.issue40106@roundup.psfhosted.org>
Message-ID: <1586813651.21.0.827544265445.issue40106@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


----------
nosy: +davin, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40106>
_______________________________________

From report at bugs.python.org  Mon Apr 13 18:00:31 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 13 Apr 2020 22:00:31 +0000
Subject: [issue39481] Implement PEP 585 (Type Hinting Generics In Standard
 Collections)
In-Reply-To: <1580231817.93.0.47144630055.issue39481@roundup.psfhosted.org>
Message-ID: <1586815231.2.0.947756880631.issue39481@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:


New changeset 25a6833f7945f14cad83509ec73954d0ad70bdb1 by Chih-Hsuan Yen in branch 'master':
bpo-39481: fix test_genericalias on Android (GH-19469)
https://github.com/python/cpython/commit/25a6833f7945f14cad83509ec73954d0ad70bdb1


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39481>
_______________________________________

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: [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:18:29 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Mon, 13 Apr 2020 22:18:29 +0000
Subject: [issue40244] AIX: build: _PyObject_GC_TRACK Asstertion failure
In-Reply-To: <1586507316.69.0.786578254213.issue40244@roundup.psfhosted.org>
Message-ID: <1586816309.41.0.344299340093.issue40244@roundup.psfhosted.org>


Batuhan Taskaya <batuhanosmantaskaya at gmail.com> added the comment:

By the noticed something that looks kind of weird, not sure if it is intentional or not but shouldn't this be self instead of gen

static void
gen_dealloc(PyGenObject *gen)
{
    PyObject *self = (PyObject *) gen;
<<<<
_PyObject_GC_UNTRACK(gen);
<<<<
    if (gen->gi_weakreflist != NULL)
        PyObject_ClearWeakRefs(self);
    _PyObject_GC_TRACK(self);

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40244>
_______________________________________

From report at bugs.python.org  Mon Apr 13 18:18:45 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 13 Apr 2020 22:18:45 +0000
Subject: [issue40274] 3D plotting library doesn't occlude objects by
 depth/perspective (objects in the scene are printed in layers).
In-Reply-To: <1586816074.17.0.60379010692.issue40274@roundup.psfhosted.org>
Message-ID: <1586816325.03.0.615742973193.issue40274@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

I'm not sure which of the libraries is the 3d plotting library you're referring to (maybe matplotlib?), but in any event it doesn't ship with python, so this isn't the appropriate bug tracker to report your issue. If it is matplotlib, their issue tracker is here: https://github.com/matplotlib/matplotlib/issues

Before reporting it there, you'll want to reproduce the problem with a smaller example.

----------
nosy: +eric.smith
resolution:  -> third party
stage:  -> resolved
status: open -> closed

_______________________________________
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: [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 18:25:40 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 13 Apr 2020 22:25:40 +0000
Subject: [issue40091] Crash in logging._after_at_fork_child_reinit_locks()
In-Reply-To: <1585328563.49.0.978667613959.issue40091@roundup.psfhosted.org>
Message-ID: <1586816740.21.0.849828735497.issue40091@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 4c3da783cffb8471303fbae3e09f3d67b31c3d06 by Victor Stinner in branch 'master':
bpo-40091: Fix a hang at fork in the logging module (GH-19416)
https://github.com/python/cpython/commit/4c3da783cffb8471303fbae3e09f3d67b31c3d06


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40091>
_______________________________________

From report at bugs.python.org  Mon Apr 13 18:29:04 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 13 Apr 2020 22:29:04 +0000
Subject: [issue40091] Crash in logging._after_at_fork_child_reinit_locks()
In-Reply-To: <1585328563.49.0.978667613959.issue40091@roundup.psfhosted.org>
Message-ID: <1586816944.91.0.395255828691.issue40091@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I merged my fix into master.

PR 19196 fix could be backported to 3.8, sadly I had to reject this PR since it introduced new problems :-( This approach (create a new lock at fork) doesn't work :-( So I'm not sure how to fix the issue on 3.8 without backporting the new _at_fork_reinit() method, but I would prefer to not backport it since I see it as a new feature.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40091>
_______________________________________

From report at bugs.python.org  Mon Apr 13 18:29:10 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 13 Apr 2020 22:29:10 +0000
Subject: [issue40091] Crash in logging._after_at_fork_child_reinit_locks()
In-Reply-To: <1585328563.49.0.978667613959.issue40091@roundup.psfhosted.org>
Message-ID: <1586816950.8.0.816882438679.issue40091@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40091>
_______________________________________

From report at bugs.python.org  Mon Apr 13 18:29:24 2020
From: report at bugs.python.org (Brian O'Sullivan)
Date: Mon, 13 Apr 2020 22:29:24 +0000
Subject: [issue40274] 3D plotting library doesn't occlude objects by
 depth/perspective (objects in the scene are printed in layers).
In-Reply-To: <1586816074.17.0.60379010692.issue40274@roundup.psfhosted.org>
Message-ID: <1586816964.48.0.901513925977.issue40274@roundup.psfhosted.org>


Brian O'Sullivan <brianmosullivan at outlook.com> added the comment:

matplotlib yes
Will do.

----------
resolution: third party -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40274>
_______________________________________

From report at bugs.python.org  Mon Apr 13 18:30:35 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 13 Apr 2020 22:30:35 +0000
Subject: [issue40214] test_ctypes.test_load_dll_with_flags Windows failure
In-Reply-To: <1586230066.46.0.791582618244.issue40214@roundup.psfhosted.org>
Message-ID: <1586817035.37.0.822997262709.issue40214@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy:  -vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40214>
_______________________________________

From report at bugs.python.org  Mon Apr 13 18:30:55 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 13 Apr 2020 22:30:55 +0000
Subject: [issue11395] print(s) fails on Windows with long strings
In-Reply-To: <1299217663.52.0.355409591746.issue11395@psf.upfronthosting.co.za>
Message-ID: <1586817055.73.0.686385787913.issue11395@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy:  -vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue11395>
_______________________________________

From report at bugs.python.org  Mon Apr 13 18:31:37 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 13 Apr 2020 22:31:37 +0000
Subject: [issue25680] Selector.select() hangs when there is nothing to select
In-Reply-To: <1448029102.96.0.470819036773.issue25680@psf.upfronthosting.co.za>
Message-ID: <1586817097.24.0.937100827698.issue25680@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy:  -vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25680>
_______________________________________

From report at bugs.python.org  Mon Apr 13 18:31:58 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 13 Apr 2020 22:31:58 +0000
Subject: [issue40204] Docs build error with Sphinx 3.0 due to invalid C
 declaration
In-Reply-To: <1586183568.2.0.322929459864.issue40204@roundup.psfhosted.org>
Message-ID: <1586817118.15.0.33707171079.issue40204@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy:  -vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40204>
_______________________________________

From report at bugs.python.org  Mon Apr 13 18:45:41 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 13 Apr 2020 22:45:41 +0000
Subject: [issue40255] Fixing Copy on Writes from reference counting
In-Reply-To: <1586619621.82.0.553262088399.issue40255@roundup.psfhosted.org>
Message-ID: <1586817941.49.0.617303871397.issue40255@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

The idea of immortal objects was proposed to solve the bpo-39511 problem.

I dislike immortable for different reasons. Here are some.

Gregory:
> We wound up not deploying it or pushing for it in CPython because the CPU performance implications of adding a branch instruction to Py_INCREC and Py_DECREF were, unsurprisingly, quite high.

Exactly. Copy-on-Write problem affects a minority of users. If PR 19474 is enabled by default, all users will pay the overhead even if they never call fork() without exec().

1.17x slower on logging_silent or unpickle_pure_python is a very expensive price :-(


Pablo:
> Anything that is touched by the immortal object will be leaked. This can also happen in obscure ways if reference cycles are created.

gc.freeze() has a similar issue, no? This function also comes from Instagram specific use case ;-)


Steve:
> This isn't actually about removing immortal objects, but removing *mutable* objects that would be shared between subinterpreters. Making some objects immortal, such as interned strings or stateless singletons, would actually benefit this work, as they could then be safely shared between subinterpreters.

>From what I understood, we simply cannot share any object (mutable or not) between two subinterpreters. Otherwise, we will need to put a lock on all Py_INCREF/Py_DECREF operation which would kill performances of running multiple interpreters in parallel. Join bpo-39511 discussion.

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40255>
_______________________________________

From report at bugs.python.org  Mon Apr 13 18:46:33 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 13 Apr 2020 22:46:33 +0000
Subject: [issue39511] [subinterpreters] Per-interpreter singletons (None, True,
 False, etc.)
In-Reply-To: <1580484815.27.0.407070570821.issue39511@roundup.psfhosted.org>
Message-ID: <1586817993.05.0.70755175318.issue39511@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

bpo-40255 proposes a concrete implementation of immortal objects: it modifies Py_INCREF and Py_DECREF which makes Python up to 1.17x slower.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39511>
_______________________________________

From report at bugs.python.org  Mon Apr 13 18:51:37 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 13 Apr 2020 22:51:37 +0000
Subject: [issue32894] AST unparsing of infinity numbers
In-Reply-To: <1519215659.19.0.467229070634.issue32894@psf.upfronthosting.co.za>
Message-ID: <1586818297.52.0.805327092766.issue32894@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 258f5179f9494189e6a80311c86981d2a88ba9d6 by Batuhan Ta?kaya in branch 'master':
bpo-32894: Support unparsing of infinity numbers in ast_unparser.c (GH-17426)
https://github.com/python/cpython/commit/258f5179f9494189e6a80311c86981d2a88ba9d6


----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32894>
_______________________________________

From report at bugs.python.org  Mon Apr 13 18:51:55 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 13 Apr 2020 22:51:55 +0000
Subject: [issue40255] Fixing Copy on Writes from reference counting
In-Reply-To: <1586619621.82.0.553262088399.issue40255@roundup.psfhosted.org>
Message-ID: <1586818315.02.0.315524751787.issue40255@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

> gc.freeze() has a similar issue, no? This function also comes from Instagram specific use case ;-)

Not really because this patch is much more impacting. gc.freeze() moves objects into a permanent generation making them not participate in the GC so the only leaks are cycle-based. With this patch immortal object will leak every strong reference that they have even if they don't participate in cycles (but also if they participate in cycles).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40255>
_______________________________________

From report at bugs.python.org  Mon Apr 13 18:54:02 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 13 Apr 2020 22:54:02 +0000
Subject: [issue40255] Fixing Copy on Writes from reference counting
In-Reply-To: <1586619621.82.0.553262088399.issue40255@roundup.psfhosted.org>
Message-ID: <1586818442.1.0.244114774481.issue40255@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I would be more interested by an experiment to move ob_refcnt outside PyObject to solve the Copy-on-Write issue, especially to measure the impact on performances.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40255>
_______________________________________

From report at bugs.python.org  Mon Apr 13 18:54:07 2020
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 13 Apr 2020 22:54:07 +0000
Subject: [issue39953] Let's update ssl error codes
In-Reply-To: <1584072470.83.0.437860249809.issue39953@roundup.psfhosted.org>
Message-ID: <1586818447.43.0.0765412585804.issue39953@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

Could you please give me a chance to review PRs for the SSL module? 

Python is still failing to compile with OpenSSL 1.0.2 and LibreSSL. The new table contains also wrong values for LibreSSL and OpenSSL 1.0.2.

----------
resolution: fixed -> 
stage: resolved -> patch review
status: closed -> open
type:  -> compile error

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39953>
_______________________________________

From report at bugs.python.org  Mon Apr 13 18:55:44 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 13 Apr 2020 22:55:44 +0000
Subject: [issue32894] AST unparsing of infinity numbers
In-Reply-To: <1519215659.19.0.467229070634.issue32894@psf.upfronthosting.co.za>
Message-ID: <1586818544.82.0.281356102885.issue32894@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

It seems like the fix works as expected:

>>> from __future__ import annotations
>>> def f(x: A[1e1000, 1e1000j]): pass
... 

>>> f.__annotations__
{'x': 'A[1e309, 1e309j]'}

>>> A=list
>>> eval(f.__annotations__['x'])
list[inf, infj]

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32894>
_______________________________________

From report at bugs.python.org  Mon Apr 13 19:08:03 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 13 Apr 2020 23:08:03 +0000
Subject: [issue39380] ftplib uses latin-1 as default encoding
In-Reply-To: <1579776260.84.0.333075912412.issue39380@roundup.psfhosted.org>
Message-ID: <1586819283.8.0.509770982457.issue39380@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset a1a0eb4a394a5ac7a8422616ce1ee4125a3ef74f by Sebastian Pedersen in branch 'master':
bpo-39380: Change ftplib encoding from latin-1 to utf-8 (GH-18048)
https://github.com/python/cpython/commit/a1a0eb4a394a5ac7a8422616ce1ee4125a3ef74f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39380>
_______________________________________

From report at bugs.python.org  Mon Apr 13 19:09:45 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 13 Apr 2020 23:09:45 +0000
Subject: [issue40274] 3D plotting library doesn't occlude objects by
 depth/perspective (objects in the scene are printed in layers).
In-Reply-To: <1586816074.17.0.60379010692.issue40274@roundup.psfhosted.org>
Message-ID: <1586819385.85.0.679491540953.issue40274@roundup.psfhosted.org>


Change by Eric V. Smith <eric at trueblade.com>:


----------
resolution:  -> third party
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40274>
_______________________________________

From report at bugs.python.org  Mon Apr 13 19:10:47 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 13 Apr 2020 23:10:47 +0000
Subject: [issue39380] ftplib uses latin-1 as default encoding
In-Reply-To: <1579776260.84.0.333075912412.issue39380@roundup.psfhosted.org>
Message-ID: <1586819447.09.0.344560084392.issue39380@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

It's now fixed. Thanks Eric V. Smith for suggesting the change and thanks Sebastian Pedersen for the very complete implementation (with tests and new constructor parameters!).

The default encoding change is documented properly in the "Changes in the Python API" section of What's New in Python 3.9.

Hopefully, it was already possible to override the encoding in Python 3.8 and older by modifying FTP.encoding class attribute.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39380>
_______________________________________

From report at bugs.python.org  Mon Apr 13 19:51:38 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Mon, 13 Apr 2020 23:51:38 +0000
Subject: [issue40208] Remove deprecated symtable.SymbolTable.has_exec
In-Reply-To: <1586192722.9.0.88612242995.issue40208@roundup.psfhosted.org>
Message-ID: <1586821898.86.0.332486452591.issue40208@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:


New changeset 990ea4200f05fcd8bce3de363f4d7745ae142385 by Batuhan Ta?kaya in branch 'master':
bpo-40208: Remove deprecated has_exec method of SymbolTable (GH-19396)
https://github.com/python/cpython/commit/990ea4200f05fcd8bce3de363f4d7745ae142385


----------
nosy: +corona10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40208>
_______________________________________

From report at bugs.python.org  Mon Apr 13 19:57:27 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 13 Apr 2020 23:57:27 +0000
Subject: [issue40241] [C API] Make PyGC_Head structure opaque,
 or even move it to the internal C API
In-Reply-To: <1586445596.83.0.583225080007.issue40241@roundup.psfhosted.org>
Message-ID: <1586822247.37.0.717637249907.issue40241@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +18854
pull_request: https://github.com/python/cpython/pull/19505

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40241>
_______________________________________

From report at bugs.python.org  Mon Apr 13 19:58:43 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Mon, 13 Apr 2020 23:58:43 +0000
Subject: [issue40208] Remove deprecated symtable.SymbolTable.has_exec
In-Reply-To: <1586192722.9.0.88612242995.issue40208@roundup.psfhosted.org>
Message-ID: <1586822323.73.0.959727298306.issue40208@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

The deletion of this symtable.SymbolTable.has_exec is now landed.
I would like to thank Batuhan and all the reviewers who have participated in this issue.

It's time for us to say goodbye to symtable.SymbolTable.has_exec.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40208>
_______________________________________

From report at bugs.python.org  Mon Apr 13 19:59:12 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 13 Apr 2020 23:59:12 +0000
Subject: [issue40268] Reorganize pycore_pystate.h header
In-Reply-To: <1586732467.85.0.974458317268.issue40268@roundup.psfhosted.org>
Message-ID: <1586822352.04.0.17077242312.issue40268@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

New changeset 0c13e1f96a9487e0efe63c3d3a05ff9738bd7dac by Victor Stinner in branch 'master':
bpo-40241: Add pycore_interp.h header (GH-19499)
https://github.com/python/cpython/commit/0c13e1f96a9487e0efe63c3d3a05ff9738bd7dac

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40268>
_______________________________________

From report at bugs.python.org  Mon Apr 13 19:59:27 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 13 Apr 2020 23:59:27 +0000
Subject: [issue40241] [C API] Make PyGC_Head structure opaque,
 or even move it to the internal C API
In-Reply-To: <1586445596.83.0.583225080007.issue40241@roundup.psfhosted.org>
Message-ID: <1586822367.51.0.0274938528629.issue40241@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> bpo-40241: Add pycore_interp.h header (GH-19499)

Oops, this change was for bpo-40268.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40241>
_______________________________________

From report at bugs.python.org  Mon Apr 13 19:59:33 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 13 Apr 2020 23:59:33 +0000
Subject: [issue40241] [C API] Make PyGC_Head structure opaque,
 or even move it to the internal C API
In-Reply-To: <1586445596.83.0.583225080007.issue40241@roundup.psfhosted.org>
Message-ID: <1586822373.36.0.284144264294.issue40241@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests:  -18854

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40241>
_______________________________________

From report at bugs.python.org  Mon Apr 13 19:59:52 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 13 Apr 2020 23:59:52 +0000
Subject: [issue40268] Reorganize pycore_pystate.h header
In-Reply-To: <1586732467.85.0.974458317268.issue40268@roundup.psfhosted.org>
Message-ID: <1586822391.99.0.651957928094.issue40268@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +18855
pull_request: https://github.com/python/cpython/pull/19505

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40268>
_______________________________________

From report at bugs.python.org  Mon Apr 13 19:59:52 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 13 Apr 2020 23:59:52 +0000
Subject: [issue40241] [C API] Make PyGC_Head structure opaque,
 or even move it to the internal C API
In-Reply-To: <1586445596.83.0.583225080007.issue40241@roundup.psfhosted.org>
Message-ID: <1586822392.09.0.0697337530572.issue40241@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +18856
pull_request: https://github.com/python/cpython/pull/19505

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40241>
_______________________________________

From report at bugs.python.org  Mon Apr 13 20:37:12 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 14 Apr 2020 00:37:12 +0000
Subject: [issue39321] AMD64 FreeBSD Non-Debug 3.x: out of swap space (test
 process killed by signal 9)
In-Reply-To: <1578925087.43.0.642221025557.issue39321@roundup.psfhosted.org>
Message-ID: <1586824632.95.0.486811430539.issue39321@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

koobs: Any update on this swap issue?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39321>
_______________________________________

From report at bugs.python.org  Mon Apr 13 20:37:59 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 14 Apr 2020 00:37:59 +0000
Subject: [issue38644] Pass explicitly tstate to function calls
In-Reply-To: <1572445884.39.0.966254854932.issue38644@roundup.psfhosted.org>
Message-ID: <1586824679.86.0.781655641948.issue38644@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38644>
_______________________________________

From report at bugs.python.org  Mon Apr 13 20:51:26 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 14 Apr 2020 00:51:26 +0000
Subject: [issue39943] Meta: Clean up various issues in C internals
In-Reply-To: <1583983387.49.0.277830283994.issue39943@roundup.psfhosted.org>
Message-ID: <1586825486.77.0.957146700337.issue39943@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Not sure if it's related to changes made recently on this issue, but I started to notice these compiler warnings on Windows:



D:\a\cpython\cpython\Modules\sre_lib.h(822,21): warning C4090: 'function': different 'const' qualifiers [D:\a\cpython\cpython\PCbuild\pythoncore.vcxproj]
D:\a\cpython\cpython\Modules\sre_lib.h(1058,17): warning C4090: 'function': different 'const' qualifiers [D:\a\cpython\cpython\PCbuild\pythoncore.vcxproj]
D:\a\cpython\cpython\Modules\sre_lib.h(1064,17): warning C4090: 'function': different 'const' qualifiers [D:\a\cpython\cpython\PCbuild\pythoncore.vcxproj]
D:\a\cpython\cpython\Modules\sre_lib.h(1134,13): warning C4090: 'function': different 'const' qualifiers [D:\a\cpython\cpython\PCbuild\pythoncore.vcxproj]
D:\a\cpython\cpython\Modules\sre_lib.h(822,21): warning C4090: 'function': different 'const' qualifiers [D:\a\cpython\cpython\PCbuild\pythoncore.vcxproj]
D:\a\cpython\cpython\Modules\sre_lib.h(1058,17): warning C4090: 'function': different 'const' qualifiers [D:\a\cpython\cpython\PCbuild\pythoncore.vcxproj]
D:\a\cpython\cpython\Modules\sre_lib.h(1064,17): warning C4090: 'function': different 'const' qualifiers [D:\a\cpython\cpython\PCbuild\pythoncore.vcxproj]
D:\a\cpython\cpython\Modules\sre_lib.h(1134,13): warning C4090: 'function': different 'const' qualifiers [D:\a\cpython\cpython\PCbuild\pythoncore.vcxproj]
D:\a\cpython\cpython\Modules\sre_lib.h(822,21): warning C4090: 'function': different 'const' qualifiers [D:\a\cpython\cpython\PCbuild\pythoncore.vcxproj]
D:\a\cpython\cpython\Modules\sre_lib.h(1058,17): warning C4090: 'function': different 'const' qualifiers [D:\a\cpython\cpython\PCbuild\pythoncore.vcxproj]
D:\a\cpython\cpython\Modules\sre_lib.h(1064,17): warning C4090: 'function': different 'const' qualifiers [D:\a\cpython\cpython\PCbuild\pythoncore.vcxproj]
D:\a\cpython\cpython\Modules\sre_lib.h(1134,13): warning C4090: 'function': different 'const' qualifiers [D:\a\cpython\cpython\PCbuild\pythoncore.vcxproj]
D:\a\cpython\cpython\Modules\_sre.c(457,26): warning C4090: 'function': different 'const' qualifiers [D:\a\cpython\cpython\PCbuild\pythoncore.vcxproj]
D:\a\cpython\cpython\Modules\_sre.c(471,26): warning C4090: 'function': different 'const' qualifiers [D:\a\cpython\cpython\PCbuild\pythoncore.vcxproj]

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39943>
_______________________________________

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: [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: [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 22:49:16 2020
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 14 Apr 2020 02:49:16 +0000
Subject: [issue40266] Failure to build _ssl module on ubuntu xenial
In-Reply-To: <1586722609.26.0.314965536558.issue40266@roundup.psfhosted.org>
Message-ID: <1586832556.34.0.978590301822.issue40266@roundup.psfhosted.org>


Change by Benjamin Peterson <benjamin at python.org>:


----------
keywords: +patch
pull_requests: +18857
stage: resolved -> patch review
pull_request: https://github.com/python/cpython/pull/19506

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40266>
_______________________________________

From report at bugs.python.org  Mon Apr 13 22:51:58 2020
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 14 Apr 2020 02:51:58 +0000
Subject: [issue39953] Let's update ssl error codes
In-Reply-To: <1586818447.43.0.0765412585804.issue39953@roundup.psfhosted.org>
Message-ID: <81de0996-618c-425e-850b-ea76a19a47ed@www.fastmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

On Mon, Apr 13, 2020, at 17:54, Christian Heimes wrote:
> 
> Christian Heimes <lists at cheimes.de> added the comment:
> 
> Could you please give me a chance to review PRs for the SSL module? 

The original PR was open for 23 days before I merged it. I happy to here feedback at any point during the lifetime of a change, though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39953>
_______________________________________

From report at bugs.python.org  Mon Apr 13 23:11:51 2020
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 14 Apr 2020 03:11:51 +0000
Subject: [issue39953] Let's update ssl error codes
In-Reply-To: <1584072470.83.0.437860249809.issue39953@roundup.psfhosted.org>
Message-ID: <1586833911.49.0.839072610227.issue39953@roundup.psfhosted.org>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset 584a3cfda4d7a65ea0c1ea1ee541378bb7be46ca by Benjamin Peterson in branch 'master':
closes bpo-40266, closes bpo-39953: Use numeric lib code if compiling against old OpenSSL. (GH-19506)
https://github.com/python/cpython/commit/584a3cfda4d7a65ea0c1ea1ee541378bb7be46ca


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39953>
_______________________________________

From report at bugs.python.org  Mon Apr 13 23:11:51 2020
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 14 Apr 2020 03:11:51 +0000
Subject: [issue40266] Failure to build _ssl module on ubuntu xenial
In-Reply-To: <1586722609.26.0.314965536558.issue40266@roundup.psfhosted.org>
Message-ID: <1586833911.62.0.441769082902.issue40266@roundup.psfhosted.org>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset 584a3cfda4d7a65ea0c1ea1ee541378bb7be46ca by Benjamin Peterson in branch 'master':
closes bpo-40266, closes bpo-39953: Use numeric lib code if compiling against old OpenSSL. (GH-19506)
https://github.com/python/cpython/commit/584a3cfda4d7a65ea0c1ea1ee541378bb7be46ca


----------
resolution: duplicate -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40266>
_______________________________________

From report at bugs.python.org  Mon Apr 13 23:12:08 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 14 Apr 2020 03:12:08 +0000
Subject: [issue40266] Failure to build _ssl module on ubuntu xenial
In-Reply-To: <1586722609.26.0.314965536558.issue40266@roundup.psfhosted.org>
Message-ID: <1586833928.84.0.111065526237.issue40266@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
nosy: +miss-islington
nosy_count: 4.0 -> 5.0
pull_requests: +18858
pull_request: https://github.com/python/cpython/pull/19507

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40266>
_______________________________________

From report at bugs.python.org  Mon Apr 13 23:12:08 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 14 Apr 2020 03:12:08 +0000
Subject: [issue39953] Let's update ssl error codes
In-Reply-To: <1584072470.83.0.437860249809.issue39953@roundup.psfhosted.org>
Message-ID: <1586833928.92.0.923658402692.issue39953@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +18859
pull_request: https://github.com/python/cpython/pull/19507

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39953>
_______________________________________

From report at bugs.python.org  Mon Apr 13 23:31:25 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 14 Apr 2020 03:31:25 +0000
Subject: [issue39953] Let's update ssl error codes
In-Reply-To: <1584072470.83.0.437860249809.issue39953@roundup.psfhosted.org>
Message-ID: <1586835085.33.0.151739063675.issue39953@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset c496e29c2bd0c29327c93174d5a40d2dc5a09402 by Miss Islington (bot) in branch '3.8':
closes bpo-40266, closes bpo-39953: Use numeric lib code if compiling against old OpenSSL. (GH-19506)
https://github.com/python/cpython/commit/c496e29c2bd0c29327c93174d5a40d2dc5a09402


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39953>
_______________________________________

From report at bugs.python.org  Mon Apr 13 23:31:25 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 14 Apr 2020 03:31:25 +0000
Subject: [issue40266] Failure to build _ssl module on ubuntu xenial
In-Reply-To: <1586722609.26.0.314965536558.issue40266@roundup.psfhosted.org>
Message-ID: <1586835085.46.0.870442183024.issue40266@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset c496e29c2bd0c29327c93174d5a40d2dc5a09402 by Miss Islington (bot) in branch '3.8':
closes bpo-40266, closes bpo-39953: Use numeric lib code if compiling against old OpenSSL. (GH-19506)
https://github.com/python/cpython/commit/c496e29c2bd0c29327c93174d5a40d2dc5a09402


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40266>
_______________________________________

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: [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 00:10:34 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 14 Apr 2020 04:10:34 +0000
Subject: [issue40278] pathlib Path.replace raises OSError when target exists
In-Reply-To: <1586835419.23.0.357197099635.issue40278@roundup.psfhosted.org>
Message-ID: <1586837434.02.0.466436129847.issue40278@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

replace under the hood uses os.replace. The docs for os.replace indicate error for certain scenarios where target is a directory : https://docs.python.org/3/library/os.html#os.replace . See also some difference between os.rename and os.replace : https://bugs.python.org/issue27886

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python, pitrou, serhiy.storchaka, xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40278>
_______________________________________

From report at bugs.python.org  Tue Apr 14 00:45:59 2020
From: report at bugs.python.org (Michael Selik)
Date: Tue, 14 Apr 2020 04:45:59 +0000
Subject: [issue40278] pathlib Path.replace raises OSError when target exists
In-Reply-To: <1586835419.23.0.357197099635.issue40278@roundup.psfhosted.org>
Message-ID: <1586839559.27.0.354244400803.issue40278@roundup.psfhosted.org>


Michael Selik <mike at selik.org> added the comment:

The docs for ``os.replace`` says "If dst is a directory, OSError will be raised."  That's helpful, but the docs for ``pathlib.Path.replace`` make it seem like the target will be unconditionally replaced regardless of whether it's a file or directory.  Sure, there's the association of the two functions in the correspondence table in the pathlib docs, but that's easy to overlook when looking up ``pathlib.Path.replace``.

If nothing else, I guess this is a request to alter the docstring.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40278>
_______________________________________

From report at bugs.python.org  Tue Apr 14 00:53:11 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 14 Apr 2020 04:53:11 +0000
Subject: [issue39481] Implement PEP 585 (Type Hinting Generics In Standard
 Collections)
In-Reply-To: <1580231817.93.0.47144630055.issue39481@roundup.psfhosted.org>
Message-ID: <1586839991.19.0.825148440901.issue39481@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:


New changeset cecf049673da6a24435acd1a6a3b34472b323c97 by Ethan Smith in branch 'master':
bpo-39481: Make functools.cached_property, partial, partialmethod generic (#19427)
https://github.com/python/cpython/commit/cecf049673da6a24435acd1a6a3b34472b323c97


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39481>
_______________________________________

From report at bugs.python.org  Tue Apr 14 00:54:43 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 14 Apr 2020 04:54:43 +0000
Subject: [issue39481] Implement PEP 585 (Type Hinting Generics In Standard
 Collections)
In-Reply-To: <1580231817.93.0.47144630055.issue39481@roundup.psfhosted.org>
Message-ID: <1586840083.51.0.666285850084.issue39481@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:


New changeset 8ef875028a3644a329c87ce420a73793e315143f by Ethan Smith in branch 'master':
bpo-39481: Make weakref and WeakSet generic (GH-19497)
https://github.com/python/cpython/commit/8ef875028a3644a329c87ce420a73793e315143f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39481>
_______________________________________

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: [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: [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 03:20:09 2020
From: report at bugs.python.org (=?utf-8?b?VmVkcmFuIMSMYcSNacSH?=)
Date: Tue, 14 Apr 2020 07:20:09 +0000
Subject: [issue40257] Improve the use of __doc__ in pydoc
In-Reply-To: <1586638478.83.0.463728061154.issue40257@roundup.psfhosted.org>
Message-ID: <1586848809.39.0.327783500285.issue40257@roundup.psfhosted.org>


Vedran ?a?i? <vedgar at gmail.com> added the comment:

Ok, I get what you're saying. But if someone writes

    class B(A):
      # no docstring at all
      ...

    help(B)

they'll still get other elements of current help? Particularly, "Methods inherited from A" (with their docstrings)?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40257>
_______________________________________

From report at bugs.python.org  Tue Apr 14 03:45:59 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 14 Apr 2020 07:45:59 +0000
Subject: [issue40257] Improve the use of __doc__ in pydoc
In-Reply-To: <1586638478.83.0.463728061154.issue40257@roundup.psfhosted.org>
Message-ID: <1586850359.51.0.209241987792.issue40257@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Yes, of course. And if it overrides some methods, but do not specify doctrings for new methods, they will be inherited from the parent class.

class A:
    """Base class"""
    def foo(self): """Some docstring"""
    def bar(self): """Other docstring"""

class B(A):
    def foo(self): pass

help(B)

Help on class B in module __main__:

class B(A)
 |  Method resolution order:
 |      B
 |      A
 |      builtins.object
 |  
 |  Methods defined here:
 |  
 |  foo(self)
 |      Some docstring
 |  
 |  ----------------------------------------------------------------------
 |  Methods inherited from A:
 |  
 |  bar(self)
 |      Other docstring
 |  
...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40257>
_______________________________________

From report at bugs.python.org  Tue Apr 14 03:51:12 2020
From: report at bugs.python.org (Torsten Landschoff)
Date: Tue, 14 Apr 2020 07:51:12 +0000
Subject: [issue36780] Interpreter exit blocks waiting for futures of shut-down
 ThreadPoolExecutors
In-Reply-To: <1556875683.94.0.285155490659.issue36780@roundup.psfhosted.org>
Message-ID: <1586850672.57.0.378916009875.issue36780@roundup.psfhosted.org>


Torsten Landschoff <t.landschoff at gmx.net> added the comment:

I intended to file a bug because of the shutdown problem but found out there is this ticket already.

In our application we sometimes run into this problem that you can't exit because of a hanging TCP connection used inside a ThreadPoolExecutor task. 

executor.shutdown(wait=False) does not help - the process still hangs.

Another problem was inside our tests were a bug caused a hanging task inside a thread pool executor and the test runner (pytest) would not terminate because of this.

I actually went so far to drop the thread reference inside the concurrent.futures.thread module. :-(

A documented way to drop a hanging executor thread would be very much appreciated.

----------
nosy: +torsten

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36780>
_______________________________________

From report at bugs.python.org  Tue Apr 14 04:03:56 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 14 Apr 2020 08:03:56 +0000
Subject: [issue39943] Meta: Clean up various issues in C internals
In-Reply-To: <1583983387.49.0.277830283994.issue39943@roundup.psfhosted.org>
Message-ID: <1586851436.68.0.320008250873.issue39943@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Yes, it is a consequence of PR 19345. But it looks like a compiler bug. It complains about implicit conversion from `const void **` to `void *` in memcpy() and PyMem_Del().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39943>
_______________________________________

From report at bugs.python.org  Tue Apr 14 04:12:25 2020
From: report at bugs.python.org (Russell Davis)
Date: Tue, 14 Apr 2020 08:12:25 +0000
Subject: [issue29255] selects.KqueueSelector behaves incorrectly when no fds
 are registered
In-Reply-To: <1484264107.13.0.0489042381572.issue29255@psf.upfronthosting.co.za>
Message-ID: <1586851945.16.0.128821884158.issue29255@roundup.psfhosted.org>


Change by Russell Davis <russell.davis at gmail.com>:


----------
keywords: +patch
pull_requests: +18860
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19508

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29255>
_______________________________________

From report at bugs.python.org  Tue Apr 14 04:12:25 2020
From: report at bugs.python.org (Russell Davis)
Date: Tue, 14 Apr 2020 08:12:25 +0000
Subject: [issue25680] Selector.select() hangs when there is nothing to select
In-Reply-To: <1448029102.96.0.470819036773.issue25680@psf.upfronthosting.co.za>
Message-ID: <1586851945.22.0.20992865456.issue25680@roundup.psfhosted.org>


Change by Russell Davis <russell.davis at gmail.com>:


----------
keywords: +patch
pull_requests: +18861
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19508

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25680>
_______________________________________

From report at bugs.python.org  Tue Apr 14 04:14:37 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 14 Apr 2020 08:14:37 +0000
Subject: [issue40280] Consider supporting emscripten/webassembly as a build
 target
In-Reply-To: <1586848295.92.0.690921486188.issue40280@roundup.psfhosted.org>
Message-ID: <1586852077.36.0.208014915892.issue40280@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Do you want to provide a pull request?

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40280>
_______________________________________

From report at bugs.python.org  Tue Apr 14 04:50:40 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 14 Apr 2020 08:50:40 +0000
Subject: [issue40280] Consider supporting emscripten/webassembly as a build
 target
In-Reply-To: <1586848295.92.0.690921486188.issue40280@roundup.psfhosted.org>
Message-ID: <1586854240.51.0.713052501845.issue40280@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40280>
_______________________________________

From report at bugs.python.org  Tue Apr 14 04:58:34 2020
From: report at bugs.python.org (pmp-p)
Date: Tue, 14 Apr 2020 08:58:34 +0000
Subject: [issue40280] Consider supporting emscripten/webassembly as a build
 target
In-Reply-To: <1586848295.92.0.690921486188.issue40280@roundup.psfhosted.org>
Message-ID: <1586854714.62.0.586609535151.issue40280@roundup.psfhosted.org>


pmp-p <pmpp.pub at gmail.com> added the comment:

you can add 
* https://github.com/pmp-p/pydk/tree/master/sources.em/Python-3.8.0b4.patchset -- Python 3.8.x 

(wasm not asm.js, clang-10+ required)

demo https://pmp-p.github.io/python-next/test.html

CPython can already run in the browser with very little patching, but major issues are :
 
 - asyncify'ing the whole wasm VM to have pre-emption over cPython's one to prevent blocking I/O slows down things *a lot* (10x)
=> (very?) bad user experience.

 - the size of vm + stdlib  ~ 30 MiB and wasm compilation time.
=> bad user experience on first load or slow connexion.

 - the lack of threading in wasm MinimumViableProduct specification (but this is the browser standard for now), that leads to rewrite bits of stdlib ( like eg asyncio module )
=> adding more maintenance burden on stdlib (!)


i tested them all and my personnal opinion is : I can see no use case that would favour "stock" cPython wasm versus a blazing fast MicroPytho (or pycopy) wasm flavour or supercharged full stack pyodide.

----------
nosy: +pmpp

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40280>
_______________________________________

From report at bugs.python.org  Tue Apr 14 04:59:32 2020
From: report at bugs.python.org (=?utf-8?b?VmVkcmFuIMSMYcSNacSH?=)
Date: Tue, 14 Apr 2020 08:59:32 +0000
Subject: [issue40257] Improve the use of __doc__ in pydoc
In-Reply-To: <1586638478.83.0.463728061154.issue40257@roundup.psfhosted.org>
Message-ID: <1586854772.81.0.274156288066.issue40257@roundup.psfhosted.org>


Vedran ?a?i? <vedgar at gmail.com> added the comment:

Then I'm fine with it. Thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40257>
_______________________________________

From report at bugs.python.org  Tue Apr 14 07:44:34 2020
From: report at bugs.python.org (hai shi)
Date: Tue, 14 Apr 2020 11:44:34 +0000
Subject: [issue40255] Fixing Copy on Writes from reference counting
In-Reply-To: <1586619621.82.0.553262088399.issue40255@roundup.psfhosted.org>
Message-ID: <1586864674.94.0.731635586203.issue40255@roundup.psfhosted.org>


Change by hai shi <shihai1991 at 126.com>:


----------
nosy: +shihai1991

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40255>
_______________________________________

From report at bugs.python.org  Tue Apr 14 08:20:16 2020
From: report at bugs.python.org (Gavin D'souza)
Date: Tue, 14 Apr 2020 12:20:16 +0000
Subject: [issue40271] Allow shell like paths in
In-Reply-To: <1586774030.36.0.315208521295.issue40271@roundup.psfhosted.org>
Message-ID: <1586866816.2.0.467624962619.issue40271@roundup.psfhosted.org>


Gavin D'souza <gavin18d at gmail.com> added the comment:

@serhiy.storchaka That makes perfect sense. Could we do something to add a parameter perhaps, to evaluate literal paths to not bread existing code? although this isn't "needed" but it'd be neat to handle this internally

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40271>
_______________________________________

From report at bugs.python.org  Tue Apr 14 08:26:31 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 14 Apr 2020 12:26:31 +0000
Subject: [issue40268] Reorganize pycore_pystate.h header
In-Reply-To: <1586732467.85.0.974458317268.issue40268@roundup.psfhosted.org>
Message-ID: <1586867191.64.0.904551468843.issue40268@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 4a3fe0835310643193ea45529ab0fb45c5f8f2fd by Victor Stinner in branch 'master':
bpo-40268: Include explicitly pycore_interp.h (GH-19505)
https://github.com/python/cpython/commit/4a3fe0835310643193ea45529ab0fb45c5f8f2fd


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40268>
_______________________________________

From report at bugs.python.org  Tue Apr 14 08:39:08 2020
From: report at bugs.python.org (Simon Biggs)
Date: Tue, 14 Apr 2020 12:39:08 +0000
Subject: [issue40280] Consider supporting emscripten/webassembly as a build
 target
In-Reply-To: <1586854714.62.0.586609535151.issue40280@roundup.psfhosted.org>
Message-ID: <CAALqB0CHDzmYY863=T5ev9QaNbvde=45Sag6e1iRnF=xLaDHHw@mail.gmail.com>


Simon Biggs <simon.grant.biggs at gmail.com> added the comment:

Hi pmp-p and Serhiy,

I'd be more than happy to attempt a pull request, but I imagine a change
such as this needs to be discussed first, trying not to "rush to make a
patch" (https://www.youtube.com/watch?v=voXVTjwnn-U&feature=youtu.be&t=2546).
Also, I doubt I will do a good job of it... but I am more than happy to try.

A note regarding "supercharged full stack pyodide", potentially without
efforts such as upstreaming into CPython and emscripten the relevant
patches, that supercharged full stack may just unfortunately stagnate. See
https://github.com/iodide-project/pyodide/issues/635#issuecomment-613408912

With respect to blocking when running Python as WASM, I have found running
the WebAssembly CPython within a webworker and signalling data back and
forth causes there to be no UI issues. It ends up being quite a neat set
up. Main down side right now however is the set up is currently going
stale, hence me believing reaching out like this is in the best interests
of Python going forward.

Cheers,
Simon

On Tue, 14 Apr 2020 at 18:58, pmp-p <report at bugs.python.org> wrote:

>
> pmp-p <pmpp.pub at gmail.com> added the comment:
>
> you can add
> *
> https://github.com/pmp-p/pydk/tree/master/sources.em/Python-3.8.0b4.patchset
> -- Python 3.8.x
>
> (wasm not asm.js, clang-10+ required)
>
> demo https://pmp-p.github.io/python-next/test.html
>
> CPython can already run in the browser with very little patching, but
> major issues are :
>
>  - asyncify'ing the whole wasm VM to have pre-emption over cPython's one
> to prevent blocking I/O slows down things *a lot* (10x)
> => (very?) bad user experience.
>
>  - the size of vm + stdlib  ~ 30 MiB and wasm compilation time.
> => bad user experience on first load or slow connexion.
>
>  - the lack of threading in wasm MinimumViableProduct specification (but
> this is the browser standard for now), that leads to rewrite bits of stdlib
> ( like eg asyncio module )
> => adding more maintenance burden on stdlib (!)
>
>
> i tested them all and my personnal opinion is : I can see no use case that
> would favour "stock" cPython wasm versus a blazing fast MicroPytho (or
> pycopy) wasm flavour or supercharged full stack pyodide.
>
> ----------
> nosy: +pmpp
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue40280>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40280>
_______________________________________

From report at bugs.python.org  Tue Apr 14 08:49:21 2020
From: report at bugs.python.org (Michael Felt)
Date: Tue, 14 Apr 2020 12:49:21 +0000
Subject: [issue40244] AIX: build: _PyObject_GC_TRACK Asstertion failure
In-Reply-To: <1586812753.29.0.127360360341.issue40244@roundup.psfhosted.org>
Message-ID: <ecdea6b8-8f73-677a-e43d-4ecb7cce5835@felt.demon.nl>


Michael Felt <aixtools at felt.demon.nl> added the comment:

With the print statements - it does not crash:

???????? ./python -E -S -m sysconfig --generate-posix-vars ; if test $?
-ne 0 ; then? echo "generate-posix-vars failed" ;? rm -f
./pybuilddir.txt ;? exit 1 ;? fi
Objects/genobject.c:122:537318120
Objects/genobject.c:126:0
Objects/genobject.c:131:0
Objects/genobject.c:135:537318120
Objects/genobject.c:122:805942488
Objects/genobject.c:126:0
Objects/genobject.c:131:0
Objects/genobject.c:135:537318120
...

diff --git a/Objects/genobject.c b/Objects/genobject.c
index d3455f8..b8287a3 100644
--- a/Objects/genobject.c
+++ b/Objects/genobject.c
@@ -117,14 +117,23 @@ exc_state_clear(_PyErr_StackItem *exc_state)
?static void
?gen_dealloc(PyGenObject *gen)
?{
+#include <stdio.h>
???? PyObject *self = (PyObject *) gen;
+??? fprintf(stderr,"%s:%d:%ld\n", __FILE__,__LINE__,
_Py_AS_GC(self)->_gc_next);
+??? fflush(stderr);

???? _PyObject_GC_UNTRACK(gen);
+??? fprintf(stderr,"%s:%d:%ld\n", __FILE__,__LINE__,
_Py_AS_GC(self)->_gc_next);
+??? fflush(stderr);

???? if (gen->gi_weakreflist != NULL)
???????? PyObject_ClearWeakRefs(self);
+??? fprintf(stderr,"%s:%d:%ld\n", __FILE__,__LINE__,
_Py_AS_GC(self)->_gc_next);
+??? fflush(stderr);

???? _PyObject_GC_TRACK(self);
+??? fprintf(stderr,"%s:%d:%ld\n", __FILE__,__LINE__,
_Py_AS_GC(self)->_gc_next);
+??? fflush(stderr);

???? if (PyObject_CallFinalizerFromDealloc(self))
???????? return;???????????????????? /* resurrected.? :( */
$

On 13/04/2020 23:19, Batuhan Taskaya wrote:
> Batuhan Taskaya <batuhanosmantaskaya at gmail.com> added the comment:
>
> @Michael.Felt can you just insert some prints between these 3 to see what is going on (and re-compile)
>
> static void
> gen_dealloc(PyGenObject *gen)
> {
>     PyObject *self = (PyObject *) gen;
> <<<<
>     _PyObject_GC_UNTRACK(gen);
> <<<<
>     if (gen->gi_weakreflist != NULL)
>         PyObject_ClearWeakRefs(self);
> <<<<
>     _PyObject_GC_TRACK(self);
>
>
> something like this should work: printf("%ld\n", _Py_AS_GC(self)->_gc_next);
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue40244>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40244>
_______________________________________

From report at bugs.python.org  Tue Apr 14 08:53:04 2020
From: report at bugs.python.org (Michael Felt)
Date: Tue, 14 Apr 2020 12:53:04 +0000
Subject: [issue40244] AIX: build: _PyObject_GC_TRACK Asstertion failure
In-Reply-To: <1586816309.41.0.344299340093.issue40244@roundup.psfhosted.org>
Message-ID: <369df245-35e0-134f-32d4-368ae75ef0be@felt.demon.nl>


Michael Felt <aixtools at felt.demon.nl> added the comment:

Also tried this:

???????? ./python -E -S -m sysconfig --generate-posix-vars ; if test $?
-ne 0 ; then? echo "generate-posix-vars failed" ;? rm -f
./pybuilddir.txt ;? exit 1 ;? fi
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? : 30084150
object refcount : 0
object type???? : 20013718
object type name: generator
object repr???? : <refcnt 0 at 30084150>

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
/bin/sh: 17302202 IOT/Abort trap(coredump)
make: 1254-004 The error code from the last command is 134.

Stop.
$ git diff
diff --git a/Objects/genobject.c b/Objects/genobject.c
index d3455f8..e783636 100644
--- a/Objects/genobject.c
+++ b/Objects/genobject.c
@@ -119,7 +119,7 @@ gen_dealloc(PyGenObject *gen)
?{
???? PyObject *self = (PyObject *) gen;

-??? _PyObject_GC_UNTRACK(gen);
+??? _PyObject_GC_UNTRACK(self);

???? if (gen->gi_weakreflist != NULL)
???????? PyObject_ClearWeakRefs(self);
$

On 14/04/2020 00:18, Batuhan Taskaya wrote:
> Batuhan Taskaya <batuhanosmantaskaya at gmail.com> added the comment:
>
> By the noticed something that looks kind of weird, not sure if it is intentional or not but shouldn't this be self instead of gen
>
> static void
> gen_dealloc(PyGenObject *gen)
> {
>     PyObject *self = (PyObject *) gen;
> <<<<
> _PyObject_GC_UNTRACK(gen);
> <<<<
>     if (gen->gi_weakreflist != NULL)
>         PyObject_ClearWeakRefs(self);
>     _PyObject_GC_TRACK(self);
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue40244>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40244>
_______________________________________

From report at bugs.python.org  Tue Apr 14 08:53:33 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 14 Apr 2020 12:53:33 +0000
Subject: [issue40268] Reorganize pycore_pystate.h header
In-Reply-To: <1586732467.85.0.974458317268.issue40268@roundup.psfhosted.org>
Message-ID: <1586868813.06.0.348605770179.issue40268@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +18862
pull_request: https://github.com/python/cpython/pull/19509

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40268>
_______________________________________

From report at bugs.python.org  Tue Apr 14 08:54:21 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Tue, 14 Apr 2020 12:54:21 +0000
Subject: [issue40244] AIX: build: _PyObject_GC_TRACK Asstertion failure
In-Reply-To: <1586507316.69.0.786578254213.issue40244@roundup.psfhosted.org>
Message-ID: <1586868861.11.0.58963123772.issue40244@roundup.psfhosted.org>


Batuhan Taskaya <batuhanosmantaskaya at gmail.com> added the comment:

> With the print statements - it does not crash:

I think this isn't directly relevant with prints but about re-compiling? (just guessing). Because I experienced when I compile python for the first time on a clean AIX environment, all extension modules failed to build. When I recompiled (with keeping all artifacts from previous build) some of them successfully got compiled. When I try to compile again, most of them successfully compiled. I'm sorry but I don't know why this happens or how to solve it. We can always revert that change but I guess that isn't the real problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40244>
_______________________________________

From report at bugs.python.org  Tue Apr 14 08:56:14 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Tue, 14 Apr 2020 12:56:14 +0000
Subject: [issue40244] AIX: build: _PyObject_GC_TRACK Asstertion failure
In-Reply-To: <1586507316.69.0.786578254213.issue40244@roundup.psfhosted.org>
Message-ID: <1586868974.06.0.135576636765.issue40244@roundup.psfhosted.org>


Batuhan Taskaya <batuhanosmantaskaya at gmail.com> added the comment:

> Also tried this:

Thanks for it, that was just something that I slightly suspected but expected to see it crash.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40244>
_______________________________________

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: [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 09:13:42 2020
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 14 Apr 2020 13:13:42 +0000
Subject: [issue40281] Add pathlib.PurePath.as_uri()
In-Reply-To: <1586869981.39.0.314985055066.issue40281@roundup.psfhosted.org>
Message-ID: <1586870022.09.0.540184565831.issue40281@roundup.psfhosted.org>


Change by Antoine Pitrou <solipsis at pitrou.net>:


----------
nosy: +barneygale

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40281>
_______________________________________

From report at bugs.python.org  Tue Apr 14 09:14:10 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 14 Apr 2020 13:14:10 +0000
Subject: [issue40268] Reorganize pycore_pystate.h header
In-Reply-To: <1586732467.85.0.974458317268.issue40268@roundup.psfhosted.org>
Message-ID: <1586870050.56.0.89906880273.issue40268@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 81a7be3fa22c983209cc0ffb3537b92b0370f83c by Victor Stinner in branch 'master':
bpo-40268: Rename _PyInterpreterState_GET_UNSAFE() (GH-19509)
https://github.com/python/cpython/commit/81a7be3fa22c983209cc0ffb3537b92b0370f83c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40268>
_______________________________________

From report at bugs.python.org  Tue Apr 14 09:16:01 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Tue, 14 Apr 2020 13:16:01 +0000
Subject: [issue40221] Use new _at_fork_reinit() lock method in multiprocessing
In-Reply-To: <1586300633.14.0.457029058496.issue40221@roundup.psfhosted.org>
Message-ID: <1586870161.23.0.257266294569.issue40221@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:


New changeset e1945307d36849f8be8937144cf3dd6ebab6274c by Dong-hee Na in branch 'master':
bpo-40221: Update multiprocessing to use _at_fork_reinit (GH-19477)
https://github.com/python/cpython/commit/e1945307d36849f8be8937144cf3dd6ebab6274c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40221>
_______________________________________

From report at bugs.python.org  Tue Apr 14 09:55:23 2020
From: report at bugs.python.org (Steve Dower)
Date: Tue, 14 Apr 2020 13:55:23 +0000
Subject: [issue39511] [subinterpreters] Per-interpreter singletons (None, True,
 False, etc.)
In-Reply-To: <1580484815.27.0.407070570821.issue39511@roundup.psfhosted.org>
Message-ID: <1586872523.52.0.0612630758554.issue39511@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
nosy: +steve.dower

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39511>
_______________________________________

From report at bugs.python.org  Tue Apr 14 09:55:00 2020
From: report at bugs.python.org (Steve Dower)
Date: Tue, 14 Apr 2020 13:55:00 +0000
Subject: [issue40255] Fixing Copy on Writes from reference counting
In-Reply-To: <1586619621.82.0.553262088399.issue40255@roundup.psfhosted.org>
Message-ID: <1586872500.97.0.19608931623.issue40255@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

>> This isn't actually about removing immortal objects, but removing *mutable*
>> objects that would be shared between subinterpreters. Making some objects
>> immortal, such as interned strings or stateless singletons, would actually
>> benefit this work, as they could then be safely shared between
>> subinterpreters.
> 
> From what I understood, we simply cannot share any object (mutable or not)
> between two subinterpreters. Otherwise, we will need to put a lock on all
> Py_INCREF/Py_DECREF operation which would kill performances of running
> multiple interpreters in parallel. Join bpo-39511 discussion.

That thread consists of everyone else telling you what I've just told you. Not sure that me telling you as well is going to help ;)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40255>
_______________________________________

From report at bugs.python.org  Tue Apr 14 09:55:22 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 14 Apr 2020 13:55:22 +0000
Subject: [issue40268] Reorganize pycore_pystate.h header
In-Reply-To: <1586732467.85.0.974458317268.issue40268@roundup.psfhosted.org>
Message-ID: <1586872522.86.0.563111762834.issue40268@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +18863
pull_request: https://github.com/python/cpython/pull/19510

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40268>
_______________________________________

From report at bugs.python.org  Tue Apr 14 10:01:21 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 14 Apr 2020 14:01:21 +0000
Subject: [issue39947] [C API] Make the PyThreadState structure opaque (move it
 to the internal C API)
In-Reply-To: <1584035214.47.0.672795796186.issue39947@roundup.psfhosted.org>
Message-ID: <1586872881.35.0.98474896323.issue39947@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
title: Make the PyThreadState structure opaque (move it to the internal C API) -> [C API] Make the PyThreadState structure opaque (move it to the internal C API)

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39947>
_______________________________________

From report at bugs.python.org  Tue Apr 14 10:23:58 2020
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 14 Apr 2020 14:23:58 +0000
Subject: [issue40255] Fixing Copy on Writes from reference counting
In-Reply-To: <1586619621.82.0.553262088399.issue40255@roundup.psfhosted.org>
Message-ID: <1586874238.64.0.941532978048.issue40255@roundup.psfhosted.org>


Antoine Pitrou <solipsis at pitrou.net> added the comment:

> I run the pyperformance test suite with PGO + LTO + full cpu isolation in the speed.python.org machine and these were the results:

Be mindful that synthetic benchmarks are probably a gentle case for branch prediction.  Real-world performance on irregular workloads might be worse still (or perhaps better, who knows :-)).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40255>
_______________________________________

From report at bugs.python.org  Tue Apr 14 10:24:49 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Tue, 14 Apr 2020 14:24:49 +0000
Subject: [issue40281] Add pathlib.PurePath.as_uri()
In-Reply-To: <1586869981.39.0.314985055066.issue40281@roundup.psfhosted.org>
Message-ID: <1586874289.1.0.509110336537.issue40281@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

+1 to add this :)

----------
nosy: +corona10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40281>
_______________________________________

From report at bugs.python.org  Tue Apr 14 10:25:48 2020
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 14 Apr 2020 14:25:48 +0000
Subject: [issue40255] Fixing Copy on Writes from reference counting
In-Reply-To: <1586619621.82.0.553262088399.issue40255@roundup.psfhosted.org>
Message-ID: <1586874348.49.0.41422122025.issue40255@roundup.psfhosted.org>


Antoine Pitrou <solipsis at pitrou.net> added the comment:

As a separate discussion, I would be interested to know whether the original use case (Eddie's) could be satisfied differently.  It probably doesn't belong to this issue, though.

(Eddie, if you want to discuss this, feel free to e-mail me privately. I think Davin Potts - co-maintainer of multiprocessing who recently added some facilities around shared memory - might be interested as well.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40255>
_______________________________________

From report at bugs.python.org  Tue Apr 14 10:58:40 2020
From: report at bugs.python.org (Andy Lester)
Date: Tue, 14 Apr 2020 14:58:40 +0000
Subject: [issue39943] Meta: Clean up various issues in C internals
In-Reply-To: <1583983387.49.0.277830283994.issue39943@roundup.psfhosted.org>
Message-ID: <1586876320.99.0.771485470034.issue39943@roundup.psfhosted.org>


Andy Lester <andy at petdance.com> added the comment:

I remember coming across a similar error from GCC about casting from a const double pointer to a single pointer void and it said (I believe) something about having to have each cast having to be valid.  I think it was implying something like that if you have 

const void **p

you have to cast that as

(void *)(const void *)p

I will see if I can find that message and/or I can find out more about this cast problem in the Windows compiler.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39943>
_______________________________________

From report at bugs.python.org  Tue Apr 14 11:26:45 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Tue, 14 Apr 2020 15:26:45 +0000
Subject: [issue40221] Use new _at_fork_reinit() lock method in multiprocessing
In-Reply-To: <1586300633.14.0.457029058496.issue40221@roundup.psfhosted.org>
Message-ID: <1586878005.71.0.705739699966.issue40221@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
pull_requests: +18864
pull_request: https://github.com/python/cpython/pull/19511

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40221>
_______________________________________

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: [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 11:33:46 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 14 Apr 2020 15:33:46 +0000
Subject: [issue40282] random.getrandbits(0) should succeed
In-Reply-To: <1586878355.33.0.583777817655.issue40282@roundup.psfhosted.org>
Message-ID: <1586878426.86.0.380231032173.issue40282@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

How random would be the 0 returned by getrandbits(0)? :-)

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40282>
_______________________________________

From report at bugs.python.org  Tue Apr 14 11:37:45 2020
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 14 Apr 2020 15:37:45 +0000
Subject: [issue40282] random.getrandbits(0) should succeed
In-Reply-To: <1586878355.33.0.583777817655.issue40282@roundup.psfhosted.org>
Message-ID: <1586878665.92.0.657549193573.issue40282@roundup.psfhosted.org>


Antoine Pitrou <solipsis at pitrou.net> added the comment:

I think you know the answer to your question ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40282>
_______________________________________

From report at bugs.python.org  Tue Apr 14 11:52:19 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 14 Apr 2020 15:52:19 +0000
Subject: [issue40268] Reorganize pycore_pystate.h header
In-Reply-To: <1586732467.85.0.974458317268.issue40268@roundup.psfhosted.org>
Message-ID: <1586879539.69.0.0679959088307.issue40268@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset e5014be0497d06d78343623588a80f491a6f7b74 by Victor Stinner in branch 'master':
bpo-40268: Remove a few pycore_pystate.h includes (GH-19510)
https://github.com/python/cpython/commit/e5014be0497d06d78343623588a80f491a6f7b74


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40268>
_______________________________________

From report at bugs.python.org  Tue Apr 14 11:54:58 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Tue, 14 Apr 2020 15:54:58 +0000
Subject: [issue39522] AST Unparser with unicode kinded constants
In-Reply-To: <1580600159.52.0.798208361602.issue39522@roundup.psfhosted.org>
Message-ID: <1586879698.28.0.0464370269967.issue39522@roundup.psfhosted.org>


Change by Batuhan Taskaya <batuhanosmantaskaya at gmail.com>:


----------
keywords: +patch
pull_requests: +18865
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19512

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39522>
_______________________________________

From report at bugs.python.org  Tue Apr 14 11:56:54 2020
From: report at bugs.python.org (Zackery Spytz)
Date: Tue, 14 Apr 2020 15:56:54 +0000
Subject: [issue40273] mappingproxy isn't reversible
In-Reply-To: <1586786082.33.0.84219610791.issue40273@roundup.psfhosted.org>
Message-ID: <1586879814.32.0.254604559567.issue40273@roundup.psfhosted.org>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
keywords: +patch
nosy: +ZackerySpytz
nosy_count: 2.0 -> 3.0
pull_requests: +18866
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19513

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40273>
_______________________________________

From report at bugs.python.org  Tue Apr 14 12:00:16 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 14 Apr 2020 16:00:16 +0000
Subject: [issue40268] Reorganize pycore_pystate.h header
In-Reply-To: <1586732467.85.0.974458317268.issue40268@roundup.psfhosted.org>
Message-ID: <1586880016.91.0.984723197244.issue40268@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +18867
pull_request: https://github.com/python/cpython/pull/19515

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40268>
_______________________________________

From report at bugs.python.org  Tue Apr 14 12:16:27 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Tue, 14 Apr 2020 16:16:27 +0000
Subject: [issue40232] PyOS_AfterFork_Child() should use
 _PyThread_at_fork_reinit()
In-Reply-To: <1586382203.52.0.537965691861.issue40232@roundup.psfhosted.org>
Message-ID: <1586880987.6.0.940722550539.issue40232@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:


New changeset 62f75fe3dd138f72303814d27183aa469eefcca6 by Dong-hee Na in branch 'master':
bpo-40232: Update PyOS_AfterFork_Child() to use _PyThread_at_fork_reinit() (GH-19450)
https://github.com/python/cpython/commit/62f75fe3dd138f72303814d27183aa469eefcca6


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40232>
_______________________________________

From report at bugs.python.org  Tue Apr 14 12:18:12 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Tue, 14 Apr 2020 16:18:12 +0000
Subject: [issue40232] PyOS_AfterFork_Child() should use
 _PyThread_at_fork_reinit()
In-Reply-To: <1586382203.52.0.537965691861.issue40232@roundup.psfhosted.org>
Message-ID: <1586881092.21.0.119365941103.issue40232@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

This issue is now solved.

Thanks, Victor for the suggestion! :)

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40232>
_______________________________________

From report at bugs.python.org  Tue Apr 14 12:30:44 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 14 Apr 2020 16:30:44 +0000
Subject: [issue40268] Reorganize pycore_pystate.h header
In-Reply-To: <1586732467.85.0.974458317268.issue40268@roundup.psfhosted.org>
Message-ID: <1586881844.74.0.158139335247.issue40268@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset e560f90602870601945ea7a4f7770827608817d2 by Victor Stinner in branch 'master':
bpo-40268: Move struct _gc_runtime_state to pycore_gc.h (GH-19515)
https://github.com/python/cpython/commit/e560f90602870601945ea7a4f7770827608817d2


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40268>
_______________________________________

From report at bugs.python.org  Tue Apr 14 12:35:43 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Tue, 14 Apr 2020 16:35:43 +0000
Subject: [issue40221] Use new _at_fork_reinit() lock method in multiprocessing
In-Reply-To: <1586300633.14.0.457029058496.issue40221@roundup.psfhosted.org>
Message-ID: <1586882143.74.0.624772202378.issue40221@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:


New changeset a5900ecf9f22e65bef489633692e9ea6941379c5 by Dong-hee Na in branch 'master':
bpo-40221: Update multiprocessing to use _at_fork_reinit (GH-19511)
https://github.com/python/cpython/commit/a5900ecf9f22e65bef489633692e9ea6941379c5


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40221>
_______________________________________

From report at bugs.python.org  Tue Apr 14 12:38:40 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Tue, 14 Apr 2020 16:38:40 +0000
Subject: [issue40221] Use new _at_fork_reinit() lock method in multiprocessing
In-Reply-To: <1586300633.14.0.457029058496.issue40221@roundup.psfhosted.org>
Message-ID: <1586882320.36.0.292053820077.issue40221@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

Looks like we update all the methods which are related to _after_fork
under Lib/multiprocessing.

I am now closing this issue.
Thanks for the suggestion, Victor :)

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40221>
_______________________________________

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: [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 13:02:27 2020
From: report at bugs.python.org (Carl Meyer)
Date: Tue, 14 Apr 2020 17:02:27 +0000
Subject: [issue40255] Fixing Copy on Writes from reference counting
In-Reply-To: <1586619621.82.0.553262088399.issue40255@roundup.psfhosted.org>
Message-ID: <1586883747.66.0.675671809261.issue40255@roundup.psfhosted.org>


Carl Meyer <carl at oddbird.net> added the comment:

> Anything that is touched by the immortal object will be leaked. This can also happen in obscure ways if reference cycles are created.

I think this is simply expected behavior if you choose to create immortal objects, and not really an issue. How could you have an immortal object that doesn't keep its strong references alive?

> this does not fully cover all cases as objects that become tracked by the GC after they are modified (for instance, dicts and tuples that only contain immutable objects). Those objects will still participate in reference counting after they start to be tracked.

I think the last sentence here is not quite right. An immortalized object will never start participating in reference counting again after it is immortalized.

There are two cases. If at the time of calling `immortalize_heap()` you have a non-GC-tracked object that is also not reachable from any GC-tracked container, then it will not be immortalized at all, so will be unaffected. This is a side effect of the PR using the GC to find objects to immortalize.

If the non-GC-tracked object is reachable from a GC-tracked object (I believe this is by far the more common case), then it will be immortalized. If it later becomes GC-tracked, it will start participating in GC (but the immortal bit causes it to appear to the GC to have a very high reference count, so GC will never collect it or any cycle it is part of), but that will not cause it to start participating in reference counting again.

> if immortal objects are handed to extension modules compiled with the other version of the macros, the reference count can be corrupted

I think the word "corrupted" makes this sound worse than it is in practice. What happens is just that the object is still effectively immortal (because the immortal bit is a very high bit), but the copy-on-write benefit is lost for the objects touched by old extensions.

> 1.17x slower on logging_silent or unpickle_pure_python is a very expensive price

Agreed. It seems the only way this makes sense is under an ifdef and off by default. CPython does a lot of that for debug features; this might be the first case of doing it for a performance feature?

> I would be more interested by an experiment to move ob_refcnt outside PyObject to solve the Copy-on-Write issue

It would certainly be interesting to see results of such an experiment. We haven't tried that for refcounts, but in the work that led to `gc.freeze()` we did try relocating the GC header to a side location. We abandoned that because the memory overhead of adding a single indirection pointer to every PyObject was too large to even consider the option further. I suspect that this memory overhead issue and/or likely cache locality problems will make moving refcounts outside PyObject look much worse for performance than this immortal-instances patch does.

----------
nosy: +carljm

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40255>
_______________________________________

From report at bugs.python.org  Tue Apr 14 13:12:21 2020
From: report at bugs.python.org (Carl Meyer)
Date: Tue, 14 Apr 2020 17:12:21 +0000
Subject: [issue40255] Fixing Copy on Writes from reference counting
In-Reply-To: <1586619621.82.0.553262088399.issue40255@roundup.psfhosted.org>
Message-ID: <1586884341.11.0.844362428784.issue40255@roundup.psfhosted.org>


Carl Meyer <carl at oddbird.net> added the comment:

> An immortalized object will never start participating in reference counting again after it is immortalized.

Well, "passed to an extension compiled with no-immortal headers" is an exception to this.

But for the "not GC tracked but later becomes GC tracked" case, it will not re-enter reference counting, only the GC.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40255>
_______________________________________

From report at bugs.python.org  Tue Apr 14 13:26:59 2020
From: report at bugs.python.org (Carl Meyer)
Date: Tue, 14 Apr 2020 17:26:59 +0000
Subject: [issue40255] Fixing Copy on Writes from reference counting
In-Reply-To: <1586619621.82.0.553262088399.issue40255@roundup.psfhosted.org>
Message-ID: <1586885219.9.0.622754372383.issue40255@roundup.psfhosted.org>


Carl Meyer <carl at oddbird.net> added the comment:

> This may break the garbage collector algorithm that relies on the balance between strong references between objects and its reference count to do the calculation of the isolated cycles.

I don't think it really breaks anything. What happens is that the immortal object appears to the GC to have a very large reference count, even after adjusting for within-cycle references. So cycles including an immortal object are always kept alive, which is exactly the behavior one should expect from an immortal object.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40255>
_______________________________________

From report at bugs.python.org  Tue Apr 14 13:28:09 2020
From: report at bugs.python.org (Michael Felt)
Date: Tue, 14 Apr 2020 17:28:09 +0000
Subject: [issue40244] AIX: build: _PyObject_GC_TRACK Asstertion failure
In-Reply-To: <1586868861.11.0.58963123772.issue40244@roundup.psfhosted.org>
Message-ID: <1d90b0c7-95f9-7c31-7bf7-c159e7e1ff29@felt.demon.nl>


Michael Felt <aixtools at felt.demon.nl> added the comment:

On 14/04/2020 14:54, Batuhan Taskaya wrote:
> Batuhan Taskaya <batuhanosmantaskaya at gmail.com> added the comment:
>
>> With the print statements - it does not crash:
> I think this isn't directly relevant with prints but about re-compiling? (just guessing).

I only recompiled the one .c file. With that one file re-compiled -
wqith fprintf statements it succeeds, restore the original .c file (git
checkout -- Objects/whatever.c; make - it fails.

Tomorrow I'll search for the option(s) needed to get (complete) assembly
code listing and try to see (and understand) the difference between what
xlc-v13 and xlc-v16 makes. And, what I shall also test - is to recompile
only this one file using xlc-v13 and see if the make then proceeds normally.

>  Because I experienced when I compile python for the first time on a clean AIX environment, all extension modules failed to build.

I only see this happen (on occasion) when I use make -j4 (or greater) -
and I have seen it happen to a lessor extent with -j2. On the subsequent
passes, whatever it is that setup.py (guessing) really needs is now
available - and the modules build as expected.

This is also why, for the last 4 years I have used my own personal
server - where I control everything (mainly NO other party OSS packaged
software and their artifacts).

>  When I recompiled (with keeping all artifacts from previous build) some of them successfully got compiled. When I try to compile again, most of them successfully compiled. I'm sorry but I don't know why this happens or how to solve it.
why - I do not understand the finer details either, but my guess is that
it is related to linking. I am nearly "amazed" - yet happy - that the
PPC64 AIX 3.X compile succeeds - but acknowledge the 22K+ lines of
warnings is related to the over parallelization of the linking.
> We can always revert that change but I guess that isn't the real problem.

No. I do not think it is the real problem either. And I do not know
compiler behavior well enough. Actually, considering the setting is
still -O0 (aka no optimization) I am surprised it has any effect. if I
understood correctly "no return" is intended to help the optimizer make
"informed" decisions.

As Victor commented earlier - very much looking like a compiler bug.
That said, still do not know what to say/write to software support as a
complaint.

>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue40244>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40244>
_______________________________________

From report at bugs.python.org  Tue Apr 14 13:30:24 2020
From: report at bugs.python.org (Dino Viehland)
Date: Tue, 14 Apr 2020 17:30:24 +0000
Subject: [issue40255] Fixing Copy on Writes from reference counting
In-Reply-To: <1586619621.82.0.553262088399.issue40255@roundup.psfhosted.org>
Message-ID: <1586885424.35.0.544660929715.issue40255@roundup.psfhosted.org>


Dino Viehland <dinoviehland at gmail.com> added the comment:

I think there's other cases of performance related features being hidden under an ifdef.  Computed gotos show up that way, although probably more because it's a compiler extension that's not supported everywhere.  Pymalloc is also very similar in that it implies an ABI change as well.

I wonder if it would be worth it to introduce an ABI flag for this as well?  On the one hand is it a slightly different contract, on the other hand using extensions that don't support the immortalization actually work just fine.

----------
nosy: +dino.viehland

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40255>
_______________________________________

From report at bugs.python.org  Tue Apr 14 13:42:58 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 14 Apr 2020 17:42:58 +0000
Subject: [issue40255] Fixing Copy on Writes from reference counting
In-Reply-To: <1586619621.82.0.553262088399.issue40255@roundup.psfhosted.org>
Message-ID: <1586886178.16.0.276077685013.issue40255@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

> I think this is simply expected behavior if you choose to create immortal objects, and not really an issue. How could you have an immortal object that doesn't keep its strong references alive?

I think I didn't express myself very well: I am saying that I perceive this as a problem because when you immortalize the heap at a given time you will also immortalize any strong reference that these objects made afterwards. The immortal property will be "infecting" other objects as strong references are created.

> I think the last sentence here is not quite right. An immortalized object will never start participating in reference counting again after it is immortalized.

Yeah, but the objects I mention will not be immortalized. These are objects that were not tracked when the immortalization is done and are not reachable from tracked objects at the moment and become tracked afterwards (for instance, some dictionary that only had immutable objects when the immortalization was done). And this is always very impacting: a single object that participates in refcounting will copy an entire page of memory. Although I agree this is a rare thing is a possible thing that can happen.

> I think the word "corrupted" makes this sound worse than it is in practice. What happens is just that the object is still effectively immortal (because the immortal bit is a very high bit), but the copy-on-write benefit is lost for the objects touched by old extensions.

Yeah, I agree that corrupted may sound a bit more dramatic than it should but I think this is still a problem because when it happens (as mentioned before) it affects entire pages and not the single object that we consider.

> But for the "not GC tracked but later becomes GC tracked" case, it will not re-enter reference counting, only the GC.

But if said objects (isolated and untracked before and now tracked) acquire strong references to immortal objects, those objects will be visited when the gc starts calculating the isolated cycles and that requires a balanced reference count to work.

----------
nosy:  -dino.viehland

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40255>
_______________________________________

From report at bugs.python.org  Tue Apr 14 13:50:14 2020
From: report at bugs.python.org (Steve Dower)
Date: Tue, 14 Apr 2020 17:50:14 +0000
Subject: [issue40255] Fixing Copy on Writes from reference counting
In-Reply-To: <1586619621.82.0.553262088399.issue40255@roundup.psfhosted.org>
Message-ID: <1586886614.82.0.189451697305.issue40255@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

There hasn't been much said about which kind of objects would be immortal. Could this be a creation-time option? Or a type object (similar to a no-op tp_dealloc)?

If it's something that is known when the object is created, then some of the "infection" concern can be reduced - but if you wanted to arbitrarily make arbitrary objects immortal dynamically then it's a different matter.

Another benefit of knowing at creation time is that immortal objects could be allocated to a different page (or potentially even to read-only shared memory, if that was appropriate).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40255>
_______________________________________

From report at bugs.python.org  Tue Apr 14 13:50:27 2020
From: report at bugs.python.org (Steve Dower)
Date: Tue, 14 Apr 2020 17:50:27 +0000
Subject: [issue40255] Fixing Copy on Writes from reference counting
In-Reply-To: <1586619621.82.0.553262088399.issue40255@roundup.psfhosted.org>
Message-ID: <1586886627.54.0.784690521883.issue40255@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
nosy: +dino.viehland

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40255>
_______________________________________

From report at bugs.python.org  Tue Apr 14 13:51:25 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 14 Apr 2020 17:51:25 +0000
Subject: [issue37531] Fix regrtest timeout for subprocesses: regrtest -jN
 --timeout=SECONDS
In-Reply-To: <1562700862.92.0.104600612678.issue37531@roundup.psfhosted.org>
Message-ID: <1586886685.79.0.359350231703.issue37531@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 67b8a1f0f0f78ec38b8626fa9f5b2f5a55c17e15 by Victor Stinner in branch '3.8':
[3.8] Update libregrtest from master (GH-19516)
https://github.com/python/cpython/commit/67b8a1f0f0f78ec38b8626fa9f5b2f5a55c17e15


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37531>
_______________________________________

From report at bugs.python.org  Tue Apr 14 13:51:25 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 14 Apr 2020 17:51:25 +0000
Subject: [issue38502] regrtest: use process groups
In-Reply-To: <1571266006.89.0.625453271604.issue38502@roundup.psfhosted.org>
Message-ID: <1586886685.66.0.734871646997.issue38502@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 67b8a1f0f0f78ec38b8626fa9f5b2f5a55c17e15 by Victor Stinner in branch '3.8':
[3.8] Update libregrtest from master (GH-19516)
https://github.com/python/cpython/commit/67b8a1f0f0f78ec38b8626fa9f5b2f5a55c17e15


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38502>
_______________________________________

From report at bugs.python.org  Tue Apr 14 13:51:25 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 14 Apr 2020 17:51:25 +0000
Subject: [issue37957] Allow regrtest to receive a file with test (and
 subtests) to ignore
In-Reply-To: <1566864234.54.0.166621143796.issue37957@roundup.psfhosted.org>
Message-ID: <1586886685.92.0.365858216538.issue37957@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 67b8a1f0f0f78ec38b8626fa9f5b2f5a55c17e15 by Victor Stinner in branch '3.8':
[3.8] Update libregrtest from master (GH-19516)
https://github.com/python/cpython/commit/67b8a1f0f0f78ec38b8626fa9f5b2f5a55c17e15


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37957>
_______________________________________

From report at bugs.python.org  Tue Apr 14 13:51:32 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 14 Apr 2020 17:51:32 +0000
Subject: [issue40255] Fixing Copy on Writes from reference counting
In-Reply-To: <1586619621.82.0.553262088399.issue40255@roundup.psfhosted.org>
Message-ID: <1586886692.87.0.761780387951.issue40255@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

> There hasn't been much said about which kind of objects would be immortal.

The current patch makes *all objects that are tracked by the gc* immortal, independently of their type (unless I am missing something).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40255>
_______________________________________

From report at bugs.python.org  Tue Apr 14 13:52:37 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 14 Apr 2020 17:52:37 +0000
Subject: [issue40255] Fixing Copy on Writes from reference counting
In-Reply-To: <1586619621.82.0.553262088399.issue40255@roundup.psfhosted.org>
Message-ID: <1586886757.73.0.603186731628.issue40255@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

> all objects that are tracked by the gc

also, all the objects that are reachable from objects tracked by the gc.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40255>
_______________________________________

From report at bugs.python.org  Tue Apr 14 13:57:30 2020
From: report at bugs.python.org (Barry Alan Scott)
Date: Tue, 14 Apr 2020 17:57:30 +0000
Subject: [issue40260] modulefinder traceback regression starting on Windows
In-Reply-To: <1586680620.99.0.514402715757.issue40260@roundup.psfhosted.org>
Message-ID: <1586887050.27.0.00639951290834.issue40260@roundup.psfhosted.org>


Barry Alan Scott <barry-scott at users.sourceforge.net> added the comment:

io.open_code() used in the patch.

----------
components:  -Windows

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40260>
_______________________________________

From report at bugs.python.org  Tue Apr 14 13:59:22 2020
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 14 Apr 2020 17:59:22 +0000
Subject: [issue36780] Interpreter exit blocks waiting for futures of shut-down
 ThreadPoolExecutors
In-Reply-To: <1556875683.94.0.285155490659.issue36780@roundup.psfhosted.org>
Message-ID: <1586887162.9.0.385074604897.issue36780@roundup.psfhosted.org>


Change by Antoine Pitrou <solipsis at pitrou.net>:


----------
nosy: +aeros

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36780>
_______________________________________

From report at bugs.python.org  Tue Apr 14 14:02:43 2020
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 14 Apr 2020 18:02:43 +0000
Subject: [issue36780] Interpreter exit blocks waiting for futures of shut-down
 ThreadPoolExecutors
In-Reply-To: <1556875683.94.0.285155490659.issue36780@roundup.psfhosted.org>
Message-ID: <1586887363.84.0.219513408233.issue36780@roundup.psfhosted.org>


Antoine Pitrou <solipsis at pitrou.net> added the comment:

I don't think there's much ThreadPoolExecutor can do.  If you drop the references to the threads, they still exist and they still be waited upon at interpreter exit.

The solution is for you to avoid having hanging threads.  In the particular case of TCP connections, I'd recommend using a dedicated framework such as asyncio (or Twisted, Tornado, etc.) instead of home-baked networking code.

Also, note that Python sockets have a feature called *timeouts*.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36780>
_______________________________________

From report at bugs.python.org  Tue Apr 14 14:09:20 2020
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 14 Apr 2020 18:09:20 +0000
Subject: [issue40255] Fixing Copy on Writes from reference counting
In-Reply-To: <1586619621.82.0.553262088399.issue40255@roundup.psfhosted.org>
Message-ID: <1586887760.9.0.918662506638.issue40255@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:

Marking everything as immortal/eternal after you've loaded your common code & data but before you do your forking is thenorm for this kind of serving system.

You already presumably have a defined lifetime for the processes so they'll likely be set to die within N hours or days.  Memory leaks of too many things persisting is a non-issue in this kind of system.

The alternative of trying to pick and choose exactly what (and anything they reference) sticks around is a maintenance nightmare exercise in futility.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40255>
_______________________________________

From report at bugs.python.org  Tue Apr 14 14:11:24 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 14 Apr 2020 18:11:24 +0000
Subject: [issue40170] [C API] Make PyTypeObject structure an opaque structure
 in the public C API
In-Reply-To: <1585915023.07.0.846808236133.issue40170@roundup.psfhosted.org>
Message-ID: <1586887884.08.0.771196961896.issue40170@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 675d9a3d7afc767a2818c84da7ba4bf4181dcf26 by Hai Shi in branch 'master':
bpo-40170: Convert PyObject_IS_GC() macro to a function (GH-19464)
https://github.com/python/cpython/commit/675d9a3d7afc767a2818c84da7ba4bf4181dcf26


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40170>
_______________________________________

From report at bugs.python.org  Tue Apr 14 14:11:50 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 14 Apr 2020 18:11:50 +0000
Subject: [issue32033] The pwd module implementation incorrectly sets some
 attributes to None
In-Reply-To: <1510742059.52.0.213398074469.issue32033@psf.upfronthosting.co.za>
Message-ID: <1586887910.26.0.578706442133.issue32033@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 96515e9f6785328c52ebc5d4ce60e0087a9adc2d by Zackery Spytz in branch 'master':
bpo-32033: Fix test_pwd failures on Android (GH-19502)
https://github.com/python/cpython/commit/96515e9f6785328c52ebc5d4ce60e0087a9adc2d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32033>
_______________________________________

From report at bugs.python.org  Tue Apr 14 14:13:00 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 14 Apr 2020 18:13:00 +0000
Subject: [issue32033] The pwd module implementation incorrectly sets some
 attributes to None
In-Reply-To: <1510742059.52.0.213398074469.issue32033@psf.upfronthosting.co.za>
Message-ID: <1586887980.7.0.487069185506.issue32033@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
nosy: +miss-islington
nosy_count: 4.0 -> 5.0
pull_requests: +18868
pull_request: https://github.com/python/cpython/pull/19518

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32033>
_______________________________________

From report at bugs.python.org  Tue Apr 14 14:15:17 2020
From: report at bugs.python.org (=?utf-8?b?SHJ2b2plIE5pa8WhacSH?=)
Date: Tue, 14 Apr 2020 18:15:17 +0000
Subject: [issue36780] Interpreter exit blocks waiting for futures of shut-down
 ThreadPoolExecutors
In-Reply-To: <1556875683.94.0.285155490659.issue36780@roundup.psfhosted.org>
Message-ID: <1586888117.89.0.410281378481.issue36780@roundup.psfhosted.org>


Hrvoje Nik?i? <hniksic at gmail.com> added the comment:

> I don't think there's much ThreadPoolExecutor can do.  If you drop the references to the threads, they still exist and they still be waited upon at interpreter exit.

ThreadPoolExecutor introduces additional waiting of its own, and it is this wait the PR adds an option to disable.

> The solution is for you to avoid having hanging threads.

In some cases that is not possible. For example, the file IO on network file systems can take an arbitrary amount of time, and there is no way to implement a timeout. DNS lookups have been notorious for not supporting timeouts. Many third-party libraries, such as database drivers, still don't support timeouts.

This is a real issue that bit many users in production systems, it's not about a toy program using "home-baked networking code".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36780>
_______________________________________

From report at bugs.python.org  Tue Apr 14 14:16:14 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 14 Apr 2020 18:16:14 +0000
Subject: [issue32033] The pwd module implementation incorrectly sets some
 attributes to None
In-Reply-To: <1510742059.52.0.213398074469.issue32033@psf.upfronthosting.co.za>
Message-ID: <1586888174.37.0.224919567408.issue32033@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +18869
pull_request: https://github.com/python/cpython/pull/19519

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32033>
_______________________________________

From report at bugs.python.org  Tue Apr 14 14:16:47 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 14 Apr 2020 18:16:47 +0000
Subject: [issue32033] The pwd module implementation incorrectly sets some
 attributes to None
In-Reply-To: <1510742059.52.0.213398074469.issue32033@psf.upfronthosting.co.za>
Message-ID: <1586888207.73.0.805808560163.issue32033@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

It's now fixed in master and backports to 3.7 and 3.8 will be merged as soon as the CI pass.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32033>
_______________________________________

From report at bugs.python.org  Tue Apr 14 14:19:20 2020
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 14 Apr 2020 18:19:20 +0000
Subject: [issue36780] Interpreter exit blocks waiting for futures of shut-down
 ThreadPoolExecutors
In-Reply-To: <1556875683.94.0.285155490659.issue36780@roundup.psfhosted.org>
Message-ID: <1586888360.48.0.14622068716.issue36780@roundup.psfhosted.org>


Antoine Pitrou <solipsis at pitrou.net> added the comment:

I think there's a misunderstanding: "wait_at_exit" will make the *executor* forget about the threads, but Python itself still knows about them, and it waits for them to end at interpreter shutdown.

These threads were daemon threads in 3.8, so your patch indeed works there, but we've made them non-daemon in 3.9, for two reasons:
1) daemon threads are fragile and can crash the interpreter at shutdown
2) they are not supported on subinterpreters

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36780>
_______________________________________

From report at bugs.python.org  Tue Apr 14 14:26:11 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 14 Apr 2020 18:26:11 +0000
Subject: [issue40255] Fixing Copy on Writes from reference counting
In-Reply-To: <1586619621.82.0.553262088399.issue40255@roundup.psfhosted.org>
Message-ID: <1586888771.65.0.920131598667.issue40255@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

> But if said objects (isolated and untracked before and now tracked) acquire strong references to immortal objects, those objects will be visited when the gc starts calculating the isolated cycles and that requires a balanced reference count to work.

I was thinking about this a bit more and because the refcount bit is too high, the GC algorithm will be "fine" in the sense that won't break. It will just treat immortal objects as referenced from outside any cycle isolate (because the refcount hopefully will never reach 0), which is consistent with the fact that they are in the permanent generation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40255>
_______________________________________

From report at bugs.python.org  Tue Apr 14 14:30:02 2020
From: report at bugs.python.org (Carl Meyer)
Date: Tue, 14 Apr 2020 18:30:02 +0000
Subject: [issue40255] Fixing Copy on Writes from reference counting
In-Reply-To: <1586619621.82.0.553262088399.issue40255@roundup.psfhosted.org>
Message-ID: <1586889002.06.0.0553411933837.issue40255@roundup.psfhosted.org>


Carl Meyer <carl at oddbird.net> added the comment:

I think the concerns about "perfect" behavior in corner cases are in general irrelevant here.

In the scenarios where this optimization matters, there is no quantitative change that occurs at 100% coverage. Preventing 99% of CoW is 99% as good as preventing 100% :) So the fact that a few objects here and there in special cases could still trigger CoW just doesn't matter; it's still a massive improvement over the status quo. (That said, I wouldn't _mind_ improving the coverage, e.g. if you can suggest a better way to find all heap objects instead of using the GC.)

And similarly, gps is right that the concern that immortal objects can keep other objects alive (even via references added after immortalization) is a non-issue in practice. There really is no other behavior one could prefer or expect instead.

> if said objects (isolated and untracked before and now tracked) acquire strong references to immortal objects, those objects will be visited when the gc starts calculating the isolated cycles and that requires a balanced reference count to work.

I'm not sure what you mean here by "balanced ref count" or by "work" :) What will happen anytime an immortal object gets into the GC, for any reason, is that the GC will "subtract" cyclic references and see that the immortal object still has a large refcount even after that adjustment, and so it will keep the immortal object and any cycle it is part of alive. This behavior is correct and should be fully expected; nothing breaks. It doesn't matter at all to the GC that this large refcount is "fictional," and it doesn't break the GC algorithm, it results only in the desired behavior of maintaining immortality of immortal objects.

It is perhaps slightly weird that this behavior falls out of the immortal bit being a high bit rather than being more explicit. I did do some experimentation with trying to explicitly prevent immortal instances from ever entering GC, but it turned out to be hard to do that in an efficient way. And motivation to do it is low, because there's nothing wrong with the behavior in the existing PR.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40255>
_______________________________________

From report at bugs.python.org  Tue Apr 14 14:30:12 2020
From: report at bugs.python.org (=?utf-8?b?SHJ2b2plIE5pa8WhacSH?=)
Date: Tue, 14 Apr 2020 18:30:12 +0000
Subject: [issue36780] Interpreter exit blocks waiting for futures of shut-down
 ThreadPoolExecutors
In-Reply-To: <1556875683.94.0.285155490659.issue36780@roundup.psfhosted.org>
Message-ID: <1586889012.61.0.174285933768.issue36780@roundup.psfhosted.org>


Hrvoje Nik?i? <hniksic at gmail.com> added the comment:

Thanks for the clarification, I didn't know about the change to non-daemon threads.

I still think this patch is useful, and won't harm general use because it is opt-in, just like daemon threads themselves. I suggest to update the PR to specify non-waiting pool at the point of creation rather than in shutdown(). (That will also make it more acceptable for the same option not being supported for process pools - it is ok for constructor signatures to differ.)

If there is interest, someone should take over the PR, as I have changed jobs and no longer have time to actively pursue this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36780>
_______________________________________

From report at bugs.python.org  Tue Apr 14 14:31:07 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 14 Apr 2020 18:31:07 +0000
Subject: [issue32033] The pwd module implementation incorrectly sets some
 attributes to None
In-Reply-To: <1510742059.52.0.213398074469.issue32033@psf.upfronthosting.co.za>
Message-ID: <1586889067.15.0.372645712077.issue32033@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 1e1dbdf23f7a18f53a3257badc3541973831f2c4 by Miss Islington (bot) in branch '3.8':
bpo-32033: Fix test_pwd failures on Android (GH-19502)
https://github.com/python/cpython/commit/1e1dbdf23f7a18f53a3257badc3541973831f2c4


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32033>
_______________________________________

From report at bugs.python.org  Tue Apr 14 14:31:42 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 14 Apr 2020 18:31:42 +0000
Subject: [issue32033] The pwd module implementation incorrectly sets some
 attributes to None
In-Reply-To: <1510742059.52.0.213398074469.issue32033@psf.upfronthosting.co.za>
Message-ID: <1586889102.06.0.156896744508.issue32033@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 8821200d85657ef3bbec78dcb43694449c05e896 by Miss Islington (bot) in branch '3.7':
bpo-32033: Fix test_pwd failures on Android (GH-19502)
https://github.com/python/cpython/commit/8821200d85657ef3bbec78dcb43694449c05e896


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32033>
_______________________________________

From report at bugs.python.org  Tue Apr 14 14:34:38 2020
From: report at bugs.python.org (Steve Dower)
Date: Tue, 14 Apr 2020 18:34:38 +0000
Subject: [issue40260] modulefinder traceback regression starting on Windows
In-Reply-To: <1586680620.99.0.514402715757.issue40260@roundup.psfhosted.org>
Message-ID: <1586889278.43.0.548289450763.issue40260@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Thanks, Barry!

I tweaked your NEWS entry a little, so once CI completes I'll merge and backport.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40260>
_______________________________________

From report at bugs.python.org  Tue Apr 14 14:37:13 2020
From: report at bugs.python.org (=?utf-8?q?Miro_Hron=C4=8Dok?=)
Date: Tue, 14 Apr 2020 18:37:13 +0000
Subject: [issue9216] FIPS support for hashlib
In-Reply-To: <1278721335.16.0.522410247151.issue9216@psf.upfronthosting.co.za>
Message-ID: <1586889433.47.0.459868967303.issue9216@roundup.psfhosted.org>


Change by Miro Hron?ok <miro at hroncok.cz>:


----------
nosy: +hroncok
nosy_count: 17.0 -> 18.0
pull_requests: +18870
pull_request: https://github.com/python/cpython/pull/19520

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue9216>
_______________________________________

From report at bugs.python.org  Tue Apr 14 14:39:14 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 14 Apr 2020 18:39:14 +0000
Subject: [issue40255] Fixing Copy on Writes from reference counting
In-Reply-To: <1586619621.82.0.553262088399.issue40255@roundup.psfhosted.org>
Message-ID: <1586889554.46.0.45690575916.issue40255@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

> I'm not sure what you mean here by "balanced ref count" or by "work" :) What will happen anytime an immortal object gets into the GC, for any reason, is that the GC will "subtract" cyclic references and see that the immortal object still has a large refcount even after that adjustment, and so it will keep the immortal object and any cycle it is part of alive. This behavior is correct and should be fully expected; nothing breaks. It doesn't matter at all to the GC that this large refcount is "fictional," and it doesn't break the GC algorithm, it results only in the desired behavior of maintaining immortality of immortal objects.


Yep, that is right. I think there was a race condition between my previous message and yours :)

I think what was confusing me in this line of reasoning is that I was not taking into account that the immortal bit is a very high one, making the refcount gigantic. I was treating it mentally like a flag without factoring the implications of such big reference count.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40255>
_______________________________________

From report at bugs.python.org  Tue Apr 14 14:43:49 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 14 Apr 2020 18:43:49 +0000
Subject: [issue40282] random.getrandbits(0) should succeed
In-Reply-To: <1586878355.33.0.583777817655.issue40282@roundup.psfhosted.org>
Message-ID: <1586889829.38.0.0913831821783.issue40282@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Seconded.

And I wish to add the getrandbytes() method.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40282>
_______________________________________

From report at bugs.python.org  Tue Apr 14 14:50:22 2020
From: report at bugs.python.org (Lysandros Nikolaou)
Date: Tue, 14 Apr 2020 18:50:22 +0000
Subject: [issue40267] Error message differs when an expression is in an fstring
In-Reply-To: <1586728764.59.0.587923723315.issue40267@roundup.psfhosted.org>
Message-ID: <1586890222.95.0.726281693637.issue40267@roundup.psfhosted.org>


Change by Lysandros Nikolaou <lisandrosnik at gmail.com>:


----------
keywords: +patch
pull_requests: +18871
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19521

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40267>
_______________________________________

From report at bugs.python.org  Tue Apr 14 14:52:43 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 14 Apr 2020 18:52:43 +0000
Subject: [issue40282] random.getrandbits(0) should succeed
In-Reply-To: <1586878355.33.0.583777817655.issue40282@roundup.psfhosted.org>
Message-ID: <1586890363.5.0.368662321611.issue40282@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

This was discussed previously in #37000.

I agree that `getrandbits(0)` should succeed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40282>
_______________________________________

From report at bugs.python.org  Tue Apr 14 15:01:29 2020
From: report at bugs.python.org (Kyle Stanley)
Date: Tue, 14 Apr 2020 19:01:29 +0000
Subject: [issue36780] Interpreter exit blocks waiting for futures of shut-down
 ThreadPoolExecutors
In-Reply-To: <1556875683.94.0.285155490659.issue36780@roundup.psfhosted.org>
Message-ID: <1586890889.06.0.210009862883.issue36780@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:

> I don't think there's much ThreadPoolExecutor can do.  If you drop the references to the threads, they still exist and they still be waited upon at interpreter exit.
> 
> The solution is for you to avoid having hanging threads.  In the particular case of TCP connections, I'd recommend using a dedicated framework such as asyncio (or Twisted, Tornado, etc.) instead of home-baked networking code.

As far as I'm aware, I don't think there's a _safe_ way to force a hanging thread to immediately exit without causing resource-related problems (an unsafe way would be something like releasing the internal thread state lock). But in general, I think that hanging threads indicate a fundamental issue in the implementation of the function the thread is targeting. For any operation that can potentially stall or run indefinitely, there should be some form of fail safe or timeout in place to break out of it. So I agree with Antoine that it's ultimately the responsibility of the thread itself to not hang. There's not much of anything that ThreadPoolExecutor can safely do to resolve a hanging thread.

> Also, note that Python sockets have a feature called *timeouts*.

There's also of course timeouts implemented at a higher level in many networking frameworks, if the developer doesn't want to do so at the socket level. For example, see asyncio.wait_for(): https://docs.python.org/3/library/asyncio-task.html#asyncio.wait_for.

> These threads were daemon threads in 3.8, so your patch indeed works there, but we've made them non-daemon in 3.9, for two reasons:
1) daemon threads are fragile and can crash the interpreter at shutdown
2) they are not supported on subinterpreters

Just to briefly clarify on (2), Victor recently opened a PR to revert daemon threads being entirely unsupported in subinterpreters: PR-19456. From reading over the attached bpo issue, it looks like the plan is to deprecate daemon threads in subinterpreters, but to not immediately drop support because users of mod_wsgi and various monitoring tools were reliant upon it (through the C-API).

It seems like the current plan is for it to undergo a deprecation process. Either way though, I still think the change to make executors no longer reliant upon daemon threads was a significant stability improvement and will mean we don't have to make the change later when they are fully unsupported in subinterpreters.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36780>
_______________________________________

From report at bugs.python.org  Tue Apr 14 15:16:19 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 14 Apr 2020 19:16:19 +0000
Subject: [issue40260] modulefinder traceback regression starting on Windows
In-Reply-To: <1586680620.99.0.514402715757.issue40260@roundup.psfhosted.org>
Message-ID: <1586891779.55.0.848536980431.issue40260@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
nosy: +miss-islington
nosy_count: 7.0 -> 8.0
pull_requests: +18872
pull_request: https://github.com/python/cpython/pull/19522

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40260>
_______________________________________

From report at bugs.python.org  Tue Apr 14 15:16:10 2020
From: report at bugs.python.org (Steve Dower)
Date: Tue, 14 Apr 2020 19:16:10 +0000
Subject: [issue40260] modulefinder traceback regression starting on Windows
In-Reply-To: <1586680620.99.0.514402715757.issue40260@roundup.psfhosted.org>
Message-ID: <1586891770.7.0.395925256761.issue40260@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:


New changeset d42e5820631cd66ee1eab8f610d4b58f3dfdd81c by Barry in branch 'master':
bpo-40260: Update modulefinder to use io.open_code() and respect coding comments (GH-19488)
https://github.com/python/cpython/commit/d42e5820631cd66ee1eab8f610d4b58f3dfdd81c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40260>
_______________________________________

From report at bugs.python.org  Tue Apr 14 15:23:26 2020
From: report at bugs.python.org (Steve Dower)
Date: Tue, 14 Apr 2020 19:23:26 +0000
Subject: [issue23082] pathlib relative_to() can give confusing error message
In-Reply-To: <1418909839.25.0.648032443428.issue23082@psf.upfronthosting.co.za>
Message-ID: <1586892206.88.0.822716007078.issue23082@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

I agree it's worth improving the error message (and probably the docs too).

It's never made clear that relative_to only looks deeper (won't ever generate leading ".." parts) - the closest hint in the docs is that os.path.relpath is different (and that isn't even in the relative_to() section).


Tagging this easy/newcomer friendly. If you'd like to work on it, just post here - I'm happy to help get it merged.

----------
keywords: +easy, newcomer friendly
nosy: +steve.dower
versions: +Python 3.8, Python 3.9 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23082>
_______________________________________

From report at bugs.python.org  Tue Apr 14 15:24:05 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Tue, 14 Apr 2020 19:24:05 +0000
Subject: [issue39522] AST Unparser with unicode kinded constants
In-Reply-To: <1580600159.52.0.798208361602.issue39522@roundup.psfhosted.org>
Message-ID: <1586892245.52.0.195015135411.issue39522@roundup.psfhosted.org>


Change by Batuhan Taskaya <batuhanosmantaskaya at gmail.com>:


----------
pull_requests: +18873
pull_request: https://github.com/python/cpython/pull/19523

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39522>
_______________________________________

From report at bugs.python.org  Tue Apr 14 15:34:51 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 14 Apr 2020 19:34:51 +0000
Subject: [issue40260] modulefinder traceback regression starting on Windows
In-Reply-To: <1586680620.99.0.514402715757.issue40260@roundup.psfhosted.org>
Message-ID: <1586892891.52.0.658545498894.issue40260@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 59047fab0ef37f583c9e7c3a48d67792fd10ff91 by Miss Islington (bot) in branch '3.8':
bpo-40260: Update modulefinder to use io.open_code() and respect coding comments (GH-19488)
https://github.com/python/cpython/commit/59047fab0ef37f583c9e7c3a48d67792fd10ff91


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40260>
_______________________________________

From report at bugs.python.org  Tue Apr 14 15:37:34 2020
From: report at bugs.python.org (Steve Dower)
Date: Tue, 14 Apr 2020 19:37:34 +0000
Subject: [issue40260] modulefinder traceback regression starting on Windows
In-Reply-To: <1586680620.99.0.514402715757.issue40260@roundup.psfhosted.org>
Message-ID: <1586893054.89.0.0562049704451.issue40260@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40260>
_______________________________________

From report at bugs.python.org  Tue Apr 14 15:39:37 2020
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 14 Apr 2020 19:39:37 +0000
Subject: [issue40249] __import__ doesn't honour globals
In-Reply-To: <1586558028.61.0.331520667517.issue40249@roundup.psfhosted.org>
Message-ID: <1586893177.46.0.935820629593.issue40249@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

How would you propose changing the wording found at https://docs.python.org/3/library/functions.html?highlight=__import__#__import__?

----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40249>
_______________________________________

From report at bugs.python.org  Tue Apr 14 15:49:14 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 14 Apr 2020 19:49:14 +0000
Subject: [issue9216] FIPS support for hashlib
In-Reply-To: <1278721335.16.0.522410247151.issue9216@psf.upfronthosting.co.za>
Message-ID: <1586893754.98.0.869049176432.issue9216@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 4c0a31fb08407ba043688ad1c21102dd4cb99146 by Miro Hron?ok in branch 'master':
bpo-9216: Nobody expects the geohashing FIPS inquisition (GH-19520)
https://github.com/python/cpython/commit/4c0a31fb08407ba043688ad1c21102dd4cb99146


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue9216>
_______________________________________

From report at bugs.python.org  Tue Apr 14 15:49:24 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 14 Apr 2020 19:49:24 +0000
Subject: [issue9216] FIPS support for hashlib
In-Reply-To: <1278721335.16.0.522410247151.issue9216@psf.upfronthosting.co.za>
Message-ID: <1586893764.6.0.211644267268.issue9216@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +18874
pull_request: https://github.com/python/cpython/pull/19524

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue9216>
_______________________________________

From report at bugs.python.org  Tue Apr 14 15:52:00 2020
From: report at bugs.python.org (Kyle Stanley)
Date: Tue, 14 Apr 2020 19:52:00 +0000
Subject: [issue36780] Interpreter exit blocks waiting for futures of shut-down
 ThreadPoolExecutors
In-Reply-To: <1556875683.94.0.285155490659.issue36780@roundup.psfhosted.org>
Message-ID: <1586893920.44.0.602208598895.issue36780@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:

> ThreadPoolExecutor introduces additional waiting of its own, and it is this wait the PR adds an option to disable.

[next post]

> Thanks for the clarification, I didn't know about the change to non-daemon threads.

> I still think this patch is useful, and won't harm general use because it is opt-in, just like daemon threads themselves. I suggest to update the PR to specify non-waiting pool at the point of creation rather than in shutdown(). (That will also make it more acceptable for the same option not being supported for process pools - it is ok for constructor signatures to differ.)

Yes, but if you simply make the ThreadPoolExecutor forget about the thread, then all that it does is divert the wait to occur at a later time. In this case, it would get stuck at `threading._shutdown()` (where all non-daemon threads are joined) instead of `executor.shutdown()` since they no longer use daemon threads.

The only way I could see this to work as intended without making any changes to threading would be to optionally use daemon threads and avoid joining the threads in `executor.shutdown()` if `wait_at_exit` is set to False in the constructor for the executor. But at the least, users would have to be made aware in the documentation that this could lead to significant resource finalization issues, and potential incompatibility with subinterpreters. 

Otherwise, they may end up accidentally shooting themselves in the foot (which we certainly want to avoid). I'm also somewhat concerned that it may end up getting used to cover up actual bugs. 

IMO, it also would require some fairly extensive testing to make sure it works as intended, which the patch currently lacks. So in order to implement this properly, it would require a significant amount of additional time investment beyond what has been put into the existing patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36780>
_______________________________________

From report at bugs.python.org  Tue Apr 14 15:53:52 2020
From: report at bugs.python.org (Stefan Seefeld)
Date: Tue, 14 Apr 2020 19:53:52 +0000
Subject: [issue40249] __import__ doesn't honour globals
In-Reply-To: <1586558028.61.0.331520667517.issue40249@roundup.psfhosted.org>
Message-ID: <1586894032.16.0.474201066275.issue40249@roundup.psfhosted.org>


Stefan Seefeld <stefan at seefeld.name> added the comment:

I'm not entirely sure, but have to admit that the sentence

"The function imports the module name, potentially using the given globals and locals to determine how to interpret the name in a package context."

is a bit obscure. What does "determine how to interpret the name" actually mean ? Is the algorithm described anywhere in detail ? In that case, a simple reference might be enough.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40249>
_______________________________________

From report at bugs.python.org  Tue Apr 14 16:01:55 2020
From: report at bugs.python.org (=?utf-8?b?SHJ2b2plIE5pa8WhacSH?=)
Date: Tue, 14 Apr 2020 20:01:55 +0000
Subject: [issue36780] Interpreter exit blocks waiting for futures of shut-down
 ThreadPoolExecutors
In-Reply-To: <1556875683.94.0.285155490659.issue36780@roundup.psfhosted.org>
Message-ID: <1586894515.54.0.829685448159.issue36780@roundup.psfhosted.org>


Hrvoje Nik?i? <hniksic at gmail.com> added the comment:

> The only way I could see this to work as intended without making any changes to threading would be to optionally use daemon threads and avoid joining the threads in `executor.shutdown()` if `wait_at_exit` is set to False in the constructor for the executor.

Agreed, and that is precisely what I suggested in my previous comment. The attached PR already deals with the executor-specific part of the wait, but it would be straightforward to have it also affect the executor to create daemon threads, and the flag moved to the constructor.

> IMO, it also would require some fairly extensive testing to make sure it works as intended, which the patch currently lacks.

It is quite easy to check that a hanging thread (emulated by a simple sleep) is not joined by the executor with the appropriate flag set.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36780>
_______________________________________

From report at bugs.python.org  Tue Apr 14 16:03:51 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 14 Apr 2020 20:03:51 +0000
Subject: [issue40282] random.getrandbits(0) should succeed
In-Reply-To: <1586878355.33.0.583777817655.issue40282@roundup.psfhosted.org>
Message-ID: <1586894631.58.0.585569079077.issue40282@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

+0 for having getrandbits(0) return 0.  Conceptually, it is reasonable.  Practically, it is a bit inconvenient because the ValueError may have to be moved upstream to the _randbelow() methods.

-1 for getrandbytes().  That is feature creep and no user has requested it.  Also, the name leads to a confusing API with getrandbits() returning arbitrary sized python ints and getrandbytes() returning bytes.  Lastly, it mostly duplicates functionality already supplied by secrets.token_bytes().  If you really want this, open another tracker issue and don't derail the issue at hand.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40282>
_______________________________________

From report at bugs.python.org  Tue Apr 14 16:13:20 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 14 Apr 2020 20:13:20 +0000
Subject: [issue39522] AST Unparser with unicode kinded constants
In-Reply-To: <1580600159.52.0.798208361602.issue39522@roundup.psfhosted.org>
Message-ID: <1586895200.04.0.824221724239.issue39522@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
nosy: +pablogsal
nosy_count: 1.0 -> 2.0
pull_requests: +18875
pull_request: https://github.com/python/cpython/pull/19525

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39522>
_______________________________________

From report at bugs.python.org  Tue Apr 14 16:21:30 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 14 Apr 2020 20:21:30 +0000
Subject: [issue39522] AST Unparser with unicode kinded constants
In-Reply-To: <1580600159.52.0.798208361602.issue39522@roundup.psfhosted.org>
Message-ID: <1586895690.15.0.276107654585.issue39522@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset 43aeefa41915e4d3b0e68bbd4268c1c378a72dce by Batuhan Ta?kaya in branch 'master':
bpo-39522: Use _PyUnicodeWriter_WriteStr instead of PyUnicode_AS_DATA (GH-19523)
https://github.com/python/cpython/commit/43aeefa41915e4d3b0e68bbd4268c1c378a72dce


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39522>
_______________________________________

From report at bugs.python.org  Tue Apr 14 16:40:45 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 14 Apr 2020 20:40:45 +0000
Subject: [issue39522] AST Unparser with unicode kinded constants
In-Reply-To: <1580600159.52.0.798208361602.issue39522@roundup.psfhosted.org>
Message-ID: <1586896845.0.0.376656313558.issue39522@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset 33986465bde2a2188537c4ef6cdb6055e348f31f by Pablo Galindo in branch 'master':
bpo-39522: Always initialise kind attribute in constant ast nodes (GH-19525)
https://github.com/python/cpython/commit/33986465bde2a2188537c4ef6cdb6055e348f31f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39522>
_______________________________________

From report at bugs.python.org  Tue Apr 14 16:41:03 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 14 Apr 2020 20:41:03 +0000
Subject: [issue39522] AST Unparser with unicode kinded constants
In-Reply-To: <1580600159.52.0.798208361602.issue39522@roundup.psfhosted.org>
Message-ID: <1586896863.39.0.917538126762.issue39522@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39522>
_______________________________________

From report at bugs.python.org  Tue Apr 14 16:50:03 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 14 Apr 2020 20:50:03 +0000
Subject: [issue40282] random.getrandbits(0) should succeed
In-Reply-To: <1586878355.33.0.583777817655.issue40282@roundup.psfhosted.org>
Message-ID: <1586897403.95.0.439988184014.issue40282@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I do not want to open an issue if I know that the idea will be rejected.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40282>
_______________________________________

From report at bugs.python.org  Tue Apr 14 16:51:04 2020
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 14 Apr 2020 20:51:04 +0000
Subject: [issue40282] random.getrandbits(0) should succeed
In-Reply-To: <1586878355.33.0.583777817655.issue40282@roundup.psfhosted.org>
Message-ID: <1586897464.46.0.881856274924.issue40282@roundup.psfhosted.org>


Antoine Pitrou <solipsis at pitrou.net> added the comment:

About a hypothetical getrandbytes(), probably 90% of my uses of getrandbits() have been to generate random bytestrings.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40282>
_______________________________________

From report at bugs.python.org  Tue Apr 14 16:52:16 2020
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 14 Apr 2020 20:52:16 +0000
Subject: [issue40282] random.getrandbits(0) should succeed
In-Reply-To: <1586878355.33.0.583777817655.issue40282@roundup.psfhosted.org>
Message-ID: <1586897536.7.0.531482900347.issue40282@roundup.psfhosted.org>


Change by Antoine Pitrou <solipsis at pitrou.net>:


----------
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40282>
_______________________________________

From report at bugs.python.org  Tue Apr 14 16:52:22 2020
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 14 Apr 2020 20:52:22 +0000
Subject: [issue40282] random.getrandbits(0) should succeed
In-Reply-To: <1586878355.33.0.583777817655.issue40282@roundup.psfhosted.org>
Message-ID: <1586897542.51.0.341919163905.issue40282@roundup.psfhosted.org>


Change by Antoine Pitrou <solipsis at pitrou.net>:


----------
components: +Library (Lib)

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40282>
_______________________________________

From report at bugs.python.org  Tue Apr 14 17:01:50 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 14 Apr 2020 21:01:50 +0000
Subject: [issue40282] random.getrandbits(0) should succeed
In-Reply-To: <1586878355.33.0.583777817655.issue40282@roundup.psfhosted.org>
Message-ID: <1586898110.78.0.653445246385.issue40282@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Why not use secrets.token_bytes() or randrange(2**b).to_bytes()?   Do you really need an API extension?

----------
nosy: +tim.peters

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40282>
_______________________________________

From report at bugs.python.org  Tue Apr 14 17:04:50 2020
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 14 Apr 2020 21:04:50 +0000
Subject: [issue40282] random.getrandbits(0) should succeed
In-Reply-To: <1586878355.33.0.583777817655.issue40282@roundup.psfhosted.org>
Message-ID: <1586898290.36.0.525796713569.issue40282@roundup.psfhosted.org>


Antoine Pitrou <solipsis at pitrou.net> added the comment:

I agree I don't *need* it per se.  However, I suspect that for non-exports it would be easier than
`getrandbits(nbytes * 8).to_bytes(nbytes, 'endian')`.

As for `secrets.token_bytes()`, it's not really adequate for regular pseudo-random data generation when you want to use a fixed seed.  And I'm not sure what its performance characteristics are when you pass a large size.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40282>
_______________________________________

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: [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 17:23:18 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 14 Apr 2020 21:23:18 +0000
Subject: [issue40284] Add mapping methods to types.SimpleNamespace
In-Reply-To: <1586898649.19.0.221456344176.issue40284@roundup.psfhosted.org>
Message-ID: <1586899398.31.0.504218580868.issue40284@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Only the magic methods need to be added:  __getitem__, __setitem__, and __delitem__, __contains__, __len__, and __iter__.

The non-dunder names risk incursion into user-space names.

>>> SimpleNamespace(username1='value1', username2='value2')
namespace(username1='value1', username2='value2')
>>> dir(_)
['__class__', '__delattr__', '__dict__', '__dir__', '__doc__', '__eq__', '__format__', '__ge__', '__getattribute__', '__gt__', '__hash__', '__init__', '__init_subclass__', '__le__', '__lt__', '__ne__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__sizeof__', '__str__', '__subclasshook__', 'username1', 'username2']

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40284>
_______________________________________

From report at bugs.python.org  Tue Apr 14 17:31:02 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 14 Apr 2020 21:31:02 +0000
Subject: [issue40284] Add mapping methods to types.SimpleNamespace
In-Reply-To: <1586898649.19.0.221456344176.issue40284@roundup.psfhosted.org>
Message-ID: <1586899862.4.0.238271338404.issue40284@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I would prefer that SimpleNamespace remains as simple as it is:

https://docs.python.org/dev/library/types.html#types.SimpleNamespace
"A simple object subclass that provides attribute access to its namespace"

If you want to add the mapping protocol, I suggest you to create your own subclass and add the methods that you want.

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40284>
_______________________________________

From report at bugs.python.org  Tue Apr 14 17:40:54 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 14 Apr 2020 21:40:54 +0000
Subject: [issue40284] Add mapping methods to types.SimpleNamespace
In-Reply-To: <1586898649.19.0.221456344176.issue40284@roundup.psfhosted.org>
Message-ID: <1586900454.72.0.325069886118.issue40284@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> I would prefer that SimpleNamespace remains as simple as it is

This doesn't affect the simplicity of the current API at all.  If you don't need the feature, you won't even notice the extension.

> If you want to add the mapping protocol, I suggest you to create
> your own subclass and add the methods that you want

I do that for myself.  However, users would greatly benefit from having this an option.

We don't ask users to write their own defaultdicts from scratch even though that is simple dict subclass.  Providing this tool would instantly benefit a broad class of json users.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40284>
_______________________________________

From report at bugs.python.org  Tue Apr 14 17:46:08 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 14 Apr 2020 21:46:08 +0000
Subject: [issue40282] random.getrandbits(0) should succeed
In-Reply-To: <1586878355.33.0.583777817655.issue40282@roundup.psfhosted.org>
Message-ID: <1586900768.94.0.399896427183.issue40282@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> That is feature creep and no user has requested it.

Python already provides such function in the secrets module, so I'm not sure if what you mean that "no users has requested it". secrets.token_bytes() exists because there is a need for such function.

secrets.token_bytes() is more designed for security, but random.Random() is more designed for simulations. And such users also exists, that's why numpy provides numpy.random.bytes(length) function:
https://docs.scipy.org/doc/numpy-1.15.0/reference/generated/numpy.random.bytes.html

To be honest, I never understood where there is such "hole" in the random module API. Especially for SystemRandom since its source os.urandom() generates bytes.

A concrete use case is to generate manually a UUID4 from 16 random bytes. For testing, you may want to get "deterministic random" UUID4. Using getrandbits() for thta sounds unnatural to me. 

Another use case is to create a secret token: well, that's basically that secrets.token_bytes() does. That's used in multiprocessing but also in urllib (AbstractDigestAuthHandler.get_cnonce()).

So yeah, it sounds perfectly reasonable to add such simple function. I don't see how add such obvious function would be a "feature creep".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40282>
_______________________________________

From report at bugs.python.org  Tue Apr 14 17:52:36 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 14 Apr 2020 21:52:36 +0000
Subject: [issue40284] Add mapping methods to types.SimpleNamespace
In-Reply-To: <1586898649.19.0.221456344176.issue40284@roundup.psfhosted.org>
Message-ID: <1586901156.81.0.196985277503.issue40284@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> Providing this tool would instantly benefit a broad class of json users.

I'm not saying that there is no need for such tool. I am just asking to leave SimpleNamespace unchanged.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40284>
_______________________________________

From report at bugs.python.org  Tue Apr 14 18:16:36 2020
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Tue, 14 Apr 2020 22:16:36 +0000
Subject: [issue35569] OSX: Enable IPV6_RECVPKTINFO
In-Reply-To: <1545566447.14.0.0770528567349.issue35569@roundup.psfhosted.org>
Message-ID: <1586902596.06.0.341399792537.issue35569@roundup.psfhosted.org>


Change by Erlend Egeberg Aasland <erlend.aasland at innova.no>:


----------
pull_requests: +18876
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/19526

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35569>
_______________________________________

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: [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 18:38:33 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 14 Apr 2020 22:38:33 +0000
Subject: [issue40286] Add getrandbytes() method to random.Random
In-Reply-To: <1586903418.02.0.530735802731.issue40286@roundup.psfhosted.org>
Message-ID: <1586903913.49.0.903951815261.issue40286@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
keywords: +patch
pull_requests: +18877
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19527

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40286>
_______________________________________

From report at bugs.python.org  Tue Apr 14 18:41:39 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 14 Apr 2020 22:41:39 +0000
Subject: [issue40282] random.getrandbits(0) should succeed
In-Reply-To: <1586878355.33.0.583777817655.issue40282@roundup.psfhosted.org>
Message-ID: <1586904099.56.0.649283890294.issue40282@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I created bpo-40286: Add getrandbytes() method to random.Random.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40282>
_______________________________________

From report at bugs.python.org  Tue Apr 14 18:55:03 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 14 Apr 2020 22:55:03 +0000
Subject: [issue40255] Fixing Copy on Writes from reference counting
In-Reply-To: <1586619621.82.0.553262088399.issue40255@roundup.psfhosted.org>
Message-ID: <1586904903.69.0.750445151024.issue40255@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

This feature seems to be driven by Instagram use case. Are there other users who would benefit of that? Is it a common use case to load big data and then fork to use preloaded data?

PR 19474 has a maintenance cost:

* new configuration option
* new macro
* need a buildbot to check that the option is not broken
* document the change
* etc.

There is even now a question about using a different ABI flag.

It's not the common case to build a custom Python manually for a specific use case. Most users use a binary shipped by their operating system.

I'm not sure that it's worth it for Python to maintain such special build.

Maybe bpo-39511 would be a better motivation to support immortable objects.

But I'm also concerned by the huge impact on performance :-(

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40255>
_______________________________________

From report at bugs.python.org  Tue Apr 14 19:00:46 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 14 Apr 2020 23:00:46 +0000
Subject: [issue40286] Add getrandbytes() method to random.Random
In-Reply-To: <1586903418.02.0.530735802731.issue40286@roundup.psfhosted.org>
Message-ID: <1586905246.01.0.199656354857.issue40286@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

If we have to have this, the method name should be differentiated from getrandbits() because the latter returns an integer.  I suggest just random.bytes(n), the same as numpy.

> Python already has three functions to generate random bytes:

Now, there will be four ;-)

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40286>
_______________________________________

From report at bugs.python.org  Tue Apr 14 19:05:24 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 14 Apr 2020 23:05:24 +0000
Subject: [issue36670] regrtest: win_utils decodes typeperf output from the
 wrong encoding (test suite broken due to cpu usage feature on win 10/ german)
In-Reply-To: <1555689157.38.0.435665423105.issue36670@roundup.psfhosted.org>
Message-ID: <1586905524.34.0.869441037247.issue36670@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset b894b669c98cc365b84cbb8d20f531f1d0686f59 by Victor Stinner in branch '3.7':
Update libregrtest from master (GH-19517)
https://github.com/python/cpython/commit/b894b669c98cc365b84cbb8d20f531f1d0686f59


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36670>
_______________________________________

From report at bugs.python.org  Tue Apr 14 19:05:24 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 14 Apr 2020 23:05:24 +0000
Subject: [issue38502] regrtest: use process groups
In-Reply-To: <1571266006.89.0.625453271604.issue38502@roundup.psfhosted.org>
Message-ID: <1586905524.09.0.599078619729.issue38502@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset b894b669c98cc365b84cbb8d20f531f1d0686f59 by Victor Stinner in branch '3.7':
Update libregrtest from master (GH-19517)
https://github.com/python/cpython/commit/b894b669c98cc365b84cbb8d20f531f1d0686f59


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38502>
_______________________________________

From report at bugs.python.org  Tue Apr 14 19:05:24 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 14 Apr 2020 23:05:24 +0000
Subject: [issue37957] Allow regrtest to receive a file with test (and
 subtests) to ignore
In-Reply-To: <1566864234.54.0.166621143796.issue37957@roundup.psfhosted.org>
Message-ID: <1586905524.25.0.695387188719.issue37957@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset b894b669c98cc365b84cbb8d20f531f1d0686f59 by Victor Stinner in branch '3.7':
Update libregrtest from master (GH-19517)
https://github.com/python/cpython/commit/b894b669c98cc365b84cbb8d20f531f1d0686f59


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37957>
_______________________________________

From report at bugs.python.org  Tue Apr 14 19:05:24 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 14 Apr 2020 23:05:24 +0000
Subject: [issue37531] Fix regrtest timeout for subprocesses: regrtest -jN
 --timeout=SECONDS
In-Reply-To: <1562700862.92.0.104600612678.issue37531@roundup.psfhosted.org>
Message-ID: <1586905524.16.0.689271391123.issue37531@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset b894b669c98cc365b84cbb8d20f531f1d0686f59 by Victor Stinner in branch '3.7':
Update libregrtest from master (GH-19517)
https://github.com/python/cpython/commit/b894b669c98cc365b84cbb8d20f531f1d0686f59


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37531>
_______________________________________

From report at bugs.python.org  Tue Apr 14 19:05:24 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 14 Apr 2020 23:05:24 +0000
Subject: [issue36842] Implement PEP 578
In-Reply-To: <1557262112.79.0.0300199683807.issue36842@roundup.psfhosted.org>
Message-ID: <1586905524.29.0.319624970879.issue36842@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset b894b669c98cc365b84cbb8d20f531f1d0686f59 by Victor Stinner in branch '3.7':
Update libregrtest from master (GH-19517)
https://github.com/python/cpython/commit/b894b669c98cc365b84cbb8d20f531f1d0686f59


----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36842>
_______________________________________

From report at bugs.python.org  Tue Apr 14 19:06:09 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 14 Apr 2020 23:06:09 +0000
Subject: [issue40284] Add mapping methods to types.SimpleNamespace
In-Reply-To: <1586898649.19.0.221456344176.issue40284@roundup.psfhosted.org>
Message-ID: <1586905569.05.0.625763443197.issue40284@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> I'm not saying that there is no need for such tool. 
> I am just asking to leave SimpleNamespace unchanged.

I really don't see the downside. It doesn't impair SimpleNamespace in any way.  Why would we add another type with substantially the same capabilities as SimpleNamespace?  That would be a complete waste.

----------
nosy: +eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40284>
_______________________________________

From report at bugs.python.org  Tue Apr 14 19:14:21 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 14 Apr 2020 23:14:21 +0000
Subject: [issue39481] Implement PEP 585 (Type Hinting Generics In Standard
 Collections)
In-Reply-To: <1580231817.93.0.47144630055.issue39481@roundup.psfhosted.org>
Message-ID: <1586906061.63.0.90542226197.issue39481@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:


New changeset d01628e411752ee6849f862cae66a1c69fe512b7 by Ethan Smith in branch 'master':
bpo-39481: PEP 585 for dataclasses, mailbox, contextvars (GH-19425)
https://github.com/python/cpython/commit/d01628e411752ee6849f862cae66a1c69fe512b7


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39481>
_______________________________________

From report at bugs.python.org  Tue Apr 14 19:25:49 2020
From: report at bugs.python.org (Ammar Askar)
Date: Tue, 14 Apr 2020 23:25:49 +0000
Subject: [issue40270] activate (or include) json1 extension in sqlite
In-Reply-To: <1586770672.18.0.207799300786.issue40270@roundup.psfhosted.org>
Message-ID: <1586906749.09.0.457946807059.issue40270@roundup.psfhosted.org>


Change by Ammar Askar <ammar at ammaraskar.com>:


----------
keywords: +patch
nosy: +ammar2
nosy_count: 5.0 -> 6.0
pull_requests: +18878
stage: test needed -> patch review
pull_request: https://github.com/python/cpython/pull/19528

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40270>
_______________________________________

From report at bugs.python.org  Tue Apr 14 19:40:31 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 14 Apr 2020 23:40:31 +0000
Subject: [issue40268] Reorganize pycore_pystate.h header
In-Reply-To: <1586732467.85.0.974458317268.issue40268@roundup.psfhosted.org>
Message-ID: <1586907631.53.0.770271506161.issue40268@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +18879
pull_request: https://github.com/python/cpython/pull/19529

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40268>
_______________________________________

From report at bugs.python.org  Tue Apr 14 19:59:59 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 14 Apr 2020 23:59:59 +0000
Subject: [issue40268] Reorganize pycore_pystate.h header
In-Reply-To: <1586732467.85.0.974458317268.issue40268@roundup.psfhosted.org>
Message-ID: <1586908799.53.0.796476665406.issue40268@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

See also bpo-2897: Deprecate structmember.h.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40268>
_______________________________________

From report at bugs.python.org  Tue Apr 14 20:04:49 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 15 Apr 2020 00:04:49 +0000
Subject: [issue40268] Reorganize pycore_pystate.h header
In-Reply-To: <1586732467.85.0.974458317268.issue40268@roundup.psfhosted.org>
Message-ID: <1586909089.8.0.687364366587.issue40268@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 62183b8d6d49e59c6a98bbdaa65b7ea1415abb7f by Victor Stinner in branch 'master':
bpo-40268: Remove explicit pythread.h includes (#19529)
https://github.com/python/cpython/commit/62183b8d6d49e59c6a98bbdaa65b7ea1415abb7f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40268>
_______________________________________

From report at bugs.python.org  Tue Apr 14 20:12:05 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 15 Apr 2020 00:12:05 +0000
Subject: [issue40268] Reorganize pycore_pystate.h header
In-Reply-To: <1586732467.85.0.974458317268.issue40268@roundup.psfhosted.org>
Message-ID: <1586909525.45.0.712773246362.issue40268@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +18880
pull_request: https://github.com/python/cpython/pull/19530

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40268>
_______________________________________

From report at bugs.python.org  Tue Apr 14 20:35:48 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 15 Apr 2020 00:35:48 +0000
Subject: [issue40268] Reorganize pycore_pystate.h header
In-Reply-To: <1586732467.85.0.974458317268.issue40268@roundup.psfhosted.org>
Message-ID: <1586910948.29.0.150955502078.issue40268@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 4a21e57fe55076c77b0ee454e1994ca544d09dc0 by Victor Stinner in branch 'master':
bpo-40268: Remove unused structmember.h includes (GH-19530)
https://github.com/python/cpython/commit/4a21e57fe55076c77b0ee454e1994ca544d09dc0


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40268>
_______________________________________

From report at bugs.python.org  Tue Apr 14 20:38:11 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 15 Apr 2020 00:38:11 +0000
Subject: [issue40268] Reorganize pycore_pystate.h header
In-Reply-To: <1586732467.85.0.974458317268.issue40268@roundup.psfhosted.org>
Message-ID: <1586911091.99.0.693811756762.issue40268@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +18881
pull_request: https://github.com/python/cpython/pull/19531

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40268>
_______________________________________

From report at bugs.python.org  Tue Apr 14 20:46:25 2020
From: report at bugs.python.org (Ethan Smith)
Date: Wed, 15 Apr 2020 00:46:25 +0000
Subject: [issue39481] Implement PEP 585 (Type Hinting Generics In Standard
 Collections)
In-Reply-To: <1586906061.63.0.90542226197.issue39481@roundup.psfhosted.org>
Message-ID: <CAMzjp8HeSLDVW39shouMntmNmX1ith=wK7CqNd-bMhtHFFSi4g@mail.gmail.com>


Ethan Smith <ethan at ethanhs.me> added the comment:

I went through the list I generated and it seems that the
ipaddress._BaseNetwork and mmap.mmap cases are the only one I saw that
shouldn't be generic. I will submit a PR to revert those. The only item
left after that which I know of is _lru_cache_wrapper.

On Tue, Apr 14, 2020 at 4:14 PM Guido van Rossum <report at bugs.python.org>
wrote:

>
> Guido van Rossum <guido at python.org> added the comment:
>
>
> New changeset d01628e411752ee6849f862cae66a1c69fe512b7 by Ethan Smith in
> branch 'master':
> bpo-39481: PEP 585 for dataclasses, mailbox, contextvars (GH-19425)
>
> https://github.com/python/cpython/commit/d01628e411752ee6849f862cae66a1c69fe512b7
>
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue39481>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39481>
_______________________________________

From report at bugs.python.org  Tue Apr 14 20:57:57 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 15 Apr 2020 00:57:57 +0000
Subject: [issue40268] Reorganize pycore_pystate.h header
In-Reply-To: <1586732467.85.0.974458317268.issue40268@roundup.psfhosted.org>
Message-ID: <1586912277.16.0.757188932565.issue40268@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset d9ea5cae1d07e1ee8b03540a9367c26205e0e360 by Victor Stinner in branch 'master':
bpo-40268: Remove unused pycore_pymem.h includes (GH-19531)
https://github.com/python/cpython/commit/d9ea5cae1d07e1ee8b03540a9367c26205e0e360


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40268>
_______________________________________

From report at bugs.python.org  Tue Apr 14 20:58:41 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 15 Apr 2020 00:58:41 +0000
Subject: [issue40268] Reorganize pycore_pystate.h header
In-Reply-To: <1586732467.85.0.974458317268.issue40268@roundup.psfhosted.org>
Message-ID: <1586912321.74.0.121648643786.issue40268@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +18882
pull_request: https://github.com/python/cpython/pull/19532

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40268>
_______________________________________

From report at bugs.python.org  Tue Apr 14 21:03:29 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 15 Apr 2020 01:03:29 +0000
Subject: [issue39522] AST Unparser with unicode kinded constants
In-Reply-To: <1580600159.52.0.798208361602.issue39522@roundup.psfhosted.org>
Message-ID: <1586912609.3.0.569927763791.issue39522@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

commit aade1cc453698e1bc48861b16955c2c2219ec521
Author: Batuhan Ta?kaya <batuhanosmantaskaya at gmail.com>
Date:   Tue Apr 14 21:55:01 2020 +0300

    bpo-395222: Correctly unparse unicode prefix in ast_unparse.c (GH-19512)

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39522>
_______________________________________

From report at bugs.python.org  Tue Apr 14 21:06:17 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 15 Apr 2020 01:06:17 +0000
Subject: [issue39522] AST Unparser with unicode kinded constants
In-Reply-To: <1580600159.52.0.798208361602.issue39522@roundup.psfhosted.org>
Message-ID: <1586912777.04.0.37750792109.issue39522@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Many buildbots failed. Example:

https://buildbot.python.org/all/#/builders/500/builds/288

======================================================================
FAIL: test_annotations (test.test_future.AnnotationsFutureTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/dje/cpython-buildarea/3.x.edelsohn-fedora-z.lto/build/Lib/test/test_future.py", line 156, in test_annotations
    eq("u'some_string'")
  File "/home/dje/cpython-buildarea/3.x.edelsohn-fedora-z.lto/build/Lib/test/test_future.py", line 150, in assertAnnotationEqual
    self.assertEqual(actual, expected)
AssertionError: "'some_string'" != "u'some_string'"
- 'some_string'
+ u'some_string'
? +


----------------------------------------------------------------------

----------
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39522>
_______________________________________

From report at bugs.python.org  Tue Apr 14 21:25:00 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 15 Apr 2020 01:25:00 +0000
Subject: [issue40268] Reorganize pycore_pystate.h header
In-Reply-To: <1586732467.85.0.974458317268.issue40268@roundup.psfhosted.org>
Message-ID: <1586913900.75.0.544512504238.issue40268@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 361dcdcefc80f5729ed18ac0ef73327794fbf400 by Victor Stinner in branch 'master':
bpo-40268: Remove unused osdefs.h includes (GH-19532)
https://github.com/python/cpython/commit/361dcdcefc80f5729ed18ac0ef73327794fbf400


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40268>
_______________________________________

From report at bugs.python.org  Tue Apr 14 21:27:41 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 15 Apr 2020 01:27:41 +0000
Subject: [issue40268] Reorganize pycore_pystate.h header
In-Reply-To: <1586732467.85.0.974458317268.issue40268@roundup.psfhosted.org>
Message-ID: <1586914061.09.0.29366077639.issue40268@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +18883
pull_request: https://github.com/python/cpython/pull/19533

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40268>
_______________________________________

From report at bugs.python.org  Tue Apr 14 21:35:27 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 15 Apr 2020 01:35:27 +0000
Subject: [issue39573] [C API] Make PyObject an opaque structure in the limited
 C API
In-Reply-To: <1581030432.16.0.48160379721.issue39573@roundup.psfhosted.org>
Message-ID: <1586914527.97.0.175492629419.issue39573@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

PyType_FromSpec() and PyType_Spec API are not currently compatible with opaque PyObject.

Example:
---
#define PyObject_HEAD    PyObject ob_base;

typedef struct {
    PyObject_HEAD
    ...
} MyObject;

static PyType_Spec type_spec = {
    .name = "MyObject",
    .basicsize = sizeof(MyObject),
    ...
};

... = PyType_FromSpec(&type_spec);
---

sizeof(MyObject) requires to compute sizeof(PyObject).

Issue reported by Ronald Oussoren on python-dev:
https://mail.python.org/archives/list/python-dev at python.org/message/PGKRW7S2IUOWVRX6F7RT6VAWD3ZPUDYS/

----------
title: Make PyObject an opaque structure in the limited C API -> [C API] Make PyObject an opaque structure in the limited C API

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39573>
_______________________________________

From report at bugs.python.org  Tue Apr 14 21:38:49 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 15 Apr 2020 01:38:49 +0000
Subject: [issue40170] [C API] Make PyTypeObject structure an opaque structure
 in the public C API
In-Reply-To: <1585915023.07.0.846808236133.issue40170@roundup.psfhosted.org>
Message-ID: <1586914729.93.0.820022452955.issue40170@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

On python-dev, Ronald Oussoren asked to add support for the buffer protocol in PyType_FromSpec() and PyTypeSpec API:

Ronald:
> BTW. This will require growing the PyTypeSpec ABI a little, there are features you cannot implement using that API for example the buffer protocol.

https://mail.python.org/archives/list/python-dev at python.org/message/PGKRW7S2IUOWVRX6F7RT6VAWD3ZPUDYS/

See also PyType_FromSpec() issue with opaque PyObject:
https://bugs.python.org/issue39573#msg366473

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40170>
_______________________________________

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: [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 21:59:14 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 15 Apr 2020 01:59:14 +0000
Subject: [issue39481] Implement PEP 585 (Type Hinting Generics In Standard
 Collections)
In-Reply-To: <CAMzjp8HeSLDVW39shouMntmNmX1ith=wK7CqNd-bMhtHFFSi4g@mail.gmail.com>
Message-ID: <CAP7+vJ+y5fuNUr-L0nDainiQ4nVT+Jo75kKDzM_TVAhG4O5jJg@mail.gmail.com>


Guido van Rossum <guido at python.org> added the comment:

Thanks!
-- 
--Guido (mobile)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39481>
_______________________________________

From report at bugs.python.org  Tue Apr 14 22:02:05 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 15 Apr 2020 02:02:05 +0000
Subject: [issue40268] Reorganize pycore_pystate.h header
In-Reply-To: <1586732467.85.0.974458317268.issue40268@roundup.psfhosted.org>
Message-ID: <1586916125.47.0.450011236468.issue40268@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 4f98f465f14e7258c5b18a62c5aa114dbe1174d8 by Victor Stinner in branch 'master':
bpo-40268: Remove unused imports in pylifecycle.c (GH-19533)
https://github.com/python/cpython/commit/4f98f465f14e7258c5b18a62c5aa114dbe1174d8


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40268>
_______________________________________

From report at bugs.python.org  Tue Apr 14 22:03:59 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 15 Apr 2020 02:03:59 +0000
Subject: [issue40268] Reorganize pycore_pystate.h header
In-Reply-To: <1586732467.85.0.974458317268.issue40268@roundup.psfhosted.org>
Message-ID: <1586916239.95.0.954235455703.issue40268@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +18884
pull_request: https://github.com/python/cpython/pull/19536

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40268>
_______________________________________

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: [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:31:42 2020
From: report at bugs.python.org (Ammar Askar)
Date: Wed, 15 Apr 2020 02:31:42 +0000
Subject: [issue40277] Improve repr for _tuplegetter objects
In-Reply-To: <1586827419.3.0.773379446138.issue40277@roundup.psfhosted.org>
Message-ID: <1586917902.15.0.195281720988.issue40277@roundup.psfhosted.org>


Change by Ammar Askar <ammar at ammaraskar.com>:


----------
keywords: +patch
nosy: +ammar2
nosy_count: 1.0 -> 2.0
pull_requests: +18885
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19537

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40277>
_______________________________________

From report at bugs.python.org  Tue Apr 14 22:39:49 2020
From: report at bugs.python.org (Kyle Stanley)
Date: Wed, 15 Apr 2020 02:39:49 +0000
Subject: [issue36780] Interpreter exit blocks waiting for futures of shut-down
 ThreadPoolExecutors
In-Reply-To: <1556875683.94.0.285155490659.issue36780@roundup.psfhosted.org>
Message-ID: <1586918389.88.0.105679988012.issue36780@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:

> Agreed, and that is precisely what I suggested in my previous comment. The attached PR already deals with the executor-specific part of the wait, but it would be straightforward to have it also affect the executor to create daemon threads, and the flag moved to the constructor.

Ah, I see. That should be fine then, but I would like to wait on additional feedback to make sure that re-adding daemon threads (even as a opt-in flag) is something that we want to do. I think you do have a good point regarding the practical utility in situations where it may not be feasible to programmatically prevent a thread from hanging indefinitely, but the main questions are: 

Is it something that ought to be provided by ThreadPoolExecutor? 
If so, is this the best way to implement it?

> It is quite easy to check that a hanging thread (emulated by a simple sleep) is not joined by the executor with the appropriate flag set.

That would certainly be part of it, but we also have to verify a few other things (this is off the top of my head, so I'm likely missing some points):

1) All of the threads are created as daemon threads, instead of regular threads when the flag is set (easy)
2) The hanging thread itself was able to finalize properly (without any leaked references or resource issues)
3) The rest of the executor resources were able to finalize properly, despite the hanging thread
4) The interpreter was able to finalize properly, despite the hanging thread

It's not so much writing the tests that will be especially involved, it's more so the time investment required to get them all to pass. Which could potentially be on the first try, or it could take many different implementations until it works across supported platforms. In my experience so far from working with the executors, it's more likely to be the latter.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36780>
_______________________________________

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: [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 22:40:51 2020
From: report at bugs.python.org (thautwarm)
Date: Wed, 15 Apr 2020 02:40:51 +0000
Subject: [issue40289] "highlighting" how to get Python's Scripts directory in
 the documentation
In-Reply-To: <1586918438.96.0.496326994048.issue40289@roundup.psfhosted.org>
Message-ID: <1586918451.94.0.149397978294.issue40289@roundup.psfhosted.org>


Change by thautwarm <yaoxiansamma at gmail.com>:


----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python
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/issue40289>
_______________________________________

From report at bugs.python.org  Tue Apr 14 22:44:13 2020
From: report at bugs.python.org (Shantanu)
Date: Wed, 15 Apr 2020 02:44:13 +0000
Subject: [issue28002] ast.unparse can't roundtrip some f-strings
In-Reply-To: <1473268698.62.0.800338957351.issue28002@psf.upfronthosting.co.za>
Message-ID: <1586918653.32.0.639516798058.issue28002@roundup.psfhosted.org>


Shantanu <hauntsaninja at gmail.com> added the comment:

Now that `ast.unparse` is being added to stdlib, I thought I'd bump this thread. The third party library `astunparse` (which attempts to support multiple Python versions while staying very close to Tools/parser/unparse.py) has an implementation that works for complex cases.
If that sounds good, I can submit a PR and inform the original author (astunparse is license is based on PSF's, so should be okay if the original author doesn't respond).

https://github.com/simonpercivall/astunparse/blob/master/lib/astunparse/unparser.py#L461

----------
nosy: +hauntsaninja

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28002>
_______________________________________

From report at bugs.python.org  Tue Apr 14 23:05:16 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 15 Apr 2020 03:05:16 +0000
Subject: [issue39522] AST Unparser with unicode kinded constants
In-Reply-To: <1580600159.52.0.798208361602.issue39522@roundup.psfhosted.org>
Message-ID: <1586919916.34.0.144368989299.issue39522@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

I think that this was fixes by PR19525 and PR19523. For instance, the buildbot you mentioned is green when building those PRs:

https://buildbot.python.org/all/#/builders/500/builds/289

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39522>
_______________________________________

From report at bugs.python.org  Tue Apr 14 23:06:52 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 15 Apr 2020 03:06:52 +0000
Subject: [issue39522] AST Unparser with unicode kinded constants
In-Reply-To: <1580600159.52.0.798208361602.issue39522@roundup.psfhosted.org>
Message-ID: <1586920012.8.0.50732569104.issue39522@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

I checked and all current buildbot failures are related to the refleak in test_threading so I think this issue is fixed. I will close the issue, please reopen of I missed something or you would like to address something else :)

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39522>
_______________________________________

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: [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 00:18:16 2020
From: report at bugs.python.org (Glenn Linderman)
Date: Wed, 15 Apr 2020 04:18:16 +0000
Subject: [issue40284] Add mapping methods to types.SimpleNamespace
In-Reply-To: <1586898649.19.0.221456344176.issue40284@roundup.psfhosted.org>
Message-ID: <1586924296.37.0.426050948873.issue40284@roundup.psfhosted.org>


Glenn Linderman <v+python at g.nevcal.com> added the comment:

Yes, I laud this effort. I don't care if it is called SimpleNamespace (which I didn't use because it was insufficient), or anything else, but it would be extremely handy to have this battery.

I eventually found one called Dotable (or did I rename it to that?) which after a fair bit of study I finally understood, and then was able to add a few tweaks to make it work the way that was most convenient for me.

While I agree with Guido that these are not standard Python semantics, they are, as pointed out by Raymond, far more convenient to use for nested structures.

And as far as using CoffeeScript, I don't know of a CoffeeScript to Python conversion: the rest of the semantics of Python are more preferable than Javascript. I just wish Brendan Eich had consulted with Guido before inventing Javascript.

----------
nosy: +v+python

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40284>
_______________________________________

From report at bugs.python.org  Wed Apr 15 00:28:09 2020
From: report at bugs.python.org (Glenn Linderman)
Date: Wed, 15 Apr 2020 04:28:09 +0000
Subject: [issue40284] Add mapping methods to types.SimpleNamespace
In-Reply-To: <1586898649.19.0.221456344176.issue40284@roundup.psfhosted.org>
Message-ID: <1586924889.34.0.270325299205.issue40284@roundup.psfhosted.org>


Glenn Linderman <v+python at g.nevcal.com> added the comment:

Here's what I have.

Maybe it would be better if parse and dump were under or dunder names, although I think parse was in the original implementation I found.

Is this the derived from the same original as PyPI dotable? Not sure.

----------
Added file: https://bugs.python.org/file49061/Dotable.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40284>
_______________________________________

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: [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 01:32:32 2020
From: report at bugs.python.org (Mark Mikofski)
Date: Wed, 15 Apr 2020 05:32:32 +0000
Subject: [issue38583] The activate script in Windows is not correct for venvs
 created in git-bash
In-Reply-To: <1571927523.33.0.935819222823.issue38583@roundup.psfhosted.org>
Message-ID: <1586928752.24.0.0616826790055.issue38583@roundup.psfhosted.org>


Mark Mikofski <bwana.marko at yahoo.com> added the comment:

Would you consider just handling activate for windows directly in the lib/venv/__init__.py method "install_scripts(self, context, path)"
https://github.com/python/cpython/blob/4f98f465f14e7258c5b18a62c5aa114dbe1174d8/Lib/venv/__init__.py#L382

    if not srcfile.endswith(('.exe', '.pdb')):

        # handle activate for Windows (ignore WSL)
        if srcfile == "activate":
            # from docs: on unix drive is always empty
            d, p = os.path.splitdrive(context.env_dir)
            d = d.replace(':', '')
            p = p.replace('\\', '/')
            if d:
                p = '/' + d + p
            data = data.decode('utf-8')
            data = data.replace('__VENV_DIR__', p)
            data = data.encode('utf-8')

        try:
            data = data.decode('utf-8')
            data = self.replace_variables(data, context)
            data = data.encode('utf-8')
        except UnicodeError as e:

IMHO I don't think the use of windows python in WSL is a realistic use-case, my preference would be to just make this fail. In fact I tried to use it, and I could not make it work.
1. /mnt/c/path/to/python -m venv venv
Error: [WinError 5] Access is denied: 'C:\\WINDOWS\\system32\\venv'
2. /mnt/c/path/to/python -m venv -m venv /mnt/c/some/path/to/venv
fails silently, appears to do nothing, venv is not created
3. /mnt/c/path/to/python -m venv -m venv 'C:/some/path/to/venv'
makes directories at C:\some\path\to\venv, but can't be activated in WSL, that I can figure out
source /mnt/c/some/path/to/venv/Scripts/activate
: command not found
-bash: /mnt/c/some/path/to/venv/Scripts/activate: line 4: syntax error near unexpected token `$'{\r''
'bash: /mnt/c/some/path/to/venv/Scripts/activate: line 4: `deactivate () {

I guess I don't really understand why it would be useful to use the windows python in WSL, and if that's the only thing holding a quick fix for this, I guess, I would prefer to just handle windows python in windows in git-bash, and ignore WSL. Would you be open to that?

If so, I'm happy to submit a PR

thanks!

----------
nosy: +bwanamarko

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38583>
_______________________________________

From report at bugs.python.org  Wed Apr 15 01:39:25 2020
From: report at bugs.python.org (Karl Ding)
Date: Wed, 15 Apr 2020 05:39:25 +0000
Subject: [issue40291] socket library support for CAN_J1939
In-Reply-To: <1586928559.09.0.469111314858.issue40291@roundup.psfhosted.org>
Message-ID: <1586929165.19.0.119623152136.issue40291@roundup.psfhosted.org>


Change by Karl Ding <karl.jw.ding at gmail.com>:


----------
keywords: +patch
pull_requests: +18886
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19538

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40291>
_______________________________________

From report at bugs.python.org  Wed Apr 15 02:36:20 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 15 Apr 2020 06:36:20 +0000
Subject: [issue40277] Improve repr for _tuplegetter objects
In-Reply-To: <1586827419.3.0.773379446138.issue40277@roundup.psfhosted.org>
Message-ID: <1586932580.67.0.503579411107.issue40277@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:


New changeset a86b522d8f1c8b9c26b5550de221d2227158cf4d by Ammar Askar in branch 'master':
bpo-40277: Add a repr() to namedtuple's _tuplegetter to aid with introspection (GH-19537)
https://github.com/python/cpython/commit/a86b522d8f1c8b9c26b5550de221d2227158cf4d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40277>
_______________________________________

From report at bugs.python.org  Wed Apr 15 02:37:05 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 15 Apr 2020 06:37:05 +0000
Subject: [issue40277] Improve repr for _tuplegetter objects
In-Reply-To: <1586827419.3.0.773379446138.issue40277@roundup.psfhosted.org>
Message-ID: <1586932625.1.0.107302486163.issue40277@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Thanks for the PR :-)

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40277>
_______________________________________

From report at bugs.python.org  Wed Apr 15 03:33:13 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 15 Apr 2020 07:33:13 +0000
Subject: [issue28002] ast.unparse can't roundtrip some f-strings
In-Reply-To: <1473268698.62.0.800338957351.issue28002@psf.upfronthosting.co.za>
Message-ID: <1586935993.67.0.837910469267.issue28002@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
nosy: +pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28002>
_______________________________________

From report at bugs.python.org  Wed Apr 15 03:33:34 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 15 Apr 2020 07:33:34 +0000
Subject: [issue39865] getattr silences an unrelated AttributeError
In-Reply-To: <1583436241.07.0.803311507701.issue39865@roundup.psfhosted.org>
Message-ID: <1586936014.53.0.165683532965.issue39865@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Am going to mark this as closed for the reasons listed above.  If another coredev wants to champion this, feel free to resurrect the issue.

----------
resolution:  -> rejected
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39865>
_______________________________________

From report at bugs.python.org  Wed Apr 15 04:04:24 2020
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 15 Apr 2020 08:04:24 +0000
Subject: [issue40286] Add getrandbytes() method to random.Random
In-Reply-To: <1586903418.02.0.530735802731.issue40286@roundup.psfhosted.org>
Message-ID: <1586937864.07.0.243621685091.issue40286@roundup.psfhosted.org>


Change by Antoine Pitrou <solipsis at pitrou.net>:


----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40286>
_______________________________________

From report at bugs.python.org  Wed Apr 15 04:10:53 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 15 Apr 2020 08:10:53 +0000
Subject: [issue40276] Make member objects inspectable.
In-Reply-To: <1586826721.81.0.357033101024.issue40276@roundup.psfhosted.org>
Message-ID: <1586938253.65.0.681367555456.issue40276@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

What should this return?

>>> class A:
...   __slots__ = ['x', 'y', 'z']
...
>>> class B(A):
...   __slots__ = ['g','i']
...


>>> B.x.offset

----------
nosy: +pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40276>
_______________________________________

From report at bugs.python.org  Wed Apr 15 04:24:37 2020
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 15 Apr 2020 08:24:37 +0000
Subject: [issue40282] random.getrandbits(0) should succeed
In-Reply-To: <1586878355.33.0.583777817655.issue40282@roundup.psfhosted.org>
Message-ID: <1586939077.41.0.639698350806.issue40282@roundup.psfhosted.org>


Change by Antoine Pitrou <solipsis at pitrou.net>:


----------
keywords: +patch
pull_requests: +18887
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/19539

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40282>
_______________________________________

From report at bugs.python.org  Wed Apr 15 04:24:58 2020
From: report at bugs.python.org (Inada Naoki)
Date: Wed, 15 Apr 2020 08:24:58 +0000
Subject: [issue40287] SpooledTemporaryFile.seek returns None
In-Reply-To: <1586914911.28.0.271091942099.issue40287@roundup.psfhosted.org>
Message-ID: <1586939098.13.0.226901009543.issue40287@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
keywords: +patch
nosy: +inada.naoki
nosy_count: 1.0 -> 2.0
pull_requests: +18888
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19540

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40287>
_______________________________________

From report at bugs.python.org  Wed Apr 15 04:30:11 2020
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 15 Apr 2020 08:30:11 +0000
Subject: [issue39573] [C API] Make PyObject an opaque structure in the limited
 C API
In-Reply-To: <1581030432.16.0.48160379721.issue39573@roundup.psfhosted.org>
Message-ID: <1586939411.71.0.185199847075.issue39573@roundup.psfhosted.org>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

The incompatibility mentioned in msg366473 is probably fixable by treating the PyObject header the same as the GC head structure. With some care this could mostly maintain binary compatibility by inserting some unused fields in PyObject_HEAD instead of the PyObject header when an extension targets a stable ABI version that has the PyObject header in-line.

This issue seems to be comparible to the "fragile instance variable" issue fixed in Objective-C 2.0, see <https://en.wikipedia.org/wiki/Objective-C#Non-fragile_instance_variables>.  That was fixed by adding a level of indirection when accessing member variables.

Something like that is probably necessary to be able to subclass builtin types (other than object itself) in an extension.

----------
nosy: +ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39573>
_______________________________________

From report at bugs.python.org  Wed Apr 15 04:36:15 2020
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 15 Apr 2020 08:36:15 +0000
Subject: [issue40170] [C API] Make PyTypeObject structure an opaque structure
 in the public C API
In-Reply-To: <1585915023.07.0.846808236133.issue40170@roundup.psfhosted.org>
Message-ID: <1586939775.35.0.67013394698.issue40170@roundup.psfhosted.org>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Something else that probably needs attention with the TypeSpec API is subclassing type in an extension when that subclass adds fields to the type object.

I use this in PyObjC to (dynamically) create types that have some additional data.  I could probably work around this issue by adding a level of indirection (basically storing the extra data in a WeakKeyDictionary), but haven't looked into this yet.

----------
nosy: +ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40170>
_______________________________________

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: [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 04:36:31 2020
From: report at bugs.python.org (=?utf-8?b?VmVkcmFuIMSMYcSNacSH?=)
Date: Wed, 15 Apr 2020 08:36:31 +0000
Subject: [issue40286] Add getrandbytes() method to random.Random
In-Reply-To: <1586903418.02.0.530735802731.issue40286@roundup.psfhosted.org>
Message-ID: <1586939791.53.0.375236441067.issue40286@roundup.psfhosted.org>


Vedran ?a?i? <vedgar at gmail.com> added the comment:

> I suggest just random.bytes(n), the same as numpy.

The problem with this is that people who `from random import *` (some schools insist on this, probably because most functions they need already start with `rand`) will shadow builtin `bytes`. Not that those schools do anything with `bytes`, but still, it might be inconvenient.

(The metaproblem is of course that some functions already do the "poor man's namespacing" in C-style by starting with `rand`, and some don't. I'm always for user control of namespacing, but I'm just saying that it doesn't correspond to how many beginners use `random` module.)

----------
nosy: +veky

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40286>
_______________________________________

From report at bugs.python.org  Wed Apr 15 04:42:42 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 15 Apr 2020 08:42:42 +0000
Subject: [issue40276] Make member objects inspectable.
In-Reply-To: <1586826721.81.0.357033101024.issue40276@roundup.psfhosted.org>
Message-ID: <1586940162.7.0.81926119132.issue40276@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Good point.  I'll withdraw this.

----------
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40276>
_______________________________________

From report at bugs.python.org  Wed Apr 15 04:46:20 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 15 Apr 2020 08:46:20 +0000
Subject: [issue40286] Add getrandbytes() method to random.Random
In-Reply-To: <1586903418.02.0.530735802731.issue40286@roundup.psfhosted.org>
Message-ID: <1586940380.51.0.45639073601.issue40286@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Do you have another name suggestion that doesn't have a parallelism problem with the existing name?   The names getrandbytes() and getrandbits() suggest a parallelism that is incorrect.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40286>
_______________________________________

From report at bugs.python.org  Wed Apr 15 04:50:24 2020
From: report at bugs.python.org (=?utf-8?b?VmVkcmFuIMSMYcSNacSH?=)
Date: Wed, 15 Apr 2020 08:50:24 +0000
Subject: [issue40284] Add mapping methods to types.SimpleNamespace
In-Reply-To: <1586898649.19.0.221456344176.issue40284@roundup.psfhosted.org>
Message-ID: <1586940624.74.0.135736080662.issue40284@roundup.psfhosted.org>


Vedran ?a?i? <vedgar at gmail.com> added the comment:

I think there is a teaching moment here. I think it's important that no object in Python standard library conflates "item namespace" with "attr namespace". (Maybe that isn't true because of some specialized objects, but surely general ones such as SimpleNamespace shouldn't commit that mistake.)

On the other hand, we do have json in standard library, and JSON is primarily based on JavaScript Object Notation (yes, I know it's been extended to fit more languages, but still, its primal DNA shows). And the conflating of attributes and items is so natural in JS (a['b']===a.b) that it took them more than a decate to realize that separating Map from Object might be a good idea. :-)

So, maybe we should also have something like JSNamespace in stdlib (presumably in json module). But SimpleNamespace shouldn't be it. As Guido once said, a bucket has a handle, and it contains sand, but it doesn't contain a handle.

----------
nosy: +veky

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40284>
_______________________________________

From report at bugs.python.org  Wed Apr 15 04:57:43 2020
From: report at bugs.python.org (=?utf-8?b?VmVkcmFuIMSMYcSNacSH?=)
Date: Wed, 15 Apr 2020 08:57:43 +0000
Subject: [issue40286] Add getrandbytes() method to random.Random
In-Reply-To: <1586903418.02.0.530735802731.issue40286@roundup.psfhosted.org>
Message-ID: <1586941063.28.0.833307350948.issue40286@roundup.psfhosted.org>


Vedran ?a?i? <vedgar at gmail.com> added the comment:

I think that the "module owner";-P must decide whether the `random` module should follow the C-namespacing or not. Of course, I'm in the "not" camp, so I believe those two "rand..." functions (randrange is completely redundant with random.choice(range)) should be supplemented with random.int and random.float. And then random.bytes will be completely natural. And people might be gently nudged into the right direction when using Python module namespaces.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40286>
_______________________________________

From report at bugs.python.org  Wed Apr 15 05:03:47 2020
From: report at bugs.python.org (Michael Felt)
Date: Wed, 15 Apr 2020 09:03:47 +0000
Subject: [issue40244] AIX: build: _PyObject_GC_TRACK Asstertion failure
In-Reply-To: <1d90b0c7-95f9-7c31-7bf7-c159e7e1ff29@felt.demon.nl>
Message-ID: <dcd1179a-2eef-c5cf-096a-fc0f47104788@felt.demon.nl>


Michael Felt <aixtools at felt.demon.nl> added the comment:

On 14/04/2020 19:28, Michael Felt wrote:
> Michael Felt <aixtools at felt.demon.nl> added the comment:
>
> On 14/04/2020 14:54, Batuhan Taskaya wrote:
>> Batuhan Taskaya <batuhanosmantaskaya at gmail.com> added the comment:
>>
>>> With the print statements - it does not crash:
>> I think this isn't directly relevant with prints but about re-compiling? (just guessing).
> I only recompiled the one .c file. With that one file re-compiled -
> wqith fprintf statements it succeeds, restore the original .c file (git
> checkout -- Objects/whatever.c; make - it fails.
>
> Tomorrow I'll search for the option(s) needed to get (complete) assembly
> code listing and try to see (and understand) the difference between what
> xlc-v13 and xlc-v16 makes. And, what I shall also test - is to recompile
> only this one file using xlc-v13 and see if the make then proceeds normally.
>
>
Many pages of output - and I confess - I do have some difficulty reading
code every now and then.

As the "bug" wherever it may be is related, I am guessing, to compiler
optimization and how to deal with routines with "no return".

Trying to understand the listings - I ran across:

./Include/object.h:typedef void (*destructor)(PyObject *);

Could the error be related to compilers confusing a routine with no
return, versus a routine returning a pointer to a "void"?

recall the code:

static void
gen_dealloc(PyGenObject *gen)

Comments?

Michael

> As Victor commented earlier - very much looking like a compiler bug.
> That said, still do not know what to say/write to software support as a
> complaint.
>
>> ----------
>>
>> _______________________________________
>> Python tracker <report at bugs.python.org>
>> <https://bugs.python.org/issue40244>
>> _______________________________________
>>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue40244>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40244>
_______________________________________

From report at bugs.python.org  Wed Apr 15 05:27:19 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 15 Apr 2020 09:27:19 +0000
Subject: [issue40286] Add getrandbytes() method to random.Random
In-Reply-To: <1586903418.02.0.530735802731.issue40286@roundup.psfhosted.org>
Message-ID: <1586942839.0.0.482657126075.issue40286@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I concur that bytes() isn't a good name, but am still concerned that the proposed name is a bad API decision.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40286>
_______________________________________

From report at bugs.python.org  Wed Apr 15 05:38:03 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 15 Apr 2020 09:38:03 +0000
Subject: [issue40292] Memory leak when defining a new class inside a loop
In-Reply-To: <1586939786.47.0.691824545248.issue40292@roundup.psfhosted.org>
Message-ID: <1586943483.47.0.859172169276.issue40292@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Python2.7 gives similar results with:

    class A(object):
        pass

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40292>
_______________________________________

From report at bugs.python.org  Wed Apr 15 06:20:14 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 15 Apr 2020 10:20:14 +0000
Subject: [issue40292] Memory leak when defining a new class inside a loop
In-Reply-To: <1586939786.47.0.691824545248.issue40292@roundup.psfhosted.org>
Message-ID: <1586946014.4.0.712569221734.issue40292@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

It is not a leak. It is expected behavior when you call gc.set_debug(gc.DEBUG_SAVEALL).

----------
nosy: +serhiy.storchaka
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40292>
_______________________________________

From report at bugs.python.org  Wed Apr 15 06:50:23 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 15 Apr 2020 10:50:23 +0000
Subject: [issue40286] Add getrandbytes() method to random.Random
In-Reply-To: <1586903418.02.0.530735802731.issue40286@roundup.psfhosted.org>
Message-ID: <1586947823.87.0.866809323447.issue40286@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Maybe randbytes()?

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40286>
_______________________________________

From report at bugs.python.org  Wed Apr 15 08:40:52 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 15 Apr 2020 12:40:52 +0000
Subject: [issue40286] Add getrandbytes() method to random.Random
In-Reply-To: <1586903418.02.0.530735802731.issue40286@roundup.psfhosted.org>
Message-ID: <1586954452.59.0.380114382014.issue40286@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I like "from random import randbytes" name. I concur that "from random import bytes" overrides bytes() builtin type and so can likely cause troubles.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40286>
_______________________________________

From report at bugs.python.org  Wed Apr 15 08:50:05 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Wed, 15 Apr 2020 12:50:05 +0000
Subject: [issue40244] AIX: build: _PyObject_GC_TRACK Asstertion failure
In-Reply-To: <1586507316.69.0.786578254213.issue40244@roundup.psfhosted.org>
Message-ID: <1586955005.17.0.849567889099.issue40244@roundup.psfhosted.org>


Batuhan Taskaya <batuhanosmantaskaya at gmail.com> added the comment:

> No. I do not think it is the real problem either. And I do not know
compiler behavior well enough. Actually, considering the setting is
still -O0 (aka no optimization) I am surprised it has any effect. if I
understood correctly "no return" is intended to help the optimizer make
"informed" decisions.

Does removing all no returns change anything for you? (It didn't change anything for me, if I did it correctly)
find ./ -name "*.c" -type f -exec perl -pi -e 's/_Py_NO_RETURN//g' '{}' \;

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40244>
_______________________________________

From report at bugs.python.org  Wed Apr 15 08:57:20 2020
From: report at bugs.python.org (asca)
Date: Wed, 15 Apr 2020 12:57:20 +0000
Subject: [issue36207] robotsparser deny all with some rules
In-Reply-To: <1551865321.24.0.407834320039.issue36207@roundup.psfhosted.org>
Message-ID: <1586955440.52.0.628831811064.issue36207@roundup.psfhosted.org>


asca <arthur.ascarateil at gmail.com> added the comment:

I thought it was going to work but apparently when I try https://www.actusite.fr/robots.txt, it doesn't

----------
nosy: +artasca

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36207>
_______________________________________

From report at bugs.python.org  Wed Apr 15 09:07:40 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 15 Apr 2020 13:07:40 +0000
Subject: [issue40268] Reorganize pycore_pystate.h header
In-Reply-To: <1586732467.85.0.974458317268.issue40268@roundup.psfhosted.org>
Message-ID: <1586956060.94.0.753649127778.issue40268@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 5eca75df031d3cbe577c75dd87734b48c787e7f6 by Victor Stinner in branch 'master':
bpo-40268: Reformat posixmodule.c includes (GH-19536)
https://github.com/python/cpython/commit/5eca75df031d3cbe577c75dd87734b48c787e7f6


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40268>
_______________________________________

From report at bugs.python.org  Wed Apr 15 09:17:50 2020
From: report at bugs.python.org (Michael Felt)
Date: Wed, 15 Apr 2020 13:17:50 +0000
Subject: [issue39953] Let's update ssl error codes
In-Reply-To: <1584072470.83.0.437860249809.issue39953@roundup.psfhosted.org>
Message-ID: <1586956670.26.0.97133483394.issue39953@roundup.psfhosted.org>


Michael Felt <aixtools at felt.demon.nl> added the comment:

Do I need to open a new issue?

This breaks building _ssl on AIX.

building '_ssl' extension
xlc_r -O -I./Include/internal -I/opt/aixtools/include -I./Include -I. -I/home/aixtools/python/cpython-master/Include -I/home/aixtools/python/cpython-master -c /home/aixtools/python/cpython-master/Modules/_ssl.c -o build/temp.aix-7200-1543-32-3.9-pydebug/home/aixtools/python/cpython-master/Modules/_ssl.o
"/home/aixtools/python/cpython-master/Modules/_ssl_data.h", line 650.28: 1506-045 (S) Undeclared identifier ERR_LIB_ASYNC.
"/home/aixtools/python/cpython-master/Modules/_ssl_data.h", line 1510.29: 1506-045 (S) Undeclared identifier ERR_LIB_CT.
"/home/aixtools/python/cpython-master/Modules/_ssl_data.h", line 2650.24: 1506-045 (S) Undeclared identifier ERR_LIB_KDF.
"/home/aixtools/python/cpython-master/Modules/_ssl.c", line 579.17: 1506-196 (W) Initialization between types "void*" and "struct _object*(*)(struct {...}*)" is not allowed.



commit 909b87d2bb3d6330d39c48e43f7f50f4d086cc41
Author: Benjamin Peterson <benjamin at python.org>
Date:   Sun Apr 12 13:59:31 2020 -0500

    closes bpo-39953: Generate ifdefs around library code definitions. (GH-19490)

commit 3e0dd3730b5eff7e9ae6fb921aa77cd26efc9e3a
Author: Benjamin Peterson <benjamin at python.org>
Date:   Sat Apr 11 15:36:12 2020 -0500

    closes bpo-39953: Update OpenSSL error codes table. (GH-19082)

    I updated the error codes using the OpenSSL 1.1.1f source tree.

commit 173ad83b074b3bf0c9e86eb8bd101c2841f74297
Author: Antoine Pitrou <solipsis at pitrou.net>
Date:   Sun Jan 18 17:39:32 2015 +0100

    Issue #23248: Update ssl error codes from latest OpenSSL git master.

commit f7338f65fb8bdb85c52dc54d06d003a82a06bbb3
Author: Antoine Pitrou <solipsis at pitrou.net>
Date:   Fri Jun 22 21:12:59 2012 +0200

    Add forgotten files for #14837.
$

----------
nosy: +Michael.Felt

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39953>
_______________________________________

From report at bugs.python.org  Wed Apr 15 09:21:06 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 15 Apr 2020 13:21:06 +0000
Subject: [issue40286] Add randbytes() method to random.Random
In-Reply-To: <1586903418.02.0.530735802731.issue40286@roundup.psfhosted.org>
Message-ID: <1586956866.03.0.323257901188.issue40286@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I updated my PR to rename the method to randbytes().

----------
title: Add getrandbytes() method to random.Random -> Add randbytes() method to random.Random

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40286>
_______________________________________

From report at bugs.python.org  Wed Apr 15 09:23:00 2020
From: report at bugs.python.org (Michael Felt)
Date: Wed, 15 Apr 2020 13:23:00 +0000
Subject: [issue39953] Let's update ssl error codes
In-Reply-To: <1584072470.83.0.437860249809.issue39953@roundup.psfhosted.org>
Message-ID: <1586956980.83.0.889785587401.issue39953@roundup.psfhosted.org>


Michael Felt <aixtools at felt.demon.nl> added the comment:

Also checking with gcc: get the following messages:

Failed to build these modules:
_ssl

Could not build the ssl module!
Python requires an OpenSSL 1.0.2 or 1.1 compatible libssl with X509_VERIFY_PARAM_set1_host().
LibreSSL 2.6.4 and earlier do not provide the necessary APIs, https://github.com/libressl-portable/portable/issues/381

messages:
building '_ssl' extension
gcc -pthread -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/opt/aixtools/include -I./Include -I. -I/home/aixtools/python/cpython-master/Include -I/home/aixtools/python/cpython-master -c /home/aixtools/python/cpython-master/Modules/_ssl.c -o build/temp.aix-7200-1543-32-3.9-pydebug/home/aixtools/python/cpython-master/Modules/_ssl.o
In file included from /home/aixtools/python/cpython-master/Modules/_ssl.c:136:0:
/home/aixtools/python/cpython-master/Modules/_ssl_data.h:650:28: error: 'ERR_LIB_ASYNC' undeclared here (not in a function); did you mean 'ERR_LIB_ASN1'?
     {"FAILED_TO_SET_POOL", ERR_LIB_ASYNC, 101},
                            ^~~~~~~~~~~~~
                            ERR_LIB_ASN1
/home/aixtools/python/cpython-master/Modules/_ssl_data.h:1510:29: error: 'ERR_LIB_CT' undeclared here (not in a function); did you mean 'ERR_LIB_CMS'?
     {"BASE64_DECODE_ERROR", ERR_LIB_CT, 108},
                             ^~~~~~~~~~
                             ERR_LIB_CMS
/home/aixtools/python/cpython-master/Modules/_ssl_data.h:2650:24: error: 'ERR_LIB_KDF' undeclared here (not in a function); did you mean 'ERR_LIB_BUF'?
     {"INVALID_DIGEST", ERR_LIB_KDF, 100},
                        ^~~~~~~~~~~
                        ERR_LIB_BUF

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39953>
_______________________________________

From report at bugs.python.org  Wed Apr 15 09:35:40 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 15 Apr 2020 13:35:40 +0000
Subject: [issue40286] Add randbytes() method to random.Random
In-Reply-To: <1586903418.02.0.530735802731.issue40286@roundup.psfhosted.org>
Message-ID: <1586957740.61.0.313448294771.issue40286@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

The performance of the new method is not my first motivation.

My first motivation is to avoid consumers of the random to write a wrong implementation which would be biased. It's too easy to write biased functions without notifying.

Moreover, it seems like we can do something to get reproducible behavior on different architectures (different endianness) which would also be a nice feature.

For example, in bpo-13396, Amaury found this two functions in the wild:

* struct.pack("Q", random.getrandbits(64))
* sha1(str(random.getrandbits(8*20))).digest()

As I wrote, users are creative to workaround missing features :-) I don't think that these two implementations give the same result on big and little endian.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40286>
_______________________________________

From report at bugs.python.org  Wed Apr 15 09:46:44 2020
From: report at bugs.python.org (Michael Felt)
Date: Wed, 15 Apr 2020 13:46:44 +0000
Subject: [issue39953] Let's update ssl error codes
In-Reply-To: <1584072470.83.0.437860249809.issue39953@roundup.psfhosted.org>
Message-ID: <1586958404.51.0.846406517865.issue39953@roundup.psfhosted.org>


Michael Felt <aixtools at felt.demon.nl> added the comment:

And when I use a standard OpenSSL library (on AIX):

building '_ssl' extension
gcc -pthread -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/opt/freeware/include -I./Include -I. -I/home/aixtools/python/cpython-master/Include -I/home/aixtools/python/cpython-master -c /home/aixtools/python/cpython-master/Modules/_ssl.c -o build/temp.aix-7200-1543-32-3.9-pydebug/home/aixtools/python/cpython-master/Modules/_ssl.o
Modules/ld_so_aix gcc -pthread -bI:Modules/python.exp build/temp.aix-7200-1543-32-3.9-pydebug/home/aixtools/python/cpython-master/Modules/_ssl.o -L/opt/freeware/lib -lssl -lcrypto -o build/lib.aix-7200-1543-32-3.9-pydebug/_ssl.so
ld: 0711-317 ERROR: Undefined symbol: .SSL_SESSION_get_ticket_lifetime_hint
ld: 0711-317 ERROR: Undefined symbol: .SSL_SESSION_has_ticket
ld: 0711-317 ERROR: Undefined symbol: .SSL_session_reused
ld: 0711-317 ERROR: Undefined symbol: .COMP_get_type
ld: 0711-317 ERROR: Undefined symbol: .SSL_is_init_finished
ld: 0711-317 ERROR: Undefined symbol: .SSL_CTX_get_options
ld: 0711-317 ERROR: Undefined symbol: .SSL_CTX_clear_options
ld: 0711-317 ERROR: Undefined symbol: .SSL_CTX_set_options
ld: 0711-317 ERROR: Undefined symbol: .SSL_CIPHER_is_aead
ld: 0711-317 ERROR: Undefined symbol: .SSL_CIPHER_get_cipher_nid
ld: 0711-317 ERROR: Undefined symbol: .SSL_CIPHER_get_digest_nid
ld: 0711-317 ERROR: Undefined symbol: .SSL_CIPHER_get_kx_nid
ld: 0711-317 ERROR: Undefined symbol: .SSL_CIPHER_get_auth_nid
ld: 0711-317 ERROR: Undefined symbol: .X509_STORE_get0_objects
ld: 0711-317 ERROR: Undefined symbol: .X509_OBJECT_get0_X509
ld: 0711-317 ERROR: Undefined symbol: .OPENSSL_sk_num
ld: 0711-317 ERROR: Undefined symbol: .OPENSSL_sk_value
ld: 0711-317 ERROR: Undefined symbol: .X509_OBJECT_get_type
ld: 0711-317 ERROR: Undefined symbol: .X509_NAME_ENTRY_set
ld: 0711-317 ERROR: Undefined symbol: .SSL_CTX_get_default_passwd_cb
ld: 0711-317 ERROR: Undefined symbol: .SSL_CTX_get_default_passwd_cb_userdata
ld: 0711-317 ERROR: Undefined symbol: .OpenSSL_version_num
ld: 0711-317 ERROR: Undefined symbol: .TLS_method
ld: 0711-317 ERROR: Undefined symbol: .TLS_client_method
ld: 0711-317 ERROR: Undefined symbol: .TLS_server_method
ld: 0711-317 ERROR: Undefined symbol: .BIO_up_ref
ld: 0711-317 ERROR: Undefined symbol: .OPENSSL_sk_pop_free
ld: 0711-317 ERROR: Undefined symbol: .X509_get_version
ld: 0711-317 ERROR: Undefined symbol: .X509_getm_notBefore
ld: 0711-317 ERROR: Undefined symbol: .X509_getm_notAfter
ld: 0711-317 ERROR: Undefined symbol: .OpenSSL_version
ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information.

$ lslpp -L | grep openssl
  aixtools.openssl.rte      1.0.2.16    C     F    aixtools openssl 27-Aug-2018
  openssl.base             1.0.1.515    CE    F    Open Secure Socket Layer
  openssl.man.en_US        1.0.1.515    C     F    Open Secure Socket Layer
  openssl          1.1.0g-1withsslv2    C     R    Secure Sockets Layer and
  openssl-devel    1.1.0g-1withsslv2    C     R    Secure Sockets Layer and

+++ FYI +++
IBM AIX used some strange version numbers: 1.0.1.515 is actually an OpenSSL 1.0.2 ABI version.

The "aixtools" fileset is 1.0.2p (p == 16th character of alphabet).

In any case - the test for X509_VERIFY_PARAM_set1_host() has been passing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39953>
_______________________________________

From report at bugs.python.org  Wed Apr 15 09:50:07 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 15 Apr 2020 13:50:07 +0000
Subject: [issue40268] Reorganize pycore_pystate.h header
In-Reply-To: <1586732467.85.0.974458317268.issue40268@roundup.psfhosted.org>
Message-ID: <1586958607.0.0.0698720378269.issue40268@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> It exposes too many internals whereas most consumers only need basic functions like _PyThreadState_GET().

That's basically done: pycore_pystate.h no longer defines PyInterpreterState structure. pycore_interp.h must now be included explicitly. It's now included by the following files:

* Modules/gcmodule.c
* Modules/_io/textio.c
* Modules/main.c
* Modules/_threadmodule.c
* Objects/codeobject.c
* Objects/interpreteridobject.c
* Objects/longobject.c
* Objects/moduleobject.c
* Objects/unicodeobject.c
* Parser/listnode.c
* Python/codecs.c
* Python/dynload_shlib.c
* Python/import.c
* Python/initconfig.c
* Python/pythonrun.c
* Python/_warnings.c

I also pushed many cleanup changes. I think that it's now enough, I close the issue ;-)

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40268>
_______________________________________

From report at bugs.python.org  Wed Apr 15 09:56:13 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Wed, 15 Apr 2020 13:56:13 +0000
Subject: [issue40288] atexit module should not be loaded more than once per
 interpreter
In-Reply-To: <1586917009.7.0.806642420762.issue40288@roundup.psfhosted.org>
Message-ID: <1586958973.98.0.200946704638.issue40288@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

I will take a look :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40288>
_______________________________________

From report at bugs.python.org  Wed Apr 15 09:58:12 2020
From: report at bugs.python.org (Carl Meyer)
Date: Wed, 15 Apr 2020 13:58:12 +0000
Subject: [issue40255] Fixing Copy on Writes from reference counting
In-Reply-To: <1586619621.82.0.553262088399.issue40255@roundup.psfhosted.org>
Message-ID: <1586959092.06.0.90623757013.issue40255@roundup.psfhosted.org>


Carl Meyer <carl at oddbird.net> added the comment:

> Is it a common use case to load big data and then fork to use preloaded data?

A lot of the "big data" in question here is simply lots of Python module/class/code objects resulting from importing lots of Python modules.

And yes, this "pre-fork" model is extremely common for serving Python web applications; it is the way most Python web application servers work. We already have an example in this thread of another large Python web application (YouTube) that had similar needs and considered a similar approach.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40255>
_______________________________________

From report at bugs.python.org  Wed Apr 15 10:05:23 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 15 Apr 2020 14:05:23 +0000
Subject: [issue40255] Fixing Copy on Writes from reference counting
In-Reply-To: <1586619621.82.0.553262088399.issue40255@roundup.psfhosted.org>
Message-ID: <1586959523.61.0.538269311929.issue40255@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Carl:
> A lot of the "big data" in question here is simply lots of Python module/class/code objects resulting from importing lots of Python modules.
>
> And yes, this "pre-fork" model is extremely common for serving Python web applications; it is the way most Python web application servers work. (...)

I would be interested to hear the answer to Antoine's question which is basically: why not using the multiprocessing fork server?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40255>
_______________________________________

From report at bugs.python.org  Wed Apr 15 10:23:58 2020
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 15 Apr 2020 14:23:58 +0000
Subject: [issue40255] Fixing Copy on Writes from reference counting
In-Reply-To: <1586619621.82.0.553262088399.issue40255@roundup.psfhosted.org>
Message-ID: <1586960638.99.0.114744451799.issue40255@roundup.psfhosted.org>


Antoine Pitrou <solipsis at pitrou.net> added the comment:

I'll note that this "extremely common" model can break as soon as you have hidden worker threads somewhere (this can happen in a third-party library).

For example, the libhdfs library is not fork-safe.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40255>
_______________________________________

From report at bugs.python.org  Wed Apr 15 10:30:16 2020
From: report at bugs.python.org (hai shi)
Date: Wed, 15 Apr 2020 14:30:16 +0000
Subject: [issue40170] [C API] Make PyTypeObject structure an opaque structure
 in the public C API
In-Reply-To: <1585915023.07.0.846808236133.issue40170@roundup.psfhosted.org>
Message-ID: <1586961016.56.0.418832450725.issue40170@roundup.psfhosted.org>


hai shi <shihai1991 at 126.com> added the comment:

> Py_TRASHCAN_BEGIN() access directly PyTypeObject.tp_dealloc

Looks like this macro not recorded in docs. Do we need using function to replace this macro?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40170>
_______________________________________

From report at bugs.python.org  Wed Apr 15 10:34:39 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 15 Apr 2020 14:34:39 +0000
Subject: [issue40170] [C API] Make PyTypeObject structure an opaque structure
 in the public C API
In-Reply-To: <1585915023.07.0.846808236133.issue40170@roundup.psfhosted.org>
Message-ID: <1586961279.19.0.180544485477.issue40170@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> Looks like this macro not recorded in docs.

It never prevented anyone to use a function of the C API :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40170>
_______________________________________

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: [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 11:12:55 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 15 Apr 2020 15:12:55 +0000
Subject: [issue40286] Add randbytes() method to random.Random
In-Reply-To: <1586903418.02.0.530735802731.issue40286@roundup.psfhosted.org>
Message-ID: <1586963575.77.0.234708410242.issue40286@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

All Random methods give the same result independently of endianess and bitness of the platform.

> I don't think that these two implementations give the same result on big and little endian.

The second one does.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40286>
_______________________________________

From report at bugs.python.org  Wed Apr 15 11:20:43 2020
From: report at bugs.python.org (Steve Dower)
Date: Wed, 15 Apr 2020 15:20:43 +0000
Subject: [issue40293] cpython-source-deps project missing release for libffi
 commits
In-Reply-To: <1586962962.85.0.815414541497.issue40293@roundup.psfhosted.org>
Message-ID: <1586964043.42.0.652766412417.issue40293@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

In master, we build against the latest build out of that repo, which comes from the libffi branch (not the 3.3.0 RC).

In 3.8 (and 3.7? I forget) we use the 3.3.0 RC build. There's no later release from libffi (last I checked), and no important fixes since then (only ARM64 support, which we contributed).

We'll probably tag for 3.9.0b1 and retarget the master branch to take that one, so that we can control updates that go into that release. But right now there isn't anything we want to tag right now (and GitHub generates the tarball itself, so we don't have to upload anything - you can get the branch tip through the "Download" button on the front page).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40293>
_______________________________________

From report at bugs.python.org  Wed Apr 15 11:23:10 2020
From: report at bugs.python.org (Steve Dower)
Date: Wed, 15 Apr 2020 15:23:10 +0000
Subject: [issue40293] cpython-source-deps project missing release for libffi
 commits
In-Reply-To: <1586962962.85.0.815414541497.issue40293@roundup.psfhosted.org>
Message-ID: <1586964190.16.0.553797245068.issue40293@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

To save the clicks, here's the URL that will get the latest sources from the libffi branch: https://github.com/python/cpython-source-deps/archive/libffi.zip

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40293>
_______________________________________

From report at bugs.python.org  Wed Apr 15 11:35:16 2020
From: report at bugs.python.org (hai shi)
Date: Wed, 15 Apr 2020 15:35:16 +0000
Subject: [issue40170] [C API] Make PyTypeObject structure an opaque structure
 in the public C API
In-Reply-To: <1585915023.07.0.846808236133.issue40170@roundup.psfhosted.org>
Message-ID: <1586964916.1.0.569742192572.issue40170@roundup.psfhosted.org>


Change by hai shi <shihai1991 at 126.com>:


----------
pull_requests: +18889
pull_request: https://github.com/python/cpython/pull/19541

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40170>
_______________________________________

From report at bugs.python.org  Wed Apr 15 11:53:32 2020
From: report at bugs.python.org (SilentGhost)
Date: Wed, 15 Apr 2020 15:53:32 +0000
Subject: [issue39953] Let's update ssl error codes
In-Reply-To: <1584072470.83.0.437860249809.issue39953@roundup.psfhosted.org>
Message-ID: <1586966012.06.0.705872450565.issue39953@roundup.psfhosted.org>


SilentGhost <ghost.adh at runbox.com> added the comment:

Michael, could you try with the latest fix in 584a3cfda4?

----------
nosy: +SilentGhost

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39953>
_______________________________________

From report at bugs.python.org  Wed Apr 15 12:16:59 2020
From: report at bugs.python.org (Gregory Szorc)
Date: Wed, 15 Apr 2020 16:16:59 +0000
Subject: [issue40293] cpython-source-deps project missing release for libffi
 commits
In-Reply-To: <1586962962.85.0.815414541497.issue40293@roundup.psfhosted.org>
Message-ID: <1586967419.15.0.969294104346.issue40293@roundup.psfhosted.org>


Gregory Szorc <gregory.szorc at gmail.com> added the comment:

I don't like utilizing the dynamic archive links like https://github.com/python/cpython-source-deps/archive/libffi.zip (even if you pin the commit) because GitHub does not guarantee the file content is deterministic over time. I perform SHA-256 validation of all dependencies I download from the Internet. And if I rely on the /archive/ URLs, all it takes is GitHub updating some library that subtly changes the tar/zip structure and my hashes are invalidated.

Release artifacts are immutable and don't have this problem.

As it stands, I will likely `git clone` and check out the commit I need. Although I would prefer a release artifact.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40293>
_______________________________________

From report at bugs.python.org  Wed Apr 15 08:30:28 2020
From: report at bugs.python.org (Michael Felt)
Date: Wed, 15 Apr 2020 12:30:28 +0000
Subject: [issue40244] AIX: build: _PyObject_GC_TRACK Asstertion failure
In-Reply-To: <dcd1179a-2eef-c5cf-096a-fc0f47104788@felt.demon.nl>
Message-ID: <51733e34-ee9d-f6d4-f740-857bce144701@felt.demon.nl>


Michael Felt <aixtools at felt.demon.nl> added the comment:

On 15/04/2020 11:03, Michael Felt wrote:
> Michael Felt <aixtools at felt.demon.nl> added the comment:
>
> On 14/04/2020 19:28, Michael Felt wrote:
>> Michael Felt <aixtools at felt.demon.nl> added the comment:
>>
>> On 14/04/2020 14:54, Batuhan Taskaya wrote:
>>> Batuhan Taskaya <batuhanosmantaskaya at gmail.com> added the comment:
>>>
>>>> With the print statements - it does not crash:
>>> I think this isn't directly relevant with prints but about re-compiling? (just guessing).
>> I only recompiled the one .c file. With that one file re-compiled -
>> wqith fprintf statements it succeeds, restore the original .c file (git
>> checkout -- Objects/whatever.c; make - it fails.
>>
>> Tomorrow I'll search for the option(s) needed to get (complete) assembly
>> code listing and try to see (and understand) the difference between what
>> xlc-v13 and xlc-v16 makes. And, what I shall also test - is to recompile
>> only this one file using xlc-v13 and see if the make then proceeds normally.
>>
>>
> Many pages of output - and I confess - I do have some difficulty reading
> code every now and then.
>
> As the "bug" wherever it may be is related, I am guessing, to compiler
> optimization and how to deal with routines with "no return".
>
> Trying to understand the listings - I ran across:
>
> ./Include/object.h:typedef void (*destructor)(PyObject *);
>
> Could the error be related to compilers confusing a routine with no
> return, versus a routine returning a pointer to a "void"?

Although I as I think about it I believe the statement is correct:
"destructor" is a typedef of a pointer to a function (with an argument
of PyObject *) that has no_return (aka == void).

Sigh.

Instead. The two listings: note, they are practically identical for the
first 60 pages (aka skip to 'Page 61')

>
> recall the code:
>
> static void
> gen_dealloc(PyGenObject *gen)
>
> Comments?
>
> Michael
>
>> As Victor commented earlier - very much looking like a compiler bug.
>> That said, still do not know what to say/write to software support as a
>> complaint.
>>
>>> ----------
>>>
>>> _______________________________________
>>> Python tracker <report at bugs.python.org>
>>> <https://bugs.python.org/issue40244>
>>> _______________________________________
>>>
>> ----------
>>
>> _______________________________________
>> Python tracker <report at bugs.python.org>
>> <https://bugs.python.org/issue40244>
>> _______________________________________
>>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue40244>
> _______________________________________
>

----------
Added file: https://bugs.python.org/file49063/genobject-combined.lst

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40244>
_______________________________________
-------------- next part --------------


Wed Apr 15 07:30:04 CDT 2020  Page 1


IBM XL C for AIX, Version 13.1.3.4 Objects/genobject.c 04/15/20 03:35:33 (C)                                                                                    IBM XL C for AIX, Version 16.1.0.3 Objects/genobject.c 04/15/20 03:29:57 (C)

>>>>> SOURCE SECTION <<<<<                                                                                                                                      >>>>> SOURCE SECTION <<<<<

        1 | /* Generator object implementation */                                                                                                                       1 | /* Generator object implementation */
        2 |                                                                                                                                                             2 |
        3 | #include "Python.h"                                                                                                                                         3 | #include "Python.h"
"./Include/pyport.h", line 4.48: 1506-457 (I) File /home/aixtools/python/cpython-master/./pyconfig.h has already been included.                                 "./Include/pyport.h", line 4.48: 1506-457 (I) File /home/aixtools/python/cpython-master/./pyconfig.h has already been included.
"./Include/pyport.h", line 199.20: 1506-457 (I) File /opt/IBM/xlc/13.1.3/include/stdlib.h has already been included.                                            "./Include/pyport.h", line 199.20: 1506-457 (I) File /opt/IBM/xlc/16.1.0/include/stdlib.h has already been included.
"./Include/pyport.h", line 212.22: 1506-457 (I) File /usr/include/sys/time.h has already been included.                                                         "./Include/pyport.h", line 212.22: 1506-457 (I) File /usr/include/sys/time.h has already been included.
"./Include/pyport.h", line 238.22: 1506-457 (I) File /usr/include/sys/stat.h has already been included.                                                         "./Include/pyport.h", line 238.22: 1506-457 (I) File /usr/include/sys/stat.h has already been included.
"./Include/pymath.h", line 4.48: 1506-457 (I) File /home/aixtools/python/cpython-master/./pyconfig.h has already been included.                                 "./Include/pymath.h", line 4.48: 1506-457 (I) File /home/aixtools/python/cpython-master/./pyconfig.h has already been included.
"./Include/pytime.h", line 5.48: 1506-457 (I) File /home/aixtools/python/cpython-master/./pyconfig.h has already been included.                                 "./Include/pytime.h", line 5.48: 1506-457 (I) File /home/aixtools/python/cpython-master/./pyconfig.h has already been included.
"./Include/object.h", line 628.12: 1506-495 (I) Pointer type conversion found.                                                                                  "./Include/object.h", line 628.12: 1506-495 (I) Pointer type conversion found.
"./Include/object.h", line 628.12: 1506-374 (I) Pointer types "const struct _object*" and "struct _object*" are not compatible.                                 "./Include/object.h", line 628.12: 1506-374 (I) Pointer types "const struct _object*" and "struct _object*" are not compatible.
"./Include/pytime.h", line 98.21: 1506-492 (I) Redefinition of round hides previous definition.                                                                 "./Include/pytime.h", line 98.21: 1506-492 (I) Redefinition of round hides previous definition.
"./Include/pytime.h", line 104.21: 1506-492 (I) Redefinition of round hides previous definition.                                                                "./Include/pytime.h", line 104.21: 1506-492 (I) Redefinition of round hides previous definition.
"./Include/pytime.h", line 111.21: 1506-492 (I) Redefinition of round hides previous definition.                                                                "./Include/pytime.h", line 111.21: 1506-492 (I) Redefinition of round hides previous definition.
"./Include/pytime.h", line 115.21: 1506-492 (I) Redefinition of round hides previous definition.                                                                "./Include/pytime.h", line 115.21: 1506-492 (I) Redefinition of round hides previous definition.
"./Include/pytime.h", line 131.21: 1506-492 (I) Redefinition of round hides previous definition.                                                                "./Include/pytime.h", line 131.21: 1506-492 (I) Redefinition of round hides previous definition.
"./Include/pytime.h", line 136.21: 1506-492 (I) Redefinition of round hides previous definition.                                                                "./Include/pytime.h", line 136.21: 1506-492 (I) Redefinition of round hides previous definition.
"./Include/pytime.h", line 148.21: 1506-492 (I) Redefinition of round hides previous definition.                                                                "./Include/pytime.h", line 148.21: 1506-492 (I) Redefinition of round hides previous definition.
"./Include/pytime.h", line 165.15: 1506-492 (I) Redefinition of div hides previous definition.                                                                  "./Include/pytime.h", line 165.15: 1506-492 (I) Redefinition of div hides previous definition.
"./Include/pymem.h", line 8.20: 1506-457 (I) File /home/aixtools/python/cpython-master/./Include/pyport.h has already been included.                            "./Include/pymem.h", line 8.20: 1506-457 (I) File /home/aixtools/python/cpython-master/./Include/pyport.h has already been included.
"./Include/Python.h", line 88.20: 1506-457 (I) File /home/aixtools/python/cpython-master/./Include/object.h has already been included.                          "./Include/Python.h", line 88.20: 1506-457 (I) File /home/aixtools/python/cpython-master/./Include/object.h has already been included.
"./Include/objimpl.h", line 8.19: 1506-457 (I) File /home/aixtools/python/cpython-master/./Include/pymem.h has already been included.                           "./Include/objimpl.h", line 8.19: 1506-457 (I) File /home/aixtools/python/cpython-master/./Include/pymem.h has already been included.
"./Include/cpython/objimpl.h", line 70.9: 1506-495 (I) Pointer type conversion found.                                                                           "./Include/cpython/objimpl.h", line 70.9: 1506-495 (I) Pointer type conversion found.
"./Include/cpython/objimpl.h", line 70.9: 1506-374 (I) Pointer types "struct _object*" and "struct _typeobject*" are not compatible.                            "./Include/cpython/objimpl.h", line 70.9: 1506-374 (I) Pointer types "struct _object*" and "struct _typeobject*" are not compatible.
"./Include/cpython/objimpl.h", line 84.5: 1506-495 (I) Pointer type conversion found.                                                                           "./Include/cpython/objimpl.h", line 84.5: 1506-495 (I) Pointer type conversion found.
"./Include/cpython/objimpl.h", line 84.5: 1506-374 (I) Pointer types "struct _object*" and "struct {...}*" are not compatible.                                  "./Include/cpython/objimpl.h", line 84.5: 1506-374 (I) Pointer types "struct _object*" and "struct {...}*" are not compatible.
"./Include/typeslots.h", line 3.8: 1506-290 (I) Unknown macro name Py_bf_getbuffer on #undef directive.                                                         "./Include/typeslots.h", line 3.8: 1506-290 (I) Unknown macro name Py_bf_getbuffer on #undef directive.
"./Include/typeslots.h", line 4.8: 1506-290 (I) Unknown macro name Py_bf_releasebuffer on #undef directive.                                                     "./Include/typeslots.h", line 4.8: 1506-290 (I) Unknown macro name Py_bf_releasebuffer on #undef directive.
"./Include/bytesobject.h", line 10.20: 1506-457 (I) File /opt/IBM/xlc/13.1.3/include/stdarg.h has already been included.                                        "./Include/bytesobject.h", line 10.20: 1506-457 (I) File /opt/IBM/xlc/16.1.0/include/stdarg.h has already been included.
"./Include/unicodeobject.h", line 4.20: 1506-457 (I) File /opt/IBM/xlc/13.1.3/include/stdarg.h has already been included.                                       "./Include/unicodeobject.h", line 4.20: 1506-457 (I) File /opt/IBM/xlc/16.1.0/include/stdarg.h has already been included.
"./Include/unicodeobject.h", line 186.16: 1506-492 (I) Redefinition of index hides previous definition.                                                         "./Include/unicodeobject.h", line 186.16: 1506-492 (I) Redefinition of index hides previous definition.
"./Include/unicodeobject.h", line 196.16: 1506-492 (I) Redefinition of index hides previous definition.                                                         "./Include/unicodeobject.h", line 196.16: 1506-492 (I) Redefinition of index hides previous definition.
"./Include/pycapsule.h", line 31.26: 1506-492 (I) Redefinition of destructor hides previous definition.                                                         "./Include/pycapsule.h", line 31.26: 1506-492 (I) Redefinition of destructor hides previous definition.
"./Include/pycapsule.h", line 45.81: 1506-492 (I) Redefinition of destructor hides previous definition.                                                         "./Include/pycapsule.h", line 45.81: 1506-492 (I) Redefinition of destructor hides previous definition.
"./Include/cpython/initconfig.h", line 41.16: 1506-492 (I) Redefinition of index hides previous definition.                                                     "./Include/cpython/initconfig.h", line 41.16: 1506-492 (I) Redefinition of index hides previous definition.
"./Include/pyerrors.h", line 324.20: 1506-457 (I) File /opt/IBM/xlc/13.1.3/include/stdarg.h has already been included.                                          "./Include/pyerrors.h", line 324.20: 1506-457 (I) File /opt/IBM/xlc/16.1.0/include/stdarg.h has already been included.
"./Include/Python.h", line 133.32: 1506-457 (I) File /home/aixtools/python/cpython-master/./Include/cpython/initconfig.h has already been included.             "./Include/Python.h", line 133.32: 1506-457 (I) File /home/aixtools/python/cpython-master/./Include/cpython/initconfig.h has already been included.
"./Include/Python.h", line 134.21: 1506-457 (I) File /home/aixtools/python/cpython-master/./Include/pystate.h has already been included.                        "./Include/Python.h", line 134.21: 1506-457 (I) File /home/aixtools/python/cpython-master/./Include/pystate.h has already been included.
"./Include/modsupport.h", line 10.20: 1506-457 (I) File /opt/IBM/xlc/13.1.3/include/stdarg.h has already been included.                                         "./Include/modsupport.h", line 10.20: 1506-457 (I) File /opt/IBM/xlc/16.1.0/include/stdarg.h has already been included.
"./Include/code.h", line 170.61: 1506-492 (I) Redefinition of index hides previous definition.                                                                  "./Include/code.h", line 170.61: 1506-492 (I) Redefinition of index hides previous definition.
"./Include/code.h", line 172.61: 1506-492 (I) Redefinition of index hides previous definition.                                                                  "./Include/code.h", line 172.61: 1506-492 (I) Redefinition of index hides previous definition.
"./Include/abstract.h", line 281.8: 1506-290 (I) Unknown macro name PyObject_Length on #undef directive.                                                        "./Include/abstract.h", line 281.8: 1506-290 (I) Unknown macro name PyObject_Length on #undef directive.
"./Include/abstract.h", line 626.8: 1506-290 (I) Unknown macro name PySequence_Length on #undef directive.                                                      "./Include/abstract.h", line 626.8: 1506-290 (I) Unknown macro name PySequence_Length on #undef directive.
"./Include/abstract.h", line 724.8: 1506-290 (I) Unknown macro name PySequence_In on #undef directive.                                                          "./Include/abstract.h", line 724.8: 1506-290 (I) Unknown macro name PySequence_In on #undef directive.
"./Include/abstract.h", line 769.8: 1506-290 (I) Unknown macro name PyMapping_Length on #undef directive.                                                       "./Include/abstract.h", line 769.8: 1506-290 (I) Unknown macro name PyMapping_Length on #undef directive.
"./Include/cpython/abstract.h", line 80.30: 1506-495 (I) Pointer type conversion found.                                                                         "./Include/cpython/abstract.h", line 80.30: 1506-495 (I) Pointer type conversion found.
"./Include/cpython/abstract.h", line 80.30: 1506-374 (I) Pointer types "char*" and "struct _object*" are not compatible.                                        "./Include/cpython/abstract.h", line 80.30: 1506-374 (I) Pointer types "char*" and "struct _object*" are not compatible.
"./Include/cpython/abstract.h", line 80.11: 1506-495 (I) Pointer type conversion found.                                                                         "./Include/cpython/abstract.h", line 80.11: 1506-495 (I) Pointer type conversion found.
"./Include/cpython/abstract.h", line 80.11: 1506-374 (I) Pointer types "struct _object*(**)(struct _object*,struct _object* const*,unsigned long,struct _object "./Include/cpython/abstract.h", line 80.11: 1506-374 (I) Pointer types "struct _object*(**)(struct _object*,struct _object* const*,unsigned long,struct _object
"./Include/cpython/abstract.h", line 82.1: 1506-412 (I) Referenced variable "ptr", which was not initialized in its declaration.                                "./Include/cpython/abstract.h", line 82.1: 1506-412 (I) Referenced variable "ptr", which was not initialized in its declaration.
"./Include/cpython/abstract.h", line 82.1: 1506-412 (I) Referenced variable "offset", which was not initialized in its declaration.                             "./Include/cpython/abstract.h", line 82.1: 1506-412 (I) Referenced variable "offset", which was not initialized in its declaration.
"./Include/cpython/abstract.h", line 82.1: 1506-412 (I) Referenced variable "tp", which was not initialized in its declaration.                                 "./Include/cpython/abstract.h", line 82.1: 1506-412 (I) Referenced variable "tp", which was not initialized in its declaration.







Wed Apr 15 07:30:04 CDT 2020  Page 2


"./Include/cpython/abstract.h", line 120.1: 1506-412 (I) Referenced variable "res", which was not initialized in its declaration.                               "./Include/cpython/abstract.h", line 120.1: 1506-412 (I) Referenced variable "res", which was not initialized in its declaration.
"./Include/cpython/abstract.h", line 120.1: 1506-412 (I) Referenced variable "func", which was not initialized in its declaration.                              "./Include/cpython/abstract.h", line 120.1: 1506-412 (I) Referenced variable "func", which was not initialized in its declaration.
"./Include/cpython/abstract.h", line 189.1: 1506-412 (I) Referenced variable "nargsf", which was not initialized in its declaration.                            "./Include/cpython/abstract.h", line 189.1: 1506-412 (I) Referenced variable "nargsf", which was not initialized in its declaration.
"./Include/cpython/abstract.h", line 189.1: 1506-412 (I) Referenced variable "tstate", which was not initialized in its declaration.                            "./Include/cpython/abstract.h", line 189.1: 1506-412 (I) Referenced variable "tstate", which was not initialized in its declaration.
"./Include/cpython/abstract.h", line 189.1: 1506-412 (I) Referenced variable "args", which was not initialized in its declaration.                              "./Include/cpython/abstract.h", line 189.1: 1506-412 (I) Referenced variable "args", which was not initialized in its declaration.
"./Include/cpython/abstract.h", line 189.1: 1506-412 (I) Referenced variable "_args", which was not initialized in its declaration.                             "./Include/cpython/abstract.h", line 189.1: 1506-412 (I) Referenced variable "_args", which was not initialized in its declaration.
"./Include/cpython/abstract.h", line 374.60: 1506-492 (I) Redefinition of index hides previous definition.                                                      "./Include/cpython/abstract.h", line 374.60: 1506-492 (I) Redefinition of index hides previous definition.
"./Include/cpython/abstract.h", line 376.60: 1506-492 (I) Redefinition of index hides previous definition.                                                      "./Include/cpython/abstract.h", line 376.60: 1506-492 (I) Redefinition of index hides previous definition.
        4 | #include "pycore_ceval.h"   /* _PyEval_EvalFrame() */                                                                                                       4 | #include "pycore_ceval.h"   /* _PyEval_EvalFrame() */
"./Include/internal/pycore_atomic.h", line 12.22: 1506-457 (I) File /home/aixtools/python/cpython-master/./pyconfig.h has already been included.                "./Include/internal/pycore_atomic.h", line 12.22: 1506-457 (I) File /home/aixtools/python/cpython-master/./pyconfig.h has already been included.
"./Include/internal/pycore_gil.h", line 11.55: 1506-457 (I) File /home/aixtools/python/cpython-master/./Include/internal/pycore_atomic.h has already been inclu "./Include/internal/pycore_gil.h", line 11.55: 1506-457 (I) File /home/aixtools/python/cpython-master/./Include/internal/pycore_atomic.h has already been inclu
"./Include/internal/pycore_condvar.h", line 23.21: 1506-457 (I) File /usr/include/pthread.h has already been included.                                          "./Include/internal/pycore_condvar.h", line 23.21: 1506-457 (I) File /usr/include/pthread.h has already been included.
"./Include/internal/pycore_gil.h", line 20.8: 1506-290 (I) Unknown macro name FORCE_SWITCHING on #undef directive.                                              "./Include/internal/pycore_gil.h", line 20.8: 1506-290 (I) Unknown macro name FORCE_SWITCHING on #undef directive.
"./Include/internal/pycore_pymem.h", line 11.46: 1506-457 (I) File /home/aixtools/python/cpython-master/./Include/pymem.h has already been included.            "./Include/internal/pycore_pymem.h", line 11.46: 1506-457 (I) File /home/aixtools/python/cpython-master/./Include/pymem.h has already been included.
"./Include/internal/pycore_runtime.h", line 11.55: 1506-457 (I) File /home/aixtools/python/cpython-master/./Include/internal/pycore_atomic.h has already been i "./Include/internal/pycore_runtime.h", line 11.55: 1506-457 (I) File /home/aixtools/python/cpython-master/./Include/internal/pycore_atomic.h has already been i
"./Include/internal/pycore_runtime.h", line 12.59: 1506-457 (I) File /home/aixtools/python/cpython-master/./Include/internal/pycore_gil.h has already been incl "./Include/internal/pycore_runtime.h", line 12.59: 1506-457 (I) File /home/aixtools/python/cpython-master/./Include/internal/pycore_gil.h has already been incl
"./Include/internal/pycore_ceval.h", line 106.9: 1506-434 (I) The left-hand side of a bitwise right shift expression has a signed promoted type.                "./Include/internal/pycore_ceval.h", line 106.9: 1506-434 (I) The left-hand side of a bitwise right shift expression has a signed promoted type.
        5 | #include "pycore_object.h"                                                                                                                                  5 | #include "pycore_object.h"
"./Include/internal/pycore_object.h", line 11.58: 1506-457 (I) File /home/aixtools/python/cpython-master/./Include/internal/pycore_pystate.h has already been i "./Include/internal/pycore_object.h", line 11.58: 1506-457 (I) File /home/aixtools/python/cpython-master/./Include/internal/pycore_pystate.h has already been i
"./Include/internal/pycore_object.h", line 30.32: 1506-495 (I) Pointer type conversion found.                                                                   "./Include/internal/pycore_object.h", line 30.32: 1506-495 (I) Pointer type conversion found.
"./Include/internal/pycore_object.h", line 30.32: 1506-374 (I) Pointer types "struct {...}*" and "struct _object*" are not compatible.                          "./Include/internal/pycore_object.h", line 30.32: 1506-374 (I) Pointer types "struct {...}*" and "struct _object*" are not compatible.
"./Include/internal/pycore_object.h", line 34.21: 1506-495 (I) Pointer type conversion found.                                                                   "./Include/internal/pycore_object.h", line 34.21: 1506-495 (I) Pointer type conversion found.
"./Include/internal/pycore_object.h", line 34.21: 1506-374 (I) Pointer types "struct {...}*" and "struct _object*" are not compatible.                          "./Include/internal/pycore_object.h", line 34.21: 1506-374 (I) Pointer types "struct {...}*" and "struct _object*" are not compatible.
"./Include/internal/pycore_object.h", line 44.5: 1506-425 (I) The condition is always false.                                                                    "./Include/internal/pycore_object.h", line 44.5: 1506-425 (I) The condition is always false.
"./Include/internal/pycore_object.h", line 64.31: 1506-495 (I) Pointer type conversion found.                                                                   "./Include/internal/pycore_object.h", line 64.31: 1506-495 (I) Pointer type conversion found.
"./Include/internal/pycore_object.h", line 64.31: 1506-374 (I) Pointer types "struct {...}*" and "struct _object*" are not compatible.                          "./Include/internal/pycore_object.h", line 64.31: 1506-374 (I) Pointer types "struct {...}*" and "struct _object*" are not compatible.
"./Include/internal/pycore_object.h", line 68.21: 1506-495 (I) Pointer type conversion found.                                                                   "./Include/internal/pycore_object.h", line 68.21: 1506-495 (I) Pointer type conversion found.
"./Include/internal/pycore_object.h", line 68.21: 1506-374 (I) Pointer types "struct {...}*" and "struct _object*" are not compatible.                          "./Include/internal/pycore_object.h", line 68.21: 1506-374 (I) Pointer types "struct {...}*" and "struct _object*" are not compatible.
"./Include/internal/pycore_object.h", line 72.5: 1506-425 (I) The condition is always false.                                                                    "./Include/internal/pycore_object.h", line 72.5: 1506-425 (I) The condition is always false.
"./Include/internal/pycore_object.h", line 94.26: 1506-495 (I) Pointer type conversion found.                                                                   "./Include/internal/pycore_object.h", line 94.26: 1506-495 (I) Pointer type conversion found.
"./Include/internal/pycore_object.h", line 94.26: 1506-374 (I) Pointer types "char*" and "struct _object*" are not compatible.                                  "./Include/internal/pycore_object.h", line 94.26: 1506-374 (I) Pointer types "char*" and "struct _object*" are not compatible.
"./Include/internal/pycore_object.h", line 94.12: 1506-495 (I) Pointer type conversion found.                                                                   "./Include/internal/pycore_object.h", line 94.12: 1506-495 (I) Pointer type conversion found.
"./Include/internal/pycore_object.h", line 94.12: 1506-374 (I) Pointer types "struct _object**" and "char*" are not compatible.                                 "./Include/internal/pycore_object.h", line 94.12: 1506-374 (I) Pointer types "struct _object**" and "char*" are not compatible.
        6 | #include "pycore_pystate.h"                                                                                                                                 6 | #include "pycore_pystate.h"
"Objects/genobject.c", line 6.28: 1506-457 (I) File /home/aixtools/python/cpython-master/./Include/internal/pycore_pystate.h has already been included.         "Objects/genobject.c", line 6.28: 1506-457 (I) File /home/aixtools/python/cpython-master/./Include/internal/pycore_pystate.h has already been included.
        7 | #include "frameobject.h"                                                                                                                                    7 | #include "frameobject.h"
        8 | #include "structmember.h"                                                                                                                                   8 | #include "structmember.h"
"./Include/structmember.h", line 10.39: 1506-457 (I) File /usr/include/stddef.h has already been included.                                                      "./Include/structmember.h", line 10.39: 1506-457 (I) File /usr/include/stddef.h has already been included.
        9 | #include "opcode.h"                                                                                                                                         9 | #include "opcode.h"
       10 |                                                                                                                                                            10 |
       11 | static PyObject *gen_close(PyGenObject *, PyObject *);                                                                                                     11 | static PyObject *gen_close(PyGenObject *, PyObject *);
       12 | static PyObject *async_gen_asend_new(PyAsyncGenObject *, PyObject *);                                                                                      12 | static PyObject *async_gen_asend_new(PyAsyncGenObject *, PyObject *);
       13 | static PyObject *async_gen_athrow_new(PyAsyncGenObject *, PyObject *);                                                                                     13 | static PyObject *async_gen_athrow_new(PyAsyncGenObject *, PyObject *);
       14 |                                                                                                                                                            14 |
       15 | static const char *NON_INIT_CORO_MSG = "can't send non-None value to a "                                                                                   15 | static const char *NON_INIT_CORO_MSG = "can't send non-None value to a "
       16 |                                  "just-started coroutine";                                                                                                 16 |                                  "just-started coroutine";
       17 |                                                                                                                                                            17 |
       18 | static const char *ASYNC_GEN_IGNORED_EXIT_MSG =                                                                                                            18 | static const char *ASYNC_GEN_IGNORED_EXIT_MSG =
       19 |                                  "async generator ignored GeneratorExit";                                                                                  19 |                                  "async generator ignored GeneratorExit";
       20 |                                                                                                                                                            20 |
       21 | static inline int                                                                                                                                          21 | static inline int
       22 | exc_state_traverse(_PyErr_StackItem *exc_state, visitproc visit, void *arg)                                                                                22 | exc_state_traverse(_PyErr_StackItem *exc_state, visitproc visit, void *arg)
       23 | {                                                                                                                                                          23 | {
       24 |     Py_VISIT(exc_state->exc_type);                                                                                                                         24 |     Py_VISIT(exc_state->exc_type);
       24 +     do { if (exc_state->exc_type) { int vret = visit(((PyObject*)(exc_state->exc_type)), arg); if (vret) return vret; } } while (0);                       24 +     do { if (exc_state->exc_type) { int vret = visit(((PyObject*)(exc_state->exc_type)), arg); if (vret) return vret; } } while (0);
"Objects/genobject.c", line 24.5: 1506-425 (I) The condition is always false.                                                                                   "Objects/genobject.c", line 24.5: 1506-425 (I) The condition is always false.







Wed Apr 15 07:30:04 CDT 2020  Page 3


       25 |     Py_VISIT(exc_state->exc_value);                                                                                                                        25 |     Py_VISIT(exc_state->exc_value);
       25 +     do { if (exc_state->exc_value) { int vret = visit(((PyObject*)(exc_state->exc_value)), arg); if (vret) return vret; } } while (0);                     25 +     do { if (exc_state->exc_value) { int vret = visit(((PyObject*)(exc_state->exc_value)), arg); if (vret) return vret; } } while (0);
"Objects/genobject.c", line 25.5: 1506-425 (I) The condition is always false.                                                                                   "Objects/genobject.c", line 25.5: 1506-425 (I) The condition is always false.
       26 |     Py_VISIT(exc_state->exc_traceback);                                                                                                                    26 |     Py_VISIT(exc_state->exc_traceback);
       26 +     do { if (exc_state->exc_traceback) { int vret = visit(((PyObject*)(exc_state->exc_traceback)), arg); if (vret) return vret; } } while (0);             26 +     do { if (exc_state->exc_traceback) { int vret = visit(((PyObject*)(exc_state->exc_traceback)), arg); if (vret) return vret; } } while (0);
"Objects/genobject.c", line 26.5: 1506-425 (I) The condition is always false.                                                                                   "Objects/genobject.c", line 26.5: 1506-425 (I) The condition is always false.
       27 |     return 0;                                                                                                                                              27 |     return 0;
       28 | }                                                                                                                                                          28 | }
       29 |                                                                                                                                                            29 |
       30 | static int                                                                                                                                                 30 | static int
       31 | gen_traverse(PyGenObject *gen, visitproc visit, void *arg)                                                                                                 31 | gen_traverse(PyGenObject *gen, visitproc visit, void *arg)
       32 | {                                                                                                                                                          32 | {
       33 |     Py_VISIT((PyObject *)gen->gi_frame);                                                                                                                   33 |     Py_VISIT((PyObject *)gen->gi_frame);
       33 +     do { if ((PyObject *)gen->gi_frame) { int vret = visit(((PyObject*)((PyObject *)gen->gi_frame)), arg); if (vret) return vret; } } while (0);           33 +     do { if ((PyObject *)gen->gi_frame) { int vret = visit(((PyObject*)((PyObject *)gen->gi_frame)), arg); if (vret) return vret; } } while (0);
"Objects/genobject.c", line 33.14: 1506-495 (I) Pointer type conversion found.                                                                                  "Objects/genobject.c", line 33.14: 1506-495 (I) Pointer type conversion found.
"Objects/genobject.c", line 33.14: 1506-374 (I) Pointer types "struct _object*" and "struct _frame*" are not compatible.                                        "Objects/genobject.c", line 33.14: 1506-374 (I) Pointer types "struct _object*" and "struct _frame*" are not compatible.
"Objects/genobject.c", line 33.5: 1506-495 (I) Pointer type conversion found.                                                                                   "Objects/genobject.c", line 33.5: 1506-495 (I) Pointer type conversion found.
"Objects/genobject.c", line 33.5: 1506-374 (I) Pointer types "struct _object*" and "struct _frame*" are not compatible.                                         "Objects/genobject.c", line 33.5: 1506-374 (I) Pointer types "struct _object*" and "struct _frame*" are not compatible.
"Objects/genobject.c", line 33.5: 1506-425 (I) The condition is always false.                                                                                   "Objects/genobject.c", line 33.5: 1506-425 (I) The condition is always false.
       34 |     Py_VISIT(gen->gi_code);                                                                                                                                34 |     Py_VISIT(gen->gi_code);
       34 +     do { if (gen->gi_code) { int vret = visit(((PyObject*)(gen->gi_code)), arg); if (vret) return vret; } } while (0);                                     34 +     do { if (gen->gi_code) { int vret = visit(((PyObject*)(gen->gi_code)), arg); if (vret) return vret; } } while (0);
"Objects/genobject.c", line 34.5: 1506-425 (I) The condition is always false.                                                                                   "Objects/genobject.c", line 34.5: 1506-425 (I) The condition is always false.
       35 |     Py_VISIT(gen->gi_name);                                                                                                                                35 |     Py_VISIT(gen->gi_name);
       35 +     do { if (gen->gi_name) { int vret = visit(((PyObject*)(gen->gi_name)), arg); if (vret) return vret; } } while (0);                                     35 +     do { if (gen->gi_name) { int vret = visit(((PyObject*)(gen->gi_name)), arg); if (vret) return vret; } } while (0);
"Objects/genobject.c", line 35.5: 1506-425 (I) The condition is always false.                                                                                   "Objects/genobject.c", line 35.5: 1506-425 (I) The condition is always false.
       36 |     Py_VISIT(gen->gi_qualname);                                                                                                                            36 |     Py_VISIT(gen->gi_qualname);
       36 +     do { if (gen->gi_qualname) { int vret = visit(((PyObject*)(gen->gi_qualname)), arg); if (vret) return vret; } } while (0);                             36 +     do { if (gen->gi_qualname) { int vret = visit(((PyObject*)(gen->gi_qualname)), arg); if (vret) return vret; } } while (0);
"Objects/genobject.c", line 36.5: 1506-425 (I) The condition is always false.                                                                                   "Objects/genobject.c", line 36.5: 1506-425 (I) The condition is always false.
       37 |     /* No need to visit cr_origin, because it's just tuples/str/int, so can't                                                                              37 |     /* No need to visit cr_origin, because it's just tuples/str/int, so can't
       38 |        participate in a reference cycle. */                                                                                                                38 |        participate in a reference cycle. */
       39 |     return exc_state_traverse(&gen->gi_exc_state, visit, arg);                                                                                             39 |     return exc_state_traverse(&gen->gi_exc_state, visit, arg);
       40 | }                                                                                                                                                          40 | }
       41 |                                                                                                                                                            41 |
       42 | void                                                                                                                                                       42 | void
       43 | _PyGen_Finalize(PyObject *self)                                                                                                                            43 | _PyGen_Finalize(PyObject *self)
       44 | {                                                                                                                                                          44 | {
       45 |     PyGenObject *gen = (PyGenObject *)self;                                                                                                                45 |     PyGenObject *gen = (PyGenObject *)self;
"Objects/genobject.c", line 45.24: 1506-495 (I) Pointer type conversion found.                                                                                  "Objects/genobject.c", line 45.24: 1506-495 (I) Pointer type conversion found.
"Objects/genobject.c", line 45.24: 1506-374 (I) Pointer types "struct {...}*" and "struct _object*" are not compatible.                                         "Objects/genobject.c", line 45.24: 1506-374 (I) Pointer types "struct {...}*" and "struct _object*" are not compatible.
       46 |     PyObject *res = NULL;                                                                                                                                  46 |     PyObject *res = NULL;
       46 +     PyObject *res = 0;                                                                                                                                     46 +     PyObject *res = 0;
       47 |     PyObject *error_type, *error_value, *error_traceback;                                                                                                  47 |     PyObject *error_type, *error_value, *error_traceback;
       48 |                                                                                                                                                            48 |
       49 |     if (gen->gi_frame == NULL || gen->gi_frame->f_stacktop == NULL) {                                                                                      49 |     if (gen->gi_frame == NULL || gen->gi_frame->f_stacktop == NULL) {
       49 +     if (gen->gi_frame == 0 || gen->gi_frame->f_stacktop == 0) {                                                                                            49 +     if (gen->gi_frame == 0 || gen->gi_frame->f_stacktop == 0) {
       50 |         /* Generator isn't paused, so no need to close */                                                                                                  50 |         /* Generator isn't paused, so no need to close */
       51 |         return;                                                                                                                                            51 |         return;
       52 |     }                                                                                                                                                      52 |     }
       53 |                                                                                                                                                            53 |
       54 |     if (PyAsyncGen_CheckExact(self)) {                                                                                                                     54 |     if (PyAsyncGen_CheckExact(self)) {
       54 +     if (_Py_IS_TYPE(((const PyObject*)(self)), &PyAsyncGen_Type)) {                                                                                        54 +     if (_Py_IS_TYPE(((const PyObject*)(self)), &PyAsyncGen_Type)) {
"Objects/genobject.c", line 54.9: 1506-495 (I) Pointer type conversion found.                                                                                   "Objects/genobject.c", line 54.9: 1506-495 (I) Pointer type conversion found.
"Objects/genobject.c", line 54.9: 1506-374 (I) Pointer types "const struct _object*" and "struct _object*" are not compatible.                                  "Objects/genobject.c", line 54.9: 1506-374 (I) Pointer types "const struct _object*" and "struct _object*" are not compatible.
       55 |         PyAsyncGenObject *agen = (PyAsyncGenObject*)self;                                                                                                  55 |         PyAsyncGenObject *agen = (PyAsyncGenObject*)self;
"Objects/genobject.c", line 55.34: 1506-495 (I) Pointer type conversion found.                                                                                  "Objects/genobject.c", line 55.34: 1506-495 (I) Pointer type conversion found.
"Objects/genobject.c", line 55.34: 1506-374 (I) Pointer types "struct {...}*" and "struct _object*" are not compatible.                                         "Objects/genobject.c", line 55.34: 1506-374 (I) Pointer types "struct {...}*" and "struct _object*" are not compatible.







Wed Apr 15 07:30:04 CDT 2020  Page 4


       56 |         PyObject *finalizer = agen->ag_finalizer;                                                                                                          56 |         PyObject *finalizer = agen->ag_finalizer;
       57 |         if (finalizer && !agen->ag_closed) {                                                                                                               57 |         if (finalizer && !agen->ag_closed) {
       58 |             /* Save the current exception, if any. */                                                                                                      58 |             /* Save the current exception, if any. */
       59 |             PyErr_Fetch(&error_type, &error_value, &error_traceback);                                                                                      59 |             PyErr_Fetch(&error_type, &error_value, &error_traceback);
       60 |                                                                                                                                                            60 |
       61 |             res = PyObject_CallOneArg(finalizer, self);                                                                                                    61 |             res = PyObject_CallOneArg(finalizer, self);
       62 |                                                                                                                                                            62 |
       63 |             if (res == NULL) {                                                                                                                             63 |             if (res == NULL) {
       63 +             if (res == 0) {                                                                                                                                63 +             if (res == 0) {
       64 |                 PyErr_WriteUnraisable(self);                                                                                                               64 |                 PyErr_WriteUnraisable(self);
       65 |             } else {                                                                                                                                       65 |             } else {
       66 |                 Py_DECREF(res);                                                                                                                            66 |                 Py_DECREF(res);
       66 +                 _Py_DECREF("Objects/genobject.c", 66, ((PyObject*)(res)));                                                                                 66 +                 _Py_DECREF("Objects/genobject.c", 66, ((PyObject*)(res)));
       67 |             }                                                                                                                                              67 |             }
       68 |             /* Restore the saved exception. */                                                                                                             68 |             /* Restore the saved exception. */
       69 |             PyErr_Restore(error_type, error_value, error_traceback);                                                                                       69 |             PyErr_Restore(error_type, error_value, error_traceback);
       70 |             return;                                                                                                                                        70 |             return;
       71 |         }                                                                                                                                                  71 |         }
       72 |     }                                                                                                                                                      72 |     }
       73 |                                                                                                                                                            73 |
       74 |     /* Save the current exception, if any. */                                                                                                              74 |     /* Save the current exception, if any. */
       75 |     PyErr_Fetch(&error_type, &error_value, &error_traceback);                                                                                              75 |     PyErr_Fetch(&error_type, &error_value, &error_traceback);
       76 |                                                                                                                                                            76 |
       77 |     /* If `gen` is a coroutine, and if it was never awaited on,                                                                                            77 |     /* If `gen` is a coroutine, and if it was never awaited on,
       78 |        issue a RuntimeWarning. */                                                                                                                          78 |        issue a RuntimeWarning. */
       79 |     if (gen->gi_code != NULL &&                                                                                                                            79 |     if (gen->gi_code != NULL &&
       79 +     if (gen->gi_code != 0 &&                                                                                                                               79 +     if (gen->gi_code != 0 &&
       80 |         ((PyCodeObject *)gen->gi_code)->co_flags & CO_COROUTINE &&                                                                                         80 |         ((PyCodeObject *)gen->gi_code)->co_flags & CO_COROUTINE &&
       80 +         ((PyCodeObject *)gen->gi_code)->co_flags & 0x0080 &&                                                                                               80 +         ((PyCodeObject *)gen->gi_code)->co_flags & 0x0080 &&
"Objects/genobject.c", line 80.9: 1506-495 (I) Pointer type conversion found.                                                                                   "Objects/genobject.c", line 80.9: 1506-495 (I) Pointer type conversion found.
"Objects/genobject.c", line 80.9: 1506-374 (I) Pointer types "struct {...}*" and "struct _object*" are not compatible.                                          "Objects/genobject.c", line 80.9: 1506-374 (I) Pointer types "struct {...}*" and "struct _object*" are not compatible.
       81 |         gen->gi_frame->f_lasti == -1)                                                                                                                      81 |         gen->gi_frame->f_lasti == -1)
       82 |     {                                                                                                                                                      82 |     {
       83 |         _PyErr_WarnUnawaitedCoroutine((PyObject *)gen);                                                                                                    83 |         _PyErr_WarnUnawaitedCoroutine((PyObject *)gen);
"Objects/genobject.c", line 83.39: 1506-495 (I) Pointer type conversion found.                                                                                  "Objects/genobject.c", line 83.39: 1506-495 (I) Pointer type conversion found.
"Objects/genobject.c", line 83.39: 1506-374 (I) Pointer types "struct _object*" and "struct {...}*" are not compatible.                                         "Objects/genobject.c", line 83.39: 1506-374 (I) Pointer types "struct _object*" and "struct {...}*" are not compatible.
       84 |     }                                                                                                                                                      84 |     }
       85 |     else {                                                                                                                                                 85 |     else {
       86 |         res = gen_close(gen, NULL);                                                                                                                        86 |         res = gen_close(gen, NULL);
       86 +         res = gen_close(gen, 0);                                                                                                                           86 +         res = gen_close(gen, 0);
       87 |     }                                                                                                                                                      87 |     }
       88 |                                                                                                                                                            88 |
       89 |     if (res == NULL) {                                                                                                                                     89 |     if (res == NULL) {
       89 +     if (res == 0) {                                                                                                                                        89 +     if (res == 0) {
       90 |         if (PyErr_Occurred()) {                                                                                                                            90 |         if (PyErr_Occurred()) {
       91 |             PyErr_WriteUnraisable(self);                                                                                                                   91 |             PyErr_WriteUnraisable(self);
       92 |         }                                                                                                                                                  92 |         }
       93 |     }                                                                                                                                                      93 |     }
       94 |     else {                                                                                                                                                 94 |     else {
       95 |         Py_DECREF(res);                                                                                                                                    95 |         Py_DECREF(res);
       95 +         _Py_DECREF("Objects/genobject.c", 95, ((PyObject*)(res)));                                                                                         95 +         _Py_DECREF("Objects/genobject.c", 95, ((PyObject*)(res)));
       96 |     }                                                                                                                                                      96 |     }
       97 |                                                                                                                                                            97 |
       98 |     /* Restore the saved exception. */                                                                                                                     98 |     /* Restore the saved exception. */
       99 |     PyErr_Restore(error_type, error_value, error_traceback);                                                                                               99 |     PyErr_Restore(error_type, error_value, error_traceback);
      100 | }                                                                                                                                                         100 | }







Wed Apr 15 07:30:04 CDT 2020  Page 5


"Objects/genobject.c", line 100.1: 1506-412 (I) Referenced variable "error_traceback", which was not initialized in its declaration.                            "Objects/genobject.c", line 100.1: 1506-412 (I) Referenced variable "error_traceback", which was not initialized in its declaration.
"Objects/genobject.c", line 100.1: 1506-412 (I) Referenced variable "error_value", which was not initialized in its declaration.                                "Objects/genobject.c", line 100.1: 1506-412 (I) Referenced variable "error_value", which was not initialized in its declaration.
"Objects/genobject.c", line 100.1: 1506-412 (I) Referenced variable "error_type", which was not initialized in its declaration.                                 "Objects/genobject.c", line 100.1: 1506-412 (I) Referenced variable "error_type", which was not initialized in its declaration.
      101 |                                                                                                                                                           101 |
      102 | static inline void                                                                                                                                        102 | static inline void
      103 | exc_state_clear(_PyErr_StackItem *exc_state)                                                                                                              103 | exc_state_clear(_PyErr_StackItem *exc_state)
      104 | {                                                                                                                                                         104 | {
      105 |     PyObject *t, *v, *tb;                                                                                                                                 105 |     PyObject *t, *v, *tb;
      106 |     t = exc_state->exc_type;                                                                                                                              106 |     t = exc_state->exc_type;
      107 |     v = exc_state->exc_value;                                                                                                                             107 |     v = exc_state->exc_value;
      108 |     tb = exc_state->exc_traceback;                                                                                                                        108 |     tb = exc_state->exc_traceback;
      109 |     exc_state->exc_type = NULL;                                                                                                                           109 |     exc_state->exc_type = NULL;
      109 +     exc_state->exc_type = 0;                                                                                                                              109 +     exc_state->exc_type = 0;
      110 |     exc_state->exc_value = NULL;                                                                                                                          110 |     exc_state->exc_value = NULL;
      110 +     exc_state->exc_value = 0;                                                                                                                             110 +     exc_state->exc_value = 0;
      111 |     exc_state->exc_traceback = NULL;                                                                                                                      111 |     exc_state->exc_traceback = NULL;
      111 +     exc_state->exc_traceback = 0;                                                                                                                         111 +     exc_state->exc_traceback = 0;
      112 |     Py_XDECREF(t);                                                                                                                                        112 |     Py_XDECREF(t);
      112 +     _Py_XDECREF(((PyObject*)(t)));                                                                                                                        112 +     _Py_XDECREF(((PyObject*)(t)));
      113 |     Py_XDECREF(v);                                                                                                                                        113 |     Py_XDECREF(v);
      113 +     _Py_XDECREF(((PyObject*)(v)));                                                                                                                        113 +     _Py_XDECREF(((PyObject*)(v)));
      114 |     Py_XDECREF(tb);                                                                                                                                       114 |     Py_XDECREF(tb);
      114 +     _Py_XDECREF(((PyObject*)(tb)));                                                                                                                       114 +     _Py_XDECREF(((PyObject*)(tb)));
      115 | }                                                                                                                                                         115 | }
"Objects/genobject.c", line 115.1: 1506-412 (I) Referenced variable "tb", which was not initialized in its declaration.                                         "Objects/genobject.c", line 115.1: 1506-412 (I) Referenced variable "tb", which was not initialized in its declaration.
"Objects/genobject.c", line 115.1: 1506-412 (I) Referenced variable "v", which was not initialized in its declaration.                                          "Objects/genobject.c", line 115.1: 1506-412 (I) Referenced variable "v", which was not initialized in its declaration.
"Objects/genobject.c", line 115.1: 1506-412 (I) Referenced variable "t", which was not initialized in its declaration.                                          "Objects/genobject.c", line 115.1: 1506-412 (I) Referenced variable "t", which was not initialized in its declaration.
      116 |                                                                                                                                                           116 |
      117 | static void                                                                                                                                               117 | static void
      118 | gen_dealloc(PyGenObject *gen)                                                                                                                             118 | gen_dealloc(PyGenObject *gen)
      119 | {                                                                                                                                                         119 | {
      120 |     PyObject *self = (PyObject *) gen;                                                                                                                    120 |     PyObject *self = (PyObject *) gen;
"Objects/genobject.c", line 120.22: 1506-495 (I) Pointer type conversion found.                                                                                 "Objects/genobject.c", line 120.22: 1506-495 (I) Pointer type conversion found.
"Objects/genobject.c", line 120.22: 1506-374 (I) Pointer types "struct _object*" and "struct {...}*" are not compatible.                                        "Objects/genobject.c", line 120.22: 1506-374 (I) Pointer types "struct _object*" and "struct {...}*" are not compatible.
      121 |                                                                                                                                                           121 |
      122 |     _PyObject_GC_UNTRACK(gen);                                                                                                                            122 |     _PyObject_GC_UNTRACK(gen);
      122 +     _PyObject_GC_UNTRACK_impl("Objects/genobject.c", 122, ((PyObject*)(gen)));                                                                            122 +     _PyObject_GC_UNTRACK_impl("Objects/genobject.c", 122, ((PyObject*)(gen)));
"Objects/genobject.c", line 122.5: 1506-495 (I) Pointer type conversion found.                                                                                  "Objects/genobject.c", line 122.5: 1506-495 (I) Pointer type conversion found.
"Objects/genobject.c", line 122.5: 1506-374 (I) Pointer types "struct _object*" and "struct {...}*" are not compatible.                                         "Objects/genobject.c", line 122.5: 1506-374 (I) Pointer types "struct _object*" and "struct {...}*" are not compatible.
      123 |                                                                                                                                                           123 |
      124 |     if (gen->gi_weakreflist != NULL)                                                                                                                      124 |     if (gen->gi_weakreflist != NULL)
      124 +     if (gen->gi_weakreflist != 0)                                                                                                                         124 +     if (gen->gi_weakreflist != 0)
      125 |         PyObject_ClearWeakRefs(self);                                                                                                                     125 |         PyObject_ClearWeakRefs(self);
      126 |                                                                                                                                                           126 |
      127 |     _PyObject_GC_TRACK(self);                                                                                                                             127 |     _PyObject_GC_TRACK(self);
      127 +     _PyObject_GC_TRACK_impl("Objects/genobject.c", 127, ((PyObject*)(self)));                                                                             127 +     _PyObject_GC_TRACK_impl("Objects/genobject.c", 127, ((PyObject*)(self)));
      128 |                                                                                                                                                           128 |
      129 |     if (PyObject_CallFinalizerFromDealloc(self))                                                                                                          129 |     if (PyObject_CallFinalizerFromDealloc(self))
      130 |         return;                     /* resurrected.  :( */                                                                                                130 |         return;                     /* resurrected.  :( */
      131 |                                                                                                                                                           131 |
      132 |     _PyObject_GC_UNTRACK(self);                                                                                                                           132 |     _PyObject_GC_UNTRACK(self);
      132 +     _PyObject_GC_UNTRACK_impl("Objects/genobject.c", 132, ((PyObject*)(self)));                                                                           132 +     _PyObject_GC_UNTRACK_impl("Objects/genobject.c", 132, ((PyObject*)(self)));
      133 |     if (PyAsyncGen_CheckExact(gen)) {                                                                                                                     133 |     if (PyAsyncGen_CheckExact(gen)) {
      133 +     if (_Py_IS_TYPE(((const PyObject*)(gen)), &PyAsyncGen_Type)) {                                                                                        133 +     if (_Py_IS_TYPE(((const PyObject*)(gen)), &PyAsyncGen_Type)) {
"Objects/genobject.c", line 133.9: 1506-495 (I) Pointer type conversion found.                                                                                  "Objects/genobject.c", line 133.9: 1506-495 (I) Pointer type conversion found.
"Objects/genobject.c", line 133.9: 1506-374 (I) Pointer types "const struct _object*" and "struct {...}*" are not compatible.                                   "Objects/genobject.c", line 133.9: 1506-374 (I) Pointer types "const struct _object*" and "struct {...}*" are not compatible.







Wed Apr 15 07:30:04 CDT 2020  Page 6


      134 |         /* We have to handle this case for asynchronous generators                                                                                        134 |         /* We have to handle this case for asynchronous generators
      135 |            right here, because this code has to be between UNTRACK                                                                                        135 |            right here, because this code has to be between UNTRACK
      136 |            and GC_Del. */                                                                                                                                 136 |            and GC_Del. */
      137 |         Py_CLEAR(((PyAsyncGenObject*)gen)->ag_finalizer);                                                                                                 137 |         Py_CLEAR(((PyAsyncGenObject*)gen)->ag_finalizer);
      137 +         do { PyObject *_py_tmp = ((PyObject*)(((PyAsyncGenObject*)gen)->ag_finalizer)); if (_py_tmp != 0) { (((PyAsyncGenObject*)gen)->ag_finalizer       137 +         do { PyObject *_py_tmp = ((PyObject*)(((PyAsyncGenObject*)gen)->ag_finalizer)); if (_py_tmp != 0) { (((PyAsyncGenObject*)gen)->ag_finalizer
"Objects/genobject.c", line 137.18: 1506-495 (I) Pointer type conversion found.                                                                                 "Objects/genobject.c", line 137.18: 1506-495 (I) Pointer type conversion found.
"Objects/genobject.c", line 137.18: 1506-374 (I) Pointer types "struct {...}*" and "struct {...}*" are not compatible.                                          "Objects/genobject.c", line 137.18: 1506-374 (I) Pointer types "struct {...}*" and "struct {...}*" are not compatible.
"Objects/genobject.c", line 137.18: 1506-495 (I) Pointer type conversion found.                                                                                 "Objects/genobject.c", line 137.18: 1506-495 (I) Pointer type conversion found.
"Objects/genobject.c", line 137.18: 1506-374 (I) Pointer types "struct {...}*" and "struct {...}*" are not compatible.                                          "Objects/genobject.c", line 137.18: 1506-374 (I) Pointer types "struct {...}*" and "struct {...}*" are not compatible.
"Objects/genobject.c", line 137.9: 1506-425 (I) The condition is always false.                                                                                  "Objects/genobject.c", line 137.9: 1506-425 (I) The condition is always false.
      138 |     }                                                                                                                                                     138 |     }
      139 |     if (gen->gi_frame != NULL) {                                                                                                                          139 |     if (gen->gi_frame != NULL) {
      139 +     if (gen->gi_frame != 0) {                                                                                                                             139 +     if (gen->gi_frame != 0) {
      140 |         gen->gi_frame->f_gen = NULL;                                                                                                                      140 |         gen->gi_frame->f_gen = NULL;
      140 +         gen->gi_frame->f_gen = 0;                                                                                                                         140 +         gen->gi_frame->f_gen = 0;
      141 |         Py_CLEAR(gen->gi_frame);                                                                                                                          141 |         Py_CLEAR(gen->gi_frame);
      141 +         do { PyObject *_py_tmp = ((PyObject*)(gen->gi_frame)); if (_py_tmp != 0) { (gen->gi_frame) = 0; _Py_DECREF("Objects/genobject.c", 141, ((Py       141 +         do { PyObject *_py_tmp = ((PyObject*)(gen->gi_frame)); if (_py_tmp != 0) { (gen->gi_frame) = 0; _Py_DECREF("Objects/genobject.c", 141, ((Py
"Objects/genobject.c", line 141.9: 1506-495 (I) Pointer type conversion found.                                                                                  "Objects/genobject.c", line 141.9: 1506-495 (I) Pointer type conversion found.
"Objects/genobject.c", line 141.9: 1506-374 (I) Pointer types "struct _object*" and "struct _frame*" are not compatible.                                        "Objects/genobject.c", line 141.9: 1506-374 (I) Pointer types "struct _object*" and "struct _frame*" are not compatible.
"Objects/genobject.c", line 141.9: 1506-425 (I) The condition is always false.                                                                                  "Objects/genobject.c", line 141.9: 1506-425 (I) The condition is always false.
      142 |     }                                                                                                                                                     142 |     }
      143 |     if (((PyCodeObject *)gen->gi_code)->co_flags & CO_COROUTINE) {                                                                                        143 |     if (((PyCodeObject *)gen->gi_code)->co_flags & CO_COROUTINE) {
      143 +     if (((PyCodeObject *)gen->gi_code)->co_flags & 0x0080) {                                                                                              143 +     if (((PyCodeObject *)gen->gi_code)->co_flags & 0x0080) {
"Objects/genobject.c", line 143.9: 1506-495 (I) Pointer type conversion found.                                                                                  "Objects/genobject.c", line 143.9: 1506-495 (I) Pointer type conversion found.
"Objects/genobject.c", line 143.9: 1506-374 (I) Pointer types "struct {...}*" and "struct _object*" are not compatible.                                         "Objects/genobject.c", line 143.9: 1506-374 (I) Pointer types "struct {...}*" and "struct _object*" are not compatible.
      144 |         Py_CLEAR(((PyCoroObject *)gen)->cr_origin);                                                                                                       144 |         Py_CLEAR(((PyCoroObject *)gen)->cr_origin);
      144 +         do { PyObject *_py_tmp = ((PyObject*)(((PyCoroObject *)gen)->cr_origin)); if (_py_tmp != 0) { (((PyCoroObject *)gen)->cr_origin) = 0; _Py_D       144 +         do { PyObject *_py_tmp = ((PyObject*)(((PyCoroObject *)gen)->cr_origin)); if (_py_tmp != 0) { (((PyCoroObject *)gen)->cr_origin) = 0; _Py_D
"Objects/genobject.c", line 144.18: 1506-495 (I) Pointer type conversion found.                                                                                 "Objects/genobject.c", line 144.18: 1506-495 (I) Pointer type conversion found.
"Objects/genobject.c", line 144.18: 1506-374 (I) Pointer types "struct {...}*" and "struct {...}*" are not compatible.                                          "Objects/genobject.c", line 144.18: 1506-374 (I) Pointer types "struct {...}*" and "struct {...}*" are not compatible.
"Objects/genobject.c", line 144.18: 1506-495 (I) Pointer type conversion found.                                                                                 "Objects/genobject.c", line 144.18: 1506-495 (I) Pointer type conversion found.
"Objects/genobject.c", line 144.18: 1506-374 (I) Pointer types "struct {...}*" and "struct {...}*" are not compatible.                                          "Objects/genobject.c", line 144.18: 1506-374 (I) Pointer types "struct {...}*" and "struct {...}*" are not compatible.
"Objects/genobject.c", line 144.9: 1506-425 (I) The condition is always false.                                                                                  "Objects/genobject.c", line 144.9: 1506-425 (I) The condition is always false.
      145 |     }                                                                                                                                                     145 |     }
      146 |     Py_CLEAR(gen->gi_code);                                                                                                                               146 |     Py_CLEAR(gen->gi_code);
      146 +     do { PyObject *_py_tmp = ((PyObject*)(gen->gi_code)); if (_py_tmp != 0) { (gen->gi_code) = 0; _Py_DECREF("Objects/genobject.c", 146, ((PyObject       146 +     do { PyObject *_py_tmp = ((PyObject*)(gen->gi_code)); if (_py_tmp != 0) { (gen->gi_code) = 0; _Py_DECREF("Objects/genobject.c", 146, ((PyObject
"Objects/genobject.c", line 146.5: 1506-425 (I) The condition is always false.                                                                                  "Objects/genobject.c", line 146.5: 1506-425 (I) The condition is always false.
      147 |     Py_CLEAR(gen->gi_name);                                                                                                                               147 |     Py_CLEAR(gen->gi_name);
      147 +     do { PyObject *_py_tmp = ((PyObject*)(gen->gi_name)); if (_py_tmp != 0) { (gen->gi_name) = 0; _Py_DECREF("Objects/genobject.c", 147, ((PyObject       147 +     do { PyObject *_py_tmp = ((PyObject*)(gen->gi_name)); if (_py_tmp != 0) { (gen->gi_name) = 0; _Py_DECREF("Objects/genobject.c", 147, ((PyObject
"Objects/genobject.c", line 147.5: 1506-425 (I) The condition is always false.                                                                                  "Objects/genobject.c", line 147.5: 1506-425 (I) The condition is always false.
      148 |     Py_CLEAR(gen->gi_qualname);                                                                                                                           148 |     Py_CLEAR(gen->gi_qualname);
      148 +     do { PyObject *_py_tmp = ((PyObject*)(gen->gi_qualname)); if (_py_tmp != 0) { (gen->gi_qualname) = 0; _Py_DECREF("Objects/genobject.c", 148, ((       148 +     do { PyObject *_py_tmp = ((PyObject*)(gen->gi_qualname)); if (_py_tmp != 0) { (gen->gi_qualname) = 0; _Py_DECREF("Objects/genobject.c", 148, ((
"Objects/genobject.c", line 148.5: 1506-425 (I) The condition is always false.                                                                                  "Objects/genobject.c", line 148.5: 1506-425 (I) The condition is always false.
      149 |     exc_state_clear(&gen->gi_exc_state);                                                                                                                  149 |     exc_state_clear(&gen->gi_exc_state);
      150 |     PyObject_GC_Del(gen);                                                                                                                                 150 |     PyObject_GC_Del(gen);
      151 | }                                                                                                                                                         151 | }
      152 |                                                                                                                                                           152 |
      153 | static PyObject *                                                                                                                                         153 | static PyObject *
      154 | gen_send_ex(PyGenObject *gen, PyObject *arg, int exc, int closing)                                                                                        154 | gen_send_ex(PyGenObject *gen, PyObject *arg, int exc, int closing)
      155 | {                                                                                                                                                         155 | {
      156 |     PyThreadState *tstate = _PyThreadState_GET();                                                                                                         156 |     PyThreadState *tstate = _PyThreadState_GET();
      157 |     PyFrameObject *f = gen->gi_frame;                                                                                                                     157 |     PyFrameObject *f = gen->gi_frame;
      158 |     PyObject *result;                                                                                                                                     158 |     PyObject *result;
      159 |                                                                                                                                                           159 |
      160 |     if (gen->gi_running) {                                                                                                                                160 |     if (gen->gi_running) {
      161 |         const char *msg = "generator already executing";                                                                                                  161 |         const char *msg = "generator already executing";
      162 |         if (PyCoro_CheckExact(gen)) {                                                                                                                     162 |         if (PyCoro_CheckExact(gen)) {







Wed Apr 15 07:30:04 CDT 2020  Page 7


      162 +         if (_Py_IS_TYPE(((const PyObject*)(gen)), &PyCoro_Type)) {                                                                                        162 +         if (_Py_IS_TYPE(((const PyObject*)(gen)), &PyCoro_Type)) {
"Objects/genobject.c", line 162.13: 1506-495 (I) Pointer type conversion found.                                                                                 "Objects/genobject.c", line 162.13: 1506-495 (I) Pointer type conversion found.
"Objects/genobject.c", line 162.13: 1506-374 (I) Pointer types "const struct _object*" and "struct {...}*" are not compatible.                                  "Objects/genobject.c", line 162.13: 1506-374 (I) Pointer types "const struct _object*" and "struct {...}*" are not compatible.
      163 |             msg = "coroutine already executing";                                                                                                          163 |             msg = "coroutine already executing";
      164 |         }                                                                                                                                                 164 |         }
      165 |         else if (PyAsyncGen_CheckExact(gen)) {                                                                                                            165 |         else if (PyAsyncGen_CheckExact(gen)) {
      165 +         else if (_Py_IS_TYPE(((const PyObject*)(gen)), &PyAsyncGen_Type)) {                                                                               165 +         else if (_Py_IS_TYPE(((const PyObject*)(gen)), &PyAsyncGen_Type)) {
"Objects/genobject.c", line 165.18: 1506-495 (I) Pointer type conversion found.                                                                                 "Objects/genobject.c", line 165.18: 1506-495 (I) Pointer type conversion found.
"Objects/genobject.c", line 165.18: 1506-374 (I) Pointer types "const struct _object*" and "struct {...}*" are not compatible.                                  "Objects/genobject.c", line 165.18: 1506-374 (I) Pointer types "const struct _object*" and "struct {...}*" are not compatible.
      166 |             msg = "async generator already executing";                                                                                                    166 |             msg = "async generator already executing";
      167 |         }                                                                                                                                                 167 |         }
      168 |         PyErr_SetString(PyExc_ValueError, msg);                                                                                                           168 |         PyErr_SetString(PyExc_ValueError, msg);
      169 |         return NULL;                                                                                                                                      169 |         return NULL;
      169 +         return 0;                                                                                                                                         169 +         return 0;
      170 |     }                                                                                                                                                     170 |     }
      171 |     if (f == NULL || f->f_stacktop == NULL) {                                                                                                             171 |     if (f == NULL || f->f_stacktop == NULL) {
      171 +     if (f == 0 || f->f_stacktop == 0) {                                                                                                                   171 +     if (f == 0 || f->f_stacktop == 0) {
      172 |         if (PyCoro_CheckExact(gen) && !closing) {                                                                                                         172 |         if (PyCoro_CheckExact(gen) && !closing) {
      172 +         if (_Py_IS_TYPE(((const PyObject*)(gen)), &PyCoro_Type) && !closing) {                                                                            172 +         if (_Py_IS_TYPE(((const PyObject*)(gen)), &PyCoro_Type) && !closing) {
"Objects/genobject.c", line 172.13: 1506-495 (I) Pointer type conversion found.                                                                                 "Objects/genobject.c", line 172.13: 1506-495 (I) Pointer type conversion found.
"Objects/genobject.c", line 172.13: 1506-374 (I) Pointer types "const struct _object*" and "struct {...}*" are not compatible.                                  "Objects/genobject.c", line 172.13: 1506-374 (I) Pointer types "const struct _object*" and "struct {...}*" are not compatible.
      173 |             /* `gen` is an exhausted coroutine: raise an error,                                                                                           173 |             /* `gen` is an exhausted coroutine: raise an error,
      174 |                except when called from gen_close(), which should                                                                                          174 |                except when called from gen_close(), which should
      175 |                always be a silent method. */                                                                                                              175 |                always be a silent method. */
      176 |             PyErr_SetString(                                                                                                                              176 |             PyErr_SetString(
      177 |                 PyExc_RuntimeError,                                                                                                                       177 |                 PyExc_RuntimeError,
      178 |                 "cannot reuse already awaited coroutine");                                                                                                178 |                 "cannot reuse already awaited coroutine");
      179 |         }                                                                                                                                                 179 |         }
      180 |         else if (arg && !exc) {                                                                                                                           180 |         else if (arg && !exc) {
      181 |             /* `gen` is an exhausted generator:                                                                                                           181 |             /* `gen` is an exhausted generator:
      182 |                only set exception if called from send(). */                                                                                               182 |                only set exception if called from send(). */
      183 |             if (PyAsyncGen_CheckExact(gen)) {                                                                                                             183 |             if (PyAsyncGen_CheckExact(gen)) {
      183 +             if (_Py_IS_TYPE(((const PyObject*)(gen)), &PyAsyncGen_Type)) {                                                                                183 +             if (_Py_IS_TYPE(((const PyObject*)(gen)), &PyAsyncGen_Type)) {
"Objects/genobject.c", line 183.17: 1506-495 (I) Pointer type conversion found.                                                                                 "Objects/genobject.c", line 183.17: 1506-495 (I) Pointer type conversion found.
"Objects/genobject.c", line 183.17: 1506-374 (I) Pointer types "const struct _object*" and "struct {...}*" are not compatible.                                  "Objects/genobject.c", line 183.17: 1506-374 (I) Pointer types "const struct _object*" and "struct {...}*" are not compatible.
      184 |                 PyErr_SetNone(PyExc_StopAsyncIteration);                                                                                                  184 |                 PyErr_SetNone(PyExc_StopAsyncIteration);
      185 |             }                                                                                                                                             185 |             }
      186 |             else {                                                                                                                                        186 |             else {
      187 |                 PyErr_SetNone(PyExc_StopIteration);                                                                                                       187 |                 PyErr_SetNone(PyExc_StopIteration);
      188 |             }                                                                                                                                             188 |             }
      189 |         }                                                                                                                                                 189 |         }
      190 |         return NULL;                                                                                                                                      190 |         return NULL;
      190 +         return 0;                                                                                                                                         190 +         return 0;
      191 |     }                                                                                                                                                     191 |     }
      192 |                                                                                                                                                           192 |
      193 |     if (f->f_lasti == -1) {                                                                                                                               193 |     if (f->f_lasti == -1) {
      194 |         if (arg && arg != Py_None) {                                                                                                                      194 |         if (arg && arg != Py_None) {
      194 +         if (arg && arg != (&_Py_NoneStruct)) {                                                                                                            194 +         if (arg && arg != (&_Py_NoneStruct)) {
      195 |             const char *msg = "can't send non-None value to a "                                                                                           195 |             const char *msg = "can't send non-None value to a "
      196 |                               "just-started generator";                                                                                                   196 |                               "just-started generator";
      197 |             if (PyCoro_CheckExact(gen)) {                                                                                                                 197 |             if (PyCoro_CheckExact(gen)) {
      197 +             if (_Py_IS_TYPE(((const PyObject*)(gen)), &PyCoro_Type)) {                                                                                    197 +             if (_Py_IS_TYPE(((const PyObject*)(gen)), &PyCoro_Type)) {
"Objects/genobject.c", line 197.17: 1506-495 (I) Pointer type conversion found.                                                                                 "Objects/genobject.c", line 197.17: 1506-495 (I) Pointer type conversion found.
"Objects/genobject.c", line 197.17: 1506-374 (I) Pointer types "const struct _object*" and "struct {...}*" are not compatible.                                  "Objects/genobject.c", line 197.17: 1506-374 (I) Pointer types "const struct _object*" and "struct {...}*" are not compatible.
      198 |                 msg = NON_INIT_CORO_MSG;                                                                                                                  198 |                 msg = NON_INIT_CORO_MSG;
      199 |             }                                                                                                                                             199 |             }







Wed Apr 15 07:30:04 CDT 2020  Page 8


      200 |             else if (PyAsyncGen_CheckExact(gen)) {                                                                                                        200 |             else if (PyAsyncGen_CheckExact(gen)) {
      200 +             else if (_Py_IS_TYPE(((const PyObject*)(gen)), &PyAsyncGen_Type)) {                                                                           200 +             else if (_Py_IS_TYPE(((const PyObject*)(gen)), &PyAsyncGen_Type)) {
"Objects/genobject.c", line 200.22: 1506-495 (I) Pointer type conversion found.                                                                                 "Objects/genobject.c", line 200.22: 1506-495 (I) Pointer type conversion found.
"Objects/genobject.c", line 200.22: 1506-374 (I) Pointer types "const struct _object*" and "struct {...}*" are not compatible.                                  "Objects/genobject.c", line 200.22: 1506-374 (I) Pointer types "const struct _object*" and "struct {...}*" are not compatible.
      201 |                 msg = "can't send non-None value to a "                                                                                                   201 |                 msg = "can't send non-None value to a "
      202 |                       "just-started async generator";                                                                                                     202 |                       "just-started async generator";
      203 |             }                                                                                                                                             203 |             }
      204 |             PyErr_SetString(PyExc_TypeError, msg);                                                                                                        204 |             PyErr_SetString(PyExc_TypeError, msg);
      205 |             return NULL;                                                                                                                                  205 |             return NULL;
      205 +             return 0;                                                                                                                                     205 +             return 0;
      206 |         }                                                                                                                                                 206 |         }
      207 |     } else {                                                                                                                                              207 |     } else {
      208 |         /* Push arg onto the frame's value stack */                                                                                                       208 |         /* Push arg onto the frame's value stack */
      209 |         result = arg ? arg : Py_None;                                                                                                                     209 |         result = arg ? arg : Py_None;
      209 +         result = arg ? arg : (&_Py_NoneStruct);                                                                                                           209 +         result = arg ? arg : (&_Py_NoneStruct);
      210 |         Py_INCREF(result);                                                                                                                                210 |         Py_INCREF(result);
      210 +         _Py_INCREF(((PyObject*)(result)));                                                                                                                210 +         _Py_INCREF(((PyObject*)(result)));
      211 |         *(f->f_stacktop++) = result;                                                                                                                      211 |         *(f->f_stacktop++) = result;
      212 |     }                                                                                                                                                     212 |     }
      213 |                                                                                                                                                           213 |
      214 |     /* Generators always return to their most recent caller, not                                                                                          214 |     /* Generators always return to their most recent caller, not
      215 |      * necessarily their creator. */                                                                                                                      215 |      * necessarily their creator. */
      216 |     Py_XINCREF(tstate->frame);                                                                                                                            216 |     Py_XINCREF(tstate->frame);
      216 +     _Py_XINCREF(((PyObject*)(tstate->frame)));                                                                                                            216 +     _Py_XINCREF(((PyObject*)(tstate->frame)));
"Objects/genobject.c", line 216.5: 1506-495 (I) Pointer type conversion found.                                                                                  "Objects/genobject.c", line 216.5: 1506-495 (I) Pointer type conversion found.
"Objects/genobject.c", line 216.5: 1506-374 (I) Pointer types "struct _object*" and "struct _frame*" are not compatible.                                        "Objects/genobject.c", line 216.5: 1506-374 (I) Pointer types "struct _object*" and "struct _frame*" are not compatible.
      217 |     assert(f->f_back == NULL);                                                                                                                            217 |     assert(f->f_back == NULL);
      217 +     ((f->f_back == 0) ? ((void)0) : __assert("f->f_back == NULL", "Objects/genobject.c", 217));                                                           217 +     ((f->f_back == 0) ? ((void)0) : __assert("f->f_back == NULL", "Objects/genobject.c", 217));
      218 |     f->f_back = tstate->frame;                                                                                                                            218 |     f->f_back = tstate->frame;
      219 |                                                                                                                                                           219 |
      220 |     gen->gi_running = 1;                                                                                                                                  220 |     gen->gi_running = 1;
      221 |     gen->gi_exc_state.previous_item = tstate->exc_info;                                                                                                   221 |     gen->gi_exc_state.previous_item = tstate->exc_info;
      222 |     tstate->exc_info = &gen->gi_exc_state;                                                                                                                222 |     tstate->exc_info = &gen->gi_exc_state;
      223 |     result = _PyEval_EvalFrame(tstate, f, exc);                                                                                                           223 |     result = _PyEval_EvalFrame(tstate, f, exc);
      224 |     tstate->exc_info = gen->gi_exc_state.previous_item;                                                                                                   224 |     tstate->exc_info = gen->gi_exc_state.previous_item;
      225 |     gen->gi_exc_state.previous_item = NULL;                                                                                                               225 |     gen->gi_exc_state.previous_item = NULL;
      225 +     gen->gi_exc_state.previous_item = 0;                                                                                                                  225 +     gen->gi_exc_state.previous_item = 0;
      226 |     gen->gi_running = 0;                                                                                                                                  226 |     gen->gi_running = 0;
      227 |                                                                                                                                                           227 |
      228 |     /* Don't keep the reference to f_back any longer than necessary.  It                                                                                  228 |     /* Don't keep the reference to f_back any longer than necessary.  It
      229 |      * may keep a chain of frames alive or it could create a reference                                                                                    229 |      * may keep a chain of frames alive or it could create a reference
      230 |      * cycle. */                                                                                                                                          230 |      * cycle. */
      231 |     assert(f->f_back == tstate->frame);                                                                                                                   231 |     assert(f->f_back == tstate->frame);
      231 +     ((f->f_back == tstate->frame) ? ((void)0) : __assert("f->f_back == tstate->frame", "Objects/genobject.c", 231));                                      231 +     ((f->f_back == tstate->frame) ? ((void)0) : __assert("f->f_back == tstate->frame", "Objects/genobject.c", 231));
      232 |     Py_CLEAR(f->f_back);                                                                                                                                  232 |     Py_CLEAR(f->f_back);
      232 +     do { PyObject *_py_tmp = ((PyObject*)(f->f_back)); if (_py_tmp != 0) { (f->f_back) = 0; _Py_DECREF("Objects/genobject.c", 232, ((PyObject*)(_py       232 +     do { PyObject *_py_tmp = ((PyObject*)(f->f_back)); if (_py_tmp != 0) { (f->f_back) = 0; _Py_DECREF("Objects/genobject.c", 232, ((PyObject*)(_py
"Objects/genobject.c", line 232.5: 1506-495 (I) Pointer type conversion found.                                                                                  "Objects/genobject.c", line 232.5: 1506-495 (I) Pointer type conversion found.
"Objects/genobject.c", line 232.5: 1506-374 (I) Pointer types "struct _object*" and "struct _frame*" are not compatible.                                        "Objects/genobject.c", line 232.5: 1506-374 (I) Pointer types "struct _object*" and "struct _frame*" are not compatible.
"Objects/genobject.c", line 232.5: 1506-425 (I) The condition is always false.                                                                                  "Objects/genobject.c", line 232.5: 1506-425 (I) The condition is always false.
      233 |                                                                                                                                                           233 |
      234 |     /* If the generator just returned (as opposed to yielding), signal                                                                                    234 |     /* If the generator just returned (as opposed to yielding), signal
      235 |      * that the generator is exhausted. */                                                                                                                235 |      * that the generator is exhausted. */
      236 |     if (result && f->f_stacktop == NULL) {                                                                                                                236 |     if (result && f->f_stacktop == NULL) {
      236 +     if (result && f->f_stacktop == 0) {                                                                                                                   236 +     if (result && f->f_stacktop == 0) {
      237 |         if (result == Py_None) {                                                                                                                          237 |         if (result == Py_None) {
      237 +         if (result == (&_Py_NoneStruct)) {                                                                                                                237 +         if (result == (&_Py_NoneStruct)) {







Wed Apr 15 07:30:04 CDT 2020  Page 9


      238 |             /* Delay exception instantiation if we can */                                                                                                 238 |             /* Delay exception instantiation if we can */
      239 |             if (PyAsyncGen_CheckExact(gen)) {                                                                                                             239 |             if (PyAsyncGen_CheckExact(gen)) {
      239 +             if (_Py_IS_TYPE(((const PyObject*)(gen)), &PyAsyncGen_Type)) {                                                                                239 +             if (_Py_IS_TYPE(((const PyObject*)(gen)), &PyAsyncGen_Type)) {
"Objects/genobject.c", line 239.17: 1506-495 (I) Pointer type conversion found.                                                                                 "Objects/genobject.c", line 239.17: 1506-495 (I) Pointer type conversion found.
"Objects/genobject.c", line 239.17: 1506-374 (I) Pointer types "const struct _object*" and "struct {...}*" are not compatible.                                  "Objects/genobject.c", line 239.17: 1506-374 (I) Pointer types "const struct _object*" and "struct {...}*" are not compatible.
      240 |                 PyErr_SetNone(PyExc_StopAsyncIteration);                                                                                                  240 |                 PyErr_SetNone(PyExc_StopAsyncIteration);
      241 |             }                                                                                                                                             241 |             }
      242 |             else {                                                                                                                                        242 |             else {
      243 |                 PyErr_SetNone(PyExc_StopIteration);                                                                                                       243 |                 PyErr_SetNone(PyExc_StopIteration);
      244 |             }                                                                                                                                             244 |             }
      245 |         }                                                                                                                                                 245 |         }
      246 |         else {                                                                                                                                            246 |         else {
      247 |             /* Async generators cannot return anything but None */                                                                                        247 |             /* Async generators cannot return anything but None */
      248 |             assert(!PyAsyncGen_CheckExact(gen));                                                                                                          248 |             assert(!PyAsyncGen_CheckExact(gen));
      248 +             ((!_Py_IS_TYPE(((const PyObject*)(gen)), &PyAsyncGen_Type)) ? ((void)0) : __assert("!PyAsyncGen_CheckExact(gen)", "Objects/genobject.c"       248 +             ((!_Py_IS_TYPE(((const PyObject*)(gen)), &PyAsyncGen_Type)) ? ((void)0) : __assert("!PyAsyncGen_CheckExact(gen)", "Objects/genobject.c"
"Objects/genobject.c", line 248.21: 1506-495 (I) Pointer type conversion found.                                                                                 "Objects/genobject.c", line 248.21: 1506-495 (I) Pointer type conversion found.
"Objects/genobject.c", line 248.21: 1506-374 (I) Pointer types "const struct _object*" and "struct {...}*" are not compatible.                                  "Objects/genobject.c", line 248.21: 1506-374 (I) Pointer types "const struct _object*" and "struct {...}*" are not compatible.
      249 |             _PyGen_SetStopIterationValue(result);                                                                                                         249 |             _PyGen_SetStopIterationValue(result);
      250 |         }                                                                                                                                                 250 |         }
      251 |         Py_CLEAR(result);                                                                                                                                 251 |         Py_CLEAR(result);
      251 +         do { PyObject *_py_tmp = ((PyObject*)(result)); if (_py_tmp != 0) { (result) = 0; _Py_DECREF("Objects/genobject.c", 251, ((PyObject*)(_py_t       251 +         do { PyObject *_py_tmp = ((PyObject*)(result)); if (_py_tmp != 0) { (result) = 0; _Py_DECREF("Objects/genobject.c", 251, ((PyObject*)(_py_t
"Objects/genobject.c", line 251.9: 1506-425 (I) The condition is always false.                                                                                  "Objects/genobject.c", line 251.9: 1506-425 (I) The condition is always false.
      252 |     }                                                                                                                                                     252 |     }
      253 |     else if (!result && PyErr_ExceptionMatches(PyExc_StopIteration)) {                                                                                    253 |     else if (!result && PyErr_ExceptionMatches(PyExc_StopIteration)) {
      254 |         const char *msg = "generator raised StopIteration";                                                                                               254 |         const char *msg = "generator raised StopIteration";
      255 |         if (PyCoro_CheckExact(gen)) {                                                                                                                     255 |         if (PyCoro_CheckExact(gen)) {
      255 +         if (_Py_IS_TYPE(((const PyObject*)(gen)), &PyCoro_Type)) {                                                                                        255 +         if (_Py_IS_TYPE(((const PyObject*)(gen)), &PyCoro_Type)) {
"Objects/genobject.c", line 255.13: 1506-495 (I) Pointer type conversion found.                                                                                 "Objects/genobject.c", line 255.13: 1506-495 (I) Pointer type conversion found.
"Objects/genobject.c", line 255.13: 1506-374 (I) Pointer types "const struct _object*" and "struct {...}*" are not compatible.                                  "Objects/genobject.c", line 255.13: 1506-374 (I) Pointer types "const struct _object*" and "struct {...}*" are not compatible.
      256 |             msg = "coroutine raised StopIteration";                                                                                                       256 |             msg = "coroutine raised StopIteration";
      257 |         }                                                                                                                                                 257 |         }
      258 |         else if (PyAsyncGen_CheckExact(gen)) {                                                                                                            258 |         else if (PyAsyncGen_CheckExact(gen)) {
      258 +         else if (_Py_IS_TYPE(((const PyObject*)(gen)), &PyAsyncGen_Type)) {                                                                               258 +         else if (_Py_IS_TYPE(((const PyObject*)(gen)), &PyAsyncGen_Type)) {
"Objects/genobject.c", line 258.18: 1506-495 (I) Pointer type conversion found.                                                                                 "Objects/genobject.c", line 258.18: 1506-495 (I) Pointer type conversion found.
"Objects/genobject.c", line 258.18: 1506-374 (I) Pointer types "const struct _object*" and "struct {...}*" are not compatible.                                  "Objects/genobject.c", line 258.18: 1506-374 (I) Pointer types "const struct _object*" and "struct {...}*" are not compatible.
      259 |             msg = "async generator raised StopIteration";                                                                                                 259 |             msg = "async generator raised StopIteration";
      260 |         }                                                                                                                                                 260 |         }
      261 |         _PyErr_FormatFromCause(PyExc_RuntimeError, "%s", msg);                                                                                            261 |         _PyErr_FormatFromCause(PyExc_RuntimeError, "%s", msg);
      262 |                                                                                                                                                           262 |
      263 |     }                                                                                                                                                     263 |     }
      264 |     else if (!result && PyAsyncGen_CheckExact(gen) &&                                                                                                     264 |     else if (!result && PyAsyncGen_CheckExact(gen) &&
      264 +     else if (!result && _Py_IS_TYPE(((const PyObject*)(gen)), &PyAsyncGen_Type) &&                                                                        264 +     else if (!result && _Py_IS_TYPE(((const PyObject*)(gen)), &PyAsyncGen_Type) &&
"Objects/genobject.c", line 264.25: 1506-495 (I) Pointer type conversion found.                                                                                 "Objects/genobject.c", line 264.25: 1506-495 (I) Pointer type conversion found.
"Objects/genobject.c", line 264.25: 1506-374 (I) Pointer types "const struct _object*" and "struct {...}*" are not compatible.                                  "Objects/genobject.c", line 264.25: 1506-374 (I) Pointer types "const struct _object*" and "struct {...}*" are not compatible.
      265 |              PyErr_ExceptionMatches(PyExc_StopAsyncIteration))                                                                                            265 |              PyErr_ExceptionMatches(PyExc_StopAsyncIteration))
      266 |     {                                                                                                                                                     266 |     {
      267 |         /* code in `gen` raised a StopAsyncIteration error:                                                                                               267 |         /* code in `gen` raised a StopAsyncIteration error:
      268 |            raise a RuntimeError.                                                                                                                          268 |            raise a RuntimeError.
      269 |         */                                                                                                                                                269 |         */
      270 |         const char *msg = "async generator raised StopAsyncIteration";                                                                                    270 |         const char *msg = "async generator raised StopAsyncIteration";
      271 |         _PyErr_FormatFromCause(PyExc_RuntimeError, "%s", msg);                                                                                            271 |         _PyErr_FormatFromCause(PyExc_RuntimeError, "%s", msg);
      272 |     }                                                                                                                                                     272 |     }
      273 |                                                                                                                                                           273 |
      274 |     if (!result || f->f_stacktop == NULL) {                                                                                                               274 |     if (!result || f->f_stacktop == NULL) {
      274 +     if (!result || f->f_stacktop == 0) {                                                                                                                  274 +     if (!result || f->f_stacktop == 0) {
      275 |         /* generator can't be rerun, so release the frame */                                                                                              275 |         /* generator can't be rerun, so release the frame */







Wed Apr 15 07:30:04 CDT 2020  Page 10


      276 |         /* first clean reference cycle through stored exception traceback */                                                                              276 |         /* first clean reference cycle through stored exception traceback */
      277 |         exc_state_clear(&gen->gi_exc_state);                                                                                                              277 |         exc_state_clear(&gen->gi_exc_state);
      278 |         gen->gi_frame->f_gen = NULL;                                                                                                                      278 |         gen->gi_frame->f_gen = NULL;
      278 +         gen->gi_frame->f_gen = 0;                                                                                                                         278 +         gen->gi_frame->f_gen = 0;
      279 |         gen->gi_frame = NULL;                                                                                                                             279 |         gen->gi_frame = NULL;
      279 +         gen->gi_frame = 0;                                                                                                                                279 +         gen->gi_frame = 0;
      280 |         Py_DECREF(f);                                                                                                                                     280 |         Py_DECREF(f);
      280 +         _Py_DECREF("Objects/genobject.c", 280, ((PyObject*)(f)));                                                                                         280 +         _Py_DECREF("Objects/genobject.c", 280, ((PyObject*)(f)));
"Objects/genobject.c", line 280.9: 1506-495 (I) Pointer type conversion found.                                                                                  "Objects/genobject.c", line 280.9: 1506-495 (I) Pointer type conversion found.
"Objects/genobject.c", line 280.9: 1506-374 (I) Pointer types "struct _object*" and "struct _frame*" are not compatible.                                        "Objects/genobject.c", line 280.9: 1506-374 (I) Pointer types "struct _object*" and "struct _frame*" are not compatible.
      281 |     }                                                                                                                                                     281 |     }
      282 |                                                                                                                                                           282 |
      283 |     return result;                                                                                                                                        283 |     return result;
      284 | }                                                                                                                                                         284 | }
"Objects/genobject.c", line 284.1: 1506-412 (I) Referenced variable "result", which was not initialized in its declaration.                                     "Objects/genobject.c", line 284.1: 1506-412 (I) Referenced variable "result", which was not initialized in its declaration.
      285 |                                                                                                                                                           285 |
      286 | PyDoc_STRVAR(send_doc,                                                                                                                                    286 | PyDoc_STRVAR(send_doc,
      286 +                                                                                                                                                           286 +
      287 | "send(arg) -> send 'arg' into generator,\n\                                                                                                               287 | "send(arg) -> send 'arg' into generator,\n\
      288 | return next yielded value or raise StopIteration.");                                                                                                      288 | return next yielded value or raise StopIteration.");
      288 + static const char send_doc[] = "send(arg) -> send 'arg' into generator,\nreturn next yielded value or raise StopIteration.";                              288 + static const char send_doc[] = "send(arg) -> send 'arg' into generator,\nreturn next yielded value or raise StopIteration.";
      289 |                                                                                                                                                           289 |
      290 | PyObject *                                                                                                                                                290 | PyObject *
      291 | _PyGen_Send(PyGenObject *gen, PyObject *arg)                                                                                                              291 | _PyGen_Send(PyGenObject *gen, PyObject *arg)
      292 | {                                                                                                                                                         292 | {
      293 |     return gen_send_ex(gen, arg, 0, 0);                                                                                                                   293 |     return gen_send_ex(gen, arg, 0, 0);
      294 | }                                                                                                                                                         294 | }
      295 |                                                                                                                                                           295 |
      296 | PyDoc_STRVAR(close_doc,                                                                                                                                   296 | PyDoc_STRVAR(close_doc,
      296 +                                                                                                                                                           296 +
      297 | "close() -> raise GeneratorExit inside generator.");                                                                                                      297 | "close() -> raise GeneratorExit inside generator.");
      297 + static const char close_doc[] = "close() -> raise GeneratorExit inside generator.";                                                                       297 + static const char close_doc[] = "close() -> raise GeneratorExit inside generator.";
      298 |                                                                                                                                                           298 |
      299 | /*                                                                                                                                                        299 | /*
      300 |  *   This helper function is used by gen_close and gen_throw to                                                                                           300 |  *   This helper function is used by gen_close and gen_throw to
      301 |  *   close a subiterator being delegated to by yield-from.                                                                                                301 |  *   close a subiterator being delegated to by yield-from.
      302 |  */                                                                                                                                                       302 |  */
      303 |                                                                                                                                                           303 |
      304 | static int                                                                                                                                                304 | static int
      305 | gen_close_iter(PyObject *yf)                                                                                                                              305 | gen_close_iter(PyObject *yf)
      306 | {                                                                                                                                                         306 | {
      307 |     PyObject *retval = NULL;                                                                                                                              307 |     PyObject *retval = NULL;
      307 +     PyObject *retval = 0;                                                                                                                                 307 +     PyObject *retval = 0;
      308 |     _Py_IDENTIFIER(close);                                                                                                                                308 |     _Py_IDENTIFIER(close);
      308 +     static _Py_Identifier PyId_close = { .next = 0, .string = "close", .object = 0 };                                                                     308 +     static _Py_Identifier PyId_close = { .next = 0, .string = "close", .object = 0 };
      309 |                                                                                                                                                           309 |
      310 |     if (PyGen_CheckExact(yf) || PyCoro_CheckExact(yf)) {                                                                                                  310 |     if (PyGen_CheckExact(yf) || PyCoro_CheckExact(yf)) {
      310 +     if (_Py_IS_TYPE(((const PyObject*)(yf)), &PyGen_Type) || _Py_IS_TYPE(((const PyObject*)(yf)), &PyCoro_Type)) {                                        310 +     if (_Py_IS_TYPE(((const PyObject*)(yf)), &PyGen_Type) || _Py_IS_TYPE(((const PyObject*)(yf)), &PyCoro_Type)) {
"Objects/genobject.c", line 310.9: 1506-495 (I) Pointer type conversion found.                                                                                  "Objects/genobject.c", line 310.9: 1506-495 (I) Pointer type conversion found.
"Objects/genobject.c", line 310.9: 1506-374 (I) Pointer types "const struct _object*" and "struct _object*" are not compatible.                                 "Objects/genobject.c", line 310.9: 1506-374 (I) Pointer types "const struct _object*" and "struct _object*" are not compatible.
"Objects/genobject.c", line 310.33: 1506-495 (I) Pointer type conversion found.                                                                                 "Objects/genobject.c", line 310.33: 1506-495 (I) Pointer type conversion found.
"Objects/genobject.c", line 310.33: 1506-374 (I) Pointer types "const struct _object*" and "struct _object*" are not compatible.                                "Objects/genobject.c", line 310.33: 1506-374 (I) Pointer types "const struct _object*" and "struct _object*" are not compatible.
      311 |         retval = gen_close((PyGenObject *)yf, NULL);                                                                                                      311 |         retval = gen_close((PyGenObject *)yf, NULL);
      311 +         retval = gen_close((PyGenObject *)yf, 0);                                                                                                         311 +         retval = gen_close((PyGenObject *)yf, 0);
"Objects/genobject.c", line 311.28: 1506-495 (I) Pointer type conversion found.                                                                                 "Objects/genobject.c", line 311.28: 1506-495 (I) Pointer type conversion found.
"Objects/genobject.c", line 311.28: 1506-374 (I) Pointer types "struct {...}*" and "struct _object*" are not compatible.                                        "Objects/genobject.c", line 311.28: 1506-374 (I) Pointer types "struct {...}*" and "struct _object*" are not compatible.







Wed Apr 15 07:30:04 CDT 2020  Page 11


      312 |         if (retval == NULL)                                                                                                                               312 |         if (retval == NULL)
      312 +         if (retval == 0)                                                                                                                                  312 +         if (retval == 0)
      313 |             return -1;                                                                                                                                    313 |             return -1;
      314 |     }                                                                                                                                                     314 |     }
      315 |     else {                                                                                                                                                315 |     else {
      316 |         PyObject *meth;                                                                                                                                   316 |         PyObject *meth;
      317 |         if (_PyObject_LookupAttrId(yf, &PyId_close, &meth) < 0) {                                                                                         317 |         if (_PyObject_LookupAttrId(yf, &PyId_close, &meth) < 0) {
      318 |             PyErr_WriteUnraisable(yf);                                                                                                                    318 |             PyErr_WriteUnraisable(yf);
      319 |         }                                                                                                                                                 319 |         }
      320 |         if (meth) {                                                                                                                                       320 |         if (meth) {
      321 |             retval = _PyObject_CallNoArg(meth);                                                                                                           321 |             retval = _PyObject_CallNoArg(meth);
      322 |             Py_DECREF(meth);                                                                                                                              322 |             Py_DECREF(meth);
      322 +             _Py_DECREF("Objects/genobject.c", 322, ((PyObject*)(meth)));                                                                                  322 +             _Py_DECREF("Objects/genobject.c", 322, ((PyObject*)(meth)));
      323 |             if (retval == NULL)                                                                                                                           323 |             if (retval == NULL)
      323 +             if (retval == 0)                                                                                                                              323 +             if (retval == 0)
      324 |                 return -1;                                                                                                                                324 |                 return -1;
      325 |         }                                                                                                                                                 325 |         }
      326 |     }                                                                                                                                                     326 |     }
"Objects/genobject.c", line 326.5: 1506-412 (I) Referenced variable "meth", which was not initialized in its declaration.                                       "Objects/genobject.c", line 326.5: 1506-412 (I) Referenced variable "meth", which was not initialized in its declaration.
      327 |     Py_XDECREF(retval);                                                                                                                                   327 |     Py_XDECREF(retval);
      327 +     _Py_XDECREF(((PyObject*)(retval)));                                                                                                                   327 +     _Py_XDECREF(((PyObject*)(retval)));
      328 |     return 0;                                                                                                                                             328 |     return 0;
      329 | }                                                                                                                                                         329 | }
      330 |                                                                                                                                                           330 |
      331 | PyObject *                                                                                                                                                331 | PyObject *
      332 | _PyGen_yf(PyGenObject *gen)                                                                                                                               332 | _PyGen_yf(PyGenObject *gen)
      333 | {                                                                                                                                                         333 | {
      334 |     PyObject *yf = NULL;                                                                                                                                  334 |     PyObject *yf = NULL;
      334 +     PyObject *yf = 0;                                                                                                                                     334 +     PyObject *yf = 0;
      335 |     PyFrameObject *f = gen->gi_frame;                                                                                                                     335 |     PyFrameObject *f = gen->gi_frame;
      336 |                                                                                                                                                           336 |
      337 |     if (f && f->f_stacktop) {                                                                                                                             337 |     if (f && f->f_stacktop) {
      338 |         PyObject *bytecode = f->f_code->co_code;                                                                                                          338 |         PyObject *bytecode = f->f_code->co_code;
      339 |         unsigned char *code = (unsigned char *)PyBytes_AS_STRING(bytecode);                                                                               339 |         unsigned char *code = (unsigned char *)PyBytes_AS_STRING(bytecode);
      339 +         unsigned char *code = (unsigned char *)(((PyType_HasFeature((((PyObject*)(bytecode))->ob_type), (1UL << 27))) ? ((void)0) : __assert("PyByt       339 +         unsigned char *code = (unsigned char *)(((PyType_HasFeature((((PyObject*)(bytecode))->ob_type), (1UL << 27))) ? ((void)0) : __assert("PyByt
"Objects/genobject.c", line 339.48: 1506-495 (I) Pointer type conversion found.                                                                                 "Objects/genobject.c", line 339.48: 1506-495 (I) Pointer type conversion found.
"Objects/genobject.c", line 339.48: 1506-374 (I) Pointer types "struct {...}*" and "struct _object*" are not compatible.                                        "Objects/genobject.c", line 339.48: 1506-374 (I) Pointer types "struct {...}*" and "struct _object*" are not compatible.
      340 |                                                                                                                                                           340 |
      341 |         if (f->f_lasti < 0) {                                                                                                                             341 |         if (f->f_lasti < 0) {
      342 |             /* Return immediately if the frame didn't start yet. YIELD_FROM                                                                               342 |             /* Return immediately if the frame didn't start yet. YIELD_FROM
      343 |                always come after LOAD_CONST: a code object should not start                                                                               343 |                always come after LOAD_CONST: a code object should not start
      344 |                with YIELD_FROM */                                                                                                                         344 |                with YIELD_FROM */
      345 |             assert(code[0] != YIELD_FROM);                                                                                                                345 |             assert(code[0] != YIELD_FROM);
      345 +             ((code[0] != 72) ? ((void)0) : __assert("code[0] != YIELD_FROM", "Objects/genobject.c", 345));                                                345 +             ((code[0] != 72) ? ((void)0) : __assert("code[0] != YIELD_FROM", "Objects/genobject.c", 345));
      346 |             return NULL;                                                                                                                                  346 |             return NULL;
      346 +             return 0;                                                                                                                                     346 +             return 0;
      347 |         }                                                                                                                                                 347 |         }
      348 |                                                                                                                                                           348 |
      349 |         if (code[f->f_lasti + sizeof(_Py_CODEUNIT)] != YIELD_FROM)                                                                                        349 |         if (code[f->f_lasti + sizeof(_Py_CODEUNIT)] != YIELD_FROM)
      349 +         if (code[f->f_lasti + sizeof(_Py_CODEUNIT)] != 72)                                                                                                349 +         if (code[f->f_lasti + sizeof(_Py_CODEUNIT)] != 72)
      350 |             return NULL;                                                                                                                                  350 |             return NULL;
      350 +             return 0;                                                                                                                                     350 +             return 0;
      351 |         yf = f->f_stacktop[-1];                                                                                                                           351 |         yf = f->f_stacktop[-1];
      352 |         Py_INCREF(yf);                                                                                                                                    352 |         Py_INCREF(yf);
      352 +         _Py_INCREF(((PyObject*)(yf)));                                                                                                                    352 +         _Py_INCREF(((PyObject*)(yf)));
      353 |     }                                                                                                                                                     353 |     }







Wed Apr 15 07:30:04 CDT 2020  Page 12


      354 |                                                                                                                                                           354 |
      355 |     return yf;                                                                                                                                            355 |     return yf;
      356 | }                                                                                                                                                         356 | }
      357 |                                                                                                                                                           357 |
      358 | static PyObject *                                                                                                                                         358 | static PyObject *
      359 | gen_close(PyGenObject *gen, PyObject *args)                                                                                                               359 | gen_close(PyGenObject *gen, PyObject *args)
      360 | {                                                                                                                                                         360 | {
      361 |     PyObject *retval;                                                                                                                                     361 |     PyObject *retval;
      362 |     PyObject *yf = _PyGen_yf(gen);                                                                                                                        362 |     PyObject *yf = _PyGen_yf(gen);
      363 |     int err = 0;                                                                                                                                          363 |     int err = 0;
      364 |                                                                                                                                                           364 |
      365 |     if (yf) {                                                                                                                                             365 |     if (yf) {
      366 |         gen->gi_running = 1;                                                                                                                              366 |         gen->gi_running = 1;
      367 |         err = gen_close_iter(yf);                                                                                                                         367 |         err = gen_close_iter(yf);
      368 |         gen->gi_running = 0;                                                                                                                              368 |         gen->gi_running = 0;
      369 |         Py_DECREF(yf);                                                                                                                                    369 |         Py_DECREF(yf);
      369 +         _Py_DECREF("Objects/genobject.c", 369, ((PyObject*)(yf)));                                                                                        369 +         _Py_DECREF("Objects/genobject.c", 369, ((PyObject*)(yf)));
      370 |     }                                                                                                                                                     370 |     }
      371 |     if (err == 0)                                                                                                                                         371 |     if (err == 0)
      372 |         PyErr_SetNone(PyExc_GeneratorExit);                                                                                                               372 |         PyErr_SetNone(PyExc_GeneratorExit);
      373 |     retval = gen_send_ex(gen, Py_None, 1, 1);                                                                                                             373 |     retval = gen_send_ex(gen, Py_None, 1, 1);
      373 +     retval = gen_send_ex(gen, (&_Py_NoneStruct), 1, 1);                                                                                                   373 +     retval = gen_send_ex(gen, (&_Py_NoneStruct), 1, 1);
      374 |     if (retval) {                                                                                                                                         374 |     if (retval) {
      375 |         const char *msg = "generator ignored GeneratorExit";                                                                                              375 |         const char *msg = "generator ignored GeneratorExit";
      376 |         if (PyCoro_CheckExact(gen)) {                                                                                                                     376 |         if (PyCoro_CheckExact(gen)) {
      376 +         if (_Py_IS_TYPE(((const PyObject*)(gen)), &PyCoro_Type)) {                                                                                        376 +         if (_Py_IS_TYPE(((const PyObject*)(gen)), &PyCoro_Type)) {
"Objects/genobject.c", line 376.13: 1506-495 (I) Pointer type conversion found.                                                                                 "Objects/genobject.c", line 376.13: 1506-495 (I) Pointer type conversion found.
"Objects/genobject.c", line 376.13: 1506-374 (I) Pointer types "const struct _object*" and "struct {...}*" are not compatible.                                  "Objects/genobject.c", line 376.13: 1506-374 (I) Pointer types "const struct _object*" and "struct {...}*" are not compatible.
      377 |             msg = "coroutine ignored GeneratorExit";                                                                                                      377 |             msg = "coroutine ignored GeneratorExit";
      378 |         } else if (PyAsyncGen_CheckExact(gen)) {                                                                                                          378 |         } else if (PyAsyncGen_CheckExact(gen)) {
      378 +         } else if (_Py_IS_TYPE(((const PyObject*)(gen)), &PyAsyncGen_Type)) {                                                                             378 +         } else if (_Py_IS_TYPE(((const PyObject*)(gen)), &PyAsyncGen_Type)) {
"Objects/genobject.c", line 378.20: 1506-495 (I) Pointer type conversion found.                                                                                 "Objects/genobject.c", line 378.20: 1506-495 (I) Pointer type conversion found.
"Objects/genobject.c", line 378.20: 1506-374 (I) Pointer types "const struct _object*" and "struct {...}*" are not compatible.                                  "Objects/genobject.c", line 378.20: 1506-374 (I) Pointer types "const struct _object*" and "struct {...}*" are not compatible.
      379 |             msg = ASYNC_GEN_IGNORED_EXIT_MSG;                                                                                                             379 |             msg = ASYNC_GEN_IGNORED_EXIT_MSG;
      380 |         }                                                                                                                                                 380 |         }
      381 |         Py_DECREF(retval);                                                                                                                                381 |         Py_DECREF(retval);
      381 +         _Py_DECREF("Objects/genobject.c", 381, ((PyObject*)(retval)));                                                                                    381 +         _Py_DECREF("Objects/genobject.c", 381, ((PyObject*)(retval)));
      382 |         PyErr_SetString(PyExc_RuntimeError, msg);                                                                                                         382 |         PyErr_SetString(PyExc_RuntimeError, msg);
      383 |         return NULL;                                                                                                                                      383 |         return NULL;
      383 +         return 0;                                                                                                                                         383 +         return 0;
      384 |     }                                                                                                                                                     384 |     }
      385 |     if (PyErr_ExceptionMatches(PyExc_StopIteration)                                                                                                       385 |     if (PyErr_ExceptionMatches(PyExc_StopIteration)
      386 |         || PyErr_ExceptionMatches(PyExc_GeneratorExit)) {                                                                                                 386 |         || PyErr_ExceptionMatches(PyExc_GeneratorExit)) {
      387 |         PyErr_Clear();          /* ignore these errors */                                                                                                 387 |         PyErr_Clear();          /* ignore these errors */
      388 |         Py_RETURN_NONE;                                                                                                                                   388 |         Py_RETURN_NONE;
      388 +         return _Py_INCREF(((PyObject*)((&_Py_NoneStruct)))), (&_Py_NoneStruct);                                                                           388 +         return _Py_INCREF(((PyObject*)((&_Py_NoneStruct)))), (&_Py_NoneStruct);
      389 |     }                                                                                                                                                     389 |     }
      390 |     return NULL;                                                                                                                                          390 |     return NULL;
      390 +     return 0;                                                                                                                                             390 +     return 0;
      391 | }                                                                                                                                                         391 | }
"Objects/genobject.c", line 391.1: 1506-412 (I) Referenced variable "retval", which was not initialized in its declaration.                                     "Objects/genobject.c", line 391.1: 1506-412 (I) Referenced variable "retval", which was not initialized in its declaration.
"Objects/genobject.c", line 391.1: 1506-414 (I) The parameter "args" is never referenced.                                                                       "Objects/genobject.c", line 391.1: 1506-414 (I) The parameter "args" is never referenced.
      392 |                                                                                                                                                           392 |
      393 |                                                                                                                                                           393 |
      394 | PyDoc_STRVAR(throw_doc,                                                                                                                                   394 | PyDoc_STRVAR(throw_doc,
      394 +                                                                                                                                                           394 +







Wed Apr 15 07:30:04 CDT 2020  Page 13


      395 | "throw(typ[,val[,tb]]) -> raise exception in generator,\n\                                                                                                395 | "throw(typ[,val[,tb]]) -> raise exception in generator,\n\
      396 | return next yielded value or raise StopIteration.");                                                                                                      396 | return next yielded value or raise StopIteration.");
      396 + static const char throw_doc[] = "throw(typ[,val[,tb]]) -> raise exception in generator,\nreturn next yielded value or raise StopIteration.";              396 + static const char throw_doc[] = "throw(typ[,val[,tb]]) -> raise exception in generator,\nreturn next yielded value or raise StopIteration.";
      397 |                                                                                                                                                           397 |
      398 | static PyObject *                                                                                                                                         398 | static PyObject *
      399 | _gen_throw(PyGenObject *gen, int close_on_genexit,                                                                                                        399 | _gen_throw(PyGenObject *gen, int close_on_genexit,
      400 |            PyObject *typ, PyObject *val, PyObject *tb)                                                                                                    400 |            PyObject *typ, PyObject *val, PyObject *tb)
      401 | {                                                                                                                                                         401 | {
      402 |     PyObject *yf = _PyGen_yf(gen);                                                                                                                        402 |     PyObject *yf = _PyGen_yf(gen);
      403 |     _Py_IDENTIFIER(throw);                                                                                                                                403 |     _Py_IDENTIFIER(throw);
      403 +     static _Py_Identifier PyId_throw = { .next = 0, .string = "throw", .object = 0 };                                                                     403 +     static _Py_Identifier PyId_throw = { .next = 0, .string = "throw", .object = 0 };
      404 |                                                                                                                                                           404 |
      405 |     if (yf) {                                                                                                                                             405 |     if (yf) {
      406 |         PyObject *ret;                                                                                                                                    406 |         PyObject *ret;
      407 |         int err;                                                                                                                                          407 |         int err;
      408 |         if (PyErr_GivenExceptionMatches(typ, PyExc_GeneratorExit) &&                                                                                      408 |         if (PyErr_GivenExceptionMatches(typ, PyExc_GeneratorExit) &&
      409 |             close_on_genexit                                                                                                                              409 |             close_on_genexit
      410 |         ) {                                                                                                                                               410 |         ) {
      411 |             /* Asynchronous generators *should not* be closed right away.                                                                                 411 |             /* Asynchronous generators *should not* be closed right away.
      412 |                We have to allow some awaits to work it through, hence the                                                                                 412 |                We have to allow some awaits to work it through, hence the
      413 |                `close_on_genexit` parameter here.                                                                                                         413 |                `close_on_genexit` parameter here.
      414 |             */                                                                                                                                            414 |             */
      415 |             gen->gi_running = 1;                                                                                                                          415 |             gen->gi_running = 1;
      416 |             err = gen_close_iter(yf);                                                                                                                     416 |             err = gen_close_iter(yf);
      417 |             gen->gi_running = 0;                                                                                                                          417 |             gen->gi_running = 0;
      418 |             Py_DECREF(yf);                                                                                                                                418 |             Py_DECREF(yf);
      418 +             _Py_DECREF("Objects/genobject.c", 418, ((PyObject*)(yf)));                                                                                    418 +             _Py_DECREF("Objects/genobject.c", 418, ((PyObject*)(yf)));
      419 |             if (err < 0)                                                                                                                                  419 |             if (err < 0)
      420 |                 return gen_send_ex(gen, Py_None, 1, 0);                                                                                                   420 |                 return gen_send_ex(gen, Py_None, 1, 0);
      420 +                 return gen_send_ex(gen, (&_Py_NoneStruct), 1, 0);                                                                                         420 +                 return gen_send_ex(gen, (&_Py_NoneStruct), 1, 0);
      421 |             goto throw_here;                                                                                                                              421 |             goto throw_here;
"Objects/genobject.c", line 421.13: 1506-413 (I) A goto statement is used.                                                                                      "Objects/genobject.c", line 421.13: 1506-413 (I) A goto statement is used.
      422 |         }                                                                                                                                                 422 |         }
      423 |         if (PyGen_CheckExact(yf) || PyCoro_CheckExact(yf)) {                                                                                              423 |         if (PyGen_CheckExact(yf) || PyCoro_CheckExact(yf)) {
      423 +         if (_Py_IS_TYPE(((const PyObject*)(yf)), &PyGen_Type) || _Py_IS_TYPE(((const PyObject*)(yf)), &PyCoro_Type)) {                                    423 +         if (_Py_IS_TYPE(((const PyObject*)(yf)), &PyGen_Type) || _Py_IS_TYPE(((const PyObject*)(yf)), &PyCoro_Type)) {
"Objects/genobject.c", line 423.13: 1506-495 (I) Pointer type conversion found.                                                                                 "Objects/genobject.c", line 423.13: 1506-495 (I) Pointer type conversion found.
"Objects/genobject.c", line 423.13: 1506-374 (I) Pointer types "const struct _object*" and "struct _object*" are not compatible.                                "Objects/genobject.c", line 423.13: 1506-374 (I) Pointer types "const struct _object*" and "struct _object*" are not compatible.
"Objects/genobject.c", line 423.37: 1506-495 (I) Pointer type conversion found.                                                                                 "Objects/genobject.c", line 423.37: 1506-495 (I) Pointer type conversion found.
"Objects/genobject.c", line 423.37: 1506-374 (I) Pointer types "const struct _object*" and "struct _object*" are not compatible.                                "Objects/genobject.c", line 423.37: 1506-374 (I) Pointer types "const struct _object*" and "struct _object*" are not compatible.
      424 |             /* `yf` is a generator or a coroutine. */                                                                                                     424 |             /* `yf` is a generator or a coroutine. */
      425 |             gen->gi_running = 1;                                                                                                                          425 |             gen->gi_running = 1;
      426 |             /* Close the generator that we are currently iterating with                                                                                   426 |             /* Close the generator that we are currently iterating with
      427 |                'yield from' or awaiting on with 'await'. */                                                                                               427 |                'yield from' or awaiting on with 'await'. */
      428 |             ret = _gen_throw((PyGenObject *)yf, close_on_genexit,                                                                                         428 |             ret = _gen_throw((PyGenObject *)yf, close_on_genexit,
"Objects/genobject.c", line 428.30: 1506-495 (I) Pointer type conversion found.                                                                                 "Objects/genobject.c", line 428.30: 1506-495 (I) Pointer type conversion found.
"Objects/genobject.c", line 428.30: 1506-374 (I) Pointer types "struct {...}*" and "struct _object*" are not compatible.                                        "Objects/genobject.c", line 428.30: 1506-374 (I) Pointer types "struct {...}*" and "struct _object*" are not compatible.
      429 |                              typ, val, tb);                                                                                                               429 |                              typ, val, tb);
      430 |             gen->gi_running = 0;                                                                                                                          430 |             gen->gi_running = 0;
      431 |         } else {                                                                                                                                          431 |         } else {
      432 |             /* `yf` is an iterator or a coroutine-like object. */                                                                                         432 |             /* `yf` is an iterator or a coroutine-like object. */
      433 |             PyObject *meth;                                                                                                                               433 |             PyObject *meth;
      434 |             if (_PyObject_LookupAttrId(yf, &PyId_throw, &meth) < 0) {                                                                                     434 |             if (_PyObject_LookupAttrId(yf, &PyId_throw, &meth) < 0) {
      435 |                 Py_DECREF(yf);                                                                                                                            435 |                 Py_DECREF(yf);
      435 +                 _Py_DECREF("Objects/genobject.c", 435, ((PyObject*)(yf)));                                                                                435 +                 _Py_DECREF("Objects/genobject.c", 435, ((PyObject*)(yf)));
      436 |                 return NULL;                                                                                                                              436 |                 return NULL;
      436 +                 return 0;                                                                                                                                 436 +                 return 0;







Wed Apr 15 07:30:04 CDT 2020  Page 14


      437 |             }                                                                                                                                             437 |             }
      438 |             if (meth == NULL) {                                                                                                                           438 |             if (meth == NULL) {
      438 +             if (meth == 0) {                                                                                                                              438 +             if (meth == 0) {
      439 |                 Py_DECREF(yf);                                                                                                                            439 |                 Py_DECREF(yf);
      439 +                 _Py_DECREF("Objects/genobject.c", 439, ((PyObject*)(yf)));                                                                                439 +                 _Py_DECREF("Objects/genobject.c", 439, ((PyObject*)(yf)));
      440 |                 goto throw_here;                                                                                                                          440 |                 goto throw_here;
"Objects/genobject.c", line 440.17: 1506-413 (I) A goto statement is used.                                                                                      "Objects/genobject.c", line 440.17: 1506-413 (I) A goto statement is used.
      441 |             }                                                                                                                                             441 |             }
      442 |             gen->gi_running = 1;                                                                                                                          442 |             gen->gi_running = 1;
      443 |             ret = PyObject_CallFunctionObjArgs(meth, typ, val, tb, NULL);                                                                                 443 |             ret = PyObject_CallFunctionObjArgs(meth, typ, val, tb, NULL);
      443 +             ret = PyObject_CallFunctionObjArgs(meth, typ, val, tb, 0);                                                                                    443 +             ret = PyObject_CallFunctionObjArgs(meth, typ, val, tb, 0);
      444 |             gen->gi_running = 0;                                                                                                                          444 |             gen->gi_running = 0;
      445 |             Py_DECREF(meth);                                                                                                                              445 |             Py_DECREF(meth);
      445 +             _Py_DECREF("Objects/genobject.c", 445, ((PyObject*)(meth)));                                                                                  445 +             _Py_DECREF("Objects/genobject.c", 445, ((PyObject*)(meth)));
      446 |         }                                                                                                                                                 446 |         }
"Objects/genobject.c", line 446.9: 1506-412 (I) Referenced variable "meth", which was not initialized in its declaration.                                       "Objects/genobject.c", line 446.9: 1506-412 (I) Referenced variable "meth", which was not initialized in its declaration.
      447 |         Py_DECREF(yf);                                                                                                                                    447 |         Py_DECREF(yf);
      447 +         _Py_DECREF("Objects/genobject.c", 447, ((PyObject*)(yf)));                                                                                        447 +         _Py_DECREF("Objects/genobject.c", 447, ((PyObject*)(yf)));
      448 |         if (!ret) {                                                                                                                                       448 |         if (!ret) {
      449 |             PyObject *val;                                                                                                                                449 |             PyObject *val;
"Objects/genobject.c", line 449.22: 1506-492 (I) Redefinition of val hides previous definition.                                                                 "Objects/genobject.c", line 449.22: 1506-492 (I) Redefinition of val hides previous definition.
      450 |             /* Pop subiterator from stack */                                                                                                              450 |             /* Pop subiterator from stack */
      451 |             ret = *(--gen->gi_frame->f_stacktop);                                                                                                         451 |             ret = *(--gen->gi_frame->f_stacktop);
      452 |             assert(ret == yf);                                                                                                                            452 |             assert(ret == yf);
      452 +             ((ret == yf) ? ((void)0) : __assert("ret == yf", "Objects/genobject.c", 452));                                                                452 +             ((ret == yf) ? ((void)0) : __assert("ret == yf", "Objects/genobject.c", 452));
      453 |             Py_DECREF(ret);                                                                                                                               453 |             Py_DECREF(ret);
      453 +             _Py_DECREF("Objects/genobject.c", 453, ((PyObject*)(ret)));                                                                                   453 +             _Py_DECREF("Objects/genobject.c", 453, ((PyObject*)(ret)));
      454 |             /* Termination repetition of YIELD_FROM */                                                                                                    454 |             /* Termination repetition of YIELD_FROM */
      455 |             assert(gen->gi_frame->f_lasti >= 0);                                                                                                          455 |             assert(gen->gi_frame->f_lasti >= 0);
      455 +             ((gen->gi_frame->f_lasti >= 0) ? ((void)0) : __assert("gen->gi_frame->f_lasti >= 0", "Objects/genobject.c", 455));                            455 +             ((gen->gi_frame->f_lasti >= 0) ? ((void)0) : __assert("gen->gi_frame->f_lasti >= 0", "Objects/genobject.c", 455));
      456 |             gen->gi_frame->f_lasti += sizeof(_Py_CODEUNIT);                                                                                               456 |             gen->gi_frame->f_lasti += sizeof(_Py_CODEUNIT);
      457 |             if (_PyGen_FetchStopIterationValue(&val) == 0) {                                                                                              457 |             if (_PyGen_FetchStopIterationValue(&val) == 0) {
      458 |                 ret = gen_send_ex(gen, val, 0, 0);                                                                                                        458 |                 ret = gen_send_ex(gen, val, 0, 0);
      459 |                 Py_DECREF(val);                                                                                                                           459 |                 Py_DECREF(val);
      459 +                 _Py_DECREF("Objects/genobject.c", 459, ((PyObject*)(val)));                                                                               459 +                 _Py_DECREF("Objects/genobject.c", 459, ((PyObject*)(val)));
      460 |             } else {                                                                                                                                      460 |             } else {
      461 |                 ret = gen_send_ex(gen, Py_None, 1, 0);                                                                                                    461 |                 ret = gen_send_ex(gen, Py_None, 1, 0);
      461 +                 ret = gen_send_ex(gen, (&_Py_NoneStruct), 1, 0);                                                                                          461 +                 ret = gen_send_ex(gen, (&_Py_NoneStruct), 1, 0);
      462 |             }                                                                                                                                             462 |             }
      463 |         }                                                                                                                                                 463 |         }
"Objects/genobject.c", line 463.9: 1506-412 (I) Referenced variable "val", which was not initialized in its declaration.                                        "Objects/genobject.c", line 463.9: 1506-412 (I) Referenced variable "val", which was not initialized in its declaration.
      464 |         return ret;                                                                                                                                       464 |         return ret;
      465 |     }                                                                                                                                                     465 |     }
"Objects/genobject.c", line 465.5: 1506-412 (I) Referenced variable "err", which was not initialized in its declaration.                                        "Objects/genobject.c", line 465.5: 1506-412 (I) Referenced variable "err", which was not initialized in its declaration.
"Objects/genobject.c", line 465.5: 1506-412 (I) Referenced variable "ret", which was not initialized in its declaration.                                        "Objects/genobject.c", line 465.5: 1506-412 (I) Referenced variable "ret", which was not initialized in its declaration.
      466 |                                                                                                                                                           466 |
      467 | throw_here:                                                                                                                                               467 | throw_here:
      468 |     /* First, check the traceback argument, replacing None with                                                                                           468 |     /* First, check the traceback argument, replacing None with
      469 |        NULL. */                                                                                                                                           469 |        NULL. */
      470 |     if (tb == Py_None) {                                                                                                                                  470 |     if (tb == Py_None) {
      470 +     if (tb == (&_Py_NoneStruct)) {                                                                                                                        470 +     if (tb == (&_Py_NoneStruct)) {
      471 |         tb = NULL;                                                                                                                                        471 |         tb = NULL;
      471 +         tb = 0;                                                                                                                                           471 +         tb = 0;
      472 |     }                                                                                                                                                     472 |     }
      473 |     else if (tb != NULL && !PyTraceBack_Check(tb)) {                                                                                                      473 |     else if (tb != NULL && !PyTraceBack_Check(tb)) {
      473 +     else if (tb != 0 && !_Py_IS_TYPE(((const PyObject*)(tb)), &PyTraceBack_Type)) {                                                                       473 +     else if (tb != 0 && !_Py_IS_TYPE(((const PyObject*)(tb)), &PyTraceBack_Type)) {







Wed Apr 15 07:30:04 CDT 2020  Page 15


"Objects/genobject.c", line 473.29: 1506-495 (I) Pointer type conversion found.                                                                                 "Objects/genobject.c", line 473.29: 1506-495 (I) Pointer type conversion found.
"Objects/genobject.c", line 473.29: 1506-374 (I) Pointer types "const struct _object*" and "struct _object*" are not compatible.                                "Objects/genobject.c", line 473.29: 1506-374 (I) Pointer types "const struct _object*" and "struct _object*" are not compatible.
      474 |         PyErr_SetString(PyExc_TypeError,                                                                                                                  474 |         PyErr_SetString(PyExc_TypeError,
      475 |             "throw() third argument must be a traceback object");                                                                                         475 |             "throw() third argument must be a traceback object");
      476 |         return NULL;                                                                                                                                      476 |         return NULL;
      476 +         return 0;                                                                                                                                         476 +         return 0;
      477 |     }                                                                                                                                                     477 |     }
      478 |                                                                                                                                                           478 |
      479 |     Py_INCREF(typ);                                                                                                                                       479 |     Py_INCREF(typ);
      479 +     _Py_INCREF(((PyObject*)(typ)));                                                                                                                       479 +     _Py_INCREF(((PyObject*)(typ)));
      480 |     Py_XINCREF(val);                                                                                                                                      480 |     Py_XINCREF(val);
      480 +     _Py_XINCREF(((PyObject*)(val)));                                                                                                                      480 +     _Py_XINCREF(((PyObject*)(val)));
      481 |     Py_XINCREF(tb);                                                                                                                                       481 |     Py_XINCREF(tb);
      481 +     _Py_XINCREF(((PyObject*)(tb)));                                                                                                                       481 +     _Py_XINCREF(((PyObject*)(tb)));
      482 |                                                                                                                                                           482 |
      483 |     if (PyExceptionClass_Check(typ))                                                                                                                      483 |     if (PyExceptionClass_Check(typ))
      483 +     if ((_PyType_Check(((PyObject*)((typ)))) && PyType_HasFeature((PyTypeObject*)(typ), (1UL << 30))))                                                    483 +     if ((_PyType_Check(((PyObject*)((typ)))) && PyType_HasFeature((PyTypeObject*)(typ), (1UL << 30))))
"Objects/genobject.c", line 483.9: 1506-495 (I) Pointer type conversion found.                                                                                  "Objects/genobject.c", line 483.9: 1506-495 (I) Pointer type conversion found.
"Objects/genobject.c", line 483.9: 1506-374 (I) Pointer types "struct _typeobject*" and "struct _object*" are not compatible.                                   "Objects/genobject.c", line 483.9: 1506-374 (I) Pointer types "struct _typeobject*" and "struct _object*" are not compatible.
      484 |         PyErr_NormalizeException(&typ, &val, &tb);                                                                                                        484 |         PyErr_NormalizeException(&typ, &val, &tb);
      485 |                                                                                                                                                           485 |
      486 |     else if (PyExceptionInstance_Check(typ)) {                                                                                                            486 |     else if (PyExceptionInstance_Check(typ)) {
      486 +     else if (PyType_HasFeature((((PyObject*)(typ))->ob_type), (1UL << 30))) {                                                                             486 +     else if (PyType_HasFeature((((PyObject*)(typ))->ob_type), (1UL << 30))) {
      487 |         /* Raising an instance.  The value should be a dummy. */                                                                                          487 |         /* Raising an instance.  The value should be a dummy. */
      488 |         if (val && val != Py_None) {                                                                                                                      488 |         if (val && val != Py_None) {
      488 +         if (val && val != (&_Py_NoneStruct)) {                                                                                                            488 +         if (val && val != (&_Py_NoneStruct)) {
      489 |             PyErr_SetString(PyExc_TypeError,                                                                                                              489 |             PyErr_SetString(PyExc_TypeError,
      490 |               "instance exception may not have a separate value");                                                                                        490 |               "instance exception may not have a separate value");
      491 |             goto failed_throw;                                                                                                                            491 |             goto failed_throw;
"Objects/genobject.c", line 491.13: 1506-413 (I) A goto statement is used.                                                                                      "Objects/genobject.c", line 491.13: 1506-413 (I) A goto statement is used.
      492 |         }                                                                                                                                                 492 |         }
      493 |         else {                                                                                                                                            493 |         else {
      494 |             /* Normalize to raise <class>, <instance> */                                                                                                  494 |             /* Normalize to raise <class>, <instance> */
      495 |             Py_XDECREF(val);                                                                                                                              495 |             Py_XDECREF(val);
      495 +             _Py_XDECREF(((PyObject*)(val)));                                                                                                              495 +             _Py_XDECREF(((PyObject*)(val)));
      496 |             val = typ;                                                                                                                                    496 |             val = typ;
      497 |             typ = PyExceptionInstance_Class(typ);                                                                                                         497 |             typ = PyExceptionInstance_Class(typ);
      497 +             typ = ((PyObject*)(((PyObject*)(typ))->ob_type));                                                                                             497 +             typ = ((PyObject*)(((PyObject*)(typ))->ob_type));
"Objects/genobject.c", line 497.19: 1506-495 (I) Pointer type conversion found.                                                                                 "Objects/genobject.c", line 497.19: 1506-495 (I) Pointer type conversion found.
"Objects/genobject.c", line 497.19: 1506-374 (I) Pointer types "struct _object*" and "struct _typeobject*" are not compatible.                                  "Objects/genobject.c", line 497.19: 1506-374 (I) Pointer types "struct _object*" and "struct _typeobject*" are not compatible.
      498 |             Py_INCREF(typ);                                                                                                                               498 |             Py_INCREF(typ);
      498 +             _Py_INCREF(((PyObject*)(typ)));                                                                                                               498 +             _Py_INCREF(((PyObject*)(typ)));
      499 |                                                                                                                                                           499 |
      500 |             if (tb == NULL)                                                                                                                               500 |             if (tb == NULL)
      500 +             if (tb == 0)                                                                                                                                  500 +             if (tb == 0)
      501 |                 /* Returns NULL if there's no traceback */                                                                                                501 |                 /* Returns NULL if there's no traceback */
      502 |                 tb = PyException_GetTraceback(val);                                                                                                       502 |                 tb = PyException_GetTraceback(val);
      503 |         }                                                                                                                                                 503 |         }
      504 |     }                                                                                                                                                     504 |     }
      505 |     else {                                                                                                                                                505 |     else {
      506 |         /* Not something you can raise.  throw() fails. */                                                                                                506 |         /* Not something you can raise.  throw() fails. */
      507 |         PyErr_Format(PyExc_TypeError,                                                                                                                     507 |         PyErr_Format(PyExc_TypeError,
      508 |                      "exceptions must be classes or instances "                                                                                           508 |                      "exceptions must be classes or instances "
      509 |                      "deriving from BaseException, not %s",                                                                                               509 |                      "deriving from BaseException, not %s",
      510 |                      Py_TYPE(typ)->tp_name);                                                                                                              510 |                      Py_TYPE(typ)->tp_name);
      510 +                      (((PyObject*)(typ))->ob_type)->tp_name);                                                                                             510 +                      (((PyObject*)(typ))->ob_type)->tp_name);







Wed Apr 15 07:30:04 CDT 2020  Page 16


      511 |             goto failed_throw;                                                                                                                            511 |             goto failed_throw;
"Objects/genobject.c", line 511.13: 1506-413 (I) A goto statement is used.                                                                                      "Objects/genobject.c", line 511.13: 1506-413 (I) A goto statement is used.
      512 |     }                                                                                                                                                     512 |     }
      513 |                                                                                                                                                           513 |
      514 |     PyErr_Restore(typ, val, tb);                                                                                                                          514 |     PyErr_Restore(typ, val, tb);
      515 |     return gen_send_ex(gen, Py_None, 1, 0);                                                                                                               515 |     return gen_send_ex(gen, Py_None, 1, 0);
      515 +     return gen_send_ex(gen, (&_Py_NoneStruct), 1, 0);                                                                                                     515 +     return gen_send_ex(gen, (&_Py_NoneStruct), 1, 0);
      516 |                                                                                                                                                           516 |
      517 | failed_throw:                                                                                                                                             517 | failed_throw:
      518 |     /* Didn't use our arguments, so restore their original refcounts */                                                                                   518 |     /* Didn't use our arguments, so restore their original refcounts */
      519 |     Py_DECREF(typ);                                                                                                                                       519 |     Py_DECREF(typ);
      519 +     _Py_DECREF("Objects/genobject.c", 519, ((PyObject*)(typ)));                                                                                           519 +     _Py_DECREF("Objects/genobject.c", 519, ((PyObject*)(typ)));
      520 |     Py_XDECREF(val);                                                                                                                                      520 |     Py_XDECREF(val);
      520 +     _Py_XDECREF(((PyObject*)(val)));                                                                                                                      520 +     _Py_XDECREF(((PyObject*)(val)));
      521 |     Py_XDECREF(tb);                                                                                                                                       521 |     Py_XDECREF(tb);
      521 +     _Py_XDECREF(((PyObject*)(tb)));                                                                                                                       521 +     _Py_XDECREF(((PyObject*)(tb)));
      522 |     return NULL;                                                                                                                                          522 |     return NULL;
      522 +     return 0;                                                                                                                                             522 +     return 0;
      523 | }                                                                                                                                                         523 | }
      524 |                                                                                                                                                           524 |
      525 |                                                                                                                                                           525 |
      526 | static PyObject *                                                                                                                                         526 | static PyObject *
      527 | gen_throw(PyGenObject *gen, PyObject *args)                                                                                                               527 | gen_throw(PyGenObject *gen, PyObject *args)
      528 | {                                                                                                                                                         528 | {
      529 |     PyObject *typ;                                                                                                                                        529 |     PyObject *typ;
      530 |     PyObject *tb = NULL;                                                                                                                                  530 |     PyObject *tb = NULL;
      530 +     PyObject *tb = 0;                                                                                                                                     530 +     PyObject *tb = 0;
      531 |     PyObject *val = NULL;                                                                                                                                 531 |     PyObject *val = NULL;
      531 +     PyObject *val = 0;                                                                                                                                    531 +     PyObject *val = 0;
      532 |                                                                                                                                                           532 |
      533 |     if (!PyArg_UnpackTuple(args, "throw", 1, 3, &typ, &val, &tb)) {                                                                                       533 |     if (!PyArg_UnpackTuple(args, "throw", 1, 3, &typ, &val, &tb)) {
      534 |         return NULL;                                                                                                                                      534 |         return NULL;
      534 +         return 0;                                                                                                                                         534 +         return 0;
      535 |     }                                                                                                                                                     535 |     }
      536 |                                                                                                                                                           536 |
      537 |     return _gen_throw(gen, 1, typ, val, tb);                                                                                                              537 |     return _gen_throw(gen, 1, typ, val, tb);
      538 | }                                                                                                                                                         538 | }
"Objects/genobject.c", line 538.1: 1506-412 (I) Referenced variable "typ", which was not initialized in its declaration.                                        "Objects/genobject.c", line 538.1: 1506-412 (I) Referenced variable "typ", which was not initialized in its declaration.
      539 |                                                                                                                                                           539 |
      540 |                                                                                                                                                           540 |
      541 | static PyObject *                                                                                                                                         541 | static PyObject *
      542 | gen_iternext(PyGenObject *gen)                                                                                                                            542 | gen_iternext(PyGenObject *gen)
      543 | {                                                                                                                                                         543 | {
      544 |     return gen_send_ex(gen, NULL, 0, 0);                                                                                                                  544 |     return gen_send_ex(gen, NULL, 0, 0);
      544 +     return gen_send_ex(gen, 0, 0, 0);                                                                                                                     544 +     return gen_send_ex(gen, 0, 0, 0);
      545 | }                                                                                                                                                         545 | }
      546 |                                                                                                                                                           546 |
      547 | /*                                                                                                                                                        547 | /*
      548 |  * Set StopIteration with specified value.  Value can be arbitrary object                                                                                 548 |  * Set StopIteration with specified value.  Value can be arbitrary object
      549 |  * or NULL.                                                                                                                                               549 |  * or NULL.
      550 |  *                                                                                                                                                        550 |  *
      551 |  * Returns 0 if StopIteration is set and -1 if any other exception is set.                                                                                551 |  * Returns 0 if StopIteration is set and -1 if any other exception is set.
      552 |  */                                                                                                                                                       552 |  */
      553 | int                                                                                                                                                       553 | int
      554 | _PyGen_SetStopIterationValue(PyObject *value)                                                                                                             554 | _PyGen_SetStopIterationValue(PyObject *value)
      555 | {                                                                                                                                                         555 | {







Wed Apr 15 07:30:04 CDT 2020  Page 17


      556 |     PyObject *e;                                                                                                                                          556 |     PyObject *e;
      557 |                                                                                                                                                           557 |
      558 |     if (value == NULL ||                                                                                                                                  558 |     if (value == NULL ||
      558 +     if (value == 0 ||                                                                                                                                     558 +     if (value == 0 ||
      559 |         (!PyTuple_Check(value) && !PyExceptionInstance_Check(value)))                                                                                     559 |         (!PyTuple_Check(value) && !PyExceptionInstance_Check(value)))
      559 +         (!PyType_HasFeature((((PyObject*)(value))->ob_type), (1UL << 26)) && !PyType_HasFeature((((PyObject*)(value))->ob_type), (1UL << 30))))           559 +         (!PyType_HasFeature((((PyObject*)(value))->ob_type), (1UL << 26)) && !PyType_HasFeature((((PyObject*)(value))->ob_type), (1UL << 30))))
      560 |     {                                                                                                                                                     560 |     {
      561 |         /* Delay exception instantiation if we can */                                                                                                     561 |         /* Delay exception instantiation if we can */
      562 |         PyErr_SetObject(PyExc_StopIteration, value);                                                                                                      562 |         PyErr_SetObject(PyExc_StopIteration, value);
      563 |         return 0;                                                                                                                                         563 |         return 0;
      564 |     }                                                                                                                                                     564 |     }
      565 |     /* Construct an exception instance manually with                                                                                                      565 |     /* Construct an exception instance manually with
      566 |      * PyObject_CallOneArg and pass it to PyErr_SetObject.                                                                                                566 |      * PyObject_CallOneArg and pass it to PyErr_SetObject.
      567 |      *                                                                                                                                                    567 |      *
      568 |      * We do this to handle a situation when "value" is a tuple, in which                                                                                 568 |      * We do this to handle a situation when "value" is a tuple, in which
      569 |      * case PyErr_SetObject would set the value of StopIteration to                                                                                       569 |      * case PyErr_SetObject would set the value of StopIteration to
      570 |      * the first element of the tuple.                                                                                                                    570 |      * the first element of the tuple.
      571 |      *                                                                                                                                                    571 |      *
      572 |      * (See PyErr_SetObject/_PyErr_CreateException code for details.)                                                                                     572 |      * (See PyErr_SetObject/_PyErr_CreateException code for details.)
      573 |      */                                                                                                                                                   573 |      */
      574 |     e = PyObject_CallOneArg(PyExc_StopIteration, value);                                                                                                  574 |     e = PyObject_CallOneArg(PyExc_StopIteration, value);
      575 |     if (e == NULL) {                                                                                                                                      575 |     if (e == NULL) {
      575 +     if (e == 0) {                                                                                                                                         575 +     if (e == 0) {
      576 |         return -1;                                                                                                                                        576 |         return -1;
      577 |     }                                                                                                                                                     577 |     }
      578 |     PyErr_SetObject(PyExc_StopIteration, e);                                                                                                              578 |     PyErr_SetObject(PyExc_StopIteration, e);
      579 |     Py_DECREF(e);                                                                                                                                         579 |     Py_DECREF(e);
      579 +     _Py_DECREF("Objects/genobject.c", 579, ((PyObject*)(e)));                                                                                             579 +     _Py_DECREF("Objects/genobject.c", 579, ((PyObject*)(e)));
      580 |     return 0;                                                                                                                                             580 |     return 0;
      581 | }                                                                                                                                                         581 | }
"Objects/genobject.c", line 581.1: 1506-412 (I) Referenced variable "e", which was not initialized in its declaration.                                          "Objects/genobject.c", line 581.1: 1506-412 (I) Referenced variable "e", which was not initialized in its declaration.
      582 |                                                                                                                                                           582 |
      583 | /*                                                                                                                                                        583 | /*
      584 |  *   If StopIteration exception is set, fetches its 'value'                                                                                               584 |  *   If StopIteration exception is set, fetches its 'value'
      585 |  *   attribute if any, otherwise sets pvalue to None.                                                                                                     585 |  *   attribute if any, otherwise sets pvalue to None.
      586 |  *                                                                                                                                                        586 |  *
      587 |  *   Returns 0 if no exception or StopIteration is set.                                                                                                   587 |  *   Returns 0 if no exception or StopIteration is set.
      588 |  *   If any other exception is set, returns -1 and leaves                                                                                                 588 |  *   If any other exception is set, returns -1 and leaves
      589 |  *   pvalue unchanged.                                                                                                                                    589 |  *   pvalue unchanged.
      590 |  */                                                                                                                                                       590 |  */
      591 |                                                                                                                                                           591 |
      592 | int                                                                                                                                                       592 | int
      593 | _PyGen_FetchStopIterationValue(PyObject **pvalue)                                                                                                         593 | _PyGen_FetchStopIterationValue(PyObject **pvalue)
      594 | {                                                                                                                                                         594 | {
      595 |     PyObject *et, *ev, *tb;                                                                                                                               595 |     PyObject *et, *ev, *tb;
      596 |     PyObject *value = NULL;                                                                                                                               596 |     PyObject *value = NULL;
      596 +     PyObject *value = 0;                                                                                                                                  596 +     PyObject *value = 0;
      597 |                                                                                                                                                           597 |
      598 |     if (PyErr_ExceptionMatches(PyExc_StopIteration)) {                                                                                                    598 |     if (PyErr_ExceptionMatches(PyExc_StopIteration)) {
      599 |         PyErr_Fetch(&et, &ev, &tb);                                                                                                                       599 |         PyErr_Fetch(&et, &ev, &tb);
      600 |         if (ev) {                                                                                                                                         600 |         if (ev) {
      601 |             /* exception will usually be normalised already */                                                                                            601 |             /* exception will usually be normalised already */
      602 |             if (PyObject_TypeCheck(ev, (PyTypeObject *) et)) {                                                                                            602 |             if (PyObject_TypeCheck(ev, (PyTypeObject *) et)) {
      602 +             if ((_Py_IS_TYPE(((const PyObject*)(ev)), (PyTypeObject *) et) || PyType_IsSubtype((((PyObject*)(ev))->ob_type), ((PyTypeObject *) et))       602 +             if ((_Py_IS_TYPE(((const PyObject*)(ev)), (PyTypeObject *) et) || PyType_IsSubtype((((PyObject*)(ev))->ob_type), ((PyTypeObject *) et))
"Objects/genobject.c", line 602.17: 1506-495 (I) Pointer type conversion found.                                                                                 "Objects/genobject.c", line 602.17: 1506-495 (I) Pointer type conversion found.
"Objects/genobject.c", line 602.17: 1506-374 (I) Pointer types "const struct _object*" and "struct _object*" are not compatible.                                "Objects/genobject.c", line 602.17: 1506-374 (I) Pointer types "const struct _object*" and "struct _object*" are not compatible.







Wed Apr 15 07:30:04 CDT 2020  Page 18


"Objects/genobject.c", line 602.40: 1506-495 (I) Pointer type conversion found.                                                                                 "Objects/genobject.c", line 602.40: 1506-495 (I) Pointer type conversion found.
"Objects/genobject.c", line 602.40: 1506-374 (I) Pointer types "struct _typeobject*" and "struct _object*" are not compatible.                                  "Objects/genobject.c", line 602.40: 1506-374 (I) Pointer types "struct _typeobject*" and "struct _object*" are not compatible.
"Objects/genobject.c", line 602.17: 1506-495 (I) Pointer type conversion found.                                                                                 "Objects/genobject.c", line 602.17: 1506-495 (I) Pointer type conversion found.
"Objects/genobject.c", line 602.17: 1506-374 (I) Pointer types "struct _typeobject*" and "struct _object*" are not compatible.                                  "Objects/genobject.c", line 602.17: 1506-374 (I) Pointer types "struct _typeobject*" and "struct _object*" are not compatible.
      603 |                 value = ((PyStopIterationObject *)ev)->value;                                                                                             603 |                 value = ((PyStopIterationObject *)ev)->value;
"Objects/genobject.c", line 603.25: 1506-495 (I) Pointer type conversion found.                                                                                 "Objects/genobject.c", line 603.25: 1506-495 (I) Pointer type conversion found.
"Objects/genobject.c", line 603.25: 1506-374 (I) Pointer types "struct {...}*" and "struct _object*" are not compatible.                                        "Objects/genobject.c", line 603.25: 1506-374 (I) Pointer types "struct {...}*" and "struct _object*" are not compatible.
      604 |                 Py_INCREF(value);                                                                                                                         604 |                 Py_INCREF(value);
      604 +                 _Py_INCREF(((PyObject*)(value)));                                                                                                         604 +                 _Py_INCREF(((PyObject*)(value)));
      605 |                 Py_DECREF(ev);                                                                                                                            605 |                 Py_DECREF(ev);
      605 +                 _Py_DECREF("Objects/genobject.c", 605, ((PyObject*)(ev)));                                                                                605 +                 _Py_DECREF("Objects/genobject.c", 605, ((PyObject*)(ev)));
      606 |             } else if (et == PyExc_StopIteration && !PyTuple_Check(ev)) {                                                                                 606 |             } else if (et == PyExc_StopIteration && !PyTuple_Check(ev)) {
      606 +             } else if (et == PyExc_StopIteration && !PyType_HasFeature((((PyObject*)(ev))->ob_type), (1UL << 26))) {                                      606 +             } else if (et == PyExc_StopIteration && !PyType_HasFeature((((PyObject*)(ev))->ob_type), (1UL << 26))) {
      607 |                 /* Avoid normalisation and take ev as value.                                                                                              607 |                 /* Avoid normalisation and take ev as value.
      608 |                  *                                                                                                                                        608 |                  *
      609 |                  * Normalization is required if the value is a tuple, in                                                                                  609 |                  * Normalization is required if the value is a tuple, in
      610 |                  * that case the value of StopIteration would be set to                                                                                   610 |                  * that case the value of StopIteration would be set to
      611 |                  * the first element of the tuple.                                                                                                        611 |                  * the first element of the tuple.
      612 |                  *                                                                                                                                        612 |                  *
      613 |                  * (See _PyErr_CreateException code for details.)                                                                                         613 |                  * (See _PyErr_CreateException code for details.)
      614 |                  */                                                                                                                                       614 |                  */
      615 |                 value = ev;                                                                                                                               615 |                 value = ev;
      616 |             } else {                                                                                                                                      616 |             } else {
      617 |                 /* normalisation required */                                                                                                              617 |                 /* normalisation required */
      618 |                 PyErr_NormalizeException(&et, &ev, &tb);                                                                                                  618 |                 PyErr_NormalizeException(&et, &ev, &tb);
      619 |                 if (!PyObject_TypeCheck(ev, (PyTypeObject *)PyExc_StopIteration)) {                                                                       619 |                 if (!PyObject_TypeCheck(ev, (PyTypeObject *)PyExc_StopIteration)) {
      619 +                 if (!(_Py_IS_TYPE(((const PyObject*)(ev)), (PyTypeObject *)PyExc_StopIteration) || PyType_IsSubtype((((PyObject*)(ev))->ob_type), (       619 +                 if (!(_Py_IS_TYPE(((const PyObject*)(ev)), (PyTypeObject *)PyExc_StopIteration) || PyType_IsSubtype((((PyObject*)(ev))->ob_type), (
"Objects/genobject.c", line 619.22: 1506-495 (I) Pointer type conversion found.                                                                                 "Objects/genobject.c", line 619.22: 1506-495 (I) Pointer type conversion found.
"Objects/genobject.c", line 619.22: 1506-374 (I) Pointer types "const struct _object*" and "struct _object*" are not compatible.                                "Objects/genobject.c", line 619.22: 1506-374 (I) Pointer types "const struct _object*" and "struct _object*" are not compatible.
"Objects/genobject.c", line 619.45: 1506-495 (I) Pointer type conversion found.                                                                                 "Objects/genobject.c", line 619.45: 1506-495 (I) Pointer type conversion found.
"Objects/genobject.c", line 619.45: 1506-374 (I) Pointer types "struct _typeobject*" and "struct _object*" are not compatible.                                  "Objects/genobject.c", line 619.45: 1506-374 (I) Pointer types "struct _typeobject*" and "struct _object*" are not compatible.
"Objects/genobject.c", line 619.22: 1506-495 (I) Pointer type conversion found.                                                                                 "Objects/genobject.c", line 619.22: 1506-495 (I) Pointer type conversion found.
"Objects/genobject.c", line 619.22: 1506-374 (I) Pointer types "struct _typeobject*" and "struct _object*" are not compatible.                                  "Objects/genobject.c", line 619.22: 1506-374 (I) Pointer types "struct _typeobject*" and "struct _object*" are not compatible.
      620 |                     PyErr_Restore(et, ev, tb);                                                                                                            620 |                     PyErr_Restore(et, ev, tb);
      621 |                     return -1;                                                                                                                            621 |                     return -1;
      622 |                 }                                                                                                                                         622 |                 }
      623 |                 value = ((PyStopIterationObject *)ev)->value;                                                                                             623 |                 value = ((PyStopIterationObject *)ev)->value;
"Objects/genobject.c", line 623.25: 1506-495 (I) Pointer type conversion found.                                                                                 "Objects/genobject.c", line 623.25: 1506-495 (I) Pointer type conversion found.
"Objects/genobject.c", line 623.25: 1506-374 (I) Pointer types "struct {...}*" and "struct _object*" are not compatible.                                        "Objects/genobject.c", line 623.25: 1506-374 (I) Pointer types "struct {...}*" and "struct _object*" are not compatible.
      624 |                 Py_INCREF(value);                                                                                                                         624 |                 Py_INCREF(value);
      624 +                 _Py_INCREF(((PyObject*)(value)));                                                                                                         624 +                 _Py_INCREF(((PyObject*)(value)));
      625 |                 Py_DECREF(ev);                                                                                                                            625 |                 Py_DECREF(ev);
      625 +                 _Py_DECREF("Objects/genobject.c", 625, ((PyObject*)(ev)));                                                                                625 +                 _Py_DECREF("Objects/genobject.c", 625, ((PyObject*)(ev)));
      626 |             }                                                                                                                                             626 |             }
      627 |         }                                                                                                                                                 627 |         }
      628 |         Py_XDECREF(et);                                                                                                                                   628 |         Py_XDECREF(et);
      628 +         _Py_XDECREF(((PyObject*)(et)));                                                                                                                   628 +         _Py_XDECREF(((PyObject*)(et)));
      629 |         Py_XDECREF(tb);                                                                                                                                   629 |         Py_XDECREF(tb);
      629 +         _Py_XDECREF(((PyObject*)(tb)));                                                                                                                   629 +         _Py_XDECREF(((PyObject*)(tb)));
      630 |     } else if (PyErr_Occurred()) {                                                                                                                        630 |     } else if (PyErr_Occurred()) {
      631 |         return -1;                                                                                                                                        631 |         return -1;
      632 |     }                                                                                                                                                     632 |     }
      633 |     if (value == NULL) {                                                                                                                                  633 |     if (value == NULL) {
      633 +     if (value == 0) {                                                                                                                                     633 +     if (value == 0) {
      634 |         value = Py_None;                                                                                                                                  634 |         value = Py_None;
      634 +         value = (&_Py_NoneStruct);                                                                                                                        634 +         value = (&_Py_NoneStruct);







Wed Apr 15 07:30:04 CDT 2020  Page 19


      635 |         Py_INCREF(value);                                                                                                                                 635 |         Py_INCREF(value);
      635 +         _Py_INCREF(((PyObject*)(value)));                                                                                                                 635 +         _Py_INCREF(((PyObject*)(value)));
      636 |     }                                                                                                                                                     636 |     }
      637 |     *pvalue = value;                                                                                                                                      637 |     *pvalue = value;
      638 |     return 0;                                                                                                                                             638 |     return 0;
      639 | }                                                                                                                                                         639 | }
"Objects/genobject.c", line 639.1: 1506-412 (I) Referenced variable "tb", which was not initialized in its declaration.                                         "Objects/genobject.c", line 639.1: 1506-412 (I) Referenced variable "tb", which was not initialized in its declaration.
"Objects/genobject.c", line 639.1: 1506-412 (I) Referenced variable "ev", which was not initialized in its declaration.                                         "Objects/genobject.c", line 639.1: 1506-412 (I) Referenced variable "ev", which was not initialized in its declaration.
"Objects/genobject.c", line 639.1: 1506-412 (I) Referenced variable "et", which was not initialized in its declaration.                                         "Objects/genobject.c", line 639.1: 1506-412 (I) Referenced variable "et", which was not initialized in its declaration.
      640 |                                                                                                                                                           640 |
      641 | static PyObject *                                                                                                                                         641 | static PyObject *
      642 | gen_repr(PyGenObject *gen)                                                                                                                                642 | gen_repr(PyGenObject *gen)
      643 | {                                                                                                                                                         643 | {
      644 |     return PyUnicode_FromFormat("<generator object %S at %p>",                                                                                            644 |     return PyUnicode_FromFormat("<generator object %S at %p>",
      645 |                                 gen->gi_qualname, gen);                                                                                                   645 |                                 gen->gi_qualname, gen);
      646 | }                                                                                                                                                         646 | }
      647 |                                                                                                                                                           647 |
      648 | static PyObject *                                                                                                                                         648 | static PyObject *
      649 | gen_get_name(PyGenObject *op, void *Py_UNUSED(ignored))                                                                                                   649 | gen_get_name(PyGenObject *op, void *Py_UNUSED(ignored))
      649 + gen_get_name(PyGenObject *op, void *_unused_ignored)                                                                                                      649 + gen_get_name(PyGenObject *op, void *_unused_ignored)
      650 | {                                                                                                                                                         650 | {
      651 |     Py_INCREF(op->gi_name);                                                                                                                               651 |     Py_INCREF(op->gi_name);
      651 +     _Py_INCREF(((PyObject*)(op->gi_name)));                                                                                                               651 +     _Py_INCREF(((PyObject*)(op->gi_name)));
      652 |     return op->gi_name;                                                                                                                                   652 |     return op->gi_name;
      653 | }                                                                                                                                                         653 | }
"Objects/genobject.c", line 653.1: 1506-414 (I) The parameter "_unused_ignored" is never referenced.                                                            "Objects/genobject.c", line 653.1: 1506-414 (I) The parameter "_unused_ignored" is never referenced.
      654 |                                                                                                                                                           654 |
      655 | static int                                                                                                                                                655 | static int
      656 | gen_set_name(PyGenObject *op, PyObject *value, void *Py_UNUSED(ignored))                                                                                  656 | gen_set_name(PyGenObject *op, PyObject *value, void *Py_UNUSED(ignored))
      656 + gen_set_name(PyGenObject *op, PyObject *value, void *_unused_ignored)                                                                                     656 + gen_set_name(PyGenObject *op, PyObject *value, void *_unused_ignored)
      657 | {                                                                                                                                                         657 | {
      658 |     /* Not legal to del gen.gi_name or to set it to anything                                                                                              658 |     /* Not legal to del gen.gi_name or to set it to anything
      659 |      * other than a string object. */                                                                                                                     659 |      * other than a string object. */
      660 |     if (value == NULL || !PyUnicode_Check(value)) {                                                                                                       660 |     if (value == NULL || !PyUnicode_Check(value)) {
      660 +     if (value == 0 || !PyType_HasFeature((((PyObject*)(value))->ob_type), (1UL << 28))) {                                                                 660 +     if (value == 0 || !PyType_HasFeature((((PyObject*)(value))->ob_type), (1UL << 28))) {
      661 |         PyErr_SetString(PyExc_TypeError,                                                                                                                  661 |         PyErr_SetString(PyExc_TypeError,
      662 |                         "__name__ must be set to a string object");                                                                                       662 |                         "__name__ must be set to a string object");
      663 |         return -1;                                                                                                                                        663 |         return -1;
      664 |     }                                                                                                                                                     664 |     }
      665 |     Py_INCREF(value);                                                                                                                                     665 |     Py_INCREF(value);
      665 +     _Py_INCREF(((PyObject*)(value)));                                                                                                                     665 +     _Py_INCREF(((PyObject*)(value)));
      666 |     Py_XSETREF(op->gi_name, value);                                                                                                                       666 |     Py_XSETREF(op->gi_name, value);
      666 +     do { PyObject *_py_tmp = ((PyObject*)(op->gi_name)); (op->gi_name) = (value); _Py_XDECREF(((PyObject*)(_py_tmp))); } while (0);                       666 +     do { PyObject *_py_tmp = ((PyObject*)(op->gi_name)); (op->gi_name) = (value); _Py_XDECREF(((PyObject*)(_py_tmp))); } while (0);
"Objects/genobject.c", line 666.5: 1506-425 (I) The condition is always false.                                                                                  "Objects/genobject.c", line 666.5: 1506-425 (I) The condition is always false.
      667 |     return 0;                                                                                                                                             667 |     return 0;
      668 | }                                                                                                                                                         668 | }
"Objects/genobject.c", line 668.1: 1506-414 (I) The parameter "_unused_ignored" is never referenced.                                                            "Objects/genobject.c", line 668.1: 1506-414 (I) The parameter "_unused_ignored" is never referenced.
      669 |                                                                                                                                                           669 |
      670 | static PyObject *                                                                                                                                         670 | static PyObject *
      671 | gen_get_qualname(PyGenObject *op, void *Py_UNUSED(ignored))                                                                                               671 | gen_get_qualname(PyGenObject *op, void *Py_UNUSED(ignored))
      671 + gen_get_qualname(PyGenObject *op, void *_unused_ignored)                                                                                                  671 + gen_get_qualname(PyGenObject *op, void *_unused_ignored)
      672 | {                                                                                                                                                         672 | {
      673 |     Py_INCREF(op->gi_qualname);                                                                                                                           673 |     Py_INCREF(op->gi_qualname);
      673 +     _Py_INCREF(((PyObject*)(op->gi_qualname)));                                                                                                           673 +     _Py_INCREF(((PyObject*)(op->gi_qualname)));
      674 |     return op->gi_qualname;                                                                                                                               674 |     return op->gi_qualname;
      675 | }                                                                                                                                                         675 | }







Wed Apr 15 07:30:04 CDT 2020  Page 20


"Objects/genobject.c", line 675.1: 1506-414 (I) The parameter "_unused_ignored" is never referenced.                                                            "Objects/genobject.c", line 675.1: 1506-414 (I) The parameter "_unused_ignored" is never referenced.
      676 |                                                                                                                                                           676 |
      677 | static int                                                                                                                                                677 | static int
      678 | gen_set_qualname(PyGenObject *op, PyObject *value, void *Py_UNUSED(ignored))                                                                              678 | gen_set_qualname(PyGenObject *op, PyObject *value, void *Py_UNUSED(ignored))
      678 + gen_set_qualname(PyGenObject *op, PyObject *value, void *_unused_ignored)                                                                                 678 + gen_set_qualname(PyGenObject *op, PyObject *value, void *_unused_ignored)
      679 | {                                                                                                                                                         679 | {
      680 |     /* Not legal to del gen.__qualname__ or to set it to anything                                                                                         680 |     /* Not legal to del gen.__qualname__ or to set it to anything
      681 |      * other than a string object. */                                                                                                                     681 |      * other than a string object. */
      682 |     if (value == NULL || !PyUnicode_Check(value)) {                                                                                                       682 |     if (value == NULL || !PyUnicode_Check(value)) {
      682 +     if (value == 0 || !PyType_HasFeature((((PyObject*)(value))->ob_type), (1UL << 28))) {                                                                 682 +     if (value == 0 || !PyType_HasFeature((((PyObject*)(value))->ob_type), (1UL << 28))) {
      683 |         PyErr_SetString(PyExc_TypeError,                                                                                                                  683 |         PyErr_SetString(PyExc_TypeError,
      684 |                         "__qualname__ must be set to a string object");                                                                                   684 |                         "__qualname__ must be set to a string object");
      685 |         return -1;                                                                                                                                        685 |         return -1;
      686 |     }                                                                                                                                                     686 |     }
      687 |     Py_INCREF(value);                                                                                                                                     687 |     Py_INCREF(value);
      687 +     _Py_INCREF(((PyObject*)(value)));                                                                                                                     687 +     _Py_INCREF(((PyObject*)(value)));
      688 |     Py_XSETREF(op->gi_qualname, value);                                                                                                                   688 |     Py_XSETREF(op->gi_qualname, value);
      688 +     do { PyObject *_py_tmp = ((PyObject*)(op->gi_qualname)); (op->gi_qualname) = (value); _Py_XDECREF(((PyObject*)(_py_tmp))); } while (0);               688 +     do { PyObject *_py_tmp = ((PyObject*)(op->gi_qualname)); (op->gi_qualname) = (value); _Py_XDECREF(((PyObject*)(_py_tmp))); } while (0);
"Objects/genobject.c", line 688.5: 1506-425 (I) The condition is always false.                                                                                  "Objects/genobject.c", line 688.5: 1506-425 (I) The condition is always false.
      689 |     return 0;                                                                                                                                             689 |     return 0;
      690 | }                                                                                                                                                         690 | }
"Objects/genobject.c", line 690.1: 1506-414 (I) The parameter "_unused_ignored" is never referenced.                                                            "Objects/genobject.c", line 690.1: 1506-414 (I) The parameter "_unused_ignored" is never referenced.
      691 |                                                                                                                                                           691 |
      692 | static PyObject *                                                                                                                                         692 | static PyObject *
      693 | gen_getyieldfrom(PyGenObject *gen, void *Py_UNUSED(ignored))                                                                                              693 | gen_getyieldfrom(PyGenObject *gen, void *Py_UNUSED(ignored))
      693 + gen_getyieldfrom(PyGenObject *gen, void *_unused_ignored)                                                                                                 693 + gen_getyieldfrom(PyGenObject *gen, void *_unused_ignored)
      694 | {                                                                                                                                                         694 | {
      695 |     PyObject *yf = _PyGen_yf(gen);                                                                                                                        695 |     PyObject *yf = _PyGen_yf(gen);
      696 |     if (yf == NULL)                                                                                                                                       696 |     if (yf == NULL)
      696 +     if (yf == 0)                                                                                                                                          696 +     if (yf == 0)
      697 |         Py_RETURN_NONE;                                                                                                                                   697 |         Py_RETURN_NONE;
      697 +         return _Py_INCREF(((PyObject*)((&_Py_NoneStruct)))), (&_Py_NoneStruct);                                                                           697 +         return _Py_INCREF(((PyObject*)((&_Py_NoneStruct)))), (&_Py_NoneStruct);
      698 |     return yf;                                                                                                                                            698 |     return yf;
      699 | }                                                                                                                                                         699 | }
"Objects/genobject.c", line 699.1: 1506-414 (I) The parameter "_unused_ignored" is never referenced.                                                            "Objects/genobject.c", line 699.1: 1506-414 (I) The parameter "_unused_ignored" is never referenced.
      700 |                                                                                                                                                           700 |
      701 | static PyGetSetDef gen_getsetlist[] = {                                                                                                                   701 | static PyGetSetDef gen_getsetlist[] = {
"Objects/genobject.c", line 701.37: 1506-446 (I) Array element(s) [0] will be initialized with a default value of 0.                                            "Objects/genobject.c", line 701.37: 1506-446 (I) Array element(s) [0] will be initialized with a default value of 0.
"Objects/genobject.c", line 701.37: 1506-446 (I) Array element(s) [1] will be initialized with a default value of 0.                                            "Objects/genobject.c", line 701.37: 1506-446 (I) Array element(s) [1] will be initialized with a default value of 0.
"Objects/genobject.c", line 701.37: 1506-446 (I) Array element(s) [2] will be initialized with a default value of 0.                                            "Objects/genobject.c", line 701.37: 1506-446 (I) Array element(s) [2] will be initialized with a default value of 0.
"Objects/genobject.c", line 701.37: 1506-446 (I) Array element(s) [3] will be initialized with a default value of 0.                                            "Objects/genobject.c", line 701.37: 1506-446 (I) Array element(s) [3] will be initialized with a default value of 0.
      702 |     {"__name__", (getter)gen_get_name, (setter)gen_set_name,                                                                                              702 |     {"__name__", (getter)gen_get_name, (setter)gen_set_name,
      703 |      PyDoc_STR("name of the generator")},                                                                                                                 703 |      PyDoc_STR("name of the generator")},
      703 +      "name of the generator"},                                                                                                                            703 +      "name of the generator"},
"Objects/genobject.c", line 703.40: 1506-447 (I) The member(s) starting from "closure" will be initialized with a default value of 0.                           "Objects/genobject.c", line 703.40: 1506-447 (I) The member(s) starting from "closure" will be initialized with a default value of 0.
      704 |     {"__qualname__", (getter)gen_get_qualname, (setter)gen_set_qualname,                                                                                  704 |     {"__qualname__", (getter)gen_get_qualname, (setter)gen_set_qualname,
      705 |      PyDoc_STR("qualified name of the generator")},                                                                                                       705 |      PyDoc_STR("qualified name of the generator")},
      705 +      "qualified name of the generator"},                                                                                                                  705 +      "qualified name of the generator"},
"Objects/genobject.c", line 705.50: 1506-447 (I) The member(s) starting from "closure" will be initialized with a default value of 0.                           "Objects/genobject.c", line 705.50: 1506-447 (I) The member(s) starting from "closure" will be initialized with a default value of 0.
      706 |     {"gi_yieldfrom", (getter)gen_getyieldfrom, NULL,                                                                                                      706 |     {"gi_yieldfrom", (getter)gen_getyieldfrom, NULL,
      706 +     {"gi_yieldfrom", (getter)gen_getyieldfrom, 0,                                                                                                         706 +     {"gi_yieldfrom", (getter)gen_getyieldfrom, 0,
      707 |      PyDoc_STR("object being iterated by yield from, or None")},                                                                                          707 |      PyDoc_STR("object being iterated by yield from, or None")},
      707 +      "object being iterated by yield from, or None"},                                                                                                     707 +      "object being iterated by yield from, or None"},
"Objects/genobject.c", line 707.63: 1506-447 (I) The member(s) starting from "closure" will be initialized with a default value of 0.                           "Objects/genobject.c", line 707.63: 1506-447 (I) The member(s) starting from "closure" will be initialized with a default value of 0.
      708 |     {NULL} /* Sentinel */                                                                                                                                 708 |     {NULL} /* Sentinel */
      708 +     {0} /* Sentinel */                                                                                                                                    708 +     {0} /* Sentinel */







Wed Apr 15 07:30:04 CDT 2020  Page 21


"Objects/genobject.c", line 708.10: 1506-447 (I) The member(s) starting from "get" will be initialized with a default value of 0.                               "Objects/genobject.c", line 708.10: 1506-447 (I) The member(s) starting from "get" will be initialized with a default value of 0.
      709 | };                                                                                                                                                        709 | };
      710 |                                                                                                                                                           710 |
      711 | static PyMemberDef gen_memberlist[] = {                                                                                                                   711 | static PyMemberDef gen_memberlist[] = {
"Objects/genobject.c", line 711.37: 1506-446 (I) Array element(s) [0] will be initialized with a default value of 0.                                            "Objects/genobject.c", line 711.37: 1506-446 (I) Array element(s) [0] will be initialized with a default value of 0.
"Objects/genobject.c", line 711.37: 1506-446 (I) Array element(s) [1] will be initialized with a default value of 0.                                            "Objects/genobject.c", line 711.37: 1506-446 (I) Array element(s) [1] will be initialized with a default value of 0.
"Objects/genobject.c", line 711.37: 1506-446 (I) Array element(s) [2] will be initialized with a default value of 0.                                            "Objects/genobject.c", line 711.37: 1506-446 (I) Array element(s) [2] will be initialized with a default value of 0.
"Objects/genobject.c", line 711.37: 1506-446 (I) Array element(s) [3] will be initialized with a default value of 0.                                            "Objects/genobject.c", line 711.37: 1506-446 (I) Array element(s) [3] will be initialized with a default value of 0.
      712 |     {"gi_frame",     T_OBJECT, offsetof(PyGenObject, gi_frame),    READONLY},                                                                             712 |     {"gi_frame",     T_OBJECT, offsetof(PyGenObject, gi_frame),    READONLY},
      712 +     {"gi_frame",     6, (size_t)&(((PyGenObject *)0)->gi_frame),    1},                                                                                   712 +     {"gi_frame",     6, (size_t)&(((PyGenObject *)0)->gi_frame),    1},
"Objects/genobject.c", line 712.76: 1506-447 (I) The member(s) starting from "doc" will be initialized with a default value of 0.                               "Objects/genobject.c", line 712.76: 1506-447 (I) The member(s) starting from "doc" will be initialized with a default value of 0.
      713 |     {"gi_running",   T_BOOL,   offsetof(PyGenObject, gi_running),  READONLY},                                                                             713 |     {"gi_running",   T_BOOL,   offsetof(PyGenObject, gi_running),  READONLY},
      713 +     {"gi_running",   14,   (size_t)&(((PyGenObject *)0)->gi_running),  1},                                                                                713 +     {"gi_running",   14,   (size_t)&(((PyGenObject *)0)->gi_running),  1},
"Objects/genobject.c", line 713.76: 1506-447 (I) The member(s) starting from "doc" will be initialized with a default value of 0.                               "Objects/genobject.c", line 713.76: 1506-447 (I) The member(s) starting from "doc" will be initialized with a default value of 0.
      714 |     {"gi_code",      T_OBJECT, offsetof(PyGenObject, gi_code),     READONLY},                                                                             714 |     {"gi_code",      T_OBJECT, offsetof(PyGenObject, gi_code),     READONLY},
      714 +     {"gi_code",      6, (size_t)&(((PyGenObject *)0)->gi_code),     1},                                                                                   714 +     {"gi_code",      6, (size_t)&(((PyGenObject *)0)->gi_code),     1},
"Objects/genobject.c", line 714.76: 1506-447 (I) The member(s) starting from "doc" will be initialized with a default value of 0.                               "Objects/genobject.c", line 714.76: 1506-447 (I) The member(s) starting from "doc" will be initialized with a default value of 0.
      715 |     {NULL}      /* Sentinel */                                                                                                                            715 |     {NULL}      /* Sentinel */
      715 +     {0}      /* Sentinel */                                                                                                                               715 +     {0}      /* Sentinel */
"Objects/genobject.c", line 715.10: 1506-447 (I) The member(s) starting from "type" will be initialized with a default value of 0.                              "Objects/genobject.c", line 715.10: 1506-447 (I) The member(s) starting from "type" will be initialized with a default value of 0.
      716 | };                                                                                                                                                        716 | };
      717 |                                                                                                                                                           717 |
      718 | static PyMethodDef gen_methods[] = {                                                                                                                      718 | static PyMethodDef gen_methods[] = {
"Objects/genobject.c", line 718.34: 1506-446 (I) Array element(s) [3] will be initialized with a default value of 0.                                            "Objects/genobject.c", line 718.34: 1506-446 (I) Array element(s) [3] will be initialized with a default value of 0.
      719 |     {"send",(PyCFunction)_PyGen_Send, METH_O, send_doc},                                                                                                  719 |     {"send",(PyCFunction)_PyGen_Send, METH_O, send_doc},
      719 +     {"send",(PyCFunction)_PyGen_Send, 0x0008, send_doc},                                                                                                  719 +     {"send",(PyCFunction)_PyGen_Send, 0x0008, send_doc},
      720 |     {"throw",(PyCFunction)gen_throw, METH_VARARGS, throw_doc},                                                                                            720 |     {"throw",(PyCFunction)gen_throw, METH_VARARGS, throw_doc},
      720 +     {"throw",(PyCFunction)gen_throw, 0x0001, throw_doc},                                                                                                  720 +     {"throw",(PyCFunction)gen_throw, 0x0001, throw_doc},
      721 |     {"close",(PyCFunction)gen_close, METH_NOARGS, close_doc},                                                                                             721 |     {"close",(PyCFunction)gen_close, METH_NOARGS, close_doc},
      721 +     {"close",(PyCFunction)gen_close, 0x0004, close_doc},                                                                                                  721 +     {"close",(PyCFunction)gen_close, 0x0004, close_doc},
      722 |     {NULL, NULL}        /* Sentinel */                                                                                                                    722 |     {NULL, NULL}        /* Sentinel */
      722 +     {0, 0}        /* Sentinel */                                                                                                                          722 +     {0, 0}        /* Sentinel */
"Objects/genobject.c", line 722.16: 1506-447 (I) The member(s) starting from "ml_flags" will be initialized with a default value of 0.                          "Objects/genobject.c", line 722.16: 1506-447 (I) The member(s) starting from "ml_flags" will be initialized with a default value of 0.
      723 | };                                                                                                                                                        723 | };
      724 |                                                                                                                                                           724 |
      725 | PyTypeObject PyGen_Type = {                                                                                                                               725 | PyTypeObject PyGen_Type = {
      726 |     PyVarObject_HEAD_INIT(&PyType_Type, 0)                                                                                                                726 |     PyVarObject_HEAD_INIT(&PyType_Type, 0)
      726 +     { {   1, &PyType_Type }, 0 },                                                                                                                         726 +     { {   1, &PyType_Type }, 0 },
      727 |     "generator",                                /* tp_name */                                                                                             727 |     "generator",                                /* tp_name */
      728 |     sizeof(PyGenObject),                        /* tp_basicsize */                                                                                        728 |     sizeof(PyGenObject),                        /* tp_basicsize */
      729 |     0,                                          /* tp_itemsize */                                                                                         729 |     0,                                          /* tp_itemsize */
      730 |     /* methods */                                                                                                                                         730 |     /* methods */
      731 |     (destructor)gen_dealloc,                    /* tp_dealloc */                                                                                          731 |     (destructor)gen_dealloc,                    /* tp_dealloc */
      732 |     0,                                          /* tp_vectorcall_offset */                                                                                732 |     0,                                          /* tp_vectorcall_offset */
      733 |     0,                                          /* tp_getattr */                                                                                          733 |     0,                                          /* tp_getattr */
      734 |     0,                                          /* tp_setattr */                                                                                          734 |     0,                                          /* tp_setattr */
      735 |     0,                                          /* tp_as_async */                                                                                         735 |     0,                                          /* tp_as_async */
      736 |     (reprfunc)gen_repr,                         /* tp_repr */                                                                                             736 |     (reprfunc)gen_repr,                         /* tp_repr */
      737 |     0,                                          /* tp_as_number */                                                                                        737 |     0,                                          /* tp_as_number */
      738 |     0,                                          /* tp_as_sequence */                                                                                      738 |     0,                                          /* tp_as_sequence */
      739 |     0,                                          /* tp_as_mapping */                                                                                       739 |     0,                                          /* tp_as_mapping */
      740 |     0,                                          /* tp_hash */                                                                                             740 |     0,                                          /* tp_hash */
      741 |     0,                                          /* tp_call */                                                                                             741 |     0,                                          /* tp_call */
      742 |     0,                                          /* tp_str */                                                                                              742 |     0,                                          /* tp_str */
      743 |     PyObject_GenericGetAttr,                    /* tp_getattro */                                                                                         743 |     PyObject_GenericGetAttr,                    /* tp_getattro */
      744 |     0,                                          /* tp_setattro */                                                                                         744 |     0,                                          /* tp_setattro */







Wed Apr 15 07:30:04 CDT 2020  Page 22


      745 |     0,                                          /* tp_as_buffer */                                                                                        745 |     0,                                          /* tp_as_buffer */
      746 |     Py_TPFLAGS_DEFAULT | Py_TPFLAGS_HAVE_GC,    /* tp_flags */                                                                                            746 |     Py_TPFLAGS_DEFAULT | Py_TPFLAGS_HAVE_GC,    /* tp_flags */
      746 +     ( 0 | (1UL << 18) | 0) | (1UL << 14),    /* tp_flags */                                                                                               746 +     ( 0 | (1UL << 18) | 0) | (1UL << 14),    /* tp_flags */
      747 |     0,                                          /* tp_doc */                                                                                              747 |     0,                                          /* tp_doc */
      748 |     (traverseproc)gen_traverse,                 /* tp_traverse */                                                                                         748 |     (traverseproc)gen_traverse,                 /* tp_traverse */
      749 |     0,                                          /* tp_clear */                                                                                            749 |     0,                                          /* tp_clear */
      750 |     0,                                          /* tp_richcompare */                                                                                      750 |     0,                                          /* tp_richcompare */
      751 |     offsetof(PyGenObject, gi_weakreflist),      /* tp_weaklistoffset */                                                                                   751 |     offsetof(PyGenObject, gi_weakreflist),      /* tp_weaklistoffset */
      751 +     (size_t)&(((PyGenObject *)0)->gi_weakreflist),      /* tp_weaklistoffset */                                                                           751 +     (size_t)&(((PyGenObject *)0)->gi_weakreflist),      /* tp_weaklistoffset */
      752 |     PyObject_SelfIter,                          /* tp_iter */                                                                                             752 |     PyObject_SelfIter,                          /* tp_iter */
      753 |     (iternextfunc)gen_iternext,                 /* tp_iternext */                                                                                         753 |     (iternextfunc)gen_iternext,                 /* tp_iternext */
      754 |     gen_methods,                                /* tp_methods */                                                                                          754 |     gen_methods,                                /* tp_methods */
      755 |     gen_memberlist,                             /* tp_members */                                                                                          755 |     gen_memberlist,                             /* tp_members */
      756 |     gen_getsetlist,                             /* tp_getset */                                                                                           756 |     gen_getsetlist,                             /* tp_getset */
      757 |     0,                                          /* tp_base */                                                                                             757 |     0,                                          /* tp_base */
      758 |     0,                                          /* tp_dict */                                                                                             758 |     0,                                          /* tp_dict */
      759 |                                                                                                                                                           759 |
      760 |     0,                                          /* tp_descr_get */                                                                                        760 |     0,                                          /* tp_descr_get */
      761 |     0,                                          /* tp_descr_set */                                                                                        761 |     0,                                          /* tp_descr_set */
      762 |     0,                                          /* tp_dictoffset */                                                                                       762 |     0,                                          /* tp_dictoffset */
      763 |     0,                                          /* tp_init */                                                                                             763 |     0,                                          /* tp_init */
      764 |     0,                                          /* tp_alloc */                                                                                            764 |     0,                                          /* tp_alloc */
      765 |     0,                                          /* tp_new */                                                                                              765 |     0,                                          /* tp_new */
      766 |     0,                                          /* tp_free */                                                                                             766 |     0,                                          /* tp_free */
      767 |     0,                                          /* tp_is_gc */                                                                                            767 |     0,                                          /* tp_is_gc */
      768 |     0,                                          /* tp_bases */                                                                                            768 |     0,                                          /* tp_bases */
      769 |     0,                                          /* tp_mro */                                                                                              769 |     0,                                          /* tp_mro */
      770 |     0,                                          /* tp_cache */                                                                                            770 |     0,                                          /* tp_cache */
      771 |     0,                                          /* tp_subclasses */                                                                                       771 |     0,                                          /* tp_subclasses */
      772 |     0,                                          /* tp_weaklist */                                                                                         772 |     0,                                          /* tp_weaklist */
      773 |     0,                                          /* tp_del */                                                                                              773 |     0,                                          /* tp_del */
      774 |     0,                                          /* tp_version_tag */                                                                                      774 |     0,                                          /* tp_version_tag */
      775 |     _PyGen_Finalize,                            /* tp_finalize */                                                                                         775 |     _PyGen_Finalize,                            /* tp_finalize */
      776 | };                                                                                                                                                        776 | };
"Objects/genobject.c", line 776.1: 1506-447 (I) The member(s) starting from "tp_vectorcall" will be initialized with a default value of 0.                      "Objects/genobject.c", line 776.1: 1506-447 (I) The member(s) starting from "tp_vectorcall" will be initialized with a default value of 0.
      777 |                                                                                                                                                           777 |
      778 | static PyObject *                                                                                                                                         778 | static PyObject *
      779 | gen_new_with_qualname(PyTypeObject *type, PyFrameObject *f,                                                                                               779 | gen_new_with_qualname(PyTypeObject *type, PyFrameObject *f,
      780 |                       PyObject *name, PyObject *qualname)                                                                                                 780 |                       PyObject *name, PyObject *qualname)
      781 | {                                                                                                                                                         781 | {
      782 |     PyGenObject *gen = PyObject_GC_New(PyGenObject, type);                                                                                                782 |     PyGenObject *gen = PyObject_GC_New(PyGenObject, type);
      782 +     PyGenObject *gen = ( (PyGenObject *) _PyObject_GC_New(type) );                                                                                        782 +     PyGenObject *gen = ( (PyGenObject *) _PyObject_GC_New(type) );
"Objects/genobject.c", line 782.24: 1506-495 (I) Pointer type conversion found.                                                                                 "Objects/genobject.c", line 782.24: 1506-495 (I) Pointer type conversion found.
"Objects/genobject.c", line 782.24: 1506-374 (I) Pointer types "struct {...}*" and "struct _object*" are not compatible.                                        "Objects/genobject.c", line 782.24: 1506-374 (I) Pointer types "struct {...}*" and "struct _object*" are not compatible.
      783 |     if (gen == NULL) {                                                                                                                                    783 |     if (gen == NULL) {
      783 +     if (gen == 0) {                                                                                                                                       783 +     if (gen == 0) {
      784 |         Py_DECREF(f);                                                                                                                                     784 |         Py_DECREF(f);
      784 +         _Py_DECREF("Objects/genobject.c", 784, ((PyObject*)(f)));                                                                                         784 +         _Py_DECREF("Objects/genobject.c", 784, ((PyObject*)(f)));
"Objects/genobject.c", line 784.9: 1506-495 (I) Pointer type conversion found.                                                                                  "Objects/genobject.c", line 784.9: 1506-495 (I) Pointer type conversion found.
"Objects/genobject.c", line 784.9: 1506-374 (I) Pointer types "struct _object*" and "struct _frame*" are not compatible.                                        "Objects/genobject.c", line 784.9: 1506-374 (I) Pointer types "struct _object*" and "struct _frame*" are not compatible.
      785 |         return NULL;                                                                                                                                      785 |         return NULL;
      785 +         return 0;                                                                                                                                         785 +         return 0;
      786 |     }                                                                                                                                                     786 |     }
      787 |     gen->gi_frame = f;                                                                                                                                    787 |     gen->gi_frame = f;
      788 |     f->f_gen = (PyObject *) gen;                                                                                                                          788 |     f->f_gen = (PyObject *) gen;
"Objects/genobject.c", line 788.16: 1506-495 (I) Pointer type conversion found.                                                                                 "Objects/genobject.c", line 788.16: 1506-495 (I) Pointer type conversion found.







Wed Apr 15 07:30:04 CDT 2020  Page 23


"Objects/genobject.c", line 788.16: 1506-374 (I) Pointer types "struct _object*" and "struct {...}*" are not compatible.                                        "Objects/genobject.c", line 788.16: 1506-374 (I) Pointer types "struct _object*" and "struct {...}*" are not compatible.
      789 |     Py_INCREF(f->f_code);                                                                                                                                 789 |     Py_INCREF(f->f_code);
      789 +     _Py_INCREF(((PyObject*)(f->f_code)));                                                                                                                 789 +     _Py_INCREF(((PyObject*)(f->f_code)));
"Objects/genobject.c", line 789.5: 1506-495 (I) Pointer type conversion found.                                                                                  "Objects/genobject.c", line 789.5: 1506-495 (I) Pointer type conversion found.
"Objects/genobject.c", line 789.5: 1506-374 (I) Pointer types "struct _object*" and "struct {...}*" are not compatible.                                         "Objects/genobject.c", line 789.5: 1506-374 (I) Pointer types "struct _object*" and "struct {...}*" are not compatible.
      790 |     gen->gi_code = (PyObject *)(f->f_code);                                                                                                               790 |     gen->gi_code = (PyObject *)(f->f_code);
"Objects/genobject.c", line 790.20: 1506-495 (I) Pointer type conversion found.                                                                                 "Objects/genobject.c", line 790.20: 1506-495 (I) Pointer type conversion found.
"Objects/genobject.c", line 790.20: 1506-374 (I) Pointer types "struct _object*" and "struct {...}*" are not compatible.                                        "Objects/genobject.c", line 790.20: 1506-374 (I) Pointer types "struct _object*" and "struct {...}*" are not compatible.
      791 |     gen->gi_running = 0;                                                                                                                                  791 |     gen->gi_running = 0;
      792 |     gen->gi_weakreflist = NULL;                                                                                                                           792 |     gen->gi_weakreflist = NULL;
      792 +     gen->gi_weakreflist = 0;                                                                                                                              792 +     gen->gi_weakreflist = 0;
      793 |     gen->gi_exc_state.exc_type = NULL;                                                                                                                    793 |     gen->gi_exc_state.exc_type = NULL;
      793 +     gen->gi_exc_state.exc_type = 0;                                                                                                                       793 +     gen->gi_exc_state.exc_type = 0;
      794 |     gen->gi_exc_state.exc_value = NULL;                                                                                                                   794 |     gen->gi_exc_state.exc_value = NULL;
      794 +     gen->gi_exc_state.exc_value = 0;                                                                                                                      794 +     gen->gi_exc_state.exc_value = 0;
      795 |     gen->gi_exc_state.exc_traceback = NULL;                                                                                                               795 |     gen->gi_exc_state.exc_traceback = NULL;
      795 +     gen->gi_exc_state.exc_traceback = 0;                                                                                                                  795 +     gen->gi_exc_state.exc_traceback = 0;
      796 |     gen->gi_exc_state.previous_item = NULL;                                                                                                               796 |     gen->gi_exc_state.previous_item = NULL;
      796 +     gen->gi_exc_state.previous_item = 0;                                                                                                                  796 +     gen->gi_exc_state.previous_item = 0;
      797 |     if (name != NULL)                                                                                                                                     797 |     if (name != NULL)
      797 +     if (name != 0)                                                                                                                                        797 +     if (name != 0)
      798 |         gen->gi_name = name;                                                                                                                              798 |         gen->gi_name = name;
      799 |     else                                                                                                                                                  799 |     else
      800 |         gen->gi_name = ((PyCodeObject *)gen->gi_code)->co_name;                                                                                           800 |         gen->gi_name = ((PyCodeObject *)gen->gi_code)->co_name;
"Objects/genobject.c", line 800.24: 1506-495 (I) Pointer type conversion found.                                                                                 "Objects/genobject.c", line 800.24: 1506-495 (I) Pointer type conversion found.
"Objects/genobject.c", line 800.24: 1506-374 (I) Pointer types "struct {...}*" and "struct _object*" are not compatible.                                        "Objects/genobject.c", line 800.24: 1506-374 (I) Pointer types "struct {...}*" and "struct _object*" are not compatible.
      801 |     Py_INCREF(gen->gi_name);                                                                                                                              801 |     Py_INCREF(gen->gi_name);
      801 +     _Py_INCREF(((PyObject*)(gen->gi_name)));                                                                                                              801 +     _Py_INCREF(((PyObject*)(gen->gi_name)));
      802 |     if (qualname != NULL)                                                                                                                                 802 |     if (qualname != NULL)
      802 +     if (qualname != 0)                                                                                                                                    802 +     if (qualname != 0)
      803 |         gen->gi_qualname = qualname;                                                                                                                      803 |         gen->gi_qualname = qualname;
      804 |     else                                                                                                                                                  804 |     else
      805 |         gen->gi_qualname = gen->gi_name;                                                                                                                  805 |         gen->gi_qualname = gen->gi_name;
      806 |     Py_INCREF(gen->gi_qualname);                                                                                                                          806 |     Py_INCREF(gen->gi_qualname);
      806 +     _Py_INCREF(((PyObject*)(gen->gi_qualname)));                                                                                                          806 +     _Py_INCREF(((PyObject*)(gen->gi_qualname)));
      807 |     _PyObject_GC_TRACK(gen);                                                                                                                              807 |     _PyObject_GC_TRACK(gen);
      807 +     _PyObject_GC_TRACK_impl("Objects/genobject.c", 807, ((PyObject*)(gen)));                                                                              807 +     _PyObject_GC_TRACK_impl("Objects/genobject.c", 807, ((PyObject*)(gen)));
"Objects/genobject.c", line 807.5: 1506-495 (I) Pointer type conversion found.                                                                                  "Objects/genobject.c", line 807.5: 1506-495 (I) Pointer type conversion found.
"Objects/genobject.c", line 807.5: 1506-374 (I) Pointer types "struct _object*" and "struct {...}*" are not compatible.                                         "Objects/genobject.c", line 807.5: 1506-374 (I) Pointer types "struct _object*" and "struct {...}*" are not compatible.
      808 |     return (PyObject *)gen;                                                                                                                               808 |     return (PyObject *)gen;
"Objects/genobject.c", line 808.12: 1506-495 (I) Pointer type conversion found.                                                                                 "Objects/genobject.c", line 808.12: 1506-495 (I) Pointer type conversion found.
"Objects/genobject.c", line 808.12: 1506-374 (I) Pointer types "struct _object*" and "struct {...}*" are not compatible.                                        "Objects/genobject.c", line 808.12: 1506-374 (I) Pointer types "struct _object*" and "struct {...}*" are not compatible.
      809 | }                                                                                                                                                         809 | }
      810 |                                                                                                                                                           810 |
      811 | PyObject *                                                                                                                                                811 | PyObject *
      812 | PyGen_NewWithQualName(PyFrameObject *f, PyObject *name, PyObject *qualname)                                                                               812 | PyGen_NewWithQualName(PyFrameObject *f, PyObject *name, PyObject *qualname)
      813 | {                                                                                                                                                         813 | {
      814 |     return gen_new_with_qualname(&PyGen_Type, f, name, qualname);                                                                                         814 |     return gen_new_with_qualname(&PyGen_Type, f, name, qualname);
      815 | }                                                                                                                                                         815 | }
      816 |                                                                                                                                                           816 |
      817 | PyObject *                                                                                                                                                817 | PyObject *
      818 | PyGen_New(PyFrameObject *f)                                                                                                                               818 | PyGen_New(PyFrameObject *f)
      819 | {                                                                                                                                                         819 | {
      820 |     return gen_new_with_qualname(&PyGen_Type, f, NULL, NULL);                                                                                             820 |     return gen_new_with_qualname(&PyGen_Type, f, NULL, NULL);
      820 +     return gen_new_with_qualname(&PyGen_Type, f, 0, 0);                                                                                                   820 +     return gen_new_with_qualname(&PyGen_Type, f, 0, 0);
      821 | }                                                                                                                                                         821 | }







Wed Apr 15 07:30:04 CDT 2020  Page 24


      822 |                                                                                                                                                           822 |
      823 | /* Coroutine Object */                                                                                                                                    823 | /* Coroutine Object */
      824 |                                                                                                                                                           824 |
      825 | typedef struct {                                                                                                                                          825 | typedef struct {
      826 |     PyObject_HEAD                                                                                                                                         826 |     PyObject_HEAD
      826 +     PyObject ob_base;                                                                                                                                     826 +     PyObject ob_base;
      827 |     PyCoroObject *cw_coroutine;                                                                                                                           827 |     PyCoroObject *cw_coroutine;
      828 | } PyCoroWrapper;                                                                                                                                          828 | } PyCoroWrapper;
      829 |                                                                                                                                                           829 |
      830 | static int                                                                                                                                                830 | static int
      831 | gen_is_coroutine(PyObject *o)                                                                                                                             831 | gen_is_coroutine(PyObject *o)
      832 | {                                                                                                                                                         832 | {
      833 |     if (PyGen_CheckExact(o)) {                                                                                                                            833 |     if (PyGen_CheckExact(o)) {
      833 +     if (_Py_IS_TYPE(((const PyObject*)(o)), &PyGen_Type)) {                                                                                               833 +     if (_Py_IS_TYPE(((const PyObject*)(o)), &PyGen_Type)) {
"Objects/genobject.c", line 833.9: 1506-495 (I) Pointer type conversion found.                                                                                  "Objects/genobject.c", line 833.9: 1506-495 (I) Pointer type conversion found.
"Objects/genobject.c", line 833.9: 1506-374 (I) Pointer types "const struct _object*" and "struct _object*" are not compatible.                                 "Objects/genobject.c", line 833.9: 1506-374 (I) Pointer types "const struct _object*" and "struct _object*" are not compatible.
      834 |         PyCodeObject *code = (PyCodeObject *)((PyGenObject*)o)->gi_code;                                                                                  834 |         PyCodeObject *code = (PyCodeObject *)((PyGenObject*)o)->gi_code;
"Objects/genobject.c", line 834.46: 1506-495 (I) Pointer type conversion found.                                                                                 "Objects/genobject.c", line 834.46: 1506-495 (I) Pointer type conversion found.
"Objects/genobject.c", line 834.46: 1506-374 (I) Pointer types "struct {...}*" and "struct _object*" are not compatible.                                        "Objects/genobject.c", line 834.46: 1506-374 (I) Pointer types "struct {...}*" and "struct _object*" are not compatible.
"Objects/genobject.c", line 834.30: 1506-495 (I) Pointer type conversion found.                                                                                 "Objects/genobject.c", line 834.30: 1506-495 (I) Pointer type conversion found.
"Objects/genobject.c", line 834.30: 1506-374 (I) Pointer types "struct {...}*" and "struct _object*" are not compatible.                                        "Objects/genobject.c", line 834.30: 1506-374 (I) Pointer types "struct {...}*" and "struct _object*" are not compatible.
      835 |         if (code->co_flags & CO_ITERABLE_COROUTINE) {                                                                                                     835 |         if (code->co_flags & CO_ITERABLE_COROUTINE) {
      835 +         if (code->co_flags & 0x0100) {                                                                                                                    835 +         if (code->co_flags & 0x0100) {
      836 |             return 1;                                                                                                                                     836 |             return 1;
      837 |         }                                                                                                                                                 837 |         }
      838 |     }                                                                                                                                                     838 |     }
      839 |     return 0;                                                                                                                                             839 |     return 0;
      840 | }                                                                                                                                                         840 | }
      841 |                                                                                                                                                           841 |
      842 | /*                                                                                                                                                        842 | /*
      843 |  *   This helper function returns an awaitable for `o`:                                                                                                   843 |  *   This helper function returns an awaitable for `o`:
      844 |  *     - `o` if `o` is a coroutine-object;                                                                                                                844 |  *     - `o` if `o` is a coroutine-object;
      845 |  *     - `type(o)->tp_as_async->am_await(o)`                                                                                                              845 |  *     - `type(o)->tp_as_async->am_await(o)`
      846 |  *                                                                                                                                                        846 |  *
      847 |  *   Raises a TypeError if it's not possible to return                                                                                                    847 |  *   Raises a TypeError if it's not possible to return
      848 |  *   an awaitable and returns NULL.                                                                                                                       848 |  *   an awaitable and returns NULL.
      849 |  */                                                                                                                                                       849 |  */
      850 | PyObject *                                                                                                                                                850 | PyObject *
      851 | _PyCoro_GetAwaitableIter(PyObject *o)                                                                                                                     851 | _PyCoro_GetAwaitableIter(PyObject *o)
      852 | {                                                                                                                                                         852 | {
      853 |     unaryfunc getter = NULL;                                                                                                                              853 |     unaryfunc getter = NULL;
      853 +     unaryfunc getter = 0;                                                                                                                                 853 +     unaryfunc getter = 0;
"Objects/genobject.c", line 853.15: 1506-492 (I) Redefinition of getter hides previous definition.                                                              "Objects/genobject.c", line 853.15: 1506-492 (I) Redefinition of getter hides previous definition.
      854 |     PyTypeObject *ot;                                                                                                                                     854 |     PyTypeObject *ot;
      855 |                                                                                                                                                           855 |
      856 |     if (PyCoro_CheckExact(o) || gen_is_coroutine(o)) {                                                                                                    856 |     if (PyCoro_CheckExact(o) || gen_is_coroutine(o)) {
      856 +     if (_Py_IS_TYPE(((const PyObject*)(o)), &PyCoro_Type) || gen_is_coroutine(o)) {                                                                       856 +     if (_Py_IS_TYPE(((const PyObject*)(o)), &PyCoro_Type) || gen_is_coroutine(o)) {
"Objects/genobject.c", line 856.9: 1506-495 (I) Pointer type conversion found.                                                                                  "Objects/genobject.c", line 856.9: 1506-495 (I) Pointer type conversion found.
"Objects/genobject.c", line 856.9: 1506-374 (I) Pointer types "const struct _object*" and "struct _object*" are not compatible.                                 "Objects/genobject.c", line 856.9: 1506-374 (I) Pointer types "const struct _object*" and "struct _object*" are not compatible.
      857 |         /* 'o' is a coroutine. */                                                                                                                         857 |         /* 'o' is a coroutine. */
      858 |         Py_INCREF(o);                                                                                                                                     858 |         Py_INCREF(o);
      858 +         _Py_INCREF(((PyObject*)(o)));                                                                                                                     858 +         _Py_INCREF(((PyObject*)(o)));
      859 |         return o;                                                                                                                                         859 |         return o;
      860 |     }                                                                                                                                                     860 |     }
      861 |                                                                                                                                                           861 |
      862 |     ot = Py_TYPE(o);                                                                                                                                      862 |     ot = Py_TYPE(o);







Wed Apr 15 07:30:04 CDT 2020  Page 25


      862 +     ot = (((PyObject*)(o))->ob_type);                                                                                                                     862 +     ot = (((PyObject*)(o))->ob_type);
      863 |     if (ot->tp_as_async != NULL) {                                                                                                                        863 |     if (ot->tp_as_async != NULL) {
      863 +     if (ot->tp_as_async != 0) {                                                                                                                           863 +     if (ot->tp_as_async != 0) {
      864 |         getter = ot->tp_as_async->am_await;                                                                                                               864 |         getter = ot->tp_as_async->am_await;
      865 |     }                                                                                                                                                     865 |     }
      866 |     if (getter != NULL) {                                                                                                                                 866 |     if (getter != NULL) {
      866 +     if (getter != 0) {                                                                                                                                    866 +     if (getter != 0) {
      867 |         PyObject *res = (*getter)(o);                                                                                                                     867 |         PyObject *res = (*getter)(o);
      868 |         if (res != NULL) {                                                                                                                                868 |         if (res != NULL) {
      868 +         if (res != 0) {                                                                                                                                   868 +         if (res != 0) {
      869 |             if (PyCoro_CheckExact(res) || gen_is_coroutine(res)) {                                                                                        869 |             if (PyCoro_CheckExact(res) || gen_is_coroutine(res)) {
      869 +             if (_Py_IS_TYPE(((const PyObject*)(res)), &PyCoro_Type) || gen_is_coroutine(res)) {                                                           869 +             if (_Py_IS_TYPE(((const PyObject*)(res)), &PyCoro_Type) || gen_is_coroutine(res)) {
"Objects/genobject.c", line 869.17: 1506-495 (I) Pointer type conversion found.                                                                                 "Objects/genobject.c", line 869.17: 1506-495 (I) Pointer type conversion found.
"Objects/genobject.c", line 869.17: 1506-374 (I) Pointer types "const struct _object*" and "struct _object*" are not compatible.                                "Objects/genobject.c", line 869.17: 1506-374 (I) Pointer types "const struct _object*" and "struct _object*" are not compatible.
      870 |                 /* __await__ must return an *iterator*, not                                                                                               870 |                 /* __await__ must return an *iterator*, not
      871 |                    a coroutine or another awaitable (see PEP 492) */                                                                                      871 |                    a coroutine or another awaitable (see PEP 492) */
      872 |                 PyErr_SetString(PyExc_TypeError,                                                                                                          872 |                 PyErr_SetString(PyExc_TypeError,
      873 |                                 "__await__() returned a coroutine");                                                                                      873 |                                 "__await__() returned a coroutine");
      874 |                 Py_CLEAR(res);                                                                                                                            874 |                 Py_CLEAR(res);
      874 +                 do { PyObject *_py_tmp = ((PyObject*)(res)); if (_py_tmp != 0) { (res) = 0; _Py_DECREF("Objects/genobject.c", 874, ((PyObject*)(_py       874 +                 do { PyObject *_py_tmp = ((PyObject*)(res)); if (_py_tmp != 0) { (res) = 0; _Py_DECREF("Objects/genobject.c", 874, ((PyObject*)(_py
"Objects/genobject.c", line 874.17: 1506-425 (I) The condition is always false.                                                                                 "Objects/genobject.c", line 874.17: 1506-425 (I) The condition is always false.
      875 |             } else if (!PyIter_Check(res)) {                                                                                                              875 |             } else if (!PyIter_Check(res)) {
      875 +             } else if (!((((PyObject*)(res))->ob_type)->tp_iternext != 0 && (((PyObject*)(res))->ob_type)->tp_iternext != &_PyObject_NextNotImpleme       875 +             } else if (!((((PyObject*)(res))->ob_type)->tp_iternext != 0 && (((PyObject*)(res))->ob_type)->tp_iternext != &_PyObject_NextNotImpleme
      876 |                 PyErr_Format(PyExc_TypeError,                                                                                                             876 |                 PyErr_Format(PyExc_TypeError,
      877 |                              "__await__() returned non-iterator "                                                                                         877 |                              "__await__() returned non-iterator "
      878 |                              "of type '%.100s'",                                                                                                          878 |                              "of type '%.100s'",
      879 |                              Py_TYPE(res)->tp_name);                                                                                                      879 |                              Py_TYPE(res)->tp_name);
      879 +                              (((PyObject*)(res))->ob_type)->tp_name);                                                                                     879 +                              (((PyObject*)(res))->ob_type)->tp_name);
      880 |                 Py_CLEAR(res);                                                                                                                            880 |                 Py_CLEAR(res);
      880 +                 do { PyObject *_py_tmp = ((PyObject*)(res)); if (_py_tmp != 0) { (res) = 0; _Py_DECREF("Objects/genobject.c", 880, ((PyObject*)(_py       880 +                 do { PyObject *_py_tmp = ((PyObject*)(res)); if (_py_tmp != 0) { (res) = 0; _Py_DECREF("Objects/genobject.c", 880, ((PyObject*)(_py
"Objects/genobject.c", line 880.17: 1506-425 (I) The condition is always false.                                                                                 "Objects/genobject.c", line 880.17: 1506-425 (I) The condition is always false.
      881 |             }                                                                                                                                             881 |             }
      882 |         }                                                                                                                                                 882 |         }
      883 |         return res;                                                                                                                                       883 |         return res;
      884 |     }                                                                                                                                                     884 |     }
      885 |                                                                                                                                                           885 |
      886 |     PyErr_Format(PyExc_TypeError,                                                                                                                         886 |     PyErr_Format(PyExc_TypeError,
      887 |                  "object %.100s can't be used in 'await' expression",                                                                                     887 |                  "object %.100s can't be used in 'await' expression",
      888 |                  ot->tp_name);                                                                                                                            888 |                  ot->tp_name);
      889 |     return NULL;                                                                                                                                          889 |     return NULL;
      889 +     return 0;                                                                                                                                             889 +     return 0;
      890 | }                                                                                                                                                         890 | }
"Objects/genobject.c", line 890.1: 1506-412 (I) Referenced variable "ot", which was not initialized in its declaration.                                         "Objects/genobject.c", line 890.1: 1506-412 (I) Referenced variable "ot", which was not initialized in its declaration.
      891 |                                                                                                                                                           891 |
      892 | static PyObject *                                                                                                                                         892 | static PyObject *
      893 | coro_repr(PyCoroObject *coro)                                                                                                                             893 | coro_repr(PyCoroObject *coro)
      894 | {                                                                                                                                                         894 | {
      895 |     return PyUnicode_FromFormat("<coroutine object %S at %p>",                                                                                            895 |     return PyUnicode_FromFormat("<coroutine object %S at %p>",
      896 |                                 coro->cr_qualname, coro);                                                                                                 896 |                                 coro->cr_qualname, coro);
      897 | }                                                                                                                                                         897 | }
      898 |                                                                                                                                                           898 |
      899 | static PyObject *                                                                                                                                         899 | static PyObject *
      900 | coro_await(PyCoroObject *coro)                                                                                                                            900 | coro_await(PyCoroObject *coro)
      901 | {                                                                                                                                                         901 | {
      902 |     PyCoroWrapper *cw = PyObject_GC_New(PyCoroWrapper, &_PyCoroWrapper_Type);                                                                             902 |     PyCoroWrapper *cw = PyObject_GC_New(PyCoroWrapper, &_PyCoroWrapper_Type);
      902 +     PyCoroWrapper *cw = ( (PyCoroWrapper *) _PyObject_GC_New(&_PyCoroWrapper_Type) );                                                                     902 +     PyCoroWrapper *cw = ( (PyCoroWrapper *) _PyObject_GC_New(&_PyCoroWrapper_Type) );







Wed Apr 15 07:30:04 CDT 2020  Page 26


"Objects/genobject.c", line 902.25: 1506-495 (I) Pointer type conversion found.                                                                                 "Objects/genobject.c", line 902.25: 1506-495 (I) Pointer type conversion found.
"Objects/genobject.c", line 902.25: 1506-374 (I) Pointer types "struct {...}*" and "struct _object*" are not compatible.                                        "Objects/genobject.c", line 902.25: 1506-374 (I) Pointer types "struct {...}*" and "struct _object*" are not compatible.
      903 |     if (cw == NULL) {                                                                                                                                     903 |     if (cw == NULL) {
      903 +     if (cw == 0) {                                                                                                                                        903 +     if (cw == 0) {
      904 |         return NULL;                                                                                                                                      904 |         return NULL;
      904 +         return 0;                                                                                                                                         904 +         return 0;
      905 |     }                                                                                                                                                     905 |     }
      906 |     Py_INCREF(coro);                                                                                                                                      906 |     Py_INCREF(coro);
      906 +     _Py_INCREF(((PyObject*)(coro)));                                                                                                                      906 +     _Py_INCREF(((PyObject*)(coro)));
"Objects/genobject.c", line 906.5: 1506-495 (I) Pointer type conversion found.                                                                                  "Objects/genobject.c", line 906.5: 1506-495 (I) Pointer type conversion found.
"Objects/genobject.c", line 906.5: 1506-374 (I) Pointer types "struct _object*" and "struct {...}*" are not compatible.                                         "Objects/genobject.c", line 906.5: 1506-374 (I) Pointer types "struct _object*" and "struct {...}*" are not compatible.
      907 |     cw->cw_coroutine = coro;                                                                                                                              907 |     cw->cw_coroutine = coro;
      908 |     _PyObject_GC_TRACK(cw);                                                                                                                               908 |     _PyObject_GC_TRACK(cw);
      908 +     _PyObject_GC_TRACK_impl("Objects/genobject.c", 908, ((PyObject*)(cw)));                                                                               908 +     _PyObject_GC_TRACK_impl("Objects/genobject.c", 908, ((PyObject*)(cw)));
"Objects/genobject.c", line 908.5: 1506-495 (I) Pointer type conversion found.                                                                                  "Objects/genobject.c", line 908.5: 1506-495 (I) Pointer type conversion found.
"Objects/genobject.c", line 908.5: 1506-374 (I) Pointer types "struct _object*" and "struct {...}*" are not compatible.                                         "Objects/genobject.c", line 908.5: 1506-374 (I) Pointer types "struct _object*" and "struct {...}*" are not compatible.
      909 |     return (PyObject *)cw;                                                                                                                                909 |     return (PyObject *)cw;
"Objects/genobject.c", line 909.12: 1506-495 (I) Pointer type conversion found.                                                                                 "Objects/genobject.c", line 909.12: 1506-495 (I) Pointer type conversion found.
"Objects/genobject.c", line 909.12: 1506-374 (I) Pointer types "struct _object*" and "struct {...}*" are not compatible.                                        "Objects/genobject.c", line 909.12: 1506-374 (I) Pointer types "struct _object*" and "struct {...}*" are not compatible.
      910 | }                                                                                                                                                         910 | }
      911 |                                                                                                                                                           911 |
      912 | static PyObject *                                                                                                                                         912 | static PyObject *
      913 | coro_get_cr_await(PyCoroObject *coro, void *Py_UNUSED(ignored))                                                                                           913 | coro_get_cr_await(PyCoroObject *coro, void *Py_UNUSED(ignored))
      913 + coro_get_cr_await(PyCoroObject *coro, void *_unused_ignored)                                                                                              913 + coro_get_cr_await(PyCoroObject *coro, void *_unused_ignored)
      914 | {                                                                                                                                                         914 | {
      915 |     PyObject *yf = _PyGen_yf((PyGenObject *) coro);                                                                                                       915 |     PyObject *yf = _PyGen_yf((PyGenObject *) coro);
"Objects/genobject.c", line 915.30: 1506-495 (I) Pointer type conversion found.                                                                                 "Objects/genobject.c", line 915.30: 1506-495 (I) Pointer type conversion found.
"Objects/genobject.c", line 915.30: 1506-374 (I) Pointer types "struct {...}*" and "struct {...}*" are not compatible.                                          "Objects/genobject.c", line 915.30: 1506-374 (I) Pointer types "struct {...}*" and "struct {...}*" are not compatible.
      916 |     if (yf == NULL)                                                                                                                                       916 |     if (yf == NULL)
      916 +     if (yf == 0)                                                                                                                                          916 +     if (yf == 0)
      917 |         Py_RETURN_NONE;                                                                                                                                   917 |         Py_RETURN_NONE;
      917 +         return _Py_INCREF(((PyObject*)((&_Py_NoneStruct)))), (&_Py_NoneStruct);                                                                           917 +         return _Py_INCREF(((PyObject*)((&_Py_NoneStruct)))), (&_Py_NoneStruct);
      918 |     return yf;                                                                                                                                            918 |     return yf;
      919 | }                                                                                                                                                         919 | }
"Objects/genobject.c", line 919.1: 1506-414 (I) The parameter "_unused_ignored" is never referenced.                                                            "Objects/genobject.c", line 919.1: 1506-414 (I) The parameter "_unused_ignored" is never referenced.
      920 |                                                                                                                                                           920 |
      921 | static PyGetSetDef coro_getsetlist[] = {                                                                                                                  921 | static PyGetSetDef coro_getsetlist[] = {
"Objects/genobject.c", line 921.38: 1506-446 (I) Array element(s) [0] will be initialized with a default value of 0.                                            "Objects/genobject.c", line 921.38: 1506-446 (I) Array element(s) [0] will be initialized with a default value of 0.
"Objects/genobject.c", line 921.38: 1506-446 (I) Array element(s) [1] will be initialized with a default value of 0.                                            "Objects/genobject.c", line 921.38: 1506-446 (I) Array element(s) [1] will be initialized with a default value of 0.
"Objects/genobject.c", line 921.38: 1506-446 (I) Array element(s) [2] will be initialized with a default value of 0.                                            "Objects/genobject.c", line 921.38: 1506-446 (I) Array element(s) [2] will be initialized with a default value of 0.
"Objects/genobject.c", line 921.38: 1506-446 (I) Array element(s) [3] will be initialized with a default value of 0.                                            "Objects/genobject.c", line 921.38: 1506-446 (I) Array element(s) [3] will be initialized with a default value of 0.
      922 |     {"__name__", (getter)gen_get_name, (setter)gen_set_name,                                                                                              922 |     {"__name__", (getter)gen_get_name, (setter)gen_set_name,
      923 |      PyDoc_STR("name of the coroutine")},                                                                                                                 923 |      PyDoc_STR("name of the coroutine")},
      923 +      "name of the coroutine"},                                                                                                                            923 +      "name of the coroutine"},
"Objects/genobject.c", line 923.40: 1506-447 (I) The member(s) starting from "closure" will be initialized with a default value of 0.                           "Objects/genobject.c", line 923.40: 1506-447 (I) The member(s) starting from "closure" will be initialized with a default value of 0.
      924 |     {"__qualname__", (getter)gen_get_qualname, (setter)gen_set_qualname,                                                                                  924 |     {"__qualname__", (getter)gen_get_qualname, (setter)gen_set_qualname,
      925 |      PyDoc_STR("qualified name of the coroutine")},                                                                                                       925 |      PyDoc_STR("qualified name of the coroutine")},
      925 +      "qualified name of the coroutine"},                                                                                                                  925 +      "qualified name of the coroutine"},
"Objects/genobject.c", line 925.50: 1506-447 (I) The member(s) starting from "closure" will be initialized with a default value of 0.                           "Objects/genobject.c", line 925.50: 1506-447 (I) The member(s) starting from "closure" will be initialized with a default value of 0.
      926 |     {"cr_await", (getter)coro_get_cr_await, NULL,                                                                                                         926 |     {"cr_await", (getter)coro_get_cr_await, NULL,
      926 +     {"cr_await", (getter)coro_get_cr_await, 0,                                                                                                            926 +     {"cr_await", (getter)coro_get_cr_await, 0,
      927 |      PyDoc_STR("object being awaited on, or None")},                                                                                                      927 |      PyDoc_STR("object being awaited on, or None")},
      927 +      "object being awaited on, or None"},                                                                                                                 927 +      "object being awaited on, or None"},
"Objects/genobject.c", line 927.51: 1506-447 (I) The member(s) starting from "closure" will be initialized with a default value of 0.                           "Objects/genobject.c", line 927.51: 1506-447 (I) The member(s) starting from "closure" will be initialized with a default value of 0.
      928 |     {NULL} /* Sentinel */                                                                                                                                 928 |     {NULL} /* Sentinel */
      928 +     {0} /* Sentinel */                                                                                                                                    928 +     {0} /* Sentinel */







Wed Apr 15 07:30:04 CDT 2020  Page 27


"Objects/genobject.c", line 928.10: 1506-447 (I) The member(s) starting from "get" will be initialized with a default value of 0.                               "Objects/genobject.c", line 928.10: 1506-447 (I) The member(s) starting from "get" will be initialized with a default value of 0.
      929 | };                                                                                                                                                        929 | };
      930 |                                                                                                                                                           930 |
      931 | static PyMemberDef coro_memberlist[] = {                                                                                                                  931 | static PyMemberDef coro_memberlist[] = {
"Objects/genobject.c", line 931.38: 1506-446 (I) Array element(s) [0] will be initialized with a default value of 0.                                            "Objects/genobject.c", line 931.38: 1506-446 (I) Array element(s) [0] will be initialized with a default value of 0.
"Objects/genobject.c", line 931.38: 1506-446 (I) Array element(s) [1] will be initialized with a default value of 0.                                            "Objects/genobject.c", line 931.38: 1506-446 (I) Array element(s) [1] will be initialized with a default value of 0.
"Objects/genobject.c", line 931.38: 1506-446 (I) Array element(s) [2] will be initialized with a default value of 0.                                            "Objects/genobject.c", line 931.38: 1506-446 (I) Array element(s) [2] will be initialized with a default value of 0.
"Objects/genobject.c", line 931.38: 1506-446 (I) Array element(s) [3] will be initialized with a default value of 0.                                            "Objects/genobject.c", line 931.38: 1506-446 (I) Array element(s) [3] will be initialized with a default value of 0.
"Objects/genobject.c", line 931.38: 1506-446 (I) Array element(s) [4] will be initialized with a default value of 0.                                            "Objects/genobject.c", line 931.38: 1506-446 (I) Array element(s) [4] will be initialized with a default value of 0.
      932 |     {"cr_frame",     T_OBJECT, offsetof(PyCoroObject, cr_frame),    READONLY},                                                                            932 |     {"cr_frame",     T_OBJECT, offsetof(PyCoroObject, cr_frame),    READONLY},
      932 +     {"cr_frame",     6, (size_t)&(((PyCoroObject *)0)->cr_frame),    1},                                                                                  932 +     {"cr_frame",     6, (size_t)&(((PyCoroObject *)0)->cr_frame),    1},
"Objects/genobject.c", line 932.77: 1506-447 (I) The member(s) starting from "doc" will be initialized with a default value of 0.                               "Objects/genobject.c", line 932.77: 1506-447 (I) The member(s) starting from "doc" will be initialized with a default value of 0.
      933 |     {"cr_running",   T_BOOL,   offsetof(PyCoroObject, cr_running),  READONLY},                                                                            933 |     {"cr_running",   T_BOOL,   offsetof(PyCoroObject, cr_running),  READONLY},
      933 +     {"cr_running",   14,   (size_t)&(((PyCoroObject *)0)->cr_running),  1},                                                                               933 +     {"cr_running",   14,   (size_t)&(((PyCoroObject *)0)->cr_running),  1},
"Objects/genobject.c", line 933.77: 1506-447 (I) The member(s) starting from "doc" will be initialized with a default value of 0.                               "Objects/genobject.c", line 933.77: 1506-447 (I) The member(s) starting from "doc" will be initialized with a default value of 0.
      934 |     {"cr_code",      T_OBJECT, offsetof(PyCoroObject, cr_code),     READONLY},                                                                            934 |     {"cr_code",      T_OBJECT, offsetof(PyCoroObject, cr_code),     READONLY},
      934 +     {"cr_code",      6, (size_t)&(((PyCoroObject *)0)->cr_code),     1},                                                                                  934 +     {"cr_code",      6, (size_t)&(((PyCoroObject *)0)->cr_code),     1},
"Objects/genobject.c", line 934.77: 1506-447 (I) The member(s) starting from "doc" will be initialized with a default value of 0.                               "Objects/genobject.c", line 934.77: 1506-447 (I) The member(s) starting from "doc" will be initialized with a default value of 0.
      935 |     {"cr_origin",    T_OBJECT, offsetof(PyCoroObject, cr_origin),   READONLY},                                                                            935 |     {"cr_origin",    T_OBJECT, offsetof(PyCoroObject, cr_origin),   READONLY},
      935 +     {"cr_origin",    6, (size_t)&(((PyCoroObject *)0)->cr_origin),   1},                                                                                  935 +     {"cr_origin",    6, (size_t)&(((PyCoroObject *)0)->cr_origin),   1},
"Objects/genobject.c", line 935.77: 1506-447 (I) The member(s) starting from "doc" will be initialized with a default value of 0.                               "Objects/genobject.c", line 935.77: 1506-447 (I) The member(s) starting from "doc" will be initialized with a default value of 0.
      936 |     {NULL}      /* Sentinel */                                                                                                                            936 |     {NULL}      /* Sentinel */
      936 +     {0}      /* Sentinel */                                                                                                                               936 +     {0}      /* Sentinel */
"Objects/genobject.c", line 936.10: 1506-447 (I) The member(s) starting from "type" will be initialized with a default value of 0.                              "Objects/genobject.c", line 936.10: 1506-447 (I) The member(s) starting from "type" will be initialized with a default value of 0.
      937 | };                                                                                                                                                        937 | };
      938 |                                                                                                                                                           938 |
      939 | PyDoc_STRVAR(coro_send_doc,                                                                                                                               939 | PyDoc_STRVAR(coro_send_doc,
      939 +                                                                                                                                                           939 +
      940 | "send(arg) -> send 'arg' into coroutine,\n\                                                                                                               940 | "send(arg) -> send 'arg' into coroutine,\n\
      941 | return next iterated value or raise StopIteration.");                                                                                                     941 | return next iterated value or raise StopIteration.");
      941 + static const char coro_send_doc[] = "send(arg) -> send 'arg' into coroutine,\nreturn next iterated value or raise StopIteration.";                        941 + static const char coro_send_doc[] = "send(arg) -> send 'arg' into coroutine,\nreturn next iterated value or raise StopIteration.";
      942 |                                                                                                                                                           942 |
      943 | PyDoc_STRVAR(coro_throw_doc,                                                                                                                              943 | PyDoc_STRVAR(coro_throw_doc,
      943 +                                                                                                                                                           943 +
      944 | "throw(typ[,val[,tb]]) -> raise exception in coroutine,\n\                                                                                                944 | "throw(typ[,val[,tb]]) -> raise exception in coroutine,\n\
      945 | return next iterated value or raise StopIteration.");                                                                                                     945 | return next iterated value or raise StopIteration.");
      945 + static const char coro_throw_doc[] = "throw(typ[,val[,tb]]) -> raise exception in coroutine,\nreturn next iterated value or raise StopIteration.";        945 + static const char coro_throw_doc[] = "throw(typ[,val[,tb]]) -> raise exception in coroutine,\nreturn next iterated value or raise StopIteration.";
      946 |                                                                                                                                                           946 |
      947 | PyDoc_STRVAR(coro_close_doc,                                                                                                                              947 | PyDoc_STRVAR(coro_close_doc,
      947 +                                                                                                                                                           947 +
      948 | "close() -> raise GeneratorExit inside coroutine.");                                                                                                      948 | "close() -> raise GeneratorExit inside coroutine.");
      948 + static const char coro_close_doc[] = "close() -> raise GeneratorExit inside coroutine.";                                                                  948 + static const char coro_close_doc[] = "close() -> raise GeneratorExit inside coroutine.";
      949 |                                                                                                                                                           949 |
      950 | static PyMethodDef coro_methods[] = {                                                                                                                     950 | static PyMethodDef coro_methods[] = {
"Objects/genobject.c", line 950.35: 1506-446 (I) Array element(s) [3] will be initialized with a default value of 0.                                            "Objects/genobject.c", line 950.35: 1506-446 (I) Array element(s) [3] will be initialized with a default value of 0.
      951 |     {"send",(PyCFunction)_PyGen_Send, METH_O, coro_send_doc},                                                                                             951 |     {"send",(PyCFunction)_PyGen_Send, METH_O, coro_send_doc},
      951 +     {"send",(PyCFunction)_PyGen_Send, 0x0008, coro_send_doc},                                                                                             951 +     {"send",(PyCFunction)_PyGen_Send, 0x0008, coro_send_doc},
      952 |     {"throw",(PyCFunction)gen_throw, METH_VARARGS, coro_throw_doc},                                                                                       952 |     {"throw",(PyCFunction)gen_throw, METH_VARARGS, coro_throw_doc},
      952 +     {"throw",(PyCFunction)gen_throw, 0x0001, coro_throw_doc},                                                                                             952 +     {"throw",(PyCFunction)gen_throw, 0x0001, coro_throw_doc},
      953 |     {"close",(PyCFunction)gen_close, METH_NOARGS, coro_close_doc},                                                                                        953 |     {"close",(PyCFunction)gen_close, METH_NOARGS, coro_close_doc},
      953 +     {"close",(PyCFunction)gen_close, 0x0004, coro_close_doc},                                                                                             953 +     {"close",(PyCFunction)gen_close, 0x0004, coro_close_doc},
      954 |     {NULL, NULL}        /* Sentinel */                                                                                                                    954 |     {NULL, NULL}        /* Sentinel */
      954 +     {0, 0}        /* Sentinel */                                                                                                                          954 +     {0, 0}        /* Sentinel */
"Objects/genobject.c", line 954.16: 1506-447 (I) The member(s) starting from "ml_flags" will be initialized with a default value of 0.                          "Objects/genobject.c", line 954.16: 1506-447 (I) The member(s) starting from "ml_flags" will be initialized with a default value of 0.
      955 | };                                                                                                                                                        955 | };
      956 |                                                                                                                                                           956 |







Wed Apr 15 07:30:04 CDT 2020  Page 28


      957 | static PyAsyncMethods coro_as_async = {                                                                                                                   957 | static PyAsyncMethods coro_as_async = {
      958 |     (unaryfunc)coro_await,                      /* am_await */                                                                                            958 |     (unaryfunc)coro_await,                      /* am_await */
      959 |     0,                                          /* am_aiter */                                                                                            959 |     0,                                          /* am_aiter */
      960 |     0                                           /* am_anext */                                                                                            960 |     0                                           /* am_anext */
      961 | };                                                                                                                                                        961 | };
      962 |                                                                                                                                                           962 |
      963 | PyTypeObject PyCoro_Type = {                                                                                                                              963 | PyTypeObject PyCoro_Type = {
      964 |     PyVarObject_HEAD_INIT(&PyType_Type, 0)                                                                                                                964 |     PyVarObject_HEAD_INIT(&PyType_Type, 0)
      964 +     { {   1, &PyType_Type }, 0 },                                                                                                                         964 +     { {   1, &PyType_Type }, 0 },
      965 |     "coroutine",                                /* tp_name */                                                                                             965 |     "coroutine",                                /* tp_name */
      966 |     sizeof(PyCoroObject),                       /* tp_basicsize */                                                                                        966 |     sizeof(PyCoroObject),                       /* tp_basicsize */
      967 |     0,                                          /* tp_itemsize */                                                                                         967 |     0,                                          /* tp_itemsize */
      968 |     /* methods */                                                                                                                                         968 |     /* methods */
      969 |     (destructor)gen_dealloc,                    /* tp_dealloc */                                                                                          969 |     (destructor)gen_dealloc,                    /* tp_dealloc */
      970 |     0,                                          /* tp_vectorcall_offset */                                                                                970 |     0,                                          /* tp_vectorcall_offset */
      971 |     0,                                          /* tp_getattr */                                                                                          971 |     0,                                          /* tp_getattr */
      972 |     0,                                          /* tp_setattr */                                                                                          972 |     0,                                          /* tp_setattr */
      973 |     &coro_as_async,                             /* tp_as_async */                                                                                         973 |     &coro_as_async,                             /* tp_as_async */
      974 |     (reprfunc)coro_repr,                        /* tp_repr */                                                                                             974 |     (reprfunc)coro_repr,                        /* tp_repr */
      975 |     0,                                          /* tp_as_number */                                                                                        975 |     0,                                          /* tp_as_number */
      976 |     0,                                          /* tp_as_sequence */                                                                                      976 |     0,                                          /* tp_as_sequence */
      977 |     0,                                          /* tp_as_mapping */                                                                                       977 |     0,                                          /* tp_as_mapping */
      978 |     0,                                          /* tp_hash */                                                                                             978 |     0,                                          /* tp_hash */
      979 |     0,                                          /* tp_call */                                                                                             979 |     0,                                          /* tp_call */
      980 |     0,                                          /* tp_str */                                                                                              980 |     0,                                          /* tp_str */
      981 |     PyObject_GenericGetAttr,                    /* tp_getattro */                                                                                         981 |     PyObject_GenericGetAttr,                    /* tp_getattro */
      982 |     0,                                          /* tp_setattro */                                                                                         982 |     0,                                          /* tp_setattro */
      983 |     0,                                          /* tp_as_buffer */                                                                                        983 |     0,                                          /* tp_as_buffer */
      984 |     Py_TPFLAGS_DEFAULT | Py_TPFLAGS_HAVE_GC,    /* tp_flags */                                                                                            984 |     Py_TPFLAGS_DEFAULT | Py_TPFLAGS_HAVE_GC,    /* tp_flags */
      984 +     ( 0 | (1UL << 18) | 0) | (1UL << 14),    /* tp_flags */                                                                                               984 +     ( 0 | (1UL << 18) | 0) | (1UL << 14),    /* tp_flags */
      985 |     0,                                          /* tp_doc */                                                                                              985 |     0,                                          /* tp_doc */
      986 |     (traverseproc)gen_traverse,                 /* tp_traverse */                                                                                         986 |     (traverseproc)gen_traverse,                 /* tp_traverse */
      987 |     0,                                          /* tp_clear */                                                                                            987 |     0,                                          /* tp_clear */
      988 |     0,                                          /* tp_richcompare */                                                                                      988 |     0,                                          /* tp_richcompare */
      989 |     offsetof(PyCoroObject, cr_weakreflist),     /* tp_weaklistoffset */                                                                                   989 |     offsetof(PyCoroObject, cr_weakreflist),     /* tp_weaklistoffset */
      989 +     (size_t)&(((PyCoroObject *)0)->cr_weakreflist),     /* tp_weaklistoffset */                                                                           989 +     (size_t)&(((PyCoroObject *)0)->cr_weakreflist),     /* tp_weaklistoffset */
      990 |     0,                                          /* tp_iter */                                                                                             990 |     0,                                          /* tp_iter */
      991 |     0,                                          /* tp_iternext */                                                                                         991 |     0,                                          /* tp_iternext */
      992 |     coro_methods,                               /* tp_methods */                                                                                          992 |     coro_methods,                               /* tp_methods */
      993 |     coro_memberlist,                            /* tp_members */                                                                                          993 |     coro_memberlist,                            /* tp_members */
      994 |     coro_getsetlist,                            /* tp_getset */                                                                                           994 |     coro_getsetlist,                            /* tp_getset */
      995 |     0,                                          /* tp_base */                                                                                             995 |     0,                                          /* tp_base */
      996 |     0,                                          /* tp_dict */                                                                                             996 |     0,                                          /* tp_dict */
      997 |     0,                                          /* tp_descr_get */                                                                                        997 |     0,                                          /* tp_descr_get */
      998 |     0,                                          /* tp_descr_set */                                                                                        998 |     0,                                          /* tp_descr_set */
      999 |     0,                                          /* tp_dictoffset */                                                                                       999 |     0,                                          /* tp_dictoffset */
     1000 |     0,                                          /* tp_init */                                                                                            1000 |     0,                                          /* tp_init */
     1001 |     0,                                          /* tp_alloc */                                                                                           1001 |     0,                                          /* tp_alloc */
     1002 |     0,                                          /* tp_new */                                                                                             1002 |     0,                                          /* tp_new */
     1003 |     0,                                          /* tp_free */                                                                                            1003 |     0,                                          /* tp_free */
     1004 |     0,                                          /* tp_is_gc */                                                                                           1004 |     0,                                          /* tp_is_gc */
     1005 |     0,                                          /* tp_bases */                                                                                           1005 |     0,                                          /* tp_bases */
     1006 |     0,                                          /* tp_mro */                                                                                             1006 |     0,                                          /* tp_mro */
     1007 |     0,                                          /* tp_cache */                                                                                           1007 |     0,                                          /* tp_cache */
     1008 |     0,                                          /* tp_subclasses */                                                                                      1008 |     0,                                          /* tp_subclasses */
     1009 |     0,                                          /* tp_weaklist */                                                                                        1009 |     0,                                          /* tp_weaklist */







Wed Apr 15 07:30:04 CDT 2020  Page 29


     1010 |     0,                                          /* tp_del */                                                                                             1010 |     0,                                          /* tp_del */
     1011 |     0,                                          /* tp_version_tag */                                                                                     1011 |     0,                                          /* tp_version_tag */
     1012 |     _PyGen_Finalize,                            /* tp_finalize */                                                                                        1012 |     _PyGen_Finalize,                            /* tp_finalize */
     1013 | };                                                                                                                                                       1013 | };
"Objects/genobject.c", line 1013.1: 1506-447 (I) The member(s) starting from "tp_vectorcall" will be initialized with a default value of 0.                     "Objects/genobject.c", line 1013.1: 1506-447 (I) The member(s) starting from "tp_vectorcall" will be initialized with a default value of 0.
     1014 |                                                                                                                                                          1014 |
     1015 | static void                                                                                                                                              1015 | static void
     1016 | coro_wrapper_dealloc(PyCoroWrapper *cw)                                                                                                                  1016 | coro_wrapper_dealloc(PyCoroWrapper *cw)
     1017 | {                                                                                                                                                        1017 | {
     1018 |     _PyObject_GC_UNTRACK((PyObject *)cw);                                                                                                                1018 |     _PyObject_GC_UNTRACK((PyObject *)cw);
     1018 +     _PyObject_GC_UNTRACK_impl("Objects/genobject.c", 1018, ((PyObject*)((PyObject *)cw)));                                                               1018 +     _PyObject_GC_UNTRACK_impl("Objects/genobject.c", 1018, ((PyObject*)((PyObject *)cw)));
"Objects/genobject.c", line 1018.5: 1506-495 (I) Pointer type conversion found.                                                                                 "Objects/genobject.c", line 1018.5: 1506-495 (I) Pointer type conversion found.
"Objects/genobject.c", line 1018.5: 1506-374 (I) Pointer types "struct _object*" and "struct {...}*" are not compatible.                                        "Objects/genobject.c", line 1018.5: 1506-374 (I) Pointer types "struct _object*" and "struct {...}*" are not compatible.
     1019 |     Py_CLEAR(cw->cw_coroutine);                                                                                                                          1019 |     Py_CLEAR(cw->cw_coroutine);
     1019 +     do { PyObject *_py_tmp = ((PyObject*)(cw->cw_coroutine)); if (_py_tmp != 0) { (cw->cw_coroutine) = 0; _Py_DECREF("Objects/genobject.c", 1019, (      1019 +     do { PyObject *_py_tmp = ((PyObject*)(cw->cw_coroutine)); if (_py_tmp != 0) { (cw->cw_coroutine) = 0; _Py_DECREF("Objects/genobject.c", 1019, (
"Objects/genobject.c", line 1019.5: 1506-495 (I) Pointer type conversion found.                                                                                 "Objects/genobject.c", line 1019.5: 1506-495 (I) Pointer type conversion found.
"Objects/genobject.c", line 1019.5: 1506-374 (I) Pointer types "struct _object*" and "struct {...}*" are not compatible.                                        "Objects/genobject.c", line 1019.5: 1506-374 (I) Pointer types "struct _object*" and "struct {...}*" are not compatible.
"Objects/genobject.c", line 1019.5: 1506-425 (I) The condition is always false.                                                                                 "Objects/genobject.c", line 1019.5: 1506-425 (I) The condition is always false.
     1020 |     PyObject_GC_Del(cw);                                                                                                                                 1020 |     PyObject_GC_Del(cw);
     1021 | }                                                                                                                                                        1021 | }
     1022 |                                                                                                                                                          1022 |
     1023 | static PyObject *                                                                                                                                        1023 | static PyObject *
     1024 | coro_wrapper_iternext(PyCoroWrapper *cw)                                                                                                                 1024 | coro_wrapper_iternext(PyCoroWrapper *cw)
     1025 | {                                                                                                                                                        1025 | {
     1026 |     return gen_send_ex((PyGenObject *)cw->cw_coroutine, NULL, 0, 0);                                                                                     1026 |     return gen_send_ex((PyGenObject *)cw->cw_coroutine, NULL, 0, 0);
     1026 +     return gen_send_ex((PyGenObject *)cw->cw_coroutine, 0, 0, 0);                                                                                        1026 +     return gen_send_ex((PyGenObject *)cw->cw_coroutine, 0, 0, 0);
"Objects/genobject.c", line 1026.24: 1506-495 (I) Pointer type conversion found.                                                                                "Objects/genobject.c", line 1026.24: 1506-495 (I) Pointer type conversion found.
"Objects/genobject.c", line 1026.24: 1506-374 (I) Pointer types "struct {...}*" and "struct {...}*" are not compatible.                                         "Objects/genobject.c", line 1026.24: 1506-374 (I) Pointer types "struct {...}*" and "struct {...}*" are not compatible.
     1027 | }                                                                                                                                                        1027 | }
     1028 |                                                                                                                                                          1028 |
     1029 | static PyObject *                                                                                                                                        1029 | static PyObject *
     1030 | coro_wrapper_send(PyCoroWrapper *cw, PyObject *arg)                                                                                                      1030 | coro_wrapper_send(PyCoroWrapper *cw, PyObject *arg)
     1031 | {                                                                                                                                                        1031 | {
     1032 |     return gen_send_ex((PyGenObject *)cw->cw_coroutine, arg, 0, 0);                                                                                      1032 |     return gen_send_ex((PyGenObject *)cw->cw_coroutine, arg, 0, 0);
"Objects/genobject.c", line 1032.24: 1506-495 (I) Pointer type conversion found.                                                                                "Objects/genobject.c", line 1032.24: 1506-495 (I) Pointer type conversion found.
"Objects/genobject.c", line 1032.24: 1506-374 (I) Pointer types "struct {...}*" and "struct {...}*" are not compatible.                                         "Objects/genobject.c", line 1032.24: 1506-374 (I) Pointer types "struct {...}*" and "struct {...}*" are not compatible.
     1033 | }                                                                                                                                                        1033 | }
     1034 |                                                                                                                                                          1034 |
     1035 | static PyObject *                                                                                                                                        1035 | static PyObject *
     1036 | coro_wrapper_throw(PyCoroWrapper *cw, PyObject *args)                                                                                                    1036 | coro_wrapper_throw(PyCoroWrapper *cw, PyObject *args)
     1037 | {                                                                                                                                                        1037 | {
     1038 |     return gen_throw((PyGenObject *)cw->cw_coroutine, args);                                                                                             1038 |     return gen_throw((PyGenObject *)cw->cw_coroutine, args);
"Objects/genobject.c", line 1038.22: 1506-495 (I) Pointer type conversion found.                                                                                "Objects/genobject.c", line 1038.22: 1506-495 (I) Pointer type conversion found.
"Objects/genobject.c", line 1038.22: 1506-374 (I) Pointer types "struct {...}*" and "struct {...}*" are not compatible.                                         "Objects/genobject.c", line 1038.22: 1506-374 (I) Pointer types "struct {...}*" and "struct {...}*" are not compatible.
     1039 | }                                                                                                                                                        1039 | }
     1040 |                                                                                                                                                          1040 |
     1041 | static PyObject *                                                                                                                                        1041 | static PyObject *
     1042 | coro_wrapper_close(PyCoroWrapper *cw, PyObject *args)                                                                                                    1042 | coro_wrapper_close(PyCoroWrapper *cw, PyObject *args)
     1043 | {                                                                                                                                                        1043 | {
     1044 |     return gen_close((PyGenObject *)cw->cw_coroutine, args);                                                                                             1044 |     return gen_close((PyGenObject *)cw->cw_coroutine, args);
"Objects/genobject.c", line 1044.22: 1506-495 (I) Pointer type conversion found.                                                                                "Objects/genobject.c", line 1044.22: 1506-495 (I) Pointer type conversion found.
"Objects/genobject.c", line 1044.22: 1506-374 (I) Pointer types "struct {...}*" and "struct {...}*" are not compatible.                                         "Objects/genobject.c", line 1044.22: 1506-374 (I) Pointer types "struct {...}*" and "struct {...}*" are not compatible.
     1045 | }                                                                                                                                                        1045 | }
     1046 |                                                                                                                                                          1046 |
     1047 | static int                                                                                                                                               1047 | static int
     1048 | coro_wrapper_traverse(PyCoroWrapper *cw, visitproc visit, void *arg)                                                                                     1048 | coro_wrapper_traverse(PyCoroWrapper *cw, visitproc visit, void *arg)







Wed Apr 15 07:30:04 CDT 2020  Page 30


     1049 | {                                                                                                                                                        1049 | {
     1050 |     Py_VISIT((PyObject *)cw->cw_coroutine);                                                                                                              1050 |     Py_VISIT((PyObject *)cw->cw_coroutine);
     1050 +     do { if ((PyObject *)cw->cw_coroutine) { int vret = visit(((PyObject*)((PyObject *)cw->cw_coroutine)), arg); if (vret) return vret; } } while (      1050 +     do { if ((PyObject *)cw->cw_coroutine) { int vret = visit(((PyObject*)((PyObject *)cw->cw_coroutine)), arg); if (vret) return vret; } } while (
"Objects/genobject.c", line 1050.14: 1506-495 (I) Pointer type conversion found.                                                                                "Objects/genobject.c", line 1050.14: 1506-495 (I) Pointer type conversion found.
"Objects/genobject.c", line 1050.14: 1506-374 (I) Pointer types "struct _object*" and "struct {...}*" are not compatible.                                       "Objects/genobject.c", line 1050.14: 1506-374 (I) Pointer types "struct _object*" and "struct {...}*" are not compatible.
"Objects/genobject.c", line 1050.5: 1506-495 (I) Pointer type conversion found.                                                                                 "Objects/genobject.c", line 1050.5: 1506-495 (I) Pointer type conversion found.
"Objects/genobject.c", line 1050.5: 1506-374 (I) Pointer types "struct _object*" and "struct {...}*" are not compatible.                                        "Objects/genobject.c", line 1050.5: 1506-374 (I) Pointer types "struct _object*" and "struct {...}*" are not compatible.
"Objects/genobject.c", line 1050.5: 1506-425 (I) The condition is always false.                                                                                 "Objects/genobject.c", line 1050.5: 1506-425 (I) The condition is always false.
     1051 |     return 0;                                                                                                                                            1051 |     return 0;
     1052 | }                                                                                                                                                        1052 | }
     1053 |                                                                                                                                                          1053 |
     1054 | static PyMethodDef coro_wrapper_methods[] = {                                                                                                            1054 | static PyMethodDef coro_wrapper_methods[] = {
"Objects/genobject.c", line 1054.43: 1506-446 (I) Array element(s) [3] will be initialized with a default value of 0.                                           "Objects/genobject.c", line 1054.43: 1506-446 (I) Array element(s) [3] will be initialized with a default value of 0.
     1055 |     {"send",(PyCFunction)coro_wrapper_send, METH_O, coro_send_doc},                                                                                      1055 |     {"send",(PyCFunction)coro_wrapper_send, METH_O, coro_send_doc},
     1055 +     {"send",(PyCFunction)coro_wrapper_send, 0x0008, coro_send_doc},                                                                                      1055 +     {"send",(PyCFunction)coro_wrapper_send, 0x0008, coro_send_doc},
     1056 |     {"throw",(PyCFunction)coro_wrapper_throw, METH_VARARGS, coro_throw_doc},                                                                             1056 |     {"throw",(PyCFunction)coro_wrapper_throw, METH_VARARGS, coro_throw_doc},
     1056 +     {"throw",(PyCFunction)coro_wrapper_throw, 0x0001, coro_throw_doc},                                                                                   1056 +     {"throw",(PyCFunction)coro_wrapper_throw, 0x0001, coro_throw_doc},
     1057 |     {"close",(PyCFunction)coro_wrapper_close, METH_NOARGS, coro_close_doc},                                                                              1057 |     {"close",(PyCFunction)coro_wrapper_close, METH_NOARGS, coro_close_doc},
     1057 +     {"close",(PyCFunction)coro_wrapper_close, 0x0004, coro_close_doc},                                                                                   1057 +     {"close",(PyCFunction)coro_wrapper_close, 0x0004, coro_close_doc},
     1058 |     {NULL, NULL}        /* Sentinel */                                                                                                                   1058 |     {NULL, NULL}        /* Sentinel */
     1058 +     {0, 0}        /* Sentinel */                                                                                                                         1058 +     {0, 0}        /* Sentinel */
"Objects/genobject.c", line 1058.16: 1506-447 (I) The member(s) starting from "ml_flags" will be initialized with a default value of 0.                         "Objects/genobject.c", line 1058.16: 1506-447 (I) The member(s) starting from "ml_flags" will be initialized with a default value of 0.
     1059 | };                                                                                                                                                       1059 | };
     1060 |                                                                                                                                                          1060 |
     1061 | PyTypeObject _PyCoroWrapper_Type = {                                                                                                                     1061 | PyTypeObject _PyCoroWrapper_Type = {
     1062 |     PyVarObject_HEAD_INIT(&PyType_Type, 0)                                                                                                               1062 |     PyVarObject_HEAD_INIT(&PyType_Type, 0)
     1062 +     { {   1, &PyType_Type }, 0 },                                                                                                                        1062 +     { {   1, &PyType_Type }, 0 },
     1063 |     "coroutine_wrapper",                                                                                                                                 1063 |     "coroutine_wrapper",
     1064 |     sizeof(PyCoroWrapper),                      /* tp_basicsize */                                                                                       1064 |     sizeof(PyCoroWrapper),                      /* tp_basicsize */
     1065 |     0,                                          /* tp_itemsize */                                                                                        1065 |     0,                                          /* tp_itemsize */
     1066 |     (destructor)coro_wrapper_dealloc,           /* destructor tp_dealloc */                                                                              1066 |     (destructor)coro_wrapper_dealloc,           /* destructor tp_dealloc */
     1067 |     0,                                          /* tp_vectorcall_offset */                                                                               1067 |     0,                                          /* tp_vectorcall_offset */
     1068 |     0,                                          /* tp_getattr */                                                                                         1068 |     0,                                          /* tp_getattr */
     1069 |     0,                                          /* tp_setattr */                                                                                         1069 |     0,                                          /* tp_setattr */
     1070 |     0,                                          /* tp_as_async */                                                                                        1070 |     0,                                          /* tp_as_async */
     1071 |     0,                                          /* tp_repr */                                                                                            1071 |     0,                                          /* tp_repr */
     1072 |     0,                                          /* tp_as_number */                                                                                       1072 |     0,                                          /* tp_as_number */
     1073 |     0,                                          /* tp_as_sequence */                                                                                     1073 |     0,                                          /* tp_as_sequence */
     1074 |     0,                                          /* tp_as_mapping */                                                                                      1074 |     0,                                          /* tp_as_mapping */
     1075 |     0,                                          /* tp_hash */                                                                                            1075 |     0,                                          /* tp_hash */
     1076 |     0,                                          /* tp_call */                                                                                            1076 |     0,                                          /* tp_call */
     1077 |     0,                                          /* tp_str */                                                                                             1077 |     0,                                          /* tp_str */
     1078 |     PyObject_GenericGetAttr,                    /* tp_getattro */                                                                                        1078 |     PyObject_GenericGetAttr,                    /* tp_getattro */
     1079 |     0,                                          /* tp_setattro */                                                                                        1079 |     0,                                          /* tp_setattro */
     1080 |     0,                                          /* tp_as_buffer */                                                                                       1080 |     0,                                          /* tp_as_buffer */
     1081 |     Py_TPFLAGS_DEFAULT | Py_TPFLAGS_HAVE_GC,    /* tp_flags */                                                                                           1081 |     Py_TPFLAGS_DEFAULT | Py_TPFLAGS_HAVE_GC,    /* tp_flags */
     1081 +     ( 0 | (1UL << 18) | 0) | (1UL << 14),    /* tp_flags */                                                                                              1081 +     ( 0 | (1UL << 18) | 0) | (1UL << 14),    /* tp_flags */
     1082 |     "A wrapper object implementing __await__ for coroutines.",                                                                                           1082 |     "A wrapper object implementing __await__ for coroutines.",
     1083 |     (traverseproc)coro_wrapper_traverse,        /* tp_traverse */                                                                                        1083 |     (traverseproc)coro_wrapper_traverse,        /* tp_traverse */
     1084 |     0,                                          /* tp_clear */                                                                                           1084 |     0,                                          /* tp_clear */
     1085 |     0,                                          /* tp_richcompare */                                                                                     1085 |     0,                                          /* tp_richcompare */
     1086 |     0,                                          /* tp_weaklistoffset */                                                                                  1086 |     0,                                          /* tp_weaklistoffset */
     1087 |     PyObject_SelfIter,                          /* tp_iter */                                                                                            1087 |     PyObject_SelfIter,                          /* tp_iter */
     1088 |     (iternextfunc)coro_wrapper_iternext,        /* tp_iternext */                                                                                        1088 |     (iternextfunc)coro_wrapper_iternext,        /* tp_iternext */
     1089 |     coro_wrapper_methods,                       /* tp_methods */                                                                                         1089 |     coro_wrapper_methods,                       /* tp_methods */
     1090 |     0,                                          /* tp_members */                                                                                         1090 |     0,                                          /* tp_members */







Wed Apr 15 07:30:04 CDT 2020  Page 31


     1091 |     0,                                          /* tp_getset */                                                                                          1091 |     0,                                          /* tp_getset */
     1092 |     0,                                          /* tp_base */                                                                                            1092 |     0,                                          /* tp_base */
     1093 |     0,                                          /* tp_dict */                                                                                            1093 |     0,                                          /* tp_dict */
     1094 |     0,                                          /* tp_descr_get */                                                                                       1094 |     0,                                          /* tp_descr_get */
     1095 |     0,                                          /* tp_descr_set */                                                                                       1095 |     0,                                          /* tp_descr_set */
     1096 |     0,                                          /* tp_dictoffset */                                                                                      1096 |     0,                                          /* tp_dictoffset */
     1097 |     0,                                          /* tp_init */                                                                                            1097 |     0,                                          /* tp_init */
     1098 |     0,                                          /* tp_alloc */                                                                                           1098 |     0,                                          /* tp_alloc */
     1099 |     0,                                          /* tp_new */                                                                                             1099 |     0,                                          /* tp_new */
     1100 |     0,                                          /* tp_free */                                                                                            1100 |     0,                                          /* tp_free */
     1101 | };                                                                                                                                                       1101 | };
"Objects/genobject.c", line 1101.1: 1506-447 (I) The member(s) starting from "tp_is_gc" will be initialized with a default value of 0.                          "Objects/genobject.c", line 1101.1: 1506-447 (I) The member(s) starting from "tp_is_gc" will be initialized with a default value of 0.
     1102 |                                                                                                                                                          1102 |
     1103 | static PyObject *                                                                                                                                        1103 | static PyObject *
     1104 | compute_cr_origin(int origin_depth)                                                                                                                      1104 | compute_cr_origin(int origin_depth)
     1105 | {                                                                                                                                                        1105 | {
     1106 |     PyFrameObject *frame = PyEval_GetFrame();                                                                                                            1106 |     PyFrameObject *frame = PyEval_GetFrame();
     1107 |     /* First count how many frames we have */                                                                                                            1107 |     /* First count how many frames we have */
     1108 |     int frame_count = 0;                                                                                                                                 1108 |     int frame_count = 0;
     1109 |     for (; frame && frame_count < origin_depth; ++frame_count) {                                                                                         1109 |     for (; frame && frame_count < origin_depth; ++frame_count) {
     1110 |         frame = frame->f_back;                                                                                                                           1110 |         frame = frame->f_back;
     1111 |     }                                                                                                                                                    1111 |     }
     1112 |                                                                                                                                                          1112 |
     1113 |     /* Now collect them */                                                                                                                               1113 |     /* Now collect them */
     1114 |     PyObject *cr_origin = PyTuple_New(frame_count);                                                                                                      1114 |     PyObject *cr_origin = PyTuple_New(frame_count);
     1115 |     if (cr_origin == NULL) {                                                                                                                             1115 |     if (cr_origin == NULL) {
     1115 +     if (cr_origin == 0) {                                                                                                                                1115 +     if (cr_origin == 0) {
     1116 |         return NULL;                                                                                                                                     1116 |         return NULL;
     1116 +         return 0;                                                                                                                                        1116 +         return 0;
     1117 |     }                                                                                                                                                    1117 |     }
     1118 |     frame = PyEval_GetFrame();                                                                                                                           1118 |     frame = PyEval_GetFrame();
     1119 |     for (int i = 0; i < frame_count; ++i) {                                                                                                              1119 |     for (int i = 0; i < frame_count; ++i) {
     1120 |         PyObject *frameinfo = Py_BuildValue(                                                                                                             1120 |         PyObject *frameinfo = Py_BuildValue(
     1121 |             "OiO",                                                                                                                                       1121 |             "OiO",
     1122 |             frame->f_code->co_filename,                                                                                                                  1122 |             frame->f_code->co_filename,
     1123 |             PyFrame_GetLineNumber(frame),                                                                                                                1123 |             PyFrame_GetLineNumber(frame),
     1124 |             frame->f_code->co_name);                                                                                                                     1124 |             frame->f_code->co_name);
     1125 |         if (!frameinfo) {                                                                                                                                1125 |         if (!frameinfo) {
     1126 |             Py_DECREF(cr_origin);                                                                                                                        1126 |             Py_DECREF(cr_origin);
     1126 +             _Py_DECREF("Objects/genobject.c", 1126, ((PyObject*)(cr_origin)));                                                                           1126 +             _Py_DECREF("Objects/genobject.c", 1126, ((PyObject*)(cr_origin)));
     1127 |             return NULL;                                                                                                                                 1127 |             return NULL;
     1127 +             return 0;                                                                                                                                    1127 +             return 0;
     1128 |         }                                                                                                                                                1128 |         }
     1129 |         PyTuple_SET_ITEM(cr_origin, i, frameinfo);                                                                                                       1129 |         PyTuple_SET_ITEM(cr_origin, i, frameinfo);
     1129 +         ((((PyType_HasFeature((((PyObject*)(cr_origin))->ob_type), (1UL << 26))) ? ((void)0) : __assert("PyTuple_Check(cr_origin)", "Objects/genobj      1129 +         ((((PyType_HasFeature((((PyObject*)(cr_origin))->ob_type), (1UL << 26))) ? ((void)0) : __assert("PyTuple_Check(cr_origin)", "Objects/genobj
"Objects/genobject.c", line 1129.9: 1506-495 (I) Pointer type conversion found.                                                                                 "Objects/genobject.c", line 1129.9: 1506-495 (I) Pointer type conversion found.
"Objects/genobject.c", line 1129.9: 1506-374 (I) Pointer types "struct {...}*" and "struct _object*" are not compatible.                                        "Objects/genobject.c", line 1129.9: 1506-374 (I) Pointer types "struct {...}*" and "struct _object*" are not compatible.
     1130 |         frame = frame->f_back;                                                                                                                           1130 |         frame = frame->f_back;
     1131 |     }                                                                                                                                                    1131 |     }
     1132 |                                                                                                                                                          1132 |
     1133 |     return cr_origin;                                                                                                                                    1133 |     return cr_origin;
     1134 | }                                                                                                                                                        1134 | }
     1135 |                                                                                                                                                          1135 |
     1136 | PyObject *                                                                                                                                               1136 | PyObject *
     1137 | PyCoro_New(PyFrameObject *f, PyObject *name, PyObject *qualname)                                                                                         1137 | PyCoro_New(PyFrameObject *f, PyObject *name, PyObject *qualname)
     1138 | {                                                                                                                                                        1138 | {







Wed Apr 15 07:30:04 CDT 2020  Page 32


     1139 |     PyObject *coro = gen_new_with_qualname(&PyCoro_Type, f, name, qualname);                                                                             1139 |     PyObject *coro = gen_new_with_qualname(&PyCoro_Type, f, name, qualname);
     1140 |     if (!coro) {                                                                                                                                         1140 |     if (!coro) {
     1141 |         return NULL;                                                                                                                                     1141 |         return NULL;
     1141 +         return 0;                                                                                                                                        1141 +         return 0;
     1142 |     }                                                                                                                                                    1142 |     }
     1143 |                                                                                                                                                          1143 |
     1144 |     PyThreadState *tstate = _PyThreadState_GET();                                                                                                        1144 |     PyThreadState *tstate = _PyThreadState_GET();
     1145 |     int origin_depth = tstate->coroutine_origin_tracking_depth;                                                                                          1145 |     int origin_depth = tstate->coroutine_origin_tracking_depth;
     1146 |                                                                                                                                                          1146 |
     1147 |     if (origin_depth == 0) {                                                                                                                             1147 |     if (origin_depth == 0) {
     1148 |         ((PyCoroObject *)coro)->cr_origin = NULL;                                                                                                        1148 |         ((PyCoroObject *)coro)->cr_origin = NULL;
     1148 +         ((PyCoroObject *)coro)->cr_origin = 0;                                                                                                           1148 +         ((PyCoroObject *)coro)->cr_origin = 0;
"Objects/genobject.c", line 1148.9: 1506-495 (I) Pointer type conversion found.                                                                                 "Objects/genobject.c", line 1148.9: 1506-495 (I) Pointer type conversion found.
"Objects/genobject.c", line 1148.9: 1506-374 (I) Pointer types "struct {...}*" and "struct _object*" are not compatible.                                        "Objects/genobject.c", line 1148.9: 1506-374 (I) Pointer types "struct {...}*" and "struct _object*" are not compatible.
     1149 |     } else {                                                                                                                                             1149 |     } else {
     1150 |         PyObject *cr_origin = compute_cr_origin(origin_depth);                                                                                           1150 |         PyObject *cr_origin = compute_cr_origin(origin_depth);
     1151 |         ((PyCoroObject *)coro)->cr_origin = cr_origin;                                                                                                   1151 |         ((PyCoroObject *)coro)->cr_origin = cr_origin;
"Objects/genobject.c", line 1151.9: 1506-495 (I) Pointer type conversion found.                                                                                 "Objects/genobject.c", line 1151.9: 1506-495 (I) Pointer type conversion found.
"Objects/genobject.c", line 1151.9: 1506-374 (I) Pointer types "struct {...}*" and "struct _object*" are not compatible.                                        "Objects/genobject.c", line 1151.9: 1506-374 (I) Pointer types "struct {...}*" and "struct _object*" are not compatible.
     1152 |         if (!cr_origin) {                                                                                                                                1152 |         if (!cr_origin) {
     1153 |             Py_DECREF(coro);                                                                                                                             1153 |             Py_DECREF(coro);
     1153 +             _Py_DECREF("Objects/genobject.c", 1153, ((PyObject*)(coro)));                                                                                1153 +             _Py_DECREF("Objects/genobject.c", 1153, ((PyObject*)(coro)));
     1154 |             return NULL;                                                                                                                                 1154 |             return NULL;
     1154 +             return 0;                                                                                                                                    1154 +             return 0;
     1155 |         }                                                                                                                                                1155 |         }
     1156 |     }                                                                                                                                                    1156 |     }
     1157 |                                                                                                                                                          1157 |
     1158 |     return coro;                                                                                                                                         1158 |     return coro;
     1159 | }                                                                                                                                                        1159 | }
     1160 |                                                                                                                                                          1160 |
     1161 |                                                                                                                                                          1161 |
     1162 | /* ========= Asynchronous Generators ========= */                                                                                                        1162 | /* ========= Asynchronous Generators ========= */
     1163 |                                                                                                                                                          1163 |
     1164 |                                                                                                                                                          1164 |
     1165 | typedef enum {                                                                                                                                           1165 | typedef enum {
     1166 |     AWAITABLE_STATE_INIT,   /* new awaitable, has not yet been iterated */                                                                               1166 |     AWAITABLE_STATE_INIT,   /* new awaitable, has not yet been iterated */
     1167 |     AWAITABLE_STATE_ITER,   /* being iterated */                                                                                                         1167 |     AWAITABLE_STATE_ITER,   /* being iterated */
     1168 |     AWAITABLE_STATE_CLOSED, /* closed */                                                                                                                 1168 |     AWAITABLE_STATE_CLOSED, /* closed */
     1169 | } AwaitableState;                                                                                                                                        1169 | } AwaitableState;
     1170 |                                                                                                                                                          1170 |
     1171 |                                                                                                                                                          1171 |
     1172 | typedef struct {                                                                                                                                         1172 | typedef struct {
     1173 |     PyObject_HEAD                                                                                                                                        1173 |     PyObject_HEAD
     1173 +     PyObject ob_base;                                                                                                                                    1173 +     PyObject ob_base;
     1174 |     PyAsyncGenObject *ags_gen;                                                                                                                           1174 |     PyAsyncGenObject *ags_gen;
     1175 |                                                                                                                                                          1175 |
     1176 |     /* Can be NULL, when in the __anext__() mode                                                                                                         1176 |     /* Can be NULL, when in the __anext__() mode
     1177 |        (equivalent of "asend(None)") */                                                                                                                  1177 |        (equivalent of "asend(None)") */
     1178 |     PyObject *ags_sendval;                                                                                                                               1178 |     PyObject *ags_sendval;
     1179 |                                                                                                                                                          1179 |
     1180 |     AwaitableState ags_state;                                                                                                                            1180 |     AwaitableState ags_state;
     1181 | } PyAsyncGenASend;                                                                                                                                       1181 | } PyAsyncGenASend;
     1182 |                                                                                                                                                          1182 |
     1183 |                                                                                                                                                          1183 |
     1184 | typedef struct {                                                                                                                                         1184 | typedef struct {
     1185 |     PyObject_HEAD                                                                                                                                        1185 |     PyObject_HEAD







Wed Apr 15 07:30:04 CDT 2020  Page 33


     1185 +     PyObject ob_base;                                                                                                                                    1185 +     PyObject ob_base;
     1186 |     PyAsyncGenObject *agt_gen;                                                                                                                           1186 |     PyAsyncGenObject *agt_gen;
     1187 |                                                                                                                                                          1187 |
     1188 |     /* Can be NULL, when in the "aclose()" mode                                                                                                          1188 |     /* Can be NULL, when in the "aclose()" mode
     1189 |        (equivalent of "athrow(GeneratorExit)") */                                                                                                        1189 |        (equivalent of "athrow(GeneratorExit)") */
     1190 |     PyObject *agt_args;                                                                                                                                  1190 |     PyObject *agt_args;
     1191 |                                                                                                                                                          1191 |
     1192 |     AwaitableState agt_state;                                                                                                                            1192 |     AwaitableState agt_state;
     1193 | } PyAsyncGenAThrow;                                                                                                                                      1193 | } PyAsyncGenAThrow;
     1194 |                                                                                                                                                          1194 |
     1195 |                                                                                                                                                          1195 |
     1196 | typedef struct {                                                                                                                                         1196 | typedef struct {
     1197 |     PyObject_HEAD                                                                                                                                        1197 |     PyObject_HEAD
     1197 +     PyObject ob_base;                                                                                                                                    1197 +     PyObject ob_base;
     1198 |     PyObject *agw_val;                                                                                                                                   1198 |     PyObject *agw_val;
     1199 | } _PyAsyncGenWrappedValue;                                                                                                                               1199 | } _PyAsyncGenWrappedValue;
     1200 |                                                                                                                                                          1200 |
     1201 |                                                                                                                                                          1201 |
     1202 | #ifndef _PyAsyncGen_MAXFREELIST                                                                                                                          1202 | #ifndef _PyAsyncGen_MAXFREELIST
     1203 | #define _PyAsyncGen_MAXFREELIST 80                                                                                                                       1203 | #define _PyAsyncGen_MAXFREELIST 80
     1204 | #endif                                                                                                                                                   1204 | #endif
     1205 |                                                                                                                                                          1205 |
     1206 | /* Freelists boost performance 6-10%; they also reduce memory                                                                                            1206 | /* Freelists boost performance 6-10%; they also reduce memory
     1207 |    fragmentation, as _PyAsyncGenWrappedValue and PyAsyncGenASend                                                                                         1207 |    fragmentation, as _PyAsyncGenWrappedValue and PyAsyncGenASend
     1208 |    are short-living objects that are instantiated for every                                                                                              1208 |    are short-living objects that are instantiated for every
     1209 |    __anext__ call.                                                                                                                                       1209 |    __anext__ call.
     1210 | */                                                                                                                                                       1210 | */
     1211 |                                                                                                                                                          1211 |
     1212 | static _PyAsyncGenWrappedValue *ag_value_freelist[_PyAsyncGen_MAXFREELIST];                                                                              1212 | static _PyAsyncGenWrappedValue *ag_value_freelist[_PyAsyncGen_MAXFREELIST];
     1212 + static _PyAsyncGenWrappedValue *ag_value_freelist[80];                                                                                                   1212 + static _PyAsyncGenWrappedValue *ag_value_freelist[80];
     1213 | static int ag_value_freelist_free = 0;                                                                                                                   1213 | static int ag_value_freelist_free = 0;
     1214 |                                                                                                                                                          1214 |
     1215 | static PyAsyncGenASend *ag_asend_freelist[_PyAsyncGen_MAXFREELIST];                                                                                      1215 | static PyAsyncGenASend *ag_asend_freelist[_PyAsyncGen_MAXFREELIST];
     1215 + static PyAsyncGenASend *ag_asend_freelist[80];                                                                                                           1215 + static PyAsyncGenASend *ag_asend_freelist[80];
     1216 | static int ag_asend_freelist_free = 0;                                                                                                                   1216 | static int ag_asend_freelist_free = 0;
     1217 |                                                                                                                                                          1217 |
     1218 | #define _PyAsyncGenWrappedValue_CheckExact(o) \                                                                                                          1218 | #define _PyAsyncGenWrappedValue_CheckExact(o) \
     1219 |                     Py_IS_TYPE(o, &_PyAsyncGenWrappedValue_Type)                                                                                         1219 |                     Py_IS_TYPE(o, &_PyAsyncGenWrappedValue_Type)
     1220 |                                                                                                                                                          1220 |
     1221 | #define PyAsyncGenASend_CheckExact(o) \                                                                                                                  1221 | #define PyAsyncGenASend_CheckExact(o) \
     1222 |                     Py_IS_TYPE(o, &_PyAsyncGenASend_Type)                                                                                                1222 |                     Py_IS_TYPE(o, &_PyAsyncGenASend_Type)
     1223 |                                                                                                                                                          1223 |
     1224 |                                                                                                                                                          1224 |
     1225 | static int                                                                                                                                               1225 | static int
     1226 | async_gen_traverse(PyAsyncGenObject *gen, visitproc visit, void *arg)                                                                                    1226 | async_gen_traverse(PyAsyncGenObject *gen, visitproc visit, void *arg)
     1227 | {                                                                                                                                                        1227 | {
     1228 |     Py_VISIT(gen->ag_finalizer);                                                                                                                         1228 |     Py_VISIT(gen->ag_finalizer);
     1228 +     do { if (gen->ag_finalizer) { int vret = visit(((PyObject*)(gen->ag_finalizer)), arg); if (vret) return vret; } } while (0);                         1228 +     do { if (gen->ag_finalizer) { int vret = visit(((PyObject*)(gen->ag_finalizer)), arg); if (vret) return vret; } } while (0);
"Objects/genobject.c", line 1228.5: 1506-425 (I) The condition is always false.                                                                                 "Objects/genobject.c", line 1228.5: 1506-425 (I) The condition is always false.
     1229 |     return gen_traverse((PyGenObject*)gen, visit, arg);                                                                                                  1229 |     return gen_traverse((PyGenObject*)gen, visit, arg);
"Objects/genobject.c", line 1229.25: 1506-495 (I) Pointer type conversion found.                                                                                "Objects/genobject.c", line 1229.25: 1506-495 (I) Pointer type conversion found.
"Objects/genobject.c", line 1229.25: 1506-374 (I) Pointer types "struct {...}*" and "struct {...}*" are not compatible.                                         "Objects/genobject.c", line 1229.25: 1506-374 (I) Pointer types "struct {...}*" and "struct {...}*" are not compatible.
     1230 | }                                                                                                                                                        1230 | }
     1231 |                                                                                                                                                          1231 |
     1232 |                                                                                                                                                          1232 |
     1233 | static PyObject *                                                                                                                                        1233 | static PyObject *







Wed Apr 15 07:30:04 CDT 2020  Page 34


     1234 | async_gen_repr(PyAsyncGenObject *o)                                                                                                                      1234 | async_gen_repr(PyAsyncGenObject *o)
     1235 | {                                                                                                                                                        1235 | {
     1236 |     return PyUnicode_FromFormat("<async_generator object %S at %p>",                                                                                     1236 |     return PyUnicode_FromFormat("<async_generator object %S at %p>",
     1237 |                                 o->ag_qualname, o);                                                                                                      1237 |                                 o->ag_qualname, o);
     1238 | }                                                                                                                                                        1238 | }
     1239 |                                                                                                                                                          1239 |
     1240 |                                                                                                                                                          1240 |
     1241 | static int                                                                                                                                               1241 | static int
     1242 | async_gen_init_hooks(PyAsyncGenObject *o)                                                                                                                1242 | async_gen_init_hooks(PyAsyncGenObject *o)
     1243 | {                                                                                                                                                        1243 | {
     1244 |     PyThreadState *tstate;                                                                                                                               1244 |     PyThreadState *tstate;
     1245 |     PyObject *finalizer;                                                                                                                                 1245 |     PyObject *finalizer;
     1246 |     PyObject *firstiter;                                                                                                                                 1246 |     PyObject *firstiter;
     1247 |                                                                                                                                                          1247 |
     1248 |     if (o->ag_hooks_inited) {                                                                                                                            1248 |     if (o->ag_hooks_inited) {
     1249 |         return 0;                                                                                                                                        1249 |         return 0;
     1250 |     }                                                                                                                                                    1250 |     }
     1251 |                                                                                                                                                          1251 |
     1252 |     o->ag_hooks_inited = 1;                                                                                                                              1252 |     o->ag_hooks_inited = 1;
     1253 |                                                                                                                                                          1253 |
     1254 |     tstate = _PyThreadState_GET();                                                                                                                       1254 |     tstate = _PyThreadState_GET();
     1255 |                                                                                                                                                          1255 |
     1256 |     finalizer = tstate->async_gen_finalizer;                                                                                                             1256 |     finalizer = tstate->async_gen_finalizer;
     1257 |     if (finalizer) {                                                                                                                                     1257 |     if (finalizer) {
     1258 |         Py_INCREF(finalizer);                                                                                                                            1258 |         Py_INCREF(finalizer);
     1258 +         _Py_INCREF(((PyObject*)(finalizer)));                                                                                                            1258 +         _Py_INCREF(((PyObject*)(finalizer)));
     1259 |         o->ag_finalizer = finalizer;                                                                                                                     1259 |         o->ag_finalizer = finalizer;
     1260 |     }                                                                                                                                                    1260 |     }
     1261 |                                                                                                                                                          1261 |
     1262 |     firstiter = tstate->async_gen_firstiter;                                                                                                             1262 |     firstiter = tstate->async_gen_firstiter;
     1263 |     if (firstiter) {                                                                                                                                     1263 |     if (firstiter) {
     1264 |         PyObject *res;                                                                                                                                   1264 |         PyObject *res;
     1265 |                                                                                                                                                          1265 |
     1266 |         Py_INCREF(firstiter);                                                                                                                            1266 |         Py_INCREF(firstiter);
     1266 +         _Py_INCREF(((PyObject*)(firstiter)));                                                                                                            1266 +         _Py_INCREF(((PyObject*)(firstiter)));
     1267 |         res = PyObject_CallOneArg(firstiter, (PyObject *)o);                                                                                             1267 |         res = PyObject_CallOneArg(firstiter, (PyObject *)o);
"Objects/genobject.c", line 1267.46: 1506-495 (I) Pointer type conversion found.                                                                                "Objects/genobject.c", line 1267.46: 1506-495 (I) Pointer type conversion found.
"Objects/genobject.c", line 1267.46: 1506-374 (I) Pointer types "struct _object*" and "struct {...}*" are not compatible.                                       "Objects/genobject.c", line 1267.46: 1506-374 (I) Pointer types "struct _object*" and "struct {...}*" are not compatible.
     1268 |         Py_DECREF(firstiter);                                                                                                                            1268 |         Py_DECREF(firstiter);
     1268 +         _Py_DECREF("Objects/genobject.c", 1268, ((PyObject*)(firstiter)));                                                                               1268 +         _Py_DECREF("Objects/genobject.c", 1268, ((PyObject*)(firstiter)));
     1269 |         if (res == NULL) {                                                                                                                               1269 |         if (res == NULL) {
     1269 +         if (res == 0) {                                                                                                                                  1269 +         if (res == 0) {
     1270 |             return 1;                                                                                                                                    1270 |             return 1;
     1271 |         }                                                                                                                                                1271 |         }
     1272 |         Py_DECREF(res);                                                                                                                                  1272 |         Py_DECREF(res);
     1272 +         _Py_DECREF("Objects/genobject.c", 1272, ((PyObject*)(res)));                                                                                     1272 +         _Py_DECREF("Objects/genobject.c", 1272, ((PyObject*)(res)));
     1273 |     }                                                                                                                                                    1273 |     }
"Objects/genobject.c", line 1273.5: 1506-412 (I) Referenced variable "res", which was not initialized in its declaration.                                       "Objects/genobject.c", line 1273.5: 1506-412 (I) Referenced variable "res", which was not initialized in its declaration.
     1274 |                                                                                                                                                          1274 |
     1275 |     return 0;                                                                                                                                            1275 |     return 0;
     1276 | }                                                                                                                                                        1276 | }
"Objects/genobject.c", line 1276.1: 1506-412 (I) Referenced variable "firstiter", which was not initialized in its declaration.                                 "Objects/genobject.c", line 1276.1: 1506-412 (I) Referenced variable "firstiter", which was not initialized in its declaration.
"Objects/genobject.c", line 1276.1: 1506-412 (I) Referenced variable "finalizer", which was not initialized in its declaration.                                 "Objects/genobject.c", line 1276.1: 1506-412 (I) Referenced variable "finalizer", which was not initialized in its declaration.
"Objects/genobject.c", line 1276.1: 1506-412 (I) Referenced variable "tstate", which was not initialized in its declaration.                                    "Objects/genobject.c", line 1276.1: 1506-412 (I) Referenced variable "tstate", which was not initialized in its declaration.
     1277 |                                                                                                                                                          1277 |
     1278 |                                                                                                                                                          1278 |







Wed Apr 15 07:30:04 CDT 2020  Page 35


     1279 | static PyObject *                                                                                                                                        1279 | static PyObject *
     1280 | async_gen_anext(PyAsyncGenObject *o)                                                                                                                     1280 | async_gen_anext(PyAsyncGenObject *o)
     1281 | {                                                                                                                                                        1281 | {
     1282 |     if (async_gen_init_hooks(o)) {                                                                                                                       1282 |     if (async_gen_init_hooks(o)) {
     1283 |         return NULL;                                                                                                                                     1283 |         return NULL;
     1283 +         return 0;                                                                                                                                        1283 +         return 0;
     1284 |     }                                                                                                                                                    1284 |     }
     1285 |     return async_gen_asend_new(o, NULL);                                                                                                                 1285 |     return async_gen_asend_new(o, NULL);
     1285 +     return async_gen_asend_new(o, 0);                                                                                                                    1285 +     return async_gen_asend_new(o, 0);
     1286 | }                                                                                                                                                        1286 | }
     1287 |                                                                                                                                                          1287 |
     1288 |                                                                                                                                                          1288 |
     1289 | static PyObject *                                                                                                                                        1289 | static PyObject *
     1290 | async_gen_asend(PyAsyncGenObject *o, PyObject *arg)                                                                                                      1290 | async_gen_asend(PyAsyncGenObject *o, PyObject *arg)
     1291 | {                                                                                                                                                        1291 | {
     1292 |     if (async_gen_init_hooks(o)) {                                                                                                                       1292 |     if (async_gen_init_hooks(o)) {
     1293 |         return NULL;                                                                                                                                     1293 |         return NULL;
     1293 +         return 0;                                                                                                                                        1293 +         return 0;
     1294 |     }                                                                                                                                                    1294 |     }
     1295 |     return async_gen_asend_new(o, arg);                                                                                                                  1295 |     return async_gen_asend_new(o, arg);
     1296 | }                                                                                                                                                        1296 | }
     1297 |                                                                                                                                                          1297 |
     1298 |                                                                                                                                                          1298 |
     1299 | static PyObject *                                                                                                                                        1299 | static PyObject *
     1300 | async_gen_aclose(PyAsyncGenObject *o, PyObject *arg)                                                                                                     1300 | async_gen_aclose(PyAsyncGenObject *o, PyObject *arg)
     1301 | {                                                                                                                                                        1301 | {
     1302 |     if (async_gen_init_hooks(o)) {                                                                                                                       1302 |     if (async_gen_init_hooks(o)) {
     1303 |         return NULL;                                                                                                                                     1303 |         return NULL;
     1303 +         return 0;                                                                                                                                        1303 +         return 0;
     1304 |     }                                                                                                                                                    1304 |     }
     1305 |     return async_gen_athrow_new(o, NULL);                                                                                                                1305 |     return async_gen_athrow_new(o, NULL);
     1305 +     return async_gen_athrow_new(o, 0);                                                                                                                   1305 +     return async_gen_athrow_new(o, 0);
     1306 | }                                                                                                                                                        1306 | }
"Objects/genobject.c", line 1306.1: 1506-414 (I) The parameter "arg" is never referenced.                                                                       "Objects/genobject.c", line 1306.1: 1506-414 (I) The parameter "arg" is never referenced.
     1307 |                                                                                                                                                          1307 |
     1308 | static PyObject *                                                                                                                                        1308 | static PyObject *
     1309 | async_gen_athrow(PyAsyncGenObject *o, PyObject *args)                                                                                                    1309 | async_gen_athrow(PyAsyncGenObject *o, PyObject *args)
     1310 | {                                                                                                                                                        1310 | {
     1311 |     if (async_gen_init_hooks(o)) {                                                                                                                       1311 |     if (async_gen_init_hooks(o)) {
     1312 |         return NULL;                                                                                                                                     1312 |         return NULL;
     1312 +         return 0;                                                                                                                                        1312 +         return 0;
     1313 |     }                                                                                                                                                    1313 |     }
     1314 |     return async_gen_athrow_new(o, args);                                                                                                                1314 |     return async_gen_athrow_new(o, args);
     1315 | }                                                                                                                                                        1315 | }
     1316 |                                                                                                                                                          1316 |
     1317 |                                                                                                                                                          1317 |
     1318 | static PyGetSetDef async_gen_getsetlist[] = {                                                                                                            1318 | static PyGetSetDef async_gen_getsetlist[] = {
"Objects/genobject.c", line 1318.43: 1506-446 (I) Array element(s) [0] will be initialized with a default value of 0.                                           "Objects/genobject.c", line 1318.43: 1506-446 (I) Array element(s) [0] will be initialized with a default value of 0.
"Objects/genobject.c", line 1318.43: 1506-446 (I) Array element(s) [1] will be initialized with a default value of 0.                                           "Objects/genobject.c", line 1318.43: 1506-446 (I) Array element(s) [1] will be initialized with a default value of 0.
"Objects/genobject.c", line 1318.43: 1506-446 (I) Array element(s) [2] will be initialized with a default value of 0.                                           "Objects/genobject.c", line 1318.43: 1506-446 (I) Array element(s) [2] will be initialized with a default value of 0.
"Objects/genobject.c", line 1318.43: 1506-446 (I) Array element(s) [3] will be initialized with a default value of 0.                                           "Objects/genobject.c", line 1318.43: 1506-446 (I) Array element(s) [3] will be initialized with a default value of 0.
     1319 |     {"__name__", (getter)gen_get_name, (setter)gen_set_name,                                                                                             1319 |     {"__name__", (getter)gen_get_name, (setter)gen_set_name,
     1320 |      PyDoc_STR("name of the async generator")},                                                                                                          1320 |      PyDoc_STR("name of the async generator")},
     1320 +      "name of the async generator"},                                                                                                                     1320 +      "name of the async generator"},
"Objects/genobject.c", line 1320.46: 1506-447 (I) The member(s) starting from "closure" will be initialized with a default value of 0.                          "Objects/genobject.c", line 1320.46: 1506-447 (I) The member(s) starting from "closure" will be initialized with a default value of 0.
     1321 |     {"__qualname__", (getter)gen_get_qualname, (setter)gen_set_qualname,                                                                                 1321 |     {"__qualname__", (getter)gen_get_qualname, (setter)gen_set_qualname,







Wed Apr 15 07:30:04 CDT 2020  Page 36


     1322 |      PyDoc_STR("qualified name of the async generator")},                                                                                                1322 |      PyDoc_STR("qualified name of the async generator")},
     1322 +      "qualified name of the async generator"},                                                                                                           1322 +      "qualified name of the async generator"},
"Objects/genobject.c", line 1322.56: 1506-447 (I) The member(s) starting from "closure" will be initialized with a default value of 0.                          "Objects/genobject.c", line 1322.56: 1506-447 (I) The member(s) starting from "closure" will be initialized with a default value of 0.
     1323 |     {"ag_await", (getter)coro_get_cr_await, NULL,                                                                                                        1323 |     {"ag_await", (getter)coro_get_cr_await, NULL,
     1323 +     {"ag_await", (getter)coro_get_cr_await, 0,                                                                                                           1323 +     {"ag_await", (getter)coro_get_cr_await, 0,
     1324 |      PyDoc_STR("object being awaited on, or None")},                                                                                                     1324 |      PyDoc_STR("object being awaited on, or None")},
     1324 +      "object being awaited on, or None"},                                                                                                                1324 +      "object being awaited on, or None"},
"Objects/genobject.c", line 1324.51: 1506-447 (I) The member(s) starting from "closure" will be initialized with a default value of 0.                          "Objects/genobject.c", line 1324.51: 1506-447 (I) The member(s) starting from "closure" will be initialized with a default value of 0.
     1325 |     {NULL} /* Sentinel */                                                                                                                                1325 |     {NULL} /* Sentinel */
     1325 +     {0} /* Sentinel */                                                                                                                                   1325 +     {0} /* Sentinel */
"Objects/genobject.c", line 1325.10: 1506-447 (I) The member(s) starting from "get" will be initialized with a default value of 0.                              "Objects/genobject.c", line 1325.10: 1506-447 (I) The member(s) starting from "get" will be initialized with a default value of 0.
     1326 | };                                                                                                                                                       1326 | };
     1327 |                                                                                                                                                          1327 |
     1328 | static PyMemberDef async_gen_memberlist[] = {                                                                                                            1328 | static PyMemberDef async_gen_memberlist[] = {
"Objects/genobject.c", line 1328.43: 1506-446 (I) Array element(s) [0] will be initialized with a default value of 0.                                           "Objects/genobject.c", line 1328.43: 1506-446 (I) Array element(s) [0] will be initialized with a default value of 0.
"Objects/genobject.c", line 1328.43: 1506-446 (I) Array element(s) [1] will be initialized with a default value of 0.                                           "Objects/genobject.c", line 1328.43: 1506-446 (I) Array element(s) [1] will be initialized with a default value of 0.
"Objects/genobject.c", line 1328.43: 1506-446 (I) Array element(s) [2] will be initialized with a default value of 0.                                           "Objects/genobject.c", line 1328.43: 1506-446 (I) Array element(s) [2] will be initialized with a default value of 0.
"Objects/genobject.c", line 1328.43: 1506-446 (I) Array element(s) [3] will be initialized with a default value of 0.                                           "Objects/genobject.c", line 1328.43: 1506-446 (I) Array element(s) [3] will be initialized with a default value of 0.
     1329 |     {"ag_frame",   T_OBJECT, offsetof(PyAsyncGenObject, ag_frame),   READONLY},                                                                          1329 |     {"ag_frame",   T_OBJECT, offsetof(PyAsyncGenObject, ag_frame),   READONLY},
     1329 +     {"ag_frame",   6, (size_t)&(((PyAsyncGenObject *)0)->ag_frame),   1},                                                                                1329 +     {"ag_frame",   6, (size_t)&(((PyAsyncGenObject *)0)->ag_frame),   1},
"Objects/genobject.c", line 1329.78: 1506-447 (I) The member(s) starting from "doc" will be initialized with a default value of 0.                              "Objects/genobject.c", line 1329.78: 1506-447 (I) The member(s) starting from "doc" will be initialized with a default value of 0.
     1330 |     {"ag_running", T_BOOL,   offsetof(PyAsyncGenObject, ag_running_async),                                                                               1330 |     {"ag_running", T_BOOL,   offsetof(PyAsyncGenObject, ag_running_async),
     1330 +     {"ag_running", 14,   (size_t)&(((PyAsyncGenObject *)0)->ag_running_async),                                                                           1330 +     {"ag_running", 14,   (size_t)&(((PyAsyncGenObject *)0)->ag_running_async),
     1331 |         READONLY},                                                                                                                                       1331 |         READONLY},
     1331 +         1},                                                                                                                                              1331 +         1},
"Objects/genobject.c", line 1331.17: 1506-447 (I) The member(s) starting from "doc" will be initialized with a default value of 0.                              "Objects/genobject.c", line 1331.17: 1506-447 (I) The member(s) starting from "doc" will be initialized with a default value of 0.
     1332 |     {"ag_code",    T_OBJECT, offsetof(PyAsyncGenObject, ag_code),    READONLY},                                                                          1332 |     {"ag_code",    T_OBJECT, offsetof(PyAsyncGenObject, ag_code),    READONLY},
     1332 +     {"ag_code",    6, (size_t)&(((PyAsyncGenObject *)0)->ag_code),    1},                                                                                1332 +     {"ag_code",    6, (size_t)&(((PyAsyncGenObject *)0)->ag_code),    1},
"Objects/genobject.c", line 1332.78: 1506-447 (I) The member(s) starting from "doc" will be initialized with a default value of 0.                              "Objects/genobject.c", line 1332.78: 1506-447 (I) The member(s) starting from "doc" will be initialized with a default value of 0.
     1333 |     {NULL}      /* Sentinel */                                                                                                                           1333 |     {NULL}      /* Sentinel */
     1333 +     {0}      /* Sentinel */                                                                                                                              1333 +     {0}      /* Sentinel */
"Objects/genobject.c", line 1333.10: 1506-447 (I) The member(s) starting from "type" will be initialized with a default value of 0.                             "Objects/genobject.c", line 1333.10: 1506-447 (I) The member(s) starting from "type" will be initialized with a default value of 0.
     1334 | };                                                                                                                                                       1334 | };
     1335 |                                                                                                                                                          1335 |
     1336 | PyDoc_STRVAR(async_aclose_doc,                                                                                                                           1336 | PyDoc_STRVAR(async_aclose_doc,
     1336 +                                                                                                                                                          1336 +
     1337 | "aclose() -> raise GeneratorExit inside generator.");                                                                                                    1337 | "aclose() -> raise GeneratorExit inside generator.");
     1337 + static const char async_aclose_doc[] = "aclose() -> raise GeneratorExit inside generator.";                                                              1337 + static const char async_aclose_doc[] = "aclose() -> raise GeneratorExit inside generator.";
     1338 |                                                                                                                                                          1338 |
     1339 | PyDoc_STRVAR(async_asend_doc,                                                                                                                            1339 | PyDoc_STRVAR(async_asend_doc,
     1339 +                                                                                                                                                          1339 +
     1340 | "asend(v) -> send 'v' in generator.");                                                                                                                   1340 | "asend(v) -> send 'v' in generator.");
     1340 + static const char async_asend_doc[] = "asend(v) -> send 'v' in generator.";                                                                              1340 + static const char async_asend_doc[] = "asend(v) -> send 'v' in generator.";
     1341 |                                                                                                                                                          1341 |
     1342 | PyDoc_STRVAR(async_athrow_doc,                                                                                                                           1342 | PyDoc_STRVAR(async_athrow_doc,
     1342 +                                                                                                                                                          1342 +
     1343 | "athrow(typ[,val[,tb]]) -> raise exception in generator.");                                                                                              1343 | "athrow(typ[,val[,tb]]) -> raise exception in generator.");
     1343 + static const char async_athrow_doc[] = "athrow(typ[,val[,tb]]) -> raise exception in generator.";                                                        1343 + static const char async_athrow_doc[] = "athrow(typ[,val[,tb]]) -> raise exception in generator.";
     1344 |                                                                                                                                                          1344 |
     1345 | static PyMethodDef async_gen_methods[] = {                                                                                                               1345 | static PyMethodDef async_gen_methods[] = {
"Objects/genobject.c", line 1345.40: 1506-446 (I) Array element(s) [4] will be initialized with a default value of 0.                                           "Objects/genobject.c", line 1345.40: 1506-446 (I) Array element(s) [4] will be initialized with a default value of 0.
     1346 |     {"asend", (PyCFunction)async_gen_asend, METH_O, async_asend_doc},                                                                                    1346 |     {"asend", (PyCFunction)async_gen_asend, METH_O, async_asend_doc},
     1346 +     {"asend", (PyCFunction)async_gen_asend, 0x0008, async_asend_doc},                                                                                    1346 +     {"asend", (PyCFunction)async_gen_asend, 0x0008, async_asend_doc},
     1347 |     {"athrow",(PyCFunction)async_gen_athrow, METH_VARARGS, async_athrow_doc},                                                                            1347 |     {"athrow",(PyCFunction)async_gen_athrow, METH_VARARGS, async_athrow_doc},
     1347 +     {"athrow",(PyCFunction)async_gen_athrow, 0x0001, async_athrow_doc},                                                                                  1347 +     {"athrow",(PyCFunction)async_gen_athrow, 0x0001, async_athrow_doc},
     1348 |     {"aclose", (PyCFunction)async_gen_aclose, METH_NOARGS, async_aclose_doc},                                                                            1348 |     {"aclose", (PyCFunction)async_gen_aclose, METH_NOARGS, async_aclose_doc},







Wed Apr 15 07:30:04 CDT 2020  Page 37


     1348 +     {"aclose", (PyCFunction)async_gen_aclose, 0x0004, async_aclose_doc},                                                                                 1348 +     {"aclose", (PyCFunction)async_gen_aclose, 0x0004, async_aclose_doc},
     1349 |     {"__class_getitem__",    (PyCFunction)Py_GenericAlias,                                                                                               1349 |     {"__class_getitem__",    (PyCFunction)Py_GenericAlias,
     1350 |     METH_O|METH_CLASS,       PyDoc_STR("See PEP 585")},                                                                                                  1350 |     METH_O|METH_CLASS,       PyDoc_STR("See PEP 585")},
     1350 +     0x0008|0x0010,       "See PEP 585"},                                                                                                                 1350 +     0x0008|0x0010,       "See PEP 585"},
     1351 |     {NULL, NULL}        /* Sentinel */                                                                                                                   1351 |     {NULL, NULL}        /* Sentinel */
     1351 +     {0, 0}        /* Sentinel */                                                                                                                         1351 +     {0, 0}        /* Sentinel */
"Objects/genobject.c", line 1351.16: 1506-447 (I) The member(s) starting from "ml_flags" will be initialized with a default value of 0.                         "Objects/genobject.c", line 1351.16: 1506-447 (I) The member(s) starting from "ml_flags" will be initialized with a default value of 0.
     1352 | };                                                                                                                                                       1352 | };
     1353 |                                                                                                                                                          1353 |
     1354 |                                                                                                                                                          1354 |
     1355 | static PyAsyncMethods async_gen_as_async = {                                                                                                             1355 | static PyAsyncMethods async_gen_as_async = {
     1356 |     0,                                          /* am_await */                                                                                           1356 |     0,                                          /* am_await */
     1357 |     PyObject_SelfIter,                          /* am_aiter */                                                                                           1357 |     PyObject_SelfIter,                          /* am_aiter */
     1358 |     (unaryfunc)async_gen_anext                  /* am_anext */                                                                                           1358 |     (unaryfunc)async_gen_anext                  /* am_anext */
     1359 | };                                                                                                                                                       1359 | };
     1360 |                                                                                                                                                          1360 |
     1361 |                                                                                                                                                          1361 |
     1362 | PyTypeObject PyAsyncGen_Type = {                                                                                                                         1362 | PyTypeObject PyAsyncGen_Type = {
     1363 |     PyVarObject_HEAD_INIT(&PyType_Type, 0)                                                                                                               1363 |     PyVarObject_HEAD_INIT(&PyType_Type, 0)
     1363 +     { {   1, &PyType_Type }, 0 },                                                                                                                        1363 +     { {   1, &PyType_Type }, 0 },
     1364 |     "async_generator",                          /* tp_name */                                                                                            1364 |     "async_generator",                          /* tp_name */
     1365 |     sizeof(PyAsyncGenObject),                   /* tp_basicsize */                                                                                       1365 |     sizeof(PyAsyncGenObject),                   /* tp_basicsize */
     1366 |     0,                                          /* tp_itemsize */                                                                                        1366 |     0,                                          /* tp_itemsize */
     1367 |     /* methods */                                                                                                                                        1367 |     /* methods */
     1368 |     (destructor)gen_dealloc,                    /* tp_dealloc */                                                                                         1368 |     (destructor)gen_dealloc,                    /* tp_dealloc */
     1369 |     0,                                          /* tp_vectorcall_offset */                                                                               1369 |     0,                                          /* tp_vectorcall_offset */
     1370 |     0,                                          /* tp_getattr */                                                                                         1370 |     0,                                          /* tp_getattr */
     1371 |     0,                                          /* tp_setattr */                                                                                         1371 |     0,                                          /* tp_setattr */
     1372 |     &async_gen_as_async,                        /* tp_as_async */                                                                                        1372 |     &async_gen_as_async,                        /* tp_as_async */
     1373 |     (reprfunc)async_gen_repr,                   /* tp_repr */                                                                                            1373 |     (reprfunc)async_gen_repr,                   /* tp_repr */
     1374 |     0,                                          /* tp_as_number */                                                                                       1374 |     0,                                          /* tp_as_number */
     1375 |     0,                                          /* tp_as_sequence */                                                                                     1375 |     0,                                          /* tp_as_sequence */
     1376 |     0,                                          /* tp_as_mapping */                                                                                      1376 |     0,                                          /* tp_as_mapping */
     1377 |     0,                                          /* tp_hash */                                                                                            1377 |     0,                                          /* tp_hash */
     1378 |     0,                                          /* tp_call */                                                                                            1378 |     0,                                          /* tp_call */
     1379 |     0,                                          /* tp_str */                                                                                             1379 |     0,                                          /* tp_str */
     1380 |     PyObject_GenericGetAttr,                    /* tp_getattro */                                                                                        1380 |     PyObject_GenericGetAttr,                    /* tp_getattro */
     1381 |     0,                                          /* tp_setattro */                                                                                        1381 |     0,                                          /* tp_setattro */
     1382 |     0,                                          /* tp_as_buffer */                                                                                       1382 |     0,                                          /* tp_as_buffer */
     1383 |     Py_TPFLAGS_DEFAULT | Py_TPFLAGS_HAVE_GC,    /* tp_flags */                                                                                           1383 |     Py_TPFLAGS_DEFAULT | Py_TPFLAGS_HAVE_GC,    /* tp_flags */
     1383 +     ( 0 | (1UL << 18) | 0) | (1UL << 14),    /* tp_flags */                                                                                              1383 +     ( 0 | (1UL << 18) | 0) | (1UL << 14),    /* tp_flags */
     1384 |     0,                                          /* tp_doc */                                                                                             1384 |     0,                                          /* tp_doc */
     1385 |     (traverseproc)async_gen_traverse,           /* tp_traverse */                                                                                        1385 |     (traverseproc)async_gen_traverse,           /* tp_traverse */
     1386 |     0,                                          /* tp_clear */                                                                                           1386 |     0,                                          /* tp_clear */
     1387 |     0,                                          /* tp_richcompare */                                                                                     1387 |     0,                                          /* tp_richcompare */
     1388 |     offsetof(PyAsyncGenObject, ag_weakreflist), /* tp_weaklistoffset */                                                                                  1388 |     offsetof(PyAsyncGenObject, ag_weakreflist), /* tp_weaklistoffset */
     1388 +     (size_t)&(((PyAsyncGenObject *)0)->ag_weakreflist), /* tp_weaklistoffset */                                                                          1388 +     (size_t)&(((PyAsyncGenObject *)0)->ag_weakreflist), /* tp_weaklistoffset */
     1389 |     0,                                          /* tp_iter */                                                                                            1389 |     0,                                          /* tp_iter */
     1390 |     0,                                          /* tp_iternext */                                                                                        1390 |     0,                                          /* tp_iternext */
     1391 |     async_gen_methods,                          /* tp_methods */                                                                                         1391 |     async_gen_methods,                          /* tp_methods */
     1392 |     async_gen_memberlist,                       /* tp_members */                                                                                         1392 |     async_gen_memberlist,                       /* tp_members */
     1393 |     async_gen_getsetlist,                       /* tp_getset */                                                                                          1393 |     async_gen_getsetlist,                       /* tp_getset */
     1394 |     0,                                          /* tp_base */                                                                                            1394 |     0,                                          /* tp_base */
     1395 |     0,                                          /* tp_dict */                                                                                            1395 |     0,                                          /* tp_dict */
     1396 |     0,                                          /* tp_descr_get */                                                                                       1396 |     0,                                          /* tp_descr_get */
     1397 |     0,                                          /* tp_descr_set */                                                                                       1397 |     0,                                          /* tp_descr_set */







Wed Apr 15 07:30:04 CDT 2020  Page 38


     1398 |     0,                                          /* tp_dictoffset */                                                                                      1398 |     0,                                          /* tp_dictoffset */
     1399 |     0,                                          /* tp_init */                                                                                            1399 |     0,                                          /* tp_init */
     1400 |     0,                                          /* tp_alloc */                                                                                           1400 |     0,                                          /* tp_alloc */
     1401 |     0,                                          /* tp_new */                                                                                             1401 |     0,                                          /* tp_new */
     1402 |     0,                                          /* tp_free */                                                                                            1402 |     0,                                          /* tp_free */
     1403 |     0,                                          /* tp_is_gc */                                                                                           1403 |     0,                                          /* tp_is_gc */
     1404 |     0,                                          /* tp_bases */                                                                                           1404 |     0,                                          /* tp_bases */
     1405 |     0,                                          /* tp_mro */                                                                                             1405 |     0,                                          /* tp_mro */
     1406 |     0,                                          /* tp_cache */                                                                                           1406 |     0,                                          /* tp_cache */
     1407 |     0,                                          /* tp_subclasses */                                                                                      1407 |     0,                                          /* tp_subclasses */
     1408 |     0,                                          /* tp_weaklist */                                                                                        1408 |     0,                                          /* tp_weaklist */
     1409 |     0,                                          /* tp_del */                                                                                             1409 |     0,                                          /* tp_del */
     1410 |     0,                                          /* tp_version_tag */                                                                                     1410 |     0,                                          /* tp_version_tag */
     1411 |     _PyGen_Finalize,                            /* tp_finalize */                                                                                        1411 |     _PyGen_Finalize,                            /* tp_finalize */
     1412 | };                                                                                                                                                       1412 | };
"Objects/genobject.c", line 1412.1: 1506-447 (I) The member(s) starting from "tp_vectorcall" will be initialized with a default value of 0.                     "Objects/genobject.c", line 1412.1: 1506-447 (I) The member(s) starting from "tp_vectorcall" will be initialized with a default value of 0.
     1413 |                                                                                                                                                          1413 |
     1414 |                                                                                                                                                          1414 |
     1415 | PyObject *                                                                                                                                               1415 | PyObject *
     1416 | PyAsyncGen_New(PyFrameObject *f, PyObject *name, PyObject *qualname)                                                                                     1416 | PyAsyncGen_New(PyFrameObject *f, PyObject *name, PyObject *qualname)
     1417 | {                                                                                                                                                        1417 | {
     1418 |     PyAsyncGenObject *o;                                                                                                                                 1418 |     PyAsyncGenObject *o;
     1419 |     o = (PyAsyncGenObject *)gen_new_with_qualname(                                                                                                       1419 |     o = (PyAsyncGenObject *)gen_new_with_qualname(
"Objects/genobject.c", line 1419.9: 1506-495 (I) Pointer type conversion found.                                                                                 "Objects/genobject.c", line 1419.9: 1506-495 (I) Pointer type conversion found.
"Objects/genobject.c", line 1419.9: 1506-374 (I) Pointer types "struct {...}*" and "struct _object*" are not compatible.                                        "Objects/genobject.c", line 1419.9: 1506-374 (I) Pointer types "struct {...}*" and "struct _object*" are not compatible.
     1420 |         &PyAsyncGen_Type, f, name, qualname);                                                                                                            1420 |         &PyAsyncGen_Type, f, name, qualname);
     1421 |     if (o == NULL) {                                                                                                                                     1421 |     if (o == NULL) {
     1421 +     if (o == 0) {                                                                                                                                        1421 +     if (o == 0) {
     1422 |         return NULL;                                                                                                                                     1422 |         return NULL;
     1422 +         return 0;                                                                                                                                        1422 +         return 0;
     1423 |     }                                                                                                                                                    1423 |     }
     1424 |     o->ag_finalizer = NULL;                                                                                                                              1424 |     o->ag_finalizer = NULL;
     1424 +     o->ag_finalizer = 0;                                                                                                                                 1424 +     o->ag_finalizer = 0;
     1425 |     o->ag_closed = 0;                                                                                                                                    1425 |     o->ag_closed = 0;
     1426 |     o->ag_hooks_inited = 0;                                                                                                                              1426 |     o->ag_hooks_inited = 0;
     1427 |     o->ag_running_async = 0;                                                                                                                             1427 |     o->ag_running_async = 0;
     1428 |     return (PyObject*)o;                                                                                                                                 1428 |     return (PyObject*)o;
"Objects/genobject.c", line 1428.12: 1506-495 (I) Pointer type conversion found.                                                                                "Objects/genobject.c", line 1428.12: 1506-495 (I) Pointer type conversion found.
"Objects/genobject.c", line 1428.12: 1506-374 (I) Pointer types "struct _object*" and "struct {...}*" are not compatible.                                       "Objects/genobject.c", line 1428.12: 1506-374 (I) Pointer types "struct _object*" and "struct {...}*" are not compatible.
     1429 | }                                                                                                                                                        1429 | }
"Objects/genobject.c", line 1429.1: 1506-412 (I) Referenced variable "o", which was not initialized in its declaration.                                         "Objects/genobject.c", line 1429.1: 1506-412 (I) Referenced variable "o", which was not initialized in its declaration.
     1430 |                                                                                                                                                          1430 |
     1431 |                                                                                                                                                          1431 |
     1432 | int                                                                                                                                                      1432 | int
     1433 | PyAsyncGen_ClearFreeLists(void)                                                                                                                          1433 | PyAsyncGen_ClearFreeLists(void)
     1434 | {                                                                                                                                                        1434 | {
     1435 |     int ret = ag_value_freelist_free + ag_asend_freelist_free;                                                                                           1435 |     int ret = ag_value_freelist_free + ag_asend_freelist_free;
     1436 |                                                                                                                                                          1436 |
     1437 |     while (ag_value_freelist_free) {                                                                                                                     1437 |     while (ag_value_freelist_free) {
     1438 |         _PyAsyncGenWrappedValue *o;                                                                                                                      1438 |         _PyAsyncGenWrappedValue *o;
     1439 |         o = ag_value_freelist[--ag_value_freelist_free];                                                                                                 1439 |         o = ag_value_freelist[--ag_value_freelist_free];
     1440 |         assert(_PyAsyncGenWrappedValue_CheckExact(o));                                                                                                   1440 |         assert(_PyAsyncGenWrappedValue_CheckExact(o));
     1440 +         ((_Py_IS_TYPE(((const PyObject*)(o)), &_PyAsyncGenWrappedValue_Type)) ? ((void)0) : __assert("_PyAsyncGenWrappedValue_CheckExact(o)", "Obje      1440 +         ((_Py_IS_TYPE(((const PyObject*)(o)), &_PyAsyncGenWrappedValue_Type)) ? ((void)0) : __assert("_PyAsyncGenWrappedValue_CheckExact(o)", "Obje
"Objects/genobject.c", line 1440.16: 1506-495 (I) Pointer type conversion found.                                                                                "Objects/genobject.c", line 1440.16: 1506-495 (I) Pointer type conversion found.
"Objects/genobject.c", line 1440.16: 1506-374 (I) Pointer types "const struct _object*" and "struct {...}*" are not compatible.                                 "Objects/genobject.c", line 1440.16: 1506-374 (I) Pointer types "const struct _object*" and "struct {...}*" are not compatible.
     1441 |         PyObject_GC_Del(o);                                                                                                                              1441 |         PyObject_GC_Del(o);







Wed Apr 15 07:30:04 CDT 2020  Page 39


     1442 |     }                                                                                                                                                    1442 |     }
"Objects/genobject.c", line 1442.5: 1506-412 (I) Referenced variable "o", which was not initialized in its declaration.                                         "Objects/genobject.c", line 1442.5: 1506-412 (I) Referenced variable "o", which was not initialized in its declaration.
     1443 |                                                                                                                                                          1443 |
     1444 |     while (ag_asend_freelist_free) {                                                                                                                     1444 |     while (ag_asend_freelist_free) {
     1445 |         PyAsyncGenASend *o;                                                                                                                              1445 |         PyAsyncGenASend *o;
     1446 |         o = ag_asend_freelist[--ag_asend_freelist_free];                                                                                                 1446 |         o = ag_asend_freelist[--ag_asend_freelist_free];
     1447 |         assert(Py_IS_TYPE(o, &_PyAsyncGenASend_Type));                                                                                                   1447 |         assert(Py_IS_TYPE(o, &_PyAsyncGenASend_Type));
     1447 +         ((_Py_IS_TYPE(((const PyObject*)(o)), &_PyAsyncGenASend_Type)) ? ((void)0) : __assert("Py_IS_TYPE(o, &_PyAsyncGenASend_Type)", "Objects/gen      1447 +         ((_Py_IS_TYPE(((const PyObject*)(o)), &_PyAsyncGenASend_Type)) ? ((void)0) : __assert("Py_IS_TYPE(o, &_PyAsyncGenASend_Type)", "Objects/gen
"Objects/genobject.c", line 1447.16: 1506-495 (I) Pointer type conversion found.                                                                                "Objects/genobject.c", line 1447.16: 1506-495 (I) Pointer type conversion found.
"Objects/genobject.c", line 1447.16: 1506-374 (I) Pointer types "const struct _object*" and "struct {...}*" are not compatible.                                 "Objects/genobject.c", line 1447.16: 1506-374 (I) Pointer types "const struct _object*" and "struct {...}*" are not compatible.
     1448 |         PyObject_GC_Del(o);                                                                                                                              1448 |         PyObject_GC_Del(o);
     1449 |     }                                                                                                                                                    1449 |     }
"Objects/genobject.c", line 1449.5: 1506-412 (I) Referenced variable "o", which was not initialized in its declaration.                                         "Objects/genobject.c", line 1449.5: 1506-412 (I) Referenced variable "o", which was not initialized in its declaration.
     1450 |                                                                                                                                                          1450 |
     1451 |     return ret;                                                                                                                                          1451 |     return ret;
     1452 | }                                                                                                                                                        1452 | }
     1453 |                                                                                                                                                          1453 |
     1454 | void                                                                                                                                                     1454 | void
     1455 | _PyAsyncGen_Fini(void)                                                                                                                                   1455 | _PyAsyncGen_Fini(void)
     1456 | {                                                                                                                                                        1456 | {
     1457 |     PyAsyncGen_ClearFreeLists();                                                                                                                         1457 |     PyAsyncGen_ClearFreeLists();
     1458 | }                                                                                                                                                        1458 | }
     1459 |                                                                                                                                                          1459 |
     1460 |                                                                                                                                                          1460 |
     1461 | static PyObject *                                                                                                                                        1461 | static PyObject *
     1462 | async_gen_unwrap_value(PyAsyncGenObject *gen, PyObject *result)                                                                                          1462 | async_gen_unwrap_value(PyAsyncGenObject *gen, PyObject *result)
     1463 | {                                                                                                                                                        1463 | {
     1464 |     if (result == NULL) {                                                                                                                                1464 |     if (result == NULL) {
     1464 +     if (result == 0) {                                                                                                                                   1464 +     if (result == 0) {
     1465 |         if (!PyErr_Occurred()) {                                                                                                                         1465 |         if (!PyErr_Occurred()) {
     1466 |             PyErr_SetNone(PyExc_StopAsyncIteration);                                                                                                     1466 |             PyErr_SetNone(PyExc_StopAsyncIteration);
     1467 |         }                                                                                                                                                1467 |         }
     1468 |                                                                                                                                                          1468 |
     1469 |         if (PyErr_ExceptionMatches(PyExc_StopAsyncIteration)                                                                                             1469 |         if (PyErr_ExceptionMatches(PyExc_StopAsyncIteration)
     1470 |             || PyErr_ExceptionMatches(PyExc_GeneratorExit)                                                                                               1470 |             || PyErr_ExceptionMatches(PyExc_GeneratorExit)
     1471 |         ) {                                                                                                                                              1471 |         ) {
     1472 |             gen->ag_closed = 1;                                                                                                                          1472 |             gen->ag_closed = 1;
     1473 |         }                                                                                                                                                1473 |         }
     1474 |                                                                                                                                                          1474 |
     1475 |         gen->ag_running_async = 0;                                                                                                                       1475 |         gen->ag_running_async = 0;
     1476 |         return NULL;                                                                                                                                     1476 |         return NULL;
     1476 +         return 0;                                                                                                                                        1476 +         return 0;
     1477 |     }                                                                                                                                                    1477 |     }
     1478 |                                                                                                                                                          1478 |
     1479 |     if (_PyAsyncGenWrappedValue_CheckExact(result)) {                                                                                                    1479 |     if (_PyAsyncGenWrappedValue_CheckExact(result)) {
     1479 +     if (_Py_IS_TYPE(((const PyObject*)(result)), &_PyAsyncGenWrappedValue_Type)) {                                                                       1479 +     if (_Py_IS_TYPE(((const PyObject*)(result)), &_PyAsyncGenWrappedValue_Type)) {
"Objects/genobject.c", line 1479.9: 1506-495 (I) Pointer type conversion found.                                                                                 "Objects/genobject.c", line 1479.9: 1506-495 (I) Pointer type conversion found.
"Objects/genobject.c", line 1479.9: 1506-374 (I) Pointer types "const struct _object*" and "struct _object*" are not compatible.                                "Objects/genobject.c", line 1479.9: 1506-374 (I) Pointer types "const struct _object*" and "struct _object*" are not compatible.
     1480 |         /* async yield */                                                                                                                                1480 |         /* async yield */
     1481 |         _PyGen_SetStopIterationValue(((_PyAsyncGenWrappedValue*)result)->agw_val);                                                                       1481 |         _PyGen_SetStopIterationValue(((_PyAsyncGenWrappedValue*)result)->agw_val);
"Objects/genobject.c", line 1481.38: 1506-495 (I) Pointer type conversion found.                                                                                "Objects/genobject.c", line 1481.38: 1506-495 (I) Pointer type conversion found.
"Objects/genobject.c", line 1481.38: 1506-374 (I) Pointer types "struct {...}*" and "struct _object*" are not compatible.                                       "Objects/genobject.c", line 1481.38: 1506-374 (I) Pointer types "struct {...}*" and "struct _object*" are not compatible.
     1482 |         Py_DECREF(result);                                                                                                                               1482 |         Py_DECREF(result);
     1482 +         _Py_DECREF("Objects/genobject.c", 1482, ((PyObject*)(result)));                                                                                  1482 +         _Py_DECREF("Objects/genobject.c", 1482, ((PyObject*)(result)));
     1483 |         gen->ag_running_async = 0;                                                                                                                       1483 |         gen->ag_running_async = 0;
     1484 |         return NULL;                                                                                                                                     1484 |         return NULL;







Wed Apr 15 07:30:04 CDT 2020  Page 40


     1484 +         return 0;                                                                                                                                        1484 +         return 0;
     1485 |     }                                                                                                                                                    1485 |     }
     1486 |                                                                                                                                                          1486 |
     1487 |     return result;                                                                                                                                       1487 |     return result;
     1488 | }                                                                                                                                                        1488 | }
     1489 |                                                                                                                                                          1489 |
     1490 |                                                                                                                                                          1490 |
     1491 | /* ---------- Async Generator ASend Awaitable ------------ */                                                                                            1491 | /* ---------- Async Generator ASend Awaitable ------------ */
     1492 |                                                                                                                                                          1492 |
     1493 |                                                                                                                                                          1493 |
     1494 | static void                                                                                                                                              1494 | static void
     1495 | async_gen_asend_dealloc(PyAsyncGenASend *o)                                                                                                              1495 | async_gen_asend_dealloc(PyAsyncGenASend *o)
     1496 | {                                                                                                                                                        1496 | {
     1497 |     _PyObject_GC_UNTRACK((PyObject *)o);                                                                                                                 1497 |     _PyObject_GC_UNTRACK((PyObject *)o);
     1497 +     _PyObject_GC_UNTRACK_impl("Objects/genobject.c", 1497, ((PyObject*)((PyObject *)o)));                                                                1497 +     _PyObject_GC_UNTRACK_impl("Objects/genobject.c", 1497, ((PyObject*)((PyObject *)o)));
"Objects/genobject.c", line 1497.5: 1506-495 (I) Pointer type conversion found.                                                                                 "Objects/genobject.c", line 1497.5: 1506-495 (I) Pointer type conversion found.
"Objects/genobject.c", line 1497.5: 1506-374 (I) Pointer types "struct _object*" and "struct {...}*" are not compatible.                                        "Objects/genobject.c", line 1497.5: 1506-374 (I) Pointer types "struct _object*" and "struct {...}*" are not compatible.
     1498 |     Py_CLEAR(o->ags_gen);                                                                                                                                1498 |     Py_CLEAR(o->ags_gen);
     1498 +     do { PyObject *_py_tmp = ((PyObject*)(o->ags_gen)); if (_py_tmp != 0) { (o->ags_gen) = 0; _Py_DECREF("Objects/genobject.c", 1498, ((PyObject*)(      1498 +     do { PyObject *_py_tmp = ((PyObject*)(o->ags_gen)); if (_py_tmp != 0) { (o->ags_gen) = 0; _Py_DECREF("Objects/genobject.c", 1498, ((PyObject*)(
"Objects/genobject.c", line 1498.5: 1506-495 (I) Pointer type conversion found.                                                                                 "Objects/genobject.c", line 1498.5: 1506-495 (I) Pointer type conversion found.
"Objects/genobject.c", line 1498.5: 1506-374 (I) Pointer types "struct _object*" and "struct {...}*" are not compatible.                                        "Objects/genobject.c", line 1498.5: 1506-374 (I) Pointer types "struct _object*" and "struct {...}*" are not compatible.
"Objects/genobject.c", line 1498.5: 1506-425 (I) The condition is always false.                                                                                 "Objects/genobject.c", line 1498.5: 1506-425 (I) The condition is always false.
     1499 |     Py_CLEAR(o->ags_sendval);                                                                                                                            1499 |     Py_CLEAR(o->ags_sendval);
     1499 +     do { PyObject *_py_tmp = ((PyObject*)(o->ags_sendval)); if (_py_tmp != 0) { (o->ags_sendval) = 0; _Py_DECREF("Objects/genobject.c", 1499, ((PyO      1499 +     do { PyObject *_py_tmp = ((PyObject*)(o->ags_sendval)); if (_py_tmp != 0) { (o->ags_sendval) = 0; _Py_DECREF("Objects/genobject.c", 1499, ((PyO
"Objects/genobject.c", line 1499.5: 1506-425 (I) The condition is always false.                                                                                 "Objects/genobject.c", line 1499.5: 1506-425 (I) The condition is always false.
     1500 |     if (ag_asend_freelist_free < _PyAsyncGen_MAXFREELIST) {                                                                                              1500 |     if (ag_asend_freelist_free < _PyAsyncGen_MAXFREELIST) {
     1500 +     if (ag_asend_freelist_free < 80) {                                                                                                                   1500 +     if (ag_asend_freelist_free < 80) {
     1501 |         assert(PyAsyncGenASend_CheckExact(o));                                                                                                           1501 |         assert(PyAsyncGenASend_CheckExact(o));
     1501 +         ((_Py_IS_TYPE(((const PyObject*)(o)), &_PyAsyncGenASend_Type)) ? ((void)0) : __assert("PyAsyncGenASend_CheckExact(o)", "Objects/genobject.c      1501 +         ((_Py_IS_TYPE(((const PyObject*)(o)), &_PyAsyncGenASend_Type)) ? ((void)0) : __assert("PyAsyncGenASend_CheckExact(o)", "Objects/genobject.c
"Objects/genobject.c", line 1501.16: 1506-495 (I) Pointer type conversion found.                                                                                "Objects/genobject.c", line 1501.16: 1506-495 (I) Pointer type conversion found.
"Objects/genobject.c", line 1501.16: 1506-374 (I) Pointer types "const struct _object*" and "struct {...}*" are not compatible.                                 "Objects/genobject.c", line 1501.16: 1506-374 (I) Pointer types "const struct _object*" and "struct {...}*" are not compatible.
     1502 |         ag_asend_freelist[ag_asend_freelist_free++] = o;                                                                                                 1502 |         ag_asend_freelist[ag_asend_freelist_free++] = o;
     1503 |     } else {                                                                                                                                             1503 |     } else {
     1504 |         PyObject_GC_Del(o);                                                                                                                              1504 |         PyObject_GC_Del(o);
     1505 |     }                                                                                                                                                    1505 |     }
     1506 | }                                                                                                                                                        1506 | }
     1507 |                                                                                                                                                          1507 |
     1508 | static int                                                                                                                                               1508 | static int
     1509 | async_gen_asend_traverse(PyAsyncGenASend *o, visitproc visit, void *arg)                                                                                 1509 | async_gen_asend_traverse(PyAsyncGenASend *o, visitproc visit, void *arg)
     1510 | {                                                                                                                                                        1510 | {
     1511 |     Py_VISIT(o->ags_gen);                                                                                                                                1511 |     Py_VISIT(o->ags_gen);
     1511 +     do { if (o->ags_gen) { int vret = visit(((PyObject*)(o->ags_gen)), arg); if (vret) return vret; } } while (0);                                       1511 +     do { if (o->ags_gen) { int vret = visit(((PyObject*)(o->ags_gen)), arg); if (vret) return vret; } } while (0);
"Objects/genobject.c", line 1511.5: 1506-495 (I) Pointer type conversion found.                                                                                 "Objects/genobject.c", line 1511.5: 1506-495 (I) Pointer type conversion found.
"Objects/genobject.c", line 1511.5: 1506-374 (I) Pointer types "struct _object*" and "struct {...}*" are not compatible.                                        "Objects/genobject.c", line 1511.5: 1506-374 (I) Pointer types "struct _object*" and "struct {...}*" are not compatible.
"Objects/genobject.c", line 1511.5: 1506-425 (I) The condition is always false.                                                                                 "Objects/genobject.c", line 1511.5: 1506-425 (I) The condition is always false.
     1512 |     Py_VISIT(o->ags_sendval);                                                                                                                            1512 |     Py_VISIT(o->ags_sendval);
     1512 +     do { if (o->ags_sendval) { int vret = visit(((PyObject*)(o->ags_sendval)), arg); if (vret) return vret; } } while (0);                               1512 +     do { if (o->ags_sendval) { int vret = visit(((PyObject*)(o->ags_sendval)), arg); if (vret) return vret; } } while (0);
"Objects/genobject.c", line 1512.5: 1506-425 (I) The condition is always false.                                                                                 "Objects/genobject.c", line 1512.5: 1506-425 (I) The condition is always false.
     1513 |     return 0;                                                                                                                                            1513 |     return 0;
     1514 | }                                                                                                                                                        1514 | }
     1515 |                                                                                                                                                          1515 |
     1516 |                                                                                                                                                          1516 |
     1517 | static PyObject *                                                                                                                                        1517 | static PyObject *
     1518 | async_gen_asend_send(PyAsyncGenASend *o, PyObject *arg)                                                                                                  1518 | async_gen_asend_send(PyAsyncGenASend *o, PyObject *arg)
     1519 | {                                                                                                                                                        1519 | {
     1520 |     PyObject *result;                                                                                                                                    1520 |     PyObject *result;







Wed Apr 15 07:30:04 CDT 2020  Page 41


     1521 |                                                                                                                                                          1521 |
     1522 |     if (o->ags_state == AWAITABLE_STATE_CLOSED) {                                                                                                        1522 |     if (o->ags_state == AWAITABLE_STATE_CLOSED) {
     1523 |         PyErr_SetString(                                                                                                                                 1523 |         PyErr_SetString(
     1524 |             PyExc_RuntimeError,                                                                                                                          1524 |             PyExc_RuntimeError,
     1525 |             "cannot reuse already awaited __anext__()/asend()");                                                                                         1525 |             "cannot reuse already awaited __anext__()/asend()");
     1526 |         return NULL;                                                                                                                                     1526 |         return NULL;
     1526 +         return 0;                                                                                                                                        1526 +         return 0;
     1527 |     }                                                                                                                                                    1527 |     }
     1528 |                                                                                                                                                          1528 |
     1529 |     if (o->ags_state == AWAITABLE_STATE_INIT) {                                                                                                          1529 |     if (o->ags_state == AWAITABLE_STATE_INIT) {
     1530 |         if (o->ags_gen->ag_running_async) {                                                                                                              1530 |         if (o->ags_gen->ag_running_async) {
     1531 |             PyErr_SetString(                                                                                                                             1531 |             PyErr_SetString(
     1532 |                 PyExc_RuntimeError,                                                                                                                      1532 |                 PyExc_RuntimeError,
     1533 |                 "anext(): asynchronous generator is already running");                                                                                   1533 |                 "anext(): asynchronous generator is already running");
     1534 |             return NULL;                                                                                                                                 1534 |             return NULL;
     1534 +             return 0;                                                                                                                                    1534 +             return 0;
     1535 |         }                                                                                                                                                1535 |         }
     1536 |                                                                                                                                                          1536 |
     1537 |         if (arg == NULL || arg == Py_None) {                                                                                                             1537 |         if (arg == NULL || arg == Py_None) {
     1537 +         if (arg == 0 || arg == (&_Py_NoneStruct)) {                                                                                                      1537 +         if (arg == 0 || arg == (&_Py_NoneStruct)) {
     1538 |             arg = o->ags_sendval;                                                                                                                        1538 |             arg = o->ags_sendval;
     1539 |         }                                                                                                                                                1539 |         }
     1540 |         o->ags_state = AWAITABLE_STATE_ITER;                                                                                                             1540 |         o->ags_state = AWAITABLE_STATE_ITER;
     1541 |     }                                                                                                                                                    1541 |     }
     1542 |                                                                                                                                                          1542 |
     1543 |     o->ags_gen->ag_running_async = 1;                                                                                                                    1543 |     o->ags_gen->ag_running_async = 1;
     1544 |     result = gen_send_ex((PyGenObject*)o->ags_gen, arg, 0, 0);                                                                                           1544 |     result = gen_send_ex((PyGenObject*)o->ags_gen, arg, 0, 0);
"Objects/genobject.c", line 1544.26: 1506-495 (I) Pointer type conversion found.                                                                                "Objects/genobject.c", line 1544.26: 1506-495 (I) Pointer type conversion found.
"Objects/genobject.c", line 1544.26: 1506-374 (I) Pointer types "struct {...}*" and "struct {...}*" are not compatible.                                         "Objects/genobject.c", line 1544.26: 1506-374 (I) Pointer types "struct {...}*" and "struct {...}*" are not compatible.
     1545 |     result = async_gen_unwrap_value(o->ags_gen, result);                                                                                                 1545 |     result = async_gen_unwrap_value(o->ags_gen, result);
     1546 |                                                                                                                                                          1546 |
     1547 |     if (result == NULL) {                                                                                                                                1547 |     if (result == NULL) {
     1547 +     if (result == 0) {                                                                                                                                   1547 +     if (result == 0) {
     1548 |         o->ags_state = AWAITABLE_STATE_CLOSED;                                                                                                           1548 |         o->ags_state = AWAITABLE_STATE_CLOSED;
     1549 |     }                                                                                                                                                    1549 |     }
     1550 |                                                                                                                                                          1550 |
     1551 |     return result;                                                                                                                                       1551 |     return result;
     1552 | }                                                                                                                                                        1552 | }
"Objects/genobject.c", line 1552.1: 1506-412 (I) Referenced variable "result", which was not initialized in its declaration.                                    "Objects/genobject.c", line 1552.1: 1506-412 (I) Referenced variable "result", which was not initialized in its declaration.
     1553 |                                                                                                                                                          1553 |
     1554 |                                                                                                                                                          1554 |
     1555 | static PyObject *                                                                                                                                        1555 | static PyObject *
     1556 | async_gen_asend_iternext(PyAsyncGenASend *o)                                                                                                             1556 | async_gen_asend_iternext(PyAsyncGenASend *o)
     1557 | {                                                                                                                                                        1557 | {
     1558 |     return async_gen_asend_send(o, NULL);                                                                                                                1558 |     return async_gen_asend_send(o, NULL);
     1558 +     return async_gen_asend_send(o, 0);                                                                                                                   1558 +     return async_gen_asend_send(o, 0);
     1559 | }                                                                                                                                                        1559 | }
     1560 |                                                                                                                                                          1560 |
     1561 |                                                                                                                                                          1561 |
     1562 | static PyObject *                                                                                                                                        1562 | static PyObject *
     1563 | async_gen_asend_throw(PyAsyncGenASend *o, PyObject *args)                                                                                                1563 | async_gen_asend_throw(PyAsyncGenASend *o, PyObject *args)
     1564 | {                                                                                                                                                        1564 | {
     1565 |     PyObject *result;                                                                                                                                    1565 |     PyObject *result;
     1566 |                                                                                                                                                          1566 |
     1567 |     if (o->ags_state == AWAITABLE_STATE_CLOSED) {                                                                                                        1567 |     if (o->ags_state == AWAITABLE_STATE_CLOSED) {
     1568 |         PyErr_SetString(                                                                                                                                 1568 |         PyErr_SetString(







Wed Apr 15 07:30:04 CDT 2020  Page 42


     1569 |             PyExc_RuntimeError,                                                                                                                          1569 |             PyExc_RuntimeError,
     1570 |             "cannot reuse already awaited __anext__()/asend()");                                                                                         1570 |             "cannot reuse already awaited __anext__()/asend()");
     1571 |         return NULL;                                                                                                                                     1571 |         return NULL;
     1571 +         return 0;                                                                                                                                        1571 +         return 0;
     1572 |     }                                                                                                                                                    1572 |     }
     1573 |                                                                                                                                                          1573 |
     1574 |     result = gen_throw((PyGenObject*)o->ags_gen, args);                                                                                                  1574 |     result = gen_throw((PyGenObject*)o->ags_gen, args);
"Objects/genobject.c", line 1574.24: 1506-495 (I) Pointer type conversion found.                                                                                "Objects/genobject.c", line 1574.24: 1506-495 (I) Pointer type conversion found.
"Objects/genobject.c", line 1574.24: 1506-374 (I) Pointer types "struct {...}*" and "struct {...}*" are not compatible.                                         "Objects/genobject.c", line 1574.24: 1506-374 (I) Pointer types "struct {...}*" and "struct {...}*" are not compatible.
     1575 |     result = async_gen_unwrap_value(o->ags_gen, result);                                                                                                 1575 |     result = async_gen_unwrap_value(o->ags_gen, result);
     1576 |                                                                                                                                                          1576 |
     1577 |     if (result == NULL) {                                                                                                                                1577 |     if (result == NULL) {
     1577 +     if (result == 0) {                                                                                                                                   1577 +     if (result == 0) {
     1578 |         o->ags_state = AWAITABLE_STATE_CLOSED;                                                                                                           1578 |         o->ags_state = AWAITABLE_STATE_CLOSED;
     1579 |     }                                                                                                                                                    1579 |     }
     1580 |                                                                                                                                                          1580 |
     1581 |     return result;                                                                                                                                       1581 |     return result;
     1582 | }                                                                                                                                                        1582 | }
"Objects/genobject.c", line 1582.1: 1506-412 (I) Referenced variable "result", which was not initialized in its declaration.                                    "Objects/genobject.c", line 1582.1: 1506-412 (I) Referenced variable "result", which was not initialized in its declaration.
     1583 |                                                                                                                                                          1583 |
     1584 |                                                                                                                                                          1584 |
     1585 | static PyObject *                                                                                                                                        1585 | static PyObject *
     1586 | async_gen_asend_close(PyAsyncGenASend *o, PyObject *args)                                                                                                1586 | async_gen_asend_close(PyAsyncGenASend *o, PyObject *args)
     1587 | {                                                                                                                                                        1587 | {
     1588 |     o->ags_state = AWAITABLE_STATE_CLOSED;                                                                                                               1588 |     o->ags_state = AWAITABLE_STATE_CLOSED;
     1589 |     Py_RETURN_NONE;                                                                                                                                      1589 |     Py_RETURN_NONE;
     1589 +     return _Py_INCREF(((PyObject*)((&_Py_NoneStruct)))), (&_Py_NoneStruct);                                                                              1589 +     return _Py_INCREF(((PyObject*)((&_Py_NoneStruct)))), (&_Py_NoneStruct);
     1590 | }                                                                                                                                                        1590 | }
"Objects/genobject.c", line 1590.1: 1506-414 (I) The parameter "args" is never referenced.                                                                      "Objects/genobject.c", line 1590.1: 1506-414 (I) The parameter "args" is never referenced.
     1591 |                                                                                                                                                          1591 |
     1592 |                                                                                                                                                          1592 |
     1593 | static PyMethodDef async_gen_asend_methods[] = {                                                                                                         1593 | static PyMethodDef async_gen_asend_methods[] = {
"Objects/genobject.c", line 1593.46: 1506-446 (I) Array element(s) [3] will be initialized with a default value of 0.                                           "Objects/genobject.c", line 1593.46: 1506-446 (I) Array element(s) [3] will be initialized with a default value of 0.
     1594 |     {"send", (PyCFunction)async_gen_asend_send, METH_O, send_doc},                                                                                       1594 |     {"send", (PyCFunction)async_gen_asend_send, METH_O, send_doc},
     1594 +     {"send", (PyCFunction)async_gen_asend_send, 0x0008, send_doc},                                                                                       1594 +     {"send", (PyCFunction)async_gen_asend_send, 0x0008, send_doc},
     1595 |     {"throw", (PyCFunction)async_gen_asend_throw, METH_VARARGS, throw_doc},                                                                              1595 |     {"throw", (PyCFunction)async_gen_asend_throw, METH_VARARGS, throw_doc},
     1595 +     {"throw", (PyCFunction)async_gen_asend_throw, 0x0001, throw_doc},                                                                                    1595 +     {"throw", (PyCFunction)async_gen_asend_throw, 0x0001, throw_doc},
     1596 |     {"close", (PyCFunction)async_gen_asend_close, METH_NOARGS, close_doc},                                                                               1596 |     {"close", (PyCFunction)async_gen_asend_close, METH_NOARGS, close_doc},
     1596 +     {"close", (PyCFunction)async_gen_asend_close, 0x0004, close_doc},                                                                                    1596 +     {"close", (PyCFunction)async_gen_asend_close, 0x0004, close_doc},
     1597 |     {NULL, NULL}        /* Sentinel */                                                                                                                   1597 |     {NULL, NULL}        /* Sentinel */
     1597 +     {0, 0}        /* Sentinel */                                                                                                                         1597 +     {0, 0}        /* Sentinel */
"Objects/genobject.c", line 1597.16: 1506-447 (I) The member(s) starting from "ml_flags" will be initialized with a default value of 0.                         "Objects/genobject.c", line 1597.16: 1506-447 (I) The member(s) starting from "ml_flags" will be initialized with a default value of 0.
     1598 | };                                                                                                                                                       1598 | };
     1599 |                                                                                                                                                          1599 |
     1600 |                                                                                                                                                          1600 |
     1601 | static PyAsyncMethods async_gen_asend_as_async = {                                                                                                       1601 | static PyAsyncMethods async_gen_asend_as_async = {
     1602 |     PyObject_SelfIter,                          /* am_await */                                                                                           1602 |     PyObject_SelfIter,                          /* am_await */
     1603 |     0,                                          /* am_aiter */                                                                                           1603 |     0,                                          /* am_aiter */
     1604 |     0                                           /* am_anext */                                                                                           1604 |     0                                           /* am_anext */
     1605 | };                                                                                                                                                       1605 | };
     1606 |                                                                                                                                                          1606 |
     1607 |                                                                                                                                                          1607 |
     1608 | PyTypeObject _PyAsyncGenASend_Type = {                                                                                                                   1608 | PyTypeObject _PyAsyncGenASend_Type = {
     1609 |     PyVarObject_HEAD_INIT(&PyType_Type, 0)                                                                                                               1609 |     PyVarObject_HEAD_INIT(&PyType_Type, 0)
     1609 +     { {   1, &PyType_Type }, 0 },                                                                                                                        1609 +     { {   1, &PyType_Type }, 0 },
     1610 |     "async_generator_asend",                    /* tp_name */                                                                                            1610 |     "async_generator_asend",                    /* tp_name */







Wed Apr 15 07:30:04 CDT 2020  Page 43


     1611 |     sizeof(PyAsyncGenASend),                    /* tp_basicsize */                                                                                       1611 |     sizeof(PyAsyncGenASend),                    /* tp_basicsize */
     1612 |     0,                                          /* tp_itemsize */                                                                                        1612 |     0,                                          /* tp_itemsize */
     1613 |     /* methods */                                                                                                                                        1613 |     /* methods */
     1614 |     (destructor)async_gen_asend_dealloc,        /* tp_dealloc */                                                                                         1614 |     (destructor)async_gen_asend_dealloc,        /* tp_dealloc */
     1615 |     0,                                          /* tp_vectorcall_offset */                                                                               1615 |     0,                                          /* tp_vectorcall_offset */
     1616 |     0,                                          /* tp_getattr */                                                                                         1616 |     0,                                          /* tp_getattr */
     1617 |     0,                                          /* tp_setattr */                                                                                         1617 |     0,                                          /* tp_setattr */
     1618 |     &async_gen_asend_as_async,                  /* tp_as_async */                                                                                        1618 |     &async_gen_asend_as_async,                  /* tp_as_async */
     1619 |     0,                                          /* tp_repr */                                                                                            1619 |     0,                                          /* tp_repr */
     1620 |     0,                                          /* tp_as_number */                                                                                       1620 |     0,                                          /* tp_as_number */
     1621 |     0,                                          /* tp_as_sequence */                                                                                     1621 |     0,                                          /* tp_as_sequence */
     1622 |     0,                                          /* tp_as_mapping */                                                                                      1622 |     0,                                          /* tp_as_mapping */
     1623 |     0,                                          /* tp_hash */                                                                                            1623 |     0,                                          /* tp_hash */
     1624 |     0,                                          /* tp_call */                                                                                            1624 |     0,                                          /* tp_call */
     1625 |     0,                                          /* tp_str */                                                                                             1625 |     0,                                          /* tp_str */
     1626 |     PyObject_GenericGetAttr,                    /* tp_getattro */                                                                                        1626 |     PyObject_GenericGetAttr,                    /* tp_getattro */
     1627 |     0,                                          /* tp_setattro */                                                                                        1627 |     0,                                          /* tp_setattro */
     1628 |     0,                                          /* tp_as_buffer */                                                                                       1628 |     0,                                          /* tp_as_buffer */
     1629 |     Py_TPFLAGS_DEFAULT | Py_TPFLAGS_HAVE_GC,    /* tp_flags */                                                                                           1629 |     Py_TPFLAGS_DEFAULT | Py_TPFLAGS_HAVE_GC,    /* tp_flags */
     1629 +     ( 0 | (1UL << 18) | 0) | (1UL << 14),    /* tp_flags */                                                                                              1629 +     ( 0 | (1UL << 18) | 0) | (1UL << 14),    /* tp_flags */
     1630 |     0,                                          /* tp_doc */                                                                                             1630 |     0,                                          /* tp_doc */
     1631 |     (traverseproc)async_gen_asend_traverse,     /* tp_traverse */                                                                                        1631 |     (traverseproc)async_gen_asend_traverse,     /* tp_traverse */
     1632 |     0,                                          /* tp_clear */                                                                                           1632 |     0,                                          /* tp_clear */
     1633 |     0,                                          /* tp_richcompare */                                                                                     1633 |     0,                                          /* tp_richcompare */
     1634 |     0,                                          /* tp_weaklistoffset */                                                                                  1634 |     0,                                          /* tp_weaklistoffset */
     1635 |     PyObject_SelfIter,                          /* tp_iter */                                                                                            1635 |     PyObject_SelfIter,                          /* tp_iter */
     1636 |     (iternextfunc)async_gen_asend_iternext,     /* tp_iternext */                                                                                        1636 |     (iternextfunc)async_gen_asend_iternext,     /* tp_iternext */
     1637 |     async_gen_asend_methods,                    /* tp_methods */                                                                                         1637 |     async_gen_asend_methods,                    /* tp_methods */
     1638 |     0,                                          /* tp_members */                                                                                         1638 |     0,                                          /* tp_members */
     1639 |     0,                                          /* tp_getset */                                                                                          1639 |     0,                                          /* tp_getset */
     1640 |     0,                                          /* tp_base */                                                                                            1640 |     0,                                          /* tp_base */
     1641 |     0,                                          /* tp_dict */                                                                                            1641 |     0,                                          /* tp_dict */
     1642 |     0,                                          /* tp_descr_get */                                                                                       1642 |     0,                                          /* tp_descr_get */
     1643 |     0,                                          /* tp_descr_set */                                                                                       1643 |     0,                                          /* tp_descr_set */
     1644 |     0,                                          /* tp_dictoffset */                                                                                      1644 |     0,                                          /* tp_dictoffset */
     1645 |     0,                                          /* tp_init */                                                                                            1645 |     0,                                          /* tp_init */
     1646 |     0,                                          /* tp_alloc */                                                                                           1646 |     0,                                          /* tp_alloc */
     1647 |     0,                                          /* tp_new */                                                                                             1647 |     0,                                          /* tp_new */
     1648 | };                                                                                                                                                       1648 | };
"Objects/genobject.c", line 1648.1: 1506-447 (I) The member(s) starting from "tp_free" will be initialized with a default value of 0.                           "Objects/genobject.c", line 1648.1: 1506-447 (I) The member(s) starting from "tp_free" will be initialized with a default value of 0.
     1649 |                                                                                                                                                          1649 |
     1650 |                                                                                                                                                          1650 |
     1651 | static PyObject *                                                                                                                                        1651 | static PyObject *
     1652 | async_gen_asend_new(PyAsyncGenObject *gen, PyObject *sendval)                                                                                            1652 | async_gen_asend_new(PyAsyncGenObject *gen, PyObject *sendval)
     1653 | {                                                                                                                                                        1653 | {
     1654 |     PyAsyncGenASend *o;                                                                                                                                  1654 |     PyAsyncGenASend *o;
     1655 |     if (ag_asend_freelist_free) {                                                                                                                        1655 |     if (ag_asend_freelist_free) {
     1656 |         ag_asend_freelist_free--;                                                                                                                        1656 |         ag_asend_freelist_free--;
     1657 |         o = ag_asend_freelist[ag_asend_freelist_free];                                                                                                   1657 |         o = ag_asend_freelist[ag_asend_freelist_free];
     1658 |         _Py_NewReference((PyObject *)o);                                                                                                                 1658 |         _Py_NewReference((PyObject *)o);
"Objects/genobject.c", line 1658.26: 1506-495 (I) Pointer type conversion found.                                                                                "Objects/genobject.c", line 1658.26: 1506-495 (I) Pointer type conversion found.
"Objects/genobject.c", line 1658.26: 1506-374 (I) Pointer types "struct _object*" and "struct {...}*" are not compatible.                                       "Objects/genobject.c", line 1658.26: 1506-374 (I) Pointer types "struct _object*" and "struct {...}*" are not compatible.
     1659 |     } else {                                                                                                                                             1659 |     } else {
     1660 |         o = PyObject_GC_New(PyAsyncGenASend, &_PyAsyncGenASend_Type);                                                                                    1660 |         o = PyObject_GC_New(PyAsyncGenASend, &_PyAsyncGenASend_Type);
     1660 +         o = ( (PyAsyncGenASend *) _PyObject_GC_New(&_PyAsyncGenASend_Type) );                                                                            1660 +         o = ( (PyAsyncGenASend *) _PyObject_GC_New(&_PyAsyncGenASend_Type) );
"Objects/genobject.c", line 1660.13: 1506-495 (I) Pointer type conversion found.                                                                                "Objects/genobject.c", line 1660.13: 1506-495 (I) Pointer type conversion found.







Wed Apr 15 07:30:04 CDT 2020  Page 44


"Objects/genobject.c", line 1660.13: 1506-374 (I) Pointer types "struct {...}*" and "struct _object*" are not compatible.                                       "Objects/genobject.c", line 1660.13: 1506-374 (I) Pointer types "struct {...}*" and "struct _object*" are not compatible.
     1661 |         if (o == NULL) {                                                                                                                                 1661 |         if (o == NULL) {
     1661 +         if (o == 0) {                                                                                                                                    1661 +         if (o == 0) {
     1662 |             return NULL;                                                                                                                                 1662 |             return NULL;
     1662 +             return 0;                                                                                                                                    1662 +             return 0;
     1663 |         }                                                                                                                                                1663 |         }
     1664 |     }                                                                                                                                                    1664 |     }
     1665 |                                                                                                                                                          1665 |
     1666 |     Py_INCREF(gen);                                                                                                                                      1666 |     Py_INCREF(gen);
     1666 +     _Py_INCREF(((PyObject*)(gen)));                                                                                                                      1666 +     _Py_INCREF(((PyObject*)(gen)));
"Objects/genobject.c", line 1666.5: 1506-495 (I) Pointer type conversion found.                                                                                 "Objects/genobject.c", line 1666.5: 1506-495 (I) Pointer type conversion found.
"Objects/genobject.c", line 1666.5: 1506-374 (I) Pointer types "struct _object*" and "struct {...}*" are not compatible.                                        "Objects/genobject.c", line 1666.5: 1506-374 (I) Pointer types "struct _object*" and "struct {...}*" are not compatible.
     1667 |     o->ags_gen = gen;                                                                                                                                    1667 |     o->ags_gen = gen;
     1668 |                                                                                                                                                          1668 |
     1669 |     Py_XINCREF(sendval);                                                                                                                                 1669 |     Py_XINCREF(sendval);
     1669 +     _Py_XINCREF(((PyObject*)(sendval)));                                                                                                                 1669 +     _Py_XINCREF(((PyObject*)(sendval)));
     1670 |     o->ags_sendval = sendval;                                                                                                                            1670 |     o->ags_sendval = sendval;
     1671 |                                                                                                                                                          1671 |
     1672 |     o->ags_state = AWAITABLE_STATE_INIT;                                                                                                                 1672 |     o->ags_state = AWAITABLE_STATE_INIT;
     1673 |                                                                                                                                                          1673 |
     1674 |     _PyObject_GC_TRACK((PyObject*)o);                                                                                                                    1674 |     _PyObject_GC_TRACK((PyObject*)o);
     1674 +     _PyObject_GC_TRACK_impl("Objects/genobject.c", 1674, ((PyObject*)((PyObject*)o)));                                                                   1674 +     _PyObject_GC_TRACK_impl("Objects/genobject.c", 1674, ((PyObject*)((PyObject*)o)));
"Objects/genobject.c", line 1674.5: 1506-495 (I) Pointer type conversion found.                                                                                 "Objects/genobject.c", line 1674.5: 1506-495 (I) Pointer type conversion found.
"Objects/genobject.c", line 1674.5: 1506-374 (I) Pointer types "struct _object*" and "struct {...}*" are not compatible.                                        "Objects/genobject.c", line 1674.5: 1506-374 (I) Pointer types "struct _object*" and "struct {...}*" are not compatible.
     1675 |     return (PyObject*)o;                                                                                                                                 1675 |     return (PyObject*)o;
"Objects/genobject.c", line 1675.12: 1506-495 (I) Pointer type conversion found.                                                                                "Objects/genobject.c", line 1675.12: 1506-495 (I) Pointer type conversion found.
"Objects/genobject.c", line 1675.12: 1506-374 (I) Pointer types "struct _object*" and "struct {...}*" are not compatible.                                       "Objects/genobject.c", line 1675.12: 1506-374 (I) Pointer types "struct _object*" and "struct {...}*" are not compatible.
     1676 | }                                                                                                                                                        1676 | }
"Objects/genobject.c", line 1676.1: 1506-412 (I) Referenced variable "o", which was not initialized in its declaration.                                         "Objects/genobject.c", line 1676.1: 1506-412 (I) Referenced variable "o", which was not initialized in its declaration.
     1677 |                                                                                                                                                          1677 |
     1678 |                                                                                                                                                          1678 |
     1679 | /* ---------- Async Generator Value Wrapper ------------ */                                                                                              1679 | /* ---------- Async Generator Value Wrapper ------------ */
     1680 |                                                                                                                                                          1680 |
     1681 |                                                                                                                                                          1681 |
     1682 | static void                                                                                                                                              1682 | static void
     1683 | async_gen_wrapped_val_dealloc(_PyAsyncGenWrappedValue *o)                                                                                                1683 | async_gen_wrapped_val_dealloc(_PyAsyncGenWrappedValue *o)
     1684 | {                                                                                                                                                        1684 | {
     1685 |     _PyObject_GC_UNTRACK((PyObject *)o);                                                                                                                 1685 |     _PyObject_GC_UNTRACK((PyObject *)o);
     1685 +     _PyObject_GC_UNTRACK_impl("Objects/genobject.c", 1685, ((PyObject*)((PyObject *)o)));                                                                1685 +     _PyObject_GC_UNTRACK_impl("Objects/genobject.c", 1685, ((PyObject*)((PyObject *)o)));
"Objects/genobject.c", line 1685.5: 1506-495 (I) Pointer type conversion found.                                                                                 "Objects/genobject.c", line 1685.5: 1506-495 (I) Pointer type conversion found.
"Objects/genobject.c", line 1685.5: 1506-374 (I) Pointer types "struct _object*" and "struct {...}*" are not compatible.                                        "Objects/genobject.c", line 1685.5: 1506-374 (I) Pointer types "struct _object*" and "struct {...}*" are not compatible.
     1686 |     Py_CLEAR(o->agw_val);                                                                                                                                1686 |     Py_CLEAR(o->agw_val);
     1686 +     do { PyObject *_py_tmp = ((PyObject*)(o->agw_val)); if (_py_tmp != 0) { (o->agw_val) = 0; _Py_DECREF("Objects/genobject.c", 1686, ((PyObject*)(      1686 +     do { PyObject *_py_tmp = ((PyObject*)(o->agw_val)); if (_py_tmp != 0) { (o->agw_val) = 0; _Py_DECREF("Objects/genobject.c", 1686, ((PyObject*)(
"Objects/genobject.c", line 1686.5: 1506-425 (I) The condition is always false.                                                                                 "Objects/genobject.c", line 1686.5: 1506-425 (I) The condition is always false.
     1687 |     if (ag_value_freelist_free < _PyAsyncGen_MAXFREELIST) {                                                                                              1687 |     if (ag_value_freelist_free < _PyAsyncGen_MAXFREELIST) {
     1687 +     if (ag_value_freelist_free < 80) {                                                                                                                   1687 +     if (ag_value_freelist_free < 80) {
     1688 |         assert(_PyAsyncGenWrappedValue_CheckExact(o));                                                                                                   1688 |         assert(_PyAsyncGenWrappedValue_CheckExact(o));
     1688 +         ((_Py_IS_TYPE(((const PyObject*)(o)), &_PyAsyncGenWrappedValue_Type)) ? ((void)0) : __assert("_PyAsyncGenWrappedValue_CheckExact(o)", "Obje      1688 +         ((_Py_IS_TYPE(((const PyObject*)(o)), &_PyAsyncGenWrappedValue_Type)) ? ((void)0) : __assert("_PyAsyncGenWrappedValue_CheckExact(o)", "Obje
"Objects/genobject.c", line 1688.16: 1506-495 (I) Pointer type conversion found.                                                                                "Objects/genobject.c", line 1688.16: 1506-495 (I) Pointer type conversion found.
"Objects/genobject.c", line 1688.16: 1506-374 (I) Pointer types "const struct _object*" and "struct {...}*" are not compatible.                                 "Objects/genobject.c", line 1688.16: 1506-374 (I) Pointer types "const struct _object*" and "struct {...}*" are not compatible.
     1689 |         ag_value_freelist[ag_value_freelist_free++] = o;                                                                                                 1689 |         ag_value_freelist[ag_value_freelist_free++] = o;
     1690 |     } else {                                                                                                                                             1690 |     } else {
     1691 |         PyObject_GC_Del(o);                                                                                                                              1691 |         PyObject_GC_Del(o);
     1692 |     }                                                                                                                                                    1692 |     }
     1693 | }                                                                                                                                                        1693 | }
     1694 |                                                                                                                                                          1694 |







Wed Apr 15 07:30:04 CDT 2020  Page 45


     1695 |                                                                                                                                                          1695 |
     1696 | static int                                                                                                                                               1696 | static int
     1697 | async_gen_wrapped_val_traverse(_PyAsyncGenWrappedValue *o,                                                                                               1697 | async_gen_wrapped_val_traverse(_PyAsyncGenWrappedValue *o,
     1698 |                                visitproc visit, void *arg)                                                                                               1698 |                                visitproc visit, void *arg)
     1699 | {                                                                                                                                                        1699 | {
     1700 |     Py_VISIT(o->agw_val);                                                                                                                                1700 |     Py_VISIT(o->agw_val);
     1700 +     do { if (o->agw_val) { int vret = visit(((PyObject*)(o->agw_val)), arg); if (vret) return vret; } } while (0);                                       1700 +     do { if (o->agw_val) { int vret = visit(((PyObject*)(o->agw_val)), arg); if (vret) return vret; } } while (0);
"Objects/genobject.c", line 1700.5: 1506-425 (I) The condition is always false.                                                                                 "Objects/genobject.c", line 1700.5: 1506-425 (I) The condition is always false.
     1701 |     return 0;                                                                                                                                            1701 |     return 0;
     1702 | }                                                                                                                                                        1702 | }
     1703 |                                                                                                                                                          1703 |
     1704 |                                                                                                                                                          1704 |
     1705 | PyTypeObject _PyAsyncGenWrappedValue_Type = {                                                                                                            1705 | PyTypeObject _PyAsyncGenWrappedValue_Type = {
     1706 |     PyVarObject_HEAD_INIT(&PyType_Type, 0)                                                                                                               1706 |     PyVarObject_HEAD_INIT(&PyType_Type, 0)
     1706 +     { {   1, &PyType_Type }, 0 },                                                                                                                        1706 +     { {   1, &PyType_Type }, 0 },
     1707 |     "async_generator_wrapped_value",            /* tp_name */                                                                                            1707 |     "async_generator_wrapped_value",            /* tp_name */
     1708 |     sizeof(_PyAsyncGenWrappedValue),            /* tp_basicsize */                                                                                       1708 |     sizeof(_PyAsyncGenWrappedValue),            /* tp_basicsize */
     1709 |     0,                                          /* tp_itemsize */                                                                                        1709 |     0,                                          /* tp_itemsize */
     1710 |     /* methods */                                                                                                                                        1710 |     /* methods */
     1711 |     (destructor)async_gen_wrapped_val_dealloc,  /* tp_dealloc */                                                                                         1711 |     (destructor)async_gen_wrapped_val_dealloc,  /* tp_dealloc */
     1712 |     0,                                          /* tp_vectorcall_offset */                                                                               1712 |     0,                                          /* tp_vectorcall_offset */
     1713 |     0,                                          /* tp_getattr */                                                                                         1713 |     0,                                          /* tp_getattr */
     1714 |     0,                                          /* tp_setattr */                                                                                         1714 |     0,                                          /* tp_setattr */
     1715 |     0,                                          /* tp_as_async */                                                                                        1715 |     0,                                          /* tp_as_async */
     1716 |     0,                                          /* tp_repr */                                                                                            1716 |     0,                                          /* tp_repr */
     1717 |     0,                                          /* tp_as_number */                                                                                       1717 |     0,                                          /* tp_as_number */
     1718 |     0,                                          /* tp_as_sequence */                                                                                     1718 |     0,                                          /* tp_as_sequence */
     1719 |     0,                                          /* tp_as_mapping */                                                                                      1719 |     0,                                          /* tp_as_mapping */
     1720 |     0,                                          /* tp_hash */                                                                                            1720 |     0,                                          /* tp_hash */
     1721 |     0,                                          /* tp_call */                                                                                            1721 |     0,                                          /* tp_call */
     1722 |     0,                                          /* tp_str */                                                                                             1722 |     0,                                          /* tp_str */
     1723 |     PyObject_GenericGetAttr,                    /* tp_getattro */                                                                                        1723 |     PyObject_GenericGetAttr,                    /* tp_getattro */
     1724 |     0,                                          /* tp_setattro */                                                                                        1724 |     0,                                          /* tp_setattro */
     1725 |     0,                                          /* tp_as_buffer */                                                                                       1725 |     0,                                          /* tp_as_buffer */
     1726 |     Py_TPFLAGS_DEFAULT | Py_TPFLAGS_HAVE_GC,    /* tp_flags */                                                                                           1726 |     Py_TPFLAGS_DEFAULT | Py_TPFLAGS_HAVE_GC,    /* tp_flags */
     1726 +     ( 0 | (1UL << 18) | 0) | (1UL << 14),    /* tp_flags */                                                                                              1726 +     ( 0 | (1UL << 18) | 0) | (1UL << 14),    /* tp_flags */
     1727 |     0,                                          /* tp_doc */                                                                                             1727 |     0,                                          /* tp_doc */
     1728 |     (traverseproc)async_gen_wrapped_val_traverse, /* tp_traverse */                                                                                      1728 |     (traverseproc)async_gen_wrapped_val_traverse, /* tp_traverse */
     1729 |     0,                                          /* tp_clear */                                                                                           1729 |     0,                                          /* tp_clear */
     1730 |     0,                                          /* tp_richcompare */                                                                                     1730 |     0,                                          /* tp_richcompare */
     1731 |     0,                                          /* tp_weaklistoffset */                                                                                  1731 |     0,                                          /* tp_weaklistoffset */
     1732 |     0,                                          /* tp_iter */                                                                                            1732 |     0,                                          /* tp_iter */
     1733 |     0,                                          /* tp_iternext */                                                                                        1733 |     0,                                          /* tp_iternext */
     1734 |     0,                                          /* tp_methods */                                                                                         1734 |     0,                                          /* tp_methods */
     1735 |     0,                                          /* tp_members */                                                                                         1735 |     0,                                          /* tp_members */
     1736 |     0,                                          /* tp_getset */                                                                                          1736 |     0,                                          /* tp_getset */
     1737 |     0,                                          /* tp_base */                                                                                            1737 |     0,                                          /* tp_base */
     1738 |     0,                                          /* tp_dict */                                                                                            1738 |     0,                                          /* tp_dict */
     1739 |     0,                                          /* tp_descr_get */                                                                                       1739 |     0,                                          /* tp_descr_get */
     1740 |     0,                                          /* tp_descr_set */                                                                                       1740 |     0,                                          /* tp_descr_set */
     1741 |     0,                                          /* tp_dictoffset */                                                                                      1741 |     0,                                          /* tp_dictoffset */
     1742 |     0,                                          /* tp_init */                                                                                            1742 |     0,                                          /* tp_init */
     1743 |     0,                                          /* tp_alloc */                                                                                           1743 |     0,                                          /* tp_alloc */
     1744 |     0,                                          /* tp_new */                                                                                             1744 |     0,                                          /* tp_new */
     1745 | };                                                                                                                                                       1745 | };
"Objects/genobject.c", line 1745.1: 1506-447 (I) The member(s) starting from "tp_free" will be initialized with a default value of 0.                           "Objects/genobject.c", line 1745.1: 1506-447 (I) The member(s) starting from "tp_free" will be initialized with a default value of 0.







Wed Apr 15 07:30:04 CDT 2020  Page 46


     1746 |                                                                                                                                                          1746 |
     1747 |                                                                                                                                                          1747 |
     1748 | PyObject *                                                                                                                                               1748 | PyObject *
     1749 | _PyAsyncGenValueWrapperNew(PyObject *val)                                                                                                                1749 | _PyAsyncGenValueWrapperNew(PyObject *val)
     1750 | {                                                                                                                                                        1750 | {
     1751 |     _PyAsyncGenWrappedValue *o;                                                                                                                          1751 |     _PyAsyncGenWrappedValue *o;
     1752 |     assert(val);                                                                                                                                         1752 |     assert(val);
     1752 +     ((val) ? ((void)0) : __assert("val", "Objects/genobject.c", 1752));                                                                                  1752 +     ((val) ? ((void)0) : __assert("val", "Objects/genobject.c", 1752));
     1753 |                                                                                                                                                          1753 |
     1754 |     if (ag_value_freelist_free) {                                                                                                                        1754 |     if (ag_value_freelist_free) {
     1755 |         ag_value_freelist_free--;                                                                                                                        1755 |         ag_value_freelist_free--;
     1756 |         o = ag_value_freelist[ag_value_freelist_free];                                                                                                   1756 |         o = ag_value_freelist[ag_value_freelist_free];
     1757 |         assert(_PyAsyncGenWrappedValue_CheckExact(o));                                                                                                   1757 |         assert(_PyAsyncGenWrappedValue_CheckExact(o));
     1757 +         ((_Py_IS_TYPE(((const PyObject*)(o)), &_PyAsyncGenWrappedValue_Type)) ? ((void)0) : __assert("_PyAsyncGenWrappedValue_CheckExact(o)", "Obje      1757 +         ((_Py_IS_TYPE(((const PyObject*)(o)), &_PyAsyncGenWrappedValue_Type)) ? ((void)0) : __assert("_PyAsyncGenWrappedValue_CheckExact(o)", "Obje
"Objects/genobject.c", line 1757.16: 1506-495 (I) Pointer type conversion found.                                                                                "Objects/genobject.c", line 1757.16: 1506-495 (I) Pointer type conversion found.
"Objects/genobject.c", line 1757.16: 1506-374 (I) Pointer types "const struct _object*" and "struct {...}*" are not compatible.                                 "Objects/genobject.c", line 1757.16: 1506-374 (I) Pointer types "const struct _object*" and "struct {...}*" are not compatible.
     1758 |         _Py_NewReference((PyObject*)o);                                                                                                                  1758 |         _Py_NewReference((PyObject*)o);
"Objects/genobject.c", line 1758.26: 1506-495 (I) Pointer type conversion found.                                                                                "Objects/genobject.c", line 1758.26: 1506-495 (I) Pointer type conversion found.
"Objects/genobject.c", line 1758.26: 1506-374 (I) Pointer types "struct _object*" and "struct {...}*" are not compatible.                                       "Objects/genobject.c", line 1758.26: 1506-374 (I) Pointer types "struct _object*" and "struct {...}*" are not compatible.
     1759 |     } else {                                                                                                                                             1759 |     } else {
     1760 |         o = PyObject_GC_New(_PyAsyncGenWrappedValue,                                                                                                     1760 |         o = PyObject_GC_New(_PyAsyncGenWrappedValue,
     1760 +         o =                                                                                                                                              1760 +         o =
     1761 |                             &_PyAsyncGenWrappedValue_Type);                                                                                              1761 |                             &_PyAsyncGenWrappedValue_Type);
     1761 + ( (_PyAsyncGenWrappedValue *) _PyObject_GC_New(&_PyAsyncGenWrappedValue_Type) );                                                                         1761 + ( (_PyAsyncGenWrappedValue *) _PyObject_GC_New(&_PyAsyncGenWrappedValue_Type) );
"Objects/genobject.c", line 1760.13: 1506-495 (I) Pointer type conversion found.                                                                                "Objects/genobject.c", line 1760.13: 1506-495 (I) Pointer type conversion found.
"Objects/genobject.c", line 1760.13: 1506-374 (I) Pointer types "struct {...}*" and "struct _object*" are not compatible.                                       "Objects/genobject.c", line 1760.13: 1506-374 (I) Pointer types "struct {...}*" and "struct _object*" are not compatible.
     1762 |         if (o == NULL) {                                                                                                                                 1762 |         if (o == NULL) {
     1762 +         if (o == 0) {                                                                                                                                    1762 +         if (o == 0) {
     1763 |             return NULL;                                                                                                                                 1763 |             return NULL;
     1763 +             return 0;                                                                                                                                    1763 +             return 0;
     1764 |         }                                                                                                                                                1764 |         }
     1765 |     }                                                                                                                                                    1765 |     }
     1766 |     o->agw_val = val;                                                                                                                                    1766 |     o->agw_val = val;
     1767 |     Py_INCREF(val);                                                                                                                                      1767 |     Py_INCREF(val);
     1767 +     _Py_INCREF(((PyObject*)(val)));                                                                                                                      1767 +     _Py_INCREF(((PyObject*)(val)));
     1768 |     _PyObject_GC_TRACK((PyObject*)o);                                                                                                                    1768 |     _PyObject_GC_TRACK((PyObject*)o);
     1768 +     _PyObject_GC_TRACK_impl("Objects/genobject.c", 1768, ((PyObject*)((PyObject*)o)));                                                                   1768 +     _PyObject_GC_TRACK_impl("Objects/genobject.c", 1768, ((PyObject*)((PyObject*)o)));
"Objects/genobject.c", line 1768.5: 1506-495 (I) Pointer type conversion found.                                                                                 "Objects/genobject.c", line 1768.5: 1506-495 (I) Pointer type conversion found.
"Objects/genobject.c", line 1768.5: 1506-374 (I) Pointer types "struct _object*" and "struct {...}*" are not compatible.                                        "Objects/genobject.c", line 1768.5: 1506-374 (I) Pointer types "struct _object*" and "struct {...}*" are not compatible.
     1769 |     return (PyObject*)o;                                                                                                                                 1769 |     return (PyObject*)o;
"Objects/genobject.c", line 1769.12: 1506-495 (I) Pointer type conversion found.                                                                                "Objects/genobject.c", line 1769.12: 1506-495 (I) Pointer type conversion found.
"Objects/genobject.c", line 1769.12: 1506-374 (I) Pointer types "struct _object*" and "struct {...}*" are not compatible.                                       "Objects/genobject.c", line 1769.12: 1506-374 (I) Pointer types "struct _object*" and "struct {...}*" are not compatible.
     1770 | }                                                                                                                                                        1770 | }
"Objects/genobject.c", line 1770.1: 1506-412 (I) Referenced variable "o", which was not initialized in its declaration.                                         "Objects/genobject.c", line 1770.1: 1506-412 (I) Referenced variable "o", which was not initialized in its declaration.
     1771 |                                                                                                                                                          1771 |
     1772 |                                                                                                                                                          1772 |
     1773 | /* ---------- Async Generator AThrow awaitable ------------ */                                                                                           1773 | /* ---------- Async Generator AThrow awaitable ------------ */
     1774 |                                                                                                                                                          1774 |
     1775 |                                                                                                                                                          1775 |
     1776 | static void                                                                                                                                              1776 | static void
     1777 | async_gen_athrow_dealloc(PyAsyncGenAThrow *o)                                                                                                            1777 | async_gen_athrow_dealloc(PyAsyncGenAThrow *o)
     1778 | {                                                                                                                                                        1778 | {
     1779 |     _PyObject_GC_UNTRACK((PyObject *)o);                                                                                                                 1779 |     _PyObject_GC_UNTRACK((PyObject *)o);
     1779 +     _PyObject_GC_UNTRACK_impl("Objects/genobject.c", 1779, ((PyObject*)((PyObject *)o)));                                                                1779 +     _PyObject_GC_UNTRACK_impl("Objects/genobject.c", 1779, ((PyObject*)((PyObject *)o)));
"Objects/genobject.c", line 1779.5: 1506-495 (I) Pointer type conversion found.                                                                                 "Objects/genobject.c", line 1779.5: 1506-495 (I) Pointer type conversion found.
"Objects/genobject.c", line 1779.5: 1506-374 (I) Pointer types "struct _object*" and "struct {...}*" are not compatible.                                        "Objects/genobject.c", line 1779.5: 1506-374 (I) Pointer types "struct _object*" and "struct {...}*" are not compatible.







Wed Apr 15 07:30:04 CDT 2020  Page 47


     1780 |     Py_CLEAR(o->agt_gen);                                                                                                                                1780 |     Py_CLEAR(o->agt_gen);
     1780 +     do { PyObject *_py_tmp = ((PyObject*)(o->agt_gen)); if (_py_tmp != 0) { (o->agt_gen) = 0; _Py_DECREF("Objects/genobject.c", 1780, ((PyObject*)(      1780 +     do { PyObject *_py_tmp = ((PyObject*)(o->agt_gen)); if (_py_tmp != 0) { (o->agt_gen) = 0; _Py_DECREF("Objects/genobject.c", 1780, ((PyObject*)(
"Objects/genobject.c", line 1780.5: 1506-495 (I) Pointer type conversion found.                                                                                 "Objects/genobject.c", line 1780.5: 1506-495 (I) Pointer type conversion found.
"Objects/genobject.c", line 1780.5: 1506-374 (I) Pointer types "struct _object*" and "struct {...}*" are not compatible.                                        "Objects/genobject.c", line 1780.5: 1506-374 (I) Pointer types "struct _object*" and "struct {...}*" are not compatible.
"Objects/genobject.c", line 1780.5: 1506-425 (I) The condition is always false.                                                                                 "Objects/genobject.c", line 1780.5: 1506-425 (I) The condition is always false.
     1781 |     Py_CLEAR(o->agt_args);                                                                                                                               1781 |     Py_CLEAR(o->agt_args);
     1781 +     do { PyObject *_py_tmp = ((PyObject*)(o->agt_args)); if (_py_tmp != 0) { (o->agt_args) = 0; _Py_DECREF("Objects/genobject.c", 1781, ((PyObject*      1781 +     do { PyObject *_py_tmp = ((PyObject*)(o->agt_args)); if (_py_tmp != 0) { (o->agt_args) = 0; _Py_DECREF("Objects/genobject.c", 1781, ((PyObject*
"Objects/genobject.c", line 1781.5: 1506-425 (I) The condition is always false.                                                                                 "Objects/genobject.c", line 1781.5: 1506-425 (I) The condition is always false.
     1782 |     PyObject_GC_Del(o);                                                                                                                                  1782 |     PyObject_GC_Del(o);
     1783 | }                                                                                                                                                        1783 | }
     1784 |                                                                                                                                                          1784 |
     1785 |                                                                                                                                                          1785 |
     1786 | static int                                                                                                                                               1786 | static int
     1787 | async_gen_athrow_traverse(PyAsyncGenAThrow *o, visitproc visit, void *arg)                                                                               1787 | async_gen_athrow_traverse(PyAsyncGenAThrow *o, visitproc visit, void *arg)
     1788 | {                                                                                                                                                        1788 | {
     1789 |     Py_VISIT(o->agt_gen);                                                                                                                                1789 |     Py_VISIT(o->agt_gen);
     1789 +     do { if (o->agt_gen) { int vret = visit(((PyObject*)(o->agt_gen)), arg); if (vret) return vret; } } while (0);                                       1789 +     do { if (o->agt_gen) { int vret = visit(((PyObject*)(o->agt_gen)), arg); if (vret) return vret; } } while (0);
"Objects/genobject.c", line 1789.5: 1506-495 (I) Pointer type conversion found.                                                                                 "Objects/genobject.c", line 1789.5: 1506-495 (I) Pointer type conversion found.
"Objects/genobject.c", line 1789.5: 1506-374 (I) Pointer types "struct _object*" and "struct {...}*" are not compatible.                                        "Objects/genobject.c", line 1789.5: 1506-374 (I) Pointer types "struct _object*" and "struct {...}*" are not compatible.
"Objects/genobject.c", line 1789.5: 1506-425 (I) The condition is always false.                                                                                 "Objects/genobject.c", line 1789.5: 1506-425 (I) The condition is always false.
     1790 |     Py_VISIT(o->agt_args);                                                                                                                               1790 |     Py_VISIT(o->agt_args);
     1790 +     do { if (o->agt_args) { int vret = visit(((PyObject*)(o->agt_args)), arg); if (vret) return vret; } } while (0);                                     1790 +     do { if (o->agt_args) { int vret = visit(((PyObject*)(o->agt_args)), arg); if (vret) return vret; } } while (0);
"Objects/genobject.c", line 1790.5: 1506-425 (I) The condition is always false.                                                                                 "Objects/genobject.c", line 1790.5: 1506-425 (I) The condition is always false.
     1791 |     return 0;                                                                                                                                            1791 |     return 0;
     1792 | }                                                                                                                                                        1792 | }
     1793 |                                                                                                                                                          1793 |
     1794 |                                                                                                                                                          1794 |
     1795 | static PyObject *                                                                                                                                        1795 | static PyObject *
     1796 | async_gen_athrow_send(PyAsyncGenAThrow *o, PyObject *arg)                                                                                                1796 | async_gen_athrow_send(PyAsyncGenAThrow *o, PyObject *arg)
     1797 | {                                                                                                                                                        1797 | {
     1798 |     PyGenObject *gen = (PyGenObject*)o->agt_gen;                                                                                                         1798 |     PyGenObject *gen = (PyGenObject*)o->agt_gen;
"Objects/genobject.c", line 1798.24: 1506-495 (I) Pointer type conversion found.                                                                                "Objects/genobject.c", line 1798.24: 1506-495 (I) Pointer type conversion found.
"Objects/genobject.c", line 1798.24: 1506-374 (I) Pointer types "struct {...}*" and "struct {...}*" are not compatible.                                         "Objects/genobject.c", line 1798.24: 1506-374 (I) Pointer types "struct {...}*" and "struct {...}*" are not compatible.
     1799 |     PyFrameObject *f = gen->gi_frame;                                                                                                                    1799 |     PyFrameObject *f = gen->gi_frame;
     1800 |     PyObject *retval;                                                                                                                                    1800 |     PyObject *retval;
     1801 |                                                                                                                                                          1801 |
     1802 |     if (o->agt_state == AWAITABLE_STATE_CLOSED) {                                                                                                        1802 |     if (o->agt_state == AWAITABLE_STATE_CLOSED) {
     1803 |         PyErr_SetString(                                                                                                                                 1803 |         PyErr_SetString(
     1804 |             PyExc_RuntimeError,                                                                                                                          1804 |             PyExc_RuntimeError,
     1805 |             "cannot reuse already awaited aclose()/athrow()");                                                                                           1805 |             "cannot reuse already awaited aclose()/athrow()");
     1806 |         return NULL;                                                                                                                                     1806 |         return NULL;
     1806 +         return 0;                                                                                                                                        1806 +         return 0;
     1807 |     }                                                                                                                                                    1807 |     }
     1808 |                                                                                                                                                          1808 |
     1809 |     if (f == NULL || f->f_stacktop == NULL) {                                                                                                            1809 |     if (f == NULL || f->f_stacktop == NULL) {
     1809 +     if (f == 0 || f->f_stacktop == 0) {                                                                                                                  1809 +     if (f == 0 || f->f_stacktop == 0) {
     1810 |         o->agt_state = AWAITABLE_STATE_CLOSED;                                                                                                           1810 |         o->agt_state = AWAITABLE_STATE_CLOSED;
     1811 |         PyErr_SetNone(PyExc_StopIteration);                                                                                                              1811 |         PyErr_SetNone(PyExc_StopIteration);
     1812 |         return NULL;                                                                                                                                     1812 |         return NULL;
     1812 +         return 0;                                                                                                                                        1812 +         return 0;
     1813 |     }                                                                                                                                                    1813 |     }
     1814 |                                                                                                                                                          1814 |
     1815 |     if (o->agt_state == AWAITABLE_STATE_INIT) {                                                                                                          1815 |     if (o->agt_state == AWAITABLE_STATE_INIT) {
     1816 |         if (o->agt_gen->ag_running_async) {                                                                                                              1816 |         if (o->agt_gen->ag_running_async) {
     1817 |             o->agt_state = AWAITABLE_STATE_CLOSED;                                                                                                       1817 |             o->agt_state = AWAITABLE_STATE_CLOSED;
     1818 |             if (o->agt_args == NULL) {                                                                                                                   1818 |             if (o->agt_args == NULL) {







Wed Apr 15 07:30:04 CDT 2020  Page 48


     1818 +             if (o->agt_args == 0) {                                                                                                                      1818 +             if (o->agt_args == 0) {
     1819 |                 PyErr_SetString(                                                                                                                         1819 |                 PyErr_SetString(
     1820 |                     PyExc_RuntimeError,                                                                                                                  1820 |                     PyExc_RuntimeError,
     1821 |                     "aclose(): asynchronous generator is already running");                                                                              1821 |                     "aclose(): asynchronous generator is already running");
     1822 |             }                                                                                                                                            1822 |             }
     1823 |             else {                                                                                                                                       1823 |             else {
     1824 |                 PyErr_SetString(                                                                                                                         1824 |                 PyErr_SetString(
     1825 |                     PyExc_RuntimeError,                                                                                                                  1825 |                     PyExc_RuntimeError,
     1826 |                     "athrow(): asynchronous generator is already running");                                                                              1826 |                     "athrow(): asynchronous generator is already running");
     1827 |             }                                                                                                                                            1827 |             }
     1828 |             return NULL;                                                                                                                                 1828 |             return NULL;
     1828 +             return 0;                                                                                                                                    1828 +             return 0;
     1829 |         }                                                                                                                                                1829 |         }
     1830 |                                                                                                                                                          1830 |
     1831 |         if (o->agt_gen->ag_closed) {                                                                                                                     1831 |         if (o->agt_gen->ag_closed) {
     1832 |             o->agt_state = AWAITABLE_STATE_CLOSED;                                                                                                       1832 |             o->agt_state = AWAITABLE_STATE_CLOSED;
     1833 |             PyErr_SetNone(PyExc_StopAsyncIteration);                                                                                                     1833 |             PyErr_SetNone(PyExc_StopAsyncIteration);
     1834 |             return NULL;                                                                                                                                 1834 |             return NULL;
     1834 +             return 0;                                                                                                                                    1834 +             return 0;
     1835 |         }                                                                                                                                                1835 |         }
     1836 |                                                                                                                                                          1836 |
     1837 |         if (arg != Py_None) {                                                                                                                            1837 |         if (arg != Py_None) {
     1837 +         if (arg != (&_Py_NoneStruct)) {                                                                                                                  1837 +         if (arg != (&_Py_NoneStruct)) {
     1838 |             PyErr_SetString(PyExc_RuntimeError, NON_INIT_CORO_MSG);                                                                                      1838 |             PyErr_SetString(PyExc_RuntimeError, NON_INIT_CORO_MSG);
     1839 |             return NULL;                                                                                                                                 1839 |             return NULL;
     1839 +             return 0;                                                                                                                                    1839 +             return 0;
     1840 |         }                                                                                                                                                1840 |         }
     1841 |                                                                                                                                                          1841 |
     1842 |         o->agt_state = AWAITABLE_STATE_ITER;                                                                                                             1842 |         o->agt_state = AWAITABLE_STATE_ITER;
     1843 |         o->agt_gen->ag_running_async = 1;                                                                                                                1843 |         o->agt_gen->ag_running_async = 1;
     1844 |                                                                                                                                                          1844 |
     1845 |         if (o->agt_args == NULL) {                                                                                                                       1845 |         if (o->agt_args == NULL) {
     1845 +         if (o->agt_args == 0) {                                                                                                                          1845 +         if (o->agt_args == 0) {
     1846 |             /* aclose() mode */                                                                                                                          1846 |             /* aclose() mode */
     1847 |             o->agt_gen->ag_closed = 1;                                                                                                                   1847 |             o->agt_gen->ag_closed = 1;
     1848 |                                                                                                                                                          1848 |
     1849 |             retval = _gen_throw((PyGenObject *)gen,                                                                                                      1849 |             retval = _gen_throw((PyGenObject *)gen,
     1850 |                                 0,  /* Do not close generator when                                                                                       1850 |                                 0,  /* Do not close generator when
     1851 |                                        PyExc_GeneratorExit is passed */                                                                                  1851 |                                        PyExc_GeneratorExit is passed */
     1852 |                                 PyExc_GeneratorExit, NULL, NULL);                                                                                        1852 |                                 PyExc_GeneratorExit, NULL, NULL);
     1852 +                                 PyExc_GeneratorExit, 0, 0);                                                                                              1852 +                                 PyExc_GeneratorExit, 0, 0);
     1853 |                                                                                                                                                          1853 |
     1854 |             if (retval && _PyAsyncGenWrappedValue_CheckExact(retval)) {                                                                                  1854 |             if (retval && _PyAsyncGenWrappedValue_CheckExact(retval)) {
     1854 +             if (retval && _Py_IS_TYPE(((const PyObject*)(retval)), &_PyAsyncGenWrappedValue_Type)) {                                                     1854 +             if (retval && _Py_IS_TYPE(((const PyObject*)(retval)), &_PyAsyncGenWrappedValue_Type)) {
"Objects/genobject.c", line 1854.27: 1506-495 (I) Pointer type conversion found.                                                                                "Objects/genobject.c", line 1854.27: 1506-495 (I) Pointer type conversion found.
"Objects/genobject.c", line 1854.27: 1506-374 (I) Pointer types "const struct _object*" and "struct _object*" are not compatible.                               "Objects/genobject.c", line 1854.27: 1506-374 (I) Pointer types "const struct _object*" and "struct _object*" are not compatible.
     1855 |                 Py_DECREF(retval);                                                                                                                       1855 |                 Py_DECREF(retval);
     1855 +                 _Py_DECREF("Objects/genobject.c", 1855, ((PyObject*)(retval)));                                                                          1855 +                 _Py_DECREF("Objects/genobject.c", 1855, ((PyObject*)(retval)));
     1856 |                 goto yield_close;                                                                                                                        1856 |                 goto yield_close;
"Objects/genobject.c", line 1856.17: 1506-413 (I) A goto statement is used.                                                                                     "Objects/genobject.c", line 1856.17: 1506-413 (I) A goto statement is used.
     1857 |             }                                                                                                                                            1857 |             }
     1858 |         } else {                                                                                                                                         1858 |         } else {
     1859 |             PyObject *typ;                                                                                                                               1859 |             PyObject *typ;
     1860 |             PyObject *tb = NULL;                                                                                                                         1860 |             PyObject *tb = NULL;
     1860 +             PyObject *tb = 0;                                                                                                                            1860 +             PyObject *tb = 0;
     1861 |             PyObject *val = NULL;                                                                                                                        1861 |             PyObject *val = NULL;







Wed Apr 15 07:30:04 CDT 2020  Page 49


     1861 +             PyObject *val = 0;                                                                                                                           1861 +             PyObject *val = 0;
     1862 |                                                                                                                                                          1862 |
     1863 |             if (!PyArg_UnpackTuple(o->agt_args, "athrow", 1, 3,                                                                                          1863 |             if (!PyArg_UnpackTuple(o->agt_args, "athrow", 1, 3,
     1864 |                                    &typ, &val, &tb)) {                                                                                                   1864 |                                    &typ, &val, &tb)) {
     1865 |                 return NULL;                                                                                                                             1865 |                 return NULL;
     1865 +                 return 0;                                                                                                                                1865 +                 return 0;
     1866 |             }                                                                                                                                            1866 |             }
     1867 |                                                                                                                                                          1867 |
     1868 |             retval = _gen_throw((PyGenObject *)gen,                                                                                                      1868 |             retval = _gen_throw((PyGenObject *)gen,
     1869 |                                 0,  /* Do not close generator when                                                                                       1869 |                                 0,  /* Do not close generator when
     1870 |                                        PyExc_GeneratorExit is passed */                                                                                  1870 |                                        PyExc_GeneratorExit is passed */
     1871 |                                 typ, val, tb);                                                                                                           1871 |                                 typ, val, tb);
     1872 |             retval = async_gen_unwrap_value(o->agt_gen, retval);                                                                                         1872 |             retval = async_gen_unwrap_value(o->agt_gen, retval);
     1873 |         }                                                                                                                                                1873 |         }
"Objects/genobject.c", line 1873.9: 1506-412 (I) Referenced variable "typ", which was not initialized in its declaration.                                       "Objects/genobject.c", line 1873.9: 1506-412 (I) Referenced variable "typ", which was not initialized in its declaration.
     1874 |         if (retval == NULL) {                                                                                                                            1874 |         if (retval == NULL) {
     1874 +         if (retval == 0) {                                                                                                                               1874 +         if (retval == 0) {
     1875 |             goto check_error;                                                                                                                            1875 |             goto check_error;
"Objects/genobject.c", line 1875.13: 1506-413 (I) A goto statement is used.                                                                                     "Objects/genobject.c", line 1875.13: 1506-413 (I) A goto statement is used.
     1876 |         }                                                                                                                                                1876 |         }
     1877 |         return retval;                                                                                                                                   1877 |         return retval;
     1878 |     }                                                                                                                                                    1878 |     }
     1879 |                                                                                                                                                          1879 |
     1880 |     assert(o->agt_state == AWAITABLE_STATE_ITER);                                                                                                        1880 |     assert(o->agt_state == AWAITABLE_STATE_ITER);
     1880 +     ((o->agt_state == AWAITABLE_STATE_ITER) ? ((void)0) : __assert("o->agt_state == AWAITABLE_STATE_ITER", "Objects/genobject.c", 1880));                1880 +     ((o->agt_state == AWAITABLE_STATE_ITER) ? ((void)0) : __assert("o->agt_state == AWAITABLE_STATE_ITER", "Objects/genobject.c", 1880));
     1881 |                                                                                                                                                          1881 |
     1882 |     retval = gen_send_ex((PyGenObject *)gen, arg, 0, 0);                                                                                                 1882 |     retval = gen_send_ex((PyGenObject *)gen, arg, 0, 0);
     1883 |     if (o->agt_args) {                                                                                                                                   1883 |     if (o->agt_args) {
     1884 |         return async_gen_unwrap_value(o->agt_gen, retval);                                                                                               1884 |         return async_gen_unwrap_value(o->agt_gen, retval);
     1885 |     } else {                                                                                                                                             1885 |     } else {
     1886 |         /* aclose() mode */                                                                                                                              1886 |         /* aclose() mode */
     1887 |         if (retval) {                                                                                                                                    1887 |         if (retval) {
     1888 |             if (_PyAsyncGenWrappedValue_CheckExact(retval)) {                                                                                            1888 |             if (_PyAsyncGenWrappedValue_CheckExact(retval)) {
     1888 +             if (_Py_IS_TYPE(((const PyObject*)(retval)), &_PyAsyncGenWrappedValue_Type)) {                                                               1888 +             if (_Py_IS_TYPE(((const PyObject*)(retval)), &_PyAsyncGenWrappedValue_Type)) {
"Objects/genobject.c", line 1888.17: 1506-495 (I) Pointer type conversion found.                                                                                "Objects/genobject.c", line 1888.17: 1506-495 (I) Pointer type conversion found.
"Objects/genobject.c", line 1888.17: 1506-374 (I) Pointer types "const struct _object*" and "struct _object*" are not compatible.                               "Objects/genobject.c", line 1888.17: 1506-374 (I) Pointer types "const struct _object*" and "struct _object*" are not compatible.
     1889 |                 Py_DECREF(retval);                                                                                                                       1889 |                 Py_DECREF(retval);
     1889 +                 _Py_DECREF("Objects/genobject.c", 1889, ((PyObject*)(retval)));                                                                          1889 +                 _Py_DECREF("Objects/genobject.c", 1889, ((PyObject*)(retval)));
     1890 |                 goto yield_close;                                                                                                                        1890 |                 goto yield_close;
"Objects/genobject.c", line 1890.17: 1506-413 (I) A goto statement is used.                                                                                     "Objects/genobject.c", line 1890.17: 1506-413 (I) A goto statement is used.
     1891 |             }                                                                                                                                            1891 |             }
     1892 |             else {                                                                                                                                       1892 |             else {
     1893 |                 return retval;                                                                                                                           1893 |                 return retval;
     1894 |             }                                                                                                                                            1894 |             }
     1895 |         }                                                                                                                                                1895 |         }
     1896 |         else {                                                                                                                                           1896 |         else {
     1897 |             goto check_error;                                                                                                                            1897 |             goto check_error;
"Objects/genobject.c", line 1897.13: 1506-413 (I) A goto statement is used.                                                                                     "Objects/genobject.c", line 1897.13: 1506-413 (I) A goto statement is used.
     1898 |         }                                                                                                                                                1898 |         }
     1899 |     }                                                                                                                                                    1899 |     }
     1900 |                                                                                                                                                          1900 |
     1901 | yield_close:                                                                                                                                             1901 | yield_close:
     1902 |     o->agt_gen->ag_running_async = 0;                                                                                                                    1902 |     o->agt_gen->ag_running_async = 0;
     1903 |     o->agt_state = AWAITABLE_STATE_CLOSED;                                                                                                               1903 |     o->agt_state = AWAITABLE_STATE_CLOSED;
     1904 |     PyErr_SetString(                                                                                                                                     1904 |     PyErr_SetString(
     1905 |         PyExc_RuntimeError, ASYNC_GEN_IGNORED_EXIT_MSG);                                                                                                 1905 |         PyExc_RuntimeError, ASYNC_GEN_IGNORED_EXIT_MSG);







Wed Apr 15 07:30:04 CDT 2020  Page 50


     1906 |     return NULL;                                                                                                                                         1906 |     return NULL;
     1906 +     return 0;                                                                                                                                            1906 +     return 0;
     1907 |                                                                                                                                                          1907 |
     1908 | check_error:                                                                                                                                             1908 | check_error:
     1909 |     o->agt_gen->ag_running_async = 0;                                                                                                                    1909 |     o->agt_gen->ag_running_async = 0;
     1910 |     o->agt_state = AWAITABLE_STATE_CLOSED;                                                                                                               1910 |     o->agt_state = AWAITABLE_STATE_CLOSED;
     1911 |     if (PyErr_ExceptionMatches(PyExc_StopAsyncIteration) ||                                                                                              1911 |     if (PyErr_ExceptionMatches(PyExc_StopAsyncIteration) ||
     1912 |             PyErr_ExceptionMatches(PyExc_GeneratorExit))                                                                                                 1912 |             PyErr_ExceptionMatches(PyExc_GeneratorExit))
     1913 |     {                                                                                                                                                    1913 |     {
     1914 |         if (o->agt_args == NULL) {                                                                                                                       1914 |         if (o->agt_args == NULL) {
     1914 +         if (o->agt_args == 0) {                                                                                                                          1914 +         if (o->agt_args == 0) {
     1915 |             /* when aclose() is called we don't want to propagate                                                                                        1915 |             /* when aclose() is called we don't want to propagate
     1916 |                StopAsyncIteration or GeneratorExit; just raise                                                                                           1916 |                StopAsyncIteration or GeneratorExit; just raise
     1917 |                StopIteration, signalling that this 'aclose()' await                                                                                      1917 |                StopIteration, signalling that this 'aclose()' await
     1918 |                is done.                                                                                                                                  1918 |                is done.
     1919 |             */                                                                                                                                           1919 |             */
     1920 |             PyErr_Clear();                                                                                                                               1920 |             PyErr_Clear();
     1921 |             PyErr_SetNone(PyExc_StopIteration);                                                                                                          1921 |             PyErr_SetNone(PyExc_StopIteration);
     1922 |         }                                                                                                                                                1922 |         }
     1923 |     }                                                                                                                                                    1923 |     }
     1924 |     return NULL;                                                                                                                                         1924 |     return NULL;
     1924 +     return 0;                                                                                                                                            1924 +     return 0;
     1925 | }                                                                                                                                                        1925 | }
"Objects/genobject.c", line 1925.1: 1506-412 (I) Referenced variable "retval", which was not initialized in its declaration.                                    "Objects/genobject.c", line 1925.1: 1506-412 (I) Referenced variable "retval", which was not initialized in its declaration.
     1926 |                                                                                                                                                          1926 |
     1927 |                                                                                                                                                          1927 |
     1928 | static PyObject *                                                                                                                                        1928 | static PyObject *
     1929 | async_gen_athrow_throw(PyAsyncGenAThrow *o, PyObject *args)                                                                                              1929 | async_gen_athrow_throw(PyAsyncGenAThrow *o, PyObject *args)
     1930 | {                                                                                                                                                        1930 | {
     1931 |     PyObject *retval;                                                                                                                                    1931 |     PyObject *retval;
     1932 |                                                                                                                                                          1932 |
     1933 |     if (o->agt_state == AWAITABLE_STATE_CLOSED) {                                                                                                        1933 |     if (o->agt_state == AWAITABLE_STATE_CLOSED) {
     1934 |         PyErr_SetString(                                                                                                                                 1934 |         PyErr_SetString(
     1935 |             PyExc_RuntimeError,                                                                                                                          1935 |             PyExc_RuntimeError,
     1936 |             "cannot reuse already awaited aclose()/athrow()");                                                                                           1936 |             "cannot reuse already awaited aclose()/athrow()");
     1937 |         return NULL;                                                                                                                                     1937 |         return NULL;
     1937 +         return 0;                                                                                                                                        1937 +         return 0;
     1938 |     }                                                                                                                                                    1938 |     }
     1939 |                                                                                                                                                          1939 |
     1940 |     retval = gen_throw((PyGenObject*)o->agt_gen, args);                                                                                                  1940 |     retval = gen_throw((PyGenObject*)o->agt_gen, args);
"Objects/genobject.c", line 1940.24: 1506-495 (I) Pointer type conversion found.                                                                                "Objects/genobject.c", line 1940.24: 1506-495 (I) Pointer type conversion found.
"Objects/genobject.c", line 1940.24: 1506-374 (I) Pointer types "struct {...}*" and "struct {...}*" are not compatible.                                         "Objects/genobject.c", line 1940.24: 1506-374 (I) Pointer types "struct {...}*" and "struct {...}*" are not compatible.
     1941 |     if (o->agt_args) {                                                                                                                                   1941 |     if (o->agt_args) {
     1942 |         return async_gen_unwrap_value(o->agt_gen, retval);                                                                                               1942 |         return async_gen_unwrap_value(o->agt_gen, retval);
     1943 |     } else {                                                                                                                                             1943 |     } else {
     1944 |         /* aclose() mode */                                                                                                                              1944 |         /* aclose() mode */
     1945 |         if (retval && _PyAsyncGenWrappedValue_CheckExact(retval)) {                                                                                      1945 |         if (retval && _PyAsyncGenWrappedValue_CheckExact(retval)) {
     1945 +         if (retval && _Py_IS_TYPE(((const PyObject*)(retval)), &_PyAsyncGenWrappedValue_Type)) {                                                         1945 +         if (retval && _Py_IS_TYPE(((const PyObject*)(retval)), &_PyAsyncGenWrappedValue_Type)) {
"Objects/genobject.c", line 1945.23: 1506-495 (I) Pointer type conversion found.                                                                                "Objects/genobject.c", line 1945.23: 1506-495 (I) Pointer type conversion found.
"Objects/genobject.c", line 1945.23: 1506-374 (I) Pointer types "const struct _object*" and "struct _object*" are not compatible.                               "Objects/genobject.c", line 1945.23: 1506-374 (I) Pointer types "const struct _object*" and "struct _object*" are not compatible.
     1946 |             o->agt_gen->ag_running_async = 0;                                                                                                            1946 |             o->agt_gen->ag_running_async = 0;
     1947 |             o->agt_state = AWAITABLE_STATE_CLOSED;                                                                                                       1947 |             o->agt_state = AWAITABLE_STATE_CLOSED;
     1948 |             Py_DECREF(retval);                                                                                                                           1948 |             Py_DECREF(retval);
     1948 +             _Py_DECREF("Objects/genobject.c", 1948, ((PyObject*)(retval)));                                                                              1948 +             _Py_DECREF("Objects/genobject.c", 1948, ((PyObject*)(retval)));
     1949 |             PyErr_SetString(PyExc_RuntimeError, ASYNC_GEN_IGNORED_EXIT_MSG);                                                                             1949 |             PyErr_SetString(PyExc_RuntimeError, ASYNC_GEN_IGNORED_EXIT_MSG);
     1950 |             return NULL;                                                                                                                                 1950 |             return NULL;







Wed Apr 15 07:30:04 CDT 2020  Page 51


     1950 +             return 0;                                                                                                                                    1950 +             return 0;
     1951 |         }                                                                                                                                                1951 |         }
     1952 |         if (PyErr_ExceptionMatches(PyExc_StopAsyncIteration) ||                                                                                          1952 |         if (PyErr_ExceptionMatches(PyExc_StopAsyncIteration) ||
     1953 |             PyErr_ExceptionMatches(PyExc_GeneratorExit))                                                                                                 1953 |             PyErr_ExceptionMatches(PyExc_GeneratorExit))
     1954 |         {                                                                                                                                                1954 |         {
     1955 |             /* when aclose() is called we don't want to propagate                                                                                        1955 |             /* when aclose() is called we don't want to propagate
     1956 |                StopAsyncIteration or GeneratorExit; just raise                                                                                           1956 |                StopAsyncIteration or GeneratorExit; just raise
     1957 |                StopIteration, signalling that this 'aclose()' await                                                                                      1957 |                StopIteration, signalling that this 'aclose()' await
     1958 |                is done.                                                                                                                                  1958 |                is done.
     1959 |             */                                                                                                                                           1959 |             */
     1960 |             PyErr_Clear();                                                                                                                               1960 |             PyErr_Clear();
     1961 |             PyErr_SetNone(PyExc_StopIteration);                                                                                                          1961 |             PyErr_SetNone(PyExc_StopIteration);
     1962 |         }                                                                                                                                                1962 |         }
     1963 |         return retval;                                                                                                                                   1963 |         return retval;
     1964 |     }                                                                                                                                                    1964 |     }
     1965 | }                                                                                                                                                        1965 | }
"Objects/genobject.c", line 1965.1: 1506-412 (I) Referenced variable "retval", which was not initialized in its declaration.                                    "Objects/genobject.c", line 1965.1: 1506-412 (I) Referenced variable "retval", which was not initialized in its declaration.
     1966 |                                                                                                                                                          1966 |
     1967 |                                                                                                                                                          1967 |
     1968 | static PyObject *                                                                                                                                        1968 | static PyObject *
     1969 | async_gen_athrow_iternext(PyAsyncGenAThrow *o)                                                                                                           1969 | async_gen_athrow_iternext(PyAsyncGenAThrow *o)
     1970 | {                                                                                                                                                        1970 | {
     1971 |     return async_gen_athrow_send(o, Py_None);                                                                                                            1971 |     return async_gen_athrow_send(o, Py_None);
     1971 +     return async_gen_athrow_send(o, (&_Py_NoneStruct));                                                                                                  1971 +     return async_gen_athrow_send(o, (&_Py_NoneStruct));
     1972 | }                                                                                                                                                        1972 | }
     1973 |                                                                                                                                                          1973 |
     1974 |                                                                                                                                                          1974 |
     1975 | static PyObject *                                                                                                                                        1975 | static PyObject *
     1976 | async_gen_athrow_close(PyAsyncGenAThrow *o, PyObject *args)                                                                                              1976 | async_gen_athrow_close(PyAsyncGenAThrow *o, PyObject *args)
     1977 | {                                                                                                                                                        1977 | {
     1978 |     o->agt_state = AWAITABLE_STATE_CLOSED;                                                                                                               1978 |     o->agt_state = AWAITABLE_STATE_CLOSED;
     1979 |     Py_RETURN_NONE;                                                                                                                                      1979 |     Py_RETURN_NONE;
     1979 +     return _Py_INCREF(((PyObject*)((&_Py_NoneStruct)))), (&_Py_NoneStruct);                                                                              1979 +     return _Py_INCREF(((PyObject*)((&_Py_NoneStruct)))), (&_Py_NoneStruct);
     1980 | }                                                                                                                                                        1980 | }
"Objects/genobject.c", line 1980.1: 1506-414 (I) The parameter "args" is never referenced.                                                                      "Objects/genobject.c", line 1980.1: 1506-414 (I) The parameter "args" is never referenced.
     1981 |                                                                                                                                                          1981 |
     1982 |                                                                                                                                                          1982 |
     1983 | static PyMethodDef async_gen_athrow_methods[] = {                                                                                                        1983 | static PyMethodDef async_gen_athrow_methods[] = {
"Objects/genobject.c", line 1983.47: 1506-446 (I) Array element(s) [3] will be initialized with a default value of 0.                                           "Objects/genobject.c", line 1983.47: 1506-446 (I) Array element(s) [3] will be initialized with a default value of 0.
     1984 |     {"send", (PyCFunction)async_gen_athrow_send, METH_O, send_doc},                                                                                      1984 |     {"send", (PyCFunction)async_gen_athrow_send, METH_O, send_doc},
     1984 +     {"send", (PyCFunction)async_gen_athrow_send, 0x0008, send_doc},                                                                                      1984 +     {"send", (PyCFunction)async_gen_athrow_send, 0x0008, send_doc},
     1985 |     {"throw", (PyCFunction)async_gen_athrow_throw, METH_VARARGS, throw_doc},                                                                             1985 |     {"throw", (PyCFunction)async_gen_athrow_throw, METH_VARARGS, throw_doc},
     1985 +     {"throw", (PyCFunction)async_gen_athrow_throw, 0x0001, throw_doc},                                                                                   1985 +     {"throw", (PyCFunction)async_gen_athrow_throw, 0x0001, throw_doc},
     1986 |     {"close", (PyCFunction)async_gen_athrow_close, METH_NOARGS, close_doc},                                                                              1986 |     {"close", (PyCFunction)async_gen_athrow_close, METH_NOARGS, close_doc},
     1986 +     {"close", (PyCFunction)async_gen_athrow_close, 0x0004, close_doc},                                                                                   1986 +     {"close", (PyCFunction)async_gen_athrow_close, 0x0004, close_doc},
     1987 |     {NULL, NULL}        /* Sentinel */                                                                                                                   1987 |     {NULL, NULL}        /* Sentinel */
     1987 +     {0, 0}        /* Sentinel */                                                                                                                         1987 +     {0, 0}        /* Sentinel */
"Objects/genobject.c", line 1987.16: 1506-447 (I) The member(s) starting from "ml_flags" will be initialized with a default value of 0.                         "Objects/genobject.c", line 1987.16: 1506-447 (I) The member(s) starting from "ml_flags" will be initialized with a default value of 0.
     1988 | };                                                                                                                                                       1988 | };
     1989 |                                                                                                                                                          1989 |
     1990 |                                                                                                                                                          1990 |
     1991 | static PyAsyncMethods async_gen_athrow_as_async = {                                                                                                      1991 | static PyAsyncMethods async_gen_athrow_as_async = {
     1992 |     PyObject_SelfIter,                          /* am_await */                                                                                           1992 |     PyObject_SelfIter,                          /* am_await */
     1993 |     0,                                          /* am_aiter */                                                                                           1993 |     0,                                          /* am_aiter */
     1994 |     0                                           /* am_anext */                                                                                           1994 |     0                                           /* am_anext */
     1995 | };                                                                                                                                                       1995 | };







Wed Apr 15 07:30:04 CDT 2020  Page 52


     1996 |                                                                                                                                                          1996 |
     1997 |                                                                                                                                                          1997 |
     1998 | PyTypeObject _PyAsyncGenAThrow_Type = {                                                                                                                  1998 | PyTypeObject _PyAsyncGenAThrow_Type = {
     1999 |     PyVarObject_HEAD_INIT(&PyType_Type, 0)                                                                                                               1999 |     PyVarObject_HEAD_INIT(&PyType_Type, 0)
     1999 +     { {   1, &PyType_Type }, 0 },                                                                                                                        1999 +     { {   1, &PyType_Type }, 0 },
     2000 |     "async_generator_athrow",                   /* tp_name */                                                                                            2000 |     "async_generator_athrow",                   /* tp_name */
     2001 |     sizeof(PyAsyncGenAThrow),                   /* tp_basicsize */                                                                                       2001 |     sizeof(PyAsyncGenAThrow),                   /* tp_basicsize */
     2002 |     0,                                          /* tp_itemsize */                                                                                        2002 |     0,                                          /* tp_itemsize */
     2003 |     /* methods */                                                                                                                                        2003 |     /* methods */
     2004 |     (destructor)async_gen_athrow_dealloc,       /* tp_dealloc */                                                                                         2004 |     (destructor)async_gen_athrow_dealloc,       /* tp_dealloc */
     2005 |     0,                                          /* tp_vectorcall_offset */                                                                               2005 |     0,                                          /* tp_vectorcall_offset */
     2006 |     0,                                          /* tp_getattr */                                                                                         2006 |     0,                                          /* tp_getattr */
     2007 |     0,                                          /* tp_setattr */                                                                                         2007 |     0,                                          /* tp_setattr */
     2008 |     &async_gen_athrow_as_async,                 /* tp_as_async */                                                                                        2008 |     &async_gen_athrow_as_async,                 /* tp_as_async */
     2009 |     0,                                          /* tp_repr */                                                                                            2009 |     0,                                          /* tp_repr */
     2010 |     0,                                          /* tp_as_number */                                                                                       2010 |     0,                                          /* tp_as_number */
     2011 |     0,                                          /* tp_as_sequence */                                                                                     2011 |     0,                                          /* tp_as_sequence */
     2012 |     0,                                          /* tp_as_mapping */                                                                                      2012 |     0,                                          /* tp_as_mapping */
     2013 |     0,                                          /* tp_hash */                                                                                            2013 |     0,                                          /* tp_hash */
     2014 |     0,                                          /* tp_call */                                                                                            2014 |     0,                                          /* tp_call */
     2015 |     0,                                          /* tp_str */                                                                                             2015 |     0,                                          /* tp_str */
     2016 |     PyObject_GenericGetAttr,                    /* tp_getattro */                                                                                        2016 |     PyObject_GenericGetAttr,                    /* tp_getattro */
     2017 |     0,                                          /* tp_setattro */                                                                                        2017 |     0,                                          /* tp_setattro */
     2018 |     0,                                          /* tp_as_buffer */                                                                                       2018 |     0,                                          /* tp_as_buffer */
     2019 |     Py_TPFLAGS_DEFAULT | Py_TPFLAGS_HAVE_GC,    /* tp_flags */                                                                                           2019 |     Py_TPFLAGS_DEFAULT | Py_TPFLAGS_HAVE_GC,    /* tp_flags */
     2019 +     ( 0 | (1UL << 18) | 0) | (1UL << 14),    /* tp_flags */                                                                                              2019 +     ( 0 | (1UL << 18) | 0) | (1UL << 14),    /* tp_flags */
     2020 |     0,                                          /* tp_doc */                                                                                             2020 |     0,                                          /* tp_doc */
     2021 |     (traverseproc)async_gen_athrow_traverse,    /* tp_traverse */                                                                                        2021 |     (traverseproc)async_gen_athrow_traverse,    /* tp_traverse */
     2022 |     0,                                          /* tp_clear */                                                                                           2022 |     0,                                          /* tp_clear */
     2023 |     0,                                          /* tp_richcompare */                                                                                     2023 |     0,                                          /* tp_richcompare */
     2024 |     0,                                          /* tp_weaklistoffset */                                                                                  2024 |     0,                                          /* tp_weaklistoffset */
     2025 |     PyObject_SelfIter,                          /* tp_iter */                                                                                            2025 |     PyObject_SelfIter,                          /* tp_iter */
     2026 |     (iternextfunc)async_gen_athrow_iternext,    /* tp_iternext */                                                                                        2026 |     (iternextfunc)async_gen_athrow_iternext,    /* tp_iternext */
     2027 |     async_gen_athrow_methods,                   /* tp_methods */                                                                                         2027 |     async_gen_athrow_methods,                   /* tp_methods */
     2028 |     0,                                          /* tp_members */                                                                                         2028 |     0,                                          /* tp_members */
     2029 |     0,                                          /* tp_getset */                                                                                          2029 |     0,                                          /* tp_getset */
     2030 |     0,                                          /* tp_base */                                                                                            2030 |     0,                                          /* tp_base */
     2031 |     0,                                          /* tp_dict */                                                                                            2031 |     0,                                          /* tp_dict */
     2032 |     0,                                          /* tp_descr_get */                                                                                       2032 |     0,                                          /* tp_descr_get */
     2033 |     0,                                          /* tp_descr_set */                                                                                       2033 |     0,                                          /* tp_descr_set */
     2034 |     0,                                          /* tp_dictoffset */                                                                                      2034 |     0,                                          /* tp_dictoffset */
     2035 |     0,                                          /* tp_init */                                                                                            2035 |     0,                                          /* tp_init */
     2036 |     0,                                          /* tp_alloc */                                                                                           2036 |     0,                                          /* tp_alloc */
     2037 |     0,                                          /* tp_new */                                                                                             2037 |     0,                                          /* tp_new */
     2038 | };                                                                                                                                                       2038 | };
"Objects/genobject.c", line 2038.1: 1506-447 (I) The member(s) starting from "tp_free" will be initialized with a default value of 0.                           "Objects/genobject.c", line 2038.1: 1506-447 (I) The member(s) starting from "tp_free" will be initialized with a default value of 0.
     2039 |                                                                                                                                                          2039 |
     2040 |                                                                                                                                                          2040 |
     2041 | static PyObject *                                                                                                                                        2041 | static PyObject *
     2042 | async_gen_athrow_new(PyAsyncGenObject *gen, PyObject *args)                                                                                              2042 | async_gen_athrow_new(PyAsyncGenObject *gen, PyObject *args)
     2043 | {                                                                                                                                                        2043 | {
     2044 |     PyAsyncGenAThrow *o;                                                                                                                                 2044 |     PyAsyncGenAThrow *o;
     2045 |     o = PyObject_GC_New(PyAsyncGenAThrow, &_PyAsyncGenAThrow_Type);                                                                                      2045 |     o = PyObject_GC_New(PyAsyncGenAThrow, &_PyAsyncGenAThrow_Type);
     2045 +     o = ( (PyAsyncGenAThrow *) _PyObject_GC_New(&_PyAsyncGenAThrow_Type) );                                                                              2045 +     o = ( (PyAsyncGenAThrow *) _PyObject_GC_New(&_PyAsyncGenAThrow_Type) );
"Objects/genobject.c", line 2045.9: 1506-495 (I) Pointer type conversion found.                                                                                 "Objects/genobject.c", line 2045.9: 1506-495 (I) Pointer type conversion found.
"Objects/genobject.c", line 2045.9: 1506-374 (I) Pointer types "struct {...}*" and "struct _object*" are not compatible.                                        "Objects/genobject.c", line 2045.9: 1506-374 (I) Pointer types "struct {...}*" and "struct _object*" are not compatible.







Wed Apr 15 07:30:04 CDT 2020  Page 53


     2046 |     if (o == NULL) {                                                                                                                                     2046 |     if (o == NULL) {
     2046 +     if (o == 0) {                                                                                                                                        2046 +     if (o == 0) {
     2047 |         return NULL;                                                                                                                                     2047 |         return NULL;
     2047 +         return 0;                                                                                                                                        2047 +         return 0;
     2048 |     }                                                                                                                                                    2048 |     }
     2049 |     o->agt_gen = gen;                                                                                                                                    2049 |     o->agt_gen = gen;
     2050 |     o->agt_args = args;                                                                                                                                  2050 |     o->agt_args = args;
     2051 |     o->agt_state = AWAITABLE_STATE_INIT;                                                                                                                 2051 |     o->agt_state = AWAITABLE_STATE_INIT;
     2052 |     Py_INCREF(gen);                                                                                                                                      2052 |     Py_INCREF(gen);
     2052 +     _Py_INCREF(((PyObject*)(gen)));                                                                                                                      2052 +     _Py_INCREF(((PyObject*)(gen)));
"Objects/genobject.c", line 2052.5: 1506-495 (I) Pointer type conversion found.                                                                                 "Objects/genobject.c", line 2052.5: 1506-495 (I) Pointer type conversion found.
"Objects/genobject.c", line 2052.5: 1506-374 (I) Pointer types "struct _object*" and "struct {...}*" are not compatible.                                        "Objects/genobject.c", line 2052.5: 1506-374 (I) Pointer types "struct _object*" and "struct {...}*" are not compatible.
     2053 |     Py_XINCREF(args);                                                                                                                                    2053 |     Py_XINCREF(args);
     2053 +     _Py_XINCREF(((PyObject*)(args)));                                                                                                                    2053 +     _Py_XINCREF(((PyObject*)(args)));
     2054 |     _PyObject_GC_TRACK((PyObject*)o);                                                                                                                    2054 |     _PyObject_GC_TRACK((PyObject*)o);
     2054 +     _PyObject_GC_TRACK_impl("Objects/genobject.c", 2054, ((PyObject*)((PyObject*)o)));                                                                   2054 +     _PyObject_GC_TRACK_impl("Objects/genobject.c", 2054, ((PyObject*)((PyObject*)o)));
"Objects/genobject.c", line 2054.5: 1506-495 (I) Pointer type conversion found.                                                                                 "Objects/genobject.c", line 2054.5: 1506-495 (I) Pointer type conversion found.
"Objects/genobject.c", line 2054.5: 1506-374 (I) Pointer types "struct _object*" and "struct {...}*" are not compatible.                                        "Objects/genobject.c", line 2054.5: 1506-374 (I) Pointer types "struct _object*" and "struct {...}*" are not compatible.
     2055 |     return (PyObject*)o;                                                                                                                                 2055 |     return (PyObject*)o;
"Objects/genobject.c", line 2055.12: 1506-495 (I) Pointer type conversion found.                                                                                "Objects/genobject.c", line 2055.12: 1506-495 (I) Pointer type conversion found.
"Objects/genobject.c", line 2055.12: 1506-374 (I) Pointer types "struct _object*" and "struct {...}*" are not compatible.                                       "Objects/genobject.c", line 2055.12: 1506-374 (I) Pointer types "struct _object*" and "struct {...}*" are not compatible.
     2056 | }                                                                                                                                                        2056 | }
"Objects/genobject.c", line 2056.1: 1506-412 (I) Referenced variable "o", which was not initialized in its declaration.                                         "Objects/genobject.c", line 2056.1: 1506-412 (I) Referenced variable "o", which was not initialized in its declaration.
"Objects/genobject.c", line 2056.1: 1506-415 (I) The external function definition "_PyAsyncGen_Fini" is never referenced.                                       "Objects/genobject.c", line 2056.1: 1506-415 (I) The external function definition "_PyAsyncGen_Fini" is never referenced.
"Objects/genobject.c", line 2056.1: 1506-469 (I) The static function "_PyType_HasFeature" is declared or defined but never referenced.                          "Objects/genobject.c", line 2056.1: 1506-469 (I) The static function "_PyType_HasFeature" is declared or defined but never referenced.
"Objects/genobject.c", line 2056.1: 1506-469 (I) The static function "_PyObject_GET_WEAKREFS_LISTPTR" is declared or defined but never referenced.              "Objects/genobject.c", line 2056.1: 1506-469 (I) The static function "_PyObject_GET_WEAKREFS_LISTPTR" is declared or defined but never referenced.
"Objects/genobject.c", line 2056.1: 1506-469 (I) The static function "_Py_LeaveRecursiveCall_inline" is declared or defined but never referenced.               "Objects/genobject.c", line 2056.1: 1506-469 (I) The static function "_Py_LeaveRecursiveCall_inline" is declared or defined but never referenced.
"Objects/genobject.c", line 2056.1: 1506-469 (I) The static function "_Py_EnterRecursiveCall_inline" is declared or defined but never referenced.               "Objects/genobject.c", line 2056.1: 1506-469 (I) The static function "_Py_EnterRecursiveCall_inline" is declared or defined but never referenced.
"Objects/genobject.c", line 2056.1: 1506-469 (I) The static function "_PyInterpreterState_GET_UNSAFE" is declared or defined but never referenced.              "Objects/genobject.c", line 2056.1: 1506-469 (I) The static function "_PyInterpreterState_GET_UNSAFE" is declared or defined but never referenced.
"Objects/genobject.c", line 2056.1: 1506-469 (I) The static function "_Py_ThreadCanHandlePendingCalls" is declared or defined but never referenced.             "Objects/genobject.c", line 2056.1: 1506-469 (I) The static function "_Py_ThreadCanHandlePendingCalls" is declared or defined but never referenced.
"Objects/genobject.c", line 2056.1: 1506-469 (I) The static function "_Py_ThreadCanHandleSignals" is declared or defined but never referenced.                  "Objects/genobject.c", line 2056.1: 1506-469 (I) The static function "_Py_ThreadCanHandleSignals" is declared or defined but never referenced.
"Objects/genobject.c", line 2056.1: 1506-469 (I) The static function "_Py_IsMainInterpreter" is declared or defined but never referenced.                       "Objects/genobject.c", line 2056.1: 1506-469 (I) The static function "_Py_IsMainInterpreter" is declared or defined but never referenced.
"Objects/genobject.c", line 2056.1: 1506-469 (I) The static function "_PyRuntimeState_SetFinalizing" is declared or defined but never referenced.               "Objects/genobject.c", line 2056.1: 1506-469 (I) The static function "_PyRuntimeState_SetFinalizing" is declared or defined but never referenced.
"Objects/genobject.c", line 2056.1: 1506-469 (I) The static function "_PyRuntimeState_GetFinalizing" is declared or defined but never referenced.               "Objects/genobject.c", line 2056.1: 1506-469 (I) The static function "_PyRuntimeState_GetFinalizing" is declared or defined but never referenced.
"Objects/genobject.c", line 2056.1: 1506-469 (I) The static function "_PyMem_IsPtrFreed" is declared or defined but never referenced.                           "Objects/genobject.c", line 2056.1: 1506-469 (I) The static function "_PyMem_IsPtrFreed" is declared or defined but never referenced.
"Objects/genobject.c", line 2056.1: 1506-469 (I) The static function "_PyObject_CallMethodIdOneArg" is declared or defined but never referenced.                "Objects/genobject.c", line 2056.1: 1506-469 (I) The static function "_PyObject_CallMethodIdOneArg" is declared or defined but never referenced.
"Objects/genobject.c", line 2056.1: 1506-469 (I) The static function "_PyObject_CallMethodIdNoArgs" is declared or defined but never referenced.                "Objects/genobject.c", line 2056.1: 1506-469 (I) The static function "_PyObject_CallMethodIdNoArgs" is declared or defined but never referenced.
"Objects/genobject.c", line 2056.1: 1506-469 (I) The static function "PyObject_CallMethodOneArg" is declared or defined but never referenced.                   "Objects/genobject.c", line 2056.1: 1506-469 (I) The static function "PyObject_CallMethodOneArg" is declared or defined but never referenced.
"Objects/genobject.c", line 2056.1: 1506-469 (I) The static function "PyObject_CallMethodNoArgs" is declared or defined but never referenced.                   "Objects/genobject.c", line 2056.1: 1506-469 (I) The static function "PyObject_CallMethodNoArgs" is declared or defined but never referenced.
"Objects/genobject.c", line 2056.1: 1506-469 (I) The static function "_PyObject_FastCall" is declared or defined but never referenced.                          "Objects/genobject.c", line 2056.1: 1506-469 (I) The static function "_PyObject_FastCall" is declared or defined but never referenced.
"Objects/genobject.c", line 2056.1: 1506-469 (I) The static function "PyObject_Vectorcall" is declared or defined but never referenced.                         "Objects/genobject.c", line 2056.1: 1506-469 (I) The static function "PyObject_Vectorcall" is declared or defined but never referenced.
"Objects/genobject.c", line 2056.1: 1506-415 (I) The external function definition "_PyAsyncGenValueWrapperNew" is never referenced.                             "Objects/genobject.c", line 2056.1: 1506-415 (I) The external function definition "_PyAsyncGenValueWrapperNew" is never referenced.
"Objects/genobject.c", line 2056.1: 1506-415 (I) The external function definition "PyAsyncGen_New" is never referenced.                                         "Objects/genobject.c", line 2056.1: 1506-415 (I) The external function definition "PyAsyncGen_New" is never referenced.
"Objects/genobject.c", line 2056.1: 1506-415 (I) The external function definition "PyCoro_New" is never referenced.                                             "Objects/genobject.c", line 2056.1: 1506-415 (I) The external function definition "PyCoro_New" is never referenced.
"Objects/genobject.c", line 2056.1: 1506-415 (I) The external function definition "_PyCoro_GetAwaitableIter" is never referenced.                               "Objects/genobject.c", line 2056.1: 1506-415 (I) The external function definition "_PyCoro_GetAwaitableIter" is never referenced.
"Objects/genobject.c", line 2056.1: 1506-415 (I) The external function definition "PyGen_NewWithQualName" is never referenced.                                  "Objects/genobject.c", line 2056.1: 1506-415 (I) The external function definition "PyGen_NewWithQualName" is never referenced.
"Objects/genobject.c", line 2056.1: 1506-415 (I) The external function definition "PyGen_New" is never referenced.                                              "Objects/genobject.c", line 2056.1: 1506-415 (I) The external function definition "PyGen_New" is never referenced.
"Objects/genobject.c", line 2056.1: 1506-469 (I) The static function "_PyObject_INIT_VAR" is declared or defined but never referenced.                          "Objects/genobject.c", line 2056.1: 1506-469 (I) The static function "_PyObject_INIT_VAR" is declared or defined but never referenced.
"Objects/genobject.c", line 2056.1: 1506-469 (I) The static function "_PyType_CheckExact" is declared or defined but never referenced.                          "Objects/genobject.c", line 2056.1: 1506-469 (I) The static function "_PyType_CheckExact" is declared or defined but never referenced.
"Objects/genobject.c", line 2056.1: 1506-469 (I) The static function "_Py_SET_REFCNT" is declared or defined but never referenced.                              "Objects/genobject.c", line 2056.1: 1506-469 (I) The static function "_Py_SET_REFCNT" is declared or defined but never referenced.

>>>>> OPTIONS SECTION <<<<<                                                                                                                                     >>>>> OPTIONS SECTION <<<<<

IBM XL C for AIX, Version 13.1.3.4                                                                                                                              IBM XL C for AIX, Version 16.1.0.3
***   Command Line Invocation ***                                                                                                                               ***   Command Line Invocation ***
***   Options In Effect   ***                                                                                                                                   ***   Options In Effect   ***







Wed Apr 15 07:30:04 CDT 2020  Page 54



CPLUSCMT            G                   LIST                SOURCE                                                                                              CPLUSCMT            G                   LIST                SOURCE
THREADED                                                                                                                                                        THREADED

OPTIMIZE=2                                                                                                                                                      OPTIMIZE=2
ALIAS=ANSI:NOTYPEPTR:NOALLPTRS:NOADDRTAKEN:RESTRICT:NOGLOBAL                                                                                                    ALIAS=ANSI:NOTYPEPTR:NOALLPTRS:NOADDRTAKEN:RESTRICT:NOGLOBAL
DEBUG=2                                                                                                                                                         DEBUG=2
INFO=CLS:CMP:CND:CNS:CNV:CPY:DCL:EFF:ENU:EXT:GEN:NOGNR:GOT:INI:LAN:OBS:ORD:PAR:POR:PPC:NOPPT:PRO:REA:RET:TRD:NOTRU:TRX:UND:UNI:USE:VFT:PRIVATE:REDUCTION:C99:NO INFO=CLS:CMP:CND:CNS:CNV:CPY:DCL:EFF:ENU:EXT:GEN:NOGNR:GOT:INI:LAN:OBS:ORD:PAR:POR:PPC:NOPPT:PRO:REA:RET:TRD:NOTRU:TRX:UND:UNI:USE:VFT:PRIVATE:REDUCTION:C99:NO
LANGLVL=EXTC99:UCS:NOTEXTAFTERENDIF                                                                                                                             LANGLVL=EXTC99:UCS:NOTEXTAFTERENDIF
LEAVES=abort                                                                                                                                                    LEAVES=abort
LEAVES=exit                                                                                                                                                     LEAVES=exit
LEAVES=_Exit                                                                                                                                                    LEAVES=_Exit
LEAVES=_PyObject_AssertFailed                                                                                                                                   LEAVES=_PyObject_AssertFailed
LEAVES=PyThread_exit_thread                                                                                                                                     LEAVES=PyThread_exit_thread
LEAVES=Py_FatalError                                                                                                                                            LEAVES=Py_FatalError
LEAVES=_Py_FatalErrorFunc                                                                                                                                       LEAVES=_Py_FatalErrorFunc
LEAVES=_Py_FatalErrorFormat                                                                                                                                     LEAVES=_Py_FatalErrorFormat
LEAVES=Py_Exit                                                                                                                                                  LEAVES=Py_Exit
LEAVES=Py_ExitStatusException                                                                                                                                   LEAVES=Py_ExitStatusException



>>>>> FILE TABLE SECTION <<<<<                                                                                                                                  >>>>> FILE TABLE SECTION <<<<<

                                       FILE CREATION        FROM                                                                                                                                       FILE CREATION        FROM
FILE NO   FILENAME                    DATE       TIME       FILE    LINE                                                                                        FILE NO   FILENAME                    DATE       TIME       FILE    LINE
     0    Objects/genobject.c         04/15/20   03:29:35                                                                                                            0    Objects/genobject.c         04/15/20   03:29:35
     1    ./Include/Python.h          04/13/20   06:30:41      0       3                                                                                             1    ./Include/Python.h          04/13/20   06:30:41      0       3
     2    ./Include/patchlevel.h      03/30/20   03:25:21      1       7                                                                                             2    ./Include/patchlevel.h      03/30/20   03:25:21      1       7
     3    ./pyconfig.h                04/13/20   06:35:05      1       8                                                                                             3    ./pyconfig.h                04/13/20   06:35:05      1       8
     4    ./Include/pymacconfig.h     10/01/18   11:15:51      1       9                                                                                             4    ./Include/pymacconfig.h     10/01/18   11:15:51      1       9
     5    /usr/include/limits.h       09/17/14   19:01:41      1      11                                                                                             5    /usr/include/limits.h       09/17/14   19:01:41      1      11
     6    /usr/include/sys/limits.h   09/17/14   19:01:41      5      30                                                                                             6    /usr/include/sys/limits.h   09/17/14   19:01:41      5      30
     7    /usr/include/standards.h    09/17/14   19:01:48      6      39                                                                                             7    /usr/include/standards.h    09/17/14   19:01:48      6      39
     8    /usr/include/float.h        09/17/14   19:01:36      6     306                                                                                             8    /usr/include/float.h        09/17/14   19:01:36      6     306
     9    /usr/include/stdio.h        09/17/14   19:01:49      1      25                                                                                             9    /usr/include/stdio.h        09/17/14   19:01:49      1      25
    10    /usr/include/va_list.h      09/17/14   19:02:11      9     201                                                                                            10    /usr/include/va_list.h      09/17/14   19:02:11      9     201
    11    /usr/include/sys/types.h    11/04/14   11:49:54      9     477                                                                                            11    /usr/include/sys/types.h    11/04/14   11:49:54      9     477
    12    /usr/include/strict_stdtypes.h                                                                                                                            12    /usr/include/strict_stdtypes.h
                                      09/17/14   19:04:25     11      58                                                                                                                              09/17/14   19:04:25     11      58
    13    /usr/include/sys/inttypes.h 09/17/14   19:03:04     11      61                                                                                            13    /usr/include/sys/inttypes.h 09/17/14   19:03:04     11      61
    14    /usr/include/stdint.h       07/29/14   13:32:39     13      51                                                                                            14    /usr/include/stdint.h       07/29/14   13:32:39     13      51
    15    /usr/include/end_strict_stdtypes.h                                                                                                                        15    /usr/include/end_strict_stdtypes.h
                                      09/17/14   19:04:25     11      64                                                                                                                              09/17/14   19:04:25     11      64
    16    /usr/include/sys/m_types.h  09/17/14   19:01:42     11     485                                                                                            16    /usr/include/sys/m_types.h  09/17/14   19:01:42     11     485
    17    /usr/include/sys/vm_types.h 09/17/14   19:03:22     16      40                                                                                            17    /usr/include/sys/vm_types.h 09/17/14   19:03:22     16      40
    18    /opt/IBM/xlc/13.1.3/include/string.h                                                                                                                      18    /opt/IBM/xlc/16.1.0/include/string.h
                                      05/30/16   15:42:57      1      30                                                                                                                              10/30/18   23:03:26      1      30
    19    /usr/include/string.h       09/17/14   19:01:49     18      60                                                                                            19    /usr/include/string.h       09/17/14   19:01:49     18      60
    20    /usr/include/errno.h        09/17/14   19:01:35      1      32                                                                                            20    /usr/include/errno.h        09/17/14   19:01:35      1      32
    21    /opt/IBM/xlc/13.1.3/include/stdlib.h                                                                                                                      21    /opt/IBM/xlc/16.1.0/include/stdlib.h
                                      05/30/16   15:42:57      1      34                                                                                                                              10/30/18   23:03:26      1      34
    22    /usr/include/stdlib.h       09/17/14   19:01:49     21      21                                                                                            22    /usr/include/stdlib.h       09/17/14   19:01:49     21      21
    23    /usr/include/sys/wait.h     09/17/14   19:01:54     22     355                                                                                            23    /usr/include/sys/wait.h     09/17/14   19:01:54     22     355
    24    /usr/include/end_strict_stdtypes.h                                                                                                                        24    /usr/include/end_strict_stdtypes.h
                                      09/17/14   19:04:25     23      39                                                                                                                              09/17/14   19:04:25     23      39







Wed Apr 15 07:30:04 CDT 2020  Page 55


    25    /usr/include/sys/resource.h 09/17/14   19:01:46     23      47                                                                                            25    /usr/include/sys/resource.h 09/17/14   19:01:46     23      47
    26    /usr/include/sys/time.h     08/11/15   10:55:54     25      57                                                                                            26    /usr/include/sys/time.h     08/11/15   10:55:54     25      57
    27    /usr/include/sys/signal.h   11/04/14   11:49:54     23      50                                                                                            27    /usr/include/sys/signal.h   11/04/14   11:49:54     23      50
    28    /usr/include/sys/context.h  08/26/14   11:45:08     27     363                                                                                            28    /usr/include/sys/context.h  08/26/14   11:45:08     27     363
    29    /usr/include/sys/m_param.h  09/17/14   19:01:42     28      39                                                                                            29    /usr/include/sys/m_param.h  09/17/14   19:01:42     28      39
    30    /usr/include/sys/mstsave.h  03/03/15   13:33:39     28      40                                                                                            30    /usr/include/sys/mstsave.h  03/03/15   13:33:39     28      40
    31    /usr/include/sys/m_signal.h 09/17/14   19:03:25     27     638                                                                                            31    /usr/include/sys/m_signal.h 09/17/14   19:03:25     27     638
    32    /usr/include/sys/localedef.h                                                                                                                              32    /usr/include/sys/localedef.h
                                      09/17/14   19:01:41     22     617                                                                                                                              09/17/14   19:01:41     22     617
    33    /usr/include/sys/lc_core.h  09/17/14   19:01:40     32      42                                                                                            33    /usr/include/sys/lc_core.h  09/17/14   19:01:40     32      42
    34    /usr/include/locale.h       09/17/14   19:01:41     32      43                                                                                            34    /usr/include/locale.h       09/17/14   19:01:41     32      43
    35    /usr/include/sys/localedef31.h                                                                                                                            35    /usr/include/sys/localedef31.h
                                      09/17/14   19:01:41     32      45                                                                                                                              09/17/14   19:01:41     32      45
    36    /usr/include/unistd.h       07/23/18   10:18:40      1      36                                                                                            36    /usr/include/unistd.h       07/23/18   10:18:40      1      36
    37    /usr/include/end_strict_stdtypes.h                                                                                                                        37    /usr/include/end_strict_stdtypes.h
                                      09/17/14   19:04:25     36      55                                                                                                                              09/17/14   19:04:25     36      55
    38    /usr/include/sys/access.h   09/17/14   19:01:28     36      58                                                                                            38    /usr/include/sys/access.h   09/17/14   19:01:28     36      58
    39    /usr/include/sys/lockf.h    09/17/14   19:01:41     36     847                                                                                            39    /usr/include/sys/lockf.h    09/17/14   19:01:41     36     847
    40    /usr/include/sys/stat.h     09/17/14   19:01:48     39      45                                                                                            40    /usr/include/sys/stat.h     09/17/14   19:01:48     39      45
    41    /usr/include/end_strict_stdtypes.h                                                                                                                        41    /usr/include/end_strict_stdtypes.h
                                      09/17/14   19:04:25     40      43                                                                                                                              09/17/14   19:04:25     40      43
    42    /usr/include/sys/mode.h     09/17/14   19:01:42     40      51                                                                                            42    /usr/include/sys/mode.h     09/17/14   19:01:42     40      51
    43    /usr/include/crypt.h        09/17/14   19:02:17      1      44                                                                                            43    /usr/include/crypt.h        09/17/14   19:02:17      1      44
    44    /opt/IBM/xlc/13.1.3/include/assert.h                                                                                                                      44    /opt/IBM/xlc/16.1.0/include/assert.h
                                      04/19/17   13:51:06      1      61                                                                                                                              05/27/19   14:26:41      1      61
    45    /usr/include/assert.h       09/17/14   19:01:29     44      12                                                                                            45    /usr/include/assert.h       09/17/14   19:01:29     44      12
    46    ./Include/pyport.h          04/10/20   06:28:09      1      63                                                                                            46    ./Include/pyport.h          04/10/20   06:28:09      1      63
    47    /usr/include/inttypes.h     09/17/14   19:03:04     46       6                                                                                            47    /usr/include/inttypes.h     09/17/14   19:03:04     46       6
    48    /opt/IBM/xlc/13.1.3/include/math.h                                                                                                                        48    /opt/IBM/xlc/16.1.0/include/math.h
                                      04/19/17   13:51:06     46     205                                                                                                                              05/27/19   14:26:41     46     205
    49    /usr/include/math.h         04/01/15   15:50:51     48      18                                                                                            49    /usr/include/math.h         04/01/15   15:50:51     48      18
    50    /usr/include/time.h         09/17/14   19:01:52     46     213                                                                                            50    /usr/include/time.h         09/17/14   19:01:52     46     213
    51    /usr/include/end_strict_stdtypes.h                                                                                                                        51    /usr/include/end_strict_stdtypes.h
                                      09/17/14   19:04:25     50     180                                                                                                                              09/17/14   19:04:25     50     180
    52    /usr/include/stddef.h       09/17/14   19:01:49     50     260                                                                                            52    /usr/include/stddef.h       09/17/14   19:01:49     50     260
    53    /usr/include/sys/select.h   09/17/14   19:01:47     46     230                                                                                            53    /usr/include/sys/select.h   09/17/14   19:01:47     46     230
    54    /usr/include/sys/termio.h   09/17/14   19:01:51     46     576                                                                                            54    /usr/include/sys/termio.h   09/17/14   19:01:51     46     576
    55    /usr/include/sys/ioctl.h    09/17/14   19:01:39     54      36                                                                                            55    /usr/include/sys/ioctl.h    09/17/14   19:01:39     54      36
    56    /usr/include/sys/ttychars.h 09/17/14   19:01:52     55      60                                                                                            56    /usr/include/sys/ttychars.h 09/17/14   19:01:52     55      60
    57    /usr/include/sys/ttydev.h   09/17/14   19:01:52     55      61                                                                                            57    /usr/include/sys/ttydev.h   09/17/14   19:01:52     55      61
    58    /usr/include/sys/ttmap.h    09/17/14   19:01:52     54      37                                                                                            58    /usr/include/sys/ttmap.h    09/17/14   19:01:52     54      37
    59    /usr/include/termios.h      09/17/14   19:01:51     54      40                                                                                            59    /usr/include/termios.h      09/17/14   19:01:51     54      40
    60    /usr/include/end_strict_stdtypes.h                                                                                                                        60    /usr/include/end_strict_stdtypes.h
                                      09/17/14   19:04:25     59      47                                                                                                                              09/17/14   19:04:25     59      47
    61    ./Include/exports.h         11/18/19   01:52:30     46     641                                                                                            61    ./Include/exports.h         11/18/19   01:52:30     46     641
    62    ./Include/pymacro.h         03/11/20   13:49:35      1      64                                                                                            62    ./Include/pymacro.h         03/11/20   13:49:35      1      64
    63    ./Include/pymath.h          03/11/20   12:55:16      1      84                                                                                            63    ./Include/pymath.h          03/11/20   12:55:16      1      84
    64    ./Include/pytime.h          11/18/19   01:51:38      1      85                                                                                            64    ./Include/pytime.h          11/18/19   01:51:38      1      85
    65    ./Include/object.h          04/13/20   06:30:42     64       6                                                                                            65    ./Include/object.h          04/13/20   06:30:42     64       6
    66    ./Include/cpython/object.h  03/30/20   03:25:21     65     610                                                                                            66    ./Include/cpython/object.h  03/30/20   03:25:21     65     610
    67    ./Include/pymem.h           03/11/20   12:55:16      1      86                                                                                            67    ./Include/pymem.h           03/11/20   12:55:16      1      86
    68    ./Include/cpython/pymem.h   09/07/19   07:47:00     67     107                                                                                            68    ./Include/cpython/pymem.h   09/07/19   07:47:00     67     107
    69    ./Include/objimpl.h         04/13/20   06:30:42      1      89                                                                                            69    ./Include/objimpl.h         04/13/20   06:30:42      1      89
    70    ./Include/cpython/objimpl.h 04/13/20   06:30:41     69     208                                                                                            70    ./Include/cpython/objimpl.h 04/13/20   06:30:41     69     208
    71    ./Include/typeslots.h       10/01/18   11:15:52      1      90                                                                                            71    ./Include/typeslots.h       10/01/18   11:15:52      1      90
    72    ./Include/pyhash.h          03/11/20   12:55:16      1      91                                                                                            72    ./Include/pyhash.h          03/11/20   12:55:16      1      91







Wed Apr 15 07:30:04 CDT 2020  Page 56


    73    ./Include/pydebug.h         10/01/18   11:15:51      1      93                                                                                            73    ./Include/pydebug.h         10/01/18   11:15:51      1      93
    74    ./Include/bytearrayobject.h 03/11/20   12:55:14      1      95                                                                                            74    ./Include/bytearrayobject.h 03/11/20   12:55:14      1      95
    75    /opt/IBM/xlc/13.1.3/include/stdarg.h                                                                                                                      75    /opt/IBM/xlc/16.1.0/include/stdarg.h
                                      04/19/17   13:51:06     74       9                                                                                                                              05/27/19   14:26:41     74       9
    76    /usr/include/stdarg.h       09/17/14   19:03:25     75      12                                                                                            76    /usr/include/stdarg.h       09/17/14   19:03:25     75      12
    77    ./Include/cpython/bytearrayobject.h                                                                                                                       77    ./Include/cpython/bytearrayobject.h
                                      03/11/20   12:55:14     74      39                                                                                                                              03/11/20   12:55:14     74      39
    78    ./Include/bytesobject.h     03/11/20   12:55:14      1      96                                                                                            78    ./Include/bytesobject.h     03/11/20   12:55:14      1      96
    79    /opt/IBM/xlc/13.1.3/include/stdarg.h                                                                                                                      79    /opt/IBM/xlc/16.1.0/include/stdarg.h
                                      04/19/17   13:51:06     78      10                                                                                                                              05/27/19   14:26:41     78      10
    80    ./Include/cpython/bytesobject.h                                                                                                                           80    ./Include/cpython/bytesobject.h
                                      03/11/20   12:55:14     78      75                                                                                                                              03/11/20   12:55:14     78      75
    81    ./Include/unicodeobject.h   03/11/20   12:55:17      1      97                                                                                            81    ./Include/unicodeobject.h   03/11/20   12:55:17      1      97
    82    /opt/IBM/xlc/13.1.3/include/stdarg.h                                                                                                                      82    /opt/IBM/xlc/16.1.0/include/stdarg.h
                                      04/19/17   13:51:06     81       4                                                                                                                              05/27/19   14:26:41     81       4
    83    /usr/include/ctype.h        09/17/14   19:01:32     81      58                                                                                            83    /usr/include/ctype.h        09/17/14   19:01:32     81      58
    84    /usr/include/wchar.h        09/17/14   19:01:54     81      97                                                                                            84    /usr/include/wchar.h        09/17/14   19:01:54     81      97
    85    /usr/include/end_strict_stdtypes.h                                                                                                                        85    /usr/include/end_strict_stdtypes.h
                                      09/17/14   19:04:25     84      44                                                                                                                              09/17/14   19:04:25     84      44
    86    ./Include/cpython/unicodeobject.h                                                                                                                         86    ./Include/cpython/unicodeobject.h
                                      04/13/20   06:30:26     81    1026                                                                                                                              04/13/20   06:30:26     81    1026
    87    ./Include/longobject.h      03/11/20   12:55:16      1      98                                                                                            87    ./Include/longobject.h      03/11/20   12:55:16      1      98
    88    ./Include/longintrepr.h     10/01/18   11:15:51      1      99                                                                                            88    ./Include/longintrepr.h     10/01/18   11:15:51      1      99
    89    ./Include/boolobject.h      03/11/20   12:55:13      1     100                                                                                            89    ./Include/boolobject.h      03/11/20   12:55:13      1     100
    90    ./Include/floatobject.h     03/11/20   12:55:15      1     101                                                                                            90    ./Include/floatobject.h     03/11/20   12:55:15      1     101
    91    ./Include/complexobject.h   03/11/20   12:55:14      1     102                                                                                            91    ./Include/complexobject.h   03/11/20   12:55:14      1     102
    92    ./Include/rangeobject.h     03/11/20   12:55:17      1     103                                                                                            92    ./Include/rangeobject.h     03/11/20   12:55:17      1     103
    93    ./Include/memoryobject.h    03/11/20   12:55:16      1     104                                                                                            93    ./Include/memoryobject.h    03/11/20   12:55:16      1     104
    94    ./Include/tupleobject.h     03/11/20   12:55:17      1     105                                                                                            94    ./Include/tupleobject.h     03/11/20   12:55:17      1     105
    95    ./Include/cpython/tupleobject.h                                                                                                                           95    ./Include/cpython/tupleobject.h
                                      09/07/19   07:47:00     94      41                                                                                                                              09/07/19   07:47:00     94      41
    96    ./Include/listobject.h      03/11/20   12:55:16      1     106                                                                                            96    ./Include/listobject.h      03/11/20   12:55:16      1     106
    97    ./Include/cpython/listobject.h                                                                                                                            97    ./Include/cpython/listobject.h
                                      03/11/20   12:55:14     96      45                                                                                                                              03/11/20   12:55:14     96      45
    98    ./Include/dictobject.h      03/11/20   12:55:15      1     107                                                                                            98    ./Include/dictobject.h      03/11/20   12:55:15      1     107
    99    ./Include/cpython/dictobject.h                                                                                                                            99    ./Include/cpython/dictobject.h
                                      09/07/19   07:47:00     98      87                                                                                                                              09/07/19   07:47:00     98      87
   100    ./Include/odictobject.h     03/11/20   12:55:16      1     108                                                                                           100    ./Include/odictobject.h     03/11/20   12:55:16      1     108
   101    ./Include/enumobject.h      10/01/18   11:15:50      1     109                                                                                           101    ./Include/enumobject.h      10/01/18   11:15:50      1     109
   102    ./Include/setobject.h       03/11/20   12:55:17      1     110                                                                                           102    ./Include/setobject.h       03/11/20   12:55:17      1     110
   103    ./Include/methodobject.h    03/11/20   12:55:16      1     111                                                                                           103    ./Include/methodobject.h    03/11/20   12:55:16      1     111
   104    ./Include/moduleobject.h    03/11/20   12:55:16      1     112                                                                                           104    ./Include/moduleobject.h    03/11/20   12:55:16      1     112
   105    ./Include/funcobject.h      03/11/20   12:55:15      1     113                                                                                           105    ./Include/funcobject.h      03/11/20   12:55:15      1     113
   106    ./Include/classobject.h     03/11/20   12:55:14      1     114                                                                                           106    ./Include/classobject.h     03/11/20   12:55:14      1     114
   107    ./Include/fileobject.h      09/07/19   07:47:01      1     115                                                                                           107    ./Include/fileobject.h      09/07/19   07:47:01      1     115
   108    ./Include/cpython/fileobject.h                                                                                                                           108    ./Include/cpython/fileobject.h
                                      09/07/19   07:47:00    107      35                                                                                                                              09/07/19   07:47:00    107      35
   109    ./Include/pycapsule.h       03/11/20   12:55:16      1     116                                                                                           109    ./Include/pycapsule.h       03/11/20   12:55:16      1     116
   110    ./Include/traceback.h       03/11/20   12:55:17      1     117                                                                                           110    ./Include/traceback.h       03/11/20   12:55:17      1     117
   111    ./Include/cpython/traceback.h                                                                                                                            111    ./Include/cpython/traceback.h
                                      09/07/19   07:47:00    110      21                                                                                                                              09/07/19   07:47:00    110      21
   112    ./Include/sliceobject.h     03/11/20   12:55:17      1     118                                                                                           112    ./Include/sliceobject.h     03/11/20   12:55:17      1     118
   113    ./Include/cellobject.h      03/11/20   12:55:14      1     119                                                                                           113    ./Include/cellobject.h      03/11/20   12:55:14      1     119
   114    ./Include/iterobject.h      03/11/20   12:55:16      1     120                                                                                           114    ./Include/iterobject.h      03/11/20   12:55:16      1     120
   115    ./Include/genobject.h       03/11/20   12:55:15      1     121                                                                                           115    ./Include/genobject.h       03/11/20   12:55:15      1     121
   116    ./Include/pystate.h         04/10/20   06:13:07    115      11                                                                                           116    ./Include/pystate.h         04/10/20   06:13:07    115      11







Wed Apr 15 07:30:04 CDT 2020  Page 57


   117    ./Include/pythread.h        04/13/20   06:30:42    116      10                                                                                           117    ./Include/pythread.h        04/13/20   06:30:42    116      10
   118    /usr/include/pthread.h      10/15/14   15:50:20    117     128                                                                                           118    /usr/include/pthread.h      10/15/14   15:50:20    117     128
   119    /usr/include/end_strict_stdtypes.h                                                                                                                       119    /usr/include/end_strict_stdtypes.h
                                      09/17/14   19:04:25    118      59                                                                                                                              09/17/14   19:04:25    118      59
   120    /usr/include/sched.h        09/17/14   19:03:04    118      63                                                                                           120    /usr/include/sched.h        09/17/14   19:03:04    118      63
   121    /usr/include/sys/sched.h    09/17/14   19:01:47    120      51                                                                                           121    /usr/include/sys/sched.h    09/17/14   19:01:47    120      51
   122    /usr/include/sys/pri.h      03/18/15   14:13:22    121      38                                                                                           122    /usr/include/sys/pri.h      03/18/15   14:13:22    121      38
   123    /usr/include/sys/proc.h     03/18/15   14:13:22    122      43                                                                                           123    /usr/include/sys/proc.h     03/18/15   14:13:22    122      43
   124    /usr/include/sys/ptrace.h   01/06/15   11:00:18    123      42                                                                                           124    /usr/include/sys/ptrace.h   01/06/15   11:00:18    123      42
   125    /usr/include/sys/thread.h   10/01/15   00:49:23    124      28                                                                                           125    /usr/include/sys/thread.h   10/01/15   00:49:23    124      28
   126    /usr/include/sys/processor.h                                                                                                                             126    /usr/include/sys/processor.h
                                      09/17/14   19:02:22    125      35                                                                                                                              09/17/14   19:02:22    125      35
   127    /usr/include/sys/kerrno.h   09/30/15   15:12:50    126      33                                                                                           127    /usr/include/sys/kerrno.h   09/30/15   15:12:50    126      33
   128    /usr/include/sys/lock_def.h 11/04/14   11:49:54    125      36                                                                                           128    /usr/include/sys/lock_def.h 11/04/14   11:49:54    125      36
   129    /usr/include/sys/var.h      09/17/14   19:01:53    125      37                                                                                           129    /usr/include/sys/var.h      09/17/14   19:01:53    125      37
   130    /usr/include/sys/atomic_op.h                                                                                                                             130    /usr/include/sys/atomic_op.h
                                      09/17/14   19:02:22    125      38                                                                                                                              09/17/14   19:02:22    125      38
   131    /usr/include/sys/timer.h    09/17/14   19:01:52    125      41                                                                                           131    /usr/include/sys/timer.h    09/17/14   19:01:52    125      41
   132    /usr/include/sys/cred.h     09/17/14   19:01:32    125      42                                                                                           132    /usr/include/sys/cred.h     09/17/14   19:01:32    125      42
   133    /usr/include/sys/priv.h     09/21/15   13:15:06    132      46                                                                                           133    /usr/include/sys/priv.h     09/21/15   13:15:06    132      46
   134    /usr/include/sys/tcb.h      09/17/14   19:01:51    133      34                                                                                           134    /usr/include/sys/tcb.h      09/17/14   19:01:51    133      34
   135    /usr/include/sys/pcl.h      09/17/14   19:01:44    133      42                                                                                           135    /usr/include/sys/pcl.h      09/17/14   19:01:44    133      42
   136    /usr/include/sys/lockl.h    09/17/14   19:01:41    132      47                                                                                           136    /usr/include/sys/lockl.h    09/17/14   19:01:41    132      47
   137    /usr/include/sys/capabilities.h                                                                                                                          137    /usr/include/sys/capabilities.h
                                      09/17/14   19:03:39    132      48                                                                                                                              09/17/14   19:03:39    132      48
   138    /usr/include/sys/secattr.h  09/17/14   19:05:03    132      49                                                                                           138    /usr/include/sys/secattr.h  09/17/14   19:05:03    132      49
   139    /usr/include/sys/mac.h      09/17/14   19:05:01    138      37                                                                                           139    /usr/include/sys/mac.h      09/17/14   19:05:01    138      37
   140    /usr/include/sys/systemcfg.h                                                                                                                             140    /usr/include/sys/systemcfg.h
                                      09/17/14   19:03:22    139      45                                                                                                                              09/17/14   19:03:22    139      45
   141    /usr/include/sys/extendio.h 09/17/14   19:04:53    125      44                                                                                           141    /usr/include/sys/extendio.h 09/17/14   19:04:53    125      44
   142    /usr/include/sys/pri.h      03/18/15   14:13:22    123      46                                                                                           142    /usr/include/sys/pri.h      03/18/15   14:13:22    123      46
   143    /usr/include/sys/corralid.h 10/01/15   00:49:23    123      51                                                                                           143    /usr/include/sys/corralid.h 10/01/15   00:49:23    123      51
   144    ./Include/cpython/pystate.h 04/13/20   06:30:41    116     146                                                                                           144    ./Include/cpython/pystate.h 04/13/20   06:30:41    116     146
   145    ./Include/cpython/initconfig.h                                                                                                                           145    ./Include/cpython/initconfig.h
                                      03/11/20   12:55:14    144       9                                                                                                                              03/11/20   12:55:14    144       9
   146    ./Include/descrobject.h     09/07/19   07:47:00      1     122                                                                                           146    ./Include/descrobject.h     09/07/19   07:47:00      1     122
   147    ./Include/genericaliasobject.h                                                                                                                           147    ./Include/genericaliasobject.h
                                      04/13/20   06:30:41      1     123                                                                                                                              04/13/20   06:30:41      1     123
   148    ./Include/warnings.h        10/01/18   11:15:52      1     124                                                                                           148    ./Include/warnings.h        10/01/18   11:15:52      1     124
   149    ./Include/weakrefobject.h   03/11/20   12:55:17      1     125                                                                                           149    ./Include/weakrefobject.h   03/11/20   12:55:17      1     125
   150    ./Include/structseq.h       02/19/20   11:17:06      1     126                                                                                           150    ./Include/structseq.h       02/19/20   11:17:06      1     126
   151    ./Include/namespaceobject.h 10/01/18   11:15:51      1     127                                                                                           151    ./Include/namespaceobject.h 10/01/18   11:15:51      1     127
   152    ./Include/picklebufobject.h 03/11/20   12:55:16      1     128                                                                                           152    ./Include/picklebufobject.h 03/11/20   12:55:16      1     128
   153    ./Include/codecs.h          10/01/18   11:15:50      1     130                                                                                           153    ./Include/codecs.h          10/01/18   11:15:50      1     130
   154    ./Include/pyerrors.h        03/11/20   13:49:35      1     131                                                                                           154    ./Include/pyerrors.h        03/11/20   13:49:35      1     131
   155    /opt/IBM/xlc/13.1.3/include/stdarg.h                                                                                                                     155    /opt/IBM/xlc/16.1.0/include/stdarg.h
                                      04/19/17   13:51:06    154     324                                                                                                                              05/27/19   14:26:41    154     324
   156    ./Include/cpython/pyerrors.h                                                                                                                             156    ./Include/cpython/pyerrors.h
                                      03/30/20   03:25:21    154     332                                                                                                                              03/30/20   03:25:21    154     332
   157    ./Include/context.h         03/11/20   12:55:14      1     135                                                                                           157    ./Include/context.h         03/11/20   12:55:14      1     135
   158    ./Include/pyarena.h         10/01/18   11:15:51      1     137                                                                                           158    ./Include/pyarena.h         10/01/18   11:15:51      1     137
   159    ./Include/modsupport.h      03/30/20   03:25:21      1     138                                                                                           159    ./Include/modsupport.h      03/30/20   03:25:21      1     138
   160    /opt/IBM/xlc/13.1.3/include/stdarg.h                                                                                                                     160    /opt/IBM/xlc/16.1.0/include/stdarg.h
                                      04/19/17   13:51:06    159      10                                                                                                                              05/27/19   14:26:41    159      10
   161    ./Include/compile.h         03/30/20   03:25:21      1     139                                                                                           161    ./Include/compile.h         03/30/20   03:25:21      1     139
   162    ./Include/code.h            03/11/20   12:55:14    161       5                                                                                           162    ./Include/code.h            03/11/20   12:55:14    161       5







Wed Apr 15 07:30:04 CDT 2020  Page 58


   163    ./Include/pythonrun.h       09/07/19   07:47:02      1     140                                                                                           163    ./Include/pythonrun.h       09/07/19   07:47:02      1     140
   164    ./Include/pylifecycle.h     11/18/19   01:51:38      1     141                                                                                           164    ./Include/pylifecycle.h     11/18/19   01:51:38      1     141
   165    ./Include/cpython/pylifecycle.h                                                                                                                          165    ./Include/cpython/pylifecycle.h
                                      03/11/20   12:55:15    164      68                                                                                                                              03/11/20   12:55:15    164      68
   166    ./Include/ceval.h           03/11/20   15:39:24      1     142                                                                                           166    ./Include/ceval.h           03/11/20   15:39:24      1     142
   167    ./Include/cpython/ceval.h   04/10/20   06:13:07    166     157                                                                                           167    ./Include/cpython/ceval.h   04/10/20   06:13:07    166     157
   168    ./Include/sysmodule.h       09/07/19   07:47:02      1     143                                                                                           168    ./Include/sysmodule.h       09/07/19   07:47:02      1     143
   169    ./Include/cpython/sysmodule.h                                                                                                                            169    ./Include/cpython/sysmodule.h
                                      04/10/20   06:13:07    168      34                                                                                                                              04/10/20   06:13:07    168      34
   170    ./Include/osmodule.h        10/01/18   11:15:51      1     144                                                                                           170    ./Include/osmodule.h        10/01/18   11:15:51      1     144
   171    ./Include/intrcheck.h       09/07/19   07:47:01      1     145                                                                                           171    ./Include/intrcheck.h       09/07/19   07:47:01      1     145
   172    ./Include/import.h          03/11/20   12:55:15      1     146                                                                                           172    ./Include/import.h          03/11/20   12:55:15      1     146
   173    ./Include/cpython/import.h  09/07/19   07:47:00    172      91                                                                                           173    ./Include/cpython/import.h  09/07/19   07:47:00    172      91
   174    ./Include/abstract.h        11/18/19   01:52:30      1     148                                                                                           174    ./Include/abstract.h        11/18/19   01:52:30      1     148
   175    ./Include/cpython/abstract.h                                                                                                                             175    ./Include/cpython/abstract.h
                                      04/13/20   06:30:41    174     843                                                                                                                              04/13/20   06:30:41    174     843
   176    ./Include/bltinmodule.h     10/01/18   11:15:50      1     149                                                                                           176    ./Include/bltinmodule.h     10/01/18   11:15:50      1     149
   177    ./Include/eval.h            10/01/18   11:15:50      1     151                                                                                           177    ./Include/eval.h            10/01/18   11:15:50      1     151
   178    ./Include/pyctype.h         10/01/18   11:15:51      1     153                                                                                           178    ./Include/pyctype.h         10/01/18   11:15:51      1     153
   179    ./Include/pystrtod.h        10/01/18   11:15:51      1     154                                                                                           179    ./Include/pystrtod.h        10/01/18   11:15:51      1     154
   180    ./Include/pystrcmp.h        10/01/18   11:15:51      1     155                                                                                           180    ./Include/pystrcmp.h        10/01/18   11:15:51      1     155
   181    ./Include/fileutils.h       03/11/20   12:55:15      1     156                                                                                           181    ./Include/fileutils.h       03/11/20   12:55:15      1     156
   182    ./Include/cpython/fileutils.h                                                                                                                            182    ./Include/cpython/fileutils.h
                                      03/11/20   12:55:14    181      23                                                                                                                              03/11/20   12:55:14    181      23
   183    ./Include/pyfpe.h           03/11/20   12:55:16      1     157                                                                                           183    ./Include/pyfpe.h           03/11/20   12:55:16      1     157
   184    ./Include/tracemalloc.h     09/07/19   07:47:02      1     158                                                                                           184    ./Include/tracemalloc.h     09/07/19   07:47:02      1     158
   185    ./Include/internal/pycore_ceval.h                                                                                                                        185    ./Include/internal/pycore_ceval.h
                                      04/13/20   06:30:42      0       4                                                                                                                              04/13/20   06:30:42      0       4
   186    ./Include/internal/pycore_pystate.h                                                                                                                      186    ./Include/internal/pycore_pystate.h
                                      04/13/20   06:30:42    185      16                                                                                                                              04/13/20   06:30:42    185      16
   187    ./Include/internal/pycore_interp.h                                                                                                                       187    ./Include/internal/pycore_interp.h
                                      04/13/20   06:30:42    186      11                                                                                                                              04/13/20   06:30:42    186      11
   188    ./Include/internal/pycore_atomic.h                                                                                                                       188    ./Include/internal/pycore_atomic.h
                                      11/18/19   01:52:31    187      11                                                                                                                              11/18/19   01:52:31    187      11
   189    ./Include/dynamic_annotations.h                                                                                                                          189    ./Include/dynamic_annotations.h
                                      10/01/18   11:15:50    188      11                                                                                                                              10/01/18   11:15:50    188      11
   190    ./Include/internal/pycore_gil.h                                                                                                                          190    ./Include/internal/pycore_gil.h
                                      11/18/19   01:52:31    187      12                                                                                                                              11/18/19   01:52:31    187      12
   191    ./Include/internal/pycore_condvar.h                                                                                                                      191    ./Include/internal/pycore_condvar.h
                                      09/07/19   07:47:01    190      12                                                                                                                              09/07/19   07:47:01    190      12
   192    ./Include/internal/pycore_pymem.h                                                                                                                        192    ./Include/internal/pycore_pymem.h
                                      04/13/20   06:30:42    187      13                                                                                                                              04/13/20   06:30:42    187      13
   193    ./Include/internal/pycore_gc.h                                                                                                                           193    ./Include/internal/pycore_gc.h
                                      04/13/20   06:30:42    192      12                                                                                                                              04/13/20   06:30:42    192      12
   194    ./Include/internal/pycore_warnings.h                                                                                                                     194    ./Include/internal/pycore_warnings.h
                                      03/11/20   12:55:16    187      14                                                                                                                              03/11/20   12:55:16    187      14
   195    ./Include/internal/pycore_runtime.h                                                                                                                      195    ./Include/internal/pycore_runtime.h
                                      04/13/20   06:30:42    186      12                                                                                                                              04/13/20   06:30:42    186      12
   196    ./Include/internal/pycore_object.h                                                                                                                       196    ./Include/internal/pycore_object.h
                                      04/13/20   06:30:42      0       5                                                                                                                              04/13/20   06:30:42      0       5
   197    ./Include/frameobject.h     03/11/20   12:55:15      0       7                                                                                           197    ./Include/frameobject.h     03/11/20   12:55:15      0       7
   198    ./Include/cpython/frameobject.h                                                                                                                          198    ./Include/cpython/frameobject.h
                                      03/11/20   12:55:14    197      15                                                                                                                              03/11/20   12:55:14    197      15
   199    ./Include/structmember.h    10/01/18   11:15:51      0       8                                                                                           199    ./Include/structmember.h    10/01/18   11:15:51      0       8
   200    ./Include/opcode.h          03/11/20   12:55:16      0       9                                                                                           200    ./Include/opcode.h          03/11/20   12:55:16      0       9








Wed Apr 15 07:30:04 CDT 2020  Page 59



>>>>> COMPILATION EPILOGUE SECTION <<<<<                                                                                                                        >>>>> COMPILATION EPILOGUE SECTION <<<<<

IBM XL C/C++ Compilers Summary of Diagnosed Conditions                                                                                                          IBM XL C/C++ Compilers Summary of Diagnosed Conditions

TOTAL   UNRECOVERABLE  SEVERE       ERROR     WARNING    INFORMATIONAL                                                                                          TOTAL   UNRECOVERABLE  SEVERE       ERROR     WARNING    INFORMATIONAL
               (U)       (S)         (E)        (W)          (I)                                                                                                               (U)       (S)         (E)        (W)          (I)
  498           0         0           0          0          498                                                                                                   498           0         0           0          0          498


Source records read.........................................   53630                                                                                            Source records read.........................................   53630

1501-008  Compilation successful for file Objects/genobject.c. Object file created.                                                                             1501-008  Compilation successful for file Objects/genobject.c. Object file created.


>>>>> OBJECT SECTION, OPTIMIZATION <<<<<                                                                                                                        >>>>> OBJECT SECTION, OPTIMIZATION <<<<<


 GPR's set/used:   s-us ss-- ---- ----  ---- ---- ---- ----                                                                                                      GPR's set/used:   s-us ss-- ---- ----  ---- ---- ---- ----
 FPR's set/used:   ---- ---- ---- ----  ---- ---- ---- ----                                                                                                      FPR's set/used:   ---- ---- ---- ----  ---- ---- ---- ----
 CCR's set/used:   ---- ----                                                                                                                                     CCR's set/used:   ---- ----
     | 000000                             PDEF     async_gen_athrow_close                                                                                            | 000000                             PDEF       async_gen_athrow_close
 1976|                                    PROC      o,args,gr3,gr4                                                                                               1976|                                    PROC       o,args,gr3,gr4
 1978| 000000 addi       38000002   1     LI        gr0=2                                                                                                        1978| 000000 addi       38000002   1     LI         gr0=2
  401| 000004 lwz        80A20004   1     L4A       gr5=._Py_RefTotal(gr2,0)                                                                                      401| 000004 lwz        80A20004   1     L4A        gr5=._Py_RefTotal(gr2,0)
 1978| 000008 stw        90030010   1     ST4A      (*)aggr#E.agt_state(gr3,16)=gr0                                                                              1978| 000008 stw        90030010   1     ST4A       (*)aggr#E.agt_state(gr3,16)=gr0
 1979| 00000C lwz        80620008   1     L4A       gr3=._Py_NoneStruct(gr2,0)                                                                                   1979| 00000C lwz        80620008   1     L4A        gr3=._Py_NoneStruct(gr2,0)
  401| 000010 lwz        80850000   1     L4A       gr4=<s117:d0:l4>(gr5,0)                                                                                       401| 000010 lwz        80850000   1     L4A        gr4=_Py_RefTotal(gr5,0)
  401| 000014 addi       38040001   2     AI        gr0=gr4,1                                                                                                     401| 000014 addi       38040001   2     AI         gr0=gr4,1
  401| 000018 stw        90050000   1     ST4A      <s117:d0:l4>(gr5,0)=gr0                                                                                       401| 000018 stw        90050000   1     ST4A       _Py_RefTotal(gr5,0)=gr0
  403| 00001C lwz        80830000   1     L4A       gr4=<s119:d0:l4>(gr3,0)                                                                                       403| 00001C lwz        80830000   1     L4A        gr4=_Py_NoneStruct%##1(gr3,0)
  403| 000020 addi       38040001   2     AI        gr0=gr4,1                                                                                                     403| 000020 addi       38040001   2     AI         gr0=gr4,1
  403| 000024 stw        90030000   1     ST4A      <s119:d0:l4>(gr3,0)=gr0                                                                                       403| 000024 stw        90030000   1     ST4A       _Py_NoneStruct%##1(gr3,0)=gr0
 1980| 000028 bclr       4E800020   0     BA        lr                                                                                                           1980| 000028 bclr       4E800020   0     BA         lr
     |               Tag Table                                                                                                                                       |               Tag Table
     | 00002C        00000000 00002040 00000200 00000000 0000002C 00166173                                                                                           | 00002C        00000000 00002040 00000200 00000000 0000002C 00166173
     | 000044        796E635F 67656E5F 61746872 6F775F63 6C6F7365                                                                                                    | 000044        796E635F 67656E5F 61746872 6F775F63 6C6F7365
     |               Instruction count           11                                                                                                                  |               Instruction count           11
     |               Straight-line exec time     12                                                                                                                  |               Straight-line exec time     12
 GPR's set/used:   suus ssss ssss s---  ---- ---- ---- ----                                                                                                      GPR's set/used:   suus ssss ssss s---  ---- ---- ---- ----
 FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----                                                                                                      FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----
 CCR's set/used:   ss-- -sss                                                                                                                                     CCR's set/used:   ss-- -sss
     | 000000                             PDEF     async_gen_athrow_iternext                                                                                         | 000000                             PDEF       async_gen_athrow_iternext
 1969|                                    PROC      o,gr3                                                                                                        1969|                                    PROC       o,gr3
 1971| 000060 lwz        80820008   1     L4A       gr4=._Py_NoneStruct(gr2,0)                                                                                   1971| 000060 lwz        80820008   1     L4A        gr4=._Py_NoneStruct(gr2,0)
 1972| 000064 b          4800025C   0     CALLF     gr3=async_gen_athrow_send,2,(*)aggr#E",gr3,(*)_object",gr4,#ProcAlias",async_gen_athrow_send",fcr",gr1,cr[0  1972| 000064 b          4800029C   0     CALLF      gr3=async_gen_athrow_send,2,(*)aggr#E",gr3,(*)_object",gr4,#ProcAlias",async_gen_athrow_send",fcr",gr1,cr[
 1972|                                CL.727:                                                                                                                    1972|                                CL.727:
     |               Tag Table                                                                                                                                       |               Tag Table
     | 000068        00000000 00002040 00000100 00000000 00000008 00196173                                                                                           | 000068        00000000 00002040 00000100 00000000 00000008 00196173
     | 000080        796E635F 67656E5F 61746872 6F775F69 7465726E 657874                                                                                             | 000080        796E635F 67656E5F 61746872 6F775F69 7465726E 657874
     |               Instruction count            2                                                                                                                  |               Instruction count            2
     |               Straight-line exec time      1                                                                                                                  |               Straight-line exec time      1
 GPR's set/used:   ssus ssss ssss s---  ---- ---- ---- ---s                                                                                                      GPR's set/used:   ssus ssss ssss s---  ---- ---- ---- --ss
 FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----                                                                                                      FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----
 CCR's set/used:   ss-- -sss                                                                                                                                     CCR's set/used:   ss-- -sss
     | 000000                             PDEF     async_gen_athrow_throw                                                                                            | 000000                             PDEF       async_gen_athrow_throw







Wed Apr 15 07:30:04 CDT 2020  Page 60


 1929|                                    PROC      o,args,gr3,gr4                                                                                               1929|                                    PROC       o,args,gr3,gr4
    0| 0000A0 mfspr      7C0802A6   1     LFLR      gr0=lr                                                                                                          0| 0000A0 mfspr      7C0802A6   1     LFLR       gr0=lr
    0| 0000A4 ori        60650000   1     LR        gr5=gr3                                                                                                         0| 0000A4 stwu       9421FFC0   1     ST4U       gr1,#stack(gr1,-64)=gr1
    0| 0000A8 stw        90010008   1     ST4A      #stack(gr1,8)=gr0                                                                                               0| 0000A8 stw        90010048   1     ST4A       #stack(gr1,72)=gr0
    0| 0000AC stw        93E1FFFC   1     ST4A      #stack(gr1,-4)=gr31                                                                                             0| 0000AC stw        93E1003C   1     ST4A       #stack(gr1,60)=gr31
    0| 0000B0 stwu       9421FF90   1     ST4U      gr1,#stack(gr1,-112)=gr1                                                                                        0| 0000B0 ori        607F0000   1     LR         gr31=gr3
 1933| 0000B4 lwz        80030010   1     L4A       gr0=(*)aggr#E.agt_state(gr3,16)                                                                                 0| 0000B4 stw        93C10038   1     ST4A       #stack(gr1,56)=gr30
 1933| 0000B8 cmpwi      2C000002   2     C4        cr0=gr0,2                                                                                                    1933| 0000B8 lwz        80030010   1     L4A        gr0=(*)aggr#E.agt_state(gr3,16)
 1933| 0000BC bc         41820198   1     BT        CL.2301,cr0,0x4/eq,taken=30%(30,70)                                                                          1933| 0000BC cmpwi      2C000002   2     C4         cr0=gr0,2
 1940| 0000C0 lwz        80630008   1     L4A       gr3=(*)aggr#E.agt_gen(gr3,8)                                                                                 1933| 0000C0 bc         418201C8   1     BT         CL.1785,cr0,0x4/eq,taken=30%(30,70)
 1938| 0000C4 stw        90A1005C   1     ST4A      #parameter_store0(gr1,92)=gr5                                                                                1940| 0000C4 lwz        80630008   1     L4A        gr3=(*)aggr#E.agt_gen(gr3,8)
 1940| 0000C8 bl         480029B9   0     CALL      gr3=gen_throw,2,(*)aggr#3",gr3,(*)_object",gr4,#ProcAlias",gen_throw",fcr",gr1,cr[01567]",gr0",gr4"-gr12",f  1940| 0000C8 bl         480027D9   0     CALL       gr3=gen_throw,2,(*)aggr#3",gr3,(*)_object",gr4,#ProcAlias",gen_throw",fcr",gr1,cr[01567]",gr0",gr4"-gr12",
 1945| 0000CC lwz        80020014   1     L4A       gr0=._PyAsyncGenWrappedValue_Type(gr2,0)                                                                     1945| 0000CC lwz        80C20014   1     L4A        gr6=._PyAsyncGenWrappedValue_Type(gr2,0)
 1940| 0000D0 or.        7C7F1B79   1     LR_R      gr31,cr0=gr3                                                                                                 1941| 0000D0 lwz        801F000C   1     L4A        gr0=(*)aggr#E.agt_args(gr31,12)
 1940| 0000D4 lwz        80A1005C   1     L4A       gr5=#parameter_store0(gr1,92)                                                                                1940| 0000D4 ori        60640000   1     LR         gr4=gr3
 1941| 0000D8 lwz        8085000C   2     L4A       gr4=(*)aggr#E.agt_args(gr5,12)                                                                               1940| 0000D8 or.        7C7E1B79   1     LR_R       gr30,cr0=gr3
 1941| 0000DC cmpwi      2C840000   2     C4        cr1=gr4,0                                                                                                    1941| 0000DC cmpwi      2C800000   1     C4         cr1=gr0,0
 1941| 0000E0 bc         40860154   1     BF        CL.1671,cr1,0x4/eq,taken=30%(30,70)                                                                          1941| 0000E0 bc         40860188   1     BF         CL.2352,cr1,0x4/eq,taken=30%(30,70)
 1945| 0000E4 bc         418200D8   1     BT        CL.6,cr0,0x4/eq,taken=30%(30,70)                                                                             1945| 0000E4 bc         41820108   1     BT         CL.2350,cr0,0x4/eq,taken=30%(30,70)
 1947| 0000E8 addi       39200002   1     LI        gr9=2                                                                                                        1947| 0000E8 addi       38000002   3     LI         gr0=2
  415| 0000EC lwz        80820004   1     L4A       gr4=._Py_RefTotal(gr2,0)                                                                                      415| 0000EC lwz        80A20004   1     L4A        gr5=._Py_RefTotal(gr2,0)
  128| 0000F0 lwz        80DF0004   1     L4A       gr6=(*)C_object._object.ob_type(gr31,4)                                                                       128| 0000F0 lwz        80830004   1     L4A        gr4=(*)C_object._object.ob_type(gr3,4)
    0| 0000F4 lwz        80620018   1     L4A       gr3=.+CONSTANT_AREA(gr2,0)                                                                                      0| 0000F4 lwz        80620018   1     L4A        gr3=.+CONSTANT_AREA(gr2,0)
  128| 0000F8 cmplw      7C060040   1     CL4       cr0=gr6,gr0                                                                                                   128| 0000F8 cmplw      7C043040   1     CL4        cr0=gr4,gr6
  408| 0000FC addi       38631110   1     AI        gr3=gr3,4368                                                                                                  408| 0000FC addi       38631110   1     AI         gr3=gr3,4368
  415| 000100 lwz        80C40000   1     L4A       gr6=<s117:d0:l4>(gr4,0)                                                                                       415| 000100 lwz        80850000   1     L4A        gr4=_Py_RefTotal(gr5,0)
 1945| 000104 bc         408200B8   0     BF        CL.6,cr0,0x4/eq,taken=40%(40,60)                                                                             1945| 000104 bc         408200E8   0     BF         CL.2350,cr0,0x4/eq,taken=40%(40,60)
  417| 000108 lwz        80FF0000   2     L4A       gr7=(*)_object._object.ob_refcnt(gr31,0)                                                                      417| 000108 lwz        80DE0000   2     L4A        gr6=(*)_object._object.ob_refcnt(gr30,0)
 1946| 00010C addi       38000000   1     LI        gr0=0                                                                                                        1946| 00010C addi       39000000   1     LI         gr8=0
 1946| 000110 lwz        81050008   1     L4A       gr8=(*)aggr#E.agt_gen(gr5,8)                                                                                 1946| 000110 lwz        80FF0008   1     L4A        gr7=(*)aggr#E.agt_gen(gr31,8)
 1947| 000114 stw        91250010   1     ST4A      (*)aggr#E.agt_state(gr5,16)=gr9                                                                              1947| 000114 stw        901F0010   1     ST4A       (*)aggr#E.agt_state(gr31,16)=gr0
  415| 000118 addi       38A6FFFF   1     AI        gr5=gr6,-1                                                                                                    415| 000118 addi       3804FFFF   1     AI         gr0=gr4,-1
  415| 00011C stw        90A40000   1     ST4A      <s117:d0:l4>(gr4,0)=gr5                                                                                       415| 00011C stw        90050000   1     ST4A       _Py_RefTotal(gr5,0)=gr0
  417| 000120 addi       3887FFFF   1     AI        gr4=gr7,-1                                                                                                    417| 000120 addi       3886FFFF   1     AI         gr4=gr6,-1
  417| 000124 stw        909F0000   1     ST4A      (*)_object._object.ob_refcnt(gr31,0)=gr4                                                                      417| 000124 stw        909E0000   1     ST4A       (*)_object._object.ob_refcnt(gr30,0)=gr4
 1946| 000128 stw        9008003C   1     ST4A      (*)aggr#4.ag_running_async(gr8,60)=gr0                                                                       1946| 000128 stw        9107003C   1     ST4A       (*)aggr#4.ag_running_async(gr7,60)=gr8
  417| 00012C cmpwi      2C040000   1     C4        cr0=gr4,0                                                                                                     417| 00012C cmpwi      2C040000   1     C4         cr0=gr4,0
  417| 000130 bc         41820078   1     BT        CL.1505,cr0,0x4/eq,taken=40%(40,60)                                                                           417| 000130 bc         4182007C   1     BT         CL.1505,cr0,0x4/eq,taken=40%(40,60)
  420| 000134 addi       3880079C   2     LI        gr4=1948                                                                                                      420| 000134 addi       3880079C   2     LI         gr4=1948
  420| 000138 ori        63E50000   1     LR        gr5=gr31                                                                                                      420| 000138 ori        63C50000   1     LR         gr5=gr30
  419| 00013C bc         4080003C   0     BF        CL.2302,cr0,0x1/lt,taken=30%(30,70)                                                                             0| 00013C lwz        83E1003C   1     L4A        gr31=#stack(gr1,60)
    0| 000140 lwz        83E1006C   2     L4A       gr31=#stack(gr1,108)                                                                                          419| 000140 bc         4080003C   0     BF         CL.2348,cr0,0x1/lt,taken=50%(0,0)
  420| 000144 bl         4BFFFEBD   0     CALL      _Py_NegativeRefcount,3,(*)Cuchar",gr3,gr4,(*)_object",gr5,#ProcAlias",_Py_NegativeRefcount",fcr",gr1,cr[015     0| 000144 lwz        83C10038   2     L4A        gr30=#stack(gr1,56)
  420| 000148 ori        60000000   1                                                                                                                             420| 000148 bl         4BFFFEB9   0     CALL       _Py_NegativeRefcount,3,(*)Cuchar",gr3,gr4,(*)_object",gr5,#ProcAlias",_Py_NegativeRefcount",fcr",gr1,cr[01
    0|                                CL.1669:                                                                                                                    420| 00014C ori        60000000   1
 1949| 00014C lwz        8062001C   1     L4A       gr3=.PyExc_RuntimeError(gr2,0)                                                                               1949| 000150 lwz        8062001C   1     L4A        gr3=.PyExc_RuntimeError(gr2,0)
 1949| 000150 lwz        80820020   1     L4A       gr4=.$STATIC(gr2,0)                                                                                          1949| 000154 lwz        80820020   1     L4A        gr4=.$STATIC(gr2,0)
 1949| 000154 lwz        80630000   1     L4A       gr3=<s143:d0:l4>(gr3,0)                                                                                      1949| 000158 lwz        80630000   1     L4A        gr3=PyExc_RuntimeError(gr3,0)
 1949| 000158 lwz        80840004   1     L4A       gr4=ASYNC_GEN_IGNORED_EXIT_MSG(gr4,4)                                                                        1949| 00015C lwz        80840004   1     L4A        gr4=ASYNC_GEN_IGNORED_EXIT_MSG(gr4,4)
 1949| 00015C bl         4BFFFEA5   0     CALL      PyErr_SetString,2,(*)_object",gr3,(*)Cuchar",gr4,#ProcAlias",PyErr_SetString",fcr",gr1,cr[01567]",gr0",gr3"  1949| 000160 bl         4BFFFEA1   0     CALL       PyErr_SetString,2,(*)_object",gr3,(*)Cuchar",gr4,#ProcAlias",PyErr_SetString",fcr",gr1,cr[01567]",gr0",gr3
 1949| 000160 ori        60000000   1                                                                                                                            1949| 000164 ori        60000000   1
 1950| 000164 addi       38600000   1     LI        gr3=0                                                                                                        1950| 000168 addi       38600000   1     LI         gr3=0
 1965| 000168 addi       38210070   1     AI        gr1=gr1,112                                                                                                     0| 00016C lwz        80010048   1     L4A        gr0=#stack(gr1,72)
    0| 00016C lwz        80010008   1     L4A       gr0=#stack(gr1,8)                                                                                            1965| 000170 addi       38210040   1     AI         gr1=gr1,64
    0| 000170 mtspr      7C0803A6   2     LLR       lr=gr0                                                                                                          0| 000174 mtspr      7C0803A6   1     LLR        lr=gr0
 1965| 000174 bclr       4E800020   3     BA        lr                                                                                                           1965| 000178 bclr       4E800020   3     BA         lr







Wed Apr 15 07:30:04 CDT 2020  Page 61


    0|                                CL.2302:                                                                                                                      0|                                CL.2348:
 1949| 000178 lwz        8062001C   1     L4A       gr3=.PyExc_RuntimeError(gr2,0)                                                                               1949| 00017C lwz        8062001C   1     L4A        gr3=.PyExc_RuntimeError(gr2,0)
 1949| 00017C lwz        80C20020   1     L4A       gr6=.$STATIC(gr2,0)                                                                                          1949| 000180 lwz        80820020   1     L4A        gr4=.$STATIC(gr2,0)
    0| 000180 lwz        83E1006C   1     L4A       gr31=#stack(gr1,108)                                                                                            0| 000184 lwz        83C10038   1     L4A        gr30=#stack(gr1,56)
 1949| 000184 lwz        80630000   1     L4A       gr3=<s143:d0:l4>(gr3,0)                                                                                      1949| 000188 lwz        80630000   1     L4A        gr3=PyExc_RuntimeError(gr3,0)
 1949| 000188 lwz        80860004   1     L4A       gr4=ASYNC_GEN_IGNORED_EXIT_MSG(gr6,4)                                                                        1949| 00018C lwz        80840004   1     L4A        gr4=ASYNC_GEN_IGNORED_EXIT_MSG(gr4,4)
 1949| 00018C bl         4BFFFE75   0     CALL      PyErr_SetString,2,(*)_object",gr3,(*)Cuchar",gr4,#ProcAlias",PyErr_SetString",fcr",gr1,cr[01567]",gr0",gr3"  1949| 000190 bl         4BFFFE71   0     CALL       PyErr_SetString,2,(*)_object",gr3,(*)Cuchar",gr4,#ProcAlias",PyErr_SetString",fcr",gr1,cr[01567]",gr0",gr3
 1949| 000190 ori        60000000   1                                                                                                                            1949| 000194 ori        60000000   1
 1950| 000194 addi       38600000   1     LI        gr3=0                                                                                                        1950| 000198 addi       38600000   1     LI         gr3=0
 1965| 000198 addi       38210070   1     AI        gr1=gr1,112                                                                                                     0| 00019C lwz        80010048   1     L4A        gr0=#stack(gr1,72)
    0| 00019C lwz        80010008   1     L4A       gr0=#stack(gr1,8)                                                                                            1965| 0001A0 addi       38210040   1     AI         gr1=gr1,64
    0| 0001A0 mtspr      7C0803A6   2     LLR       lr=gr0                                                                                                          0| 0001A4 mtspr      7C0803A6   1     LLR        lr=gr0
 1965| 0001A4 bclr       4E800020   3     BA        lr                                                                                                           1965| 0001A8 bclr       4E800020   3     BA         lr
  423|                                CL.1505:                                                                                                                    423|                                CL.1505:
  425| 0001A8 ori        63E30000   1     LR        gr3=gr31                                                                                                      425| 0001AC ori        63C30000   1     LR         gr3=gr30
  425| 0001AC bl         4BFFFE55   0     CALL      _Py_Dealloc,1,(*)_object",gr3,#ProcAlias",_Py_Dealloc",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",l     0| 0001B0 lwz        83E1003C   1     L4A        gr31=#stack(gr1,60)
  425| 0001B0 ori        60000000   1                                                                                                                             425| 0001B4 bl         4BFFFE4D   0     CALL       _Py_Dealloc,1,(*)_object",gr3,#ProcAlias",_Py_Dealloc",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",
    0| 0001B4 lwz        83E1006C   1     L4A       gr31=#stack(gr1,108)                                                                                          425| 0001B8 ori        60000000   1
    0| 0001B8 b          4BFFFF94   0     B         CL.1669,-1                                                                                                   1949| 0001BC lwz        8062001C   1     L4A        gr3=.PyExc_RuntimeError(gr2,0)
 1951|                                CL.6:                                                                                                                      1949| 0001C0 lwz        80820020   1     L4A        gr4=.$STATIC(gr2,0)
 1952| 0001BC lwz        80620024   1     L4A       gr3=.PyExc_StopAsyncIteration(gr2,0)                                                                            0| 0001C4 lwz        83C10038   1     L4A        gr30=#stack(gr1,56)
 1952| 0001C0 lwz        80630000   2     L4A       gr3=<s137:d0:l4>(gr3,0)                                                                                      1949| 0001C8 lwz        80630000   1     L4A        gr3=PyExc_RuntimeError(gr3,0)
 1952| 0001C4 bl         4BFFFE3D   0     CALL      gr3=PyErr_ExceptionMatches,1,(*)_object",gr3,#ProcAlias",PyErr_ExceptionMatches",fcr",gr1,cr[01567]",gr0",g  1949| 0001CC lwz        80840004   1     L4A        gr4=ASYNC_GEN_IGNORED_EXIT_MSG(gr4,4)
 1952| 0001C8 ori        60000000   1                                                                                                                            1949| 0001D0 bl         4BFFFE31   0     CALL       PyErr_SetString,2,(*)_object",gr3,(*)Cuchar",gr4,#ProcAlias",PyErr_SetString",fcr",gr1,cr[01567]",gr0",gr3
 1953| 0001CC lwz        80820028   1     L4A       gr4=.PyExc_GeneratorExit(gr2,0)                                                                              1949| 0001D4 ori        60000000   1
 1952| 0001D0 cmpwi      2C030000   1     C4        cr0=gr3,0                                                                                                    1950| 0001D8 addi       38600000   1     LI         gr3=0
 1952| 0001D4 bc         40820030   1     BF        CL.7,cr0,0x4/eq,taken=30%(30,70)                                                                                0| 0001DC lwz        80010048   1     L4A        gr0=#stack(gr1,72)
 1953| 0001D8 lwz        80640000   2     L4A       gr3=<s141:d0:l4>(gr4,0)                                                                                      1965| 0001E0 addi       38210040   1     AI         gr1=gr1,64
 1953| 0001DC bl         4BFFFE25   0     CALL      gr3=PyErr_ExceptionMatches,1,(*)_object",gr3,#ProcAlias",PyErr_ExceptionMatches",fcr",gr1,cr[01567]",gr0",g     0| 0001E4 mtspr      7C0803A6   1     LLR        lr=gr0
 1953| 0001E0 ori        60000000   1                                                                                                                            1965| 0001E8 bclr       4E800020   3     BA         lr
 1953| 0001E4 cmpwi      2C030000   1     C4        cr0=gr3,0                                                                                                       0|                                CL.2350:
 1963| 0001E8 ori        63E30000   1     LR        gr3=gr31                                                                                                     1952| 0001EC lwz        80620024   1     L4A        gr3=.PyExc_StopAsyncIteration(gr2,0)
 1953| 0001EC bc         40820018   0     BF        CL.7,cr0,0x4/eq,taken=40%(40,60)                                                                                0| 0001F0 lwz        83E1003C   1     L4A        gr31=#stack(gr1,60)
    0| 0001F0 lwz        83E1006C   2     L4A       gr31=#stack(gr1,108)                                                                                         1952| 0001F4 lwz        80630000   1     L4A        gr3=PyExc_StopAsyncIteration(gr3,0)
 1965| 0001F4 addi       38210070   1     AI        gr1=gr1,112                                                                                                  1952| 0001F8 bl         4BFFFE09   0     CALL       gr3=PyErr_ExceptionMatches,1,(*)_object",gr3,#ProcAlias",PyErr_ExceptionMatches",fcr",gr1,cr[01567]",gr0",
    0| 0001F8 lwz        80010008   1     L4A       gr0=#stack(gr1,8)                                                                                            1952| 0001FC ori        60000000   1
    0| 0001FC mtspr      7C0803A6   2     LLR       lr=gr0                                                                                                       1953| 000200 lwz        80820028   1     L4A        gr4=.PyExc_GeneratorExit(gr2,0)
 1965| 000200 bclr       4E800020   3     BA        lr                                                                                                           1952| 000204 cmpwi      2C030000   1     C4         cr0=gr3,0
 1953|                                CL.7:                                                                                                                      1952| 000208 bc         40820030   1     BF         CL.7,cr0,0x4/eq,taken=30%(30,70)
 1960| 000204 bl         4BFFFDFD   0     CALL      PyErr_Clear,0,#ProcAlias",PyErr_Clear",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",lr",fcr",xer",fsr  1953| 00020C lwz        80640000   2     L4A        gr3=PyExc_GeneratorExit(gr4,0)
 1960| 000208 ori        60000000   1                                                                                                                            1953| 000210 bl         4BFFFDF1   0     CALL       gr3=PyErr_ExceptionMatches,1,(*)_object",gr3,#ProcAlias",PyErr_ExceptionMatches",fcr",gr1,cr[01567]",gr0",
 1961| 00020C lwz        8062002C   1     L4A       gr3=.PyExc_StopIteration(gr2,0)                                                                              1953| 000214 ori        60000000   1
 1961| 000210 lwz        80630000   2     L4A       gr3=<s139:d0:l4>(gr3,0)                                                                                      1953| 000218 cmpwi      2C030000   1     C4         cr0=gr3,0
 1961| 000214 bl         4BFFFDED   0     CALL      PyErr_SetNone,1,(*)_object",gr3,#ProcAlias",PyErr_SetNone",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",m  1963| 00021C ori        63C30000   1     LR         gr3=gr30
 1961| 000218 ori        60000000   1                                                                                                                            1953| 000220 bc         40820018   0     BF         CL.7,cr0,0x4/eq,taken=40%(40,60)
 1963| 00021C ori        63E30000   1     LR        gr3=gr31                                                                                                        0| 000224 lwz        83C10038   2     L4A        gr30=#stack(gr1,56)
    0| 000220 lwz        83E1006C   1     L4A       gr31=#stack(gr1,108)                                                                                            0| 000228 lwz        80010048   1     L4A        gr0=#stack(gr1,72)
 1965| 000224 addi       38210070   1     AI        gr1=gr1,112                                                                                                  1965| 00022C addi       38210040   1     AI         gr1=gr1,64
    0| 000228 lwz        80010008   1     L4A       gr0=#stack(gr1,8)                                                                                               0| 000230 mtspr      7C0803A6   1     LLR        lr=gr0
    0| 00022C mtspr      7C0803A6   2     LLR       lr=gr0                                                                                                       1965| 000234 bclr       4E800020   3     BA         lr
 1965| 000230 bclr       4E800020   3     BA        lr                                                                                                           1953|                                CL.7:
    0|                                CL.1671:                                                                                                                   1960| 000238 bl         4BFFFDC9   0     CALL       PyErr_Clear,0,#ProcAlias",PyErr_Clear",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",lr",fcr",xer",fs
 1942| 000234 lwz        80650008   1     L4A       gr3=(*)aggr#E.agt_gen(gr5,8)                                                                                 1960| 00023C ori        60000000   1
 1942| 000238 ori        63E40000   1     LR        gr4=gr31                                                                                                     1961| 000240 lwz        8062002C   1     L4A        gr3=.PyExc_StopIteration(gr2,0)
 1942| 00023C bl         480011E5   0     CALL      gr3=IPRA.$async_gen_unwrap_value,2,(*)aggr#4",gr3,(*)_object",gr4,#ProcAlias",IPRA.$async_gen_unwrap_value"  1961| 000244 lwz        80630000   2     L4A        gr3=PyExc_StopIteration(gr3,0)
    0| 000240 lwz        83E1006C   1     L4A       gr31=#stack(gr1,108)                                                                                         1961| 000248 bl         4BFFFDB9   0     CALL       PyErr_SetNone,1,(*)_object",gr3,#ProcAlias",PyErr_SetNone",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",







Wed Apr 15 07:30:04 CDT 2020  Page 62


 1965| 000244 addi       38210070   1     AI        gr1=gr1,112                                                                                                  1961| 00024C ori        60000000   1
    0| 000248 lwz        80010008   1     L4A       gr0=#stack(gr1,8)                                                                                            1963| 000250 ori        63C30000   1     LR         gr3=gr30
    0| 00024C mtspr      7C0803A6   2     LLR       lr=gr0                                                                                                          0| 000254 lwz        83C10038   1     L4A        gr30=#stack(gr1,56)
 1965| 000250 bclr       4E800020   3     BA        lr                                                                                                              0| 000258 lwz        80010048   1     L4A        gr0=#stack(gr1,72)
    0|                                CL.2301:                                                                                                                   1965| 00025C addi       38210040   1     AI         gr1=gr1,64
 1934| 000254 lwz        8062001C   1     L4A       gr3=.PyExc_RuntimeError(gr2,0)                                                                                  0| 000260 mtspr      7C0803A6   1     LLR        lr=gr0
 1934| 000258 lwz        80820018   1     L4A       gr4=.+CONSTANT_AREA(gr2,0)                                                                                   1965| 000264 bclr       4E800020   3     BA         lr
 1934| 00025C addi       38841324   2     AI        gr4=gr4,4900                                                                                                    0|                                CL.2352:
 1934| 000260 lwz        80630000   1     L4A       gr3=<s143:d0:l4>(gr3,0)                                                                                      1942| 000268 lwz        807F0008   1     L4A        gr3=(*)aggr#E.agt_gen(gr31,8)
 1934| 000264 bl         4BFFFD9D   0     CALL      PyErr_SetString,2,(*)_object",gr3,gr4,#ProcAlias",PyErr_SetString",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"     0| 00026C lwz        83C10038   1     L4A        gr30=#stack(gr1,56)
 1934| 000268 ori        60000000   1                                                                                                                            1942| 000270 bl         48001091   0     CALL       gr3=async_gen_unwrap_value,2,(*)aggr#4",gr3,(*)_object",gr4,#ProcAlias",async_gen_unwrap_value",fcr",gr1,c
 1937| 00026C addi       38600000   1     LI        gr3=0                                                                                                           0| 000274 lwz        83E1003C   1     L4A        gr31=#stack(gr1,60)
 1965| 000270 addi       38210070   1     AI        gr1=gr1,112                                                                                                     0| 000278 lwz        80010048   1     L4A        gr0=#stack(gr1,72)
    0| 000274 lwz        80010008   1     L4A       gr0=#stack(gr1,8)                                                                                            1965| 00027C addi       38210040   1     AI         gr1=gr1,64
    0| 000278 mtspr      7C0803A6   2     LLR       lr=gr0                                                                                                          0| 000280 mtspr      7C0803A6   1     LLR        lr=gr0
 1965| 00027C bclr       4E800020   3     BA        lr                                                                                                           1965| 000284 bclr       4E800020   3     BA         lr
     |               Tag Table                                                                                                                                      0|                                CL.1785:
     | 000280        00000000 00002041 80010200 00000000 000001E0 00166173                                                                                       1934| 000288 lwz        8062001C   1     L4A        gr3=.PyExc_RuntimeError(gr2,0)
     | 000298        796E635F 67656E5F 61746872 6F775F74 68726F77                                                                                                1934| 00028C lwz        80820018   1     L4A        gr4=.+CONSTANT_AREA(gr2,0)
     |               Instruction count          120                                                                                                                 0| 000290 lwz        83E1003C   1     L4A        gr31=#stack(gr1,60)
     |               Straight-line exec time    134                                                                                                              1934| 000294 addi       38841324   1     AI         gr4=gr4,4900
 GPR's set/used:   ssus ssss ssss s---  ---- ---- ---- -sss                                                                                                      1934| 000298 lwz        80630000   1     L4A        gr3=PyExc_RuntimeError(gr3,0)
 FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----                                                                                                      1934| 00029C bl         4BFFFD65   0     CALL       PyErr_SetString,2,(*)_object",gr3,gr4,#ProcAlias",PyErr_SetString",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0
 CCR's set/used:   ss-- -sss                                                                                                                                     1934| 0002A0 ori        60000000   1
     | 000000                             PDEF     async_gen_athrow_send                                                                                         1937| 0002A4 addi       38600000   1     LI         gr3=0
 1796|                                    PROC      o,arg,gr3,gr4                                                                                                   0| 0002A8 lwz        80010048   1     L4A        gr0=#stack(gr1,72)
    0| 0002C0 mfspr      7C0802A6   1     LFLR      gr0=lr                                                                                                       1965| 0002AC addi       38210040   1     AI         gr1=gr1,64
 1798| 0002C4 addi       38C00001   1     LI        gr6=1                                                                                                           0| 0002B0 mtspr      7C0803A6   1     LLR        lr=gr0
    0| 0002C8 stw        90010008   1     ST4A      #stack(gr1,8)=gr0                                                                                            1965| 0002B4 bclr       4E800020   3     BA         lr
    0| 0002CC stw        93E1FFFC   1     ST4A      #stack(gr1,-4)=gr31                                                                                              |               Tag Table
    0| 0002D0 ori        607F0000   1     LR        gr31=gr3                                                                                                         | 0002B8        00000000 00002041 80020200 00000000 00000218 00166173
    0| 0002D4 stw        93C1FFF8   1     ST4A      #stack(gr1,-8)=gr30                                                                                              | 0002D0        796E635F 67656E5F 61746872 6F775F74 68726F77
    0| 0002D8 stw        93A1FFF4   1     ST4A      #stack(gr1,-12)=gr29                                                                                             |               Instruction count          134
    0| 0002DC ori        609E0000   1     LR        gr30=gr4                                                                                                         |               Straight-line exec time    142
 1802| 0002E0 lwz        80030010   1     L4A       gr0=(*)aggr#E.agt_state(gr3,16)                                                                              GPR's set/used:   ssus ssss ssss s---  ---- ---- ---- -sss
 1798| 0002E4 lwz        83A30008   1     L4A       gr29=(*)aggr#E.agt_gen(gr3,8)                                                                                FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----
    0| 0002E8 stwu       9421FF80   1     ST4U      gr1,#stack(gr1,-128)=gr1                                                                                     CCR's set/used:   ss-- -sss
 1802| 0002EC cmpwi      2C000002   1     C4        cr0=gr0,2                                                                                                        | 000000                             PDEF       async_gen_athrow_send
 1799| 0002F0 lwz        807D0008   1     L4A       gr3=(*)aggr#3.gi_frame(gr29,8)                                                                               1796|                                    PROC       o,arg,gr3,gr4
    0| 0002F4 ori        60650000   2     LR        gr5=gr3                                                                                                      1802| 000300 lwz        80A30010   1     L4A        gr5=(*)aggr#E.agt_state(gr3,16)
 1802| 0002F8 bc         418204F8   0     BT        CL.2311,cr0,0x4/eq,taken=30%(30,70)                                                                             0| 000304 mfspr      7C0802A6   1     LFLR       gr0=lr
 1810| 0002FC addi       38E00002   1     LI        gr7=2                                                                                                           0| 000308 stwu       9421FF90   1     ST4U       gr1,#stack(gr1,-112)=gr1
 1811| 000300 lwz        8082002C   1     L4A       gr4=.PyExc_StopIteration(gr2,0)                                                                              1802| 00030C cmpwi      2C050002   1     C4         cr0=gr5,2
 1809| 000304 cmpwi      2C050000   1     C4        cr0=gr5,0                                                                                                       0| 000310 stw        90010078   1     ST4A       #stack(gr1,120)=gr0
 1809| 000308 bc         418204B8   1     BT        CL.2304,cr0,0x4/eq,taken=30%(30,70)                                                                             0| 000314 stw        93E1006C   1     ST4A       #stack(gr1,108)=gr31
 1815| 00030C cmpwi      2C000000   2     C4        cr0=gr0,0                                                                                                       0| 000318 ori        607F0000   1     LR         gr31=gr3
 1809| 000310 lwz        80630024   1     L4A       gr3=(*)_frame._frame.f_stacktop(gr3,36)                                                                      1798| 00031C addi       38000001   1     LI         gr0=1
 1809| 000314 cmpwi      2C830000   2     C4        cr1=gr3,0                                                                                                       0| 000320 stw        93C10068   1     ST4A       #stack(gr1,104)=gr30
 1809| 000318 bc         418604A8   1     BT        CL.2304,cr1,0x4/eq,taken=30%(30,70)                                                                             0| 000324 stw        93A10064   1     ST4A       #stack(gr1,100)=gr29
 1880| 00031C cmpwi      2C800001   2     C4        cr1=gr0,1                                                                                                       0| 000328 ori        609E0000   1     LR         gr30=gr4
 1815| 000320 bc         408203D8   0     BF        CL.13,cr0,0x4/eq,taken=50%(0,0)                                                                              1802| 00032C bc         418204F0   0     BT         CL.2361,cr0,0x4/eq,taken=30%(30,70)
 1816| 000324 lwz        801D003C   1     L4A       gr0=(*)aggr#4.ag_running_async(gr29,60)                                                                      1798| 000330 lwz        83A30008   2     L4A        gr29=(*)aggr#E.agt_gen(gr3,8)
    0| 000328 lwz        8062001C   1     L4A       gr3=.PyExc_RuntimeError(gr2,0)                                                                               1815| 000334 cmpwi      2C050000   1     C4         cr0=gr5,0
 1817| 00032C addi       38800002   1     LI        gr4=2                                                                                                        1810| 000338 addi       38E00002   1     LI         gr7=2
 1816| 000330 cmpwi      2C000000   1     C4        cr0=gr0,0                                                                                                    1811| 00033C lwz        8062002C   1     L4A        gr3=.PyExc_StopIteration(gr2,0)
 1816| 000334 bc         41820070   1     BT        CL.14,cr0,0x4/eq,taken=50%(0,0)                                                                              1799| 000340 lwz        809D0008   1     L4A        gr4=(*)aggr#3.gi_frame(gr29,8)







Wed Apr 15 07:30:04 CDT 2020  Page 63


 1818| 000338 lwz        801F000C   2     L4A       gr0=(*)aggr#E.agt_args(gr31,12)                                                                              1811| 000344 lwz        80630000   1     L4A        gr3=PyExc_StopIteration(gr3,0)
 1819| 00033C lwz        80A20018   1     L4A       gr5=.+CONSTANT_AREA(gr2,0)                                                                                      0| 000348 ori        60860000   1     LR         gr6=gr4
    0| 000340 lwz        83C10078   1     L4A       gr30=#stack(gr1,120)                                                                                         1809| 00034C cmpwi      2C860000   1     C4         cr1=gr6,0
    0| 000344 lwz        83A10074   1     L4A       gr29=#stack(gr1,116)                                                                                         1809| 000350 bc         418604A0   1     BT         CL.2354,cr1,0x4/eq,taken=30%(30,70)
 1817| 000348 stw        909F0010   1     ST4A      (*)aggr#E.agt_state(gr31,16)=gr4                                                                             1809| 000354 lwz        80840024   2     L4A        gr4=(*)_frame._frame.f_stacktop(gr4,36)
 1824| 00034C ori        60A60000   1     LR        gr6=gr5                                                                                                      1809| 000358 cmpwi      2C840000   2     C4         cr1=gr4,0
    0| 000350 lwz        80630000   1     L4A       gr3=<s143:d0:l4>(gr3,0)                                                                                      1809| 00035C bc         41860494   1     BT         CL.2354,cr1,0x4/eq,taken=30%(30,70)
 1818| 000354 cmpwi      2C000000   1     C4        cr0=gr0,0                                                                                                    1880| 000360 cmpwi      2C850001   2     C4         cr1=gr5,1
 1819| 000358 addi       38851354   1     AI        gr4=gr5,4948                                                                                                 1815| 000364 bc         408203C4   0     BF         CL.13,cr0,0x4/eq,taken=50%(0,0)
 1818| 00035C bc         40820024   0     BF        CL.15,cr0,0x4/eq,taken=50%(0,0)                                                                              1816| 000368 lwz        809D003C   1     L4A        gr4=(*)aggr#4.ag_running_async(gr29,60)
    0| 000360 lwz        83E1007C   2     L4A       gr31=#stack(gr1,124)                                                                                            0| 00036C lwz        8062001C   1     L4A        gr3=.PyExc_RuntimeError(gr2,0)
 1819| 000364 bl         4BFFFC9D   0     CALL      PyErr_SetString,2,(*)_object",gr3,gr4,#ProcAlias",PyErr_SetString",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"  1817| 000370 addi       38A00002   1     LI         gr5=2
 1819| 000368 ori        60000000   1                                                                                                                            1816| 000374 cmpwi      2C040000   1     C4         cr0=gr4,0
 1924| 00036C addi       38600000   1     LI        gr3=0                                                                                                        1816| 000378 bc         41820070   1     BT         CL.14,cr0,0x4/eq,taken=50%(0,0)
 1925| 000370 addi       38210080   1     AI        gr1=gr1,128                                                                                                  1818| 00037C lwz        801F000C   2     L4A        gr0=(*)aggr#E.agt_args(gr31,12)
    0| 000374 lwz        80010008   1     L4A       gr0=#stack(gr1,8)                                                                                            1819| 000380 lwz        80820018   1     L4A        gr4=.+CONSTANT_AREA(gr2,0)
    0| 000378 mtspr      7C0803A6   2     LLR       lr=gr0                                                                                                          0| 000384 lwz        83C10068   1     L4A        gr30=#stack(gr1,104)
 1925| 00037C bclr       4E800020   3     BA        lr                                                                                                              0| 000388 lwz        83A10064   1     L4A        gr29=#stack(gr1,100)
 1822|                                CL.15:                                                                                                                     1817| 00038C stw        90BF0010   1     ST4A       (*)aggr#E.agt_state(gr31,16)=gr5
 1824| 000380 addi       38861388   1     AI        gr4=gr6,5000                                                                                                 1824| 000390 ori        60850000   1     LR         gr5=gr4
    0| 000384 lwz        83E1007C   1     L4A       gr31=#stack(gr1,124)                                                                                            0| 000394 lwz        80630000   1     L4A        gr3=PyExc_RuntimeError(gr3,0)
 1824| 000388 bl         4BFFFC79   0     CALL      PyErr_SetString,2,(*)_object",gr3,gr4,#ProcAlias",PyErr_SetString",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"  1818| 000398 cmpwi      2C000000   1     C4         cr0=gr0,0
 1824| 00038C ori        60000000   1                                                                                                                            1819| 00039C addi       38841354   1     AI         gr4=gr4,4948
 1924| 000390 addi       38600000   1     LI        gr3=0                                                                                                        1818| 0003A0 bc         40820024   0     BF         CL.15,cr0,0x4/eq,taken=50%(0,0)
 1925| 000394 addi       38210080   1     AI        gr1=gr1,128                                                                                                     0| 0003A4 lwz        83E1006C   2     L4A        gr31=#stack(gr1,108)
    0| 000398 lwz        80010008   1     L4A       gr0=#stack(gr1,8)                                                                                            1819| 0003A8 bl         4BFFFC59   0     CALL       PyErr_SetString,2,(*)_object",gr3,gr4,#ProcAlias",PyErr_SetString",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0
    0| 00039C mtspr      7C0803A6   2     LLR       lr=gr0                                                                                                       1819| 0003AC ori        60000000   1
 1925| 0003A0 bclr       4E800020   3     BA        lr                                                                                                           1924| 0003B0 addi       38600000   1     LI         gr3=0
 1829|                                CL.14:                                                                                                                        0| 0003B4 lwz        80010078   1     L4A        gr0=#stack(gr1,120)
 1831| 0003A4 lwz        801D0038   1     L4A       gr0=(*)aggr#4.ag_closed(gr29,56)                                                                             1925| 0003B8 addi       38210070   1     AI         gr1=gr1,112
 1837| 0003A8 lwz        80620008   1     L4A       gr3=._Py_NoneStruct(gr2,0)                                                                                      0| 0003BC mtspr      7C0803A6   1     LLR        lr=gr0
 1831| 0003AC cmpwi      2C000000   1     C4        cr0=gr0,0                                                                                                    1925| 0003C0 bclr       4E800020   3     BA         lr
 1837| 0003B0 cmplw      7C83F040   1     CL4       cr1=gr3,gr30                                                                                                 1822|                                CL.15:
 1831| 0003B4 bc         4082030C   0     BF        CL.2312,cr0,0x4/eq,taken=30%(30,70)                                                                          1824| 0003C4 addi       38851388   1     AI         gr4=gr5,5000
    0| 0003B8 lwz        83C10078   2     L4A       gr30=#stack(gr1,120)                                                                                            0| 0003C8 lwz        83E1006C   1     L4A        gr31=#stack(gr1,108)
 1837| 0003BC bc         408602D0   0     BF        CL.2313,cr1,0x4/eq,taken=30%(30,70)                                                                          1824| 0003CC bl         4BFFFC35   0     CALL       PyErr_SetString,2,(*)_object",gr3,gr4,#ProcAlias",PyErr_SetString",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0
 1860| 0003C0 addi       38000000   2     LI        gr0=0                                                                                                        1824| 0003D0 ori        60000000   1
 1849| 0003C4 lwz        80A20028   1     L4A       gr5=.PyExc_GeneratorExit(gr2,0)                                                                              1924| 0003D4 addi       38600000   1     LI         gr3=0
 1863| 0003C8 addi       39210060   1     AI        gr9=gr1,96                                                                                                      0| 0003D8 lwz        80010078   1     L4A        gr0=#stack(gr1,120)
 1845| 0003CC lwz        807F000C   1     L4A       gr3=(*)aggr#E.agt_args(gr31,12)                                                                              1925| 0003DC addi       38210070   1     AI         gr1=gr1,112
 1842| 0003D0 stw        90DF0010   1     ST4A      (*)aggr#E.agt_state(gr31,16)=gr6                                                                                0| 0003E0 mtspr      7C0803A6   1     LLR        lr=gr0
 1843| 0003D4 stw        90DD003C   1     ST4A      (*)aggr#4.ag_running_async(gr29,60)=gr6                                                                      1925| 0003E4 bclr       4E800020   3     BA         lr
 1845| 0003D8 cmpwi      2C030000   1     C4        cr0=gr3,0                                                                                                    1829|                                CL.14:
 1845| 0003DC bc         40820214   1     BF        CL.19,cr0,0x4/eq,taken=50%(0,0)                                                                              1831| 0003E8 lwz        807D0038   1     L4A        gr3=(*)aggr#4.ag_closed(gr29,56)
 1849| 0003E0 ori        63A30000   2     LR        gr3=gr29                                                                                                     1837| 0003EC lwz        80820008   1     L4A        gr4=._Py_NoneStruct(gr2,0)
 1847| 0003E4 stw        90DD0038   1     ST4A      (*)aggr#4.ag_closed(gr29,56)=gr6                                                                             1831| 0003F0 cmpwi      2C030000   1     C4         cr0=gr3,0
 1849| 0003E8 addi       38800000   1     LI        gr4=0                                                                                                        1837| 0003F4 cmplw      7C84F040   1     CL4        cr1=gr4,gr30
 1849| 0003EC addi       38C00000   1     LI        gr6=0                                                                                                        1831| 0003F8 bc         408202F8   0     BF         CL.2362,cr0,0x4/eq,taken=30%(30,70)
 1849| 0003F0 addi       38E00000   1     LI        gr7=0                                                                                                           0| 0003FC lwz        83C10068   2     L4A        gr30=#stack(gr1,104)
 1849| 0003F4 lwz        80A50000   1     L4A       gr5=<s141:d0:l4>(gr5,0)                                                                                      1837| 000400 bc         408602BC   0     BF         CL.2363,cr1,0x4/eq,taken=30%(30,70)
 1849| 0003F8 stw        9361FFEC   1     ST4A      #stack_prune(gr1,-20)=gr27                                                                                   1849| 000404 lwz        81220028   2     L4A        gr9=.PyExc_GeneratorExit(gr2,0)
 1849| 0003FC stw        9381FFF0   1     ST4A      #stack_prune(gr1,-16)=gr28                                                                                   1863| 000408 addi       38A00001   1     LI         gr5=1
 1849| 000400 stw        93E1FFFC   1     ST4A      #stack_prune(gr1,-4)=gr31                                                                                    1845| 00040C lwz        807F000C   1     L4A        gr3=(*)aggr#E.agt_args(gr31,12)
 1849| 000404 bl         4800275D   0     CALL      gr3=IPRA.$_gen_throw,5,(*)aggr#3",gr3,gr4,(*)_object",gr5,(*)_object",gr6,(*)_object",gr7,#ProcAlias",IPRA.  1863| 000410 addi       38C00003   1     LI         gr6=3
 1849| 000408 lwz        83E1FFFC   1     L4A       gr31=#stack_prune(gr1,-4)                                                                                    1860| 000414 addi       39400000   1     LI         gr10=0
 1849| 00040C lwz        8381FFF0   1     L4A       gr28=#stack_prune(gr1,-16)                                                                                   1863| 000418 lwz        80820018   1     L4A        gr4=.+CONSTANT_AREA(gr2,0)







Wed Apr 15 07:30:04 CDT 2020  Page 64


 1849| 000410 lwz        8361FFEC   1     L4A       gr27=#stack_prune(gr1,-20)                                                                                   1863| 00041C addi       38E10060   1     AI         gr7=gr1,96
 1849| 000414 or.        7C651B79   1     LR_R      gr5,cr0=gr3                                                                                                  1842| 000420 stw        901F0010   1     ST4A       (*)aggr#E.agt_state(gr31,16)=gr0
 1854| 000418 bc         418201D0   1     BT        CL.2307,cr0,0x4/eq,taken=30%(30,70)                                                                          1845| 000424 cmpwi      2C030000   1     C4         cr0=gr3,0
 1854| 00041C lwz        80020014   2     L4A       gr0=._PyAsyncGenWrappedValue_Type(gr2,0)                                                                     1843| 000428 stw        901D003C   1     ST4A       (*)aggr#4.ag_running_async(gr29,60)=gr0
  128| 000420 lwz        80830004   1     L4A       gr4=(*)C_object._object.ob_type(gr3,4)                                                                       1863| 00042C addi       3901005C   1     AI         gr8=gr1,92
    0| 000424 lwz        83A10074   1     L4A       gr29=#stack(gr1,116)                                                                                         1845| 000430 bc         40820208   0     BF         CL.19,cr0,0x4/eq,taken=50%(0,0)
  128| 000428 cmplw      7C040040   1     CL4       cr0=gr4,gr0                                                                                                  1849| 000434 ori        63A30000   2     LR         gr3=gr29
 1854| 00042C bc         408200EC   1     BF        CL.20,cr0,0x4/eq,taken=50%(0,0)                                                                              1847| 000438 stw        901D0038   1     ST4A       (*)aggr#4.ag_closed(gr29,56)=gr0
  415| 000430 lwz        80820004   2     L4A       gr4=._Py_RefTotal(gr2,0)                                                                                     1849| 00043C addi       38800000   1     LI         gr4=0
    0| 000434 lwz        80C20018   1     L4A       gr6=.+CONSTANT_AREA(gr2,0)                                                                                   1849| 000440 addi       38C00000   1     LI         gr6=0
  417| 000438 lwz        80E50000   1     L4A       gr7=(*)_object._object.ob_refcnt(gr5,0)                                                                      1849| 000444 addi       38E00000   1     LI         gr7=0
  408| 00043C addi       3800073F   1     LI        gr0=1855                                                                                                     1849| 000448 lwz        80A90000   1     L4A        gr5=PyExc_GeneratorExit(gr9,0)
  417| 000440 addi       38E7FFFF   1     AI        gr7=gr7,-1                                                                                                   1849| 00044C stw        9361FFEC   1     ST4A       #stack_prune(gr1,-20)=gr27
  417| 000444 stw        90E50000   1     ST4A      (*)_object._object.ob_refcnt(gr5,0)=gr7                                                                      1849| 000450 stw        9381FFF0   1     ST4A       #stack_prune(gr1,-16)=gr28
  417| 000448 lwz        81030000   1     L4A       gr8=(*)_object._object.ob_refcnt(gr3,0)                                                                      1849| 000454 stw        93E1FFFC   1     ST4A       #stack_prune(gr1,-4)=gr31
  408| 00044C addi       38661110   1     AI        gr3=gr6,4368                                                                                                 1849| 000458 bl         48002529   0     CALL       gr3=IPRA.$_gen_throw,5,(*)aggr#3",gr3,gr4,(*)_object",gr5,(*)_object",gr6,(*)_object",gr7,#ProcAlias",IPRA
  415| 000450 lwz        80C40000   1     L4A       gr6=<s117:d0:l4>(gr4,0)                                                                                      1849| 00045C lwz        83E1FFFC   1     L4A        gr31=#stack_prune(gr1,-4)
  417| 000454 cmpwi      2C080000   1     C4        cr0=gr8,0                                                                                                    1849| 000460 lwz        8381FFF0   1     L4A        gr28=#stack_prune(gr1,-16)
  415| 000458 addi       38C6FFFF   1     AI        gr6=gr6,-1                                                                                                   1849| 000464 lwz        8361FFEC   1     L4A        gr27=#stack_prune(gr1,-20)
  415| 00045C stw        90C40000   1     ST4A      <s117:d0:l4>(gr4,0)=gr6                                                                                      1849| 000468 or.        7C651B79   1     LR_R       gr5,cr0=gr3
  417| 000460 bc         41820084   0     BT        CL.1493,cr0,0x4/eq,taken=40%(40,60)                                                                          1854| 00046C bc         418201C4   1     BT         CL.2357,cr0,0x4/eq,taken=30%(30,70)
  419| 000464 cmpwi      2C070000   2     C4        cr0=gr7,0                                                                                                    1854| 000470 lwz        80020014   2     L4A        gr0=._PyAsyncGenWrappedValue_Type(gr2,0)
  417| 000468 bc         41800048   1     BT        CL.2303,cr0,0x1/lt,taken=40%(40,60)                                                                           128| 000474 lwz        80630004   1     L4A        gr3=(*)C_object._object.ob_type(gr3,4)
 1901|                                yield_close:                                                                                                                  0| 000478 lwz        83A10064   1     L4A        gr29=#stack(gr1,100)
 1902| 00046C lwz        807F0008   1     L4A       gr3=(*)aggr#E.agt_gen(gr31,8)                                                                                 128| 00047C cmplw      7C030040   1     CL4        cr0=gr3,gr0
 1902| 000470 addi       38000000   1     LI        gr0=0                                                                                                        1854| 000480 bc         408200E0   1     BF         CL.20,cr0,0x4/eq,taken=50%(0,0)
 1903| 000474 addi       38C00002   1     LI        gr6=2                                                                                                         417| 000484 lwz        80E50000   2     L4A        gr7=(*)_object._object.ob_refcnt(gr5,0)
 1904| 000478 lwz        80A2001C   1     L4A       gr5=.PyExc_RuntimeError(gr2,0)                                                                                415| 000488 lwz        80C20004   1     L4A        gr6=._Py_RefTotal(gr2,0)
 1904| 00047C lwz        80820020   1     L4A       gr4=.$STATIC(gr2,0)                                                                                             0| 00048C lwz        80620018   1     L4A        gr3=.+CONSTANT_AREA(gr2,0)
 1903| 000480 stw        90DF0010   1     ST4A      (*)aggr#E.agt_state(gr31,16)=gr6                                                                              408| 000490 addi       3880073F   1     LI         gr4=1855
 1902| 000484 stw        9003003C   1     ST4A      (*)aggr#4.ag_running_async(gr3,60)=gr0                                                                        417| 000494 addi       3807FFFF   1     AI         gr0=gr7,-1
 1904| 000488 lwz        80650000   1     L4A       gr3=<s143:d0:l4>(gr5,0)                                                                                       417| 000498 stw        90050000   1     ST4A       (*)_object._object.ob_refcnt(gr5,0)=gr0
 1904| 00048C lwz        80840004   1     L4A       gr4=ASYNC_GEN_IGNORED_EXIT_MSG(gr4,4)                                                                         408| 00049C addi       38631110   1     AI         gr3=gr3,4368
    0|                                CL.2321:                                                                                                                    415| 0004A0 lwz        80E60000   1     L4A        gr7=_Py_RefTotal(gr6,0)
 1904| 000490 bl         4BFFFB71   0     CALL      PyErr_SetString,2,(*)_object",gr3,(*)Cuchar",gr4,#ProcAlias",PyErr_SetString",fcr",gr1,cr[01567]",gr0",gr3"   415| 0004A4 addi       38E7FFFF   2     AI         gr7=gr7,-1
 1904| 000494 ori        60000000   1                                                                                                                             417| 0004A8 cmpwi      2C000000   1     C4         cr0=gr0,0
 1906| 000498 addi       38600000   1     LI        gr3=0                                                                                                         415| 0004AC stw        90E60000   1     ST4A       _Py_RefTotal(gr6,0)=gr7
    0| 00049C lwz        83E1007C   1     L4A       gr31=#stack(gr1,124)                                                                                          417| 0004B0 bc         4182007C   0     BT         CL.1493,cr0,0x4/eq,taken=40%(40,60)
 1925| 0004A0 addi       38210080   1     AI        gr1=gr1,128                                                                                                   408| 0004B4 bc         41800048   0     BT         CL.2353,cr0,0x1/lt,taken=40%(40,60)
    0| 0004A4 lwz        80010008   1     L4A       gr0=#stack(gr1,8)                                                                                            1901|                                yield_close:
    0| 0004A8 mtspr      7C0803A6   2     LLR       lr=gr0                                                                                                       1902| 0004B8 lwz        807F0008   1     L4A        gr3=(*)aggr#E.agt_gen(gr31,8)
 1925| 0004AC bclr       4E800020   3     BA        lr                                                                                                           1902| 0004BC addi       38000000   1     LI         gr0=0
  419|                                CL.2303:                                                                                                                   1903| 0004C0 addi       38C00002   1     LI         gr6=2
  420| 0004B0 ori        60040000   1     LR        gr4=gr0                                                                                                      1904| 0004C4 lwz        80A2001C   1     L4A        gr5=.PyExc_RuntimeError(gr2,0)
  420| 0004B4 bl         4BFFFB4D   0     CALL      _Py_NegativeRefcount,3,(*)Cuchar",gr3,gr4,(*)_object",gr5,#ProcAlias",_Py_NegativeRefcount",fcr",gr1,cr[015  1904| 0004C8 lwz        80820020   1     L4A        gr4=.$STATIC(gr2,0)
  420| 0004B8 ori        60000000   1                                                                                                                            1903| 0004CC stw        90DF0010   1     ST4A       (*)aggr#E.agt_state(gr31,16)=gr6
 1902| 0004BC lwz        807F0008   1     L4A       gr3=(*)aggr#E.agt_gen(gr31,8)                                                                                1902| 0004D0 stw        9003003C   1     ST4A       (*)aggr#4.ag_running_async(gr3,60)=gr0
 1902| 0004C0 addi       38000000   1     LI        gr0=0                                                                                                        1904| 0004D4 lwz        80650000   1     L4A        gr3=PyExc_RuntimeError(gr5,0)
 1903| 0004C4 addi       38C00002   1     LI        gr6=2                                                                                                        1904| 0004D8 lwz        80840004   1     L4A        gr4=ASYNC_GEN_IGNORED_EXIT_MSG(gr4,4)
 1904| 0004C8 lwz        80A2001C   1     L4A       gr5=.PyExc_RuntimeError(gr2,0)                                                                                  0|                                CL.2371:
 1904| 0004CC lwz        80820020   1     L4A       gr4=.$STATIC(gr2,0)                                                                                          1904| 0004DC bl         4BFFFB25   0     CALL       PyErr_SetString,2,(*)_object",gr3,(*)Cuchar",gr4,#ProcAlias",PyErr_SetString",fcr",gr1,cr[01567]",gr0",gr3
 1903| 0004D0 stw        90DF0010   1     ST4A      (*)aggr#E.agt_state(gr31,16)=gr6                                                                             1904| 0004E0 ori        60000000   1
 1902| 0004D4 stw        9003003C   1     ST4A      (*)aggr#4.ag_running_async(gr3,60)=gr0                                                                       1902| 0004E4 addi       38600000   1     LI         gr3=0
 1904| 0004D8 lwz        80650000   1     L4A       gr3=<s143:d0:l4>(gr5,0)                                                                                         0| 0004E8 lwz        83E1006C   1     L4A        gr31=#stack(gr1,108)
 1904| 0004DC lwz        80840004   1     L4A       gr4=ASYNC_GEN_IGNORED_EXIT_MSG(gr4,4)                                                                           0| 0004EC lwz        80010078   1     L4A        gr0=#stack(gr1,120)
  423| 0004E0 b          4BFFFFB0   0     B         CL.2321,-1                                                                                                   1925| 0004F0 addi       38210070   1     AI         gr1=gr1,112







Wed Apr 15 07:30:04 CDT 2020  Page 65


  423|                                CL.1493:                                                                                                                      0| 0004F4 mtspr      7C0803A6   1     LLR        lr=gr0
  425| 0004E4 ori        60A30000   1     LR        gr3=gr5                                                                                                      1925| 0004F8 bclr       4E800020   3     BA         lr
  425| 0004E8 bl         4BFFFB19   0     CALL      _Py_Dealloc,1,(*)_object",gr3,#ProcAlias",_Py_Dealloc",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",l   419|                                CL.2353:
  425| 0004EC ori        60000000   1                                                                                                                             420| 0004FC bl         4BFFFB05   0     CALL       _Py_NegativeRefcount,3,(*)Cuchar",gr3,gr4,(*)_object",gr5,#ProcAlias",_Py_NegativeRefcount",fcr",gr1,cr[01
 1902| 0004F0 lwz        807F0008   1     L4A       gr3=(*)aggr#E.agt_gen(gr31,8)                                                                                 420| 000500 ori        60000000   1
 1902| 0004F4 addi       38000000   1     LI        gr0=0                                                                                                        1902| 000504 lwz        807F0008   1     L4A        gr3=(*)aggr#E.agt_gen(gr31,8)
 1903| 0004F8 addi       38C00002   1     LI        gr6=2                                                                                                        1902| 000508 addi       38000000   1     LI         gr0=0
 1904| 0004FC lwz        80A2001C   1     L4A       gr5=.PyExc_RuntimeError(gr2,0)                                                                               1903| 00050C addi       38C00002   1     LI         gr6=2
 1904| 000500 lwz        80820020   1     L4A       gr4=.$STATIC(gr2,0)                                                                                          1904| 000510 lwz        80A2001C   1     L4A        gr5=.PyExc_RuntimeError(gr2,0)
 1903| 000504 stw        90DF0010   1     ST4A      (*)aggr#E.agt_state(gr31,16)=gr6                                                                             1904| 000514 lwz        80820020   1     L4A        gr4=.$STATIC(gr2,0)
 1902| 000508 stw        9003003C   1     ST4A      (*)aggr#4.ag_running_async(gr3,60)=gr0                                                                       1903| 000518 stw        90DF0010   1     ST4A       (*)aggr#E.agt_state(gr31,16)=gr6
 1904| 00050C lwz        80650000   1     L4A       gr3=<s143:d0:l4>(gr5,0)                                                                                      1902| 00051C stw        9003003C   1     ST4A       (*)aggr#4.ag_running_async(gr3,60)=gr0
 1904| 000510 lwz        80840004   1     L4A       gr4=ASYNC_GEN_IGNORED_EXIT_MSG(gr4,4)                                                                        1904| 000520 lwz        80650000   1     L4A        gr3=PyExc_RuntimeError(gr5,0)
    0| 000514 b          4BFFFF7C   0     B         CL.2321,-1                                                                                                   1904| 000524 lwz        80840004   1     L4A        gr4=ASYNC_GEN_IGNORED_EXIT_MSG(gr4,4)
 1857|                                CL.20:                                                                                                                      423| 000528 b          4BFFFFB4   0     B          CL.2371,-1
 1874| 000518 cmpwi      2C050000   1     C4        cr0=gr5,0                                                                                                     423|                                CL.1493:
 1874| 00051C bc         4182001C   1     BT        check_error,cr0,0x4/eq,taken=40%(40,60)                                                                       425| 00052C ori        60A30000   1     LR         gr3=gr5
    0|                                CL.2310:                                                                                                                    425| 000530 bl         4BFFFAD1   0     CALL       _Py_Dealloc,1,(*)_object",gr3,#ProcAlias",_Py_Dealloc",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",
 1877| 000520 ori        60A30000   1     LR        gr3=gr5                                                                                                       425| 000534 ori        60000000   1
    0| 000524 lwz        83E1007C   1     L4A       gr31=#stack(gr1,124)                                                                                         1902| 000538 lwz        807F0008   1     L4A        gr3=(*)aggr#E.agt_gen(gr31,8)
 1925| 000528 addi       38210080   1     AI        gr1=gr1,128                                                                                                  1902| 00053C addi       38000000   1     LI         gr0=0
    0| 00052C lwz        80010008   1     L4A       gr0=#stack(gr1,8)                                                                                            1903| 000540 addi       38C00002   1     LI         gr6=2
    0| 000530 mtspr      7C0803A6   2     LLR       lr=gr0                                                                                                       1904| 000544 lwz        80A2001C   1     L4A        gr5=.PyExc_RuntimeError(gr2,0)
 1925| 000534 bclr       4E800020   3     BA        lr                                                                                                           1904| 000548 lwz        80820020   1     L4A        gr4=.$STATIC(gr2,0)
 1908|                                check_error:                                                                                                               1903| 00054C stw        90DF0010   1     ST4A       (*)aggr#E.agt_state(gr31,16)=gr6
 1909| 000538 addi       38000000   1     LI        gr0=0                                                                                                        1902| 000550 stw        9003003C   1     ST4A       (*)aggr#4.ag_running_async(gr3,60)=gr0
 1909| 00053C lwz        807F0008   1     L4A       gr3=(*)aggr#E.agt_gen(gr31,8)                                                                                1904| 000554 lwz        80650000   1     L4A        gr3=PyExc_RuntimeError(gr5,0)
 1910| 000540 addi       38A00002   1     LI        gr5=2                                                                                                        1904| 000558 lwz        80840004   1     L4A        gr4=ASYNC_GEN_IGNORED_EXIT_MSG(gr4,4)
 1911| 000544 lwz        80820024   1     L4A       gr4=.PyExc_StopAsyncIteration(gr2,0)                                                                            0| 00055C b          4BFFFF80   0     B          CL.2371,-1
 1910| 000548 stw        90BF0010   1     ST4A      (*)aggr#E.agt_state(gr31,16)=gr5                                                                             1857|                                CL.20:
 1909| 00054C stw        9003003C   1     ST4A      (*)aggr#4.ag_running_async(gr3,60)=gr0                                                                       1874| 000560 cmpwi      2C050000   1     C4         cr0=gr5,0
 1911| 000550 lwz        80640000   1     L4A       gr3=<s137:d0:l4>(gr4,0)                                                                                      1874| 000564 bc         4182001C   1     BT         check_error,cr0,0x4/eq,taken=40%(40,60)
 1911| 000554 bl         4BFFFAAD   0     CALL      gr3=PyErr_ExceptionMatches,1,(*)_object",gr3,#ProcAlias",PyErr_ExceptionMatches",fcr",gr1,cr[01567]",gr0",g     0|                                CL.2360:
 1911| 000558 ori        60000000   1                                                                                                                            1877| 000568 ori        60A30000   1     LR         gr3=gr5
 1911| 00055C cmpwi      2C030000   1     C4        cr0=gr3,0                                                                                                       0| 00056C lwz        83E1006C   1     L4A        gr31=#stack(gr1,108)
 1911| 000560 bc         41820058   1     BT        CL.2317,cr0,0x4/eq,taken=40%(40,60)                                                                             0| 000570 lwz        80010078   1     L4A        gr0=#stack(gr1,120)
 1912|                                CL.36:                                                                                                                     1925| 000574 addi       38210070   1     AI         gr1=gr1,112
 1914| 000564 lwz        801F000C   1     L4A       gr0=(*)aggr#E.agt_args(gr31,12)                                                                                 0| 000578 mtspr      7C0803A6   1     LLR        lr=gr0
 1914| 000568 cmpwi      2C000000   2     C4        cr0=gr0,0                                                                                                    1925| 00057C bclr       4E800020   3     BA         lr
 1914| 00056C bc         4182001C   1     BT        CL.2318,cr0,0x4/eq,taken=40%(40,60)                                                                          1908|                                check_error:
 1924| 000570 addi       38600000   1     LI        gr3=0                                                                                                        1909| 000580 addi       38000000   1     LI         gr0=0
    0| 000574 lwz        83E1007C   1     L4A       gr31=#stack(gr1,124)                                                                                         1909| 000584 lwz        807F0008   1     L4A        gr3=(*)aggr#E.agt_gen(gr31,8)
 1925| 000578 addi       38210080   1     AI        gr1=gr1,128                                                                                                  1910| 000588 addi       38A00002   1     LI         gr5=2
    0| 00057C lwz        80010008   1     L4A       gr0=#stack(gr1,8)                                                                                            1911| 00058C lwz        80820024   1     L4A        gr4=.PyExc_StopAsyncIteration(gr2,0)
    0| 000580 mtspr      7C0803A6   2     LLR       lr=gr0                                                                                                       1910| 000590 stw        90BF0010   1     ST4A       (*)aggr#E.agt_state(gr31,16)=gr5
 1925| 000584 bclr       4E800020   3     BA        lr                                                                                                           1909| 000594 stw        9003003C   1     ST4A       (*)aggr#4.ag_running_async(gr3,60)=gr0
    0|                                CL.2318:                                                                                                                   1911| 000598 lwz        80640000   1     L4A        gr3=PyExc_StopAsyncIteration(gr4,0)
    0| 000588 lwz        83E1007C   1     L4A       gr31=#stack(gr1,124)                                                                                         1911| 00059C bl         4BFFFA65   0     CALL       gr3=PyErr_ExceptionMatches,1,(*)_object",gr3,#ProcAlias",PyErr_ExceptionMatches",fcr",gr1,cr[01567]",gr0",
 1920| 00058C bl         4BFFFA75   0     CALL      PyErr_Clear,0,#ProcAlias",PyErr_Clear",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",lr",fcr",xer",fsr  1911| 0005A0 ori        60000000   1
 1920| 000590 ori        60000000   1                                                                                                                            1911| 0005A4 cmpwi      2C030000   1     C4         cr0=gr3,0
 1921| 000594 lwz        8062002C   1     L4A       gr3=.PyExc_StopIteration(gr2,0)                                                                              1911| 0005A8 bc         41820058   1     BT         CL.2367,cr0,0x4/eq,taken=40%(40,60)
 1921| 000598 lwz        80630000   2     L4A       gr3=<s139:d0:l4>(gr3,0)                                                                                      1912|                                CL.36:
 1921| 00059C bl         4BFFFA65   0     CALL      PyErr_SetNone,1,(*)_object",gr3,#ProcAlias",PyErr_SetNone",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",m  1914| 0005AC lwz        801F000C   1     L4A        gr0=(*)aggr#E.agt_args(gr31,12)
 1921| 0005A0 ori        60000000   1                                                                                                                            1914| 0005B0 cmpwi      2C000000   2     C4         cr0=gr0,0
 1924| 0005A4 addi       38600000   1     LI        gr3=0                                                                                                        1914| 0005B4 bc         4182001C   1     BT         CL.2368,cr0,0x4/eq,taken=40%(40,60)
 1925| 0005A8 addi       38210080   1     AI        gr1=gr1,128                                                                                                  1924| 0005B8 addi       38600000   1     LI         gr3=0







Wed Apr 15 07:30:04 CDT 2020  Page 66


    0| 0005AC lwz        80010008   1     L4A       gr0=#stack(gr1,8)                                                                                               0| 0005BC lwz        83E1006C   1     L4A        gr31=#stack(gr1,108)
    0| 0005B0 mtspr      7C0803A6   2     LLR       lr=gr0                                                                                                          0| 0005C0 lwz        80010078   1     L4A        gr0=#stack(gr1,120)
 1925| 0005B4 bclr       4E800020   3     BA        lr                                                                                                           1925| 0005C4 addi       38210070   1     AI         gr1=gr1,112
    0|                                CL.2317:                                                                                                                      0| 0005C8 mtspr      7C0803A6   1     LLR        lr=gr0
 1912| 0005B8 lwz        80620028   1     L4A       gr3=.PyExc_GeneratorExit(gr2,0)                                                                              1925| 0005CC bclr       4E800020   3     BA         lr
 1912| 0005BC lwz        80630000   2     L4A       gr3=<s141:d0:l4>(gr3,0)                                                                                         0|                                CL.2368:
 1912| 0005C0 bl         4BFFFA41   0     CALL      gr3=PyErr_ExceptionMatches,1,(*)_object",gr3,#ProcAlias",PyErr_ExceptionMatches",fcr",gr1,cr[01567]",gr0",g     0| 0005D0 lwz        83E1006C   1     L4A        gr31=#stack(gr1,108)
 1912| 0005C4 ori        60000000   1                                                                                                                            1920| 0005D4 bl         4BFFFA2D   0     CALL       PyErr_Clear,0,#ProcAlias",PyErr_Clear",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",lr",fcr",xer",fs
 1912| 0005C8 cmpwi      2C030000   1     C4        cr0=gr3,0                                                                                                    1920| 0005D8 ori        60000000   1
 1912| 0005CC bc         4082FF98   1     BF        CL.36,cr0,0x4/eq,taken=50%(0,0)                                                                              1921| 0005DC lwz        8062002C   1     L4A        gr3=.PyExc_StopIteration(gr2,0)
 1924| 0005D0 addi       38600000   2     LI        gr3=0                                                                                                        1921| 0005E0 lwz        80630000   2     L4A        gr3=PyExc_StopIteration(gr3,0)
    0| 0005D4 lwz        83E1007C   1     L4A       gr31=#stack(gr1,124)                                                                                         1921| 0005E4 bl         4BFFFA1D   0     CALL       PyErr_SetNone,1,(*)_object",gr3,#ProcAlias",PyErr_SetNone",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",
 1925| 0005D8 addi       38210080   1     AI        gr1=gr1,128                                                                                                  1921| 0005E8 ori        60000000   1
    0| 0005DC lwz        80010008   1     L4A       gr0=#stack(gr1,8)                                                                                            1924| 0005EC addi       38600000   1     LI         gr3=0
    0| 0005E0 mtspr      7C0803A6   2     LLR       lr=gr0                                                                                                          0| 0005F0 lwz        80010078   1     L4A        gr0=#stack(gr1,120)
 1925| 0005E4 bclr       4E800020   3     BA        lr                                                                                                           1925| 0005F4 addi       38210070   1     AI         gr1=gr1,112
    0|                                CL.2307:                                                                                                                      0| 0005F8 mtspr      7C0803A6   1     LLR        lr=gr0
    0| 0005E8 lwz        83A10074   1     L4A       gr29=#stack(gr1,116)                                                                                         1925| 0005FC bclr       4E800020   3     BA         lr
    0| 0005EC b          4BFFFF2C   0     B         CL.20,-1                                                                                                        0|                                CL.2367:
 1858|                                CL.19:                                                                                                                     1912| 000600 lwz        80620028   1     L4A        gr3=.PyExc_GeneratorExit(gr2,0)
 1863| 0005F0 addi       39010064   1     AI        gr8=gr1,100                                                                                                  1912| 000604 lwz        80630000   2     L4A        gr3=PyExc_GeneratorExit(gr3,0)
 1860| 0005F4 stw        90010060   1     ST4A      tb(gr1,96)=gr0                                                                                               1912| 000608 bl         4BFFF9F9   0     CALL       gr3=PyErr_ExceptionMatches,1,(*)_object",gr3,#ProcAlias",PyErr_ExceptionMatches",fcr",gr1,cr[01567]",gr0",
 1863| 0005F8 addi       38E10068   1     AI        gr7=gr1,104                                                                                                  1912| 00060C ori        60000000   1
 1863| 0005FC lwz        80820018   1     L4A       gr4=.+CONSTANT_AREA(gr2,0)                                                                                   1912| 000610 cmpwi      2C030000   1     C4         cr0=gr3,0
 1861| 000600 stw        90010064   1     ST4A      val(gr1,100)=gr0                                                                                             1912| 000614 bc         4082FF98   1     BF         CL.36,cr0,0x4/eq,taken=50%(0,0)
 1863| 000604 addi       38A00001   1     LI        gr5=1                                                                                                        1924| 000618 addi       38600000   2     LI         gr3=0
 1863| 000608 addi       38C00003   1     LI        gr6=3                                                                                                           0| 00061C lwz        83E1006C   1     L4A        gr31=#stack(gr1,108)
 1863| 00060C addi       38841080   1     AI        gr4=gr4,4224                                                                                                    0| 000620 lwz        80010078   1     L4A        gr0=#stack(gr1,120)
 1863| 000610 bl         4BFFF9F1   0     CALL      gr3=PyArg_UnpackTuple,7,(*)_object",gr3-gr6,typ",gr7,val",gr8,tb",gr9,#ProcAlias",(*)_object",(*)_object",(  1925| 000624 addi       38210070   1     AI         gr1=gr1,112
 1863| 000614 ori        60000000   1                                                                                                                               0| 000628 mtspr      7C0803A6   1     LLR        lr=gr0
 1863| 000618 cmpwi      2C030000   1     C4        cr0=gr3,0                                                                                                    1925| 00062C bclr       4E800020   3     BA         lr
 1863| 00061C bc         41820054   1     BT        CL.2306,cr0,0x4/eq,taken=30%(30,70)                                                                             0|                                CL.2357:
 1868| 000620 ori        63A30000   2     LR        gr3=gr29                                                                                                        0| 000630 lwz        83A10064   1     L4A        gr29=#stack(gr1,100)
 1868| 000624 lwz        80A10068   1     L4A       gr5=typ(gr1,104)                                                                                                0| 000634 b          4BFFFF2C   0     B          CL.20,-1
 1868| 000628 addi       38800000   1     LI        gr4=0                                                                                                        1858|                                CL.19:
 1868| 00062C lwz        80E10060   1     L4A       gr7=tb(gr1,96)                                                                                               1863| 000638 addi       38841080   1     AI         gr4=gr4,4224
 1868| 000630 lwz        80C10064   1     L4A       gr6=val(gr1,100)                                                                                             1860| 00063C stw        91410058   1     ST4A       tb(gr1,88)=gr10
 1868| 000634 stw        9361FFEC   1     ST4A      #stack_prune(gr1,-20)=gr27                                                                                   1863| 000640 addi       39210058   1     AI         gr9=gr1,88
 1868| 000638 stw        9381FFF0   1     ST4A      #stack_prune(gr1,-16)=gr28                                                                                   1861| 000644 stw        9141005C   1     ST4A       val(gr1,92)=gr10
 1868| 00063C stw        93E1FFFC   1     ST4A      #stack_prune(gr1,-4)=gr31                                                                                    1863| 000648 bl         4BFFF9B9   0     CALL       gr3=PyArg_UnpackTuple,7,(*)_object",gr3-gr6,typ",gr7,val",gr8,tb",gr9,#ProcAlias",(*)_object",(*)_object",
 1868| 000640 bl         48002521   0     CALL      gr3=IPRA.$_gen_throw,5,(*)aggr#3",gr3,gr4,(*)_object",gr5,(*)_object",gr6,(*)_object",gr7,#ProcAlias",IPRA.  1863| 00064C ori        60000000   1
 1868| 000644 lwz        83E1FFFC   1     L4A       gr31=#stack_prune(gr1,-4)                                                                                    1863| 000650 cmpwi      2C030000   1     C4         cr0=gr3,0
 1868| 000648 lwz        8381FFF0   1     L4A       gr28=#stack_prune(gr1,-16)                                                                                   1863| 000654 bc         4182004C   1     BT         CL.2356,cr0,0x4/eq,taken=30%(30,70)
 1868| 00064C lwz        8361FFEC   1     L4A       gr27=#stack_prune(gr1,-20)                                                                                   1868| 000658 ori        63A30000   2     LR         gr3=gr29
 1868| 000650 ori        60640000   1     LR        gr4=gr3                                                                                                      1868| 00065C lwz        80A10060   1     L4A        gr5=typ(gr1,96)
 1872| 000654 lwz        807F0008   1     L4A       gr3=(*)aggr#E.agt_gen(gr31,8)                                                                                1868| 000660 addi       38800000   1     LI         gr4=0
 1872| 000658 stw        93E1FFFC   1     ST4A      #stack_prune(gr1,-4)=gr31                                                                                    1868| 000664 lwz        80E10058   1     L4A        gr7=tb(gr1,88)
 1872| 00065C bl         48000DC5   0     CALL      gr3=IPRA.$async_gen_unwrap_value,2,(*)aggr#4",gr3,(*)_object",gr4,#ProcAlias",IPRA.$async_gen_unwrap_value"  1868| 000668 lwz        80C1005C   1     L4A        gr6=val(gr1,92)
 1872| 000660 lwz        83E1FFFC   1     L4A       gr31=#stack_prune(gr1,-4)                                                                                    1868| 00066C stw        9361FFEC   1     ST4A       #stack_prune(gr1,-20)=gr27
 1872| 000664 ori        60650000   1     LR        gr5=gr3                                                                                                      1868| 000670 stw        9381FFF0   1     ST4A       #stack_prune(gr1,-16)=gr28
    0| 000668 lwz        83A10074   1     L4A       gr29=#stack(gr1,116)                                                                                         1868| 000674 stw        93E1FFFC   1     ST4A       #stack_prune(gr1,-4)=gr31
    0| 00066C b          4BFFFEAC   0     B         CL.20,-1                                                                                                     1868| 000678 bl         48002309   0     CALL       gr3=IPRA.$_gen_throw,5,(*)aggr#3",gr3,gr4,(*)_object",gr5,(*)_object",gr6,(*)_object",gr7,#ProcAlias",IPRA
    0|                                CL.2306:                                                                                                                   1868| 00067C lwz        83E1FFFC   1     L4A        gr31=#stack_prune(gr1,-4)
 1924| 000670 addi       38600000   1     LI        gr3=0                                                                                                        1868| 000680 lwz        8381FFF0   1     L4A        gr28=#stack_prune(gr1,-16)
    0| 000674 lwz        83E1007C   1     L4A       gr31=#stack(gr1,124)                                                                                         1868| 000684 lwz        8361FFEC   1     L4A        gr27=#stack_prune(gr1,-20)
    0| 000678 lwz        83A10074   1     L4A       gr29=#stack(gr1,116)                                                                                         1868| 000688 ori        60640000   1     LR         gr4=gr3







Wed Apr 15 07:30:04 CDT 2020  Page 67


 1925| 00067C addi       38210080   1     AI        gr1=gr1,128                                                                                                  1872| 00068C lwz        807F0008   1     L4A        gr3=(*)aggr#E.agt_gen(gr31,8)
    0| 000680 lwz        80010008   1     L4A       gr0=#stack(gr1,8)                                                                                            1872| 000690 bl         48000C71   0     CALL       gr3=async_gen_unwrap_value,2,(*)aggr#4",gr3,(*)_object",gr4,#ProcAlias",async_gen_unwrap_value",fcr",gr1,c
    0| 000684 mtspr      7C0803A6   2     LLR       lr=gr0                                                                                                       1872| 000694 ori        60650000   1     LR         gr5=gr3
 1925| 000688 bclr       4E800020   3     BA        lr                                                                                                              0| 000698 lwz        83A10064   1     L4A        gr29=#stack(gr1,100)
    0|                                CL.2313:                                                                                                                      0| 00069C b          4BFFFEC4   0     B          CL.20,-1
 1838| 00068C lwz        8062001C   1     L4A       gr3=.PyExc_RuntimeError(gr2,0)                                                                                  0|                                CL.2356:
 1838| 000690 lwz        80820020   1     L4A       gr4=.$STATIC(gr2,0)                                                                                          1924| 0006A0 addi       38600000   1     LI         gr3=0
    0| 000694 lwz        83E1007C   1     L4A       gr31=#stack(gr1,124)                                                                                            0| 0006A4 lwz        83E1006C   1     L4A        gr31=#stack(gr1,108)
    0| 000698 lwz        83A10074   1     L4A       gr29=#stack(gr1,116)                                                                                            0| 0006A8 lwz        83A10064   1     L4A        gr29=#stack(gr1,100)
 1838| 00069C lwz        80630000   1     L4A       gr3=<s143:d0:l4>(gr3,0)                                                                                         0| 0006AC lwz        80010078   1     L4A        gr0=#stack(gr1,120)
 1838| 0006A0 lwz        80840000   1     L4A       gr4=NON_INIT_CORO_MSG(gr4,0)                                                                                 1925| 0006B0 addi       38210070   1     AI         gr1=gr1,112
 1838| 0006A4 bl         4BFFF95D   0     CALL      PyErr_SetString,2,(*)_object",gr3,(*)Cuchar",gr4,#ProcAlias",PyErr_SetString",fcr",gr1,cr[01567]",gr0",gr3"     0| 0006B4 mtspr      7C0803A6   1     LLR        lr=gr0
 1838| 0006A8 ori        60000000   1                                                                                                                            1925| 0006B8 bclr       4E800020   3     BA         lr
 1839| 0006AC addi       38600000   1     LI        gr3=0                                                                                                           0|                                CL.2363:
 1925| 0006B0 addi       38210080   1     AI        gr1=gr1,128                                                                                                  1838| 0006BC lwz        8062001C   1     L4A        gr3=.PyExc_RuntimeError(gr2,0)
    0| 0006B4 lwz        80010008   1     L4A       gr0=#stack(gr1,8)                                                                                            1838| 0006C0 lwz        80820020   1     L4A        gr4=.$STATIC(gr2,0)
    0| 0006B8 mtspr      7C0803A6   2     LLR       lr=gr0                                                                                                          0| 0006C4 lwz        83E1006C   1     L4A        gr31=#stack(gr1,108)
 1925| 0006BC bclr       4E800020   3     BA        lr                                                                                                              0| 0006C8 lwz        83A10064   1     L4A        gr29=#stack(gr1,100)
    0|                                CL.2312:                                                                                                                   1838| 0006CC lwz        80630000   1     L4A        gr3=PyExc_RuntimeError(gr3,0)
 1833| 0006C0 lwz        80620024   1     L4A       gr3=.PyExc_StopAsyncIteration(gr2,0)                                                                         1838| 0006D0 lwz        80840000   1     L4A        gr4=NON_INIT_CORO_MSG(gr4,0)
 1832| 0006C4 addi       38000002   1     LI        gr0=2                                                                                                        1838| 0006D4 bl         4BFFF92D   0     CALL       PyErr_SetString,2,(*)_object",gr3,(*)Cuchar",gr4,#ProcAlias",PyErr_SetString",fcr",gr1,cr[01567]",gr0",gr3
    0| 0006C8 lwz        83C10078   1     L4A       gr30=#stack(gr1,120)                                                                                         1838| 0006D8 ori        60000000   1
    0| 0006CC lwz        83A10074   1     L4A       gr29=#stack(gr1,116)                                                                                         1839| 0006DC addi       38600000   1     LI         gr3=0
 1832| 0006D0 stw        901F0010   1     ST4A      (*)aggr#E.agt_state(gr31,16)=gr0                                                                                0| 0006E0 lwz        80010078   1     L4A        gr0=#stack(gr1,120)
 1833| 0006D4 lwz        80630000   1     L4A       gr3=<s137:d0:l4>(gr3,0)                                                                                      1925| 0006E4 addi       38210070   1     AI         gr1=gr1,112
 1833| 0006D8 bl         4BFFF929   0     CALL      PyErr_SetNone,1,(*)_object",gr3,#ProcAlias",PyErr_SetNone",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",m     0| 0006E8 mtspr      7C0803A6   1     LLR        lr=gr0
 1833| 0006DC ori        60000000   1                                                                                                                            1925| 0006EC bclr       4E800020   3     BA         lr
 1834| 0006E0 addi       38600000   1     LI        gr3=0                                                                                                           0|                                CL.2362:
    0| 0006E4 lwz        83E1007C   1     L4A       gr31=#stack(gr1,124)                                                                                         1833| 0006F0 lwz        80620024   1     L4A        gr3=.PyExc_StopAsyncIteration(gr2,0)
 1925| 0006E8 addi       38210080   1     AI        gr1=gr1,128                                                                                                  1832| 0006F4 addi       38000002   1     LI         gr0=2
    0| 0006EC lwz        80010008   1     L4A       gr0=#stack(gr1,8)                                                                                               0| 0006F8 lwz        83C10068   1     L4A        gr30=#stack(gr1,104)
    0| 0006F0 mtspr      7C0803A6   2     LLR       lr=gr0                                                                                                          0| 0006FC lwz        83A10064   1     L4A        gr29=#stack(gr1,100)
 1925| 0006F4 bclr       4E800020   3     BA        lr                                                                                                           1832| 000700 stw        901F0010   1     ST4A       (*)aggr#E.agt_state(gr31,16)=gr0
 1878|                                CL.13:                                                                                                                     1833| 000704 lwz        80630000   1     L4A        gr3=PyExc_StopAsyncIteration(gr3,0)
 1880| 0006F8 bc         408600AC   0     BF        CL.2315,cr1,0x4/eq,taken=40%(40,60)                                                                          1833| 000708 bl         4BFFF8F9   0     CALL       PyErr_SetNone,1,(*)_object",gr3,#ProcAlias",PyErr_SetNone",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",
 1880|                                CL.29:                                                                                                                     1833| 00070C ori        60000000   1
 1882| 0006FC ori        63A30000   1     LR        gr3=gr29                                                                                                     1834| 000710 addi       38600000   1     LI         gr3=0
 1882| 000700 ori        63C40000   1     LR        gr4=gr30                                                                                                        0| 000714 lwz        83E1006C   1     L4A        gr31=#stack(gr1,108)
 1882| 000704 addi       38A00000   1     LI        gr5=0                                                                                                           0| 000718 lwz        80010078   1     L4A        gr0=#stack(gr1,120)
 1882| 000708 addi       38C00000   1     LI        gr6=0                                                                                                        1925| 00071C addi       38210070   1     AI         gr1=gr1,112
 1882| 00070C bl         48003155   0     CALL      gr3=gen_send_ex,4,(*)aggr#3",gr3,(*)_object",gr4-gr6,#ProcAlias",gen_send_ex",fcr",gr1,cr[01567]",gr0",gr4"     0| 000720 mtspr      7C0803A6   1     LLR        lr=gr0
 1882| 000710 ori        60640000   1     LR        gr4=gr3                                                                                                      1925| 000724 bclr       4E800020   3     BA         lr
    0| 000714 ori        60600000   1     LR        gr0=gr3                                                                                                      1878|                                CL.13:
 1883| 000718 lwz        807F000C   1     L4A       gr3=(*)aggr#E.agt_args(gr31,12)                                                                              1880| 000728 bc         408600AC   0     BF         CL.2365,cr1,0x4/eq,taken=40%(40,60)
 1883| 00071C cmpwi      2C030000   2     C4        cr0=gr3,0                                                                                                    1880|                                CL.29:
 1883| 000720 bc         40820060   1     BF        CL.2316,cr0,0x4/eq,taken=30%(30,70)                                                                          1882| 00072C ori        63A30000   1     LR         gr3=gr29
 1887| 000724 cmpwi      2C000000   2     C4        cr0=gr0,0                                                                                                    1882| 000730 ori        63C40000   1     LR         gr4=gr30
    0| 000728 lwz        83C10078   1     L4A       gr30=#stack(gr1,120)                                                                                         1882| 000734 addi       38A00000   1     LI         gr5=0
    0| 00072C lwz        83A10074   1     L4A       gr29=#stack(gr1,116)                                                                                         1882| 000738 addi       38C00000   1     LI         gr6=0
 1887| 000730 bc         4182FE08   0     BT        check_error,cr0,0x4/eq,taken=30%(30,70)                                                                      1882| 00073C bl         48002F45   0     CALL       gr3=gen_send_ex,4,(*)aggr#3",gr3,(*)_object",gr4-gr6,#ProcAlias",gen_send_ex",fcr",gr1,cr[01567]",gr0",gr4
 1888| 000734 lwz        80020014   1     L4A       gr0=._PyAsyncGenWrappedValue_Type(gr2,0)                                                                     1882| 000740 ori        60640000   1     LR         gr4=gr3
 1882| 000738 ori        60850000   1     LR        gr5=gr4                                                                                                         0| 000744 ori        60600000   1     LR         gr0=gr3
  128| 00073C lwz        80640004   1     L4A       gr3=(*)C_object._object.ob_type(gr4,4)                                                                       1883| 000748 lwz        807F000C   1     L4A        gr3=(*)aggr#E.agt_args(gr31,12)
  128| 000740 cmplw      7C030040   2     CL4       cr0=gr3,gr0                                                                                                  1883| 00074C cmpwi      2C030000   2     C4         cr0=gr3,0
 1888| 000744 bc         4082FDDC   1     BF        CL.2310,cr0,0x4/eq,taken=30%(30,70)                                                                          1883| 000750 bc         40820060   1     BF         CL.2366,cr0,0x4/eq,taken=30%(30,70)
  415| 000748 lwz        80C20004   1     L4A       gr6=._Py_RefTotal(gr2,0)                                                                                     1887| 000754 cmpwi      2C000000   2     C4         cr0=gr0,0







Wed Apr 15 07:30:04 CDT 2020  Page 68


  417| 00074C lwz        80E40000   1     L4A       gr7=(*)_object._object.ob_refcnt(gr4,0)                                                                         0| 000758 lwz        83C10068   1     L4A        gr30=#stack(gr1,104)
    0| 000750 lwz        80620018   1     L4A       gr3=.+CONSTANT_AREA(gr2,0)                                                                                      0| 00075C lwz        83A10064   1     L4A        gr29=#stack(gr1,100)
  408| 000754 addi       38000761   1     LI        gr0=1889                                                                                                     1887| 000760 bc         4182FE20   0     BT         check_error,cr0,0x4/eq,taken=30%(30,70)
  417| 000758 addi       38E7FFFF   1     AI        gr7=gr7,-1                                                                                                   1888| 000764 lwz        80020014   1     L4A        gr0=._PyAsyncGenWrappedValue_Type(gr2,0)
  417| 00075C stw        90E40000   1     ST4A      (*)_object._object.ob_refcnt(gr4,0)=gr7                                                                      1887| 000768 ori        60850000   1     LR         gr5=gr4
  408| 000760 addi       38631110   1     AI        gr3=gr3,4368                                                                                                  128| 00076C lwz        80640004   1     L4A        gr3=(*)C_object._object.ob_type(gr4,4)
  415| 000764 lwz        80860000   1     L4A       gr4=<s117:d0:l4>(gr6,0)                                                                                       128| 000770 cmplw      7C030040   2     CL4        cr0=gr3,gr0
  415| 000768 addi       3884FFFF   2     AI        gr4=gr4,-1                                                                                                   1888| 000774 bc         4082FDF4   1     BF         CL.2360,cr0,0x4/eq,taken=30%(30,70)
  417| 00076C cmpwi      2C070000   1     C4        cr0=gr7,0                                                                                                     415| 000778 lwz        80C20004   1     L4A        gr6=._Py_RefTotal(gr2,0)
  415| 000770 stw        90860000   1     ST4A      <s117:d0:l4>(gr6,0)=gr4                                                                                       417| 00077C lwz        80E40000   1     L4A        gr7=(*)_object._object.ob_refcnt(gr4,0)
  417| 000774 bc         4182FD70   0     BT        CL.1493,cr0,0x4/eq,taken=40%(40,60)                                                                             0| 000780 lwz        80620018   1     L4A        gr3=.+CONSTANT_AREA(gr2,0)
  419| 000778 bc         4180FD38   0     BT        CL.2303,cr0,0x1/lt,taken=40%(40,60)                                                                           408| 000784 addi       38800761   1     LI         gr4=1889
  419| 00077C b          4BFFFCF0   1     B         yield_close,-1                                                                                                417| 000788 addi       3807FFFF   1     AI         gr0=gr7,-1
    0|                                CL.2316:                                                                                                                    417| 00078C stw        90050000   1     ST4A       (*)_object._object.ob_refcnt(gr5,0)=gr0
 1884| 000780 lwz        807F0008   1     L4A       gr3=(*)aggr#E.agt_gen(gr31,8)                                                                                 408| 000790 addi       38631110   1     AI         gr3=gr3,4368
    0| 000784 lwz        83C10078   1     L4A       gr30=#stack(gr1,120)                                                                                          415| 000794 lwz        80E60000   1     L4A        gr7=_Py_RefTotal(gr6,0)
    0| 000788 lwz        83A10074   1     L4A       gr29=#stack(gr1,116)                                                                                          415| 000798 addi       38E7FFFF   2     AI         gr7=gr7,-1
 1884| 00078C bl         48000C95   0     CALL      gr3=IPRA.$async_gen_unwrap_value,2,(*)aggr#4",gr3,(*)_object",gr4,#ProcAlias",IPRA.$async_gen_unwrap_value"   415| 00079C stw        90E60000   1     ST4A       _Py_RefTotal(gr6,0)=gr7
    0| 000790 lwz        83E1007C   1     L4A       gr31=#stack(gr1,124)                                                                                          417| 0007A0 cmpwi      2C000000   1     C4         cr0=gr0,0
 1925| 000794 addi       38210080   1     AI        gr1=gr1,128                                                                                                   417| 0007A4 bc         4182FD88   1     BT         CL.1493,cr0,0x4/eq,taken=40%(40,60)
    0| 000798 lwz        80010008   1     L4A       gr0=#stack(gr1,8)                                                                                             419| 0007A8 bc         4180FD54   1     BT         CL.2353,cr0,0x1/lt,taken=40%(40,60)
    0| 00079C mtspr      7C0803A6   2     LLR       lr=gr0                                                                                                        419| 0007AC b          4BFFFD0C   1     B          yield_close,-1
 1925| 0007A0 bclr       4E800020   3     BA        lr                                                                                                              0|                                CL.2366:
    0|                                CL.2315:                                                                                                                   1884| 0007B0 lwz        807F0008   1     L4A        gr3=(*)aggr#E.agt_gen(gr31,8)
 1880| 0007A4 addi       38A00758   1     LI        gr5=1880                                                                                                        0| 0007B4 lwz        83C10068   1     L4A        gr30=#stack(gr1,104)
 1880| 0007A8 lwz        80620018   1     L4A       gr3=.+CONSTANT_AREA(gr2,0)                                                                                      0| 0007B8 lwz        83A10064   1     L4A        gr29=#stack(gr1,100)
 1880| 0007AC addi       38831110   2     AI        gr4=gr3,4368                                                                                                 1884| 0007BC bl         48000B45   0     CALL       gr3=async_gen_unwrap_value,2,(*)aggr#4",gr3,(*)_object",gr4,#ProcAlias",async_gen_unwrap_value",fcr",gr1,c
 1880| 0007B0 addi       386313BC   1     AI        gr3=gr3,5052                                                                                                    0| 0007C0 lwz        83E1006C   1     L4A        gr31=#stack(gr1,108)
 1880| 0007B4 bl         4BFFF84D   0     CALL      __assert,3,gr3-gr5,#ProcAlias",__assert",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",lr",fcr",xer",f     0| 0007C4 lwz        80010078   1     L4A        gr0=#stack(gr1,120)
 1880| 0007B8 ori        60000000   1                                                                                                                            1925| 0007C8 addi       38210070   1     AI         gr1=gr1,112
    0| 0007BC b          4BFFFF40   0     B         CL.29,-1                                                                                                        0| 0007CC mtspr      7C0803A6   1     LLR        lr=gr0
    0|                                CL.2304:                                                                                                                   1925| 0007D0 bclr       4E800020   3     BA         lr
 1810| 0007C0 stw        90FF0010   1     ST4A      (*)aggr#E.agt_state(gr31,16)=gr7                                                                                0|                                CL.2365:
 1811| 0007C4 lwz        80640000   1     L4A       gr3=<s139:d0:l4>(gr4,0)                                                                                      1880| 0007D4 addi       38A00758   1     LI         gr5=1880
    0| 0007C8 lwz        83C10078   1     L4A       gr30=#stack(gr1,120)                                                                                         1880| 0007D8 lwz        80620018   1     L4A        gr3=.+CONSTANT_AREA(gr2,0)
    0| 0007CC lwz        83A10074   1     L4A       gr29=#stack(gr1,116)                                                                                         1880| 0007DC addi       38831110   2     AI         gr4=gr3,4368
 1811| 0007D0 bl         4BFFF831   0     CALL      PyErr_SetNone,1,(*)_object",gr3,#ProcAlias",PyErr_SetNone",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",m  1880| 0007E0 addi       386313BC   1     AI         gr3=gr3,5052
 1811| 0007D4 ori        60000000   1                                                                                                                            1880| 0007E4 bl         4BFFF81D   0     CALL       __assert,3,gr3-gr5,#ProcAlias",__assert",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",lr",fcr",xer",
 1812| 0007D8 addi       38600000   1     LI        gr3=0                                                                                                        1880| 0007E8 ori        60000000   1
    0| 0007DC lwz        83E1007C   1     L4A       gr31=#stack(gr1,124)                                                                                            0| 0007EC b          4BFFFF40   0     B          CL.29,-1
 1925| 0007E0 addi       38210080   1     AI        gr1=gr1,128                                                                                                     0|                                CL.2354:
    0| 0007E4 lwz        80010008   1     L4A       gr0=#stack(gr1,8)                                                                                            1810| 0007F0 stw        90FF0010   1     ST4A       (*)aggr#E.agt_state(gr31,16)=gr7
    0| 0007E8 mtspr      7C0803A6   2     LLR       lr=gr0                                                                                                          0| 0007F4 lwz        83C10068   1     L4A        gr30=#stack(gr1,104)
 1925| 0007EC bclr       4E800020   3     BA        lr                                                                                                              0| 0007F8 lwz        83A10064   1     L4A        gr29=#stack(gr1,100)
    0|                                CL.2311:                                                                                                                   1811| 0007FC bl         4BFFF805   0     CALL       PyErr_SetNone,1,(*)_object",gr3,#ProcAlias",PyErr_SetNone",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",
 1803| 0007F0 lwz        80A2001C   1     L4A       gr5=.PyExc_RuntimeError(gr2,0)                                                                               1811| 000800 ori        60000000   1
 1803| 0007F4 lwz        80820018   1     L4A       gr4=.+CONSTANT_AREA(gr2,0)                                                                                   1812| 000804 addi       38600000   1     LI         gr3=0
    0| 0007F8 lwz        83E1007C   1     L4A       gr31=#stack(gr1,124)                                                                                            0| 000808 lwz        83E1006C   1     L4A        gr31=#stack(gr1,108)
    0| 0007FC lwz        83C10078   1     L4A       gr30=#stack(gr1,120)                                                                                            0| 00080C lwz        80010078   1     L4A        gr0=#stack(gr1,120)
    0| 000800 lwz        83A10074   1     L4A       gr29=#stack(gr1,116)                                                                                         1925| 000810 addi       38210070   1     AI         gr1=gr1,112
 1803| 000804 addi       38841324   1     AI        gr4=gr4,4900                                                                                                    0| 000814 mtspr      7C0803A6   1     LLR        lr=gr0
 1803| 000808 lwz        80650000   1     L4A       gr3=<s143:d0:l4>(gr5,0)                                                                                      1925| 000818 bclr       4E800020   3     BA         lr
 1803| 00080C bl         4BFFF7F5   0     CALL      PyErr_SetString,2,(*)_object",gr3,gr4,#ProcAlias",PyErr_SetString",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"     0|                                CL.2361:
 1803| 000810 ori        60000000   1                                                                                                                            1803| 00081C lwz        8062001C   1     L4A        gr3=.PyExc_RuntimeError(gr2,0)
 1806| 000814 addi       38600000   1     LI        gr3=0                                                                                                        1803| 000820 lwz        80820018   1     L4A        gr4=.+CONSTANT_AREA(gr2,0)
 1925| 000818 addi       38210080   1     AI        gr1=gr1,128                                                                                                     0| 000824 lwz        83E1006C   1     L4A        gr31=#stack(gr1,108)







Wed Apr 15 07:30:04 CDT 2020  Page 69


    0| 00081C lwz        80010008   1     L4A       gr0=#stack(gr1,8)                                                                                               0| 000828 lwz        83C10068   1     L4A        gr30=#stack(gr1,104)
    0| 000820 mtspr      7C0803A6   2     LLR       lr=gr0                                                                                                       1803| 00082C addi       38841324   1     AI         gr4=gr4,4900
 1925| 000824 bclr       4E800020   3     BA        lr                                                                                                           1803| 000830 lwz        80630000   1     L4A        gr3=PyExc_RuntimeError(gr3,0)
     |               Tag Table                                                                                                                                   1803| 000834 bl         4BFFF7CD   0     CALL       PyErr_SetString,2,(*)_object",gr3,gr4,#ProcAlias",PyErr_SetString",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0
     | 000828        00000000 00002041 80030200 00000000 00000568 00156173                                                                                       1803| 000838 ori        60000000   1
     | 000840        796E635F 67656E5F 61746872 6F775F73 656E64                                                                                                  1806| 00083C addi       38600000   1     LI         gr3=0
     |               Instruction count          346                                                                                                                 0| 000840 lwz        80010078   1     L4A        gr0=#stack(gr1,120)
     |               Straight-line exec time    372                                                                                                              1925| 000844 addi       38210070   1     AI         gr1=gr1,112
 GPR's set/used:   ssus ssss ssss s---  ---- ---- ---- ----                                                                                                         0| 000848 mtspr      7C0803A6   1     LLR        lr=gr0
 FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----                                                                                                      1925| 00084C bclr       4E800020   3     BA         lr
 CCR's set/used:   ss-- -sss                                                                                                                                         |               Tag Table
     | 000000                             PDEF     async_gen_athrow_traverse                                                                                         | 000850        00000000 00002041 80030200 00000000 00000550 00156173
 1787|                                    PROC      o,visit,arg,gr3-gr5                                                                                              | 000868        796E635F 67656E5F 61746872 6F775F73 656E64
    0| 000860 mfspr      7C0802A6   1     LFLR      gr0=lr                                                                                                           |               Instruction count          340
    0| 000864 ori        60660000   1     LR        gr6=gr3                                                                                                          |               Straight-line exec time    353
 1789| 000868 lwz        80630008   1     L4A       gr3=(*)aggr#E.agt_gen(gr3,8)                                                                                 GPR's set/used:   su-s ssss ssss s---  ---- ---- ---- ----
 1789| 00086C cmpwi      2C030000   2     C4        cr0=gr3,0                                                                                                    FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----
    0| 000870 stw        90010008   1     ST4A      #stack(gr1,8)=gr0                                                                                            CCR's set/used:   ss-- -sss
    0| 000874 ori        60A00000   1     LR        gr0=gr5                                                                                                          | 000000                             PDEF       async_gen_athrow_traverse
    0| 000878 stwu       9421FFA0   1     ST4U      gr1,#stack(gr1,-96)=gr1                                                                                      1787|                                    PROC       o_123_5_124_5,visit_123_5_124_5,arg_123_5_124_5,gr3-gr5
    0| 00087C ori        60850000   1     LR        gr5=gr4                                                                                                      1789| 000880 lwz        80030008   1     L4A        gr0=(*)aggr#E.agt_gen(gr3,8)
 1789| 000880 ori        60040000   1     LR        gr4=gr0                                                                                                      1789| 000884 cmpwi      2C000000   2     C4         cr0=gr0,0
 1789| 000884 stw        90410014   1     ST4A      #cur_toc(gr1,20)=gr2                                                                                         1789| 000888 bc         4082001C   1     BF         CL.1789,cr0,0x4/eq,taken=30%(30,70)
 1789| 000888 bc         41820080   0     BT        CL.2298,cr0,0x4/eq,taken=30%(30,70)                                                                          1790| 00088C lwz        8003000C   1     L4A        gr0=(*)aggr#E.agt_args(gr3,12)
    0| 00088C stw        90C1004C   1     ST4A      #parameter_store0(gr1,76)=gr6                                                                                1790| 000890 cmpwi      2C000000   2     C4         cr0=gr0,0
    0| 000890 stw        90010050   1     ST4A      #parameter_store1(gr1,80)=gr0                                                                                1790| 000894 bc         4082000C   1     BF         CL.2347,cr0,0x4/eq,taken=40%(40,60)
    0| 000894 stw        90A10054   1     ST4A      #parameter_store2(gr1,84)=gr5                                                                                1791| 000898 addi       38600000   1     LI         gr3=0
 1789| 000898 lwz        80050000   1     L4A       gr0=#fnc_adr(gr5,0)                                                                                          1792| 00089C bclr       4E800020   0     BA         lr
 1789| 00089C lwz        81650008   1     L4A       gr11=#new_env(gr5,8)                                                                                            0|                                CL.2347:
 1789| 0008A0 mtspr      7C0903A6   1     LCTR      ctr=gr0                                                                                                      1792| 0008A0 b          48005BE0   0     CALLF      gr3=async_gen_athrow_traverse at AF123_5,3,gr3-gr5,fcr",async_gen_athrow_traverse at AF123_5",gr1,cr[01567]",gr0
 1789| 0008A4 lwz        80450004   1     CALL      gr3=gr5,2,(*)_object",gr3,(*)void",gr4,#ProcAlias",fcr",(*)int()",gr1,cr[01567]",gr0",gr4"-gr12",fp0"-fp13"     0|                                CL.1789:
 1789| 0008A8 bcctrl     4E800421   0                                                                                                                            1792| 0008A4 b          48005C7C   0     CALLF      gr3=async_gen_athrow_traverse at AF124_5,3,gr3-gr5,fcr",async_gen_athrow_traverse at AF124_5",gr1,cr[01567]",gr0
 1789| 0008AC lwz        80410014   1                                                                                                                                |               Tag Table
 1789| 0008B0 cmpwi      2C030000   1     C4        cr0=gr3,0                                                                                                        | 0008A8        00000000 00002040 00000300 00000000 00000028 00196173
 1789| 0008B4 lwz        80C1004C   1     L4A       gr6=#parameter_store0(gr1,76)                                                                                    | 0008C0        796E635F 67656E5F 61746872 6F775F74 72617665 727365
 1789| 0008B8 lwz        80010050   1     L4A       gr0=#parameter_store1(gr1,80)                                                                                    |               Instruction count           10
 1789| 0008BC lwz        80A10054   1     L4A       gr5=#parameter_store2(gr1,84)                                                                                    |               Straight-line exec time      9
 1789| 0008C0 bc         40820038   0     BF        CL.724,cr0,0x4/eq,taken=30%(30,70)                                                                           GPR's set/used:   ssus ssss ssss s---  ---- ---- ---- -sss
 1790| 0008C4 lwz        8066000C   2     L4A       gr3=(*)aggr#E.agt_args(gr6,12)                                                                               FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----
 1790| 0008C8 cmpwi      2C030000   2     C4        cr0=gr3,0                                                                                                    CCR's set/used:   ss-- -sss
 1790| 0008CC bc         41820028   1     BT        CL.51,cr0,0x4/eq,taken=30%(30,70)                                                                                | 000000                             PDEF       async_gen_athrow_dealloc
    0|                                CL.1679:                                                                                                                   1777|                                    PROC       o,gr3
 1790| 0008D0 ori        60040000   1     LR        gr4=gr0                                                                                                         0| 0008E0 mfspr      7C0802A6   1     LFLR       gr0=lr
 1790| 0008D4 lwz        80050000   1     L4A       gr0=#fnc_adr(gr5,0)                                                                                             0| 0008E4 stwu       9421FFB0   1     ST4U       gr1,#stack(gr1,-80)=gr1
 1790| 0008D8 lwz        81650008   1     L4A       gr11=#new_env(gr5,8)                                                                                            0| 0008E8 stw        90010058   1     ST4A       #stack(gr1,88)=gr0
 1790| 0008DC mtspr      7C0903A6   1     LCTR      ctr=gr0                                                                                                         0| 0008EC stw        93E1004C   1     ST4A       #stack(gr1,76)=gr31
 1790| 0008E0 lwz        80450004   1     CALL      gr3=gr5,2,(*)_object",gr3,(*)void",gr4,#ProcAlias",fcr",(*)int()",gr1,cr[01567]",gr0",gr4"-gr12",fp0"-fp13"     0| 0008F0 ori        607F0000   1     LR         gr31=gr3
 1790| 0008E4 bcctrl     4E800421   0                                                                                                                               0| 0008F4 stw        93C10048   1     ST4A       #stack(gr1,72)=gr30
 1790| 0008E8 lwz        80410014   1                                                                                                                               0| 0008F8 stw        93A10044   1     ST4A       #stack(gr1,68)=gr29
 1790| 0008EC cmpwi      2C030000   1     C4        cr0=gr3,0                                                                                                      73| 0008FC addi       3BA00000   1     LI         gr29=0
 1790| 0008F0 bc         40820008   1     BF        CL.724,cr0,0x4/eq,taken=50%(0,0)                                                                                0| 000900 lwz        83C20018   1     L4A        gr30=.+CONSTANT_AREA(gr2,0)
 1790|                                CL.51:                                                                                                                       64| 000904 lwz        8003FFF8   1     L4A        gr0=(*)_object%##2(gr3,-8)
 1791| 0008F4 addi       38600000   1     LI        gr3=0                                                                                                          64| 000908 cmpwi      2C000000   2     C4         cr0=gr0,0
 1792|                                CL.724:                                                                                                                      64| 00090C bc         41820188   1     BT         CL.1797,cr0,0x4/eq,taken=10%(10,90)
 1792| 0008F8 addi       38210060   1     AI        gr1=gr1,96                                                                                                     69| 000910 lwz        80C3FFFC   1     L4A        gr6=(*)aggr#2._gc_prev(gr3,-4)
    0| 0008FC lwz        80010008   1     L4A       gr0=#stack(gr1,8)                                                                                              70| 000914 lwz        8063FFF8   1     L4A        gr3=(*)aggr#2._gc_next(gr3,-8)







Wed Apr 15 07:30:04 CDT 2020  Page 70


    0| 000900 mtspr      7C0803A6   2     LLR       lr=gr0                                                                                                       1780| 000918 lwz        80BF0008   1     L4A        gr5=(*)aggr#E.agt_gen(gr31,8)
 1792| 000904 bclr       4E800020   3     BA        lr                                                                                                              0| 00091C or.        7CA02B79   2     LR_R       gr0,cr0=gr5
    0|                                CL.2298:                                                                                                                     69| 000920 rlwinm     54C4003A   1     RN4        gr4=gr6,0,0xFFFFFFFC
 1790| 000908 lwz        8066000C   1     L4A       gr3=(*)aggr#E.agt_args(gr6,12)                                                                                 72| 000924 lwz        80030004   1     L4A        gr0=(*)aggr#2._gc_prev(gr3,4)
 1790| 00090C cmpwi      2C030000   2     C4        cr0=gr3,0                                                                                                      71| 000928 stw        90640000   1     ST4A       (*)aggr#2._gc_next(gr4,0)=gr3
 1790| 000910 bc         4182FFE4   1     BT        CL.51,cr0,0x4/eq,taken=30%(30,70)                                                                              73| 00092C stw        93BFFFF8   1     ST4A       (*)aggr#2._gc_next(gr31,-8)=gr29
    0| 000914 b          4BFFFFBC   1     B         CL.1679,-1                                                                                                     72| 000930 rlwimi     50C0003A   1     RI4        gr0=gr6,0,gr0,0xFFFFFFFC
     |               Tag Table                                                                                                                                     72| 000934 stw        90030004   1     ST4A       (*)aggr#2._gc_prev(gr3,4)=gr0
     | 000918        00000000 00002041 80000300 00000000 000000B8 00196173                                                                                         74| 000938 lwz        807FFFFC   1     L4A        gr3=(*)aggr#2._gc_prev(gr31,-4)
     | 000930        796E635F 67656E5F 61746872 6F775F74 72617665 727365                                                                                           74| 00093C rlwinm     546007FE   2     RN4        gr0=gr3,0,0x1
     |               Instruction count           46                                                                                                                74| 000940 stw        901FFFFC   1     ST4A       (*)aggr#2._gc_prev(gr31,-4)=gr0
     |               Straight-line exec time     49                                                                                                              1780| 000944 bc         41820030   0     BT         CL.1791,cr0,0x4/eq,taken=50%(0,0)
 GPR's set/used:   ssus ssss ssss s---  ---- ---- ---- -sss                                                                                                      1780| 000948 stw        93BF0008   1     ST4A       (*)aggr#E.agt_gen(gr31,8)=gr29
 FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----                                                                                                       415| 00094C lwz        80820004   1     L4A        gr4=._Py_RefTotal(gr2,0)
 CCR's set/used:   ss-- -sss                                                                                                                                      417| 000950 lwz        80650000   1     L4A        gr3=(*)_object._object.ob_refcnt(gr5,0)
     | 000000                             PDEF     async_gen_athrow_dealloc                                                                                       417| 000954 addi       3803FFFF   2     AI         gr0=gr3,-1
 1777|                                    PROC      o,gr3                                                                                                         417| 000958 stw        90050000   1     ST4A       (*)_object._object.ob_refcnt(gr5,0)=gr0
    0| 000960 mfspr      7C0802A6   1     LFLR      gr0=lr                                                                                                        415| 00095C lwz        80640000   1     L4A        gr3=_Py_RefTotal(gr4,0)
    0| 000964 stw        90010008   2     ST4A      #stack(gr1,8)=gr0                                                                                             415| 000960 addi       38C3FFFF   2     AI         gr6=gr3,-1
    0| 000968 stw        93E1FFFC   1     ST4A      #stack(gr1,-4)=gr31                                                                                           415| 000964 stw        90C40000   1     ST4A       _Py_RefTotal(gr4,0)=gr6
    0| 00096C ori        607F0000   1     LR        gr31=gr3                                                                                                      417| 000968 cmpwi      2C000000   1     C4         cr0=gr0,0
    0| 000970 stw        93C1FFF8   1     ST4A      #stack(gr1,-8)=gr30                                                                                           417| 00096C bc         41820118   1     BT         CL.1483,cr0,0x4/eq,taken=40%(40,60)
    0| 000974 stw        93A1FFF4   1     ST4A      #stack(gr1,-12)=gr29                                                                                          419| 000970 bc         418000F4   1     BT         CL.2340,cr0,0x1/lt,taken=40%(40,60)
   73| 000978 addi       3BA00000   1     LI        gr29=0                                                                                                          0|                                CL.1791:
    0| 00097C lwz        83C20018   1     L4A       gr30=.+CONSTANT_AREA(gr2,0)                                                                                  1781| 000974 lwz        80BF000C   1     L4A        gr5=(*)aggr#E.agt_args(gr31,12)
   64| 000980 lwz        8003FFF8   1     L4A       gr0=(*)_object%##2(gr3,-8)                                                                                      0| 000978 or.        7CA02B79   2     LR_R       gr0,cr0=gr5
    0| 000984 stwu       9421FFB0   1     ST4U      gr1,#stack(gr1,-80)=gr1                                                                                      1781| 00097C bc         418200C0   1     BT         CL.2341,cr0,0x4/eq,taken=30%(30,70)
   64| 000988 cmpwi      2C000000   1     C4        cr0=gr0,0                                                                                                       0|                                CL.1792:
   64| 00098C bc         41820188   1     BT        CL.1688,cr0,0x4/eq,taken=10%(10,90)                                                                           415| 000980 lwz        80820004   1     L4A        gr4=._Py_RefTotal(gr2,0)
   69| 000990 lwz        80C3FFFC   1     L4A       gr6=(*)aggr#2._gc_prev(gr3,-4)                                                                                417| 000984 lwz        80650000   1     L4A        gr3=(*)_object._object.ob_refcnt(gr5,0)
   70| 000994 lwz        8063FFF8   1     L4A       gr3=(*)aggr#2._gc_next(gr3,-8)                                                                               1781| 000988 stw        93BF000C   1     ST4A       (*)aggr#E.agt_args(gr31,12)=gr29
 1780| 000998 lwz        80BF0008   1     L4A       gr5=(*)aggr#E.agt_gen(gr31,8)                                                                                 417| 00098C addi       3803FFFF   1     AI         gr0=gr3,-1
   69| 00099C rlwinm     54C4003A   1     RN4       gr4=gr6,0,0xFFFFFFFC                                                                                          417| 000990 stw        90050000   1     ST4A       (*)_object._object.ob_refcnt(gr5,0)=gr0
    0| 0009A0 or.        7CA02B79   1     LR_R      gr0,cr0=gr5                                                                                                   415| 000994 lwz        80640000   1     L4A        gr3=_Py_RefTotal(gr4,0)
   72| 0009A4 lwz        80030004   1     L4A       gr0=(*)aggr#2._gc_prev(gr3,4)                                                                                 415| 000998 addi       38C3FFFF   2     AI         gr6=gr3,-1
   71| 0009A8 stw        90640000   1     ST4A      (*)aggr#2._gc_next(gr4,0)=gr3                                                                                 415| 00099C stw        90C40000   1     ST4A       _Py_RefTotal(gr4,0)=gr6
   73| 0009AC stw        93BFFFF8   1     ST4A      (*)aggr#2._gc_next(gr31,-8)=gr29                                                                              417| 0009A0 cmpwi      2C000000   1     C4         cr0=gr0,0
   72| 0009B0 rlwimi     50C0003A   1     RI4       gr0=gr6,0,gr0,0xFFFFFFFC                                                                                      417| 0009A4 bc         41820064   1     BT         CL.1487,cr0,0x4/eq,taken=40%(40,60)
   72| 0009B4 stw        90030004   1     ST4A      (*)aggr#2._gc_prev(gr3,4)=gr0                                                                                   0| 0009A8 lwz        83A10044   1     L4A        gr29=#stack(gr1,68)
   74| 0009B8 lwz        807FFFFC   1     L4A       gr3=(*)aggr#2._gc_prev(gr31,-4)                                                                               419| 0009AC bc         40800038   0     BF         CL.2339,cr0,0x1/lt,taken=50%(0,0)
   74| 0009BC rlwinm     546007FE   2     RN4       gr0=gr3,0,0x1                                                                                                 420| 0009B0 addi       387E1110   2     AI         gr3=gr30,4368
   74| 0009C0 stw        901FFFFC   1     ST4A      (*)aggr#2._gc_prev(gr31,-4)=gr0                                                                               420| 0009B4 addi       388006F5   1     LI         gr4=1781
 1780| 0009C4 bc         41820030   0     BT        CL.1682,cr0,0x4/eq,taken=50%(0,0)                                                                             420| 0009B8 bl         4BFFF649   0     CALL       _Py_NegativeRefcount,3,(*)Cuchar",gr3,gr4,(*)_object",gr5,#ProcAlias",_Py_NegativeRefcount",fcr",gr1,cr[01
 1780| 0009C8 stw        93BF0008   1     ST4A      (*)aggr#E.agt_gen(gr31,8)=gr29                                                                                420| 0009BC ori        60000000   1
  415| 0009CC lwz        80820004   1     L4A       gr4=._Py_RefTotal(gr2,0)                                                                                     1782| 0009C0 ori        63E30000   1     LR         gr3=gr31
  417| 0009D0 lwz        80650000   1     L4A       gr3=(*)_object._object.ob_refcnt(gr5,0)                                                                      1782| 0009C4 bl         4BFFF63D   0     CALL       PyObject_GC_Del,1,(*)void",gr3,#ProcAlias",PyObject_GC_Del",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13"
  417| 0009D4 addi       3803FFFF   2     AI        gr0=gr3,-1                                                                                                   1782| 0009C8 ori        60000000   1
  417| 0009D8 stw        90050000   1     ST4A      (*)_object._object.ob_refcnt(gr5,0)=gr0                                                                         0| 0009CC lwz        83C10048   1     L4A        gr30=#stack(gr1,72)
  415| 0009DC lwz        80640000   1     L4A       gr3=<s117:d0:l4>(gr4,0)                                                                                         0| 0009D0 lwz        83E1004C   1     L4A        gr31=#stack(gr1,76)
  415| 0009E0 addi       38C3FFFF   2     AI        gr6=gr3,-1                                                                                                      0| 0009D4 lwz        80010058   1     L4A        gr0=#stack(gr1,88)
  415| 0009E4 stw        90C40000   1     ST4A      <s117:d0:l4>(gr4,0)=gr6                                                                                      1783| 0009D8 addi       38210050   1     AI         gr1=gr1,80
  417| 0009E8 cmpwi      2C000000   1     C4        cr0=gr0,0                                                                                                       0| 0009DC mtspr      7C0803A6   1     LLR        lr=gr0
  417| 0009EC bc         41820118   1     BT        CL.1483,cr0,0x4/eq,taken=40%(40,60)                                                                          1783| 0009E0 bclr       4E800020   3     BA         lr
  419| 0009F0 bc         418000F4   1     BT        CL.2295,cr0,0x1/lt,taken=40%(40,60)                                                                             0|                                CL.2339:
    0|                                CL.1682:                                                                                                                   1782| 0009E4 ori        63E30000   1     LR         gr3=gr31
 1781| 0009F4 lwz        80BF000C   1     L4A       gr5=(*)aggr#E.agt_args(gr31,12)                                                                                 0| 0009E8 lwz        83C10048   1     L4A        gr30=#stack(gr1,72)







Wed Apr 15 07:30:04 CDT 2020  Page 71


    0| 0009F8 or.        7CA02B79   2     LR_R      gr0,cr0=gr5                                                                                                  1782| 0009EC bl         4BFFF615   0     CALL       PyObject_GC_Del,1,(*)void",gr3,#ProcAlias",PyObject_GC_Del",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13"
 1781| 0009FC bc         418200C0   1     BT        CL.2296,cr0,0x4/eq,taken=30%(30,70)                                                                          1782| 0009F0 ori        60000000   1
    0|                                CL.1683:                                                                                                                      0| 0009F4 lwz        83E1004C   1     L4A        gr31=#stack(gr1,76)
  415| 000A00 lwz        80820004   1     L4A       gr4=._Py_RefTotal(gr2,0)                                                                                        0| 0009F8 lwz        80010058   1     L4A        gr0=#stack(gr1,88)
  417| 000A04 lwz        80650000   1     L4A       gr3=(*)_object._object.ob_refcnt(gr5,0)                                                                      1783| 0009FC addi       38210050   1     AI         gr1=gr1,80
 1781| 000A08 stw        93BF000C   1     ST4A      (*)aggr#E.agt_args(gr31,12)=gr29                                                                                0| 000A00 mtspr      7C0803A6   1     LLR        lr=gr0
  417| 000A0C addi       3803FFFF   1     AI        gr0=gr3,-1                                                                                                   1783| 000A04 bclr       4E800020   3     BA         lr
  417| 000A10 stw        90050000   1     ST4A      (*)_object._object.ob_refcnt(gr5,0)=gr0                                                                       423|                                CL.1487:
  415| 000A14 lwz        80640000   1     L4A       gr3=<s117:d0:l4>(gr4,0)                                                                                       425| 000A08 ori        60A30000   1     LR         gr3=gr5
  415| 000A18 addi       38C3FFFF   2     AI        gr6=gr3,-1                                                                                                      0| 000A0C lwz        83C10048   1     L4A        gr30=#stack(gr1,72)
  415| 000A1C stw        90C40000   1     ST4A      <s117:d0:l4>(gr4,0)=gr6                                                                                         0| 000A10 lwz        83A10044   1     L4A        gr29=#stack(gr1,68)
  417| 000A20 cmpwi      2C000000   1     C4        cr0=gr0,0                                                                                                     425| 000A14 bl         4BFFF5ED   0     CALL       _Py_Dealloc,1,(*)_object",gr3,#ProcAlias",_Py_Dealloc",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",
  417| 000A24 bc         41820064   1     BT        CL.1487,cr0,0x4/eq,taken=40%(40,60)                                                                           425| 000A18 ori        60000000   1
    0| 000A28 lwz        83A10044   1     L4A       gr29=#stack(gr1,68)                                                                                          1782| 000A1C ori        63E30000   1     LR         gr3=gr31
  419| 000A2C bc         40800038   0     BF        CL.2294,cr0,0x1/lt,taken=50%(0,0)                                                                            1782| 000A20 bl         4BFFF5E1   0     CALL       PyObject_GC_Del,1,(*)void",gr3,#ProcAlias",PyObject_GC_Del",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13"
  420| 000A30 addi       387E1110   2     AI        gr3=gr30,4368                                                                                                1782| 000A24 ori        60000000   1
  420| 000A34 addi       388006F5   1     LI        gr4=1781                                                                                                        0| 000A28 lwz        83E1004C   1     L4A        gr31=#stack(gr1,76)
  420| 000A38 bl         4BFFF5C9   0     CALL      _Py_NegativeRefcount,3,(*)Cuchar",gr3,gr4,(*)_object",gr5,#ProcAlias",_Py_NegativeRefcount",fcr",gr1,cr[015     0| 000A2C lwz        80010058   1     L4A        gr0=#stack(gr1,88)
  420| 000A3C ori        60000000   1                                                                                                                            1783| 000A30 addi       38210050   1     AI         gr1=gr1,80
 1782| 000A40 ori        63E30000   1     LR        gr3=gr31                                                                                                        0| 000A34 mtspr      7C0803A6   1     LLR        lr=gr0
 1782| 000A44 bl         4BFFF5BD   0     CALL      PyObject_GC_Del,1,(*)void",gr3,#ProcAlias",PyObject_GC_Del",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",  1783| 000A38 bclr       4E800020   3     BA         lr
 1782| 000A48 ori        60000000   1                                                                                                                               0|                                CL.2341:
    0| 000A4C lwz        83C10048   1     L4A       gr30=#stack(gr1,72)                                                                                          1782| 000A3C ori        63E30000   1     LR         gr3=gr31
    0| 000A50 lwz        83E1004C   1     L4A       gr31=#stack(gr1,76)                                                                                             0| 000A40 lwz        83C10048   1     L4A        gr30=#stack(gr1,72)
 1783| 000A54 addi       38210050   1     AI        gr1=gr1,80                                                                                                      0| 000A44 lwz        83A10044   1     L4A        gr29=#stack(gr1,68)
    0| 000A58 lwz        80010008   1     L4A       gr0=#stack(gr1,8)                                                                                            1782| 000A48 bl         4BFFF5B9   0     CALL       PyObject_GC_Del,1,(*)void",gr3,#ProcAlias",PyObject_GC_Del",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13"
    0| 000A5C mtspr      7C0803A6   2     LLR       lr=gr0                                                                                                       1782| 000A4C ori        60000000   1
 1783| 000A60 bclr       4E800020   3     BA        lr                                                                                                              0| 000A50 lwz        83E1004C   1     L4A        gr31=#stack(gr1,76)
    0|                                CL.2294:                                                                                                                      0| 000A54 lwz        80010058   1     L4A        gr0=#stack(gr1,88)
 1782| 000A64 ori        63E30000   1     LR        gr3=gr31                                                                                                     1783| 000A58 addi       38210050   1     AI         gr1=gr1,80
    0| 000A68 lwz        83C10048   1     L4A       gr30=#stack(gr1,72)                                                                                             0| 000A5C mtspr      7C0803A6   1     LLR        lr=gr0
 1782| 000A6C bl         4BFFF595   0     CALL      PyObject_GC_Del,1,(*)void",gr3,#ProcAlias",PyObject_GC_Del",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",  1783| 000A60 bclr       4E800020   3     BA         lr
 1782| 000A70 ori        60000000   1                                                                                                                               0|                                CL.2340:
    0| 000A74 lwz        83E1004C   1     L4A       gr31=#stack(gr1,76)                                                                                           420| 000A64 addi       387E1110   1     AI         gr3=gr30,4368
 1783| 000A78 addi       38210050   1     AI        gr1=gr1,80                                                                                                    420| 000A68 addi       388006F4   1     LI         gr4=1780
    0| 000A7C lwz        80010008   1     L4A       gr0=#stack(gr1,8)                                                                                             420| 000A6C bl         4BFFF595   0     CALL       _Py_NegativeRefcount,3,(*)Cuchar",gr3,gr4,(*)_object",gr5,#ProcAlias",_Py_NegativeRefcount",fcr",gr1,cr[01
    0| 000A80 mtspr      7C0803A6   2     LLR       lr=gr0                                                                                                        420| 000A70 ori        60000000   1
 1783| 000A84 bclr       4E800020   3     BA        lr                                                                                                           1781| 000A74 lwz        80BF000C   1     L4A        gr5=(*)aggr#E.agt_args(gr31,12)
  423|                                CL.1487:                                                                                                                      0| 000A78 or.        7CA02B79   2     LR_R       gr0,cr0=gr5
  425| 000A88 ori        60A30000   1     LR        gr3=gr5                                                                                                      1781| 000A7C bc         4082FF04   1     BF         CL.1792,cr0,0x4/eq,taken=70%(70,30)
    0| 000A8C lwz        83C10048   1     L4A       gr30=#stack(gr1,72)                                                                                             0| 000A80 b          4BFFFFBC   1     B          CL.2341,-1
    0| 000A90 lwz        83A10044   1     L4A       gr29=#stack(gr1,68)                                                                                           423|                                CL.1483:
  425| 000A94 bl         4BFFF56D   0     CALL      _Py_Dealloc,1,(*)_object",gr3,#ProcAlias",_Py_Dealloc",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",l   425| 000A84 ori        60A30000   1     LR         gr3=gr5
  425| 000A98 ori        60000000   1                                                                                                                             425| 000A88 bl         4BFFF579   0     CALL       _Py_Dealloc,1,(*)_object",gr3,#ProcAlias",_Py_Dealloc",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",
 1782| 000A9C ori        63E30000   1     LR        gr3=gr31                                                                                                      425| 000A8C ori        60000000   1
 1782| 000AA0 bl         4BFFF561   0     CALL      PyObject_GC_Del,1,(*)void",gr3,#ProcAlias",PyObject_GC_Del",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",     0| 000A90 b          4BFFFEE4   0     B          CL.1791,-1
 1782| 000AA4 ori        60000000   1                                                                                                                               0|                                CL.1797:
    0| 000AA8 lwz        83E1004C   1     L4A       gr31=#stack(gr1,76)                                                                                            64| 000A94 addi       389E13E4   1     AI         gr4=gr30,5092
 1783| 000AAC addi       38210050   1     AI        gr1=gr1,80                                                                                                     64| 000A98 addi       38BE140C   1     AI         gr5=gr30,5132
    0| 000AB0 lwz        80010008   1     L4A       gr0=#stack(gr1,8)                                                                                              64| 000A9C addi       38DE1110   1     AI         gr6=gr30,4368
    0| 000AB4 mtspr      7C0803A6   2     LLR       lr=gr0                                                                                                         64| 000AA0 addi       38E006F3   1     LI         gr7=1779
 1783| 000AB8 bclr       4E800020   3     BA        lr                                                                                                             64| 000AA4 addi       391E1438   1     AI         gr8=gr30,5176
    0|                                CL.2296:                                                                                                                     64| 000AA8 bl         4BFFF559   0     CALL       _PyObject_AssertFailed,6,(*)_object",gr3-gr5,(*)Cuchar",gr6-gr8,#ProcAlias",_PyObject_AssertFailed",fcr",g
 1782| 000ABC ori        63E30000   1     LR        gr3=gr31                                                                                                       64| 000AAC ori        60000000   1
    0| 000AC0 lwz        83C10048   1     L4A       gr30=#stack(gr1,72)                                                                                            64| 000AB0 tw         7C8E7008   1     TRAP       9
    0| 000AC4 lwz        83A10044   1     L4A       gr29=#stack(gr1,68)                                                                                              | 000AB4 b          48000000   0







Wed Apr 15 07:30:04 CDT 2020  Page 72


 1782| 000AC8 bl         4BFFF539   0     CALL      PyObject_GC_Del,1,(*)void",gr3,#ProcAlias",PyObject_GC_Del",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",      |               Tag Table
 1782| 000ACC ori        60000000   1                                                                                                                                | 000AB8        00000000 00002041 80030100 00000000 000001D8 00186173
    0| 000AD0 lwz        83E1004C   1     L4A       gr31=#stack(gr1,76)                                                                                              | 000AD0        796E635F 67656E5F 61746872 6F775F64 65616C6C 6F63
 1783| 000AD4 addi       38210050   1     AI        gr1=gr1,80                                                                                                       |               Instruction count          118
    0| 000AD8 lwz        80010008   1     L4A       gr0=#stack(gr1,8)                                                                                                |               Straight-line exec time    122
    0| 000ADC mtspr      7C0803A6   2     LLR       lr=gr0                                                                                                       GPR's set/used:   su-s ssss ssss s---  ---- ---- ---- ----
 1783| 000AE0 bclr       4E800020   3     BA        lr                                                                                                           FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----
    0|                                CL.2295:                                                                                                                   CCR's set/used:   ss-- -sss
  420| 000AE4 addi       387E1110   1     AI        gr3=gr30,4368                                                                                                    | 000000                             PDEF       async_gen_wrapped_val_traverse
  420| 000AE8 addi       388006F4   1     LI        gr4=1780                                                                                                     1697|                                    PROC       o_125_7,visit_125_7,arg_125_7,gr3-gr5
  420| 000AEC bl         4BFFF515   0     CALL      _Py_NegativeRefcount,3,(*)Cuchar",gr3,gr4,(*)_object",gr5,#ProcAlias",_Py_NegativeRefcount",fcr",gr1,cr[015  1700| 000B00 lwz        80030008   1     L4A        gr0=(*)aggr#C.agw_val(gr3,8)
  420| 000AF0 ori        60000000   1                                                                                                                            1700| 000B04 cmpwi      2C000000   2     C4         cr0=gr0,0
 1781| 000AF4 lwz        80BF000C   1     L4A       gr5=(*)aggr#E.agt_args(gr31,12)                                                                              1700| 000B08 bc         4082000C   1     BF         CL.1801,cr0,0x4/eq,taken=40%(40,60)
    0| 000AF8 or.        7CA02B79   2     LR_R      gr0,cr0=gr5                                                                                                  1701| 000B0C addi       38600000   1     LI         gr3=0
 1781| 000AFC bc         4082FF04   1     BF        CL.1683,cr0,0x4/eq,taken=70%(70,30)                                                                             0| 000B10 bclr       4E800020   0     BA         lr
    0| 000B00 b          4BFFFFBC   1     B         CL.2296,-1                                                                                                      0|                                CL.1801:
  423|                                CL.1483:                                                                                                                   1702| 000B14 b          48005B0C   0     CALLF      gr3=async_gen_wrapped_val_traverse at AF125_7,3,gr3-gr5,fcr",async_gen_wrapped_val_traverse at AF125_7",gr1,cr[0
  425| 000B04 ori        60A30000   1     LR        gr3=gr5                                                                                                          |               Tag Table
  425| 000B08 bl         4BFFF4F9   0     CALL      _Py_Dealloc,1,(*)_object",gr3,#ProcAlias",_Py_Dealloc",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",l      | 000B18        00000000 00002040 00000300 00000000 00000018 001E6173
  425| 000B0C ori        60000000   1                                                                                                                                | 000B30        796E635F 67656E5F 77726170 7065645F 76616C5F 74726176
    0| 000B10 b          4BFFFEE4   0     B         CL.1682,-1                                                                                                       | 000B48        65727365
    0|                                CL.1688:                                                                                                                       |               Instruction count            6
   64| 000B14 addi       389E13E4   1     AI        gr4=gr30,5092                                                                                                    |               Straight-line exec time      5
   64| 000B18 addi       38BE140C   1     AI        gr5=gr30,5132                                                                                                GPR's set/used:   ssus ssss ssss s---  ---- ---- ---- -sss
   64| 000B1C addi       38DE1110   1     AI        gr6=gr30,4368                                                                                                FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----
   64| 000B20 addi       38E006F3   1     LI        gr7=1779                                                                                                     CCR's set/used:   ss-- -sss
   64| 000B24 addi       391E1438   1     AI        gr8=gr30,5176                                                                                                    | 000000                             PDEF       async_gen_wrapped_val_dealloc
   64| 000B28 bl         4BFFF4D9   0     CALL      _PyObject_AssertFailed,6,(*)_object",gr3-gr5,(*)Cuchar",gr6-gr8,#ProcAlias",_PyObject_AssertFailed",fcr",gr  1683|                                    PROC       o,gr3
   64| 000B2C ori        60000000   1                                                                                                                               0| 000B60 mfspr      7C0802A6   1     LFLR       gr0=lr
   64| 000B30 tw         7C8E7008   1     TRAP      9                                                                                                               0| 000B64 stwu       9421FFB0   1     ST4U       gr1,#stack(gr1,-80)=gr1
     | 000B34 b          48000000   0                                                                                                                               0| 000B68 stw        90010058   1     ST4A       #stack(gr1,88)=gr0
     |               Tag Table                                                                                                                                      0| 000B6C stw        93E1004C   1     ST4A       #stack(gr1,76)=gr31
     | 000B38        00000000 00002041 80030100 00000000 000001D8 00186173                                                                                          0| 000B70 ori        607F0000   1     LR         gr31=gr3
     | 000B50        796E635F 67656E5F 61746872 6F775F64 65616C6C 6F63                                                                                             73| 000B74 addi       38000000   1     LI         gr0=0
     |               Instruction count          118                                                                                                                 0| 000B78 stw        93C10048   1     ST4A       #stack(gr1,72)=gr30
     |               Straight-line exec time    125                                                                                                                 0| 000B7C stw        93A10044   1     ST4A       #stack(gr1,68)=gr29
 GPR's set/used:   su-s ssss ssss s---  ---- ---- ---- ----                                                                                                         0| 000B80 lwz        83A20018   1     L4A        gr29=.+CONSTANT_AREA(gr2,0)
 FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----                                                                                                        64| 000B84 lwz        8063FFF8   1     L4A        gr3=(*)_object%##2(gr3,-8)
 CCR's set/used:   ss-- -sss                                                                                                                                       64| 000B88 cmpwi      2C030000   2     C4         cr0=gr3,0
     | 000000                             PDEF     async_gen_wrapped_val_traverse                                                                                  64| 000B8C bc         4182015C   1     BT         CL.1807,cr0,0x4/eq,taken=10%(10,90)
 1697|                                    PROC      o_122_7,visit_122_7,arg_122_7,gr3-gr5                                                                          69| 000B90 lwz        80FFFFFC   1     L4A        gr7=(*)aggr#2._gc_prev(gr31,-4)
 1700| 000B80 lwz        80030008   1     L4A       gr0=(*)aggr#C.agw_val(gr3,8)                                                                                   70| 000B94 lwz        807FFFF8   1     L4A        gr3=(*)aggr#2._gc_next(gr31,-8)
 1700| 000B84 cmpwi      2C000000   2     C4        cr0=gr0,0                                                                                                    1686| 000B98 lwz        80BF0008   1     L4A        gr5=(*)aggr#C.agw_val(gr31,8)
 1700| 000B88 bc         4082000C   1     BF        CL.1692,cr0,0x4/eq,taken=40%(40,60)                                                                             0| 000B9C or.        7CA62B79   2     LR_R       gr6,cr0=gr5
 1701| 000B8C addi       38600000   1     LI        gr3=0                                                                                                          69| 000BA0 rlwinm     54E4003A   1     RN4        gr4=gr7,0,0xFFFFFFFC
    0| 000B90 bclr       4E800020   0     BA        lr                                                                                                             72| 000BA4 lwz        80C30004   1     L4A        gr6=(*)aggr#2._gc_prev(gr3,4)
    0|                                CL.1692:                                                                                                                     71| 000BA8 stw        90640000   1     ST4A       (*)aggr#2._gc_next(gr4,0)=gr3
 1702| 000B94 b          4800580C   0     CALLF     gr3=async_gen_wrapped_val_traverse at AF122_7,3,gr3-gr5,fcr",async_gen_wrapped_val_traverse at AF122_7",gr1,cr[01    73| 000BAC stw        901FFFF8   1     ST4A       (*)aggr#2._gc_next(gr31,-8)=gr0
     |               Tag Table                                                                                                                                     72| 000BB0 rlwimi     50E6003A   1     RI4        gr6=gr7,0,gr6,0xFFFFFFFC
     | 000B98        00000000 00002040 00000300 00000000 00000018 001E6173                                                                                         72| 000BB4 stw        90C30004   1     ST4A       (*)aggr#2._gc_prev(gr3,4)=gr6
     | 000BB0        796E635F 67656E5F 77726170 7065645F 76616C5F 74726176                                                                                         74| 000BB8 lwz        807FFFFC   1     L4A        gr3=(*)aggr#2._gc_prev(gr31,-4)
     | 000BC8        65727365                                                                                                                                      74| 000BBC rlwinm     546607FE   2     RN4        gr6=gr3,0,0x1
     |               Instruction count            6                                                                                                                74| 000BC0 stw        90DFFFFC   1     ST4A       (*)aggr#2._gc_prev(gr31,-4)=gr6
     |               Straight-line exec time      5                                                                                                              1686| 000BC4 bc         41820030   0     BT         CL.1802,cr0,0x4/eq,taken=50%(0,0)
 GPR's set/used:   ssus ssss ssss s---  ---- ---- ---- -sss                                                                                                      1686| 000BC8 stw        901F0008   1     ST4A       (*)aggr#C.agw_val(gr31,8)=gr0
 FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----                                                                                                       415| 000BCC lwz        80820004   1     L4A        gr4=._Py_RefTotal(gr2,0)







Wed Apr 15 07:30:04 CDT 2020  Page 73


 CCR's set/used:   ss-- -sss                                                                                                                                      417| 000BD0 lwz        80650000   1     L4A        gr3=(*)_object._object.ob_refcnt(gr5,0)
     | 000000                             PDEF     async_gen_wrapped_val_dealloc                                                                                  417| 000BD4 addi       3803FFFF   2     AI         gr0=gr3,-1
 1683|                                    PROC      o,gr3                                                                                                         417| 000BD8 stw        90050000   1     ST4A       (*)_object._object.ob_refcnt(gr5,0)=gr0
    0| 000BE0 mfspr      7C0802A6   1     LFLR      gr0=lr                                                                                                        415| 000BDC lwz        80640000   1     L4A        gr3=_Py_RefTotal(gr4,0)
    0| 000BE4 stw        90010008   2     ST4A      #stack(gr1,8)=gr0                                                                                             415| 000BE0 addi       38C3FFFF   2     AI         gr6=gr3,-1
    0| 000BE8 stw        93E1FFFC   1     ST4A      #stack(gr1,-4)=gr31                                                                                           415| 000BE4 stw        90C40000   1     ST4A       _Py_RefTotal(gr4,0)=gr6
    0| 000BEC ori        607F0000   1     LR        gr31=gr3                                                                                                      417| 000BE8 cmpwi      2C000000   1     C4         cr0=gr0,0
   73| 000BF0 addi       38000000   1     LI        gr0=0                                                                                                         417| 000BEC bc         418200EC   1     BT         CL.1468,cr0,0x4/eq,taken=40%(40,60)
    0| 000BF4 stw        93C1FFF8   1     ST4A      #stack(gr1,-8)=gr30                                                                                           419| 000BF0 bc         418000C4   1     BT         CL.2334,cr0,0x1/lt,taken=40%(40,60)
    0| 000BF8 stw        93A1FFF4   1     ST4A      #stack(gr1,-12)=gr29                                                                                            0|                                CL.1802:
    0| 000BFC lwz        83A20018   1     L4A       gr29=.+CONSTANT_AREA(gr2,0)                                                                                  1687| 000BF4 lwz        83C20020   1     L4A        gr30=.$STATIC(gr2,0)
   64| 000C00 lwz        8063FFF8   1     L4A       gr3=(*)_object%##2(gr3,-8)                                                                                   1687| 000BF8 lwz        807E0008   2     L4A        gr3=ag_value_freelist_free(gr30,8)
    0| 000C04 stwu       9421FFB0   1     ST4U      gr1,#stack(gr1,-80)=gr1                                                                                      1687| 000BFC cmpwi      2C030050   2     C4         cr0=gr3,80
   64| 000C08 cmpwi      2C030000   1     C4        cr0=gr3,0                                                                                                    1687| 000C00 bc         4080008C   1     BF         CL.2335,cr0,0x1/lt,taken=30%(30,70)
   64| 000C0C bc         4182015C   1     BT        CL.1698,cr0,0x4/eq,taken=10%(10,90)                                                                             0|                                CL.1803:
   70| 000C10 lwz        807FFFF8   1     L4A       gr3=(*)aggr#2._gc_next(gr31,-8)                                                                              1688| 000C04 lwz        80020014   1     L4A        gr0=._PyAsyncGenWrappedValue_Type(gr2,0)
 1686| 000C14 lwz        80BF0008   1     L4A       gr5=(*)aggr#C.agw_val(gr31,8)                                                                                 128| 000C08 lwz        809F0004   1     L4A        gr4=(*)C_object._object.ob_type(gr31,4)
   69| 000C18 lwz        80FFFFFC   1     L4A       gr7=(*)aggr#2._gc_prev(gr31,-4)                                                                               128| 000C0C cmplw      7C040040   2     CL4        cr0=gr4,gr0
    0| 000C1C or.        7CA62B79   1     LR_R      gr6,cr0=gr5                                                                                                  1688| 000C10 bc         40820034   1     BF         CL.1808,cr0,0x4/eq,taken=40%(40,60)
   69| 000C20 rlwinm     54E4003A   1     RN4       gr4=gr7,0,0xFFFFFFFC                                                                                         1689| 000C14 lwz        80820044   1     L4A        gr4=.$STATIC_BSS(gr2,0)
   72| 000C24 lwz        80C30004   1     L4A       gr6=(*)aggr#2._gc_prev(gr3,4)                                                                                1689| 000C18 rlwinm     5465103A   1     SLL4       gr5=gr3,2
   72| 000C28 rlwimi     50E6003A   2     RI4       gr6=gr7,0,gr6,0xFFFFFFFC                                                                                     1689| 000C1C addi       38030001   1     AI         gr0=gr3,1
   71| 000C2C stw        90640000   1     ST4A      (*)aggr#2._gc_next(gr4,0)=gr3                                                                                   0| 000C20 lwz        83A10044   1     L4A        gr29=#stack(gr1,68)
   72| 000C30 stw        90C30004   1     ST4A      (*)aggr#2._gc_prev(gr3,4)=gr6                                                                                1689| 000C24 stw        901E0008   1     ST4A       ag_value_freelist_free(gr30,8)=gr0
   73| 000C34 stw        901FFFF8   1     ST4A      (*)aggr#2._gc_next(gr31,-8)=gr0                                                                                 0| 000C28 lwz        83C10048   1     L4A        gr30=#stack(gr1,72)
   74| 000C38 lwz        807FFFFC   1     L4A       gr3=(*)aggr#2._gc_prev(gr31,-4)                                                                              1689| 000C2C stwx       7FE4292E   1     ST4A       ag_value_freelist[]0(gr4,gr5,0)=gr31
   74| 000C3C rlwinm     546607FE   2     RN4       gr6=gr3,0,0x1                                                                                                   0| 000C30 lwz        83E1004C   1     L4A        gr31=#stack(gr1,76)
   74| 000C40 stw        90DFFFFC   1     ST4A      (*)aggr#2._gc_prev(gr31,-4)=gr6                                                                                 0| 000C34 lwz        80010058   1     L4A        gr0=#stack(gr1,88)
 1686| 000C44 bc         41820030   0     BT        CL.1693,cr0,0x4/eq,taken=50%(0,0)                                                                            1693| 000C38 addi       38210050   1     AI         gr1=gr1,80
 1686| 000C48 stw        901F0008   1     ST4A      (*)aggr#C.agw_val(gr31,8)=gr0                                                                                   0| 000C3C mtspr      7C0803A6   1     LLR        lr=gr0
  415| 000C4C lwz        80820004   1     L4A       gr4=._Py_RefTotal(gr2,0)                                                                                     1693| 000C40 bclr       4E800020   3     BA         lr
  417| 000C50 lwz        80650000   1     L4A       gr3=(*)_object._object.ob_refcnt(gr5,0)                                                                         0|                                CL.1808:
  417| 000C54 addi       3803FFFF   2     AI        gr0=gr3,-1                                                                                                   1688| 000C44 addi       387D1450   1     AI         gr3=gr29,5200
  417| 000C58 stw        90050000   1     ST4A      (*)_object._object.ob_refcnt(gr5,0)=gr0                                                                      1688| 000C48 addi       389D1110   1     AI         gr4=gr29,4368
  415| 000C5C lwz        80640000   1     L4A       gr3=<s117:d0:l4>(gr4,0)                                                                                      1688| 000C4C addi       38A00698   1     LI         gr5=1688
  415| 000C60 addi       38C3FFFF   2     AI        gr6=gr3,-1                                                                                                   1688| 000C50 bl         4BFFF3B1   0     CALL       __assert,3,gr3-gr5,#ProcAlias",__assert",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",lr",fcr",xer",
  415| 000C64 stw        90C40000   1     ST4A      <s117:d0:l4>(gr4,0)=gr6                                                                                      1688| 000C54 ori        60000000   1
  417| 000C68 cmpwi      2C000000   1     C4        cr0=gr0,0                                                                                                       0| 000C58 lwz        807E0008   1     L4A        gr3=ag_value_freelist_free(gr30,8)
  417| 000C6C bc         418200EC   1     BT        CL.1468,cr0,0x4/eq,taken=40%(40,60)                                                                          1689| 000C5C lwz        80820044   1     L4A        gr4=.$STATIC_BSS(gr2,0)
  419| 000C70 bc         418000C4   1     BT        CL.2289,cr0,0x1/lt,taken=40%(40,60)                                                                             0| 000C60 lwz        83A10044   1     L4A        gr29=#stack(gr1,68)
    0|                                CL.1693:                                                                                                                   1689| 000C64 rlwinm     5465103A   1     SLL4       gr5=gr3,2
 1687| 000C74 lwz        83C20020   1     L4A       gr30=.$STATIC(gr2,0)                                                                                         1689| 000C68 addi       38030001   1     AI         gr0=gr3,1
 1687| 000C78 lwz        807E0008   2     L4A       gr3=ag_value_freelist_free(gr30,8)                                                                           1689| 000C6C stw        901E0008   1     ST4A       ag_value_freelist_free(gr30,8)=gr0
 1687| 000C7C cmpwi      2C030050   2     C4        cr0=gr3,80                                                                                                      0| 000C70 lwz        83C10048   1     L4A        gr30=#stack(gr1,72)
 1687| 000C80 bc         4080008C   1     BF        CL.2290,cr0,0x1/lt,taken=30%(30,70)                                                                          1689| 000C74 stwx       7FE4292E   1     ST4A       ag_value_freelist[]0(gr4,gr5,0)=gr31
    0|                                CL.1694:                                                                                                                      0| 000C78 lwz        83E1004C   1     L4A        gr31=#stack(gr1,76)
 1688| 000C84 lwz        80020014   1     L4A       gr0=._PyAsyncGenWrappedValue_Type(gr2,0)                                                                        0| 000C7C lwz        80010058   1     L4A        gr0=#stack(gr1,88)
  128| 000C88 lwz        809F0004   1     L4A       gr4=(*)C_object._object.ob_type(gr31,4)                                                                      1693| 000C80 addi       38210050   1     AI         gr1=gr1,80
  128| 000C8C cmplw      7C040040   2     CL4       cr0=gr4,gr0                                                                                                     0| 000C84 mtspr      7C0803A6   1     LLR        lr=gr0
 1688| 000C90 bc         40820034   1     BF        CL.1699,cr0,0x4/eq,taken=40%(40,60)                                                                          1693| 000C88 bclr       4E800020   3     BA         lr
 1689| 000C94 lwz        80820044   1     L4A       gr4=.$STATIC_BSS(gr2,0)                                                                                         0|                                CL.2335:
 1689| 000C98 rlwinm     5465103A   1     SLL4      gr5=gr3,2                                                                                                    1691| 000C8C ori        63E30000   1     LR         gr3=gr31
 1689| 000C9C addi       38030001   1     AI        gr0=gr3,1                                                                                                       0| 000C90 lwz        83C10048   1     L4A        gr30=#stack(gr1,72)
    0| 000CA0 lwz        83A10044   1     L4A       gr29=#stack(gr1,68)                                                                                             0| 000C94 lwz        83A10044   1     L4A        gr29=#stack(gr1,68)
 1689| 000CA4 stw        901E0008   1     ST4A      ag_value_freelist_free(gr30,8)=gr0                                                                           1691| 000C98 bl         4BFFF369   0     CALL       PyObject_GC_Del,1,(*)void",gr3,#ProcAlias",PyObject_GC_Del",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13"
    0| 000CA8 lwz        83C10048   1     L4A       gr30=#stack(gr1,72)                                                                                          1691| 000C9C ori        60000000   1







Wed Apr 15 07:30:04 CDT 2020  Page 74


 1689| 000CAC stwx       7FE4292E   1     ST4A      ag_value_freelist[]0(gr4,gr5,0)=gr31                                                                            0| 000CA0 lwz        83E1004C   1     L4A        gr31=#stack(gr1,76)
    0| 000CB0 lwz        83E1004C   1     L4A       gr31=#stack(gr1,76)                                                                                             0| 000CA4 lwz        80010058   1     L4A        gr0=#stack(gr1,88)
 1693| 000CB4 addi       38210050   1     AI        gr1=gr1,80                                                                                                   1693| 000CA8 addi       38210050   1     AI         gr1=gr1,80
    0| 000CB8 lwz        80010008   1     L4A       gr0=#stack(gr1,8)                                                                                               0| 000CAC mtspr      7C0803A6   1     LLR        lr=gr0
    0| 000CBC mtspr      7C0803A6   2     LLR       lr=gr0                                                                                                       1693| 000CB0 bclr       4E800020   3     BA         lr
 1693| 000CC0 bclr       4E800020   3     BA        lr                                                                                                              0|                                CL.2334:
    0|                                CL.1699:                                                                                                                    420| 000CB4 addi       387D1110   1     AI         gr3=gr29,4368
 1688| 000CC4 addi       387D1450   1     AI        gr3=gr29,5200                                                                                                 420| 000CB8 addi       38800696   1     LI         gr4=1686
 1688| 000CC8 addi       389D1110   1     AI        gr4=gr29,4368                                                                                                 420| 000CBC bl         4BFFF345   0     CALL       _Py_NegativeRefcount,3,(*)Cuchar",gr3,gr4,(*)_object",gr5,#ProcAlias",_Py_NegativeRefcount",fcr",gr1,cr[01
 1688| 000CCC addi       38A00698   1     LI        gr5=1688                                                                                                      420| 000CC0 ori        60000000   1
 1688| 000CD0 bl         4BFFF331   0     CALL      __assert,3,gr3-gr5,#ProcAlias",__assert",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",lr",fcr",xer",f  1687| 000CC4 lwz        83C20020   1     L4A        gr30=.$STATIC(gr2,0)
 1688| 000CD4 ori        60000000   1                                                                                                                            1687| 000CC8 lwz        807E0008   2     L4A        gr3=ag_value_freelist_free(gr30,8)
    0| 000CD8 lwz        807E0008   1     L4A       gr3=ag_value_freelist_free(gr30,8)                                                                           1687| 000CCC cmpwi      2C030050   2     C4         cr0=gr3,80
 1689| 000CDC lwz        80820044   1     L4A       gr4=.$STATIC_BSS(gr2,0)                                                                                      1687| 000CD0 bc         4180FF34   1     BT         CL.1803,cr0,0x1/lt,taken=70%(70,30)
    0| 000CE0 lwz        83A10044   1     L4A       gr29=#stack(gr1,68)                                                                                             0| 000CD4 b          4BFFFFB8   1     B          CL.2335,-1
 1689| 000CE4 rlwinm     5465103A   1     SLL4      gr5=gr3,2                                                                                                     423|                                CL.1468:
 1689| 000CE8 addi       38030001   1     AI        gr0=gr3,1                                                                                                     425| 000CD8 ori        60A30000   1     LR         gr3=gr5
 1689| 000CEC stw        901E0008   1     ST4A      ag_value_freelist_free(gr30,8)=gr0                                                                            425| 000CDC bl         4BFFF325   0     CALL       _Py_Dealloc,1,(*)_object",gr3,#ProcAlias",_Py_Dealloc",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",
    0| 000CF0 lwz        83C10048   1     L4A       gr30=#stack(gr1,72)                                                                                           425| 000CE0 ori        60000000   1
 1689| 000CF4 stwx       7FE4292E   1     ST4A      ag_value_freelist[]0(gr4,gr5,0)=gr31                                                                            0| 000CE4 b          4BFFFF10   0     B          CL.1802,-1
    0| 000CF8 lwz        83E1004C   1     L4A       gr31=#stack(gr1,76)                                                                                             0|                                CL.1807:
 1693| 000CFC addi       38210050   1     AI        gr1=gr1,80                                                                                                     64| 000CE8 ori        63E30000   1     LR         gr3=gr31
    0| 000D00 lwz        80010008   1     L4A       gr0=#stack(gr1,8)                                                                                              64| 000CEC addi       389D13E4   1     AI         gr4=gr29,5092
    0| 000D04 mtspr      7C0803A6   2     LLR       lr=gr0                                                                                                         64| 000CF0 addi       38BD140C   1     AI         gr5=gr29,5132
 1693| 000D08 bclr       4E800020   3     BA        lr                                                                                                             64| 000CF4 addi       38DD1110   1     AI         gr6=gr29,4368
    0|                                CL.2290:                                                                                                                     64| 000CF8 addi       38E00695   1     LI         gr7=1685
 1691| 000D0C ori        63E30000   1     LR        gr3=gr31                                                                                                       64| 000CFC addi       391D1438   1     AI         gr8=gr29,5176
    0| 000D10 lwz        83C10048   1     L4A       gr30=#stack(gr1,72)                                                                                            64| 000D00 bl         4BFFF301   0     CALL       _PyObject_AssertFailed,6,(*)_object",gr3-gr5,(*)Cuchar",gr6-gr8,#ProcAlias",_PyObject_AssertFailed",fcr",g
    0| 000D14 lwz        83A10044   1     L4A       gr29=#stack(gr1,68)                                                                                            64| 000D04 ori        60000000   1
 1691| 000D18 bl         4BFFF2E9   0     CALL      PyObject_GC_Del,1,(*)void",gr3,#ProcAlias",PyObject_GC_Del",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",    64| 000D08 tw         7C8E7008   1     TRAP       9
 1691| 000D1C ori        60000000   1                                                                                                                                | 000D0C b          48000000   0
    0| 000D20 lwz        83E1004C   1     L4A       gr31=#stack(gr1,76)                                                                                              |               Tag Table
 1693| 000D24 addi       38210050   1     AI        gr1=gr1,80                                                                                                       | 000D10        00000000 00002041 80030100 00000000 000001B0 001D6173
    0| 000D28 lwz        80010008   1     L4A       gr0=#stack(gr1,8)                                                                                                | 000D28        796E635F 67656E5F 77726170 7065645F 76616C5F 6465616C
    0| 000D2C mtspr      7C0803A6   2     LLR       lr=gr0                                                                                                           | 000D40        6C6F63
 1693| 000D30 bclr       4E800020   3     BA        lr                                                                                                               |               Instruction count          108
    0|                                CL.2289:                                                                                                                       |               Straight-line exec time    116
  420| 000D34 addi       387D1110   1     AI        gr3=gr29,4368                                                                                                GPR's set/used:   s-us ss-- ---- ----  ---- ---- ---- ----
  420| 000D38 addi       38800696   1     LI        gr4=1686                                                                                                     FPR's set/used:   ---- ---- ---- ----  ---- ---- ---- ----
  420| 000D3C bl         4BFFF2C5   0     CALL      _Py_NegativeRefcount,3,(*)Cuchar",gr3,gr4,(*)_object",gr5,#ProcAlias",_Py_NegativeRefcount",fcr",gr1,cr[015  CCR's set/used:   ---- ----
  420| 000D40 ori        60000000   1                                                                                                                                | 000000                             PDEF       async_gen_asend_close
 1687| 000D44 lwz        83C20020   1     L4A       gr30=.$STATIC(gr2,0)                                                                                         1586|                                    PROC       o,args,gr3,gr4
 1687| 000D48 lwz        807E0008   2     L4A       gr3=ag_value_freelist_free(gr30,8)                                                                           1588| 000D60 addi       38000002   1     LI         gr0=2
 1687| 000D4C cmpwi      2C030050   2     C4        cr0=gr3,80                                                                                                    401| 000D64 lwz        80A20004   1     L4A        gr5=._Py_RefTotal(gr2,0)
 1687| 000D50 bc         4180FF34   1     BT        CL.1694,cr0,0x1/lt,taken=70%(70,30)                                                                          1588| 000D68 stw        90030010   1     ST4A       (*)aggr#D.ags_state(gr3,16)=gr0
    0| 000D54 b          4BFFFFB8   1     B         CL.2290,-1                                                                                                   1589| 000D6C lwz        80620008   1     L4A        gr3=._Py_NoneStruct(gr2,0)
  423|                                CL.1468:                                                                                                                    401| 000D70 lwz        80850000   1     L4A        gr4=_Py_RefTotal(gr5,0)
  425| 000D58 ori        60A30000   1     LR        gr3=gr5                                                                                                       401| 000D74 addi       38040001   2     AI         gr0=gr4,1
  425| 000D5C bl         4BFFF2A5   0     CALL      _Py_Dealloc,1,(*)_object",gr3,#ProcAlias",_Py_Dealloc",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",l   401| 000D78 stw        90050000   1     ST4A       _Py_RefTotal(gr5,0)=gr0
  425| 000D60 ori        60000000   1                                                                                                                             403| 000D7C lwz        80830000   1     L4A        gr4=_Py_NoneStruct%##1(gr3,0)
    0| 000D64 b          4BFFFF10   0     B         CL.1693,-1                                                                                                    403| 000D80 addi       38040001   2     AI         gr0=gr4,1
    0|                                CL.1698:                                                                                                                    403| 000D84 stw        90030000   1     ST4A       _Py_NoneStruct%##1(gr3,0)=gr0
   64| 000D68 ori        63E30000   1     LR        gr3=gr31                                                                                                     1590| 000D88 bclr       4E800020   0     BA         lr
   64| 000D6C addi       389D13E4   1     AI        gr4=gr29,5092                                                                                                    |               Tag Table
   64| 000D70 addi       38BD140C   1     AI        gr5=gr29,5132                                                                                                    | 000D8C        00000000 00002040 00000200 00000000 0000002C 00156173
   64| 000D74 addi       38DD1110   1     AI        gr6=gr29,4368                                                                                                    | 000DA4        796E635F 67656E5F 6173656E 645F636C 6F7365







Wed Apr 15 07:30:04 CDT 2020  Page 75


   64| 000D78 addi       38E00695   1     LI        gr7=1685                                                                                                         |               Instruction count           11
   64| 000D7C addi       391D1438   1     AI        gr8=gr29,5176                                                                                                    |               Straight-line exec time     12
   64| 000D80 bl         4BFFF281   0     CALL      _PyObject_AssertFailed,6,(*)_object",gr3-gr5,(*)Cuchar",gr6-gr8,#ProcAlias",_PyObject_AssertFailed",fcr",gr  GPR's set/used:   ssus ssss ssss s---  ---- ---- ---- ---s
   64| 000D84 ori        60000000   1                                                                                                                            FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----
   64| 000D88 tw         7C8E7008   1     TRAP      9                                                                                                            CCR's set/used:   ss-- -sss
     | 000D8C b          48000000   0                                                                                                                                | 000000                             PDEF       async_gen_asend_throw
     |               Tag Table                                                                                                                                   1563|                                    PROC       o,args,gr3,gr4
     | 000D90        00000000 00002041 80030100 00000000 000001B0 001D6173                                                                                          0| 000DC0 mfspr      7C0802A6   1     LFLR       gr0=lr
     | 000DA8        796E635F 67656E5F 77726170 7065645F 76616C5F 6465616C                                                                                          0| 000DC4 stwu       9421FFC0   1     ST4U       gr1,#stack(gr1,-64)=gr1
     | 000DC0        6C6F63                                                                                                                                         0| 000DC8 stw        90010048   1     ST4A       #stack(gr1,72)=gr0
     |               Instruction count          108                                                                                                                 0| 000DCC stw        93E1003C   1     ST4A       #stack(gr1,60)=gr31
     |               Straight-line exec time    119                                                                                                                 0| 000DD0 ori        607F0000   1     LR         gr31=gr3
 GPR's set/used:   s-us ss-- ---- ----  ---- ---- ---- ----                                                                                                      1567| 000DD4 lwz        80030010   1     L4A        gr0=(*)aggr#D.ags_state(gr3,16)
 FPR's set/used:   ---- ---- ---- ----  ---- ---- ---- ----                                                                                                      1567| 000DD8 cmpwi      2C000002   2     C4         cr0=gr0,2
 CCR's set/used:   ---- ----                                                                                                                                     1567| 000DDC bc         41820050   1     BT         CL.1814,cr0,0x4/eq,taken=30%(30,70)
     | 000000                             PDEF     async_gen_asend_close                                                                                         1574| 000DE0 lwz        80630008   1     L4A        gr3=(*)aggr#D.ags_gen(gr3,8)
 1586|                                    PROC      o,args,gr3,gr4                                                                                               1574| 000DE4 bl         48001ABD   0     CALL       gr3=gen_throw,2,(*)aggr#3",gr3,(*)_object",gr4,#ProcAlias",gen_throw",fcr",gr1,cr[01567]",gr0",gr4"-gr12",
 1588| 000DE0 addi       38000002   1     LI        gr0=2                                                                                                        1574| 000DE8 ori        60640000   1     LR         gr4=gr3
  401| 000DE4 lwz        80A20004   1     L4A       gr5=._Py_RefTotal(gr2,0)                                                                                     1575| 000DEC lwz        807F0008   1     L4A        gr3=(*)aggr#D.ags_gen(gr31,8)
 1588| 000DE8 stw        90030010   1     ST4A      (*)aggr#D.ags_state(gr3,16)=gr0                                                                              1575| 000DF0 bl         48000511   0     CALL       gr3=async_gen_unwrap_value,2,(*)aggr#4",gr3,(*)_object",gr4,#ProcAlias",async_gen_unwrap_value",fcr",gr1,c
 1589| 000DEC lwz        80620008   1     L4A       gr3=._Py_NoneStruct(gr2,0)                                                                                   1578| 000DF4 addi       38000002   1     LI         gr0=2
  401| 000DF0 lwz        80850000   1     L4A       gr4=<s117:d0:l4>(gr5,0)                                                                                      1577| 000DF8 cmpwi      2C030000   1     C4         cr0=gr3,0
  401| 000DF4 addi       38040001   2     AI        gr0=gr4,1                                                                                                    1577| 000DFC bc         4082001C   1     BF         CL.2331,cr0,0x4/eq,taken=50%(0,0)
  401| 000DF8 stw        90050000   1     ST4A      <s117:d0:l4>(gr5,0)=gr0                                                                                      1578| 000E00 stw        901F0010   2     ST4A       (*)aggr#D.ags_state(gr31,16)=gr0
  403| 000DFC lwz        80830000   1     L4A       gr4=<s119:d0:l4>(gr3,0)                                                                                         0| 000E04 lwz        80810048   1     L4A        gr4=#stack(gr1,72)
  403| 000E00 addi       38040001   2     AI        gr0=gr4,1                                                                                                       0| 000E08 mtspr      7C8803A6   2     LLR        lr=gr4
  403| 000E04 stw        90030000   1     ST4A      <s119:d0:l4>(gr3,0)=gr0                                                                                         0| 000E0C lwz        83E1003C   1     L4A        gr31=#stack(gr1,60)
 1590| 000E08 bclr       4E800020   0     BA        lr                                                                                                           1582| 000E10 addi       38210040   1     AI         gr1=gr1,64
     |               Tag Table                                                                                                                                   1582| 000E14 bclr       4E800020   1     BA         lr
     | 000E0C        00000000 00002040 00000200 00000000 0000002C 00156173                                                                                          0|                                CL.2331:
     | 000E24        796E635F 67656E5F 6173656E 645F636C 6F7365                                                                                                     0| 000E18 lwz        80010048   1     L4A        gr0=#stack(gr1,72)
     |               Instruction count           11                                                                                                                 0| 000E1C lwz        83E1003C   1     L4A        gr31=#stack(gr1,60)
     |               Straight-line exec time     12                                                                                                              1582| 000E20 addi       38210040   1     AI         gr1=gr1,64
 GPR's set/used:   ssus ssss ssss s---  ---- ---- ---- ---s                                                                                                         0| 000E24 mtspr      7C0803A6   1     LLR        lr=gr0
 FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----                                                                                                      1582| 000E28 bclr       4E800020   3     BA         lr
 CCR's set/used:   ss-- -sss                                                                                                                                        0|                                CL.1814:
     | 000000                             PDEF     async_gen_asend_throw                                                                                         1568| 000E2C lwz        8062001C   1     L4A        gr3=.PyExc_RuntimeError(gr2,0)
 1563|                                    PROC      o,args,gr3,gr4                                                                                               1568| 000E30 lwz        80820018   1     L4A        gr4=.+CONSTANT_AREA(gr2,0)
    0| 000E40 mfspr      7C0802A6   1     LFLR      gr0=lr                                                                                                          0| 000E34 lwz        83E1003C   1     L4A        gr31=#stack(gr1,60)
    0| 000E44 stw        90010008   2     ST4A      #stack(gr1,8)=gr0                                                                                            1568| 000E38 addi       38841478   1     AI         gr4=gr4,5240
    0| 000E48 stw        93E1FFFC   1     ST4A      #stack(gr1,-4)=gr31                                                                                          1568| 000E3C lwz        80630000   1     L4A        gr3=PyExc_RuntimeError(gr3,0)
    0| 000E4C ori        607F0000   1     LR        gr31=gr3                                                                                                     1568| 000E40 bl         4BFFF1C1   0     CALL       PyErr_SetString,2,(*)_object",gr3,gr4,#ProcAlias",PyErr_SetString",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0
    0| 000E50 stwu       9421FFB0   1     ST4U      gr1,#stack(gr1,-80)=gr1                                                                                      1568| 000E44 ori        60000000   1
 1567| 000E54 lwz        80030010   1     L4A       gr0=(*)aggr#D.ags_state(gr3,16)                                                                              1571| 000E48 addi       38600000   1     LI         gr3=0
 1567| 000E58 cmpwi      2C000002   2     C4        cr0=gr0,2                                                                                                       0| 000E4C lwz        80010048   1     L4A        gr0=#stack(gr1,72)
 1567| 000E5C bc         41820058   1     BT        CL.1705,cr0,0x4/eq,taken=30%(30,70)                                                                          1582| 000E50 addi       38210040   1     AI         gr1=gr1,64
 1574| 000E60 stw        90610048   1     ST4A      #parameter_store0(gr1,72)=gr3                                                                                   0| 000E54 mtspr      7C0803A6   1     LLR        lr=gr0
 1574| 000E64 lwz        80630008   1     L4A       gr3=(*)aggr#D.ags_gen(gr3,8)                                                                                 1582| 000E58 bclr       4E800020   3     BA         lr
 1574| 000E68 bl         48001C19   0     CALL      gr3=gen_throw,2,(*)aggr#3",gr3,(*)_object",gr4,#ProcAlias",gen_throw",fcr",gr1,cr[01567]",gr0",gr4"-gr12",f      |               Tag Table
 1574| 000E6C ori        60640000   1     LR        gr4=gr3                                                                                                          | 000E5C        00000000 00002041 80010200 00000000 0000009C 00156173
 1575| 000E70 lwz        807F0008   1     L4A       gr3=(*)aggr#D.ags_gen(gr31,8)                                                                                    | 000E74        796E635F 67656E5F 6173656E 645F7468 726F77
 1575| 000E74 bl         480005AD   0     CALL      gr3=IPRA.$async_gen_unwrap_value,2,(*)aggr#4",gr3,(*)_object",gr4,#ProcAlias",IPRA.$async_gen_unwrap_value"      |               Instruction count           39
 1578| 000E78 addi       38000002   1     LI        gr0=2                                                                                                            |               Straight-line exec time     43
 1577| 000E7C cmpwi      2C030000   1     C4        cr0=gr3,0                                                                                                    GPR's set/used:   su-s ssss ssss s---  ---- ---- ---- ----
 1575| 000E80 lwz        83E10048   1     L4A       gr31=#parameter_store0(gr1,72)                                                                               FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----
 1577| 000E84 bc         4082001C   0     BF        CL.2286,cr0,0x4/eq,taken=50%(0,0)                                                                            CCR's set/used:   ss-- -sss







Wed Apr 15 07:30:04 CDT 2020  Page 76


    0| 000E88 lwz        80810058   2     L4A       gr4=#stack(gr1,88)                                                                                               | 000000                             PDEF       async_gen_asend_iternext
    0| 000E8C mtspr      7C8803A6   2     LLR       lr=gr4                                                                                                       1556|                                    PROC       o,gr3
 1578| 000E90 stw        901F0010   1     ST4A      (*)aggr#D.ags_state(gr31,16)=gr0                                                                             1558| 000EA0 addi       38800000   1     LI         gr4=0
    0| 000E94 lwz        83E1004C   1     L4A       gr31=#stack(gr1,76)                                                                                          1559| 000EA4 b          4800003C   0     CALLF      gr3=async_gen_asend_send,2,(*)aggr#D",gr3,(*)_object",gr4,#ProcAlias",async_gen_asend_send",fcr",gr1,cr[01
 1582| 000E98 addi       38210050   1     AI        gr1=gr1,80                                                                                                   1559|                                CL.716:
 1582| 000E9C bclr       4E800020   0     BA        lr                                                                                                               |               Tag Table
    0|                                CL.2286:                                                                                                                       | 000EA8        00000000 00002040 00000100 00000000 00000008 00186173
    0| 000EA0 lwz        80010058   1     L4A       gr0=#stack(gr1,88)                                                                                               | 000EC0        796E635F 67656E5F 6173656E 645F6974 65726E65 7874
    0| 000EA4 lwz        83E1004C   1     L4A       gr31=#stack(gr1,76)                                                                                              |               Instruction count            2
 1582| 000EA8 addi       38210050   1     AI        gr1=gr1,80                                                                                                       |               Straight-line exec time      1
    0| 000EAC mtspr      7C0803A6   1     LLR       lr=gr0                                                                                                       GPR's set/used:   ssus ssss ssss s---  ---- ---- ---- ---s
 1582| 000EB0 bclr       4E800020   3     BA        lr                                                                                                           FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----
    0|                                CL.1705:                                                                                                                   CCR's set/used:   ss-- -sss
 1568| 000EB4 lwz        8062001C   1     L4A       gr3=.PyExc_RuntimeError(gr2,0)                                                                                   | 000000                             PDEF       async_gen_asend_send
 1568| 000EB8 lwz        80820018   1     L4A       gr4=.+CONSTANT_AREA(gr2,0)                                                                                   1518|                                    PROC       o,arg,gr3,gr4
    0| 000EBC lwz        83E1004C   1     L4A       gr31=#stack(gr1,76)                                                                                             0| 000EE0 mfspr      7C0802A6   1     LFLR       gr0=lr
 1568| 000EC0 addi       38841478   1     AI        gr4=gr4,5240                                                                                                    0| 000EE4 stwu       9421FFC0   1     ST4U       gr1,#stack(gr1,-64)=gr1
 1568| 000EC4 lwz        80630000   1     L4A       gr3=<s143:d0:l4>(gr3,0)                                                                                      1544| 000EE8 addi       38A00000   1     LI         gr5=0
 1568| 000EC8 bl         4BFFF139   0     CALL      PyErr_SetString,2,(*)_object",gr3,gr4,#ProcAlias",PyErr_SetString",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"  1544| 000EEC addi       38C00000   1     LI         gr6=0
 1568| 000ECC ori        60000000   1                                                                                                                               0| 000EF0 stw        90010048   1     ST4A       #stack(gr1,72)=gr0
 1571| 000ED0 addi       38600000   1     LI        gr3=0                                                                                                           0| 000EF4 stw        93E1003C   1     ST4A       #stack(gr1,60)=gr31
    0| 000ED4 lwz        80010058   1     L4A       gr0=#stack(gr1,88)                                                                                              0| 000EF8 ori        607F0000   1     LR         gr31=gr3
 1582| 000ED8 addi       38210050   1     AI        gr1=gr1,80                                                                                                   1543| 000EFC addi       38000001   1     LI         gr0=1
    0| 000EDC mtspr      7C0803A6   1     LLR       lr=gr0                                                                                                       1522| 000F00 lwz        80630010   1     L4A        gr3=(*)aggr#D.ags_state(gr3,16)
 1582| 000EE0 bclr       4E800020   3     BA        lr                                                                                                           1529| 000F04 cmpwi      2C030000   2     C4         cr0=gr3,0
     |               Tag Table                                                                                                                                   1522| 000F08 cmpwi      2C830002   1     C4         cr1=gr3,2
     | 000EE4        00000000 00002041 80010200 00000000 000000A4 00156173                                                                                       1522| 000F0C bc         418600C0   1     BT         CL.1816,cr1,0x4/eq,taken=30%(30,70)
     | 000EFC        796E635F 67656E5F 6173656E 645F7468 726F77                                                                                                     0| 000F10 lwz        807F0008   1     L4A        gr3=(*)aggr#D.ags_gen(gr31,8)
     |               Instruction count           41                                                                                                              1529| 000F14 bc         40820030   0     BF         CL.91,cr0,0x4/eq,taken=40%(40,60)
     |               Straight-line exec time     44                                                                                                              1540| 000F18 addi       39200001   2     LI         gr9=1
 GPR's set/used:   su-s ssss ssss s---  ---- ---- ---- ----                                                                                                      1537| 000F1C cmpwi      2C040000   1     C4         cr0=gr4,0
 FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----                                                                                                      1530| 000F20 lwz        80E3003C   1     L4A        gr7=(*)aggr#4.ag_running_async(gr3,60)
 CCR's set/used:   ss-- -sss                                                                                                                                     1530| 000F24 cmpwi      2C870000   2     C4         cr1=gr7,0
     | 000000                             PDEF     async_gen_asend_iternext                                                                                      1530| 000F28 bc         40860074   1     BF         CL.1818,cr1,0x4/eq,taken=30%(30,70)
 1556|                                    PROC      o,gr3                                                                                                        1537| 000F2C lwz        80E20008   1     L4A        gr7=._Py_NoneStruct(gr2,0)
 1558| 000F20 addi       38800000   1     LI        gr4=0                                                                                                        1537| 000F30 bc         41820060   0     BT         CL.93,cr0,0x4/eq,taken=50%(0,0)
 1559| 000F24 b          4800003C   0     CALLF     gr3=async_gen_asend_send,2,(*)aggr#D",gr3,(*)_object",gr4,#ProcAlias",async_gen_asend_send",fcr",gr1,cr[015  1540| 000F34 addi       39000001   2     LI         gr8=1
 1559|                                CL.716:                                                                                                                    1537| 000F38 cmplw      7C072040   1     CL4        cr0=gr7,gr4
     |               Tag Table                                                                                                                                   1537| 000F3C bc         41820054   1     BT         CL.93,cr0,0x4/eq,taken=50%(0,0)
     | 000F28        00000000 00002040 00000100 00000000 00000008 00186173                                                                                       1540| 000F40 stw        911F0010   2     ST4A       (*)aggr#D.ags_state(gr31,16)=gr8
     | 000F40        796E635F 67656E5F 6173656E 645F6974 65726E65 7874                                                                                           1541|                                CL.91:
     |               Instruction count            2                                                                                                              1543| 000F44 stw        9003003C   1     ST4A       (*)aggr#4.ag_running_async(gr3,60)=gr0
     |               Straight-line exec time      1                                                                                                              1544| 000F48 bl         48002739   0     CALL       gr3=gen_send_ex,4,(*)aggr#3",gr3,(*)_object",gr4-gr6,#ProcAlias",gen_send_ex",fcr",gr1,cr[01567]",gr0",gr4
 GPR's set/used:   ssus ssss ssss s---  ---- ---- ---- ---s                                                                                                      1544| 000F4C ori        60640000   1     LR         gr4=gr3
 FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----                                                                                                      1545| 000F50 lwz        807F0008   1     L4A        gr3=(*)aggr#D.ags_gen(gr31,8)
 CCR's set/used:   ss-- -sss                                                                                                                                     1545| 000F54 bl         480003AD   0     CALL       gr3=async_gen_unwrap_value,2,(*)aggr#4",gr3,(*)_object",gr4,#ProcAlias",async_gen_unwrap_value",fcr",gr1,c
     | 000000                             PDEF     async_gen_asend_send                                                                                          1548| 000F58 addi       38000002   1     LI         gr0=2
 1518|                                    PROC      o,arg,gr3,gr4                                                                                                1547| 000F5C cmpwi      2C030000   1     C4         cr0=gr3,0
    0| 000F60 mfspr      7C0802A6   1     LFLR      gr0=lr                                                                                                       1547| 000F60 bc         4082001C   1     BF         CL.2330,cr0,0x4/eq,taken=50%(0,0)
 1544| 000F64 addi       38A00000   1     LI        gr5=0                                                                                                           0| 000F64 lwz        80810048   2     L4A        gr4=#stack(gr1,72)
 1544| 000F68 addi       38C00000   1     LI        gr6=0                                                                                                        1548| 000F68 stw        901F0010   1     ST4A       (*)aggr#D.ags_state(gr31,16)=gr0
    0| 000F6C stw        90010008   1     ST4A      #stack(gr1,8)=gr0                                                                                               0| 000F6C mtspr      7C8803A6   1     LLR        lr=gr4
    0| 000F70 stw        93E1FFFC   1     ST4A      #stack(gr1,-4)=gr31                                                                                             0| 000F70 lwz        83E1003C   1     L4A        gr31=#stack(gr1,60)
    0| 000F74 ori        607F0000   1     LR        gr31=gr3                                                                                                     1552| 000F74 addi       38210040   1     AI         gr1=gr1,64
 1543| 000F78 addi       38000001   1     LI        gr0=1                                                                                                        1552| 000F78 bclr       4E800020   1     BA         lr
    0| 000F7C stwu       9421FFB0   1     ST4U      gr1,#stack(gr1,-80)=gr1                                                                                         0|                                CL.2330:







Wed Apr 15 07:30:04 CDT 2020  Page 77


 1522| 000F80 lwz        80630010   1     L4A       gr3=(*)aggr#D.ags_state(gr3,16)                                                                                 0| 000F7C lwz        80010048   1     L4A        gr0=#stack(gr1,72)
 1529| 000F84 cmpwi      2C030000   2     C4        cr0=gr3,0                                                                                                       0| 000F80 lwz        83E1003C   1     L4A        gr31=#stack(gr1,60)
 1522| 000F88 cmpwi      2C830002   1     C4        cr1=gr3,2                                                                                                    1552| 000F84 addi       38210040   1     AI         gr1=gr1,64
 1522| 000F8C bc         418600C8   1     BT        CL.1708,cr1,0x4/eq,taken=30%(30,70)                                                                             0| 000F88 mtspr      7C0803A6   1     LLR        lr=gr0
    0| 000F90 lwz        807F0008   1     L4A       gr3=(*)aggr#D.ags_gen(gr31,8)                                                                                1552| 000F8C bclr       4E800020   3     BA         lr
 1529| 000F94 bc         40820030   0     BF        CL.91,cr0,0x4/eq,taken=40%(40,60)                                                                            1537|                                CL.93:
 1540| 000F98 addi       39200001   2     LI        gr9=1                                                                                                        1538| 000F90 lwz        809F000C   1     L4A        gr4=(*)aggr#D.ags_sendval(gr31,12)
 1537| 000F9C cmpwi      2C040000   1     C4        cr0=gr4,0                                                                                                    1540| 000F94 stw        913F0010   1     ST4A       (*)aggr#D.ags_state(gr31,16)=gr9
 1530| 000FA0 lwz        80E3003C   1     L4A       gr7=(*)aggr#4.ag_running_async(gr3,60)                                                                          0| 000F98 b          4BFFFFAC   0     B          CL.91,-1
 1530| 000FA4 cmpwi      2C870000   2     C4        cr1=gr7,0                                                                                                       0|                                CL.1818:
 1530| 000FA8 bc         4086007C   1     BF        CL.1710,cr1,0x4/eq,taken=30%(30,70)                                                                          1531| 000F9C lwz        8062001C   1     L4A        gr3=.PyExc_RuntimeError(gr2,0)
 1537| 000FAC lwz        80E20008   1     L4A       gr7=._Py_NoneStruct(gr2,0)                                                                                   1531| 000FA0 lwz        80820018   1     L4A        gr4=.+CONSTANT_AREA(gr2,0)
 1537| 000FB0 bc         41820068   0     BT        CL.93,cr0,0x4/eq,taken=50%(0,0)                                                                                 0| 000FA4 lwz        83E1003C   1     L4A        gr31=#stack(gr1,60)
 1540| 000FB4 addi       39000001   2     LI        gr8=1                                                                                                        1531| 000FA8 addi       388414AC   1     AI         gr4=gr4,5292
 1537| 000FB8 cmplw      7C072040   1     CL4       cr0=gr7,gr4                                                                                                  1531| 000FAC lwz        80630000   1     L4A        gr3=PyExc_RuntimeError(gr3,0)
 1537| 000FBC bc         4182005C   1     BT        CL.93,cr0,0x4/eq,taken=50%(0,0)                                                                              1531| 000FB0 bl         4BFFF051   0     CALL       PyErr_SetString,2,(*)_object",gr3,gr4,#ProcAlias",PyErr_SetString",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0
 1540| 000FC0 stw        911F0010   2     ST4A      (*)aggr#D.ags_state(gr31,16)=gr8                                                                             1531| 000FB4 ori        60000000   1
 1541|                                CL.91:                                                                                                                     1534| 000FB8 addi       38600000   1     LI         gr3=0
 1543| 000FC4 stw        9003003C   1     ST4A      (*)aggr#4.ag_running_async(gr3,60)=gr0                                                                          0| 000FBC lwz        80010048   1     L4A        gr0=#stack(gr1,72)
 1544| 000FC8 bl         48002899   0     CALL      gr3=gen_send_ex,4,(*)aggr#3",gr3,(*)_object",gr4-gr6,#ProcAlias",gen_send_ex",fcr",gr1,cr[01567]",gr0",gr4"  1552| 000FC0 addi       38210040   1     AI         gr1=gr1,64
 1544| 000FCC ori        60640000   1     LR        gr4=gr3                                                                                                         0| 000FC4 mtspr      7C0803A6   1     LLR        lr=gr0
 1545| 000FD0 lwz        807F0008   1     L4A       gr3=(*)aggr#D.ags_gen(gr31,8)                                                                                1552| 000FC8 bclr       4E800020   3     BA         lr
 1545| 000FD4 stw        93E1FFFC   1     ST4A      #stack_prune(gr1,-4)=gr31                                                                                       0|                                CL.1816:
 1545| 000FD8 bl         48000449   0     CALL      gr3=IPRA.$async_gen_unwrap_value,2,(*)aggr#4",gr3,(*)_object",gr4,#ProcAlias",IPRA.$async_gen_unwrap_value"  1523| 000FCC lwz        8062001C   1     L4A        gr3=.PyExc_RuntimeError(gr2,0)
 1545| 000FDC lwz        83E1FFFC   1     L4A       gr31=#stack_prune(gr1,-4)                                                                                    1523| 000FD0 lwz        80820018   1     L4A        gr4=.+CONSTANT_AREA(gr2,0)
 1548| 000FE0 addi       38000002   1     LI        gr0=2                                                                                                           0| 000FD4 lwz        83E1003C   1     L4A        gr31=#stack(gr1,60)
 1547| 000FE4 cmpwi      2C030000   1     C4        cr0=gr3,0                                                                                                    1523| 000FD8 addi       38841478   1     AI         gr4=gr4,5240
 1547| 000FE8 bc         4082001C   1     BF        CL.2285,cr0,0x4/eq,taken=50%(0,0)                                                                            1523| 000FDC lwz        80630000   1     L4A        gr3=PyExc_RuntimeError(gr3,0)
    0| 000FEC lwz        80810058   2     L4A       gr4=#stack(gr1,88)                                                                                           1523| 000FE0 bl         4BFFF021   0     CALL       PyErr_SetString,2,(*)_object",gr3,gr4,#ProcAlias",PyErr_SetString",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0
 1548| 000FF0 stw        901F0010   1     ST4A      (*)aggr#D.ags_state(gr31,16)=gr0                                                                             1523| 000FE4 ori        60000000   1
    0| 000FF4 mtspr      7C8803A6   1     LLR       lr=gr4                                                                                                       1526| 000FE8 addi       38600000   1     LI         gr3=0
    0| 000FF8 lwz        83E1004C   1     L4A       gr31=#stack(gr1,76)                                                                                             0| 000FEC lwz        80010048   1     L4A        gr0=#stack(gr1,72)
 1552| 000FFC addi       38210050   1     AI        gr1=gr1,80                                                                                                   1552| 000FF0 addi       38210040   1     AI         gr1=gr1,64
 1552| 001000 bclr       4E800020   1     BA        lr                                                                                                              0| 000FF4 mtspr      7C0803A6   1     LLR        lr=gr0
    0|                                CL.2285:                                                                                                                   1552| 000FF8 bclr       4E800020   3     BA         lr
    0| 001004 lwz        80010058   1     L4A       gr0=#stack(gr1,88)                                                                                               |               Tag Table
    0| 001008 lwz        83E1004C   1     L4A       gr31=#stack(gr1,76)                                                                                              | 000FFC        00000000 00002041 80010200 00000000 0000011C 00146173
 1552| 00100C addi       38210050   1     AI        gr1=gr1,80                                                                                                       | 001014        796E635F 67656E5F 6173656E 645F7365 6E64
    0| 001010 mtspr      7C0803A6   1     LLR       lr=gr0                                                                                                           |               Instruction count           71
 1552| 001014 bclr       4E800020   3     BA        lr                                                                                                               |               Straight-line exec time     76
 1537|                                CL.93:                                                                                                                     GPR's set/used:   su-s ssss ssss s---  ---- ---- ---- ----
 1538| 001018 lwz        809F000C   1     L4A       gr4=(*)aggr#D.ags_sendval(gr31,12)                                                                           FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----
 1540| 00101C stw        913F0010   1     ST4A      (*)aggr#D.ags_state(gr31,16)=gr9                                                                             CCR's set/used:   ss-- -sss
    0| 001020 b          4BFFFFA4   0     B         CL.91,-1                                                                                                         | 000000                             PDEF       async_gen_asend_traverse
    0|                                CL.1710:                                                                                                                   1509|                                    PROC       o_126_13_127_13,visit_126_13_127_13,arg_126_13_127_13,gr3-gr5
 1531| 001024 lwz        8062001C   1     L4A       gr3=.PyExc_RuntimeError(gr2,0)                                                                               1511| 001040 lwz        80030008   1     L4A        gr0=(*)aggr#D.ags_gen(gr3,8)
 1531| 001028 lwz        80820018   1     L4A       gr4=.+CONSTANT_AREA(gr2,0)                                                                                   1511| 001044 cmpwi      2C000000   2     C4         cr0=gr0,0
    0| 00102C lwz        83E1004C   1     L4A       gr31=#stack(gr1,76)                                                                                          1511| 001048 bc         4082001C   1     BF         CL.1825,cr0,0x4/eq,taken=30%(30,70)
 1531| 001030 addi       388414AC   1     AI        gr4=gr4,5292                                                                                                 1512| 00104C lwz        8003000C   1     L4A        gr0=(*)aggr#D.ags_sendval(gr3,12)
 1531| 001034 lwz        80630000   1     L4A       gr3=<s143:d0:l4>(gr3,0)                                                                                      1512| 001050 cmpwi      2C000000   2     C4         cr0=gr0,0
 1531| 001038 bl         4BFFEFC9   0     CALL      PyErr_SetString,2,(*)_object",gr3,gr4,#ProcAlias",PyErr_SetString",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"  1512| 001054 bc         4082000C   1     BF         CL.2323,cr0,0x4/eq,taken=40%(40,60)
 1531| 00103C ori        60000000   1                                                                                                                            1513| 001058 addi       38600000   1     LI         gr3=0
 1534| 001040 addi       38600000   1     LI        gr3=0                                                                                                        1514| 00105C bclr       4E800020   0     BA         lr
    0| 001044 lwz        80010058   1     L4A       gr0=#stack(gr1,88)                                                                                              0|                                CL.2323:
 1552| 001048 addi       38210050   1     AI        gr1=gr1,80                                                                                                   1514| 001060 b          48005660   0     CALLF      gr3=async_gen_asend_traverse at AF126_13,3,gr3-gr5,fcr",async_gen_asend_traverse at AF126_13",gr1,cr[01567]",gr0
    0| 00104C mtspr      7C0803A6   1     LLR       lr=gr0                                                                                                          0|                                CL.1825:







Wed Apr 15 07:30:04 CDT 2020  Page 78


 1552| 001050 bclr       4E800020   3     BA        lr                                                                                                           1514| 001064 b          480056FC   0     CALLF      gr3=async_gen_asend_traverse at AF127_13,3,gr3-gr5,fcr",async_gen_asend_traverse at AF127_13",gr1,cr[01567]",gr0
    0|                                CL.1708:                                                                                                                       |               Tag Table
 1523| 001054 lwz        8062001C   1     L4A       gr3=.PyExc_RuntimeError(gr2,0)                                                                                   | 001068        00000000 00002040 00000300 00000000 00000028 00186173
 1523| 001058 lwz        80820018   1     L4A       gr4=.+CONSTANT_AREA(gr2,0)                                                                                       | 001080        796E635F 67656E5F 6173656E 645F7472 61766572 7365
    0| 00105C lwz        83E1004C   1     L4A       gr31=#stack(gr1,76)                                                                                              |               Instruction count           10
 1523| 001060 addi       38841478   1     AI        gr4=gr4,5240                                                                                                     |               Straight-line exec time      9
 1523| 001064 lwz        80630000   1     L4A       gr3=<s143:d0:l4>(gr3,0)                                                                                      GPR's set/used:   ssus ssss ssss s---  ---- ---- ---- -sss
 1523| 001068 bl         4BFFEF99   0     CALL      PyErr_SetString,2,(*)_object",gr3,gr4,#ProcAlias",PyErr_SetString",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"  FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----
 1523| 00106C ori        60000000   1                                                                                                                            CCR's set/used:   ss-- -sss
 1526| 001070 addi       38600000   1     LI        gr3=0                                                                                                            | 000000                             PDEF       async_gen_asend_dealloc
    0| 001074 lwz        80010058   1     L4A       gr0=#stack(gr1,88)                                                                                           1495|                                    PROC       o,gr3
 1552| 001078 addi       38210050   1     AI        gr1=gr1,80                                                                                                      0| 0010A0 mfspr      7C0802A6   1     LFLR       gr0=lr
    0| 00107C mtspr      7C0803A6   1     LLR       lr=gr0                                                                                                          0| 0010A4 stwu       9421FFB0   1     ST4U       gr1,#stack(gr1,-80)=gr1
 1552| 001080 bclr       4E800020   3     BA        lr                                                                                                              0| 0010A8 stw        90010058   1     ST4A       #stack(gr1,88)=gr0
     |               Tag Table                                                                                                                                      0| 0010AC stw        93E1004C   1     ST4A       #stack(gr1,76)=gr31
     | 001084        00000000 00002041 80010200 00000000 00000124 00146173                                                                                          0| 0010B0 ori        607F0000   1     LR         gr31=gr3
     | 00109C        796E635F 67656E5F 6173656E 645F7365 6E64                                                                                                       0| 0010B4 stw        93C10048   1     ST4A       #stack(gr1,72)=gr30
     |               Instruction count           73                                                                                                                 0| 0010B8 stw        93A10044   1     ST4A       #stack(gr1,68)=gr29
     |               Straight-line exec time     78                                                                                                                73| 0010BC addi       3BC00000   1     LI         gr30=0
 GPR's set/used:   ssus ssss ssss s---  ---- ---- ---- ----                                                                                                         0| 0010C0 lwz        83A20018   1     L4A        gr29=.+CONSTANT_AREA(gr2,0)
 FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----                                                                                                        64| 0010C4 lwz        8003FFF8   1     L4A        gr0=(*)_object%##2(gr3,-8)
 CCR's set/used:   ss-- -sss                                                                                                                                       64| 0010C8 cmpwi      2C000000   2     C4         cr0=gr0,0
     | 000000                             PDEF     async_gen_asend_traverse                                                                                        64| 0010CC bc         418201CC   1     BT         CL.1835,cr0,0x4/eq,taken=10%(10,90)
 1509|                                    PROC      o,visit,arg,gr3-gr5                                                                                            69| 0010D0 lwz        80C3FFFC   1     L4A        gr6=(*)aggr#2._gc_prev(gr3,-4)
    0| 0010C0 mfspr      7C0802A6   1     LFLR      gr0=lr                                                                                                         70| 0010D4 lwz        8063FFF8   1     L4A        gr3=(*)aggr#2._gc_next(gr3,-8)
    0| 0010C4 ori        60660000   1     LR        gr6=gr3                                                                                                      1498| 0010D8 lwz        80BF0008   1     L4A        gr5=(*)aggr#D.ags_gen(gr31,8)
 1511| 0010C8 lwz        80630008   1     L4A       gr3=(*)aggr#D.ags_gen(gr3,8)                                                                                    0| 0010DC or.        7CA02B79   2     LR_R       gr0,cr0=gr5
 1511| 0010CC cmpwi      2C030000   2     C4        cr0=gr3,0                                                                                                      69| 0010E0 rlwinm     54C4003A   1     RN4        gr4=gr6,0,0xFFFFFFFC
    0| 0010D0 stw        90010008   1     ST4A      #stack(gr1,8)=gr0                                                                                              72| 0010E4 lwz        80030004   1     L4A        gr0=(*)aggr#2._gc_prev(gr3,4)
    0| 0010D4 ori        60A00000   1     LR        gr0=gr5                                                                                                        71| 0010E8 stw        90640000   1     ST4A       (*)aggr#2._gc_next(gr4,0)=gr3
    0| 0010D8 stwu       9421FFA0   1     ST4U      gr1,#stack(gr1,-96)=gr1                                                                                        73| 0010EC stw        93DFFFF8   1     ST4A       (*)aggr#2._gc_next(gr31,-8)=gr30
    0| 0010DC ori        60850000   1     LR        gr5=gr4                                                                                                        72| 0010F0 rlwimi     50C0003A   1     RI4        gr0=gr6,0,gr0,0xFFFFFFFC
 1511| 0010E0 ori        60040000   1     LR        gr4=gr0                                                                                                        72| 0010F4 stw        90030004   1     ST4A       (*)aggr#2._gc_prev(gr3,4)=gr0
 1511| 0010E4 stw        90410014   1     ST4A      #cur_toc(gr1,20)=gr2                                                                                           74| 0010F8 lwz        807FFFFC   1     L4A        gr3=(*)aggr#2._gc_prev(gr31,-4)
 1511| 0010E8 bc         41820080   0     BT        CL.2278,cr0,0x4/eq,taken=30%(30,70)                                                                            74| 0010FC rlwinm     546007FE   2     RN4        gr0=gr3,0,0x1
    0| 0010EC stw        90C1004C   1     ST4A      #parameter_store0(gr1,76)=gr6                                                                                  74| 001100 stw        901FFFFC   1     ST4A       (*)aggr#2._gc_prev(gr31,-4)=gr0
    0| 0010F0 stw        90010050   1     ST4A      #parameter_store1(gr1,80)=gr0                                                                                1498| 001104 bc         41820030   0     BT         CL.1827,cr0,0x4/eq,taken=50%(0,0)
    0| 0010F4 stw        90A10054   1     ST4A      #parameter_store2(gr1,84)=gr5                                                                                1498| 001108 stw        93DF0008   1     ST4A       (*)aggr#D.ags_gen(gr31,8)=gr30
 1511| 0010F8 lwz        80050000   1     L4A       gr0=#fnc_adr(gr5,0)                                                                                           415| 00110C lwz        80820004   1     L4A        gr4=._Py_RefTotal(gr2,0)
 1511| 0010FC lwz        81650008   1     L4A       gr11=#new_env(gr5,8)                                                                                          417| 001110 lwz        80650000   1     L4A        gr3=(*)_object._object.ob_refcnt(gr5,0)
 1511| 001100 mtspr      7C0903A6   1     LCTR      ctr=gr0                                                                                                       417| 001114 addi       3803FFFF   2     AI         gr0=gr3,-1
 1511| 001104 lwz        80450004   1     CALL      gr3=gr5,2,(*)_object",gr3,(*)void",gr4,#ProcAlias",fcr",(*)int()",gr1,cr[01567]",gr0",gr4"-gr12",fp0"-fp13"   417| 001118 stw        90050000   1     ST4A       (*)_object._object.ob_refcnt(gr5,0)=gr0
 1511| 001108 bcctrl     4E800421   0                                                                                                                             415| 00111C lwz        80640000   1     L4A        gr3=_Py_RefTotal(gr4,0)
 1511| 00110C lwz        80410014   1                                                                                                                             415| 001120 addi       38C3FFFF   2     AI         gr6=gr3,-1
 1511| 001110 cmpwi      2C030000   1     C4        cr0=gr3,0                                                                                                     415| 001124 stw        90C40000   1     ST4A       _Py_RefTotal(gr4,0)=gr6
 1511| 001114 lwz        80C1004C   1     L4A       gr6=#parameter_store0(gr1,76)                                                                                 417| 001128 cmpwi      2C000000   1     C4         cr0=gr0,0
 1511| 001118 lwz        80010050   1     L4A       gr0=#parameter_store1(gr1,80)                                                                                 417| 00112C bc         4182015C   1     BT         CL.1442,cr0,0x4/eq,taken=40%(40,60)
 1511| 00111C lwz        80A10054   1     L4A       gr5=#parameter_store2(gr1,84)                                                                                 419| 001130 bc         41800138   1     BT         CL.2315,cr0,0x1/lt,taken=40%(40,60)
 1511| 001120 bc         40820038   0     BF        CL.714,cr0,0x4/eq,taken=30%(30,70)                                                                              0|                                CL.1827:
 1512| 001124 lwz        8066000C   2     L4A       gr3=(*)aggr#D.ags_sendval(gr6,12)                                                                            1499| 001134 lwz        80BF000C   1     L4A        gr5=(*)aggr#D.ags_sendval(gr31,12)
 1512| 001128 cmpwi      2C030000   2     C4        cr0=gr3,0                                                                                                       0| 001138 or.        7CA02B79   2     LR_R       gr0,cr0=gr5
 1512| 00112C bc         41820028   1     BT        CL.106,cr0,0x4/eq,taken=30%(30,70)                                                                           1499| 00113C bc         408200CC   1     BF         CL.1828,cr0,0x4/eq,taken=50%(0,0)
    0|                                CL.1717:                                                                                                                      0|                                CL.1831:
 1512| 001130 ori        60040000   1     LR        gr4=gr0                                                                                                      1500| 001140 lwz        83C20020   1     L4A        gr30=.$STATIC(gr2,0)
 1512| 001134 lwz        80050000   1     L4A       gr0=#fnc_adr(gr5,0)                                                                                          1500| 001144 lwz        807E000C   2     L4A        gr3=ag_asend_freelist_free(gr30,12)
 1512| 001138 lwz        81650008   1     L4A       gr11=#new_env(gr5,8)                                                                                         1500| 001148 cmpwi      2C030050   2     C4         cr0=gr3,80







Wed Apr 15 07:30:04 CDT 2020  Page 79


 1512| 00113C mtspr      7C0903A6   1     LCTR      ctr=gr0                                                                                                      1500| 00114C bc         40800094   1     BF         CL.2316,cr0,0x1/lt,taken=30%(30,70)
 1512| 001140 lwz        80450004   1     CALL      gr3=gr5,2,(*)_object",gr3,(*)void",gr4,#ProcAlias",fcr",(*)int()",gr1,cr[01567]",gr0",gr4"-gr12",fp0"-fp13"     0|                                CL.1832:
 1512| 001144 bcctrl     4E800421   0                                                                                                                            1501| 001150 lwz        80020060   1     L4A        gr0=._PyAsyncGenASend_Type(gr2,0)
 1512| 001148 lwz        80410014   1                                                                                                                             128| 001154 lwz        809F0004   1     L4A        gr4=(*)C_object._object.ob_type(gr31,4)
 1512| 00114C cmpwi      2C030000   1     C4        cr0=gr3,0                                                                                                     128| 001158 cmplw      7C040040   2     CL4        cr0=gr4,gr0
 1512| 001150 bc         40820008   1     BF        CL.714,cr0,0x4/eq,taken=50%(0,0)                                                                             1501| 00115C bc         40820038   1     BF         CL.1836,cr0,0x4/eq,taken=40%(40,60)
 1512|                                CL.106:                                                                                                                    1502| 001160 lwz        80820044   1     L4A        gr4=.$STATIC_BSS(gr2,0)
 1513| 001154 addi       38600000   1     LI        gr3=0                                                                                                        1502| 001164 rlwinm     5465103A   1     SLL4       gr5=gr3,2
 1514|                                CL.714:                                                                                                                    1502| 001168 addi       38030001   1     AI         gr0=gr3,1
 1514| 001158 addi       38210060   1     AI        gr1=gr1,96                                                                                                      0| 00116C lwz        83A10044   1     L4A        gr29=#stack(gr1,68)
    0| 00115C lwz        80010008   1     L4A       gr0=#stack(gr1,8)                                                                                            1502| 001170 stw        901E000C   1     ST4A       ag_asend_freelist_free(gr30,12)=gr0
    0| 001160 mtspr      7C0803A6   2     LLR       lr=gr0                                                                                                       1502| 001174 addi       38640140   1     AI         gr3=gr4,320
 1514| 001164 bclr       4E800020   3     BA        lr                                                                                                           1502| 001178 stwx       7FE3292E   1     ST4A       ag_asend_freelist[]0(gr3,gr5,0)=gr31
    0|                                CL.2278:                                                                                                                      0| 00117C lwz        83E1004C   1     L4A        gr31=#stack(gr1,76)
 1512| 001168 lwz        8066000C   1     L4A       gr3=(*)aggr#D.ags_sendval(gr6,12)                                                                               0| 001180 lwz        83C10048   1     L4A        gr30=#stack(gr1,72)
 1512| 00116C cmpwi      2C030000   2     C4        cr0=gr3,0                                                                                                       0| 001184 lwz        80010058   1     L4A        gr0=#stack(gr1,88)
 1512| 001170 bc         4182FFE4   1     BT        CL.106,cr0,0x4/eq,taken=30%(30,70)                                                                           1506| 001188 addi       38210050   1     AI         gr1=gr1,80
    0| 001174 b          4BFFFFBC   1     B         CL.1717,-1                                                                                                      0| 00118C mtspr      7C0803A6   1     LLR        lr=gr0
     |               Tag Table                                                                                                                                   1506| 001190 bclr       4E800020   3     BA         lr
     | 001178        00000000 00002041 80000300 00000000 000000B8 00186173                                                                                          0|                                CL.1836:
     | 001190        796E635F 67656E5F 6173656E 645F7472 61766572 7365                                                                                           1501| 001194 addi       387D14E0   1     AI         gr3=gr29,5344
     |               Instruction count           46                                                                                                              1501| 001198 addi       389D1110   1     AI         gr4=gr29,4368
     |               Straight-line exec time     49                                                                                                              1501| 00119C addi       38A005DD   1     LI         gr5=1501
 GPR's set/used:   ssus ssss ssss s---  ---- ---- ---- -sss                                                                                                      1501| 0011A0 bl         4BFFEE61   0     CALL       __assert,3,gr3-gr5,#ProcAlias",__assert",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",lr",fcr",xer",
 FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----                                                                                                      1501| 0011A4 ori        60000000   1
 CCR's set/used:   ss-- -sss                                                                                                                                        0| 0011A8 lwz        807E000C   1     L4A        gr3=ag_asend_freelist_free(gr30,12)
     | 000000                             PDEF     async_gen_asend_dealloc                                                                                       1502| 0011AC lwz        80820044   1     L4A        gr4=.$STATIC_BSS(gr2,0)
 1495|                                    PROC      o,gr3                                                                                                           0| 0011B0 lwz        83A10044   1     L4A        gr29=#stack(gr1,68)
    0| 0011C0 mfspr      7C0802A6   1     LFLR      gr0=lr                                                                                                       1502| 0011B4 rlwinm     5465103A   1     SLL4       gr5=gr3,2
    0| 0011C4 stw        90010008   2     ST4A      #stack(gr1,8)=gr0                                                                                            1502| 0011B8 addi       38840140   1     AI         gr4=gr4,320
    0| 0011C8 stw        93E1FFFC   1     ST4A      #stack(gr1,-4)=gr31                                                                                          1502| 0011BC addi       38030001   1     AI         gr0=gr3,1
    0| 0011CC ori        607F0000   1     LR        gr31=gr3                                                                                                     1502| 0011C0 stw        901E000C   1     ST4A       ag_asend_freelist_free(gr30,12)=gr0
    0| 0011D0 stw        93C1FFF8   1     ST4A      #stack(gr1,-8)=gr30                                                                                          1502| 0011C4 stwx       7FE4292E   1     ST4A       ag_asend_freelist[]0(gr4,gr5,0)=gr31
    0| 0011D4 stw        93A1FFF4   1     ST4A      #stack(gr1,-12)=gr29                                                                                            0| 0011C8 lwz        83E1004C   1     L4A        gr31=#stack(gr1,76)
   73| 0011D8 addi       3BC00000   1     LI        gr30=0                                                                                                          0| 0011CC lwz        83C10048   1     L4A        gr30=#stack(gr1,72)
    0| 0011DC lwz        83A20018   1     L4A       gr29=.+CONSTANT_AREA(gr2,0)                                                                                     0| 0011D0 lwz        80010058   1     L4A        gr0=#stack(gr1,88)
   64| 0011E0 lwz        8003FFF8   1     L4A       gr0=(*)_object%##2(gr3,-8)                                                                                   1506| 0011D4 addi       38210050   1     AI         gr1=gr1,80
    0| 0011E4 stwu       9421FFB0   1     ST4U      gr1,#stack(gr1,-80)=gr1                                                                                         0| 0011D8 mtspr      7C0803A6   1     LLR        lr=gr0
   64| 0011E8 cmpwi      2C000000   1     C4        cr0=gr0,0                                                                                                    1506| 0011DC bclr       4E800020   3     BA         lr
   64| 0011EC bc         418201CC   1     BT        CL.1728,cr0,0x4/eq,taken=10%(10,90)                                                                             0|                                CL.2316:
   69| 0011F0 lwz        80C3FFFC   1     L4A       gr6=(*)aggr#2._gc_prev(gr3,-4)                                                                               1504| 0011E0 ori        63E30000   1     LR         gr3=gr31
   70| 0011F4 lwz        8063FFF8   1     L4A       gr3=(*)aggr#2._gc_next(gr3,-8)                                                                                  0| 0011E4 lwz        83A10044   1     L4A        gr29=#stack(gr1,68)
 1498| 0011F8 lwz        80BF0008   1     L4A       gr5=(*)aggr#D.ags_gen(gr31,8)                                                                                1504| 0011E8 bl         4BFFEE19   0     CALL       PyObject_GC_Del,1,(*)void",gr3,#ProcAlias",PyObject_GC_Del",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13"
   69| 0011FC rlwinm     54C4003A   1     RN4       gr4=gr6,0,0xFFFFFFFC                                                                                         1504| 0011EC ori        60000000   1
    0| 001200 or.        7CA02B79   1     LR_R      gr0,cr0=gr5                                                                                                     0| 0011F0 lwz        83E1004C   1     L4A        gr31=#stack(gr1,76)
   72| 001204 lwz        80030004   1     L4A       gr0=(*)aggr#2._gc_prev(gr3,4)                                                                                   0| 0011F4 lwz        83C10048   1     L4A        gr30=#stack(gr1,72)
   71| 001208 stw        90640000   1     ST4A      (*)aggr#2._gc_next(gr4,0)=gr3                                                                                   0| 0011F8 lwz        80010058   1     L4A        gr0=#stack(gr1,88)
   73| 00120C stw        93DFFFF8   1     ST4A      (*)aggr#2._gc_next(gr31,-8)=gr30                                                                             1506| 0011FC addi       38210050   1     AI         gr1=gr1,80
   72| 001210 rlwimi     50C0003A   1     RI4       gr0=gr6,0,gr0,0xFFFFFFFC                                                                                        0| 001200 mtspr      7C0803A6   1     LLR        lr=gr0
   72| 001214 stw        90030004   1     ST4A      (*)aggr#2._gc_prev(gr3,4)=gr0                                                                                1506| 001204 bclr       4E800020   3     BA         lr
   74| 001218 lwz        807FFFFC   1     L4A       gr3=(*)aggr#2._gc_prev(gr31,-4)                                                                                 0|                                CL.1828:
   74| 00121C rlwinm     546007FE   2     RN4       gr0=gr3,0,0x1                                                                                                 415| 001208 lwz        80820004   1     L4A        gr4=._Py_RefTotal(gr2,0)
   74| 001220 stw        901FFFFC   1     ST4A      (*)aggr#2._gc_prev(gr31,-4)=gr0                                                                               417| 00120C lwz        80650000   1     L4A        gr3=(*)_object._object.ob_refcnt(gr5,0)
 1498| 001224 bc         41820030   0     BT        CL.1720,cr0,0x4/eq,taken=50%(0,0)                                                                            1499| 001210 stw        93DF000C   1     ST4A       (*)aggr#D.ags_sendval(gr31,12)=gr30
 1498| 001228 stw        93DF0008   1     ST4A      (*)aggr#D.ags_gen(gr31,8)=gr30                                                                                417| 001214 addi       3803FFFF   1     AI         gr0=gr3,-1
  415| 00122C lwz        80820004   1     L4A       gr4=._Py_RefTotal(gr2,0)                                                                                      417| 001218 stw        90050000   1     ST4A       (*)_object._object.ob_refcnt(gr5,0)=gr0







Wed Apr 15 07:30:04 CDT 2020  Page 80


  417| 001230 lwz        80650000   1     L4A       gr3=(*)_object._object.ob_refcnt(gr5,0)                                                                       415| 00121C lwz        80640000   1     L4A        gr3=_Py_RefTotal(gr4,0)
  417| 001234 addi       3803FFFF   2     AI        gr0=gr3,-1                                                                                                    415| 001220 addi       38C3FFFF   2     AI         gr6=gr3,-1
  417| 001238 stw        90050000   1     ST4A      (*)_object._object.ob_refcnt(gr5,0)=gr0                                                                       415| 001224 stw        90C40000   1     ST4A       _Py_RefTotal(gr4,0)=gr6
  415| 00123C lwz        80640000   1     L4A       gr3=<s117:d0:l4>(gr4,0)                                                                                       417| 001228 cmpwi      2C000000   1     C4         cr0=gr0,0
  415| 001240 addi       38C3FFFF   2     AI        gr6=gr3,-1                                                                                                    417| 00122C bc         4182002C   1     BT         CL.1446,cr0,0x4/eq,taken=40%(40,60)
  415| 001244 stw        90C40000   1     ST4A      <s117:d0:l4>(gr4,0)=gr6                                                                                       419| 001230 bc         4080FF10   1     BF         CL.1831,cr0,0x1/lt,taken=60%(60,40)
  417| 001248 cmpwi      2C000000   1     C4        cr0=gr0,0                                                                                                     420| 001234 addi       387D1110   2     AI         gr3=gr29,4368
  417| 00124C bc         4182015C   1     BT        CL.1442,cr0,0x4/eq,taken=40%(40,60)                                                                           420| 001238 addi       388005DB   1     LI         gr4=1499
  419| 001250 bc         41800138   1     BT        CL.2274,cr0,0x1/lt,taken=40%(40,60)                                                                           420| 00123C bl         4BFFEDC5   0     CALL       _Py_NegativeRefcount,3,(*)Cuchar",gr3,gr4,(*)_object",gr5,#ProcAlias",_Py_NegativeRefcount",fcr",gr1,cr[01
    0|                                CL.1720:                                                                                                                    420| 001240 ori        60000000   1
 1499| 001254 lwz        80BF000C   1     L4A       gr5=(*)aggr#D.ags_sendval(gr31,12)                                                                           1500| 001244 lwz        83C20020   1     L4A        gr30=.$STATIC(gr2,0)
    0| 001258 or.        7CA02B79   2     LR_R      gr0,cr0=gr5                                                                                                  1500| 001248 lwz        807E000C   2     L4A        gr3=ag_asend_freelist_free(gr30,12)
 1499| 00125C bc         408200CC   1     BF        CL.1721,cr0,0x4/eq,taken=50%(0,0)                                                                            1500| 00124C cmpwi      2C030050   2     C4         cr0=gr3,80
    0|                                CL.1724:                                                                                                                   1500| 001250 bc         4180FF00   1     BT         CL.1832,cr0,0x1/lt,taken=70%(70,30)
 1500| 001260 lwz        83C20020   1     L4A       gr30=.$STATIC(gr2,0)                                                                                            0| 001254 b          4BFFFF8C   1     B          CL.2316,-1
 1500| 001264 lwz        807E000C   2     L4A       gr3=ag_asend_freelist_free(gr30,12)                                                                           423|                                CL.1446:
 1500| 001268 cmpwi      2C030050   2     C4        cr0=gr3,80                                                                                                    425| 001258 ori        60A30000   1     LR         gr3=gr5
 1500| 00126C bc         40800094   1     BF        CL.2275,cr0,0x1/lt,taken=30%(30,70)                                                                           425| 00125C bl         4BFFEDA5   0     CALL       _Py_Dealloc,1,(*)_object",gr3,#ProcAlias",_Py_Dealloc",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",
    0|                                CL.1725:                                                                                                                    425| 001260 ori        60000000   1
 1501| 001270 lwz        80020060   1     L4A       gr0=._PyAsyncGenASend_Type(gr2,0)                                                                               0| 001264 b          4BFFFEDC   0     B          CL.1831,-1
  128| 001274 lwz        809F0004   1     L4A       gr4=(*)C_object._object.ob_type(gr31,4)                                                                         0|                                CL.2315:
  128| 001278 cmplw      7C040040   2     CL4       cr0=gr4,gr0                                                                                                   420| 001268 addi       387D1110   1     AI         gr3=gr29,4368
 1501| 00127C bc         40820038   1     BF        CL.1729,cr0,0x4/eq,taken=40%(40,60)                                                                           420| 00126C addi       388005DA   1     LI         gr4=1498
 1502| 001280 lwz        80820044   1     L4A       gr4=.$STATIC_BSS(gr2,0)                                                                                       420| 001270 bl         4BFFED91   0     CALL       _Py_NegativeRefcount,3,(*)Cuchar",gr3,gr4,(*)_object",gr5,#ProcAlias",_Py_NegativeRefcount",fcr",gr1,cr[01
 1502| 001284 rlwinm     5465103A   1     SLL4      gr5=gr3,2                                                                                                     420| 001274 ori        60000000   1
 1502| 001288 addi       38030001   1     AI        gr0=gr3,1                                                                                                    1499| 001278 lwz        80BF000C   1     L4A        gr5=(*)aggr#D.ags_sendval(gr31,12)
    0| 00128C lwz        83A10044   1     L4A       gr29=#stack(gr1,68)                                                                                             0| 00127C or.        7CA02B79   2     LR_R       gr0,cr0=gr5
 1502| 001290 stw        901E000C   1     ST4A      ag_asend_freelist_free(gr30,12)=gr0                                                                          1499| 001280 bc         4182FEC0   1     BT         CL.1831,cr0,0x4/eq,taken=50%(0,0)
 1502| 001294 addi       38640140   1     AI        gr3=gr4,320                                                                                                  1499| 001284 b          4BFFFF84   1     B          CL.1828,-1
 1502| 001298 stwx       7FE3292E   1     ST4A      ag_asend_freelist[]0(gr3,gr5,0)=gr31                                                                          423|                                CL.1442:
    0| 00129C lwz        83E1004C   1     L4A       gr31=#stack(gr1,76)                                                                                           425| 001288 ori        60A30000   1     LR         gr3=gr5
 1506| 0012A0 addi       38210050   1     AI        gr1=gr1,80                                                                                                    425| 00128C bl         4BFFED75   0     CALL       _Py_Dealloc,1,(*)_object",gr3,#ProcAlias",_Py_Dealloc",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",
    0| 0012A4 lwz        83C1FFF8   1     L4A       gr30=#stack(gr1,-8)                                                                                           425| 001290 ori        60000000   1
    0| 0012A8 lwz        80010008   1     L4A       gr0=#stack(gr1,8)                                                                                               0| 001294 b          4BFFFEA0   0     B          CL.1827,-1
    0| 0012AC mtspr      7C0803A6   2     LLR       lr=gr0                                                                                                          0|                                CL.1835:
 1506| 0012B0 bclr       4E800020   3     BA        lr                                                                                                             64| 001298 addi       389D13E4   1     AI         gr4=gr29,5092
    0|                                CL.1729:                                                                                                                     64| 00129C addi       38BD140C   1     AI         gr5=gr29,5132
 1501| 0012B4 addi       387D14E0   1     AI        gr3=gr29,5344                                                                                                  64| 0012A0 addi       38DD1110   1     AI         gr6=gr29,4368
 1501| 0012B8 addi       389D1110   1     AI        gr4=gr29,4368                                                                                                  64| 0012A4 addi       38E005D9   1     LI         gr7=1497
 1501| 0012BC addi       38A005DD   1     LI        gr5=1501                                                                                                       64| 0012A8 addi       391D1438   1     AI         gr8=gr29,5176
 1501| 0012C0 bl         4BFFED41   0     CALL      __assert,3,gr3-gr5,#ProcAlias",__assert",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",lr",fcr",xer",f    64| 0012AC bl         4BFFED55   0     CALL       _PyObject_AssertFailed,6,(*)_object",gr3-gr5,(*)Cuchar",gr6-gr8,#ProcAlias",_PyObject_AssertFailed",fcr",g
 1501| 0012C4 ori        60000000   1                                                                                                                              64| 0012B0 ori        60000000   1
    0| 0012C8 lwz        807E000C   1     L4A       gr3=ag_asend_freelist_free(gr30,12)                                                                            64| 0012B4 tw         7C8E7008   1     TRAP       9
 1502| 0012CC lwz        80820044   1     L4A       gr4=.$STATIC_BSS(gr2,0)                                                                                          | 0012B8 b          48000000   0
    0| 0012D0 lwz        83A10044   1     L4A       gr29=#stack(gr1,68)                                                                                              |               Tag Table
 1502| 0012D4 rlwinm     5465103A   1     SLL4      gr5=gr3,2                                                                                                        | 0012BC        00000000 00002041 80030100 00000000 0000021C 00176173
 1502| 0012D8 addi       38840140   1     AI        gr4=gr4,320                                                                                                      | 0012D4        796E635F 67656E5F 6173656E 645F6465 616C6C6F 63
 1502| 0012DC addi       38030001   1     AI        gr0=gr3,1                                                                                                        |               Instruction count          135
 1502| 0012E0 stw        901E000C   1     ST4A      ag_asend_freelist_free(gr30,12)=gr0                                                                              |               Straight-line exec time    144
 1502| 0012E4 stwx       7FE4292E   1     ST4A      ag_asend_freelist[]0(gr4,gr5,0)=gr31                                                                         GPR's set/used:   suus ssss ssss s---  ---- ---- ---- ----
    0| 0012E8 lwz        83E1004C   1     L4A       gr31=#stack(gr1,76)                                                                                          FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----
 1506| 0012EC addi       38210050   1     AI        gr1=gr1,80                                                                                                   CCR's set/used:   ss-- -sss
    0| 0012F0 lwz        83C1FFF8   1     L4A       gr30=#stack(gr1,-8)                                                                                              | 000000                             PDEF       async_gen_unwrap_value
    0| 0012F4 lwz        80010008   1     L4A       gr0=#stack(gr1,8)                                                                                            1462|                                    PROC       gen_121_15_122_15,result_121_15_122_15,gr3,gr4
    0| 0012F8 mtspr      7C0803A6   2     LLR       lr=gr0                                                                                                       1464| 001300 cmpwi      2C040000   1     C4         cr0=gr4,0
 1506| 0012FC bclr       4E800020   3     BA        lr                                                                                                           1479| 001304 lwz        80020014   1     L4A        gr0=._PyAsyncGenWrappedValue_Type(gr2,0)







Wed Apr 15 07:30:04 CDT 2020  Page 81


    0|                                CL.2275:                                                                                                                    128| 001308 lwz        80A40004   1     L4A        gr5=(*)C_object._object.ob_type(gr4,4)
 1504| 001300 ori        63E30000   1     LR        gr3=gr31                                                                                                     1464| 00130C bc         41820018   0     BT         CL.1779,cr0,0x4/eq,taken=30%(30,70)
    0| 001304 lwz        83A10044   1     L4A       gr29=#stack(gr1,68)                                                                                           128| 001310 cmplw      7C050040   2     CL4        cr0=gr5,gr0
 1504| 001308 bl         4BFFECF9   0     CALL      PyObject_GC_Del,1,(*)void",gr3,#ProcAlias",PyObject_GC_Del",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",  1479| 001314 bc         4182000C   1     BT         CL.2329,cr0,0x4/eq,taken=40%(40,60)
 1504| 00130C ori        60000000   1                                                                                                                            1487| 001318 ori        60830000   2     LR         gr3=gr4
    0| 001310 lwz        83E1004C   1     L4A       gr31=#stack(gr1,76)                                                                                          1488| 00131C bclr       4E800020   0     BA         lr
 1506| 001314 addi       38210050   1     AI        gr1=gr1,80                                                                                                      0|                                CL.2329:
    0| 001318 lwz        83C1FFF8   1     L4A       gr30=#stack(gr1,-8)                                                                                          1488| 001320 b          48004F20   0     CALLF      gr3=async_gen_unwrap_value at AF121_15,2,gr3,gr4,fcr",async_gen_unwrap_value at AF121_15",gr1,cr[01567]",gr0",gr
    0| 00131C lwz        80010008   1     L4A       gr0=#stack(gr1,8)                                                                                               0|                                CL.1779:
    0| 001320 mtspr      7C0803A6   2     LLR       lr=gr0                                                                                                       1488| 001324 b          4800503C   0     CALLF      gr3=async_gen_unwrap_value at AF122_15,2,gr3,gr4,fcr",async_gen_unwrap_value at AF122_15",gr1,cr[01567]",gr0",gr
 1506| 001324 bclr       4E800020   3     BA        lr                                                                                                               |               Tag Table
    0|                                CL.1721:                                                                                                                       | 001328        00000000 00002040 00000200 00000000 00000028 00166173
  415| 001328 lwz        80820004   1     L4A       gr4=._Py_RefTotal(gr2,0)                                                                                         | 001340        796E635F 67656E5F 756E7772 61705F76 616C7565
  417| 00132C lwz        80650000   1     L4A       gr3=(*)_object._object.ob_refcnt(gr5,0)                                                                          |               Instruction count           10
 1499| 001330 stw        93DF000C   1     ST4A      (*)aggr#D.ags_sendval(gr31,12)=gr30                                                                              |               Straight-line exec time      8
  417| 001334 addi       3803FFFF   1     AI        gr0=gr3,-1                                                                                                   GPR's set/used:   su-s ssss ssss s---  ---- ---- ---- ----
  417| 001338 stw        90050000   1     ST4A      (*)_object._object.ob_refcnt(gr5,0)=gr0                                                                      FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----
  415| 00133C lwz        80640000   1     L4A       gr3=<s117:d0:l4>(gr4,0)                                                                                      CCR's set/used:   ss-- -sss
  415| 001340 addi       38C3FFFF   2     AI        gr6=gr3,-1                                                                                                       | 000000                             PDEF       _PyAsyncGen_Fini
  415| 001344 stw        90C40000   1     ST4A      <s117:d0:l4>(gr4,0)=gr6                                                                                      1455|                                    PROC
  417| 001348 cmpwi      2C000000   1     C4        cr0=gr0,0                                                                                                    1458| 001360 b          48003AA0   0     CALLF      gr3=PyAsyncGen_ClearFreeLists,0,#ProcAlias",PyAsyncGen_ClearFreeLists",fcr",gr1,cr[01567]",gr0",gr4"-gr12"
  417| 00134C bc         4182002C   1     BT        CL.1446,cr0,0x4/eq,taken=40%(40,60)                                                                          1458|                                CL.711:
  419| 001350 bc         4080FF10   1     BF        CL.1724,cr0,0x1/lt,taken=60%(60,40)                                                                              |               Tag Table
  420| 001354 addi       387D1110   2     AI        gr3=gr29,4368                                                                                                    | 001364        00000000 00002040 00000000 00000004 00105F50 79417379
  420| 001358 addi       388005DB   1     LI        gr4=1499                                                                                                         | 00137C        6E634765 6E5F4669 6E69
  420| 00135C bl         4BFFECA5   0     CALL      _Py_NegativeRefcount,3,(*)Cuchar",gr3,gr4,(*)_object",gr5,#ProcAlias",_Py_NegativeRefcount",fcr",gr1,cr[015      |               Instruction count            1
  420| 001360 ori        60000000   1                                                                                                                                |               Straight-line exec time      0
 1500| 001364 lwz        83C20020   1     L4A       gr30=.$STATIC(gr2,0)                                                                                         GPR's set/used:   ss-s ssss ssss s---  ---- ---- ---- --ss
 1500| 001368 lwz        807E000C   2     L4A       gr3=ag_asend_freelist_free(gr30,12)                                                                          FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----
 1500| 00136C cmpwi      2C030050   2     C4        cr0=gr3,80                                                                                                   CCR's set/used:   ss-- -sss
 1500| 001370 bc         4180FF00   1     BT        CL.1725,cr0,0x1/lt,taken=70%(70,30)                                                                              | 000000                             PDEF       async_gen_athrow
    0| 001374 b          4BFFFF8C   1     B         CL.2275,-1                                                                                                   1309|                                    PROC       o,args,gr3,gr4
  423|                                CL.1446:                                                                                                                      0| 0013A0 mfspr      7C0802A6   1     LFLR       gr0=lr
  425| 001378 ori        60A30000   1     LR        gr3=gr5                                                                                                         0| 0013A4 stwu       9421FFC0   1     ST4U       gr1,#stack(gr1,-64)=gr1
  425| 00137C bl         4BFFEC85   0     CALL      _Py_Dealloc,1,(*)_object",gr3,#ProcAlias",_Py_Dealloc",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",l     0| 0013A8 stw        90010048   1     ST4A       #stack(gr1,72)=gr0
  425| 001380 ori        60000000   1                                                                                                                               0| 0013AC stw        93E1003C   1     ST4A       #stack(gr1,60)=gr31
    0| 001384 b          4BFFFEDC   0     B         CL.1724,-1                                                                                                      0| 0013B0 ori        607F0000   1     LR         gr31=gr3
    0|                                CL.2274:                                                                                                                      0| 0013B4 stw        93C10038   1     ST4A       #stack(gr1,56)=gr30
  420| 001388 addi       387D1110   1     AI        gr3=gr29,4368                                                                                                   0| 0013B8 ori        609E0000   1     LR         gr30=gr4
  420| 00138C addi       388005DA   1     LI        gr4=1498                                                                                                     1248| 0013BC lwz        80030034   1     L4A        gr0=(*)aggr#4.ag_hooks_inited(gr3,52)
  420| 001390 bl         4BFFEC71   0     CALL      _Py_NegativeRefcount,3,(*)Cuchar",gr3,gr4,(*)_object",gr5,#ProcAlias",_Py_NegativeRefcount",fcr",gr1,cr[015  1248| 0013C0 cmpwi      2C000000   2     C4         cr0=gr0,0
  420| 001394 ori        60000000   1                                                                                                                            1248| 0013C4 bc         40820050   1     BF         CL.2300,cr0,0x4/eq,taken=30%(30,70)
 1499| 001398 lwz        80BF000C   1     L4A       gr5=(*)aggr#D.ags_sendval(gr31,12)                                                                              0| 0013C8 bl         48005499   1     CALL       gr3=async_gen_init_hooks at AF128_21,1,gr3,async_gen_init_hooks",(*)aggr#4",#ProcAlias",fcr",async_gen_init_h
    0| 00139C or.        7CA02B79   2     LR_R      gr0,cr0=gr5                                                                                                  1311| 0013CC cmpwi      2C030000   1     C4         cr0=gr3,0
 1499| 0013A0 bc         4182FEC0   1     BT        CL.1724,cr0,0x4/eq,taken=50%(0,0)                                                                            1312| 0013D0 addi       38600000   1     LI         gr3=0
 1499| 0013A4 b          4BFFFF84   1     B         CL.1721,-1                                                                                                   1311| 0013D4 bc         4182001C   0     BT         CL.1878,cr0,0x4/eq,taken=40%(40,60)
  423|                                CL.1442:                                                                                                                      0| 0013D8 lwz        80010048   2     L4A        gr0=#stack(gr1,72)
  425| 0013A8 ori        60A30000   1     LR        gr3=gr5                                                                                                         0| 0013DC lwz        83E1003C   1     L4A        gr31=#stack(gr1,60)
  425| 0013AC bl         4BFFEC55   0     CALL      _Py_Dealloc,1,(*)_object",gr3,#ProcAlias",_Py_Dealloc",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",l     0| 0013E0 lwz        83C10038   1     L4A        gr30=#stack(gr1,56)
  425| 0013B0 ori        60000000   1                                                                                                                            1315| 0013E4 addi       38210040   1     AI         gr1=gr1,64
    0| 0013B4 b          4BFFFEA0   0     B         CL.1720,-1                                                                                                      0| 0013E8 mtspr      7C0803A6   1     LLR        lr=gr0
    0|                                CL.1728:                                                                                                                   1315| 0013EC bclr       4E800020   3     BA         lr
   64| 0013B8 addi       389D13E4   1     AI        gr4=gr29,5092                                                                                                   0|                                CL.1878:
   64| 0013BC addi       38BD140C   1     AI        gr5=gr29,5132                                                                                                1314| 0013F0 ori        63E30000   1     LR         gr3=gr31
   64| 0013C0 addi       38DD1110   1     AI        gr6=gr29,4368                                                                                                1314| 0013F4 ori        63C40000   1     LR         gr4=gr30
   64| 0013C4 addi       38E005D9   1     LI        gr7=1497                                                                                                     1314| 0013F8 bl         48003329   0     CALL       gr3=IPRA.$async_gen_athrow_new,2,(*)aggr#4",gr3,(*)_object",gr4,#ProcAlias",IPRA.$async_gen_athrow_new",fc







Wed Apr 15 07:30:04 CDT 2020  Page 82


   64| 0013C8 addi       391D1438   1     AI        gr8=gr29,5176                                                                                                   0| 0013FC lwz        83C10038   1     L4A        gr30=#stack(gr1,56)
   64| 0013CC bl         4BFFEC35   0     CALL      _PyObject_AssertFailed,6,(*)_object",gr3-gr5,(*)Cuchar",gr6-gr8,#ProcAlias",_PyObject_AssertFailed",fcr",gr     0| 001400 lwz        80010048   1     L4A        gr0=#stack(gr1,72)
   64| 0013D0 ori        60000000   1                                                                                                                               0| 001404 lwz        83E1003C   1     L4A        gr31=#stack(gr1,60)
   64| 0013D4 tw         7C8E7008   1     TRAP      9                                                                                                            1315| 001408 addi       38210040   1     AI         gr1=gr1,64
     | 0013D8 b          48000000   0                                                                                                                               0| 00140C mtspr      7C0803A6   1     LLR        lr=gr0
     |               Tag Table                                                                                                                                   1315| 001410 bclr       4E800020   3     BA         lr
     | 0013DC        00000000 00002041 80030100 00000000 0000021C 00176173                                                                                          0|                                CL.2300:
     | 0013F4        796E635F 67656E5F 6173656E 645F6465 616C6C6F 63                                                                                                0| 001414 lwz        83E1003C   1     L4A        gr31=#stack(gr1,60)
     |               Instruction count          135                                                                                                                 0| 001418 lwz        83C10038   1     L4A        gr30=#stack(gr1,56)
     |               Straight-line exec time    146                                                                                                              1314| 00141C stw        93C1FFF8   2     ST4A       #stack_prune(gr1,-8)=gr30
 GPR's set/used:   ssus ssss ssss s---  ---- ---- ---- --ss                                                                                                      1314| 001420 stw        93E1FFFC   1     ST4A       #stack_prune(gr1,-4)=gr31
 FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----                                                                                                      1314| 001424 bl         480032FD   0     CALL       gr3=IPRA.$async_gen_athrow_new,2,(*)aggr#4",gr3,(*)_object",gr4,#ProcAlias",IPRA.$async_gen_athrow_new",fc
 CCR's set/used:   ss-- -sss                                                                                                                                     1314| 001428 lwz        83E1FFFC   1     L4A        gr31=#stack_prune(gr1,-4)
     | 000000                             PDEF     IPRA.$async_gen_unwrap_value                                                                                  1314| 00142C lwz        83C1FFF8   1     L4A        gr30=#stack_prune(gr1,-8)
 1462|                                    PROC      gen,result,gr3,gr4                                                                                              0| 001430 lwz        80010048   1     L4A        gr0=#stack(gr1,72)
    0| 001420 mfspr      7C0802A6   1     LFLR      gr0=lr                                                                                                       1315| 001434 addi       38210040   1     AI         gr1=gr1,64
    0| 001424 or.        7C852379   1     LR_R      gr5,cr0=gr4                                                                                                     0| 001438 mtspr      7C0803A6   1     LLR        lr=gr0
    0| 001428 stw        90010008   1     ST4A      #stack(gr1,8)=gr0                                                                                            1315| 00143C bclr       4E800020   3     BA         lr
    0| 00142C stw        93C1FFF8   1     ST4A      #stack(gr1,-8)=gr30                                                                                              |               Tag Table
    0| 001430 ori        607E0000   1     LR        gr30=gr3                                                                                                         | 001440        00000000 00002041 80020200 00000000 000000A0 00106173
    0| 001434 stwu       9421FF90   1     ST4U      gr1,#stack(gr1,-112)=gr1                                                                                         | 001458        796E635F 67656E5F 61746872 6F77
 1464| 001438 bc         418200A8   0     BT        CL.1657,cr0,0x4/eq,taken=30%(30,70)                                                                              |               Instruction count           40
  128| 00143C lwz        80020014   2     L4A       gr0=._PyAsyncGenWrappedValue_Type(gr2,0)                                                                         |               Straight-line exec time     46
  128| 001440 lwz        80650004   1     L4A       gr3=(*)C_object._object.ob_type(gr5,4)                                                                       GPR's set/used:   ss-s ssss ssss s---  ---- ---- ---- ---s
  128| 001444 cmplw      7C030040   2     CL4       cr0=gr3,gr0                                                                                                  FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----
 1479| 001448 bc         40820080   1     BF        CL.129,cr0,0x4/eq,taken=30%(30,70)                                                                           CCR's set/used:   ss-- -sss
    0| 00144C stw        90A10058   1     ST4A      #parameter_store0(gr1,88)=gr5                                                                                    | 000000                             PDEF       async_gen_aclose
 1481| 001450 lwz        80650008   1     L4A       gr3=(*)aggr#C.agw_val(gr5,8)                                                                                 1300|                                    PROC       o,arg,gr3,gr4
 1481| 001454 bl         4800498D   0     CALL      gr3=_PyGen_SetStopIterationValue,1,(*)_object",gr3,#ProcAlias",_PyGen_SetStopIterationValue",fcr",gr1,cr[01     0| 001480 mfspr      7C0802A6   1     LFLR       gr0=lr
  415| 001458 lwz        80820004   1     L4A       gr4=._Py_RefTotal(gr2,0)                                                                                        0| 001484 stwu       9421FFC0   1     ST4U       gr1,#stack(gr1,-64)=gr1
    0| 00145C lwz        80620018   1     L4A       gr3=.+CONSTANT_AREA(gr2,0)                                                                                      0| 001488 stw        90010048   1     ST4A       #stack(gr1,72)=gr0
  408| 001460 addi       38631110   2     AI        gr3=gr3,4368                                                                                                    0| 00148C stw        93E1003C   1     ST4A       #stack(gr1,60)=gr31
 1481| 001464 lwz        80A10058   1     L4A       gr5=#parameter_store0(gr1,88)                                                                                   0| 001490 ori        607F0000   1     LR         gr31=gr3
  417| 001468 lwz        80C50000   2     L4A       gr6=(*)_object._object.ob_refcnt(gr5,0)                                                                      1248| 001494 lwz        80030034   1     L4A        gr0=(*)aggr#4.ag_hooks_inited(gr3,52)
  417| 00146C addi       3806FFFF   2     AI        gr0=gr6,-1                                                                                                   1248| 001498 cmpwi      2C000000   2     C4         cr0=gr0,0
  417| 001470 stw        90050000   1     ST4A      (*)_object._object.ob_refcnt(gr5,0)=gr0                                                                      1248| 00149C bc         40820050   1     BF         CL.2299,cr0,0x4/eq,taken=30%(30,70)
  415| 001474 lwz        80C40000   1     L4A       gr6=<s117:d0:l4>(gr4,0)                                                                                         0| 0014A0 bl         480053C1   1     CALL       gr3=async_gen_init_hooks at AF128_21,1,gr3,async_gen_init_hooks",(*)aggr#4",#ProcAlias",fcr",async_gen_init_h
  415| 001478 addi       38C6FFFF   2     AI        gr6=gr6,-1                                                                                                   1302| 0014A4 cmpwi      2C030000   1     C4         cr0=gr3,0
  415| 00147C stw        90C40000   1     ST4A      <s117:d0:l4>(gr4,0)=gr6                                                                                      1303| 0014A8 addi       38600000   1     LI         gr3=0
  417| 001480 cmpwi      2C000000   1     C4        cr0=gr0,0                                                                                                    1302| 0014AC bc         41820018   0     BT         CL.1881,cr0,0x4/eq,taken=40%(40,60)
  417| 001484 bc         41820034   1     BT        CL.1454,cr0,0x4/eq,taken=40%(40,60)                                                                             0| 0014B0 lwz        80010048   2     L4A        gr0=#stack(gr1,72)
  419| 001488 bc         41800020   1     BT        CL.2282,cr0,0x1/lt,taken=40%(40,60)                                                                             0| 0014B4 lwz        83E1003C   1     L4A        gr31=#stack(gr1,60)
    0|                                CL.1655:                                                                                                                   1306| 0014B8 addi       38210040   1     AI         gr1=gr1,64
 1475| 00148C addi       38600000   1     LI        gr3=0                                                                                                           0| 0014BC mtspr      7C0803A6   1     LLR        lr=gr0
 1475| 001490 stw        907E003C   1     ST4A      (*)aggr#4.ag_running_async(gr30,60)=gr3                                                                      1306| 0014C0 bclr       4E800020   3     BA         lr
    0| 001494 lwz        83C10068   1     L4A       gr30=#stack(gr1,104)                                                                                            0|                                CL.1881:
 1488| 001498 addi       38210070   1     AI        gr1=gr1,112                                                                                                  1305| 0014C4 ori        63E30000   1     LR         gr3=gr31
    0| 00149C lwz        80010008   1     L4A       gr0=#stack(gr1,8)                                                                                            1305| 0014C8 addi       38800000   1     LI         gr4=0
    0| 0014A0 mtspr      7C0803A6   2     LLR       lr=gr0                                                                                                       1305| 0014CC stw        93C1FFF8   1     ST4A       #stack_prune(gr1,-8)=gr30
 1488| 0014A4 bclr       4E800020   3     BA        lr                                                                                                           1305| 0014D0 bl         48003251   0     CALL       gr3=IPRA.$async_gen_athrow_new,2,(*)aggr#4",gr3,(*)_object",gr4,#ProcAlias",IPRA.$async_gen_athrow_new",fc
    0|                                CL.2282:                                                                                                                   1305| 0014D4 lwz        83C1FFF8   1     L4A        gr30=#stack_prune(gr1,-8)
  420| 0014A8 addi       388005CA   1     LI        gr4=1482                                                                                                        0| 0014D8 lwz        83E1003C   1     L4A        gr31=#stack(gr1,60)
  420| 0014AC bl         4BFFEB55   0     CALL      _Py_NegativeRefcount,3,(*)Cuchar",gr3,gr4,(*)_object",gr5,#ProcAlias",_Py_NegativeRefcount",fcr",gr1,cr[015     0| 0014DC lwz        80010048   1     L4A        gr0=#stack(gr1,72)
  420| 0014B0 ori        60000000   1                                                                                                                            1306| 0014E0 addi       38210040   1     AI         gr1=gr1,64
  423| 0014B4 b          4BFFFFD8   0     B         CL.1655,-1                                                                                                      0| 0014E4 mtspr      7C0803A6   1     LLR        lr=gr0
  423|                                CL.1454:                                                                                                                   1306| 0014E8 bclr       4E800020   3     BA         lr







Wed Apr 15 07:30:04 CDT 2020  Page 83


  425| 0014B8 ori        60A30000   1     LR        gr3=gr5                                                                                                         0|                                CL.2299:
  425| 0014BC bl         4BFFEB45   0     CALL      _Py_Dealloc,1,(*)_object",gr3,#ProcAlias",_Py_Dealloc",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",l  1305| 0014EC addi       38800000   1     LI         gr4=0
  425| 0014C0 ori        60000000   1                                                                                                                               0| 0014F0 lwz        83E1003C   1     L4A        gr31=#stack(gr1,60)
    0| 0014C4 b          4BFFFFC8   0     B         CL.1655,-1                                                                                                   1305| 0014F4 stw        93C1FFF8   1     ST4A       #stack_prune(gr1,-8)=gr30
 1485|                                CL.129:                                                                                                                    1305| 0014F8 stw        93E1FFFC   1     ST4A       #stack_prune(gr1,-4)=gr31
 1487| 0014C8 ori        60A30000   1     LR        gr3=gr5                                                                                                      1305| 0014FC bl         48003225   0     CALL       gr3=IPRA.$async_gen_athrow_new,2,(*)aggr#4",gr3,(*)_object",gr4,#ProcAlias",IPRA.$async_gen_athrow_new",fc
    0| 0014CC lwz        83C10068   1     L4A       gr30=#stack(gr1,104)                                                                                         1305| 001500 lwz        83E1FFFC   1     L4A        gr31=#stack_prune(gr1,-4)
 1488| 0014D0 addi       38210070   1     AI        gr1=gr1,112                                                                                                  1305| 001504 lwz        83C1FFF8   1     L4A        gr30=#stack_prune(gr1,-8)
    0| 0014D4 lwz        80010008   1     L4A       gr0=#stack(gr1,8)                                                                                               0| 001508 lwz        80010048   1     L4A        gr0=#stack(gr1,72)
    0| 0014D8 mtspr      7C0803A6   2     LLR       lr=gr0                                                                                                       1306| 00150C addi       38210040   1     AI         gr1=gr1,64
 1488| 0014DC bclr       4E800020   3     BA        lr                                                                                                              0| 001510 mtspr      7C0803A6   1     LLR        lr=gr0
    0|                                CL.1657:                                                                                                                   1306| 001514 bclr       4E800020   3     BA         lr
 1465| 0014E0 bl         4BFFEB21   0     CALL      gr3=PyErr_Occurred,0,#ProcAlias",PyErr_Occurred",fcr",gr1,cr[01567]",gr0",gr4"-gr12",fp0"-fp13",mq",lr",fcr      |               Tag Table
 1465| 0014E4 ori        60000000   1                                                                                                                                | 001518        00000000 00002041 80010200 00000000 00000098 00106173
 1465| 0014E8 cmpwi      2C030000   1     C4        cr0=gr3,0                                                                                                        | 001530        796E635F 67656E5F 61636C6F 7365
    0| 0014EC lwz        83E20024   1     L4A       gr31=.PyExc_StopAsyncIteration(gr2,0)                                                                            |               Instruction count           38
 1465| 0014F0 bc         41820048   0     BT        CL.1659,cr0,0x4/eq,taken=50%(0,0)                                                                                |               Straight-line exec time     43
 1469| 0014F4 lwz        807F0000   2     L4A       gr3=<s137:d0:l4>(gr31,0)                                                                                     GPR's set/used:   ss-s ssss ssss s---  ---- ---- ---- --ss
 1469| 0014F8 bl         4BFFEB09   0     CALL      gr3=PyErr_ExceptionMatches,1,(*)_object",gr3,#ProcAlias",PyErr_ExceptionMatches",fcr",gr1,cr[01567]",gr0",g  FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----
 1469| 0014FC ori        60000000   1                                                                                                                            CCR's set/used:   ss-- -sss
 1469| 001500 cmpwi      2C030000   1     C4        cr0=gr3,0                                                                                                        | 000000                             PDEF       async_gen_asend
 1469| 001504 bc         40820028   1     BF        CL.2281,cr0,0x4/eq,taken=50%(0,0)                                                                            1290|                                    PROC       o,arg,gr3,gr4
    0|                                CL.2283:                                                                                                                      0| 001540 mfspr      7C0802A6   1     LFLR       gr0=lr
 1470| 001508 lwz        80620028   1     L4A       gr3=.PyExc_GeneratorExit(gr2,0)                                                                                 0| 001544 stwu       9421FFC0   1     ST4U       gr1,#stack(gr1,-64)=gr1
 1470| 00150C lwz        80630000   2     L4A       gr3=<s141:d0:l4>(gr3,0)                                                                                         0| 001548 stw        90010048   1     ST4A       #stack(gr1,72)=gr0
 1470| 001510 bl         4BFFEAF1   0     CALL      gr3=PyErr_ExceptionMatches,1,(*)_object",gr3,#ProcAlias",PyErr_ExceptionMatches",fcr",gr1,cr[01567]",gr0",g     0| 00154C stw        93E1003C   1     ST4A       #stack(gr1,60)=gr31
 1470| 001514 ori        60000000   1                                                                                                                               0| 001550 ori        607F0000   1     LR         gr31=gr3
 1470| 001518 cmpwi      2C030000   1     C4        cr0=gr3,0                                                                                                       0| 001554 stw        93C10038   1     ST4A       #stack(gr1,56)=gr30
 1470| 00151C bc         4182FF70   1     BT        CL.1655,cr0,0x4/eq,taken=30%(30,70)                                                                             0| 001558 ori        609E0000   1     LR         gr30=gr4
 1472| 001520 addi       38000001   2     LI        gr0=1                                                                                                        1248| 00155C lwz        80030034   1     L4A        gr0=(*)aggr#4.ag_hooks_inited(gr3,52)
 1472| 001524 stw        901E0038   1     ST4A      (*)aggr#4.ag_closed(gr30,56)=gr0                                                                             1248| 001560 cmpwi      2C000000   2     C4         cr0=gr0,0
    0| 001528 b          4BFFFF64   0     B         CL.1655,-1                                                                                                   1248| 001564 bc         40820050   1     BF         CL.2297,cr0,0x4/eq,taken=30%(30,70)
    0|                                CL.2281:                                                                                                                      0| 001568 bl         480052F9   1     CALL       gr3=async_gen_init_hooks at AF128_21,1,gr3,async_gen_init_hooks",(*)aggr#4",#ProcAlias",fcr",async_gen_init_h
 1472| 00152C addi       38000001   1     LI        gr0=1                                                                                                        1292| 00156C cmpwi      2C030000   1     C4         cr0=gr3,0
 1472| 001530 stw        901E0038   1     ST4A      (*)aggr#4.ag_closed(gr30,56)=gr0                                                                             1293| 001570 addi       38600000   1     LI         gr3=0
    0| 001534 b          4BFFFF58   0     B         CL.1655,-1                                                                                                   1292| 001574 bc         4182001C   0     BT         CL.1892,cr0,0x4/eq,taken=40%(40,60)
    0|                                CL.1659:                                                                                                                      0| 001578 lwz        80010048   2     L4A        gr0=#stack(gr1,72)
 1466| 001538 lwz        807F0000   1     L4A       gr3=<s137:d0:l4>(gr31,0)                                                                                        0| 00157C lwz        83E1003C   1     L4A        gr31=#stack(gr1,60)
 1466| 00153C bl         4BFFEAC5   0     CALL      PyErr_SetNone,1,(*)_object",gr3,#ProcAlias",PyErr_SetNone",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",m     0| 001580 lwz        83C10038   1     L4A        gr30=#stack(gr1,56)
 1466| 001540 ori        60000000   1                                                                                                                            1296| 001584 addi       38210040   1     AI         gr1=gr1,64
 1469| 001544 lwz        807F0000   1     L4A       gr3=<s137:d0:l4>(gr31,0)                                                                                        0| 001588 mtspr      7C0803A6   1     LLR        lr=gr0
 1469| 001548 bl         4BFFEAB9   0     CALL      gr3=PyErr_ExceptionMatches,1,(*)_object",gr3,#ProcAlias",PyErr_ExceptionMatches",fcr",gr1,cr[01567]",gr0",g  1296| 00158C bclr       4E800020   3     BA         lr
 1469| 00154C ori        60000000   1                                                                                                                               0|                                CL.1892:
 1469| 001550 cmpwi      2C030000   1     C4        cr0=gr3,0                                                                                                    1295| 001590 ori        63E30000   1     LR         gr3=gr31
 1469| 001554 bc         4182FFB4   1     BT        CL.2283,cr0,0x4/eq,taken=40%(40,60)                                                                          1295| 001594 ori        63C40000   1     LR         gr4=gr30
 1472| 001558 addi       38000001   2     LI        gr0=1                                                                                                        1295| 001598 bl         48003369   0     CALL       gr3=IPRA.$async_gen_asend_new,2,(*)aggr#4",gr3,(*)_object",gr4,#ProcAlias",IPRA.$async_gen_asend_new",fcr"
 1472| 00155C stw        901E0038   1     ST4A      (*)aggr#4.ag_closed(gr30,56)=gr0                                                                                0| 00159C lwz        83C10038   1     L4A        gr30=#stack(gr1,56)
    0| 001560 b          4BFFFF2C   0     B         CL.1655,-1                                                                                                      0| 0015A0 lwz        80010048   1     L4A        gr0=#stack(gr1,72)
     |               Tag Table                                                                                                                                      0| 0015A4 lwz        83E1003C   1     L4A        gr31=#stack(gr1,60)
     | 001564        00000000 00002041 80020200 00000000 00000144 001C4950                                                                                       1296| 0015A8 addi       38210040   1     AI         gr1=gr1,64
     | 00157C        52412E24 6173796E 635F6765 6E5F756E 77726170 5F76616C                                                                                          0| 0015AC mtspr      7C0803A6   1     LLR        lr=gr0
     | 001594        7565                                                                                                                                        1296| 0015B0 bclr       4E800020   3     BA         lr
     |               Instruction count           81                                                                                                                 0|                                CL.2297:
     |               Straight-line exec time     82                                                                                                                 0| 0015B4 lwz        83E1003C   1     L4A        gr31=#stack(gr1,60)
 GPR's set/used:   su-s ssss ssss s---  ---- ---- ---- ----                                                                                                         0| 0015B8 lwz        83C10038   1     L4A        gr30=#stack(gr1,56)
 FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----                                                                                                      1295| 0015BC stw        93C1FFF8   2     ST4A       #stack_prune(gr1,-8)=gr30







Wed Apr 15 07:30:04 CDT 2020  Page 84


 CCR's set/used:   ss-- -sss                                                                                                                                     1295| 0015C0 stw        93E1FFFC   1     ST4A       #stack_prune(gr1,-4)=gr31
     | 000000                             PDEF     _PyAsyncGen_Fini                                                                                              1295| 0015C4 bl         4800333D   0     CALL       gr3=IPRA.$async_gen_asend_new,2,(*)aggr#4",gr3,(*)_object",gr4,#ProcAlias",IPRA.$async_gen_asend_new",fcr"
 1455|                                    PROC                                                                                                                   1295| 0015C8 lwz        83E1FFFC   1     L4A        gr31=#stack_prune(gr1,-4)
 1458| 0015A0 b          48003A80   0     CALLF     gr3=PyAsyncGen_ClearFreeLists,0,#ProcAlias",PyAsyncGen_ClearFreeLists",fcr",gr1,cr[01567]",gr0",gr4"-gr12",  1295| 0015CC lwz        83C1FFF8   1     L4A        gr30=#stack_prune(gr1,-8)
 1458|                                CL.711:                                                                                                                       0| 0015D0 lwz        80010048   1     L4A        gr0=#stack(gr1,72)
     |               Tag Table                                                                                                                                   1296| 0015D4 addi       38210040   1     AI         gr1=gr1,64
     | 0015A4        00000000 00002040 00000000 00000004 00105F50 79417379                                                                                          0| 0015D8 mtspr      7C0803A6   1     LLR        lr=gr0
     | 0015BC        6E634765 6E5F4669 6E69                                                                                                                      1296| 0015DC bclr       4E800020   3     BA         lr
     |               Instruction count            1                                                                                                                  |               Tag Table
     |               Straight-line exec time      0                                                                                                                  | 0015E0        00000000 00002041 80020200 00000000 000000A0 000F6173
 GPR's set/used:   ss-s ssss ssss s---  ---- ---- ---- ----                                                                                                          | 0015F8        796E635F 67656E5F 6173656E 64
 FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----                                                                                                          |               Instruction count           40
 CCR's set/used:   ss-- -sss                                                                                                                                         |               Straight-line exec time     46
     | 000000                             PDEF     async_gen_athrow                                                                                              GPR's set/used:   ss-s ssss ssss s---  ---- ---- ---- ---s
 1309|                                    PROC      o,args,gr3,gr4                                                                                               FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----
    0| 0015E0 mfspr      7C0802A6   1     LFLR      gr0=lr                                                                                                       CCR's set/used:   ss-- -sss
    0| 0015E4 ori        60650000   1     LR        gr5=gr3                                                                                                          | 000000                             PDEF       async_gen_anext
    0| 0015E8 stw        90010008   1     ST4A      #stack(gr1,8)=gr0                                                                                            1280|                                    PROC       o,gr3
    0| 0015EC ori        60800000   1     LR        gr0=gr4                                                                                                         0| 001620 mfspr      7C0802A6   1     LFLR       gr0=lr
 1248| 0015F0 lwz        80830034   1     L4A       gr4=(*)aggr#4.ag_hooks_inited(gr3,52)                                                                           0| 001624 stwu       9421FFC0   1     ST4U       gr1,#stack(gr1,-64)=gr1
    0| 0015F4 stwu       9421FFB0   1     ST4U      gr1,#stack(gr1,-80)=gr1                                                                                         0| 001628 stw        90010048   1     ST4A       #stack(gr1,72)=gr0
 1248| 0015F8 cmpwi      2C040000   1     C4        cr0=gr4,0                                                                                                       0| 00162C stw        93E1003C   1     ST4A       #stack(gr1,60)=gr31
 1248| 0015FC bc         40820050   1     BF        CL.2259,cr0,0x4/eq,taken=30%(30,70)                                                                             0| 001630 ori        607F0000   1     LR         gr31=gr3
    0| 001600 stw        90A10048   2     ST4A      #parameter_store0(gr1,72)=gr5                                                                                1248| 001634 lwz        80030034   1     L4A        gr0=(*)aggr#4.ag_hooks_inited(gr3,52)
    0| 001604 stw        9001004C   1     ST4A      #parameter_store1(gr1,76)=gr0                                                                                1248| 001638 cmpwi      2C000000   2     C4         cr0=gr0,0
    0| 001608 bl         48004E39   0     CALL      gr3=async_gen_init_hooks at AF123_21,1,gr3,async_gen_init_hooks",(*)aggr#4",#ProcAlias",fcr",async_gen_init_ho  1248| 00163C bc         40820050   1     BF         CL.2296,cr0,0x4/eq,taken=30%(30,70)
 1311| 00160C cmpwi      2C030000   1     C4        cr0=gr3,0                                                                                                       0| 001640 bl         48005221   1     CALL       gr3=async_gen_init_hooks at AF128_21,1,gr3,async_gen_init_hooks",(*)aggr#4",#ProcAlias",fcr",async_gen_init_h
 1312| 001610 addi       38600000   1     LI        gr3=0                                                                                                        1282| 001644 cmpwi      2C030000   1     C4         cr0=gr3,0
    0| 001614 lwz        80A10048   1     L4A       gr5=#parameter_store0(gr1,72)                                                                                1283| 001648 addi       38600000   1     LI         gr3=0
    0| 001618 lwz        8001004C   1     L4A       gr0=#parameter_store1(gr1,76)                                                                                1282| 00164C bc         41820018   0     BT         CL.1895,cr0,0x4/eq,taken=40%(40,60)
 1311| 00161C bc         41820014   0     BT        CL.1785,cr0,0x4/eq,taken=40%(40,60)                                                                             0| 001650 lwz        80010048   2     L4A        gr0=#stack(gr1,72)
    0| 001620 lwz        80010058   2     L4A       gr0=#stack(gr1,88)                                                                                              0| 001654 lwz        83E1003C   1     L4A        gr31=#stack(gr1,60)
 1315| 001624 addi       38210050   1     AI        gr1=gr1,80                                                                                                   1286| 001658 addi       38210040   1     AI         gr1=gr1,64
    0| 001628 mtspr      7C0803A6   1     LLR       lr=gr0                                                                                                          0| 00165C mtspr      7C0803A6   1     LLR        lr=gr0
 1315| 00162C bclr       4E800020   3     BA        lr                                                                                                           1286| 001660 bclr       4E800020   3     BA         lr
    0|                                CL.1785:                                                                                                                      0|                                CL.1895:
 1314| 001630 ori        60A30000   1     LR        gr3=gr5                                                                                                      1285| 001664 ori        63E30000   1     LR         gr3=gr31
 1314| 001634 ori        60040000   1     LR        gr4=gr0                                                                                                      1285| 001668 addi       38800000   1     LI         gr4=0
 1314| 001638 bl         48003289   0     CALL      gr3=async_gen_athrow_new,2,(*)aggr#4",gr3,(*)_object",gr4,#ProcAlias",async_gen_athrow_new",fcr",gr1,cr[015  1285| 00166C stw        93C1FFF8   1     ST4A       #stack_prune(gr1,-8)=gr30
    0| 00163C lwz        80010058   1     L4A       gr0=#stack(gr1,88)                                                                                           1285| 001670 bl         48003291   0     CALL       gr3=IPRA.$async_gen_asend_new,2,(*)aggr#4",gr3,(*)_object",gr4,#ProcAlias",IPRA.$async_gen_asend_new",fcr"
 1315| 001640 addi       38210050   1     AI        gr1=gr1,80                                                                                                   1285| 001674 lwz        83C1FFF8   1     L4A        gr30=#stack_prune(gr1,-8)
    0| 001644 mtspr      7C0803A6   1     LLR       lr=gr0                                                                                                          0| 001678 lwz        83E1003C   1     L4A        gr31=#stack(gr1,60)
 1315| 001648 bclr       4E800020   3     BA        lr                                                                                                              0| 00167C lwz        80010048   1     L4A        gr0=#stack(gr1,72)
    0|                                CL.2259:                                                                                                                   1286| 001680 addi       38210040   1     AI         gr1=gr1,64
 1314| 00164C ori        60040000   1     LR        gr4=gr0                                                                                                         0| 001684 mtspr      7C0803A6   1     LLR        lr=gr0
 1314| 001650 bl         48003271   0     CALL      gr3=async_gen_athrow_new,2,(*)aggr#4",gr3,(*)_object",gr4,#ProcAlias",async_gen_athrow_new",fcr",gr1,cr[015  1286| 001688 bclr       4E800020   3     BA         lr
    0| 001654 lwz        80010058   1     L4A       gr0=#stack(gr1,88)                                                                                              0|                                CL.2296:
 1315| 001658 addi       38210050   1     AI        gr1=gr1,80                                                                                                   1285| 00168C addi       38800000   1     LI         gr4=0
    0| 00165C mtspr      7C0803A6   1     LLR       lr=gr0                                                                                                          0| 001690 lwz        83E1003C   1     L4A        gr31=#stack(gr1,60)
 1315| 001660 bclr       4E800020   3     BA        lr                                                                                                           1285| 001694 stw        93C1FFF8   1     ST4A       #stack_prune(gr1,-8)=gr30
     |               Tag Table                                                                                                                                   1285| 001698 stw        93E1FFFC   1     ST4A       #stack_prune(gr1,-4)=gr31
     | 001664        00000000 00002041 80000200 00000000 00000084 00106173                                                                                       1285| 00169C bl         48003265   0     CALL       gr3=IPRA.$async_gen_asend_new,2,(*)aggr#4",gr3,(*)_object",gr4,#ProcAlias",IPRA.$async_gen_asend_new",fcr"
     | 00167C        796E635F 67656E5F 61746872 6F77                                                                                                             1285| 0016A0 lwz        83E1FFFC   1     L4A        gr31=#stack_prune(gr1,-4)
     |               Instruction count           33                                                                                                              1285| 0016A4 lwz        83C1FFF8   1     L4A        gr30=#stack_prune(gr1,-8)
     |               Straight-line exec time     37                                                                                                                 0| 0016A8 lwz        80010048   1     L4A        gr0=#stack(gr1,72)
 GPR's set/used:   ss-s ssss ssss s---  ---- ---- ---- ----                                                                                                      1286| 0016AC addi       38210040   1     AI         gr1=gr1,64







Wed Apr 15 07:30:04 CDT 2020  Page 85


 FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----                                                                                                         0| 0016B0 mtspr      7C0803A6   1     LLR        lr=gr0
 CCR's set/used:   ss-- -sss                                                                                                                                     1286| 0016B4 bclr       4E800020   3     BA         lr
     | 000000                             PDEF     async_gen_aclose                                                                                                  |               Tag Table
 1300|                                    PROC      o,arg,gr3,gr4                                                                                                    | 0016B8        00000000 00002041 80010100 00000000 00000098 000F6173
    0| 0016A0 mfspr      7C0802A6   1     LFLR      gr0=lr                                                                                                           | 0016D0        796E635F 67656E5F 616E6578 74
    0| 0016A4 ori        60640000   1     LR        gr4=gr3                                                                                                          |               Instruction count           38
    0| 0016A8 stw        90010008   1     ST4A      #stack(gr1,8)=gr0                                                                                                |               Straight-line exec time     43
 1248| 0016AC lwz        80030034   1     L4A       gr0=(*)aggr#4.ag_hooks_inited(gr3,52)                                                                        GPR's set/used:   su-s ssss ssss s---  ---- ---- ---- ----
    0| 0016B0 stwu       9421FFB0   1     ST4U      gr1,#stack(gr1,-80)=gr1                                                                                      FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----
 1248| 0016B4 cmpwi      2C000000   1     C4        cr0=gr0,0                                                                                                    CCR's set/used:   ss-- -sss
 1248| 0016B8 bc         40820048   1     BF        CL.2258,cr0,0x4/eq,taken=30%(30,70)                                                                              | 000000                             PDEF       async_gen_init_hooks
    0| 0016BC stw        90810048   2     ST4A      #parameter_store0(gr1,72)=gr4                                                                                1242|                                    PROC       o_128_21,gr3
    0| 0016C0 bl         48004D81   0     CALL      gr3=async_gen_init_hooks at AF123_21,1,gr3,async_gen_init_hooks",(*)aggr#4",#ProcAlias",fcr",async_gen_init_ho  1248| 0016E0 lwz        80030034   1     L4A        gr0=(*)aggr#4.ag_hooks_inited(gr3,52)
 1302| 0016C4 cmpwi      2C030000   1     C4        cr0=gr3,0                                                                                                    1248| 0016E4 cmpwi      2C000000   2     C4         cr0=gr0,0
 1303| 0016C8 addi       38600000   1     LI        gr3=0                                                                                                        1248| 0016E8 bc         4182000C   1     BT         CL.1549,cr0,0x4/eq,taken=40%(40,60)
    0| 0016CC lwz        80810048   1     L4A       gr4=#parameter_store0(gr1,72)                                                                                1249| 0016EC addi       38600000   1     LI         gr3=0
 1302| 0016D0 bc         41820014   0     BT        CL.1789,cr0,0x4/eq,taken=40%(40,60)                                                                          1249| 0016F0 bclr       4E800020   0     BA         lr
    0| 0016D4 lwz        80010058   2     L4A       gr0=#stack(gr1,88)                                                                                              0|                                CL.1549:
 1306| 0016D8 addi       38210050   1     AI        gr1=gr1,80                                                                                                   1276| 0016F4 b          4800516C   0     CALLF      gr3=async_gen_init_hooks at AF128_21,1,gr3,async_gen_init_hooks at AF128_21",gr1,cr[01567]",gr0",gr4"-gr12",fp0"
    0| 0016DC mtspr      7C0803A6   1     LLR       lr=gr0                                                                                                           |               Tag Table
 1306| 0016E0 bclr       4E800020   3     BA        lr                                                                                                               | 0016F8        00000000 00002040 00000100 00000000 00000018 00146173
    0|                                CL.1789:                                                                                                                       | 001710        796E635F 67656E5F 696E6974 5F686F6F 6B73
 1305| 0016E4 ori        60830000   1     LR        gr3=gr4                                                                                                          |               Instruction count            6
 1305| 0016E8 addi       38800000   1     LI        gr4=0                                                                                                            |               Straight-line exec time      5
 1305| 0016EC bl         480031D5   0     CALL      gr3=async_gen_athrow_new,2,(*)aggr#4",gr3,(*)_object",gr4,#ProcAlias",async_gen_athrow_new",fcr",gr1,cr[015  GPR's set/used:   ssus ssss ssss s---  ---- ---- ---- ----
    0| 0016F0 lwz        80010058   1     L4A       gr0=#stack(gr1,88)                                                                                           FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----
 1306| 0016F4 addi       38210050   1     AI        gr1=gr1,80                                                                                                   CCR's set/used:   ss-- -sss
    0| 0016F8 mtspr      7C0803A6   1     LLR       lr=gr0                                                                                                           | 000000                             PDEF       async_gen_repr
 1306| 0016FC bclr       4E800020   3     BA        lr                                                                                                           1234|                                    PROC       o,gr3
    0|                                CL.2258:                                                                                                                      0| 001740 mfspr      7C0802A6   1     LFLR       gr0=lr
 1305| 001700 addi       38800000   1     LI        gr4=0                                                                                                        1236| 001744 lwz        8083001C   1     L4A        gr4=(*)aggr#4.ag_qualname(gr3,28)
 1305| 001704 bl         480031BD   0     CALL      gr3=async_gen_athrow_new,2,(*)aggr#4",gr3,(*)_object",gr4,#ProcAlias",async_gen_athrow_new",fcr",gr1,cr[015     0| 001748 stwu       9421FFC0   1     ST4U       gr1,#stack(gr1,-64)=gr1
    0| 001708 lwz        80010058   1     L4A       gr0=#stack(gr1,88)                                                                                           1236| 00174C ori        60650000   1     LR         gr5=gr3
 1306| 00170C addi       38210050   1     AI        gr1=gr1,80                                                                                                   1236| 001750 lwz        80620018   1     L4A        gr3=.+CONSTANT_AREA(gr2,0)
    0| 001710 mtspr      7C0803A6   1     LLR       lr=gr0                                                                                                       1236| 001754 addi       38631634   2     AI         gr3=gr3,5684
 1306| 001714 bclr       4E800020   3     BA        lr                                                                                                              0| 001758 stw        90010048   1     ST4A       #stack(gr1,72)=gr0
     |               Tag Table                                                                                                                                   1236| 00175C bl         4BFFE8A5   0     CALL       gr3=PyUnicode_FromFormat,3,gr3,(*)_object",gr4,(*)aggr#4",gr5,#ProcAlias",PyUnicode_FromFormat",fcr",gr1,c
     | 001718        00000000 00002041 80000200 00000000 00000078 00106173                                                                                       1236| 001760 ori        60000000   1
     | 001730        796E635F 67656E5F 61636C6F 7365                                                                                                                0| 001764 lwz        80010048   1     L4A        gr0=#stack(gr1,72)
     |               Instruction count           30                                                                                                              1238| 001768 addi       38210040   1     AI         gr1=gr1,64
     |               Straight-line exec time     34                                                                                                                 0| 00176C mtspr      7C0803A6   1     LLR        lr=gr0
 GPR's set/used:   ss-s ssss ssss s---  ---- ---- ---- ----                                                                                                      1238| 001770 bclr       4E800020   3     BA         lr
 FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----                                                                                                          |               Tag Table
 CCR's set/used:   ss-- -sss                                                                                                                                         | 001774        00000000 00002041 80000100 00000000 00000034 000E6173
     | 000000                             PDEF     async_gen_asend                                                                                                   | 00178C        796E635F 67656E5F 72657072
 1290|                                    PROC      o,arg,gr3,gr4                                                                                                    |               Instruction count           13
    0| 001740 mfspr      7C0802A6   1     LFLR      gr0=lr                                                                                                           |               Straight-line exec time     15
    0| 001744 ori        60650000   1     LR        gr5=gr3                                                                                                      GPR's set/used:   ssus ssss ssss s---  ---- ---- ---- -sss
    0| 001748 stw        90010008   1     ST4A      #stack(gr1,8)=gr0                                                                                            FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----
    0| 00174C ori        60800000   1     LR        gr0=gr4                                                                                                      CCR's set/used:   ss-- -sss
 1248| 001750 lwz        80830034   1     L4A       gr4=(*)aggr#4.ag_hooks_inited(gr3,52)                                                                            | 000000                             PDEF       async_gen_traverse
    0| 001754 stwu       9421FFB0   1     ST4U      gr1,#stack(gr1,-80)=gr1                                                                                      1226|                                    PROC       gen,visit,arg,gr3-gr5
 1248| 001758 cmpwi      2C040000   1     C4        cr0=gr4,0                                                                                                       0| 0017A0 mfspr      7C0802A6   1     LFLR       gr0=lr
 1248| 00175C bc         40820050   1     BF        CL.2256,cr0,0x4/eq,taken=30%(30,70)                                                                             0| 0017A4 stwu       9421FFB0   1     ST4U       gr1,#stack(gr1,-80)=gr1
    0| 001760 stw        90A10048   2     ST4A      #parameter_store0(gr1,72)=gr5                                                                                   0| 0017A8 stw        90010058   1     ST4A       #stack(gr1,88)=gr0
    0| 001764 stw        9001004C   1     ST4A      #parameter_store1(gr1,76)=gr0                                                                                   0| 0017AC stw        93E1004C   1     ST4A       #stack(gr1,76)=gr31







Wed Apr 15 07:30:04 CDT 2020  Page 86


    0| 001768 bl         48004CD9   0     CALL      gr3=async_gen_init_hooks at AF123_21,1,gr3,async_gen_init_hooks",(*)aggr#4",#ProcAlias",fcr",async_gen_init_ho     0| 0017B0 ori        607F0000   1     LR         gr31=gr3
 1292| 00176C cmpwi      2C030000   1     C4        cr0=gr3,0                                                                                                       0| 0017B4 stw        93C10048   1     ST4A       #stack(gr1,72)=gr30
 1293| 001770 addi       38600000   1     LI        gr3=0                                                                                                           0| 0017B8 stw        93A10044   1     ST4A       #stack(gr1,68)=gr29
    0| 001774 lwz        80A10048   1     L4A       gr5=#parameter_store0(gr1,72)                                                                                   0| 0017BC ori        609E0000   1     LR         gr30=gr4
    0| 001778 lwz        8001004C   1     L4A       gr0=#parameter_store1(gr1,76)                                                                                   0| 0017C0 ori        60BD0000   1     LR         gr29=gr5
 1292| 00177C bc         41820014   0     BT        CL.1802,cr0,0x4/eq,taken=40%(40,60)                                                                          1228| 0017C4 stw        90410014   1     ST4A       #cur_toc(gr1,20)=gr2
    0| 001780 lwz        80010058   2     L4A       gr0=#stack(gr1,88)                                                                                           1228| 0017C8 ori        60A40000   1     LR         gr4=gr5
 1296| 001784 addi       38210050   1     AI        gr1=gr1,80                                                                                                   1228| 0017CC lwz        80630030   1     L4A        gr3=(*)aggr#4.ag_finalizer(gr3,48)
    0| 001788 mtspr      7C0803A6   1     LLR       lr=gr0                                                                                                       1228| 0017D0 cmpwi      2C030000   2     C4         cr0=gr3,0
 1296| 00178C bclr       4E800020   3     BA        lr                                                                                                           1228| 0017D4 bc         41820040   1     BT         CL.150,cr0,0x4/eq,taken=30%(30,70)
    0|                                CL.1802:                                                                                                                   1228| 0017D8 lwz        801E0000   1     L4A        gr0=#fnc_adr(gr30,0)
 1295| 001790 ori        60A30000   1     LR        gr3=gr5                                                                                                      1228| 0017DC lwz        817E0008   1     L4A        gr11=#new_env(gr30,8)
 1295| 001794 ori        60040000   1     LR        gr4=gr0                                                                                                      1228| 0017E0 mtspr      7C0903A6   1     LCTR       ctr=gr0
 1295| 001798 bl         48003329   0     CALL      gr3=async_gen_asend_new,2,(*)aggr#4",gr3,(*)_object",gr4,#ProcAlias",async_gen_asend_new",fcr",gr1,cr[01567  1228| 0017E4 lwz        805E0004   1     CALL       gr3=gr30,2,(*)_object",gr3,(*)void",gr4,#ProcAlias",fcr",(*)int()",gr1,cr[01567]",gr0",gr4"-gr12",fp0"-fp1
    0| 00179C lwz        80010058   1     L4A       gr0=#stack(gr1,88)                                                                                           1228| 0017E8 bcctrl     4E800421   0
 1296| 0017A0 addi       38210050   1     AI        gr1=gr1,80                                                                                                   1228| 0017EC lwz        80410014   1
    0| 0017A4 mtspr      7C0803A6   1     LLR       lr=gr0                                                                                                       1228| 0017F0 cmpwi      2C030000   1     C4         cr0=gr3,0
 1296| 0017A8 bclr       4E800020   3     BA        lr                                                                                                           1228| 0017F4 bc         41820020   1     BT         CL.150,cr0,0x4/eq,taken=40%(40,60)
    0|                                CL.2256:                                                                                                                      0| 0017F8 lwz        80010058   2     L4A        gr0=#stack(gr1,88)
 1295| 0017AC ori        60040000   1     LR        gr4=gr0                                                                                                         0| 0017FC lwz        83E1004C   1     L4A        gr31=#stack(gr1,76)
 1295| 0017B0 bl         48003311   0     CALL      gr3=async_gen_asend_new,2,(*)aggr#4",gr3,(*)_object",gr4,#ProcAlias",async_gen_asend_new",fcr",gr1,cr[01567     0| 001800 lwz        83C10048   1     L4A        gr30=#stack(gr1,72)
    0| 0017B4 lwz        80010058   1     L4A       gr0=#stack(gr1,88)                                                                                              0| 001804 lwz        83A10044   1     L4A        gr29=#stack(gr1,68)
 1296| 0017B8 addi       38210050   1     AI        gr1=gr1,80                                                                                                   1230| 001808 addi       38210050   1     AI         gr1=gr1,80
    0| 0017BC mtspr      7C0803A6   1     LLR       lr=gr0                                                                                                          0| 00180C mtspr      7C0803A6   1     LLR        lr=gr0
 1296| 0017C0 bclr       4E800020   3     BA        lr                                                                                                           1230| 001810 bclr       4E800020   3     BA         lr
     |               Tag Table                                                                                                                                   1228|                                CL.150:
     | 0017C4        00000000 00002041 80000200 00000000 00000084 000F6173                                                                                       1229| 001814 ori        63E30000   1     LR         gr3=gr31
     | 0017DC        796E635F 67656E5F 6173656E 64                                                                                                               1229| 001818 ori        63C40000   1     LR         gr4=gr30
     |               Instruction count           33                                                                                                              1229| 00181C ori        63A50000   1     LR         gr5=gr29
     |               Straight-line exec time     37                                                                                                              1229| 001820 bl         48002CA1   0     CALL       gr3=gen_traverse,3,(*)aggr#3",gr3,(*)int()",gr4,(*)void",gr5,#ProcAlias",gen_traverse",fcr",gr1,cr[01567]"
 GPR's set/used:   ss-s ssss ssss s---  ---- ---- ---- ----                                                                                                         0| 001824 lwz        83A10044   1     L4A        gr29=#stack(gr1,68)
 FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----                                                                                                         0| 001828 lwz        80010058   1     L4A        gr0=#stack(gr1,88)
 CCR's set/used:   ss-- -sss                                                                                                                                        0| 00182C lwz        83C10048   1     L4A        gr30=#stack(gr1,72)
     | 000000                             PDEF     async_gen_anext                                                                                                  0| 001830 lwz        83E1004C   1     L4A        gr31=#stack(gr1,76)
 1280|                                    PROC      o,gr3                                                                                                        1230| 001834 addi       38210050   1     AI         gr1=gr1,80
    0| 001800 mfspr      7C0802A6   1     LFLR      gr0=lr                                                                                                          0| 001838 mtspr      7C0803A6   1     LLR        lr=gr0
    0| 001804 ori        60640000   1     LR        gr4=gr3                                                                                                      1230| 00183C bclr       4E800020   3     BA         lr
    0| 001808 stw        90010008   1     ST4A      #stack(gr1,8)=gr0                                                                                                |               Tag Table
 1248| 00180C lwz        80030034   1     L4A       gr0=(*)aggr#4.ag_hooks_inited(gr3,52)                                                                            | 001840        00000000 00002041 80030300 00000000 000000A0 00126173
    0| 001810 stwu       9421FFB0   1     ST4U      gr1,#stack(gr1,-80)=gr1                                                                                          | 001858        796E635F 67656E5F 74726176 65727365
 1248| 001814 cmpwi      2C000000   1     C4        cr0=gr0,0                                                                                                        |               Instruction count           40
 1248| 001818 bc         40820048   1     BF        CL.2255,cr0,0x4/eq,taken=30%(30,70)                                                                              |               Straight-line exec time     44
    0| 00181C stw        90810048   2     ST4A      #parameter_store0(gr1,72)=gr4                                                                                GPR's set/used:   ssus ssss ssss s---  ---- ---- -sss ssss
    0| 001820 bl         48004C21   0     CALL      gr3=async_gen_init_hooks at AF123_21,1,gr3,async_gen_init_hooks",(*)aggr#4",#ProcAlias",fcr",async_gen_init_ho  FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----
 1282| 001824 cmpwi      2C030000   1     C4        cr0=gr3,0                                                                                                    CCR's set/used:   ss-- -sss
 1283| 001828 addi       38600000   1     LI        gr3=0                                                                                                            | 000000                             PDEF       compute_cr_origin
    0| 00182C lwz        80810048   1     L4A       gr4=#parameter_store0(gr1,72)                                                                                1104|                                    PROC       origin_depth,gr3
 1282| 001830 bc         41820014   0     BT        CL.1806,cr0,0x4/eq,taken=40%(40,60)                                                                             0| 001880 mfspr      7C0802A6   1     LFLR       gr0=lr
    0| 001834 lwz        80010058   2     L4A       gr0=#stack(gr1,88)                                                                                              0| 001884 stwu       9421FFA0   1     ST4U       gr1,#stack(gr1,-96)=gr1
 1286| 001838 addi       38210050   1     AI        gr1=gr1,80                                                                                                      0| 001888 stw        90010068   1     ST4A       #stack(gr1,104)=gr0
    0| 00183C mtspr      7C0803A6   1     LLR       lr=gr0                                                                                                          0| 00188C stw        93E1005C   1     ST4A       #stack(gr1,92)=gr31
 1286| 001840 bclr       4E800020   3     BA        lr                                                                                                              0| 001890 stw        93C10058   1     ST4A       #stack(gr1,88)=gr30
    0|                                CL.1806:                                                                                                                      0| 001894 stw        93A10054   1     ST4A       #stack(gr1,84)=gr29
 1285| 001844 ori        60830000   1     LR        gr3=gr4                                                                                                         0| 001898 ori        607E0000   1     LR         gr30=gr3
 1285| 001848 addi       38800000   1     LI        gr4=0                                                                                                           0| 00189C stw        93810050   1     ST4A       #stack(gr1,80)=gr28
 1285| 00184C bl         48003275   0     CALL      gr3=async_gen_asend_new,2,(*)aggr#4",gr3,(*)_object",gr4,#ProcAlias",async_gen_asend_new",fcr",gr1,cr[01567     0| 0018A0 stw        9361004C   1     ST4A       #stack(gr1,76)=gr27







Wed Apr 15 07:30:04 CDT 2020  Page 87


    0| 001850 lwz        80010058   1     L4A       gr0=#stack(gr1,88)                                                                                              0| 0018A4 stw        93410048   1     ST4A       #stack(gr1,72)=gr26
 1286| 001854 addi       38210050   1     AI        gr1=gr1,80                                                                                                      0| 0018A8 stw        93210044   1     ST4A       #stack(gr1,68)=gr25
    0| 001858 mtspr      7C0803A6   1     LLR       lr=gr0                                                                                                       1106| 0018AC bl         4BFFE755   0     CALL       gr3=PyEval_GetFrame,0,#ProcAlias",PyEval_GetFrame",fcr",gr1,cr[01567]",gr0",gr4"-gr12",fp0"-fp13",mq",lr",
 1286| 00185C bclr       4E800020   3     BA        lr                                                                                                           1106| 0018B0 ori        60000000   1
    0|                                CL.2255:                                                                                                                   1109| 0018B4 cmpwi      2C1E0000   1     C4         cr0=gr30,0
 1285| 001860 addi       38800000   1     LI        gr4=0                                                                                                        1109| 0018B8 cmpwi      2C830000   1     C4         cr1=gr3,0
 1285| 001864 bl         4800325D   0     CALL      gr3=async_gen_asend_new,2,(*)aggr#4",gr3,(*)_object",gr4,#ProcAlias",async_gen_asend_new",fcr",gr1,cr[01567  1108| 0018BC addi       3BE00000   1     LI         gr31=0
    0| 001868 lwz        80010058   1     L4A       gr0=#stack(gr1,88)                                                                                           1109| 0018C0 bc         41860074   0     BT         CL.157,cr1,0x4/eq,taken=50%(0,0)
 1286| 00186C addi       38210050   1     AI        gr1=gr1,80                                                                                                      0| 0018C4 rlwinm     57C0F87E   2     SRL4       gr0=gr30,1
    0| 001870 mtspr      7C0803A6   1     LLR       lr=gr0                                                                                                          0| 0018C8 rlwinm     57C407FE   1     RN4        gr4=gr30,0,0x1
 1286| 001874 bclr       4E800020   3     BA        lr                                                                                                           1109| 0018CC bc         40810068   0     BF         CL.157,cr0,0x2/gt,taken=40%(40,60)
     |               Tag Table                                                                                                                                      0| 0018D0 cmpwi      2C800000   2     C4         cr1=gr0,0
     | 001878        00000000 00002041 80000100 00000000 00000078 000F6173                                                                                          0| 0018D4 cmpwi      2C040000   1     C4         cr0=gr4,0
     | 001890        796E635F 67656E5F 616E6578 74                                                                                                                  0| 0018D8 mtspr      7C0903A6   1     LCTR       ctr=gr0
     |               Instruction count           30                                                                                                                 0| 0018DC bc         41820018   0     BT         CL.2136,cr0,0x4/eq,taken=50%(0,0)
     |               Straight-line exec time     34                                                                                                              1109| 0018E0 addi       3BE00001   2     LI         gr31=1
 GPR's set/used:   su-s ssss ssss s---  ---- ---- ---- ----                                                                                                      1110| 0018E4 lwz        8063000C   1     L4A        gr3=(*)_frame._frame.f_back(gr3,12)
 FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----                                                                                                      1109| 0018E8 cmpwi      2C030000   2     C4         cr0=gr3,0
 CCR's set/used:   ss-- -sss                                                                                                                                     1109| 0018EC bc         41820048   1     BT         CL.157,cr0,0x4/eq,taken=50%(0,0)
     | 000000                             PDEF     async_gen_init_hooks                                                                                             0| 0018F0 bc         41860044   1     BT         CL.157,cr1,0x4/eq,taken=20%(20,80)
 1242|                                    PROC      o_123_21,gr3                                                                                                    0|                                CL.2136:
 1248| 0018A0 lwz        80030034   1     L4A       gr0=(*)aggr#4.ag_hooks_inited(gr3,52)                                                                        1109| 0018F4 addi       3BFF0001   1     AI         gr31=gr31,1
 1248| 0018A4 cmpwi      2C000000   2     C4        cr0=gr0,0                                                                                                       0| 0018F8 bc         4240002C   0     BCF        ctr=CL.2142,taken=0%(0,100)
 1248| 0018A8 bc         4182000C   1     BT        CL.1520,cr0,0x4/eq,taken=40%(40,60)                                                                             0| 0018FC ori        60210000   2
 1249| 0018AC addi       38600000   1     LI        gr3=0                                                                                                        1109|                                CL.158:
 1249| 0018B0 bclr       4E800020   0     BA        lr                                                                                                           1110| 001900 lwz        8063000C   1     L4A        gr3=(*)_frame._frame.f_back(gr3,12)
    0|                                CL.1520:                                                                                                                      0| 001904 or.        7C601B79   2     LR_R       gr0,cr0=gr3
 1276| 0018B4 b          48004B8C   0     CALLF     gr3=async_gen_init_hooks at AF123_21,1,gr3,async_gen_init_hooks at AF123_21",gr1,cr[01567]",gr0",gr4"-gr12",fp0"-  1109| 001908 bc         4182002C   1     BT         CL.157,cr0,0x4/eq,taken=20%(20,80)
     |               Tag Table                                                                                                                                   1109| 00190C addi       3BFF0001   1     AI         gr31=gr31,1
     | 0018B8        00000000 00002040 00000100 00000000 00000018 00146173                                                                                       1110| 001910 lwz        8063000C   1     L4A        gr3=(*)_frame._frame.f_back(gr3,12)
     | 0018D0        796E635F 67656E5F 696E6974 5F686F6F 6B73                                                                                                       0| 001914 or.        7C601B79   2     LR_R       gr0,cr0=gr3
     |               Instruction count            6                                                                                                              1109| 001918 bc         4182001C   1     BT         CL.157,cr0,0x4/eq,taken=20%(20,80)
     |               Straight-line exec time      5                                                                                                              1109| 00191C addi       3BFF0001   1     AI         gr31=gr31,1
 GPR's set/used:   ssus ssss ssss s---  ---- ---- ---- ----                                                                                                         0| 001920 bc         4200FFE0   0     BCT        ctr=CL.158,taken=100%(100,0)
 FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----                                                                                                         0|                                CL.2142:
 CCR's set/used:   ss-- -sss                                                                                                                                     1110| 001924 lwz        8003000C   1     L4A        gr0=(*)_frame._frame.f_back(gr3,12)
     | 000000                             PDEF     async_gen_repr                                                                                                1109| 001928 cmpwi      2C000000   2     C4         cr0=gr0,0
 1234|                                    PROC      o,gr3                                                                                                        1109| 00192C bc         41820008   1     BT         CL.157,cr0,0x4/eq,taken=20%(20,80)
    0| 001900 mfspr      7C0802A6   1     LFLR      gr0=lr                                                                                                       1109| 001930 addi       3BFF0001   1     AI         gr31=gr31,1
 1236| 001904 lwz        8083001C   1     L4A       gr4=(*)aggr#4.ag_qualname(gr3,28)                                                                            1109|                                CL.157:
 1236| 001908 ori        60650000   1     LR        gr5=gr3                                                                                                      1114| 001934 ori        63E30000   1     LR         gr3=gr31
 1236| 00190C lwz        80620018   1     L4A       gr3=.+CONSTANT_AREA(gr2,0)                                                                                   1114| 001938 bl         4BFFE6C9   0     CALL       gr3=PyTuple_New,1,gr3,#ProcAlias",PyTuple_New",fcr",gr1,cr[01567]",gr0",gr4"-gr12",fp0"-fp13",mq",lr",fcr"
 1236| 001910 addi       38631634   2     AI        gr3=gr3,5684                                                                                                 1114| 00193C ori        60000000   1
    0| 001914 stw        90010008   1     ST4A      #stack(gr1,8)=gr0                                                                                            1115| 001940 or.        7C7E1B79   1     LR_R       gr30,cr0=gr3
    0| 001918 stwu       9421FFC0   1     ST4U      gr1,#stack(gr1,-64)=gr1                                                                                      1115| 001944 bc         418201E0   1     BT         CL.2178,cr0,0x4/eq,taken=30%(30,70)
 1236| 00191C bl         4BFFE6E5   0     CALL      gr3=PyUnicode_FromFormat,3,gr3,(*)_object",gr4,(*)aggr#4",gr5,#ProcAlias",PyUnicode_FromFormat",fcr",gr1,cr  1118| 001948 bl         4BFFE6B9   1     CALL       gr3=PyEval_GetFrame,0,#ProcAlias",PyEval_GetFrame",fcr",gr1,cr[01567]",gr0",gr4"-gr12",fp0"-fp13",mq",lr",
 1236| 001920 ori        60000000   1                                                                                                                            1118| 00194C ori        60000000   1
    0| 001924 lwz        80010048   1     L4A       gr0=#stack(gr1,72)                                                                                           1118| 001950 ori        607D0000   1     LR         gr29=gr3
 1238| 001928 addi       38210040   1     AI        gr1=gr1,64                                                                                                      0| 001954 lwz        83820018   1     L4A        gr28=.+CONSTANT_AREA(gr2,0)
    0| 00192C mtspr      7C0803A6   1     LLR       lr=gr0                                                                                                       1119| 001958 cmpwi      2C1F0000   1     C4         cr0=gr31,0
 1238| 001930 bclr       4E800020   3     BA        lr                                                                                                           1119| 00195C bc         408101A4   1     BF         CL.1981,cr0,0x2/gt,taken=30%(30,70)
     |               Tag Table                                                                                                                                   1119| 001960 addi       3B600000   2     LI         gr27=0
     | 001934        00000000 00002041 80000100 00000000 00000034 000E6173                                                                                       1129| 001964 addi       3B3E0008   1     AI         gr25=gr30,8
     | 00194C        796E635F 67656E5F 72657072                                                                                                                  1120| 001968 lwz        80830010   1     L4A        gr4=(*)_frame._frame.f_code(gr3,16)
     |               Instruction count           13                                                                                                              1120| 00196C lwz        83440040   2     L4A        gr26=(*)aggr#5.co_filename(gr4,64)
     |               Straight-line exec time     15                                                                                                              1120| 001970 ori        60000000   1







Wed Apr 15 07:30:04 CDT 2020  Page 88


 GPR's set/used:   ssus ssss ssss s---  ---- ---- ---- ----                                                                                                      1120| 001974 ori        60000000   1
 FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----                                                                                                      1120| 001978 ori        60000000   1
 CCR's set/used:   ss-- -sss                                                                                                                                     1120| 00197C ori        60210000   1
     | 000000                             PDEF     async_gen_traverse                                                                                               0|                                CL.2145:
 1226|                                    PROC      gen,visit,arg,gr3-gr5                                                                                        1120| 001980 bl         4BFFE681   0     CALL       gr3=PyFrame_GetLineNumber,1,(*)_frame",gr3,#ProcAlias",PyFrame_GetLineNumber",fcr",gr1,cr[01567]",gr0",gr4
    0| 001960 mfspr      7C0802A6   1     LFLR      gr0=lr                                                                                                       1120| 001984 ori        60000000   1
    0| 001964 ori        60670000   1     LR        gr7=gr3                                                                                                      1120| 001988 ori        60650000   1     LR         gr5=gr3
    0| 001968 ori        60860000   1     LR        gr6=gr4                                                                                                      1120| 00198C lwz        80DD0010   1     L4A        gr6=(*)_frame._frame.f_code(gr29,16)
 1228| 00196C lwz        80630030   1     L4A       gr3=(*)aggr#4.ag_finalizer(gr3,48)                                                                           1120| 001990 addi       387C16E8   1     AI         gr3=gr28,5864
 1228| 001970 ori        60A40000   1     LR        gr4=gr5                                                                                                      1120| 001994 ori        63440000   1     LR         gr4=gr26
    0| 001974 stw        90010008   1     ST4A      #stack(gr1,8)=gr0                                                                                            1120| 001998 lwz        80C60044   1     L4A        gr6=(*)aggr#5.co_name(gr6,68)
    0| 001978 ori        60A00000   1     LR        gr0=gr5                                                                                                      1120| 00199C bl         4BFFE665   0     CALL       gr3=Py_BuildValue,4,gr3,(*)_object",gr4,gr5,(*)_object",gr6,#ProcAlias",Py_BuildValue",fcr",gr1,cr[01567]"
 1228| 00197C cmpwi      2C030000   1     C4        cr0=gr3,0                                                                                                    1120| 0019A0 ori        60000000   1
    0| 001980 stwu       9421FFA0   1     ST4U      gr1,#stack(gr1,-96)=gr1                                                                                      1120| 0019A4 or.        7C7A1B79   1     LR_R       gr26,cr0=gr3
 1228| 001984 stw        90410014   1     ST4A      #cur_toc(gr1,20)=gr2                                                                                         1125| 0019A8 bc         418200AC   1     BT         CL.2172,cr0,0x4/eq,taken=20%(20,80)
 1228| 001988 bc         4182004C   0     BT        CL.150,cr0,0x4/eq,taken=30%(30,70)                                                                           1129| 0019AC lwz        807E0004   2     L4A        gr3=(*)_object._object.ob_type(gr30,4)
 1228| 00198C stw        90A10050   2     ST4A      #parameter_store2(gr1,80)=gr5                                                                                 617| 0019B0 bl         4BFFE651   0     CALL       gr3=PyType_GetFlags,1,(*)_typeobject",gr3,#ProcAlias",PyType_GetFlags",fcr",gr1,cr[01567]",gr0",gr4"-gr12"
 1228| 001990 stw        90E10048   1     ST4A      #parameter_store0(gr1,72)=gr7                                                                                 617| 0019B4 ori        60000000   1
 1228| 001994 stw        90C1004C   1     ST4A      #parameter_store1(gr1,76)=gr6                                                                                 617| 0019B8 andis.     74600400   1     RN4_R      gr0,cr0=gr3,0,0x4000000
 1228| 001998 lwz        80060000   1     L4A       gr0=#fnc_adr(gr6,0)                                                                                          1129| 0019BC bc         4182005C   1     BT         CL.2180,cr0,0x4/eq,taken=40%(40,60)
 1228| 00199C lwz        81660008   1     L4A       gr11=#new_env(gr6,8)                                                                                         1129| 0019C0 stw        93590004   2     ST4A       (*)aggr#B..[]0(gr25,4)=gr26
 1228| 0019A0 mtspr      7C0903A6   1     LCTR      ctr=gr0                                                                                                      1129| 0019C4 addi       3B390004   1     AI         gr25=gr25,4
 1228| 0019A4 lwz        80460004   1     CALL      gr3=gr6,2,(*)_object",gr3,(*)void",gr4,#ProcAlias",fcr",(*)int()",gr1,cr[01567]",gr0",gr4"-gr12",fp0"-fp13"  1119| 0019C8 addi       3B7B0001   1     AI         gr27=gr27,1
 1228| 0019A8 bcctrl     4E800421   0                                                                                                                            1130| 0019CC lwz        83BD000C   1     L4A        gr29=(*)_frame._frame.f_back(gr29,12)
 1228| 0019AC lwz        80410014   1                                                                                                                            1120| 0019D0 ori        63A30000   2     LR         gr3=gr29
 1228| 0019B0 cmpwi      2C030000   1     C4        cr0=gr3,0                                                                                                    1119| 0019D4 cmpw       7C1FD800   1     C4         cr0=gr31,gr27
 1228| 0019B4 lwz        80010050   1     L4A       gr0=#parameter_store2(gr1,80)                                                                                1119| 0019D8 bc         40810010   1     BF         CL.2173,cr0,0x2/gt,taken=20%(20,80)
 1228| 0019B8 lwz        80E10048   1     L4A       gr7=#parameter_store0(gr1,72)                                                                                1120| 0019DC lwz        809D0010   1     L4A        gr4=(*)_frame._frame.f_code(gr29,16)
 1228| 0019BC lwz        80C1004C   1     L4A       gr6=#parameter_store1(gr1,76)                                                                                1120| 0019E0 lwz        83440040   2     L4A        gr26=(*)aggr#5.co_filename(gr4,64)
 1228| 0019C0 bc         41820014   0     BT        CL.150,cr0,0x4/eq,taken=40%(40,60)                                                                              0| 0019E4 b          4BFFFF9C   0     B          CL.2145,-1
    0| 0019C4 lwz        80010068   2     L4A       gr0=#stack(gr1,104)                                                                                          1119|                                CL.2173:
 1230| 0019C8 addi       38210060   1     AI        gr1=gr1,96                                                                                                   1133| 0019E8 ori        63C30000   1     LR         gr3=gr30
    0| 0019CC mtspr      7C0803A6   1     LLR       lr=gr0                                                                                                          0| 0019EC lwz        83E1005C   1     L4A        gr31=#stack(gr1,92)
 1230| 0019D0 bclr       4E800020   3     BA        lr                                                                                                              0| 0019F0 lwz        83A10054   1     L4A        gr29=#stack(gr1,84)
 1228|                                CL.150:                                                                                                                       0| 0019F4 lwz        83810050   1     L4A        gr28=#stack(gr1,80)
 1229| 0019D4 ori        60E30000   1     LR        gr3=gr7                                                                                                         0| 0019F8 lwz        8361004C   1     L4A        gr27=#stack(gr1,76)
 1229| 0019D8 ori        60C40000   1     LR        gr4=gr6                                                                                                         0| 0019FC lwz        83410048   1     L4A        gr26=#stack(gr1,72)
 1229| 0019DC ori        60050000   1     LR        gr5=gr0                                                                                                         0| 001A00 lwz        83210044   1     L4A        gr25=#stack(gr1,68)
 1229| 0019E0 bl         48002C81   0     CALL      gr3=gen_traverse,3,(*)aggr#3",gr3,(*)int()",gr4,(*)void",gr5,#ProcAlias",gen_traverse",fcr",gr1,cr[01567]",     0| 001A04 lwz        83C10058   1     L4A        gr30=#stack(gr1,88)
    0| 0019E4 lwz        80010068   1     L4A       gr0=#stack(gr1,104)                                                                                             0| 001A08 lwz        80010068   1     L4A        gr0=#stack(gr1,104)
 1230| 0019E8 addi       38210060   1     AI        gr1=gr1,96                                                                                                   1134| 001A0C addi       38210060   1     AI         gr1=gr1,96
    0| 0019EC mtspr      7C0803A6   1     LLR       lr=gr0                                                                                                          0| 001A10 mtspr      7C0803A6   1     LLR        lr=gr0
 1230| 0019F0 bclr       4E800020   3     BA        lr                                                                                                           1134| 001A14 bclr       4E800020   3     BA         lr
     |               Tag Table                                                                                                                                      0|                                CL.2180:
     | 0019F4        00000000 00002041 80000300 00000000 00000094 00126173                                                                                       1129| 001A18 addi       387C16EC   1     AI         gr3=gr28,5868
     | 001A0C        796E635F 67656E5F 74726176 65727365                                                                                                         1129| 001A1C addi       389C1110   1     AI         gr4=gr28,4368
     |               Instruction count           37                                                                                                              1129| 001A20 addi       38A00469   1     LI         gr5=1129
     |               Straight-line exec time     39                                                                                                              1129| 001A24 bl         4BFFE5DD   0     CALL       __assert,3,gr3-gr5,#ProcAlias",__assert",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",lr",fcr",xer",
 GPR's set/used:   ssus ssss ssss s---  ---- ---- ssss ssss                                                                                                      1129| 001A28 ori        60000000   1
 FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----                                                                                                      1129| 001A2C stw        93590004   1     ST4A       (*)aggr#B..[]0(gr25,4)=gr26
 CCR's set/used:   ss-- -sss                                                                                                                                     1129| 001A30 addi       3B390004   1     AI         gr25=gr25,4
     | 000000                             PDEF     compute_cr_origin                                                                                             1119| 001A34 addi       3B7B0001   1     AI         gr27=gr27,1
 1104|                                    PROC      origin_depth,gr3                                                                                             1130| 001A38 lwz        83BD000C   1     L4A        gr29=(*)_frame._frame.f_back(gr29,12)
    0| 001A20 mfspr      7C0802A6   1     LFLR      gr0=lr                                                                                                       1120| 001A3C ori        63A30000   2     LR         gr3=gr29
    0| 001A24 stw        90010008   2     ST4A      #stack(gr1,8)=gr0                                                                                            1119| 001A40 cmpw       7C1FD800   1     C4         cr0=gr31,gr27
    0| 001A28 stw        93E1FFFC   1     ST4A      #stack(gr1,-4)=gr31                                                                                          1119| 001A44 bc         4081FFA4   1     BF         CL.2173,cr0,0x2/gt,taken=20%(20,80)







Wed Apr 15 07:30:04 CDT 2020  Page 89


    0| 001A2C stw        93C1FFF8   1     ST4A      #stack(gr1,-8)=gr30                                                                                          1120| 001A48 lwz        809D0010   1     L4A        gr4=(*)_frame._frame.f_code(gr29,16)
    0| 001A30 stw        93A1FFF4   1     ST4A      #stack(gr1,-12)=gr29                                                                                         1120| 001A4C lwz        83440040   2     L4A        gr26=(*)aggr#5.co_filename(gr4,64)
    0| 001A34 ori        607E0000   1     LR        gr30=gr3                                                                                                        0| 001A50 b          4BFFFF30   0     B          CL.2145,-1
    0| 001A38 stw        9381FFF0   1     ST4A      #stack(gr1,-16)=gr28                                                                                         1125|                                CL.2172:
    0| 001A3C stw        9361FFEC   1     ST4A      #stack(gr1,-20)=gr27                                                                                          408| 001A54 addi       387C1110   1     AI         gr3=gr28,4368
    0| 001A40 stw        9341FFE8   1     ST4A      #stack(gr1,-24)=gr26                                                                                          415| 001A58 lwz        80A20004   1     L4A        gr5=._Py_RefTotal(gr2,0)
    0| 001A44 stw        9321FFE4   1     ST4A      #stack(gr1,-28)=gr25                                                                                          417| 001A5C lwz        809E0000   1     L4A        gr4=(*)_object._object.ob_refcnt(gr30,0)
    0| 001A48 stw        9301FFE0   1     ST4A      #stack(gr1,-32)=gr24                                                                                            0| 001A60 lwz        83E1005C   1     L4A        gr31=#stack(gr1,92)
    0| 001A4C stwu       9421FFA0   1     ST4U      gr1,#stack(gr1,-96)=gr1                                                                                         0| 001A64 lwz        83A10054   1     L4A        gr29=#stack(gr1,84)
 1106| 001A50 bl         4BFFE5B1   0     CALL      gr3=PyEval_GetFrame,0,#ProcAlias",PyEval_GetFrame",fcr",gr1,cr[01567]",gr0",gr4"-gr12",fp0"-fp13",mq",lr",f     0| 001A68 lwz        8361004C   1     L4A        gr27=#stack(gr1,76)
 1106| 001A54 ori        60000000   1                                                                                                                               0| 001A6C lwz        83410048   1     L4A        gr26=#stack(gr1,72)
 1109| 001A58 cmpwi      2C830000   1     C4        cr1=gr3,0                                                                                                     417| 001A70 addi       3804FFFF   1     AI         gr0=gr4,-1
 1109| 001A5C cmpwi      2C1E0000   1     C4        cr0=gr30,0                                                                                                      0| 001A74 lwz        83210044   1     L4A        gr25=#stack(gr1,68)
 1109| 001A60 bc         418602B8   0     BT        CL.1918,cr1,0x4/eq,taken=50%(0,0)                                                                             417| 001A78 stw        901E0000   1     ST4A       (*)_object._object.ob_refcnt(gr30,0)=gr0
 1109| 001A64 addi       3BE00000   2     LI        gr31=0                                                                                                        415| 001A7C lwz        80850000   1     L4A        gr4=_Py_RefTotal(gr5,0)
    0| 001A68 rlwinm     57C0F87E   1     SRL4      gr0=gr30,1                                                                                                    415| 001A80 addi       3884FFFF   2     AI         gr4=gr4,-1
 1109| 001A6C bc         4081027C   0     BF        CL.1934,cr0,0x2/gt,taken=40%(40,60)                                                                           417| 001A84 cmpwi      2C000000   1     C4         cr0=gr0,0
    0| 001A70 andi.      73C40001   2     RN4_R     gr4,cr0=gr30,0,0x1                                                                                            415| 001A88 stw        90850000   1     ST4A       _Py_RefTotal(gr5,0)=gr4
    0| 001A74 cmpwi      2C800000   1     C4        cr1=gr0,0                                                                                                     417| 001A8C bc         4182004C   0     BT         CL.1096,cr0,0x4/eq,taken=40%(40,60)
    0| 001A78 mtspr      7C0903A6   1     LCTR      ctr=gr0                                                                                                         0| 001A90 lwz        83810050   1     L4A        gr28=#stack(gr1,80)
    0| 001A7C bc         41820018   0     BT        CL.2086,cr0,0x4/eq,taken=50%(0,0)                                                                             419| 001A94 bc         4180001C   0     BT         CL.2179,cr0,0x1/lt,taken=40%(40,60)
 1109| 001A80 addi       3BE00001   2     LI        gr31=1                                                                                                       1127| 001A98 addi       38600000   2     LI         gr3=0
 1110| 001A84 lwz        8063000C   1     L4A       gr3=(*)_frame._frame.f_back(gr3,12)                                                                             0| 001A9C lwz        83C10058   1     L4A        gr30=#stack(gr1,88)
 1109| 001A88 cmpwi      2C030000   2     C4        cr0=gr3,0                                                                                                       0| 001AA0 lwz        80010068   1     L4A        gr0=#stack(gr1,104)
 1109| 001A8C cror       4CC23382   1     CR_O      cr1=cr[01],0x4/eq,0x4/eq,0x4/eq                                                                              1134| 001AA4 addi       38210060   1     AI         gr1=gr1,96
 1109| 001A90 bc         41860258   0     BT        CL.1934,cr1,0x4/eq,taken=****                                                                                   0| 001AA8 mtspr      7C0803A6   1     LLR        lr=gr0
    0|                                CL.2086:                                                                                                                   1134| 001AAC bclr       4E800020   3     BA         lr
 1109| 001A94 addi       3BFF0001   1     AI        gr31=gr31,1                                                                                                     0|                                CL.2179:
    0| 001A98 bc         4240002C   0     BCF       ctr=CL.2092,taken=0%(0,100)                                                                                   420| 001AB0 addi       38800466   1     LI         gr4=1126
    0| 001A9C ori        60210000   2                                                                                                                             420| 001AB4 ori        63C50000   1     LR         gr5=gr30
 1109|                                CL.158:                                                                                                                     420| 001AB8 bl         4BFFE549   0     CALL       _Py_NegativeRefcount,3,(*)Cuchar",gr3,gr4,(*)_object",gr5,#ProcAlias",_Py_NegativeRefcount",fcr",gr1,cr[01
 1110| 001AA0 lwz        8063000C   1     L4A       gr3=(*)_frame._frame.f_back(gr3,12)                                                                           420| 001ABC ori        60000000   1
    0| 001AA4 or.        7C601B79   2     LR_R      gr0,cr0=gr3                                                                                                  1127| 001AC0 addi       38600000   1     LI         gr3=0
 1109| 001AA8 bc         4182002C   1     BT        CL.157,cr0,0x4/eq,taken=20%(20,80)                                                                              0| 001AC4 lwz        83C10058   1     L4A        gr30=#stack(gr1,88)
 1109| 001AAC addi       3BFF0001   1     AI        gr31=gr31,1                                                                                                     0| 001AC8 lwz        80010068   1     L4A        gr0=#stack(gr1,104)
 1110| 001AB0 lwz        8063000C   1     L4A       gr3=(*)_frame._frame.f_back(gr3,12)                                                                          1134| 001ACC addi       38210060   1     AI         gr1=gr1,96
    0| 001AB4 or.        7C601B79   2     LR_R      gr0,cr0=gr3                                                                                                     0| 001AD0 mtspr      7C0803A6   1     LLR        lr=gr0
 1109| 001AB8 bc         4182001C   1     BT        CL.157,cr0,0x4/eq,taken=20%(20,80)                                                                           1134| 001AD4 bclr       4E800020   3     BA         lr
 1109| 001ABC addi       3BFF0001   1     AI        gr31=gr31,1                                                                                                   423|                                CL.1096:
    0| 001AC0 bc         4200FFE0   0     BCT       ctr=CL.158,taken=100%(100,0)                                                                                  425| 001AD8 ori        63C30000   1     LR         gr3=gr30
    0|                                CL.2092:                                                                                                                      0| 001ADC lwz        83810050   1     L4A        gr28=#stack(gr1,80)
 1110| 001AC4 lwz        8003000C   1     L4A       gr0=(*)_frame._frame.f_back(gr3,12)                                                                           425| 001AE0 bl         4BFFE521   0     CALL       _Py_Dealloc,1,(*)_object",gr3,#ProcAlias",_Py_Dealloc",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",
 1109| 001AC8 cmpwi      2C000000   2     C4        cr0=gr0,0                                                                                                     425| 001AE4 ori        60000000   1
 1109| 001ACC bc         41820008   1     BT        CL.157,cr0,0x4/eq,taken=20%(20,80)                                                                           1127| 001AE8 addi       38600000   1     LI         gr3=0
 1109| 001AD0 addi       3BFF0001   1     AI        gr31=gr31,1                                                                                                     0| 001AEC lwz        83C10058   1     L4A        gr30=#stack(gr1,88)
 1109|                                CL.157:                                                                                                                       0| 001AF0 lwz        80010068   1     L4A        gr0=#stack(gr1,104)
 1114| 001AD4 ori        63E30000   1     LR        gr3=gr31                                                                                                     1134| 001AF4 addi       38210060   1     AI         gr1=gr1,96
 1114| 001AD8 bl         4BFFE529   0     CALL      gr3=PyTuple_New,1,gr3,#ProcAlias",PyTuple_New",fcr",gr1,cr[01567]",gr0",gr4"-gr12",fp0"-fp13",mq",lr",fcr",     0| 001AF8 mtspr      7C0803A6   1     LLR        lr=gr0
 1114| 001ADC ori        60000000   1                                                                                                                            1134| 001AFC bclr       4E800020   3     BA         lr
 1115| 001AE0 cmpwi      2C030000   1     C4        cr0=gr3,0                                                                                                       0|                                CL.1981:
 1115| 001AE4 bc         418201E8   1     BT        CL.2137,cr0,0x4/eq,taken=30%(30,70)                                                                          1133| 001B00 ori        63C30000   1     LR         gr3=gr30
    0|                                CL.1935:                                                                                                                      0| 001B04 lwz        83E1005C   1     L4A        gr31=#stack(gr1,92)
 1114| 001AE8 ori        607E0000   1     LR        gr30=gr3                                                                                                        0| 001B08 lwz        83A10054   1     L4A        gr29=#stack(gr1,84)
 1118| 001AEC bl         4BFFE515   0     CALL      gr3=PyEval_GetFrame,0,#ProcAlias",PyEval_GetFrame",fcr",gr1,cr[01567]",gr0",gr4"-gr12",fp0"-fp13",mq",lr",f     0| 001B0C lwz        83810050   1     L4A        gr28=#stack(gr1,80)
 1118| 001AF0 ori        60000000   1                                                                                                                               0| 001B10 lwz        83C10058   1     L4A        gr30=#stack(gr1,88)
 1118| 001AF4 ori        607D0000   1     LR        gr29=gr3                                                                                                        0| 001B14 lwz        80010068   1     L4A        gr0=#stack(gr1,104)







Wed Apr 15 07:30:04 CDT 2020  Page 90


 1119| 001AF8 cmpwi      2C1F0000   1     C4        cr0=gr31,0                                                                                                   1134| 001B18 addi       38210060   1     AI         gr1=gr1,96
 1119| 001AFC bc         408101B0   1     BF        CL.1938,cr0,0x2/gt,taken=30%(30,70)                                                                             0| 001B1C mtspr      7C0803A6   1     LLR        lr=gr0
 1120| 001B00 lwz        80830010   2     L4A       gr4=(*)_frame._frame.f_code(gr3,16)                                                                          1134| 001B20 bclr       4E800020   3     BA         lr
 1119| 001B04 addi       3B800000   1     LI        gr28=0                                                                                                          0|                                CL.2178:
 1129| 001B08 addi       3B5E0008   1     AI        gr26=gr30,8                                                                                                  1116| 001B24 addi       38600000   1     LI         gr3=0
 1129| 001B0C lwz        83220018   1     L4A       gr25=.+CONSTANT_AREA(gr2,0)                                                                                     0| 001B28 lwz        83E1005C   1     L4A        gr31=#stack(gr1,92)
 1120| 001B10 lwz        83020018   1     L4A       gr24=.+CONSTANT_AREA(gr2,0)                                                                                     0| 001B2C lwz        83C10058   1     L4A        gr30=#stack(gr1,88)
 1120| 001B14 lwz        83640040   1     L4A       gr27=(*)aggr#5.co_filename(gr4,64)                                                                              0| 001B30 lwz        80010068   1     L4A        gr0=#stack(gr1,104)
 1120| 001B18 ori        60000000   1                                                                                                                            1134| 001B34 addi       38210060   1     AI         gr1=gr1,96
 1120| 001B1C ori        60210000   1                                                                                                                               0| 001B38 mtspr      7C0803A6   1     LLR        lr=gr0
    0|                                CL.2095:                                                                                                                   1134| 001B3C bclr       4E800020   3     BA         lr
 1120| 001B20 bl         4BFFE4E1   0     CALL      gr3=PyFrame_GetLineNumber,1,(*)_frame",gr3,#ProcAlias",PyFrame_GetLineNumber",fcr",gr1,cr[01567]",gr0",gr4"      |               Tag Table
 1120| 001B24 ori        60000000   1                                                                                                                                | 001B40        00000000 00002041 80070100 00000000 000002C0 0011636F
 1120| 001B28 lwz        80DD0010   1     L4A       gr6=(*)_frame._frame.f_code(gr29,16)                                                                             | 001B58        6D707574 655F6372 5F6F7269 67696E
 1120| 001B2C ori        60650000   1     LR        gr5=gr3                                                                                                          |               Instruction count          176
 1120| 001B30 addi       387816E8   1     AI        gr3=gr24,5864                                                                                                    |               Straight-line exec time    189
 1120| 001B34 ori        63640000   1     LR        gr4=gr27                                                                                                     GPR's set/used:   su-s ssss ssss s---  ---- ---- ---- ----
 1120| 001B38 lwz        80C60044   1     L4A       gr6=(*)aggr#5.co_name(gr6,68)                                                                                FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----
 1120| 001B3C bl         4BFFE4C5   0     CALL      gr3=Py_BuildValue,4,gr3,(*)_object",gr4,gr5,(*)_object",gr6,#ProcAlias",Py_BuildValue",fcr",gr1,cr[01567]",  CCR's set/used:   ss-- -sss
 1120| 001B40 ori        60000000   1                                                                                                                                | 000000                             PDEF       coro_wrapper_traverse
 1120| 001B44 or.        7C7B1B79   1     LR_R      gr27,cr0=gr3                                                                                                 1048|                                    PROC       cw_129_25,visit_129_25,arg_129_25,gr3-gr5
 1125| 001B48 bc         418200B4   1     BT        CL.2133,cr0,0x4/eq,taken=20%(20,80)                                                                          1050| 001B80 lwz        80030008   1     L4A        gr0=(*)aggr#A.cw_coroutine(gr3,8)
 1129| 001B4C lwz        807E0004   2     L4A       gr3=(*)_object._object.ob_type(gr30,4)                                                                       1050| 001B84 cmpwi      2C000000   2     C4         cr0=gr0,0
  617| 001B50 bl         4BFFE4B1   0     CALL      gr3=PyType_GetFlags,1,(*)_typeobject",gr3,#ProcAlias",PyType_GetFlags",fcr",gr1,cr[01567]",gr0",gr4"-gr12",  1050| 001B88 bc         4082000C   1     BF         CL.1914,cr0,0x4/eq,taken=40%(40,60)
  617| 001B54 ori        60000000   1                                                                                                                            1051| 001B8C addi       38600000   1     LI         gr3=0
 1129| 001B58 andis.     74600400   1     RN4_R     gr0,cr0=gr3,0,0x4000000                                                                                         0| 001B90 bclr       4E800020   0     BA         lr
 1129| 001B5C bc         41820060   1     BT        CL.2142,cr0,0x4/eq,taken=40%(40,60)                                                                             0|                                CL.1914:
 1119| 001B60 addi       3B9C0001   2     AI        gr28=gr28,1                                                                                                  1052| 001B94 b          4800518C   0     CALLF      gr3=coro_wrapper_traverse at AF129_25,3,gr3-gr5,fcr",coro_wrapper_traverse at AF129_25",gr1,cr[01567]",gr0",gr4"
 1130| 001B64 lwz        83BD000C   1     L4A       gr29=(*)_frame._frame.f_back(gr29,12)                                                                            |               Tag Table
 1129| 001B68 stw        937A0004   1     ST4A      (*)aggr#B..[]0(gr26,4)=gr27                                                                                      | 001B98        00000000 00002040 00000300 00000000 00000018 0015636F
 1129| 001B6C addi       3B5A0004   1     AI        gr26=gr26,4                                                                                                      | 001BB0        726F5F77 72617070 65725F74 72617665 727365
 1120| 001B70 ori        63A30000   1     LR        gr3=gr29                                                                                                         |               Instruction count            6
 1119| 001B74 cmpw       7C1FE000   1     C4        cr0=gr31,gr28                                                                                                    |               Straight-line exec time      5
 1119| 001B78 bc         40810010   1     BF        CL.2134,cr0,0x2/gt,taken=20%(20,80)                                                                          GPR's set/used:   su-s ssss ssss s---  ---- ---- ---- ----
 1120| 001B7C lwz        809D0010   2     L4A       gr4=(*)_frame._frame.f_code(gr29,16)                                                                         FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----
 1120| 001B80 lwz        83640040   2     L4A       gr27=(*)aggr#5.co_filename(gr4,64)                                                                           CCR's set/used:   ss-- -sss
    0| 001B84 b          4BFFFF9C   0     B         CL.2095,-1                                                                                                       | 000000                             PDEF       coro_wrapper_close
 1119|                                CL.2134:                                                                                                                   1042|                                    PROC       cw,args,gr3,gr4
 1133| 001B88 ori        63C30000   1     LR        gr3=gr30                                                                                                     1044| 001BE0 lwz        80630008   1     L4A        gr3=(*)aggr#A.cw_coroutine(gr3,8)
    0| 001B8C lwz        83E1005C   1     L4A       gr31=#stack(gr1,92)                                                                                          1045| 001BE4 b          48002F7C   0     CALLF      gr3=gen_close,2,(*)aggr#3",gr3,(*)_object",gr4,#ProcAlias",gen_close",fcr",gr1,cr[01567]",gr0",gr4"-gr12",
    0| 001B90 lwz        83A10054   1     L4A       gr29=#stack(gr1,84)                                                                                          1045|                                CL.698:
    0| 001B94 lwz        83810050   1     L4A       gr28=#stack(gr1,80)                                                                                              |               Tag Table
    0| 001B98 lwz        8361004C   1     L4A       gr27=#stack(gr1,76)                                                                                              | 001BE8        00000000 00002040 00000200 00000000 00000008 0012636F
    0| 001B9C lwz        83410048   1     L4A       gr26=#stack(gr1,72)                                                                                              | 001C00        726F5F77 72617070 65725F63 6C6F7365
    0| 001BA0 lwz        83210044   1     L4A       gr25=#stack(gr1,68)                                                                                              |               Instruction count            2
    0| 001BA4 lwz        83010040   1     L4A       gr24=#stack(gr1,64)                                                                                              |               Straight-line exec time      1
 1134| 001BA8 addi       38210060   1     AI        gr1=gr1,96                                                                                                   GPR's set/used:   su-s ssss ssss s---  ---- ---- ---- ----
    0| 001BAC lwz        83C1FFF8   1     L4A       gr30=#stack(gr1,-8)                                                                                          FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----
    0| 001BB0 lwz        80010008   1     L4A       gr0=#stack(gr1,8)                                                                                            CCR's set/used:   ss-- -sss
    0| 001BB4 mtspr      7C0803A6   2     LLR       lr=gr0                                                                                                           | 000000                             PDEF       coro_wrapper_throw
 1134| 001BB8 bclr       4E800020   3     BA        lr                                                                                                           1036|                                    PROC       cw,args,gr3,gr4
    0|                                CL.2142:                                                                                                                   1038| 001C20 lwz        80630008   1     L4A        gr3=(*)aggr#A.cw_coroutine(gr3,8)
 1129| 001BBC ori        63240000   1     LR        gr4=gr25                                                                                                     1039| 001C24 b          48000C7C   0     CALLF      gr3=gen_throw,2,(*)aggr#3",gr3,(*)_object",gr4,#ProcAlias",gen_throw",fcr",gr1,cr[01567]",gr0",gr4"-gr12",
 1129| 001BC0 addi       38A00469   1     LI        gr5=1129                                                                                                     1039|                                CL.697:
 1129| 001BC4 addi       387916EC   1     AI        gr3=gr25,5868                                                                                                    |               Tag Table
 1129| 001BC8 addi       38841110   1     AI        gr4=gr4,4368                                                                                                     | 001C28        00000000 00002040 00000200 00000000 00000008 0012636F







Wed Apr 15 07:30:04 CDT 2020  Page 91


 1129| 001BCC bl         4BFFE435   0     CALL      __assert,3,gr3-gr5,#ProcAlias",__assert",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",lr",fcr",xer",f      | 001C40        726F5F77 72617070 65725F74 68726F77
 1129| 001BD0 ori        60000000   1                                                                                                                                |               Instruction count            2
 1129| 001BD4 stw        937A0004   1     ST4A      (*)aggr#B..[]0(gr26,4)=gr27                                                                                      |               Straight-line exec time      1
 1129| 001BD8 addi       3B5A0004   1     AI        gr26=gr26,4                                                                                                  GPR's set/used:   su-s ssss ssss s---  ---- ---- ---- ----
 1119| 001BDC addi       3B9C0001   1     AI        gr28=gr28,1                                                                                                  FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----
 1130| 001BE0 lwz        83BD000C   1     L4A       gr29=(*)_frame._frame.f_back(gr29,12)                                                                        CCR's set/used:   ss-- -sss
 1120| 001BE4 ori        63A30000   2     LR        gr3=gr29                                                                                                         | 000000                             PDEF       coro_wrapper_send
 1119| 001BE8 cmpw       7C1FE000   1     C4        cr0=gr31,gr28                                                                                                1030|                                    PROC       cw,arg,gr3,gr4
 1119| 001BEC bc         4081FF9C   1     BF        CL.2134,cr0,0x2/gt,taken=20%(20,80)                                                                          1032| 001C60 lwz        80630008   1     L4A        gr3=(*)aggr#A.cw_coroutine(gr3,8)
 1120| 001BF0 lwz        809D0010   1     L4A       gr4=(*)_frame._frame.f_code(gr29,16)                                                                         1032| 001C64 addi       38A00000   1     LI         gr5=0
 1120| 001BF4 lwz        83640040   2     L4A       gr27=(*)aggr#5.co_filename(gr4,64)                                                                           1032| 001C68 addi       38C00000   1     LI         gr6=0
    0| 001BF8 b          4BFFFF28   0     B         CL.2095,-1                                                                                                   1033| 001C6C b          48001A14   0     CALLF      gr3=gen_send_ex,4,(*)aggr#3",gr3,(*)_object",gr4-gr6,#ProcAlias",gen_send_ex",fcr",gr1,cr[01567]",gr0",gr4
 1125|                                CL.2133:                                                                                                                   1033|                                CL.696:
  417| 001BFC lwz        80BE0000   1     L4A       gr5=(*)_object._object.ob_refcnt(gr30,0)                                                                         |               Tag Table
  415| 001C00 lwz        80820004   1     L4A       gr4=._Py_RefTotal(gr2,0)                                                                                         | 001C70        00000000 00002040 00000200 00000000 00000010 0011636F
    0| 001C04 lwz        83E1005C   1     L4A       gr31=#stack(gr1,92)                                                                                              | 001C88        726F5F77 72617070 65725F73 656E64
  408| 001C08 lwz        80620018   1     L4A       gr3=.+CONSTANT_AREA(gr2,0)                                                                                       |               Instruction count            4
    0| 001C0C lwz        83A10054   1     L4A       gr29=#stack(gr1,84)                                                                                              |               Straight-line exec time      3
    0| 001C10 lwz        83810050   1     L4A       gr28=#stack(gr1,80)                                                                                          GPR's set/used:   su-s ssss ssss s---  ---- ---- ---- ----
  417| 001C14 addi       3805FFFF   1     AI        gr0=gr5,-1                                                                                                   FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----
    0| 001C18 lwz        8361004C   1     L4A       gr27=#stack(gr1,76)                                                                                          CCR's set/used:   ss-- -sss
    0| 001C1C lwz        83410048   1     L4A       gr26=#stack(gr1,72)                                                                                              | 000000                             PDEF       coro_wrapper_iternext
  408| 001C20 addi       38631110   1     AI        gr3=gr3,4368                                                                                                 1024|                                    PROC       cw,gr3
    0| 001C24 lwz        83210044   1     L4A       gr25=#stack(gr1,68)                                                                                          1026| 001CA0 lwz        80630008   1     L4A        gr3=(*)aggr#A.cw_coroutine(gr3,8)
  415| 001C28 lwz        80A40000   1     L4A       gr5=<s117:d0:l4>(gr4,0)                                                                                      1026| 001CA4 addi       38800000   1     LI         gr4=0
    0| 001C2C lwz        83010040   1     L4A       gr24=#stack(gr1,64)                                                                                          1026| 001CA8 addi       38A00000   1     LI         gr5=0
  417| 001C30 stw        901E0000   1     ST4A      (*)_object._object.ob_refcnt(gr30,0)=gr0                                                                     1026| 001CAC addi       38C00000   1     LI         gr6=0
  415| 001C34 addi       38A5FFFF   1     AI        gr5=gr5,-1                                                                                                   1027| 001CB0 b          480019D0   0     CALLF      gr3=gen_send_ex,4,(*)aggr#3",gr3,(*)_object",gr4-gr6,#ProcAlias",gen_send_ex",fcr",gr1,cr[01567]",gr0",gr4
  417| 001C38 cmpwi      2C000000   1     C4        cr0=gr0,0                                                                                                    1027|                                CL.695:
  415| 001C3C stw        90A40000   1     ST4A      <s117:d0:l4>(gr4,0)=gr5                                                                                          |               Tag Table
  417| 001C40 bc         41820048   0     BT        CL.1096,cr0,0x4/eq,taken=40%(40,60)                                                                              | 001CB4        00000000 00002040 00000100 00000000 00000014 0015636F
  417| 001C44 bc         4180001C   1     BT        CL.2141,cr0,0x1/lt,taken=40%(40,60)                                                                              | 001CCC        726F5F77 72617070 65725F69 7465726E 657874
 1116| 001C48 addi       38600000   3     LI        gr3=0                                                                                                            |               Instruction count            5
 1134| 001C4C addi       38210060   1     AI        gr1=gr1,96                                                                                                       |               Straight-line exec time      4
    0| 001C50 lwz        83C1FFF8   1     L4A       gr30=#stack(gr1,-8)                                                                                          GPR's set/used:   ssus ssss ssss s---  ---- ---- ---- ---s
    0| 001C54 lwz        80010008   1     L4A       gr0=#stack(gr1,8)                                                                                            FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----
    0| 001C58 mtspr      7C0803A6   2     LLR       lr=gr0                                                                                                       CCR's set/used:   ss-- -sss
 1134| 001C5C bclr       4E800020   3     BA        lr                                                                                                               | 000000                             PDEF       coro_wrapper_dealloc
    0|                                CL.2141:                                                                                                                   1016|                                    PROC       cw,gr3
  420| 001C60 addi       38800466   1     LI        gr4=1126                                                                                                        0| 001CE0 mfspr      7C0802A6   1     LFLR       gr0=lr
  420| 001C64 ori        63C50000   1     LR        gr5=gr30                                                                                                        0| 001CE4 lwz        81020018   1     L4A        gr8=.+CONSTANT_AREA(gr2,0)
  420| 001C68 bl         4BFFE399   0     CALL      _Py_NegativeRefcount,3,(*)Cuchar",gr3,gr4,(*)_object",gr5,#ProcAlias",_Py_NegativeRefcount",fcr",gr1,cr[015     0| 001CE8 stwu       9421FFC0   1     ST4U       gr1,#stack(gr1,-64)=gr1
  420| 001C6C ori        60000000   1                                                                                                                              61| 001CEC addi       38C81110   1     AI         gr6=gr8,4368
 1116| 001C70 addi       38600000   1     LI        gr3=0                                                                                                           0| 001CF0 stw        90010048   1     ST4A       #stack(gr1,72)=gr0
 1134| 001C74 addi       38210060   1     AI        gr1=gr1,96                                                                                                      0| 001CF4 stw        93E1003C   1     ST4A       #stack(gr1,60)=gr31
    0| 001C78 lwz        83C1FFF8   1     L4A       gr30=#stack(gr1,-8)                                                                                             0| 001CF8 ori        607F0000   1     LR         gr31=gr3
    0| 001C7C lwz        80010008   1     L4A       gr0=#stack(gr1,8)                                                                                              64| 001CFC lwz        8003FFF8   1     L4A        gr0=(*)_object%##2(gr3,-8)
    0| 001C80 mtspr      7C0803A6   2     LLR       lr=gr0                                                                                                         64| 001D00 cmpwi      2C000000   2     C4         cr0=gr0,0
 1134| 001C84 bclr       4E800020   3     BA        lr                                                                                                             64| 001D04 bc         418200E8   1     BT         CL.1918,cr0,0x4/eq,taken=10%(10,90)
  423|                                CL.1096:                                                                                                                     69| 001D08 lwz        80E3FFFC   1     L4A        gr7=(*)aggr#2._gc_prev(gr3,-4)
  425| 001C88 ori        63C30000   1     LR        gr3=gr30                                                                                                       70| 001D0C lwz        8063FFF8   1     L4A        gr3=(*)aggr#2._gc_next(gr3,-8)
  425| 001C8C bl         4BFFE375   0     CALL      _Py_Dealloc,1,(*)_object",gr3,#ProcAlias",_Py_Dealloc",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",l  1019| 001D10 lwz        80BF0008   1     L4A        gr5=(*)aggr#A.cw_coroutine(gr31,8)
  425| 001C90 ori        60000000   1                                                                                                                               0| 001D14 or.        7CA02B79   2     LR_R       gr0,cr0=gr5
 1116| 001C94 addi       38600000   1     LI        gr3=0                                                                                                          69| 001D18 rlwinm     54E4003A   1     RN4        gr4=gr7,0,0xFFFFFFFC
 1134| 001C98 addi       38210060   1     AI        gr1=gr1,96                                                                                                     72| 001D1C lwz        80030004   1     L4A        gr0=(*)aggr#2._gc_prev(gr3,4)
    0| 001C9C lwz        83C1FFF8   1     L4A       gr30=#stack(gr1,-8)                                                                                            71| 001D20 stw        90640000   1     ST4A       (*)aggr#2._gc_next(gr4,0)=gr3







Wed Apr 15 07:30:04 CDT 2020  Page 92


    0| 001CA0 lwz        80010008   1     L4A       gr0=#stack(gr1,8)                                                                                              73| 001D24 addi       38800000   1     LI         gr4=0
    0| 001CA4 mtspr      7C0803A6   2     LLR       lr=gr0                                                                                                         72| 001D28 rlwimi     50E0003A   1     RI4        gr0=gr7,0,gr0,0xFFFFFFFC
 1134| 001CA8 bclr       4E800020   3     BA        lr                                                                                                             72| 001D2C stw        90030004   1     ST4A       (*)aggr#2._gc_prev(gr3,4)=gr0
    0|                                CL.1938:                                                                                                                     74| 001D30 lwz        807FFFFC   1     L4A        gr3=(*)aggr#2._gc_prev(gr31,-4)
 1133| 001CAC ori        63C30000   1     LR        gr3=gr30                                                                                                       73| 001D34 stw        909FFFF8   1     ST4A       (*)aggr#2._gc_next(gr31,-8)=gr4
    0| 001CB0 lwz        83E1005C   1     L4A       gr31=#stack(gr1,92)                                                                                            74| 001D38 rlwinm     546007FE   1     RN4        gr0=gr3,0,0x1
    0| 001CB4 lwz        83A10054   1     L4A       gr29=#stack(gr1,84)                                                                                            74| 001D3C stw        901FFFFC   1     ST4A       (*)aggr#2._gc_prev(gr31,-4)=gr0
 1134| 001CB8 addi       38210060   1     AI        gr1=gr1,96                                                                                                   1019| 001D40 bc         41820060   0     BT         CL.1915,cr0,0x4/eq,taken=30%(30,70)
    0| 001CBC lwz        83C1FFF8   1     L4A       gr30=#stack(gr1,-8)                                                                                           417| 001D44 lwz        80E50000   1     L4A        gr7=(*)_object._object.ob_refcnt(gr5,0)
    0| 001CC0 lwz        80010008   1     L4A       gr0=#stack(gr1,8)                                                                                             415| 001D48 lwz        80620004   1     L4A        gr3=._Py_RefTotal(gr2,0)
    0| 001CC4 mtspr      7C0803A6   2     LLR       lr=gr0                                                                                                       1019| 001D4C stw        909F0008   1     ST4A       (*)aggr#A.cw_coroutine(gr31,8)=gr4
 1134| 001CC8 bclr       4E800020   3     BA        lr                                                                                                            417| 001D50 addi       3807FFFF   1     AI         gr0=gr7,-1
    0|                                CL.2137:                                                                                                                    417| 001D54 stw        90050000   1     ST4A       (*)_object._object.ob_refcnt(gr5,0)=gr0
 1116| 001CCC addi       38600000   1     LI        gr3=0                                                                                                         415| 001D58 lwz        80830000   1     L4A        gr4=_Py_RefTotal(gr3,0)
    0| 001CD0 lwz        83E1005C   1     L4A       gr31=#stack(gr1,92)                                                                                           417| 001D5C cmpwi      2C000000   1     C4         cr0=gr0,0
 1134| 001CD4 addi       38210060   1     AI        gr1=gr1,96                                                                                                    415| 001D60 addi       3804FFFF   1     AI         gr0=gr4,-1
    0| 001CD8 lwz        83C1FFF8   1     L4A       gr30=#stack(gr1,-8)                                                                                           415| 001D64 stw        90030000   1     ST4A       _Py_RefTotal(gr3,0)=gr0
    0| 001CDC lwz        80010008   1     L4A       gr0=#stack(gr1,8)                                                                                             417| 001D68 bc         41820058   0     BT         CL.1347,cr0,0x4/eq,taken=40%(40,60)
    0| 001CE0 mtspr      7C0803A6   2     LLR       lr=gr0                                                                                                        419| 001D6C bc         40800034   1     BF         CL.1915,cr0,0x1/lt,taken=50%(0,0)
 1134| 001CE4 bclr       4E800020   3     BA        lr                                                                                                            420| 001D70 ori        60C30000   3     LR         gr3=gr6
    0|                                CL.1934:                                                                                                                    420| 001D74 addi       388003FB   1     LI         gr4=1019
 1114| 001CE8 ori        63E30000   1     LR        gr3=gr31                                                                                                      420| 001D78 bl         4BFFE289   0     CALL       _Py_NegativeRefcount,3,(*)Cuchar",gr3,gr4,(*)_object",gr5,#ProcAlias",_Py_NegativeRefcount",fcr",gr1,cr[01
 1114| 001CEC bl         4BFFE315   0     CALL      gr3=PyTuple_New,1,gr3,#ProcAlias",PyTuple_New",fcr",gr1,cr[01567]",gr0",gr4"-gr12",fp0"-fp13",mq",lr",fcr",   420| 001D7C ori        60000000   1
 1114| 001CF0 ori        60000000   1                                                                                                                            1020| 001D80 ori        63E30000   1     LR         gr3=gr31
 1115| 001CF4 cmpwi      2C030000   1     C4        cr0=gr3,0                                                                                                    1020| 001D84 bl         4BFFE27D   0     CALL       PyObject_GC_Del,1,(*)void",gr3,#ProcAlias",PyObject_GC_Del",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13"
 1115| 001CF8 bc         4082FDF0   1     BF        CL.1935,cr0,0x4/eq,taken=70%(70,30)                                                                          1020| 001D88 ori        60000000   1
 1116| 001CFC addi       38600000   2     LI        gr3=0                                                                                                           0| 001D8C lwz        83E1003C   1     L4A        gr31=#stack(gr1,60)
    0| 001D00 lwz        83E1005C   1     L4A       gr31=#stack(gr1,92)                                                                                             0| 001D90 lwz        80010048   1     L4A        gr0=#stack(gr1,72)
 1134| 001D04 addi       38210060   1     AI        gr1=gr1,96                                                                                                   1021| 001D94 addi       38210040   1     AI         gr1=gr1,64
    0| 001D08 lwz        83C1FFF8   1     L4A       gr30=#stack(gr1,-8)                                                                                             0| 001D98 mtspr      7C0803A6   1     LLR        lr=gr0
    0| 001D0C lwz        80010008   1     L4A       gr0=#stack(gr1,8)                                                                                            1021| 001D9C bclr       4E800020   3     BA         lr
    0| 001D10 mtspr      7C0803A6   2     LLR       lr=gr0                                                                                                          0|                                CL.1915:
 1134| 001D14 bclr       4E800020   3     BA        lr                                                                                                           1020| 001DA0 ori        63E30000   1     LR         gr3=gr31
    0|                                CL.1918:                                                                                                                   1020| 001DA4 bl         4BFFE25D   0     CALL       PyObject_GC_Del,1,(*)void",gr3,#ProcAlias",PyObject_GC_Del",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13"
 1108| 001D18 addi       3BE00000   1     LI        gr31=0                                                                                                       1020| 001DA8 ori        60000000   1
    0| 001D1C b          4BFFFFCC   0     B         CL.1934,-1                                                                                                      0| 001DAC lwz        83E1003C   1     L4A        gr31=#stack(gr1,60)
     |               Tag Table                                                                                                                                      0| 001DB0 lwz        80010048   1     L4A        gr0=#stack(gr1,72)
     | 001D20        00000000 00002041 80080100 00000000 00000300 0011636F                                                                                       1021| 001DB4 addi       38210040   1     AI         gr1=gr1,64
     | 001D38        6D707574 655F6372 5F6F7269 67696E                                                                                                              0| 001DB8 mtspr      7C0803A6   1     LLR        lr=gr0
     |               Instruction count          192                                                                                                              1021| 001DBC bclr       4E800020   3     BA         lr
     |               Straight-line exec time    212                                                                                                               423|                                CL.1347:
 GPR's set/used:   su-s ssss ssss s---  ---- ---- ---- ----                                                                                                       425| 001DC0 ori        60A30000   1     LR         gr3=gr5
 FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----                                                                                                       425| 001DC4 bl         4BFFE23D   0     CALL       _Py_Dealloc,1,(*)_object",gr3,#ProcAlias",_Py_Dealloc",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",
 CCR's set/used:   ss-- -sss                                                                                                                                      425| 001DC8 ori        60000000   1
     | 000000                             PDEF     coro_wrapper_traverse                                                                                         1020| 001DCC ori        63E30000   1     LR         gr3=gr31
 1048|                                    PROC      cw_124_25,visit_124_25,arg_124_25,gr3-gr5                                                                    1020| 001DD0 bl         4BFFE231   0     CALL       PyObject_GC_Del,1,(*)void",gr3,#ProcAlias",PyObject_GC_Del",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13"
 1050| 001D60 lwz        80030008   1     L4A       gr0=(*)aggr#A.cw_coroutine(gr3,8)                                                                            1020| 001DD4 ori        60000000   1
 1050| 001D64 cmpwi      2C000000   2     C4        cr0=gr0,0                                                                                                       0| 001DD8 lwz        83E1003C   1     L4A        gr31=#stack(gr1,60)
 1050| 001D68 bc         4082000C   1     BF        CL.1825,cr0,0x4/eq,taken=40%(40,60)                                                                             0| 001DDC lwz        80010048   1     L4A        gr0=#stack(gr1,72)
 1051| 001D6C addi       38600000   1     LI        gr3=0                                                                                                        1021| 001DE0 addi       38210040   1     AI         gr1=gr1,64
    0| 001D70 bclr       4E800020   0     BA        lr                                                                                                              0| 001DE4 mtspr      7C0803A6   1     LLR        lr=gr0
    0|                                CL.1825:                                                                                                                   1021| 001DE8 bclr       4E800020   3     BA         lr
 1052| 001D74 b          48004A4C   0     CALLF     gr3=coro_wrapper_traverse at AF124_25,3,gr3-gr5,fcr",coro_wrapper_traverse at AF124_25",gr1,cr[01567]",gr0",gr4"-     0|                                CL.1918:
     |               Tag Table                                                                                                                                     64| 001DEC addi       388813E4   1     AI         gr4=gr8,5092
     | 001D78        00000000 00002040 00000300 00000000 00000018 0015636F                                                                                         64| 001DF0 addi       38A8140C   1     AI         gr5=gr8,5132
     | 001D90        726F5F77 72617070 65725F74 72617665 727365                                                                                                    64| 001DF4 addi       38E003FA   1     LI         gr7=1018







Wed Apr 15 07:30:04 CDT 2020  Page 93


     |               Instruction count            6                                                                                                                64| 001DF8 addi       39081438   1     AI         gr8=gr8,5176
     |               Straight-line exec time      5                                                                                                                64| 001DFC bl         4BFFE205   0     CALL       _PyObject_AssertFailed,6,(*)_object",gr3-gr5,(*)Cuchar",gr6-gr8,#ProcAlias",_PyObject_AssertFailed",fcr",g
 GPR's set/used:   su-s ssss ssss s---  ---- ---- ---- ----                                                                                                        64| 001E00 ori        60000000   1
 FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----                                                                                                        64| 001E04 tw         7C8E7008   1     TRAP       9
 CCR's set/used:   ss-- -sss                                                                                                                                         | 001E08 b          48000000   0
     | 000000                             PDEF     coro_wrapper_close                                                                                                |               Tag Table
 1042|                                    PROC      cw,args,gr3,gr4                                                                                                  | 001E0C        00000000 00002041 80010100 00000000 0000012C 0014636F
 1044| 001DC0 lwz        80630008   1     L4A       gr3=(*)aggr#A.cw_coroutine(gr3,8)                                                                                | 001E24        726F5F77 72617070 65725F64 65616C6C 6F63
 1045| 001DC4 b          48002F7C   0     CALLF     gr3=gen_close,2,(*)aggr#3",gr3,(*)_object",gr4,#ProcAlias",gen_close",fcr",gr1,cr[01567]",gr0",gr4"-gr12",f      |               Instruction count           75
 1045|                                CL.698:                                                                                                                        |               Straight-line exec time     76
     |               Tag Table                                                                                                                                   GPR's set/used:   ssus ssss ssss s---  ---- ---- ---- ----
     | 001DC8        00000000 00002040 00000200 00000000 00000008 0012636F                                                                                       FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----
     | 001DE0        726F5F77 72617070 65725F63 6C6F7365                                                                                                         CCR's set/used:   ss-- -sss
     |               Instruction count            2                                                                                                                  | 000000                             PDEF       coro_get_cr_await
     |               Straight-line exec time      1                                                                                                               913|                                    PROC       coro,_unused_ignored,gr3,gr4
 GPR's set/used:   su-s ssss ssss s---  ---- ---- ---- ----                                                                                                         0| 001E40 mfspr      7C0802A6   1     LFLR       gr0=lr
 FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----                                                                                                         0| 001E44 stwu       9421FFC0   1     ST4U       gr1,#stack(gr1,-64)=gr1
 CCR's set/used:   ss-- -sss                                                                                                                                        0| 001E48 stw        90010048   1     ST4A       #stack(gr1,72)=gr0
     | 000000                             PDEF     coro_wrapper_throw                                                                                             915| 001E4C bl         48003A95   0     CALL       gr3=_PyGen_yf,1,(*)aggr#3",gr3,#ProcAlias",_PyGen_yf",fcr",gr1,cr[01567]",gr0",gr4"-gr12",fp0"-fp13",mq",l
 1036|                                    PROC      cw,args,gr3,gr4                                                                                               916| 001E50 cmpwi      2C030000   1     C4         cr0=gr3,0
 1038| 001E00 lwz        80630008   1     L4A       gr3=(*)aggr#A.cw_coroutine(gr3,8)                                                                             401| 001E54 lwz        80820004   1     L4A        gr4=._Py_RefTotal(gr2,0)
 1039| 001E04 b          48000C7C   0     CALLF     gr3=gen_throw,2,(*)aggr#3",gr3,(*)_object",gr4,#ProcAlias",gen_throw",fcr",gr1,cr[01567]",gr0",gr4"-gr12",f   916| 001E58 bc         40820030   0     BF         CL.2218,cr0,0x4/eq,taken=50%(0,0)
 1039|                                CL.697:                                                                                                                     917| 001E5C lwz        80620008   2     L4A        gr3=._Py_NoneStruct(gr2,0)
     |               Tag Table                                                                                                                                    401| 001E60 lwz        80A40000   1     L4A        gr5=_Py_RefTotal(gr4,0)
     | 001E08        00000000 00002040 00000200 00000000 00000008 0012636F                                                                                        403| 001E64 lwz        80C30000   1     L4A        gr6=_Py_NoneStruct%##1(gr3,0)
     | 001E20        726F5F77 72617070 65725F74 68726F77                                                                                                            0| 001E68 lwz        80010048   1     L4A        gr0=#stack(gr1,72)
     |               Instruction count            2                                                                                                               919| 001E6C addi       38210040   1     AI         gr1=gr1,64
     |               Straight-line exec time      1                                                                                                                 0| 001E70 mtspr      7C0803A6   1     LLR        lr=gr0
 GPR's set/used:   su-s ssss ssss s---  ---- ---- ---- ----                                                                                                       401| 001E74 addi       38050001   1     AI         gr0=gr5,1
 FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----                                                                                                       401| 001E78 stw        90040000   1     ST4A       _Py_RefTotal(gr4,0)=gr0
 CCR's set/used:   ss-- -sss                                                                                                                                      403| 001E7C addi       38860001   1     AI         gr4=gr6,1
     | 000000                             PDEF     coro_wrapper_send                                                                                              403| 001E80 stw        90830000   1     ST4A       _Py_NoneStruct%##1(gr3,0)=gr4
 1030|                                    PROC      cw,arg,gr3,gr4                                                                                                919| 001E84 bclr       4E800020   0     BA         lr
 1032| 001E40 lwz        80630008   1     L4A       gr3=(*)aggr#A.cw_coroutine(gr3,8)                                                                               0|                                CL.2218:
 1032| 001E44 addi       38A00000   1     LI        gr5=0                                                                                                           0| 001E88 lwz        80010048   1     L4A        gr0=#stack(gr1,72)
 1032| 001E48 addi       38C00000   1     LI        gr6=0                                                                                                         919| 001E8C addi       38210040   1     AI         gr1=gr1,64
 1033| 001E4C b          48001A14   0     CALLF     gr3=gen_send_ex,4,(*)aggr#3",gr3,(*)_object",gr4-gr6,#ProcAlias",gen_send_ex",fcr",gr1,cr[01567]",gr0",gr4"     0| 001E90 mtspr      7C0803A6   1     LLR        lr=gr0
 1033|                                CL.696:                                                                                                                     919| 001E94 bclr       4E800020   3     BA         lr
     |               Tag Table                                                                                                                                       |               Tag Table
     | 001E50        00000000 00002040 00000200 00000000 00000010 0011636F                                                                                           | 001E98        00000000 00002041 80000200 00000000 00000058 0011636F
     | 001E68        726F5F77 72617070 65725F73 656E64                                                                                                               | 001EB0        726F5F67 65745F63 725F6177 616974
     |               Instruction count            4                                                                                                                  |               Instruction count           22
     |               Straight-line exec time      3                                                                                                                  |               Straight-line exec time     22
 GPR's set/used:   su-s ssss ssss s---  ---- ---- ---- ----                                                                                                      GPR's set/used:   ssus ssss ssss s---  ---- ---- ---- ssss
 FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----                                                                                                      FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----
 CCR's set/used:   ss-- -sss                                                                                                                                     CCR's set/used:   ss-- -sss
     | 000000                             PDEF     coro_wrapper_iternext                                                                                             | 000000                             PDEF       coro_await
 1024|                                    PROC      cw,gr3                                                                                                        900|                                    PROC       coro,gr3
 1026| 001E80 lwz        80630008   1     L4A       gr3=(*)aggr#A.cw_coroutine(gr3,8)                                                                               0| 001EC0 mfspr      7C0802A6   1     LFLR       gr0=lr
 1026| 001E84 addi       38800000   1     LI        gr4=0                                                                                                           0| 001EC4 stwu       9421FFB0   1     ST4U       gr1,#stack(gr1,-80)=gr1
 1026| 001E88 addi       38A00000   1     LI        gr5=0                                                                                                           0| 001EC8 stw        90010058   1     ST4A       #stack(gr1,88)=gr0
 1026| 001E8C addi       38C00000   1     LI        gr6=0                                                                                                           0| 001ECC stw        93E1004C   1     ST4A       #stack(gr1,76)=gr31
 1027| 001E90 b          480019D0   0     CALLF     gr3=gen_send_ex,4,(*)aggr#3",gr3,(*)_object",gr4-gr6,#ProcAlias",gen_send_ex",fcr",gr1,cr[01567]",gr0",gr4"     0| 001ED0 ori        607F0000   1     LR         gr31=gr3
 1027|                                CL.695:                                                                                                                       0| 001ED4 stw        93C10048   1     ST4A       #stack(gr1,72)=gr30
     |               Tag Table                                                                                                                                      0| 001ED8 stw        93A10044   1     ST4A       #stack(gr1,68)=gr29
     | 001E94        00000000 00002040 00000100 00000000 00000014 0015636F                                                                                          0| 001EDC stw        93810040   1     ST4A       #stack(gr1,64)=gr28







Wed Apr 15 07:30:04 CDT 2020  Page 94


     | 001EAC        726F5F77 72617070 65725F69 7465726E 657874                                                                                                   902| 001EE0 lwz        806200A0   1     L4A        gr3=._PyCoroWrapper_Type(gr2,0)
     |               Instruction count            5                                                                                                               902| 001EE4 bl         4BFFE11D   0     CALL       gr3=_PyObject_GC_New,1,(*)_typeobject",gr3,#ProcAlias",_PyObject_GC_New",fcr",gr1,cr[01567]",gr0",gr4"-gr1
     |               Straight-line exec time      4                                                                                                               902| 001EE8 ori        60000000   1
 GPR's set/used:   ssus ssss ssss s---  ---- ---- ---- ---s                                                                                                       903| 001EEC cmpwi      2C030000   1     C4         cr0=gr3,0
 FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----                                                                                                       903| 001EF0 bc         41820134   1     BT         CL.1923,cr0,0x4/eq,taken=30%(30,70)
 CCR's set/used:   ss-- -sss                                                                                                                                      401| 001EF4 lwz        80820004   2     L4A        gr4=._Py_RefTotal(gr2,0)
     | 000000                             PDEF     coro_wrapper_dealloc                                                                                             0| 001EF8 lwz        81020018   1     L4A        gr8=.+CONSTANT_AREA(gr2,0)
 1016|                                    PROC      cw,gr3                                                                                                        903| 001EFC ori        607C0000   1     LR         gr28=gr3
    0| 001EC0 mfspr      7C0802A6   1     LFLR      gr0=lr                                                                                                        403| 001F00 lwz        807F0000   1     L4A        gr3=(*)_object._object.ob_refcnt(gr31,0)
    0| 001EC4 lwz        81020018   1     L4A       gr8=.+CONSTANT_AREA(gr2,0)                                                                                     27| 001F04 addi       38C81110   1     AI         gr6=gr8,4368
   61| 001EC8 addi       38C81110   2     AI        gr6=gr8,4368                                                                                                  403| 001F08 addi       38A30001   1     AI         gr5=gr3,1
    0| 001ECC stw        90010008   1     ST4A      #stack(gr1,8)=gr0                                                                                             403| 001F0C stw        90BF0000   1     ST4A       (*)_object._object.ob_refcnt(gr31,0)=gr5
    0| 001ED0 stw        93E1FFFC   1     ST4A      #stack(gr1,-4)=gr31                                                                                           401| 001F10 lwz        80640000   1     L4A        gr3=_Py_RefTotal(gr4,0)
    0| 001ED4 ori        607F0000   1     LR        gr31=gr3                                                                                                      907| 001F14 stw        93FC0008   1     ST4A       (*)aggr#A.cw_coroutine(gr28,8)=gr31
   73| 001ED8 addi       38000000   1     LI        gr0=0                                                                                                         401| 001F18 addi       38630001   1     AI         gr3=gr3,1
    0| 001EDC stwu       9421FFC0   1     ST4U      gr1,#stack(gr1,-64)=gr1                                                                                       401| 001F1C stw        90640000   1     ST4A       _Py_RefTotal(gr4,0)=gr3
   64| 001EE0 lwz        8063FFF8   1     L4A       gr3=(*)_object%##2(gr3,-8)                                                                                      0| 001F20 lwz        80010058   1     L4A        gr0=#stack(gr1,88)
   64| 001EE4 cmpwi      2C030000   2     C4        cr0=gr3,0                                                                                                       0| 001F24 mtspr      7C0803A6   2     LLR        lr=gr0
   64| 001EE8 bc         418200E4   1     BT        CL.1829,cr0,0x4/eq,taken=10%(10,90)                                                                            30| 001F28 lwz        801CFFF8   1     L4A        gr0=(*)_object%##2(gr28,-8)
   70| 001EEC lwz        807FFFF8   1     L4A       gr3=(*)aggr#2._gc_next(gr31,-8)                                                                                30| 001F2C cmpwi      2C000000   2     C4         cr0=gr0,0
 1019| 001EF0 lwz        80BF0008   1     L4A       gr5=(*)aggr#A.cw_coroutine(gr31,8)                                                                             30| 001F30 bc         408200D4   1     BF         CL.2216,cr0,0x4/eq,taken=10%(10,90)
   69| 001EF4 lwz        811FFFFC   1     L4A       gr8=(*)aggr#2._gc_prev(gr31,-4)                                                                                34| 001F34 addi       3BFCFFF8   1     AI         gr31=gr28,-8
    0| 001EF8 or.        7CA72B79   1     LR_R      gr7,cr0=gr5                                                                                                    35| 001F38 lwz        801CFFFC   1     L4A        gr0=(*)aggr#2._gc_prev(gr28,-4)
   69| 001EFC rlwinm     5504003A   1     RN4       gr4=gr8,0,0xFFFFFFFC                                                                                           35| 001F3C andi.      70030002   2     RN4_R      gr3,cr0=gr0,0,0x2
   72| 001F00 lwz        80E30004   1     L4A       gr7=(*)aggr#2._gc_prev(gr3,4)                                                                                  35| 001F40 bc         408200A4   1     BF         CL.1925,cr0,0x4/eq,taken=10%(10,90)
   72| 001F04 rlwimi     5107003A   2     RI4       gr7=gr8,0,gr7,0xFFFFFFFC                                                                                       67| 001F44 lwz        808200A4   1     L4A        gr4=._PyRuntime(gr2,0)
   71| 001F08 stw        90640000   1     ST4A      (*)aggr#2._gc_next(gr4,0)=gr3                                                                                  54| 001F48 lwz        806401A0   2     L4A        gr3=(*)pyruntimestate._Py_atomic_address._value(gr4,416)
   72| 001F0C stw        90E30004   1     ST4A      (*)aggr#2._gc_prev(gr3,4)=gr7                                                                                  41| 001F4C lwz        80630008   2     L4A        gr3=(*)_ts._ts.interp(gr3,8)
   73| 001F10 stw        901FFFF8   1     ST4A      (*)aggr#2._gc_next(gr31,-8)=gr0                                                                                41| 001F50 lwz        83C30188   2     L4A        gr30=(*)_is._gc_runtime_state.generation0(gr3,392)
   74| 001F14 lwz        807FFFFC   1     L4A       gr3=(*)aggr#2._gc_prev(gr31,-4)                                                                                42| 001F54 lwz        83BE0004   2     L4A        gr29=(*)aggr#2._gc_prev(gr30,4)
   74| 001F18 rlwinm     546707FE   2     RN4       gr7=gr3,0,0x1                                                                                                  44| 001F58 andi.      73A30003   2     RN4_R      gr3,cr0=gr29,0,0xFFFFFFFF00000003
   74| 001F1C stw        90FFFFFC   1     ST4A      (*)aggr#2._gc_prev(gr31,-4)=gr7                                                                                43| 001F5C stw        93FD0000   1     ST4A       (*)aggr#2._gc_next(gr29,0)=gr31
 1019| 001F20 bc         41820060   0     BT        CL.1826,cr0,0x4/eq,taken=30%(30,70)                                                                            44| 001F60 bc         40820034   0     BF         CL.2217,cr0,0x4/eq,taken=40%(40,60)
 1019| 001F24 stw        901F0008   1     ST4A      (*)aggr#A.cw_coroutine(gr31,8)=gr0                                                                             44| 001F64 rlwinm     540007BE   1     RN4        gr0=gr0,0,0x3
  415| 001F28 lwz        80820004   1     L4A       gr4=._Py_RefTotal(gr2,0)                                                                                       45| 001F68 stw        93DCFFF8   1     ST4A       (*)aggr#2._gc_next(gr28,-8)=gr30
  417| 001F2C lwz        80650000   1     L4A       gr3=(*)_object._object.ob_refcnt(gr5,0)                                                                        44| 001F6C or         7C04EB78   1     O          gr4=gr0,gr29
  417| 001F30 addi       3803FFFF   2     AI        gr0=gr3,-1                                                                                                    909| 001F70 ori        63830000   1     LR         gr3=gr28
  417| 001F34 stw        90050000   1     ST4A      (*)_object._object.ob_refcnt(gr5,0)=gr0                                                                        44| 001F74 stw        909CFFFC   1     ST4A       (*)aggr#2._gc_prev(gr28,-4)=gr4
  415| 001F38 lwz        80640000   1     L4A       gr3=<s117:d0:l4>(gr4,0)                                                                                        46| 001F78 stw        93FE0004   1     ST4A       (*)aggr#2._gc_prev(gr30,4)=gr31
  415| 001F3C addi       38E3FFFF   2     AI        gr7=gr3,-1                                                                                                      0| 001F7C lwz        83810040   1     L4A        gr28=#stack(gr1,64)
  415| 001F40 stw        90E40000   1     ST4A      <s117:d0:l4>(gr4,0)=gr7                                                                                         0| 001F80 lwz        83A10044   1     L4A        gr29=#stack(gr1,68)
  417| 001F44 cmpwi      2C000000   1     C4        cr0=gr0,0                                                                                                       0| 001F84 lwz        83C10048   1     L4A        gr30=#stack(gr1,72)
  417| 001F48 bc         41820058   1     BT        CL.1347,cr0,0x4/eq,taken=40%(40,60)                                                                             0| 001F88 lwz        83E1004C   1     L4A        gr31=#stack(gr1,76)
  419| 001F4C bc         40800034   1     BF        CL.1826,cr0,0x1/lt,taken=50%(0,0)                                                                             910| 001F8C addi       38210050   1     AI         gr1=gr1,80
  420| 001F50 ori        60C30000   1     LR        gr3=gr6                                                                                                       910| 001F90 bclr       4E800020   0     BA         lr
  420| 001F54 addi       388003FB   1     LI        gr4=1019                                                                                                        0|                                CL.2217:
  420| 001F58 bl         4BFFE0A9   0     CALL      _Py_NegativeRefcount,3,(*)Cuchar",gr3,gr4,(*)_object",gr5,#ProcAlias",_Py_NegativeRefcount",fcr",gr1,cr[015    44| 001F94 addi       386815E4   1     AI         gr3=gr8,5604
  420| 001F5C ori        60000000   1                                                                                                                              44| 001F98 addi       38881610   1     AI         gr4=gr8,5648
 1020| 001F60 ori        63E30000   1     LR        gr3=gr31                                                                                                       44| 001F9C addi       38A0002C   1     LI         gr5=44
 1020| 001F64 bl         4BFFE09D   0     CALL      PyObject_GC_Del,1,(*)void",gr3,#ProcAlias",PyObject_GC_Del",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",    44| 001FA0 bl         4BFFE061   0     CALL       __assert,3,gr3-gr5,#ProcAlias",__assert",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",lr",fcr",xer",
 1020| 001F68 ori        60000000   1                                                                                                                              44| 001FA4 ori        60000000   1
    0| 001F6C lwz        83E1003C   1     L4A       gr31=#stack(gr1,60)                                                                                             0| 001FA8 lwz        801CFFFC   1     L4A        gr0=(*)aggr#2._gc_prev(gr28,-4)
    0| 001F70 lwz        80010048   1     L4A       gr0=#stack(gr1,72)                                                                                             45| 001FAC stw        93DCFFF8   1     ST4A       (*)aggr#2._gc_next(gr28,-8)=gr30
 1021| 001F74 addi       38210040   1     AI        gr1=gr1,64                                                                                                    909| 001FB0 ori        63830000   1     LR         gr3=gr28
    0| 001F78 mtspr      7C0803A6   1     LLR       lr=gr0                                                                                                         44| 001FB4 rlwinm     540007BE   1     RN4        gr0=gr0,0,0x3
 1021| 001F7C bclr       4E800020   3     BA        lr                                                                                                             44| 001FB8 or         7C04EB78   1     O          gr4=gr0,gr29







Wed Apr 15 07:30:04 CDT 2020  Page 95


    0|                                CL.1826:                                                                                                                     44| 001FBC stw        909CFFFC   1     ST4A       (*)aggr#2._gc_prev(gr28,-4)=gr4
 1020| 001F80 ori        63E30000   1     LR        gr3=gr31                                                                                                       46| 001FC0 stw        93FE0004   1     ST4A       (*)aggr#2._gc_prev(gr30,4)=gr31
 1020| 001F84 bl         4BFFE07D   0     CALL      PyObject_GC_Del,1,(*)void",gr3,#ProcAlias",PyObject_GC_Del",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",     0| 001FC4 lwz        83810040   1     L4A        gr28=#stack(gr1,64)
 1020| 001F88 ori        60000000   1                                                                                                                               0| 001FC8 lwz        80010058   1     L4A        gr0=#stack(gr1,88)
    0| 001F8C lwz        83E1003C   1     L4A       gr31=#stack(gr1,60)                                                                                             0| 001FCC lwz        83A10044   1     L4A        gr29=#stack(gr1,68)
    0| 001F90 lwz        80010048   1     L4A       gr0=#stack(gr1,72)                                                                                              0| 001FD0 lwz        83C10048   1     L4A        gr30=#stack(gr1,72)
 1021| 001F94 addi       38210040   1     AI        gr1=gr1,64                                                                                                      0| 001FD4 mtspr      7C0803A6   1     LLR        lr=gr0
    0| 001F98 mtspr      7C0803A6   1     LLR       lr=gr0                                                                                                          0| 001FD8 lwz        83E1004C   1     L4A        gr31=#stack(gr1,76)
 1021| 001F9C bclr       4E800020   3     BA        lr                                                                                                            910| 001FDC addi       38210050   1     AI         gr1=gr1,80
  423|                                CL.1347:                                                                                                                    910| 001FE0 bclr       4E800020   1     BA         lr
  425| 001FA0 ori        60A30000   1     LR        gr3=gr5                                                                                                         0|                                CL.1925:
  425| 001FA4 bl         4BFFE05D   0     CALL      _Py_Dealloc,1,(*)_object",gr3,#ProcAlias",_Py_Dealloc",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",l    35| 001FE4 ori        63830000   1     LR         gr3=gr28
  425| 001FA8 ori        60000000   1                                                                                                                              35| 001FE8 addi       38881594   1     AI         gr4=gr8,5524
 1020| 001FAC ori        63E30000   1     LR        gr3=gr31                                                                                                       35| 001FEC addi       38A815B0   1     AI         gr5=gr8,5552
 1020| 001FB0 bl         4BFFE051   0     CALL      PyObject_GC_Del,1,(*)void",gr3,#ProcAlias",PyObject_GC_Del",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",    35| 001FF0 addi       38E0038C   1     LI         gr7=908
 1020| 001FB4 ori        60000000   1                                                                                                                              35| 001FF4 addi       39081580   1     AI         gr8=gr8,5504
    0| 001FB8 lwz        83E1003C   1     L4A       gr31=#stack(gr1,60)                                                                                            35| 001FF8 bl         4BFFE009   0     CALL       _PyObject_AssertFailed,6,(*)_object",gr3-gr5,(*)Cuchar",gr6-gr8,#ProcAlias",_PyObject_AssertFailed",fcr",g
    0| 001FBC lwz        80010048   1     L4A       gr0=#stack(gr1,72)                                                                                             35| 001FFC ori        60000000   1
 1021| 001FC0 addi       38210040   1     AI        gr1=gr1,64                                                                                                     35| 002000 tw         7C8E7008   1     TRAP       9
    0| 001FC4 mtspr      7C0803A6   1     LLR       lr=gr0                                                                                                          0|                                CL.2216:
 1021| 001FC8 bclr       4E800020   3     BA        lr                                                                                                             30| 002004 ori        63830000   1     LR         gr3=gr28
    0|                                CL.1829:                                                                                                                     30| 002008 addi       38881528   1     AI         gr4=gr8,5416
   64| 001FCC ori        63E30000   1     LR        gr3=gr31                                                                                                       30| 00200C addi       38A81550   1     AI         gr5=gr8,5456
   64| 001FD0 addi       388813E4   1     AI        gr4=gr8,5092                                                                                                   30| 002010 addi       38E0038C   1     LI         gr7=908
   64| 001FD4 addi       38A8140C   1     AI        gr5=gr8,5132                                                                                                   30| 002014 addi       39081580   1     AI         gr8=gr8,5504
   64| 001FD8 addi       38E003FA   1     LI        gr7=1018                                                                                                       30| 002018 bl         4BFFDFE9   0     CALL       _PyObject_AssertFailed,6,(*)_object",gr3-gr5,(*)Cuchar",gr6-gr8,#ProcAlias",_PyObject_AssertFailed",fcr",g
   64| 001FDC addi       39081438   1     AI        gr8=gr8,5176                                                                                                   30| 00201C ori        60000000   1
   64| 001FE0 bl         4BFFE021   0     CALL      _PyObject_AssertFailed,6,(*)_object",gr3-gr5,(*)Cuchar",gr6-gr8,#ProcAlias",_PyObject_AssertFailed",fcr",gr    30| 002020 tw         7C8E7008   1     TRAP       9
   64| 001FE4 ori        60000000   1                                                                                                                               0|                                CL.1923:
   64| 001FE8 tw         7C8E7008   1     TRAP      9                                                                                                             904| 002024 addi       38600000   1     LI         gr3=0
     | 001FEC b          48000000   0                                                                                                                               0| 002028 lwz        80010058   1     L4A        gr0=#stack(gr1,88)
     |               Tag Table                                                                                                                                      0| 00202C lwz        83E1004C   1     L4A        gr31=#stack(gr1,76)
     | 001FF0        00000000 00002041 80010100 00000000 00000130 0014636F                                                                                        910| 002030 addi       38210050   1     AI         gr1=gr1,80
     | 002008        726F5F77 72617070 65725F64 65616C6C 6F63                                                                                                       0| 002034 mtspr      7C0803A6   1     LLR        lr=gr0
     |               Instruction count           76                                                                                                               910| 002038 bclr       4E800020   3     BA         lr
     |               Straight-line exec time     80                                                                                                                  |               Tag Table
 GPR's set/used:   ssus ssss ssss s---  ---- ---- ---- ----                                                                                                          | 00203C        00000000 00002041 80040100 00000000 0000017C 000A636F
 FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----                                                                                                          | 002054        726F5F61 77616974
 CCR's set/used:   ss-- -sss                                                                                                                                         |               Instruction count           95
     | 000000                             PDEF     coro_get_cr_await                                                                                                 |               Straight-line exec time    100
  913|                                    PROC      coro,_unused_ignored,gr3,gr4                                                                                 GPR's set/used:   ssus ssss ssss s---  ---- ---- ---- ----
    0| 002020 mfspr      7C0802A6   1     LFLR      gr0=lr                                                                                                       FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----
    0| 002024 stw        90010008   2     ST4A      #stack(gr1,8)=gr0                                                                                            CCR's set/used:   ss-- -sss
    0| 002028 stwu       9421FFC0   1     ST4U      gr1,#stack(gr1,-64)=gr1                                                                                          | 000000                             PDEF       coro_repr
  915| 00202C bl         480039D5   0     CALL      gr3=_PyGen_yf,1,(*)aggr#3",gr3,#ProcAlias",_PyGen_yf",fcr",gr1,cr[01567]",gr0",gr4"-gr12",fp0"-fp13",mq",lr   893|                                    PROC       coro,gr3
  916| 002030 cmpwi      2C030000   1     C4        cr0=gr3,0                                                                                                       0| 002060 mfspr      7C0802A6   1     LFLR       gr0=lr
  401| 002034 lwz        80820004   1     L4A       gr4=._Py_RefTotal(gr2,0)                                                                                      895| 002064 lwz        8083001C   1     L4A        gr4=(*)aggr#6.cr_qualname(gr3,28)
  916| 002038 bc         40820030   0     BF        CL.2177,cr0,0x4/eq,taken=50%(0,0)                                                                               0| 002068 stwu       9421FFC0   1     ST4U       gr1,#stack(gr1,-64)=gr1
  917| 00203C lwz        80620008   2     L4A       gr3=._Py_NoneStruct(gr2,0)                                                                                    895| 00206C ori        60650000   1     LR         gr5=gr3
  401| 002040 lwz        80A40000   1     L4A       gr5=<s117:d0:l4>(gr4,0)                                                                                       895| 002070 lwz        80620018   1     L4A        gr3=.+CONSTANT_AREA(gr2,0)
  403| 002044 lwz        80C30000   1     L4A       gr6=<s119:d0:l4>(gr3,0)                                                                                       895| 002074 addi       38631658   2     AI         gr3=gr3,5720
    0| 002048 lwz        80010048   1     L4A       gr0=#stack(gr1,72)                                                                                              0| 002078 stw        90010048   1     ST4A       #stack(gr1,72)=gr0
  919| 00204C addi       38210040   1     AI        gr1=gr1,64                                                                                                    895| 00207C bl         4BFFDF85   0     CALL       gr3=PyUnicode_FromFormat,3,gr3,(*)_object",gr4,(*)aggr#6",gr5,#ProcAlias",PyUnicode_FromFormat",fcr",gr1,c
    0| 002050 mtspr      7C0803A6   1     LLR       lr=gr0                                                                                                        895| 002080 ori        60000000   1
  401| 002054 addi       38050001   1     AI        gr0=gr5,1                                                                                                       0| 002084 lwz        80010048   1     L4A        gr0=#stack(gr1,72)
  401| 002058 stw        90040000   1     ST4A      <s117:d0:l4>(gr4,0)=gr0                                                                                       897| 002088 addi       38210040   1     AI         gr1=gr1,64







Wed Apr 15 07:30:04 CDT 2020  Page 96


  403| 00205C addi       38860001   1     AI        gr4=gr6,1                                                                                                       0| 00208C mtspr      7C0803A6   1     LLR        lr=gr0
  403| 002060 stw        90830000   1     ST4A      <s119:d0:l4>(gr3,0)=gr4                                                                                       897| 002090 bclr       4E800020   3     BA         lr
  919| 002064 bclr       4E800020   0     BA        lr                                                                                                               |               Tag Table
    0|                                CL.2177:                                                                                                                       | 002094        00000000 00002041 80000100 00000000 00000034 0009636F
    0| 002068 lwz        80010048   1     L4A       gr0=#stack(gr1,72)                                                                                               | 0020AC        726F5F72 657072
  919| 00206C addi       38210040   1     AI        gr1=gr1,64                                                                                                       |               Instruction count           13
    0| 002070 mtspr      7C0803A6   1     LLR       lr=gr0                                                                                                           |               Straight-line exec time     15
  919| 002074 bclr       4E800020   3     BA        lr                                                                                                           GPR's set/used:   ssus ssss ssss s---  ---- ---- ---- ssss
     |               Tag Table                                                                                                                                   FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----
     | 002078        00000000 00002041 80000200 00000000 00000058 0011636F                                                                                       CCR's set/used:   ss-- -sss
     | 002090        726F5F67 65745F63 725F6177 616974                                                                                                               | 000000                             PDEF       gen_new_with_qualname
     |               Instruction count           22                                                                                                               779|                                    PROC       type,f,name,qualname,gr3-gr6
     |               Straight-line exec time     23                                                                                                                 0| 0020C0 mfspr      7C0802A6   1     LFLR       gr0=lr
 GPR's set/used:   ssus ssss ssss s---  ---- ---- ---- ssss                                                                                                         0| 0020C4 stwu       9421FFB0   1     ST4U       gr1,#stack(gr1,-80)=gr1
 FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----                                                                                                         0| 0020C8 stw        90010058   1     ST4A       #stack(gr1,88)=gr0
 CCR's set/used:   ss-- -sss                                                                                                                                        0| 0020CC stw        93E1004C   1     ST4A       #stack(gr1,76)=gr31
     | 000000                             PDEF     coro_await                                                                                                       0| 0020D0 ori        609F0000   1     LR         gr31=gr4
  900|                                    PROC      coro,gr3                                                                                                        0| 0020D4 stw        93C10048   1     ST4A       #stack(gr1,72)=gr30
    0| 0020A0 mfspr      7C0802A6   1     LFLR      gr0=lr                                                                                                          0| 0020D8 stw        93A10044   1     ST4A       #stack(gr1,68)=gr29
    0| 0020A4 stw        90010008   2     ST4A      #stack(gr1,8)=gr0                                                                                               0| 0020DC ori        60BE0000   1     LR         gr30=gr5
    0| 0020A8 stw        93E1FFFC   1     ST4A      #stack(gr1,-4)=gr31                                                                                             0| 0020E0 ori        60DD0000   1     LR         gr29=gr6
    0| 0020AC ori        607F0000   1     LR        gr31=gr3                                                                                                        0| 0020E4 stw        93810040   1     ST4A       #stack(gr1,64)=gr28
    0| 0020B0 stw        93C1FFF8   1     ST4A      #stack(gr1,-8)=gr30                                                                                           782| 0020E8 bl         4BFFDF19   0     CALL       gr3=_PyObject_GC_New,1,(*)_typeobject",gr3,#ProcAlias",_PyObject_GC_New",fcr",gr1,cr[01567]",gr0",gr4"-gr1
    0| 0020B4 stw        93A1FFF4   1     ST4A      #stack(gr1,-12)=gr29                                                                                          782| 0020EC ori        60000000   1
    0| 0020B8 stw        9381FFF0   1     ST4A      #stack(gr1,-16)=gr28                                                                                          783| 0020F0 cmpwi      2C030000   1     C4         cr0=gr3,0
  902| 0020BC lwz        806200A0   1     L4A       gr3=._PyCoroWrapper_Type(gr2,0)                                                                                 0| 0020F4 lwz        80820004   1     L4A        gr4=._Py_RefTotal(gr2,0)
    0| 0020C0 stwu       9421FFB0   1     ST4U      gr1,#stack(gr1,-80)=gr1                                                                                         0| 0020F8 lwz        80A40000   2     L4A        gr5=_Py_RefTotal(gr4,0)
  902| 0020C4 bl         4BFFDF3D   0     CALL      gr3=_PyObject_GC_New,1,(*)_typeobject",gr3,#ProcAlias",_PyObject_GC_New",fcr",gr1,cr[01567]",gr0",gr4"-gr12   783| 0020FC bc         41820224   0     BT         CL.1957,cr0,0x4/eq,taken=50%(0,0)
  902| 0020C8 ori        60000000   1                                                                                                                             783| 002100 ori        607C0000   1     LR         gr28=gr3
  903| 0020CC cmpwi      2C030000   1     C4        cr0=gr3,0                                                                                                     789| 002104 lwz        807F0010   1     L4A        gr3=(*)_frame._frame.f_code(gr31,16)
  903| 0020D0 bc         41820134   1     BT        CL.1834,cr0,0x4/eq,taken=30%(30,70)                                                                           791| 002108 addi       38000000   1     LI         gr0=0
  401| 0020D4 lwz        80820004   2     L4A       gr4=._Py_RefTotal(gr2,0)                                                                                      797| 00210C cmpwi      2C1E0000   1     C4         cr0=gr30,0
    0| 0020D8 lwz        81020018   1     L4A       gr8=.+CONSTANT_AREA(gr2,0)                                                                                      0| 002110 addi       38A50002   1     AI         gr5=gr5,2
  902| 0020DC ori        607C0000   1     LR        gr28=gr3                                                                                                        0| 002114 cmpwi      2C9D0000   1     C4         cr1=gr29,0
  403| 0020E0 lwz        807F0000   1     L4A       gr3=(*)_object._object.ob_refcnt(gr31,0)                                                                      788| 002118 stw        939F0030   1     ST4A       (*)_frame._frame.f_gen(gr31,48)=gr28
   27| 0020E4 addi       38C81110   1     AI        gr6=gr8,4368                                                                                                  787| 00211C stw        93FC0008   1     ST4A       (*)aggr#3.gi_frame(gr28,8)=gr31
  403| 0020E8 addi       38A30001   1     AI        gr5=gr3,1                                                                                                     790| 002120 stw        907C0010   1     ST4A       (*)aggr#3.gi_code(gr28,16)=gr3
  403| 0020EC stw        90BF0000   1     ST4A      (*)_object._object.ob_refcnt(gr31,0)=gr5                                                                      791| 002124 stb        981C000C   1     ST1Z       (*)aggr#3.gi_running(gr28,12)=gr0
  401| 0020F0 lwz        80640000   1     L4A       gr3=<s117:d0:l4>(gr4,0)                                                                                       403| 002128 lwz        80C30000   1     L4A        gr6=(*)_object._object.ob_refcnt(gr3,0)
  907| 0020F4 stw        93FC0008   1     ST4A      (*)aggr#A.cw_coroutine(gr28,8)=gr31                                                                           792| 00212C stw        901C0014   1     ST4A       (*)aggr#3.gi_weakreflist(gr28,20)=gr0
  401| 0020F8 addi       38630001   1     AI        gr3=gr3,1                                                                                                     793| 002130 stw        901C0020   1     ST4A       (*)aggr#3._err_stackitem.exc_type(gr28,32)=gr0
  401| 0020FC stw        90640000   1     ST4A      <s117:d0:l4>(gr4,0)=gr3                                                                                       794| 002134 stw        901C0024   1     ST4A       (*)aggr#3._err_stackitem.exc_value(gr28,36)=gr0
    0| 002100 lwz        80010058   1     L4A       gr0=#stack(gr1,88)                                                                                            403| 002138 addi       38C60001   1     AI         gr6=gr6,1
    0| 002104 mtspr      7C0803A6   2     LLR       lr=gr0                                                                                                        403| 00213C stw        90C30000   1     ST4A       (*)_object._object.ob_refcnt(gr3,0)=gr6
   30| 002108 lwz        801CFFF8   1     L4A       gr0=(*)_object%##2(gr28,-8)                                                                                   795| 002140 stw        901C0028   1     ST4A       (*)aggr#3._err_stackitem.exc_traceback(gr28,40)=gr0
   30| 00210C cmpwi      2C000000   2     C4        cr0=gr0,0                                                                                                     796| 002144 stw        901C002C   1     ST4A       (*)aggr#3._err_stackitem.previous_item(gr28,44)=gr0
   30| 002110 bc         408200D4   1     BF        CL.2175,cr0,0x4/eq,taken=10%(10,90)                                                                           797| 002148 bc         41820164   0     BT         CL.198,cr0,0x4/eq,taken=50%(0,0)
   34| 002114 addi       3BFCFFF8   1     AI        gr31=gr28,-8                                                                                                  798| 00214C stw        93DC0018   2     ST4A       (*)aggr#3.gi_name(gr28,24)=gr30
   35| 002118 lwz        801CFFFC   1     L4A       gr0=(*)aggr#2._gc_prev(gr28,-4)                                                                               403| 002150 lwz        807E0000   1     L4A        gr3=(*)_object._object.ob_refcnt(gr30,0)
   35| 00211C andi.      70030002   2     RN4_R     gr3,cr0=gr0,0,0x2                                                                                             403| 002154 addi       38630001   2     AI         gr3=gr3,1
   35| 002120 bc         408200A4   1     BF        CL.1836,cr0,0x4/eq,taken=10%(10,90)                                                                           403| 002158 stw        907E0000   1     ST4A       (*)_object._object.ob_refcnt(gr30,0)=gr3
   67| 002124 lwz        808200A4   1     L4A       gr4=._PyRuntime(gr2,0)                                                                                        802| 00215C bc         40860104   0     BF         CL.1640,cr1,0x4/eq,taken=50%(0,0)
   54| 002128 lwz        806401A0   2     L4A       gr3=<s149:d416:l4>(gr4,416)                                                                                   805| 002160 stw        93DC001C   1     ST4A       (*)aggr#3.gi_qualname(gr28,28)=gr30
   41| 00212C lwz        80630008   2     L4A       gr3=(*)_ts._ts.interp(gr3,8)                                                                                  403| 002164 addi       38030001   1     AI         gr0=gr3,1
   41| 002130 lwz        83C30188   2     L4A       gr30=(*)_is._gc_runtime_state.generation0(gr3,392)                                                            401| 002168 addi       38A50001   1     AI         gr5=gr5,1
   42| 002134 lwz        83BE0004   2     L4A       gr29=(*)aggr#2._gc_prev(gr30,4)                                                                               401| 00216C stw        90A40000   1     ST4A       _Py_RefTotal(gr4,0)=gr5







Wed Apr 15 07:30:04 CDT 2020  Page 97


   44| 002138 andi.      73A30003   2     RN4_R     gr3,cr0=gr29,0,0xFFFFFFFF00000003                                                                             403| 002170 stw        901E0000   1     ST4A       (*)_object._object.ob_refcnt(gr30,0)=gr0
   43| 00213C stw        93FD0000   1     ST4A      (*)aggr#2._gc_next(gr29,0)=gr31                                                                                 0| 002174 lwz        81020018   1     L4A        gr8=.+CONSTANT_AREA(gr2,0)
   44| 002140 bc         40820034   0     BF        CL.2176,cr0,0x4/eq,taken=40%(40,60)                                                                            30| 002178 lwz        807CFFF8   1     L4A        gr3=(*)_object%##2(gr28,-8)
   44| 002144 rlwinm     540007BE   1     RN4       gr0=gr0,0,0x3                                                                                                  27| 00217C addi       38C81110   1     AI         gr6=gr8,4368
   45| 002148 stw        93DCFFF8   1     ST4A      (*)aggr#2._gc_next(gr28,-8)=gr30                                                                               30| 002180 cmpwi      2C030000   1     C4         cr0=gr3,0
   44| 00214C or         7C04EB78   1     O         gr4=gr0,gr29                                                                                                   30| 002184 bc         40820108   1     BF         CL.1639,cr0,0x4/eq,taken=50%(0,0)
  909| 002150 ori        63830000   1     LR        gr3=gr28                                                                                                       30|                                CL.745:
   44| 002154 stw        909CFFFC   1     ST4A      (*)aggr#2._gc_prev(gr28,-4)=gr4                                                                                34| 002188 addi       3BFCFFF8   1     AI         gr31=gr28,-8
   46| 002158 stw        93FE0004   1     ST4A      (*)aggr#2._gc_prev(gr30,4)=gr31                                                                                35| 00218C lwz        801CFFFC   1     L4A        gr0=(*)aggr#2._gc_prev(gr28,-4)
    0| 00215C lwz        83810040   1     L4A       gr28=#stack(gr1,64)                                                                                            35| 002190 andi.      70030002   2     RN4_R      gr3,cr0=gr0,0,0x2
    0| 002160 lwz        83A10044   1     L4A       gr29=#stack(gr1,68)                                                                                            35| 002194 bc         408200AC   1     BF         CL.1960,cr0,0x4/eq,taken=10%(10,90)
    0| 002164 lwz        83C10048   1     L4A       gr30=#stack(gr1,72)                                                                                            67| 002198 lwz        808200A4   1     L4A        gr4=._PyRuntime(gr2,0)
    0| 002168 lwz        83E1004C   1     L4A       gr31=#stack(gr1,76)                                                                                            54| 00219C lwz        806401A0   2     L4A        gr3=(*)pyruntimestate._Py_atomic_address._value(gr4,416)
  910| 00216C addi       38210050   1     AI        gr1=gr1,80                                                                                                     41| 0021A0 lwz        80630008   2     L4A        gr3=(*)_ts._ts.interp(gr3,8)
  910| 002170 bclr       4E800020   0     BA        lr                                                                                                             41| 0021A4 lwz        83C30188   2     L4A        gr30=(*)_is._gc_runtime_state.generation0(gr3,392)
    0|                                CL.2176:                                                                                                                     42| 0021A8 lwz        83BE0004   2     L4A        gr29=(*)aggr#2._gc_prev(gr30,4)
   44| 002174 addi       386815E4   1     AI        gr3=gr8,5604                                                                                                   44| 0021AC andi.      73A30003   2     RN4_R      gr3,cr0=gr29,0,0xFFFFFFFF00000003
   44| 002178 addi       38881610   1     AI        gr4=gr8,5648                                                                                                   43| 0021B0 stw        93FD0000   1     ST4A       (*)aggr#2._gc_next(gr29,0)=gr31
   44| 00217C addi       38A0002C   1     LI        gr5=44                                                                                                         44| 0021B4 bc         4082003C   0     BF         CL.2038,cr0,0x4/eq,taken=40%(40,60)
   44| 002180 bl         4BFFDE81   0     CALL      __assert,3,gr3-gr5,#ProcAlias",__assert",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",lr",fcr",xer",f    44| 0021B8 rlwinm     540007BE   1     RN4        gr0=gr0,0,0x3
   44| 002184 ori        60000000   1                                                                                                                              45| 0021BC stw        93DCFFF8   1     ST4A       (*)aggr#2._gc_next(gr28,-8)=gr30
    0| 002188 lwz        801CFFFC   1     L4A       gr0=(*)aggr#2._gc_prev(gr28,-4)                                                                                44| 0021C0 or         7C04EB78   1     O          gr4=gr0,gr29
   45| 00218C stw        93DCFFF8   1     ST4A      (*)aggr#2._gc_next(gr28,-8)=gr30                                                                              808| 0021C4 ori        63830000   1     LR         gr3=gr28
  909| 002190 ori        63830000   1     LR        gr3=gr28                                                                                                       44| 0021C8 stw        909CFFFC   1     ST4A       (*)aggr#2._gc_prev(gr28,-4)=gr4
   44| 002194 rlwinm     540007BE   1     RN4       gr0=gr0,0,0x3                                                                                                  46| 0021CC stw        93FE0004   1     ST4A       (*)aggr#2._gc_prev(gr30,4)=gr31
   44| 002198 or         7C04EB78   1     O         gr4=gr0,gr29                                                                                                    0| 0021D0 lwz        83810040   1     L4A        gr28=#stack(gr1,64)
   44| 00219C stw        909CFFFC   1     ST4A      (*)aggr#2._gc_prev(gr28,-4)=gr4                                                                                 0| 0021D4 lwz        83A10044   1     L4A        gr29=#stack(gr1,68)
   46| 0021A0 stw        93FE0004   1     ST4A      (*)aggr#2._gc_prev(gr30,4)=gr31                                                                                 0| 0021D8 lwz        80010058   1     L4A        gr0=#stack(gr1,88)
    0| 0021A4 lwz        83810040   1     L4A       gr28=#stack(gr1,64)                                                                                             0| 0021DC lwz        83C10048   1     L4A        gr30=#stack(gr1,72)
    0| 0021A8 lwz        80010058   1     L4A       gr0=#stack(gr1,88)                                                                                              0| 0021E0 lwz        83E1004C   1     L4A        gr31=#stack(gr1,76)
    0| 0021AC lwz        83A10044   1     L4A       gr29=#stack(gr1,68)                                                                                           809| 0021E4 addi       38210050   1     AI         gr1=gr1,80
    0| 0021B0 lwz        83C10048   1     L4A       gr30=#stack(gr1,72)                                                                                             0| 0021E8 mtspr      7C0803A6   1     LLR        lr=gr0
    0| 0021B4 mtspr      7C0803A6   1     LLR       lr=gr0                                                                                                        809| 0021EC bclr       4E800020   3     BA         lr
    0| 0021B8 lwz        83E1004C   1     L4A       gr31=#stack(gr1,76)                                                                                             0|                                CL.2038:
  910| 0021BC addi       38210050   1     AI        gr1=gr1,80                                                                                                     44| 0021F0 addi       386815E4   1     AI         gr3=gr8,5604
  910| 0021C0 bclr       4E800020   1     BA        lr                                                                                                             44| 0021F4 addi       38881610   1     AI         gr4=gr8,5648
    0|                                CL.1836:                                                                                                                     44| 0021F8 addi       38A0002C   1     LI         gr5=44
   35| 0021C4 ori        63830000   1     LR        gr3=gr28                                                                                                       44| 0021FC bl         4BFFDE05   0     CALL       __assert,3,gr3-gr5,#ProcAlias",__assert",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",lr",fcr",xer",
   35| 0021C8 addi       38881594   1     AI        gr4=gr8,5524                                                                                                   44| 002200 ori        60000000   1
   35| 0021CC addi       38A815B0   1     AI        gr5=gr8,5552                                                                                                    0| 002204 lwz        801CFFFC   1     L4A        gr0=(*)aggr#2._gc_prev(gr28,-4)
   35| 0021D0 addi       38E0038C   1     LI        gr7=908                                                                                                        45| 002208 stw        93DCFFF8   1     ST4A       (*)aggr#2._gc_next(gr28,-8)=gr30
   35| 0021D4 addi       39081580   1     AI        gr8=gr8,5504                                                                                                  808| 00220C ori        63830000   1     LR         gr3=gr28
   35| 0021D8 bl         4BFFDE29   0     CALL      _PyObject_AssertFailed,6,(*)_object",gr3-gr5,(*)Cuchar",gr6-gr8,#ProcAlias",_PyObject_AssertFailed",fcr",gr    44| 002210 rlwinm     540007BE   1     RN4        gr0=gr0,0,0x3
   35| 0021DC ori        60000000   1                                                                                                                              44| 002214 or         7C04EB78   1     O          gr4=gr0,gr29
   35| 0021E0 tw         7C8E7008   1     TRAP      9                                                                                                              44| 002218 stw        909CFFFC   1     ST4A       (*)aggr#2._gc_prev(gr28,-4)=gr4
    0|                                CL.2175:                                                                                                                     46| 00221C stw        93FE0004   1     ST4A       (*)aggr#2._gc_prev(gr30,4)=gr31
   30| 0021E4 ori        63830000   1     LR        gr3=gr28                                                                                                        0| 002220 lwz        83810040   1     L4A        gr28=#stack(gr1,64)
   30| 0021E8 addi       38881528   1     AI        gr4=gr8,5416                                                                                                    0| 002224 lwz        83A10044   1     L4A        gr29=#stack(gr1,68)
   30| 0021EC addi       38A81550   1     AI        gr5=gr8,5456                                                                                                    0| 002228 lwz        80010058   1     L4A        gr0=#stack(gr1,88)
   30| 0021F0 addi       38E0038C   1     LI        gr7=908                                                                                                         0| 00222C lwz        83C10048   1     L4A        gr30=#stack(gr1,72)
   30| 0021F4 addi       39081580   1     AI        gr8=gr8,5504                                                                                                    0| 002230 lwz        83E1004C   1     L4A        gr31=#stack(gr1,76)
   30| 0021F8 bl         4BFFDE09   0     CALL      _PyObject_AssertFailed,6,(*)_object",gr3-gr5,(*)Cuchar",gr6-gr8,#ProcAlias",_PyObject_AssertFailed",fcr",gr   809| 002234 addi       38210050   1     AI         gr1=gr1,80
   30| 0021FC ori        60000000   1                                                                                                                               0| 002238 mtspr      7C0803A6   1     LLR        lr=gr0
   30| 002200 tw         7C8E7008   1     TRAP      9                                                                                                             809| 00223C bclr       4E800020   3     BA         lr
    0|                                CL.1834:                                                                                                                      0|                                CL.1960:
  904| 002204 addi       38600000   1     LI        gr3=0                                                                                                          35| 002240 ori        63830000   1     LR         gr3=gr28







Wed Apr 15 07:30:04 CDT 2020  Page 98


    0| 002208 lwz        80010058   1     L4A       gr0=#stack(gr1,88)                                                                                             35| 002244 addi       38881594   1     AI         gr4=gr8,5524
    0| 00220C lwz        83E1004C   1     L4A       gr31=#stack(gr1,76)                                                                                            35| 002248 addi       38A815B0   1     AI         gr5=gr8,5552
  910| 002210 addi       38210050   1     AI        gr1=gr1,80                                                                                                     35| 00224C addi       38E00327   1     LI         gr7=807
    0| 002214 mtspr      7C0803A6   1     LLR       lr=gr0                                                                                                         35| 002250 addi       39081580   1     AI         gr8=gr8,5504
  910| 002218 bclr       4E800020   3     BA        lr                                                                                                             35| 002254 bl         4BFFDDAD   0     CALL       _PyObject_AssertFailed,6,(*)_object",gr3-gr5,(*)Cuchar",gr6-gr8,#ProcAlias",_PyObject_AssertFailed",fcr",g
     |               Tag Table                                                                                                                                     35| 002258 ori        60000000   1
     | 00221C        00000000 00002041 80040100 00000000 0000017C 000A636F                                                                                         35| 00225C tw         7C8E7008   1     TRAP       9
     | 002234        726F5F61 77616974                                                                                                                              0|                                CL.1640:
     |               Instruction count           95                                                                                                               803| 002260 stw        93BC001C   1     ST4A       (*)aggr#3.gi_qualname(gr28,28)=gr29
     |               Straight-line exec time    101                                                                                                               401| 002264 addi       38A50001   1     AI         gr5=gr5,1
 GPR's set/used:   ssus ssss ssss s---  ---- ---- ---- ----                                                                                                       401| 002268 stw        90A40000   1     ST4A       _Py_RefTotal(gr4,0)=gr5
 FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----                                                                                                       403| 00226C lwz        807D0000   1     L4A        gr3=(*)_object._object.ob_refcnt(gr29,0)
 CCR's set/used:   ss-- -sss                                                                                                                                       30| 002270 lwz        801CFFF8   1     L4A        gr0=(*)_object%##2(gr28,-8)
     | 000000                             PDEF     coro_repr                                                                                                        0| 002274 lwz        81020018   1     L4A        gr8=.+CONSTANT_AREA(gr2,0)
  893|                                    PROC      coro,gr3                                                                                                      403| 002278 addi       38630001   1     AI         gr3=gr3,1
    0| 002240 mfspr      7C0802A6   1     LFLR      gr0=lr                                                                                                        403| 00227C stw        907D0000   1     ST4A       (*)_object._object.ob_refcnt(gr29,0)=gr3
  895| 002244 lwz        8083001C   1     L4A       gr4=(*)aggr#6.cr_qualname(gr3,28)                                                                              30| 002280 cmpwi      2C000000   1     C4         cr0=gr0,0
  895| 002248 ori        60650000   1     LR        gr5=gr3                                                                                                        27| 002284 addi       38C81110   1     AI         gr6=gr8,4368
  895| 00224C lwz        80620018   1     L4A       gr3=.+CONSTANT_AREA(gr2,0)                                                                                     30| 002288 bc         4182FF00   0     BT         CL.745,cr0,0x4/eq,taken=50%(0,0)
  895| 002250 addi       38631658   2     AI        gr3=gr3,5720                                                                                                    0|                                CL.1639:
    0| 002254 stw        90010008   1     ST4A      #stack(gr1,8)=gr0                                                                                              30| 00228C ori        63830000   1     LR         gr3=gr28
    0| 002258 stwu       9421FFC0   1     ST4U      gr1,#stack(gr1,-64)=gr1                                                                                        30| 002290 addi       38881528   1     AI         gr4=gr8,5416
  895| 00225C bl         4BFFDDA5   0     CALL      gr3=PyUnicode_FromFormat,3,gr3,(*)_object",gr4,(*)aggr#6",gr5,#ProcAlias",PyUnicode_FromFormat",fcr",gr1,cr    30| 002294 addi       38A81550   1     AI         gr5=gr8,5456
  895| 002260 ori        60000000   1                                                                                                                              30| 002298 addi       38E00327   1     LI         gr7=807
    0| 002264 lwz        80010048   1     L4A       gr0=#stack(gr1,72)                                                                                             30| 00229C addi       39081580   1     AI         gr8=gr8,5504
  897| 002268 addi       38210040   1     AI        gr1=gr1,64                                                                                                     30| 0022A0 bl         4BFFDD61   0     CALL       _PyObject_AssertFailed,6,(*)_object",gr3-gr5,(*)Cuchar",gr6-gr8,#ProcAlias",_PyObject_AssertFailed",fcr",g
    0| 00226C mtspr      7C0803A6   1     LLR       lr=gr0                                                                                                         30| 0022A4 ori        60000000   1
  897| 002270 bclr       4E800020   3     BA        lr                                                                                                             30| 0022A8 tw         7C8E7008   1     TRAP       9
     |               Tag Table                                                                                                                                    798|                                CL.198:
     | 002274        00000000 00002041 80000100 00000000 00000034 0009636F                                                                                        800| 0022AC lwz        80630044   1     L4A        gr3=(*)aggr#5.co_name(gr3,68)
     | 00228C        726F5F72 657072                                                                                                                              800| 0022B0 stw        907C0018   2     ST4A       (*)aggr#3.gi_name(gr28,24)=gr3
     |               Instruction count           13                                                                                                               403| 0022B4 lwz        80C30000   1     L4A        gr6=(*)_object._object.ob_refcnt(gr3,0)
     |               Straight-line exec time     15                                                                                                               403| 0022B8 addi       38C60001   2     AI         gr6=gr6,1
 GPR's set/used:   ssus ssss ssss s---  ---- ---- ---- ssss                                                                                                       403| 0022BC stw        90C30000   1     ST4A       (*)_object._object.ob_refcnt(gr3,0)=gr6
 FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----                                                                                                       802| 0022C0 bc         41860034   0     BT         CL.1948,cr1,0x4/eq,taken=50%(0,0)
 CCR's set/used:   ss-- -sss                                                                                                                                      803| 0022C4 stw        93BC001C   1     ST4A       (*)aggr#3.gi_qualname(gr28,28)=gr29
     | 000000                             PDEF     gen_new_with_qualname                                                                                          403| 0022C8 lwz        807D0000   1     L4A        gr3=(*)_object._object.ob_refcnt(gr29,0)
  779|                                    PROC      type,f,name,qualname,gr3-gr6                                                                                  401| 0022CC addi       38A50001   1     AI         gr5=gr5,1
    0| 0022A0 mfspr      7C0802A6   1     LFLR      gr0=lr                                                                                                         30| 0022D0 lwz        801CFFF8   1     L4A        gr0=(*)_object%##2(gr28,-8)
    0| 0022A4 stw        90010008   2     ST4A      #stack(gr1,8)=gr0                                                                                             401| 0022D4 stw        90A40000   1     ST4A       _Py_RefTotal(gr4,0)=gr5
    0| 0022A8 stw        93E1FFFC   1     ST4A      #stack(gr1,-4)=gr31                                                                                             0| 0022D8 lwz        81020018   1     L4A        gr8=.+CONSTANT_AREA(gr2,0)
    0| 0022AC ori        609F0000   1     LR        gr31=gr4                                                                                                      403| 0022DC addi       38630001   1     AI         gr3=gr3,1
    0| 0022B0 stw        93C1FFF8   1     ST4A      #stack(gr1,-8)=gr30                                                                                           403| 0022E0 stw        907D0000   1     ST4A       (*)_object._object.ob_refcnt(gr29,0)=gr3
    0| 0022B4 stw        93A1FFF4   1     ST4A      #stack(gr1,-12)=gr29                                                                                           30| 0022E4 cmpwi      2C000000   1     C4         cr0=gr0,0
    0| 0022B8 ori        60BE0000   1     LR        gr30=gr5                                                                                                       27| 0022E8 addi       38C81110   1     AI         gr6=gr8,4368
    0| 0022BC ori        60DD0000   1     LR        gr29=gr6                                                                                                       30| 0022EC bc         4082FFA0   0     BF         CL.1639,cr0,0x4/eq,taken=10%(10,90)
    0| 0022C0 stw        9381FFF0   1     ST4A      #stack(gr1,-16)=gr28                                                                                           30| 0022F0 b          4BFFFE98   0     B          CL.745,-1
    0| 0022C4 stwu       9421FFB0   1     ST4U      gr1,#stack(gr1,-80)=gr1                                                                                         0|                                CL.1948:
  782| 0022C8 bl         4BFFDD39   0     CALL      gr3=_PyObject_GC_New,1,(*)_typeobject",gr3,#ProcAlias",_PyObject_GC_New",fcr",gr1,cr[01567]",gr0",gr4"-gr12   805| 0022F4 stw        907C001C   1     ST4A       (*)aggr#3.gi_qualname(gr28,28)=gr3
  782| 0022CC ori        60000000   1                                                                                                                             401| 0022F8 addi       38050001   1     AI         gr0=gr5,1
  783| 0022D0 cmpwi      2C030000   1     C4        cr0=gr3,0                                                                                                     401| 0022FC stw        90040000   1     ST4A       _Py_RefTotal(gr4,0)=gr0
    0| 0022D4 lwz        80820004   1     L4A       gr4=._Py_RefTotal(gr2,0)                                                                                      403| 002300 addi       38A60001   1     AI         gr5=gr6,1
    0| 0022D8 lwz        80A40000   2     L4A       gr5=<s117:d0:l4>(gr4,0)                                                                                         0| 002304 lwz        81020018   1     L4A        gr8=.+CONSTANT_AREA(gr2,0)
  783| 0022DC bc         41820228   0     BT        CL.1874,cr0,0x4/eq,taken=50%(0,0)                                                                              30| 002308 lwz        809CFFF8   1     L4A        gr4=(*)_object%##2(gr28,-8)
  782| 0022E0 ori        607C0000   1     LR        gr28=gr3                                                                                                      403| 00230C stw        90A30000   1     ST4A       (*)_object._object.ob_refcnt(gr3,0)=gr5
  789| 0022E4 lwz        807F0010   1     L4A       gr3=(*)_frame._frame.f_code(gr31,16)                                                                           27| 002310 addi       38C81110   1     AI         gr6=gr8,4368







Wed Apr 15 07:30:04 CDT 2020  Page 99


  791| 0022E8 addi       38000000   1     LI        gr0=0                                                                                                          30| 002314 cmpwi      2C040000   1     C4         cr0=gr4,0
  797| 0022EC cmpwi      2C1E0000   1     C4        cr0=gr30,0                                                                                                     30| 002318 bc         4082FF74   1     BF         CL.1639,cr0,0x4/eq,taken=10%(10,90)
    0| 0022F0 addi       38A50002   1     AI        gr5=gr5,2                                                                                                       0| 00231C b          4BFFFE6C   1     B          CL.745,-1
    0| 0022F4 cmpwi      2C9D0000   1     C4        cr1=gr29,0                                                                                                      0|                                CL.1957:
  788| 0022F8 stw        939F0030   1     ST4A      (*)_frame._frame.f_gen(gr31,48)=gr28                                                                            0| 002320 lwz        80620018   1     L4A        gr3=.+CONSTANT_AREA(gr2,0)
  787| 0022FC stw        93FC0008   1     ST4A      (*)aggr#3.gi_frame(gr28,8)=gr31                                                                               415| 002324 addi       3805FFFF   1     AI         gr0=gr5,-1
  790| 002300 stw        907C0010   1     ST4A      (*)aggr#3.gi_code(gr28,16)=gr3                                                                                417| 002328 lwz        80BF0000   1     L4A        gr5=(*)_object._object.ob_refcnt(gr31,0)
  791| 002304 stb        981C000C   1     ST1Z      (*)aggr#3.gi_running(gr28,12)=gr0                                                                             415| 00232C stw        90040000   1     ST4A       _Py_RefTotal(gr4,0)=gr0
  403| 002308 lwz        80C30000   1     L4A       gr6=(*)_object._object.ob_refcnt(gr3,0)                                                                       408| 002330 addi       38631110   1     AI         gr3=gr3,4368
  792| 00230C stw        901C0014   1     ST4A      (*)aggr#3.gi_weakreflist(gr28,20)=gr0                                                                         417| 002334 addi       3805FFFF   1     AI         gr0=gr5,-1
  793| 002310 stw        901C0020   1     ST4A      (*)aggr#3._err_stackitem.exc_type(gr28,32)=gr0                                                                417| 002338 stw        901F0000   1     ST4A       (*)_object._object.ob_refcnt(gr31,0)=gr0
  794| 002314 stw        901C0024   1     ST4A      (*)aggr#3._err_stackitem.exc_value(gr28,36)=gr0                                                               417| 00233C cmpwi      2C000000   1     C4         cr0=gr0,0
  403| 002318 addi       38C60001   1     AI        gr6=gr6,1                                                                                                     417| 002340 bc         41820058   1     BT         CL.737,cr0,0x4/eq,taken=40%(40,60)
  403| 00231C stw        90C30000   1     ST4A      (*)_object._object.ob_refcnt(gr3,0)=gr6                                                                       419| 002344 bc         41800024   1     BT         CL.2037,cr0,0x1/lt,taken=40%(40,60)
  795| 002320 stw        901C0028   1     ST4A      (*)aggr#3._err_stackitem.exc_traceback(gr28,40)=gr0                                                           785| 002348 addi       38600000   3     LI         gr3=0
  796| 002324 stw        901C002C   1     ST4A      (*)aggr#3._err_stackitem.previous_item(gr28,44)=gr0                                                             0| 00234C lwz        83A10044   1     L4A        gr29=#stack(gr1,68)
  797| 002328 bc         41820168   0     BT        CL.198,cr0,0x4/eq,taken=50%(0,0)                                                                                0| 002350 lwz        80010058   1     L4A        gr0=#stack(gr1,88)
  798| 00232C stw        93DC0018   2     ST4A      (*)aggr#3.gi_name(gr28,24)=gr30                                                                                 0| 002354 lwz        83C10048   1     L4A        gr30=#stack(gr1,72)
  403| 002330 lwz        807E0000   1     L4A       gr3=(*)_object._object.ob_refcnt(gr30,0)                                                                        0| 002358 lwz        83E1004C   1     L4A        gr31=#stack(gr1,76)
  403| 002334 addi       38030001   2     AI        gr0=gr3,1                                                                                                     809| 00235C addi       38210050   1     AI         gr1=gr1,80
  403| 002338 stw        901E0000   1     ST4A      (*)_object._object.ob_refcnt(gr30,0)=gr0                                                                        0| 002360 mtspr      7C0803A6   1     LLR        lr=gr0
  802| 00233C bc         40860108   0     BF        CL.1863,cr1,0x4/eq,taken=50%(0,0)                                                                             809| 002364 bclr       4E800020   3     BA         lr
  805| 002340 stw        93DC001C   1     ST4A      (*)aggr#3.gi_qualname(gr28,28)=gr30                                                                             0|                                CL.2037:
    0| 002344 lwz        81020018   1     L4A       gr8=.+CONSTANT_AREA(gr2,0)                                                                                    420| 002368 addi       38800310   1     LI         gr4=784
  401| 002348 addi       38A50001   1     AI        gr5=gr5,1                                                                                                     420| 00236C ori        63E50000   1     LR         gr5=gr31
   30| 00234C lwz        807CFFF8   1     L4A       gr3=(*)_object%##2(gr28,-8)                                                                                   420| 002370 bl         4BFFDC91   0     CALL       _Py_NegativeRefcount,3,(*)Cuchar",gr3,gr4,(*)_object",gr5,#ProcAlias",_Py_NegativeRefcount",fcr",gr1,cr[01
  401| 002350 stw        90A40000   1     ST4A      <s117:d0:l4>(gr4,0)=gr5                                                                                       420| 002374 ori        60000000   1
   30| 002354 cmpwi      2C030000   1     C4        cr0=gr3,0                                                                                                     785| 002378 addi       38600000   1     LI         gr3=0
  403| 002358 ori        60030000   1     LR        gr3=gr0                                                                                                         0| 00237C lwz        83A10044   1     L4A        gr29=#stack(gr1,68)
   27| 00235C addi       38C81110   1     AI        gr6=gr8,4368                                                                                                    0| 002380 lwz        80010058   1     L4A        gr0=#stack(gr1,88)
  403| 002360 addi       38030001   1     AI        gr0=gr3,1                                                                                                       0| 002384 lwz        83C10048   1     L4A        gr30=#stack(gr1,72)
  403| 002364 stw        901E0000   1     ST4A      (*)_object._object.ob_refcnt(gr30,0)=gr0                                                                        0| 002388 lwz        83E1004C   1     L4A        gr31=#stack(gr1,76)
   30| 002368 bc         40820108   0     BF        CL.1862,cr0,0x4/eq,taken=50%(0,0)                                                                             809| 00238C addi       38210050   1     AI         gr1=gr1,80
   30|                                CL.745:                                                                                                                       0| 002390 mtspr      7C0803A6   1     LLR        lr=gr0
   34| 00236C addi       3BFCFFF8   1     AI        gr31=gr28,-8                                                                                                  809| 002394 bclr       4E800020   3     BA         lr
   35| 002370 lwz        801CFFFC   1     L4A       gr0=(*)aggr#2._gc_prev(gr28,-4)                                                                               423|                                CL.737:
   35| 002374 andi.      70030002   2     RN4_R     gr3,cr0=gr0,0,0x2                                                                                             425| 002398 ori        63E30000   1     LR         gr3=gr31
   35| 002378 bc         408200AC   1     BF        CL.1877,cr0,0x4/eq,taken=10%(10,90)                                                                           425| 00239C bl         4BFFDC65   0     CALL       _Py_Dealloc,1,(*)_object",gr3,#ProcAlias",_Py_Dealloc",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",
   67| 00237C lwz        808200A4   1     L4A       gr4=._PyRuntime(gr2,0)                                                                                        425| 0023A0 ori        60000000   1
   54| 002380 lwz        806401A0   2     L4A       gr3=<s149:d416:l4>(gr4,416)                                                                                   785| 0023A4 addi       38600000   1     LI         gr3=0
   41| 002384 lwz        80630008   2     L4A       gr3=(*)_ts._ts.interp(gr3,8)                                                                                    0| 0023A8 lwz        83A10044   1     L4A        gr29=#stack(gr1,68)
   41| 002388 lwz        83C30188   2     L4A       gr30=(*)_is._gc_runtime_state.generation0(gr3,392)                                                              0| 0023AC lwz        80010058   1     L4A        gr0=#stack(gr1,88)
   42| 00238C lwz        83BE0004   2     L4A       gr29=(*)aggr#2._gc_prev(gr30,4)                                                                                 0| 0023B0 lwz        83C10048   1     L4A        gr30=#stack(gr1,72)
   44| 002390 andi.      73A30003   2     RN4_R     gr3,cr0=gr29,0,0xFFFFFFFF00000003                                                                               0| 0023B4 lwz        83E1004C   1     L4A        gr31=#stack(gr1,76)
   43| 002394 stw        93FD0000   1     ST4A      (*)aggr#2._gc_next(gr29,0)=gr31                                                                               809| 0023B8 addi       38210050   1     AI         gr1=gr1,80
   44| 002398 bc         4082003C   0     BF        CL.1983,cr0,0x4/eq,taken=40%(40,60)                                                                             0| 0023BC mtspr      7C0803A6   1     LLR        lr=gr0
   44| 00239C rlwinm     540007BE   1     RN4       gr0=gr0,0,0x3                                                                                                 809| 0023C0 bclr       4E800020   3     BA         lr
   45| 0023A0 stw        93DCFFF8   1     ST4A      (*)aggr#2._gc_next(gr28,-8)=gr30                                                                                 |               Tag Table
   44| 0023A4 or         7C04EB78   1     O         gr4=gr0,gr29                                                                                                     | 0023C4        00000000 00002041 80040400 00000000 00000304 00156765
  808| 0023A8 ori        63830000   1     LR        gr3=gr28                                                                                                         | 0023DC        6E5F6E65 775F7769 74685F71 75616C6E 616D65
   44| 0023AC stw        909CFFFC   1     ST4A      (*)aggr#2._gc_prev(gr28,-4)=gr4                                                                                  |               Instruction count          193
   46| 0023B0 stw        93FE0004   1     ST4A      (*)aggr#2._gc_prev(gr30,4)=gr31                                                                                  |               Straight-line exec time    202
    0| 0023B4 lwz        83810040   1     L4A       gr28=#stack(gr1,64)                                                                                          GPR's set/used:   ssus ssss ssss s---  ---- ---- ---- ----
  809| 0023B8 addi       38210050   1     AI        gr1=gr1,80                                                                                                   FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----
    0| 0023BC lwz        83A1FFF4   1     L4A       gr29=#stack(gr1,-12)                                                                                         CCR's set/used:   ss-- -sss
    0| 0023C0 lwz        80010008   1     L4A       gr0=#stack(gr1,8)                                                                                                | 000000                             PDEF       gen_getyieldfrom







Wed Apr 15 07:30:04 CDT 2020  Page 100


    0| 0023C4 lwz        83C1FFF8   1     L4A       gr30=#stack(gr1,-8)                                                                                           693|                                    PROC       gen,_unused_ignored,gr3,gr4
    0| 0023C8 lwz        83E1FFFC   1     L4A       gr31=#stack(gr1,-4)                                                                                             0| 002400 mfspr      7C0802A6   1     LFLR       gr0=lr
    0| 0023CC mtspr      7C0803A6   1     LLR       lr=gr0                                                                                                          0| 002404 stwu       9421FFC0   1     ST4U       gr1,#stack(gr1,-64)=gr1
  809| 0023D0 bclr       4E800020   3     BA        lr                                                                                                              0| 002408 stw        90010048   1     ST4A       #stack(gr1,72)=gr0
    0|                                CL.1983:                                                                                                                    695| 00240C bl         480034D5   0     CALL       gr3=_PyGen_yf,1,(*)aggr#3",gr3,#ProcAlias",_PyGen_yf",fcr",gr1,cr[01567]",gr0",gr4"-gr12",fp0"-fp13",mq",l
   44| 0023D4 addi       386815E4   1     AI        gr3=gr8,5604                                                                                                  696| 002410 cmpwi      2C030000   1     C4         cr0=gr3,0
   44| 0023D8 addi       38881610   1     AI        gr4=gr8,5648                                                                                                  401| 002414 lwz        80820004   1     L4A        gr4=._Py_RefTotal(gr2,0)
   44| 0023DC addi       38A0002C   1     LI        gr5=44                                                                                                        696| 002418 bc         40820030   0     BF         CL.2215,cr0,0x4/eq,taken=50%(0,0)
   44| 0023E0 bl         4BFFDC21   0     CALL      __assert,3,gr3-gr5,#ProcAlias",__assert",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",lr",fcr",xer",f   697| 00241C lwz        80620008   2     L4A        gr3=._Py_NoneStruct(gr2,0)
   44| 0023E4 ori        60000000   1                                                                                                                             401| 002420 lwz        80A40000   1     L4A        gr5=_Py_RefTotal(gr4,0)
    0| 0023E8 lwz        801CFFFC   1     L4A       gr0=(*)aggr#2._gc_prev(gr28,-4)                                                                               403| 002424 lwz        80C30000   1     L4A        gr6=_Py_NoneStruct%##1(gr3,0)
   45| 0023EC stw        93DCFFF8   1     ST4A      (*)aggr#2._gc_next(gr28,-8)=gr30                                                                                0| 002428 lwz        80010048   1     L4A        gr0=#stack(gr1,72)
  808| 0023F0 ori        63830000   1     LR        gr3=gr28                                                                                                      699| 00242C addi       38210040   1     AI         gr1=gr1,64
   44| 0023F4 rlwinm     540007BE   1     RN4       gr0=gr0,0,0x3                                                                                                   0| 002430 mtspr      7C0803A6   1     LLR        lr=gr0
   44| 0023F8 or         7C04EB78   1     O         gr4=gr0,gr29                                                                                                  401| 002434 addi       38050001   1     AI         gr0=gr5,1
   44| 0023FC stw        909CFFFC   1     ST4A      (*)aggr#2._gc_prev(gr28,-4)=gr4                                                                               401| 002438 stw        90040000   1     ST4A       _Py_RefTotal(gr4,0)=gr0
   46| 002400 stw        93FE0004   1     ST4A      (*)aggr#2._gc_prev(gr30,4)=gr31                                                                               403| 00243C addi       38860001   1     AI         gr4=gr6,1
    0| 002404 lwz        83810040   1     L4A       gr28=#stack(gr1,64)                                                                                           403| 002440 stw        90830000   1     ST4A       _Py_NoneStruct%##1(gr3,0)=gr4
  809| 002408 addi       38210050   1     AI        gr1=gr1,80                                                                                                    699| 002444 bclr       4E800020   0     BA         lr
    0| 00240C lwz        83A1FFF4   1     L4A       gr29=#stack(gr1,-12)                                                                                            0|                                CL.2215:
    0| 002410 lwz        80010008   1     L4A       gr0=#stack(gr1,8)                                                                                               0| 002448 lwz        80010048   1     L4A        gr0=#stack(gr1,72)
    0| 002414 lwz        83C1FFF8   1     L4A       gr30=#stack(gr1,-8)                                                                                           699| 00244C addi       38210040   1     AI         gr1=gr1,64
    0| 002418 lwz        83E1FFFC   1     L4A       gr31=#stack(gr1,-4)                                                                                             0| 002450 mtspr      7C0803A6   1     LLR        lr=gr0
    0| 00241C mtspr      7C0803A6   1     LLR       lr=gr0                                                                                                        699| 002454 bclr       4E800020   3     BA         lr
  809| 002420 bclr       4E800020   3     BA        lr                                                                                                               |               Tag Table
    0|                                CL.1877:                                                                                                                       | 002458        00000000 00002041 80000200 00000000 00000058 00106765
   35| 002424 ori        63830000   1     LR        gr3=gr28                                                                                                         | 002470        6E5F6765 74796965 6C646672 6F6D
   35| 002428 addi       38881594   1     AI        gr4=gr8,5524                                                                                                     |               Instruction count           22
   35| 00242C addi       38A815B0   1     AI        gr5=gr8,5552                                                                                                     |               Straight-line exec time     22
   35| 002430 addi       38E00327   1     LI        gr7=807                                                                                                      GPR's set/used:   ssus ssss ssss s---  ---- ---- ---- --ss
   35| 002434 addi       39081580   1     AI        gr8=gr8,5504                                                                                                 FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----
   35| 002438 bl         4BFFDBC9   0     CALL      _PyObject_AssertFailed,6,(*)_object",gr3-gr5,(*)Cuchar",gr6-gr8,#ProcAlias",_PyObject_AssertFailed",fcr",gr  CCR's set/used:   ss-- -sss
   35| 00243C ori        60000000   1                                                                                                                                | 000000                             PDEF       gen_set_qualname
   35| 002440 tw         7C8E7008   1     TRAP      9                                                                                                             678|                                    PROC       op,value,_unused_ignored,gr3-gr5
    0|                                CL.1863:                                                                                                                      0| 002480 mfspr      7C0802A6   1     LFLR       gr0=lr
  803| 002444 stw        93BC001C   1     ST4A      (*)aggr#3.gi_qualname(gr28,28)=gr29                                                                             0| 002484 stwu       9421FFC0   1     ST4U       gr1,#stack(gr1,-64)=gr1
  401| 002448 addi       38A50001   1     AI        gr5=gr5,1                                                                                                       0| 002488 stw        90010048   1     ST4A       #stack(gr1,72)=gr0
  401| 00244C stw        90A40000   1     ST4A      <s117:d0:l4>(gr4,0)=gr5                                                                                         0| 00248C stw        93E1003C   1     ST4A       #stack(gr1,60)=gr31
  403| 002450 lwz        807D0000   1     L4A       gr3=(*)_object._object.ob_refcnt(gr29,0)                                                                        0| 002490 ori        607F0000   1     LR         gr31=gr3
   30| 002454 lwz        801CFFF8   1     L4A       gr0=(*)_object%##2(gr28,-8)                                                                                     0| 002494 stw        93C10038   1     ST4A       #stack(gr1,56)=gr30
    0| 002458 lwz        81020018   1     L4A       gr8=.+CONSTANT_AREA(gr2,0)                                                                                      0| 002498 or.        7C9E2379   1     LR_R       gr30,cr0=gr4
  403| 00245C addi       38630001   1     AI        gr3=gr3,1                                                                                                     682| 00249C bc         418200D0   1     BT         CL.2212,cr0,0x4/eq,taken=30%(30,70)
  403| 002460 stw        907D0000   1     ST4A      (*)_object._object.ob_refcnt(gr29,0)=gr3                                                                      682| 0024A0 lwz        807E0004   2     L4A        gr3=(*)_object._object.ob_type(gr30,4)
   30| 002464 cmpwi      2C000000   1     C4        cr0=gr0,0                                                                                                     617| 0024A4 bl         4BFFDB5D   0     CALL       gr3=PyType_GetFlags,1,(*)_typeobject",gr3,#ProcAlias",PyType_GetFlags",fcr",gr1,cr[01567]",gr0",gr4"-gr12"
   27| 002468 addi       38C81110   1     AI        gr6=gr8,4368                                                                                                  617| 0024A8 ori        60000000   1
   30| 00246C bc         4182FF00   0     BT        CL.745,cr0,0x4/eq,taken=50%(0,0)                                                                                0| 0024AC lwz        80A20018   1     L4A        gr5=.+CONSTANT_AREA(gr2,0)
    0|                                CL.1862:                                                                                                                    401| 0024B0 lwz        80820004   1     L4A        gr4=._Py_RefTotal(gr2,0)
   30| 002470 ori        63830000   1     LR        gr3=gr28                                                                                                      617| 0024B4 andis.     74601000   1     RN4_R      gr0,cr0=gr3,0,0x10000000
   30| 002474 addi       38881528   1     AI        gr4=gr8,5416                                                                                                  408| 0024B8 addi       38651124   1     AI         gr3=gr5,4388
   30| 002478 addi       38A81550   1     AI        gr5=gr8,5456                                                                                                  682| 0024BC bc         418200B0   0     BT         CL.2212,cr0,0x4/eq,taken=30%(30,70)
   30| 00247C addi       38E00327   1     LI        gr7=807                                                                                                       403| 0024C0 lwz        80DE0000   2     L4A        gr6=(*)_object._object.ob_refcnt(gr30,0)
   30| 002480 addi       39081580   1     AI        gr8=gr8,5504                                                                                                  688| 0024C4 lwz        80BF001C   1     L4A        gr5=(*)aggr#3.gi_qualname(gr31,28)
   30| 002484 bl         4BFFDB7D   0     CALL      _PyObject_AssertFailed,6,(*)_object",gr3-gr5,(*)Cuchar",gr6-gr8,#ProcAlias",_PyObject_AssertFailed",fcr",gr   688| 0024C8 stw        93DF001C   1     ST4A       (*)aggr#3.gi_qualname(gr31,28)=gr30
   30| 002488 ori        60000000   1                                                                                                                             403| 0024CC addi       38E60001   1     AI         gr7=gr6,1
   30| 00248C tw         7C8E7008   1     TRAP      9                                                                                                             401| 0024D0 lwz        80C40000   1     L4A        gr6=_Py_RefTotal(gr4,0)
  798|                                CL.198:                                                                                                                     403| 0024D4 stw        90FE0000   1     ST4A       (*)_object._object.ob_refcnt(gr30,0)=gr7







Wed Apr 15 07:30:04 CDT 2020  Page 101


  800| 002490 lwz        80630044   1     L4A       gr3=(*)aggr#5.co_name(gr3,68)                                                                                   0| 0024D8 lwz        80010048   1     L4A        gr0=#stack(gr1,72)
  800| 002494 stw        907C0018   2     ST4A      (*)aggr#3.gi_name(gr28,24)=gr3                                                                                  0| 0024DC mtspr      7C0803A6   2     LLR        lr=gr0
  403| 002498 lwz        80C30000   1     L4A       gr6=(*)_object._object.ob_refcnt(gr3,0)                                                                         0| 0024E0 or.        7CA02B79   1     LR_R       gr0,cr0=gr5
  403| 00249C addi       38060001   2     AI        gr0=gr6,1                                                                                                     401| 0024E4 addi       38060001   1     AI         gr0=gr6,1
  403| 0024A0 stw        90030000   1     ST4A      (*)_object._object.ob_refcnt(gr3,0)=gr0                                                                       401| 0024E8 stw        90040000   1     ST4A       _Py_RefTotal(gr4,0)=gr0
  802| 0024A4 bc         41860034   0     BT        CL.1865,cr1,0x4/eq,taken=50%(0,0)                                                                             491| 0024EC bc         4182006C   0     BT         CL.2211,cr0,0x4/eq,taken=30%(30,70)
  803| 0024A8 stw        93BC001C   1     ST4A      (*)aggr#3.gi_qualname(gr28,28)=gr29                                                                           415| 0024F0 stw        90C40000   1     ST4A       _Py_RefTotal(gr4,0)=gr6
  403| 0024AC lwz        807D0000   1     L4A       gr3=(*)_object._object.ob_refcnt(gr29,0)                                                                        0| 0024F4 lwz        83E1003C   1     L4A        gr31=#stack(gr1,60)
  401| 0024B0 addi       38C50001   1     AI        gr6=gr5,1                                                                                                     417| 0024F8 lwz        80850000   1     L4A        gr4=(*)_object._object.ob_refcnt(gr5,0)
   30| 0024B4 lwz        80BCFFF8   1     L4A       gr5=(*)_object%##2(gr28,-8)                                                                                     0| 0024FC lwz        83C10038   1     L4A        gr30=#stack(gr1,56)
  401| 0024B8 stw        90C40000   1     ST4A      <s117:d0:l4>(gr4,0)=gr6                                                                                       417| 002500 cmpwi      2C040001   1     C4         cr0=gr4,1
    0| 0024BC lwz        81020018   1     L4A       gr8=.+CONSTANT_AREA(gr2,0)                                                                                    417| 002504 addi       3804FFFF   1     AI         gr0=gr4,-1
  403| 0024C0 addi       38030001   1     AI        gr0=gr3,1                                                                                                     417| 002508 stw        90050000   1     ST4A       (*)_object._object.ob_refcnt(gr5,0)=gr0
  403| 0024C4 stw        901D0000   1     ST4A      (*)_object._object.ob_refcnt(gr29,0)=gr0                                                                      417| 00250C cmpwi      2C800000   1     C4         cr1=gr0,0
   30| 0024C8 cmpwi      2C050000   1     C4        cr0=gr5,0                                                                                                     417| 002510 bc         41820028   0     BT         CL.1315,cr0,0x4/eq,taken=40%(40,60)
   27| 0024CC addi       38C81110   1     AI        gr6=gr8,4368                                                                                                  420| 002514 addi       388001EC   2     LI         gr4=492
   30| 0024D0 bc         4082FFA0   0     BF        CL.1862,cr0,0x4/eq,taken=10%(10,90)                                                                           419| 002518 bc         40840014   0     BF         CL.1926,cr1,0x1/lt,taken=30%(30,70)
   30| 0024D4 b          4BFFFE98   0     B         CL.745,-1                                                                                                     420| 00251C bl         4BFFDAE5   1     CALL       _Py_NegativeRefcount,3,(*)Cuchar",gr3,gr4,(*)_object",gr5,#ProcAlias",_Py_NegativeRefcount",fcr",gr1,cr[01
    0|                                CL.1865:                                                                                                                    420| 002520 ori        60000000   1
  805| 0024D8 stw        907C001C   1     ST4A      (*)aggr#3.gi_qualname(gr28,28)=gr3                                                                              0| 002524 lwz        80010048   1     L4A        gr0=#stack(gr1,72)
  401| 0024DC addi       38A50001   1     AI        gr5=gr5,1                                                                                                       0| 002528 mtspr      7C0803A6   2     LLR        lr=gr0
  401| 0024E0 stw        90A40000   1     ST4A      <s117:d0:l4>(gr4,0)=gr5                                                                                         0|                                CL.1926:
  403| 0024E4 addi       38860002   1     AI        gr4=gr6,2                                                                                                     689| 00252C addi       38600000   1     LI         gr3=0
   30| 0024E8 lwz        801CFFF8   1     L4A       gr0=(*)_object%##2(gr28,-8)                                                                                   690| 002530 addi       38210040   1     AI         gr1=gr1,64
    0| 0024EC lwz        81020018   1     L4A       gr8=.+CONSTANT_AREA(gr2,0)                                                                                    690| 002534 bclr       4E800020   0     BA         lr
  403| 0024F0 stw        90830000   1     ST4A      (*)_object._object.ob_refcnt(gr3,0)=gr4                                                                       423|                                CL.1315:
   30| 0024F4 cmpwi      2C000000   1     C4        cr0=gr0,0                                                                                                     425| 002538 ori        60A30000   1     LR         gr3=gr5
   27| 0024F8 addi       38C81110   1     AI        gr6=gr8,4368                                                                                                  425| 00253C bl         4BFFDAC5   0     CALL       _Py_Dealloc,1,(*)_object",gr3,#ProcAlias",_Py_Dealloc",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",
   30| 0024FC bc         4082FF74   0     BF        CL.1862,cr0,0x4/eq,taken=10%(10,90)                                                                           425| 002540 ori        60000000   1
    0| 002500 b          4BFFFE6C   1     B         CL.745,-1                                                                                                     689| 002544 addi       38600000   1     LI         gr3=0
    0|                                CL.1874:                                                                                                                      0| 002548 lwz        80010048   1     L4A        gr0=#stack(gr1,72)
    0| 002504 lwz        80620018   1     L4A       gr3=.+CONSTANT_AREA(gr2,0)                                                                                    690| 00254C addi       38210040   1     AI         gr1=gr1,64
  415| 002508 addi       3805FFFF   1     AI        gr0=gr5,-1                                                                                                      0| 002550 mtspr      7C0803A6   1     LLR        lr=gr0
  417| 00250C lwz        80BF0000   1     L4A       gr5=(*)_object._object.ob_refcnt(gr31,0)                                                                      690| 002554 bclr       4E800020   3     BA         lr
  415| 002510 stw        90040000   1     ST4A      <s117:d0:l4>(gr4,0)=gr0                                                                                         0|                                CL.2211:
  408| 002514 addi       38631110   1     AI        gr3=gr3,4368                                                                                                  689| 002558 addi       38600000   1     LI         gr3=0
  417| 002518 addi       3805FFFF   1     AI        gr0=gr5,-1                                                                                                      0| 00255C lwz        83E1003C   1     L4A        gr31=#stack(gr1,60)
  417| 00251C stw        901F0000   1     ST4A      (*)_object._object.ob_refcnt(gr31,0)=gr0                                                                        0| 002560 lwz        83C10038   1     L4A        gr30=#stack(gr1,56)
  417| 002520 cmpwi      2C000000   1     C4        cr0=gr0,0                                                                                                     690| 002564 addi       38210040   1     AI         gr1=gr1,64
  417| 002524 bc         41820058   1     BT        CL.737,cr0,0x4/eq,taken=40%(40,60)                                                                            690| 002568 bclr       4E800020   0     BA         lr
  419| 002528 bc         41800024   1     BT        CL.1982,cr0,0x1/lt,taken=40%(40,60)                                                                             0|                                CL.2212:
  785| 00252C addi       38600000   3     LI        gr3=0                                                                                                         683| 00256C lwz        806200B4   1     L4A        gr3=.PyExc_TypeError(gr2,0)
  809| 002530 addi       38210050   1     AI        gr1=gr1,80                                                                                                    683| 002570 lwz        80820018   1     L4A        gr4=.+CONSTANT_AREA(gr2,0)
    0| 002534 lwz        83A1FFF4   1     L4A       gr29=#stack(gr1,-12)                                                                                            0| 002574 lwz        83E1003C   1     L4A        gr31=#stack(gr1,60)
    0| 002538 lwz        80010008   1     L4A       gr0=#stack(gr1,8)                                                                                               0| 002578 lwz        83C10038   1     L4A        gr30=#stack(gr1,56)
    0| 00253C lwz        83C1FFF8   1     L4A       gr30=#stack(gr1,-8)                                                                                           683| 00257C addi       38841674   1     AI         gr4=gr4,5748
    0| 002540 lwz        83E1FFFC   1     L4A       gr31=#stack(gr1,-4)                                                                                           683| 002580 lwz        80630000   1     L4A        gr3=PyExc_TypeError(gr3,0)
    0| 002544 mtspr      7C0803A6   1     LLR       lr=gr0                                                                                                        683| 002584 bl         4BFFDA7D   0     CALL       PyErr_SetString,2,(*)_object",gr3,gr4,#ProcAlias",PyErr_SetString",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0
  809| 002548 bclr       4E800020   3     BA        lr                                                                                                            683| 002588 ori        60000000   1
    0|                                CL.1982:                                                                                                                    685| 00258C addi       3860FFFF   1     LI         gr3=-1
  420| 00254C addi       38800310   1     LI        gr4=784                                                                                                         0| 002590 lwz        80010048   1     L4A        gr0=#stack(gr1,72)
  420| 002550 ori        63E50000   1     LR        gr5=gr31                                                                                                      690| 002594 addi       38210040   1     AI         gr1=gr1,64
  420| 002554 bl         4BFFDAAD   0     CALL      _Py_NegativeRefcount,3,(*)Cuchar",gr3,gr4,(*)_object",gr5,#ProcAlias",_Py_NegativeRefcount",fcr",gr1,cr[015     0| 002598 mtspr      7C0803A6   1     LLR        lr=gr0
  420| 002558 ori        60000000   1                                                                                                                             690| 00259C bclr       4E800020   3     BA         lr
  785| 00255C addi       38600000   1     LI        gr3=0                                                                                                            |               Tag Table
  809| 002560 addi       38210050   1     AI        gr1=gr1,80                                                                                                       | 0025A0        00000000 00002041 80020300 00000000 00000120 00106765







Wed Apr 15 07:30:04 CDT 2020  Page 102


    0| 002564 lwz        83A1FFF4   1     L4A       gr29=#stack(gr1,-12)                                                                                             | 0025B8        6E5F7365 745F7175 616C6E61 6D65
    0| 002568 lwz        80010008   1     L4A       gr0=#stack(gr1,8)                                                                                                |               Instruction count           72
    0| 00256C lwz        83C1FFF8   1     L4A       gr30=#stack(gr1,-8)                                                                                              |               Straight-line exec time     72
    0| 002570 lwz        83E1FFFC   1     L4A       gr31=#stack(gr1,-4)                                                                                          GPR's set/used:   s-us sss- ---- ----  ---- ---- ---- ----
    0| 002574 mtspr      7C0803A6   1     LLR       lr=gr0                                                                                                       FPR's set/used:   ---- ---- ---- ----  ---- ---- ---- ----
  809| 002578 bclr       4E800020   3     BA        lr                                                                                                           CCR's set/used:   ---- ----
  423|                                CL.737:                                                                                                                        | 000000                             PDEF       gen_get_qualname
  425| 00257C ori        63E30000   1     LR        gr3=gr31                                                                                                      671|                                    PROC       op,_unused_ignored,gr3,gr4
  425| 002580 bl         4BFFDA81   0     CALL      _Py_Dealloc,1,(*)_object",gr3,#ProcAlias",_Py_Dealloc",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",l   673| 0025E0 lwz        8063001C   1     L4A        gr3=(*)aggr#3.gi_qualname(gr3,28)
  425| 002584 ori        60000000   1                                                                                                                             401| 0025E4 lwz        80820004   1     L4A        gr4=._Py_RefTotal(gr2,0)
  785| 002588 addi       38600000   1     LI        gr3=0                                                                                                         401| 0025E8 lwz        80A40000   2     L4A        gr5=_Py_RefTotal(gr4,0)
  809| 00258C addi       38210050   1     AI        gr1=gr1,80                                                                                                    403| 0025EC lwz        80C30000   1     L4A        gr6=(*)_object._object.ob_refcnt(gr3,0)
    0| 002590 lwz        83A1FFF4   1     L4A       gr29=#stack(gr1,-12)                                                                                          401| 0025F0 addi       38050001   1     AI         gr0=gr5,1
    0| 002594 lwz        80010008   1     L4A       gr0=#stack(gr1,8)                                                                                             401| 0025F4 stw        90040000   1     ST4A       _Py_RefTotal(gr4,0)=gr0
    0| 002598 lwz        83C1FFF8   1     L4A       gr30=#stack(gr1,-8)                                                                                           403| 0025F8 addi       38860001   1     AI         gr4=gr6,1
    0| 00259C lwz        83E1FFFC   1     L4A       gr31=#stack(gr1,-4)                                                                                           403| 0025FC stw        90830000   1     ST4A       (*)_object._object.ob_refcnt(gr3,0)=gr4
    0| 0025A0 mtspr      7C0803A6   1     LLR       lr=gr0                                                                                                        675| 002600 bclr       4E800020   0     BA         lr
  809| 0025A4 bclr       4E800020   3     BA        lr                                                                                                               |               Tag Table
     |               Tag Table                                                                                                                                       | 002604        00000000 00002040 00000200 00000000 00000024 00106765
     | 0025A8        00000000 00002041 80040400 00000000 00000308 00156765                                                                                           | 00261C        6E5F6765 745F7175 616C6E61 6D65
     | 0025C0        6E5F6E65 775F7769 74685F71 75616C6E 616D65                                                                                                      |               Instruction count            9
     |               Instruction count          194                                                                                                                  |               Straight-line exec time      9
     |               Straight-line exec time    202                                                                                                              GPR's set/used:   ssus ssss ssss s---  ---- ---- ---- --ss
 GPR's set/used:   ssus ssss ssss s---  ---- ---- ---- ----                                                                                                      FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----
 FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----                                                                                                      CCR's set/used:   ss-- -sss
 CCR's set/used:   ss-- -sss                                                                                                                                         | 000000                             PDEF       gen_set_name
     | 000000                             PDEF     gen_getyieldfrom                                                                                               656|                                    PROC       op,value,_unused_ignored,gr3-gr5
  693|                                    PROC      gen,_unused_ignored,gr3,gr4                                                                                     0| 002640 mfspr      7C0802A6   1     LFLR       gr0=lr
    0| 0025E0 mfspr      7C0802A6   1     LFLR      gr0=lr                                                                                                          0| 002644 stwu       9421FFC0   1     ST4U       gr1,#stack(gr1,-64)=gr1
    0| 0025E4 stw        90010008   2     ST4A      #stack(gr1,8)=gr0                                                                                               0| 002648 stw        90010048   1     ST4A       #stack(gr1,72)=gr0
    0| 0025E8 stwu       9421FFC0   1     ST4U      gr1,#stack(gr1,-64)=gr1                                                                                         0| 00264C stw        93E1003C   1     ST4A       #stack(gr1,60)=gr31
  695| 0025EC bl         48003415   0     CALL      gr3=_PyGen_yf,1,(*)aggr#3",gr3,#ProcAlias",_PyGen_yf",fcr",gr1,cr[01567]",gr0",gr4"-gr12",fp0"-fp13",mq",lr     0| 002650 ori        607F0000   1     LR         gr31=gr3
  696| 0025F0 cmpwi      2C030000   1     C4        cr0=gr3,0                                                                                                       0| 002654 stw        93C10038   1     ST4A       #stack(gr1,56)=gr30
  401| 0025F4 lwz        80820004   1     L4A       gr4=._Py_RefTotal(gr2,0)                                                                                        0| 002658 or.        7C9E2379   1     LR_R       gr30,cr0=gr4
  696| 0025F8 bc         40820030   0     BF        CL.2174,cr0,0x4/eq,taken=50%(0,0)                                                                             660| 00265C bc         418200D0   1     BT         CL.2208,cr0,0x4/eq,taken=30%(30,70)
  697| 0025FC lwz        80620008   2     L4A       gr3=._Py_NoneStruct(gr2,0)                                                                                    660| 002660 lwz        807E0004   2     L4A        gr3=(*)_object._object.ob_type(gr30,4)
  401| 002600 lwz        80A40000   1     L4A       gr5=<s117:d0:l4>(gr4,0)                                                                                       617| 002664 bl         4BFFD99D   0     CALL       gr3=PyType_GetFlags,1,(*)_typeobject",gr3,#ProcAlias",PyType_GetFlags",fcr",gr1,cr[01567]",gr0",gr4"-gr12"
  403| 002604 lwz        80C30000   1     L4A       gr6=<s119:d0:l4>(gr3,0)                                                                                       617| 002668 ori        60000000   1
    0| 002608 lwz        80010048   1     L4A       gr0=#stack(gr1,72)                                                                                              0| 00266C lwz        80A20018   1     L4A        gr5=.+CONSTANT_AREA(gr2,0)
  699| 00260C addi       38210040   1     AI        gr1=gr1,64                                                                                                    401| 002670 lwz        80820004   1     L4A        gr4=._Py_RefTotal(gr2,0)
    0| 002610 mtspr      7C0803A6   1     LLR       lr=gr0                                                                                                        617| 002674 andis.     74601000   1     RN4_R      gr0,cr0=gr3,0,0x10000000
  401| 002614 addi       38050001   1     AI        gr0=gr5,1                                                                                                     408| 002678 addi       38651124   1     AI         gr3=gr5,4388
  401| 002618 stw        90040000   1     ST4A      <s117:d0:l4>(gr4,0)=gr0                                                                                       660| 00267C bc         418200B0   0     BT         CL.2208,cr0,0x4/eq,taken=30%(30,70)
  403| 00261C addi       38860001   1     AI        gr4=gr6,1                                                                                                     403| 002680 lwz        80DE0000   2     L4A        gr6=(*)_object._object.ob_refcnt(gr30,0)
  403| 002620 stw        90830000   1     ST4A      <s119:d0:l4>(gr3,0)=gr4                                                                                       666| 002684 lwz        80BF0018   1     L4A        gr5=(*)aggr#3.gi_name(gr31,24)
  699| 002624 bclr       4E800020   0     BA        lr                                                                                                            666| 002688 stw        93DF0018   1     ST4A       (*)aggr#3.gi_name(gr31,24)=gr30
    0|                                CL.2174:                                                                                                                    403| 00268C addi       38E60001   1     AI         gr7=gr6,1
    0| 002628 lwz        80010048   1     L4A       gr0=#stack(gr1,72)                                                                                            401| 002690 lwz        80C40000   1     L4A        gr6=_Py_RefTotal(gr4,0)
  699| 00262C addi       38210040   1     AI        gr1=gr1,64                                                                                                    403| 002694 stw        90FE0000   1     ST4A       (*)_object._object.ob_refcnt(gr30,0)=gr7
    0| 002630 mtspr      7C0803A6   1     LLR       lr=gr0                                                                                                          0| 002698 lwz        80010048   1     L4A        gr0=#stack(gr1,72)
  699| 002634 bclr       4E800020   3     BA        lr                                                                                                              0| 00269C mtspr      7C0803A6   2     LLR        lr=gr0
     |               Tag Table                                                                                                                                      0| 0026A0 or.        7CA02B79   1     LR_R       gr0,cr0=gr5
     | 002638        00000000 00002041 80000200 00000000 00000058 00106765                                                                                        401| 0026A4 addi       38060001   1     AI         gr0=gr6,1
     | 002650        6E5F6765 74796965 6C646672 6F6D                                                                                                              401| 0026A8 stw        90040000   1     ST4A       _Py_RefTotal(gr4,0)=gr0
     |               Instruction count           22                                                                                                               491| 0026AC bc         4182006C   0     BT         CL.2207,cr0,0x4/eq,taken=30%(30,70)
     |               Straight-line exec time     23                                                                                                               415| 0026B0 stw        90C40000   1     ST4A       _Py_RefTotal(gr4,0)=gr6







Wed Apr 15 07:30:04 CDT 2020  Page 103


 GPR's set/used:   ssus ssss ssss s---  ---- ---- ---- ----                                                                                                         0| 0026B4 lwz        83E1003C   1     L4A        gr31=#stack(gr1,60)
 FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----                                                                                                       417| 0026B8 lwz        80850000   1     L4A        gr4=(*)_object._object.ob_refcnt(gr5,0)
 CCR's set/used:   ss-- -sss                                                                                                                                        0| 0026BC lwz        83C10038   1     L4A        gr30=#stack(gr1,56)
     | 000000                             PDEF     gen_set_qualname                                                                                               417| 0026C0 cmpwi      2C040001   1     C4         cr0=gr4,1
  678|                                    PROC      op,value,_unused_ignored,gr3-gr5                                                                              417| 0026C4 addi       3804FFFF   1     AI         gr0=gr4,-1
    0| 002660 mfspr      7C0802A6   1     LFLR      gr0=lr                                                                                                        417| 0026C8 stw        90050000   1     ST4A       (*)_object._object.ob_refcnt(gr5,0)=gr0
    0| 002664 ori        60660000   1     LR        gr6=gr3                                                                                                       417| 0026CC cmpwi      2C800000   1     C4         cr1=gr0,0
    0| 002668 or.        7C842379   1     LR_R      gr4,cr0=gr4                                                                                                   417| 0026D0 bc         41820028   0     BT         CL.1305,cr0,0x4/eq,taken=40%(40,60)
    0| 00266C stw        90010008   1     ST4A      #stack(gr1,8)=gr0                                                                                             420| 0026D4 addi       388001EC   2     LI         gr4=492
    0| 002670 stwu       9421FF90   1     ST4U      gr1,#stack(gr1,-112)=gr1                                                                                      419| 0026D8 bc         40840014   0     BF         CL.1931,cr1,0x1/lt,taken=30%(30,70)
  682| 002674 bc         418200F8   0     BT        CL.2172,cr0,0x4/eq,taken=30%(30,70)                                                                           420| 0026DC bl         4BFFD925   1     CALL       _Py_NegativeRefcount,3,(*)Cuchar",gr3,gr4,(*)_object",gr5,#ProcAlias",_Py_NegativeRefcount",fcr",gr1,cr[01
  682| 002678 lwz        80640004   2     L4A       gr3=(*)_object._object.ob_type(gr4,4)                                                                         420| 0026E0 ori        60000000   1
    0| 00267C stw        90C10064   1     ST4A      #parameter_store0(gr1,100)=gr6                                                                                  0| 0026E4 lwz        80010048   1     L4A        gr0=#stack(gr1,72)
    0| 002680 stw        90810068   1     ST4A      #parameter_store1(gr1,104)=gr4                                                                                  0| 0026E8 mtspr      7C0803A6   2     LLR        lr=gr0
  617| 002684 bl         4BFFD97D   0     CALL      gr3=PyType_GetFlags,1,(*)_typeobject",gr3,#ProcAlias",PyType_GetFlags",fcr",gr1,cr[01567]",gr0",gr4"-gr12",     0|                                CL.1931:
  617| 002688 ori        60000000   1                                                                                                                             667| 0026EC addi       38600000   1     LI         gr3=0
    0| 00268C lwz        80A20018   1     L4A       gr5=.+CONSTANT_AREA(gr2,0)                                                                                    668| 0026F0 addi       38210040   1     AI         gr1=gr1,64
  401| 002690 lwz        80E20004   1     L4A       gr7=._Py_RefTotal(gr2,0)                                                                                      668| 0026F4 bclr       4E800020   0     BA         lr
  682| 002694 andis.     74601000   1     RN4_R     gr0,cr0=gr3,0,0x10000000                                                                                      423|                                CL.1305:
  408| 002698 addi       38651124   1     AI        gr3=gr5,4388                                                                                                  425| 0026F8 ori        60A30000   1     LR         gr3=gr5
  617| 00269C lwz        80C10064   1     L4A       gr6=#parameter_store0(gr1,100)                                                                                425| 0026FC bl         4BFFD905   0     CALL       _Py_Dealloc,1,(*)_object",gr3,#ProcAlias",_Py_Dealloc",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",
  617| 0026A0 lwz        80810068   1     L4A       gr4=#parameter_store1(gr1,104)                                                                                425| 002700 ori        60000000   1
  682| 0026A4 bc         4182009C   0     BT        CL.1837,cr0,0x4/eq,taken=30%(30,70)                                                                           667| 002704 addi       38600000   1     LI         gr3=0
    0| 0026A8 lwz        80010078   2     L4A       gr0=#stack(gr1,120)                                                                                             0| 002708 lwz        80010048   1     L4A        gr0=#stack(gr1,72)
    0| 0026AC mtspr      7C0803A6   2     LLR       lr=gr0                                                                                                        668| 00270C addi       38210040   1     AI         gr1=gr1,64
  403| 0026B0 lwz        81040000   1     L4A       gr8=(*)_object._object.ob_refcnt(gr4,0)                                                                         0| 002710 mtspr      7C0803A6   1     LLR        lr=gr0
  688| 0026B4 lwz        80A6001C   1     L4A       gr5=(*)aggr#3.gi_qualname(gr6,28)                                                                             668| 002714 bclr       4E800020   3     BA         lr
  688| 0026B8 stw        9086001C   1     ST4A      (*)aggr#3.gi_qualname(gr6,28)=gr4                                                                               0|                                CL.2207:
  401| 0026BC lwz        80C70000   1     L4A       gr6=<s117:d0:l4>(gr7,0)                                                                                       667| 002718 addi       38600000   1     LI         gr3=0
    0| 0026C0 or.        7CA02B79   1     LR_R      gr0,cr0=gr5                                                                                                     0| 00271C lwz        83E1003C   1     L4A        gr31=#stack(gr1,60)
  403| 0026C4 addi       39080001   1     AI        gr8=gr8,1                                                                                                       0| 002720 lwz        83C10038   1     L4A        gr30=#stack(gr1,56)
  403| 0026C8 stw        91040000   1     ST4A      (*)_object._object.ob_refcnt(gr4,0)=gr8                                                                       668| 002724 addi       38210040   1     AI         gr1=gr1,64
  401| 0026CC addi       38060001   1     AI        gr0=gr6,1                                                                                                     668| 002728 bclr       4E800020   0     BA         lr
  401| 0026D0 stw        90070000   1     ST4A      <s117:d0:l4>(gr7,0)=gr0                                                                                         0|                                CL.2208:
  491| 0026D4 bc         41820020   0     BT        CL.1839,cr0,0x4/eq,taken=30%(30,70)                                                                           661| 00272C lwz        806200B4   1     L4A        gr3=.PyExc_TypeError(gr2,0)
  415| 0026D8 stw        90C70000   1     ST4A      <s117:d0:l4>(gr7,0)=gr6                                                                                       661| 002730 lwz        80820018   1     L4A        gr4=.+CONSTANT_AREA(gr2,0)
  417| 0026DC lwz        80850000   1     L4A       gr4=(*)_object._object.ob_refcnt(gr5,0)                                                                         0| 002734 lwz        83E1003C   1     L4A        gr31=#stack(gr1,60)
  417| 0026E0 addi       3804FFFF   2     AI        gr0=gr4,-1                                                                                                      0| 002738 lwz        83C10038   1     L4A        gr30=#stack(gr1,56)
  417| 0026E4 stw        90050000   1     ST4A      (*)_object._object.ob_refcnt(gr5,0)=gr0                                                                       661| 00273C addi       388416A0   1     AI         gr4=gr4,5792
  417| 0026E8 cmpwi      2C000000   1     C4        cr0=gr0,0                                                                                                     661| 002740 lwz        80630000   1     L4A        gr3=PyExc_TypeError(gr3,0)
  417| 0026EC bc         41820034   1     BT        CL.1315,cr0,0x4/eq,taken=40%(40,60)                                                                           661| 002744 bl         4BFFD8BD   0     CALL       PyErr_SetString,2,(*)_object",gr3,gr4,#ProcAlias",PyErr_SetString",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0
  419| 0026F0 bc         41800010   1     BT        CL.2173,cr0,0x1/lt,taken=40%(40,60)                                                                           661| 002748 ori        60000000   1
    0|                                CL.1839:                                                                                                                    663| 00274C addi       3860FFFF   1     LI         gr3=-1
  689| 0026F4 addi       38600000   1     LI        gr3=0                                                                                                           0| 002750 lwz        80010048   1     L4A        gr0=#stack(gr1,72)
  690| 0026F8 addi       38210070   1     AI        gr1=gr1,112                                                                                                   668| 002754 addi       38210040   1     AI         gr1=gr1,64
  690| 0026FC bclr       4E800020   0     BA        lr                                                                                                              0| 002758 mtspr      7C0803A6   1     LLR        lr=gr0
    0|                                CL.2173:                                                                                                                    668| 00275C bclr       4E800020   3     BA         lr
  420| 002700 addi       388001EC   1     LI        gr4=492                                                                                                          |               Tag Table
  420| 002704 bl         4BFFD8FD   0     CALL      _Py_NegativeRefcount,3,(*)Cuchar",gr3,gr4,(*)_object",gr5,#ProcAlias",_Py_NegativeRefcount",fcr",gr1,cr[015      | 002760        00000000 00002041 80020300 00000000 00000120 000C6765
  420| 002708 ori        60000000   1                                                                                                                                | 002778        6E5F7365 745F6E61 6D65
  689| 00270C addi       38600000   1     LI        gr3=0                                                                                                            |               Instruction count           72
    0| 002710 lwz        80010078   1     L4A       gr0=#stack(gr1,120)                                                                                              |               Straight-line exec time     72
  690| 002714 addi       38210070   1     AI        gr1=gr1,112                                                                                                  GPR's set/used:   s-us sss- ---- ----  ---- ---- ---- ----
    0| 002718 mtspr      7C0803A6   1     LLR       lr=gr0                                                                                                       FPR's set/used:   ---- ---- ---- ----  ---- ---- ---- ----
  690| 00271C bclr       4E800020   3     BA        lr                                                                                                           CCR's set/used:   ---- ----
  423|                                CL.1315:                                                                                                                       | 000000                             PDEF       gen_get_name







Wed Apr 15 07:30:04 CDT 2020  Page 104


  425| 002720 ori        60A30000   1     LR        gr3=gr5                                                                                                       649|                                    PROC       op,_unused_ignored,gr3,gr4
  425| 002724 bl         4BFFD8DD   0     CALL      _Py_Dealloc,1,(*)_object",gr3,#ProcAlias",_Py_Dealloc",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",l   651| 0027A0 lwz        80630018   1     L4A        gr3=(*)aggr#3.gi_name(gr3,24)
  425| 002728 ori        60000000   1                                                                                                                             401| 0027A4 lwz        80820004   1     L4A        gr4=._Py_RefTotal(gr2,0)
  689| 00272C addi       38600000   1     LI        gr3=0                                                                                                         401| 0027A8 lwz        80A40000   2     L4A        gr5=_Py_RefTotal(gr4,0)
    0| 002730 lwz        80010078   1     L4A       gr0=#stack(gr1,120)                                                                                           403| 0027AC lwz        80C30000   1     L4A        gr6=(*)_object._object.ob_refcnt(gr3,0)
  690| 002734 addi       38210070   1     AI        gr1=gr1,112                                                                                                   401| 0027B0 addi       38050001   1     AI         gr0=gr5,1
    0| 002738 mtspr      7C0803A6   1     LLR       lr=gr0                                                                                                        401| 0027B4 stw        90040000   1     ST4A       _Py_RefTotal(gr4,0)=gr0
  690| 00273C bclr       4E800020   3     BA        lr                                                                                                            403| 0027B8 addi       38860001   1     AI         gr4=gr6,1
    0|                                CL.1837:                                                                                                                    403| 0027BC stw        90830000   1     ST4A       (*)_object._object.ob_refcnt(gr3,0)=gr4
  683| 002740 lwz        806200B4   1     L4A       gr3=.PyExc_TypeError(gr2,0)                                                                                   653| 0027C0 bclr       4E800020   0     BA         lr
  683| 002744 ori        60A40000   1     LR        gr4=gr5                                                                                                          |               Tag Table
  683| 002748 addi       38841674   1     AI        gr4=gr4,5748                                                                                                     | 0027C4        00000000 00002040 00000200 00000000 00000024 000C6765
  683| 00274C lwz        80630000   1     L4A       gr3=<s145:d0:l4>(gr3,0)                                                                                          | 0027DC        6E5F6765 745F6E61 6D65
  683| 002750 bl         4BFFD8B1   0     CALL      PyErr_SetString,2,(*)_object",gr3,gr4,#ProcAlias",PyErr_SetString",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"      |               Instruction count            9
  683| 002754 ori        60000000   1                                                                                                                                |               Straight-line exec time      9
  685| 002758 addi       3860FFFF   1     LI        gr3=-1                                                                                                       GPR's set/used:   ssus ssss ssss s---  ---- ---- ---- ----
    0| 00275C lwz        80010078   1     L4A       gr0=#stack(gr1,120)                                                                                          FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----
  690| 002760 addi       38210070   1     AI        gr1=gr1,112                                                                                                  CCR's set/used:   ss-- -sss
    0| 002764 mtspr      7C0803A6   1     LLR       lr=gr0                                                                                                           | 000000                             PDEF       gen_repr
  690| 002768 bclr       4E800020   3     BA        lr                                                                                                            642|                                    PROC       gen,gr3
    0|                                CL.2172:                                                                                                                      0| 002800 mfspr      7C0802A6   1     LFLR       gr0=lr
  683| 00276C lwz        806200B4   1     L4A       gr3=.PyExc_TypeError(gr2,0)                                                                                   644| 002804 lwz        8083001C   1     L4A        gr4=(*)aggr#3.gi_qualname(gr3,28)
  683| 002770 lwz        80820018   1     L4A       gr4=.+CONSTANT_AREA(gr2,0)                                                                                      0| 002808 stwu       9421FFC0   1     ST4U       gr1,#stack(gr1,-64)=gr1
  683| 002774 addi       38841674   2     AI        gr4=gr4,5748                                                                                                  644| 00280C ori        60650000   1     LR         gr5=gr3
  683| 002778 lwz        80630000   1     L4A       gr3=<s145:d0:l4>(gr3,0)                                                                                       644| 002810 lwz        80620018   1     L4A        gr3=.+CONSTANT_AREA(gr2,0)
  683| 00277C bl         4BFFD885   0     CALL      PyErr_SetString,2,(*)_object",gr3,gr4,#ProcAlias",PyErr_SetString",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"   644| 002814 addi       386316C8   2     AI         gr3=gr3,5832
  683| 002780 ori        60000000   1                                                                                                                               0| 002818 stw        90010048   1     ST4A       #stack(gr1,72)=gr0
  685| 002784 addi       3860FFFF   1     LI        gr3=-1                                                                                                        644| 00281C bl         4BFFD7E5   0     CALL       gr3=PyUnicode_FromFormat,3,gr3,(*)_object",gr4,(*)aggr#3",gr5,#ProcAlias",PyUnicode_FromFormat",fcr",gr1,c
    0| 002788 lwz        80010078   1     L4A       gr0=#stack(gr1,120)                                                                                           644| 002820 ori        60000000   1
  690| 00278C addi       38210070   1     AI        gr1=gr1,112                                                                                                     0| 002824 lwz        80010048   1     L4A        gr0=#stack(gr1,72)
    0| 002790 mtspr      7C0803A6   1     LLR       lr=gr0                                                                                                        646| 002828 addi       38210040   1     AI         gr1=gr1,64
  690| 002794 bclr       4E800020   3     BA        lr                                                                                                              0| 00282C mtspr      7C0803A6   1     LLR        lr=gr0
     |               Tag Table                                                                                                                                    646| 002830 bclr       4E800020   3     BA         lr
     | 002798        00000000 00002041 80000300 00000000 00000138 00106765                                                                                           |               Tag Table
     | 0027B0        6E5F7365 745F7175 616C6E61 6D65                                                                                                                 | 002834        00000000 00002041 80000100 00000000 00000034 00086765
     |               Instruction count           78                                                                                                                  | 00284C        6E5F7265 7072
     |               Straight-line exec time     82                                                                                                                  |               Instruction count           13
 GPR's set/used:   s-us sss- ---- ----  ---- ---- ---- ----                                                                                                          |               Straight-line exec time     15
 FPR's set/used:   ---- ---- ---- ----  ---- ---- ---- ----                                                                                                      GPR's set/used:   su-s ssss ssss s---  ---- ---- ---- ----
 CCR's set/used:   ---- ----                                                                                                                                     FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----
     | 000000                             PDEF     gen_get_qualname                                                                                              CCR's set/used:   ss-- -sss
  671|                                    PROC      op,_unused_ignored,gr3,gr4                                                                                       | 000000                             PDEF       gen_iternext
  673| 0027C0 lwz        8063001C   1     L4A       gr3=(*)aggr#3.gi_qualname(gr3,28)                                                                             542|                                    PROC       gen,gr3
  401| 0027C4 lwz        80820004   1     L4A       gr4=._Py_RefTotal(gr2,0)                                                                                      544| 002860 addi       38800000   1     LI         gr4=0
  401| 0027C8 lwz        80A40000   2     L4A       gr5=<s117:d0:l4>(gr4,0)                                                                                       544| 002864 addi       38A00000   1     LI         gr5=0
  403| 0027CC lwz        80C30000   1     L4A       gr6=(*)_object._object.ob_refcnt(gr3,0)                                                                       544| 002868 addi       38C00000   1     LI         gr6=0
  401| 0027D0 addi       38050001   1     AI        gr0=gr5,1                                                                                                     545| 00286C b          48000E14   0     CALLF      gr3=gen_send_ex,4,(*)aggr#3",gr3,(*)_object",gr4-gr6,#ProcAlias",gen_send_ex",fcr",gr1,cr[01567]",gr0",gr4
  401| 0027D4 stw        90040000   1     ST4A      <s117:d0:l4>(gr4,0)=gr0                                                                                       545|                                CL.677:
  403| 0027D8 addi       38860001   1     AI        gr4=gr6,1                                                                                                        |               Tag Table
  403| 0027DC stw        90830000   1     ST4A      (*)_object._object.ob_refcnt(gr3,0)=gr4                                                                          | 002870        00000000 00002040 00000100 00000000 00000010 000C6765
  675| 0027E0 bclr       4E800020   0     BA        lr                                                                                                               | 002888        6E5F6974 65726E65 7874
     |               Tag Table                                                                                                                                       |               Instruction count            4
     | 0027E4        00000000 00002040 00000200 00000000 00000024 00106765                                                                                           |               Straight-line exec time      3
     | 0027FC        6E5F6765 745F7175 616C6E61 6D65                                                                                                             GPR's set/used:   ssus ssss ssss s---  ---- ---- ---- ---s
     |               Instruction count            9                                                                                                              FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----
     |               Straight-line exec time      9                                                                                                              CCR's set/used:   ss-- -sss







Wed Apr 15 07:30:04 CDT 2020  Page 105


 GPR's set/used:   ssus ssss ssss s---  ---- ---- ---- ----                                                                                                          | 000000                             PDEF       gen_throw
 FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----                                                                                                       527|                                    PROC       gen,args,gr3,gr4
 CCR's set/used:   ss-- -sss                                                                                                                                        0| 0028A0 mfspr      7C0802A6   1     LFLR       gr0=lr
     | 000000                             PDEF     gen_set_name                                                                                                   533| 0028A4 lwz        80A20018   1     L4A        gr5=.+CONSTANT_AREA(gr2,0)
  656|                                    PROC      op,value,_unused_ignored,gr3-gr5                                                                                0| 0028A8 stwu       9421FFB0   1     ST4U       gr1,#stack(gr1,-80)=gr1
    0| 002820 mfspr      7C0802A6   1     LFLR      gr0=lr                                                                                                        533| 0028AC addi       38C00003   1     LI         gr6=3
    0| 002824 ori        60660000   1     LR        gr6=gr3                                                                                                       533| 0028B0 addi       39210040   1     AI         gr9=gr1,64
    0| 002828 or.        7C842379   1     LR_R      gr4,cr0=gr4                                                                                                   533| 0028B4 addi       38E10048   1     AI         gr7=gr1,72
    0| 00282C stw        90010008   1     ST4A      #stack(gr1,8)=gr0                                                                                             533| 0028B8 addi       39010044   1     AI         gr8=gr1,68
    0| 002830 stwu       9421FF90   1     ST4U      gr1,#stack(gr1,-112)=gr1                                                                                        0| 0028BC stw        90010058   1     ST4A       #stack(gr1,88)=gr0
  660| 002834 bc         418200F8   0     BT        CL.2170,cr0,0x4/eq,taken=30%(30,70)                                                                             0| 0028C0 stw        93E1004C   1     ST4A       #stack(gr1,76)=gr31
  660| 002838 lwz        80640004   2     L4A       gr3=(*)_object._object.ob_type(gr4,4)                                                                         530| 0028C4 addi       38000000   1     LI         gr0=0
    0| 00283C stw        90C10064   1     ST4A      #parameter_store0(gr1,100)=gr6                                                                                  0| 0028C8 ori        607F0000   1     LR         gr31=gr3
    0| 002840 stw        90810068   1     ST4A      #parameter_store1(gr1,104)=gr4                                                                                533| 0028CC ori        60830000   1     LR         gr3=gr4
  617| 002844 bl         4BFFD7BD   0     CALL      gr3=PyType_GetFlags,1,(*)_typeobject",gr3,#ProcAlias",PyType_GetFlags",fcr",gr1,cr[01567]",gr0",gr4"-gr12",   533| 0028D0 addi       38850E4C   1     AI         gr4=gr5,3660
  617| 002848 ori        60000000   1                                                                                                                             533| 0028D4 addi       38A00001   1     LI         gr5=1
    0| 00284C lwz        80A20018   1     L4A       gr5=.+CONSTANT_AREA(gr2,0)                                                                                    531| 0028D8 stw        90010044   1     ST4A       val(gr1,68)=gr0
  401| 002850 lwz        80E20004   1     L4A       gr7=._Py_RefTotal(gr2,0)                                                                                      530| 0028DC stw        90010040   1     ST4A       tb(gr1,64)=gr0
  660| 002854 andis.     74601000   1     RN4_R     gr0,cr0=gr3,0,0x10000000                                                                                      533| 0028E0 bl         4BFFD721   0     CALL       gr3=PyArg_UnpackTuple,7,(*)_object",gr3-gr6,typ",gr7,val",gr8,tb",gr9,#ProcAlias",(*)_object",(*)_object",
  408| 002858 addi       38651124   1     AI        gr3=gr5,4388                                                                                                  533| 0028E4 ori        60000000   1
  617| 00285C lwz        80C10064   1     L4A       gr6=#parameter_store0(gr1,100)                                                                                533| 0028E8 cmpwi      2C030000   1     C4         cr0=gr3,0
  617| 002860 lwz        80810068   1     L4A       gr4=#parameter_store1(gr1,104)                                                                                534| 0028EC addi       38600000   1     LI         gr3=0
  660| 002864 bc         4182009C   0     BT        CL.1843,cr0,0x4/eq,taken=30%(30,70)                                                                           533| 0028F0 bc         41820048   0     BT         CL.2262,cr0,0x4/eq,taken=60%(60,40)
    0| 002868 lwz        80010078   2     L4A       gr0=#stack(gr1,120)                                                                                           537| 0028F4 lwz        80A10048   2     L4A        gr5=typ(gr1,72)
    0| 00286C mtspr      7C0803A6   2     LLR       lr=gr0                                                                                                        537| 0028F8 ori        63E30000   1     LR         gr3=gr31
  403| 002870 lwz        81040000   1     L4A       gr8=(*)_object._object.ob_refcnt(gr4,0)                                                                       537| 0028FC addi       38800001   1     LI         gr4=1
  666| 002874 lwz        80A60018   1     L4A       gr5=(*)aggr#3.gi_name(gr6,24)                                                                                 537| 002900 lwz        80C10044   1     L4A        gr6=val(gr1,68)
  666| 002878 stw        90860018   1     ST4A      (*)aggr#3.gi_name(gr6,24)=gr4                                                                                 537| 002904 lwz        80E10040   1     L4A        gr7=tb(gr1,64)
  401| 00287C lwz        80C70000   1     L4A       gr6=<s117:d0:l4>(gr7,0)                                                                                       537| 002908 stw        9361FFEC   1     ST4A       #stack_prune(gr1,-20)=gr27
    0| 002880 or.        7CA02B79   1     LR_R      gr0,cr0=gr5                                                                                                   537| 00290C stw        9381FFF0   1     ST4A       #stack_prune(gr1,-16)=gr28
  403| 002884 addi       39080001   1     AI        gr8=gr8,1                                                                                                     537| 002910 stw        93A1FFF4   1     ST4A       #stack_prune(gr1,-12)=gr29
  403| 002888 stw        91040000   1     ST4A      (*)_object._object.ob_refcnt(gr4,0)=gr8                                                                       537| 002914 bl         4800006D   0     CALL       gr3=IPRA.$_gen_throw,5,(*)aggr#3",gr3,gr4,(*)_object",gr5,(*)_object",gr6,(*)_object",gr7,#ProcAlias",IPRA
  401| 00288C addi       38060001   1     AI        gr0=gr6,1                                                                                                     537| 002918 lwz        83A1FFF4   1     L4A        gr29=#stack_prune(gr1,-12)
  401| 002890 stw        90070000   1     ST4A      <s117:d0:l4>(gr7,0)=gr0                                                                                       537| 00291C lwz        8381FFF0   1     L4A        gr28=#stack_prune(gr1,-16)
  491| 002894 bc         41820020   0     BT        CL.1845,cr0,0x4/eq,taken=30%(30,70)                                                                           537| 002920 lwz        8361FFEC   1     L4A        gr27=#stack_prune(gr1,-20)
  415| 002898 stw        90C70000   1     ST4A      <s117:d0:l4>(gr7,0)=gr6                                                                                         0| 002924 lwz        83E1004C   1     L4A        gr31=#stack(gr1,76)
  417| 00289C lwz        80850000   1     L4A       gr4=(*)_object._object.ob_refcnt(gr5,0)                                                                         0| 002928 lwz        80010058   1     L4A        gr0=#stack(gr1,88)
  417| 0028A0 addi       3804FFFF   2     AI        gr0=gr4,-1                                                                                                    538| 00292C addi       38210050   1     AI         gr1=gr1,80
  417| 0028A4 stw        90050000   1     ST4A      (*)_object._object.ob_refcnt(gr5,0)=gr0                                                                         0| 002930 mtspr      7C0803A6   1     LLR        lr=gr0
  417| 0028A8 cmpwi      2C000000   1     C4        cr0=gr0,0                                                                                                     538| 002934 bclr       4E800020   3     BA         lr
  417| 0028AC bc         41820034   1     BT        CL.1305,cr0,0x4/eq,taken=40%(40,60)                                                                             0|                                CL.2262:
  419| 0028B0 bc         41800010   1     BT        CL.2171,cr0,0x1/lt,taken=40%(40,60)                                                                             0| 002938 lwz        80010058   1     L4A        gr0=#stack(gr1,88)
    0|                                CL.1845:                                                                                                                      0| 00293C lwz        83E1004C   1     L4A        gr31=#stack(gr1,76)
  667| 0028B4 addi       38600000   1     LI        gr3=0                                                                                                         538| 002940 addi       38210050   1     AI         gr1=gr1,80
  668| 0028B8 addi       38210070   1     AI        gr1=gr1,112                                                                                                     0| 002944 mtspr      7C0803A6   1     LLR        lr=gr0
  668| 0028BC bclr       4E800020   0     BA        lr                                                                                                            538| 002948 bclr       4E800020   3     BA         lr
    0|                                CL.2171:                                                                                                                       |               Tag Table
  420| 0028C0 addi       388001EC   1     LI        gr4=492                                                                                                          | 00294C        00000000 00002041 80010200 00000000 000000AC 00096765
  420| 0028C4 bl         4BFFD73D   0     CALL      _Py_NegativeRefcount,3,(*)Cuchar",gr3,gr4,(*)_object",gr5,#ProcAlias",_Py_NegativeRefcount",fcr",gr1,cr[015      | 002964        6E5F7468 726F77
  420| 0028C8 ori        60000000   1                                                                                                                                |               Instruction count           43
  667| 0028CC addi       38600000   1     LI        gr3=0                                                                                                            |               Straight-line exec time     45
    0| 0028D0 lwz        80010078   1     L4A       gr0=#stack(gr1,120)                                                                                          GPR's set/used:   ssus ssss ssss s---  ---- ---- ---s ssss
  668| 0028D4 addi       38210070   1     AI        gr1=gr1,112                                                                                                  FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----
    0| 0028D8 mtspr      7C0803A6   1     LLR       lr=gr0                                                                                                       CCR's set/used:   ss-- -sss
  668| 0028DC bclr       4E800020   3     BA        lr                                                                                                               | 000000                             PDEF       IPRA.$_gen_throw
  423|                                CL.1305:                                                                                                                    399|                                    PROC       gen,close_on_genexit,typ,val,tb,gr3-gr7







Wed Apr 15 07:30:04 CDT 2020  Page 106


  425| 0028E0 ori        60A30000   1     LR        gr3=gr5                                                                                                         0| 002980 mfspr      7C0802A6   1     LFLR       gr0=lr
  425| 0028E4 bl         4BFFD71D   0     CALL      _Py_Dealloc,1,(*)_object",gr3,#ProcAlias",_Py_Dealloc",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",l     0| 002984 stwu       9421FF80   1     ST4U       gr1,#stack(gr1,-128)=gr1
  425| 0028E8 ori        60000000   1                                                                                                                               0| 002988 stw        90010088   1     ST4A       #stack(gr1,136)=gr0
  667| 0028EC addi       38600000   1     LI        gr3=0                                                                                                           0| 00298C ori        607F0000   1     LR         gr31=gr3
    0| 0028F0 lwz        80010078   1     L4A       gr0=#stack(gr1,120)                                                                                             0| 002990 stw        93C10078   1     ST4A       #stack(gr1,120)=gr30
  668| 0028F4 addi       38210070   1     AI        gr1=gr1,112                                                                                                     0| 002994 ori        609D0000   1     LR         gr29=gr4
    0| 0028F8 mtspr      7C0803A6   1     LLR       lr=gr0                                                                                                          0| 002998 stw        90A100A0   1     ST4A       typ(gr1,160)=gr5
  668| 0028FC bclr       4E800020   3     BA        lr                                                                                                              0| 00299C stw        90C100A4   1     ST4A       val(gr1,164)=gr6
    0|                                CL.1843:                                                                                                                      0| 0029A0 stw        90E100A8   1     ST4A       tb(gr1,168)=gr7
  661| 002900 lwz        806200B4   1     L4A       gr3=.PyExc_TypeError(gr2,0)                                                                                   402| 0029A4 bl         48002F3D   0     CALL       gr3=_PyGen_yf,1,(*)aggr#3",gr3,#ProcAlias",_PyGen_yf",fcr",gr1,cr[01567]",gr0",gr4"-gr12",fp0"-fp13",mq",l
  661| 002904 ori        60A40000   1     LR        gr4=gr5                                                                                                       405| 0029A8 cmpwi      2C030000   1     C4         cr0=gr3,0
  661| 002908 addi       388416A0   1     AI        gr4=gr4,5792                                                                                                  405| 0029AC bc         408203C4   1     BF         CL.2240,cr0,0x4/eq,taken=40%(40,60)
  661| 00290C lwz        80630000   1     L4A       gr3=<s145:d0:l4>(gr3,0)                                                                                         0|                                CL.2261:
  661| 002910 bl         4BFFD6F1   0     CALL      PyErr_SetString,2,(*)_object",gr3,gr4,#ProcAlias",PyErr_SetString",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"   467|                                throw_here:
  661| 002914 ori        60000000   1                                                                                                                             470| 0029B0 lwz        806100A8   1     L4A        gr3=tb(gr1,168)
  663| 002918 addi       3860FFFF   1     LI        gr3=-1                                                                                                        470| 0029B4 lwz        80020008   1     L4A        gr0=._Py_NoneStruct(gr2,0)
    0| 00291C lwz        80010078   1     L4A       gr0=#stack(gr1,120)                                                                                             0| 0029B8 ori        60640000   1     LR         gr4=gr3
  668| 002920 addi       38210070   1     AI        gr1=gr1,112                                                                                                   470| 0029BC cmplw      7C001840   1     CL4        cr0=gr0,gr3
    0| 002924 mtspr      7C0803A6   1     LLR       lr=gr0                                                                                                        470| 0029C0 bc         40820368   1     BF         CL.244,cr0,0x4/eq,taken=50%(0,0)
  668| 002928 bclr       4E800020   3     BA        lr                                                                                                            471| 0029C4 addi       38600000   2     LI         gr3=0
    0|                                CL.2170:                                                                                                                    471| 0029C8 stw        906100A8   1     ST4A       tb(gr1,168)=gr3
  661| 00292C lwz        806200B4   1     L4A       gr3=.PyExc_TypeError(gr2,0)                                                                                   477|                                CL.245:
  661| 002930 lwz        80820018   1     L4A       gr4=.+CONSTANT_AREA(gr2,0)                                                                                    479| 0029CC lwz        808100A0   1     L4A        gr4=typ(gr1,160)
  661| 002934 addi       388416A0   2     AI        gr4=gr4,5792                                                                                                  401| 0029D0 lwz        83C20004   1     L4A        gr30=._Py_RefTotal(gr2,0)
  661| 002938 lwz        80630000   1     L4A       gr3=<s145:d0:l4>(gr3,0)                                                                                       480| 0029D4 lwz        80A100A4   1     L4A        gr5=val(gr1,164)
  661| 00293C bl         4BFFD6C5   0     CALL      PyErr_SetString,2,(*)_object",gr3,gr4,#ProcAlias",PyErr_SetString",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"     0| 0029D8 or.        7CA02B79   2     LR_R       gr0,cr0=gr5
  661| 002940 ori        60000000   1                                                                                                                             401| 0029DC lwz        80DE0000   1     L4A        gr6=_Py_RefTotal(gr30,0)
  663| 002944 addi       3860FFFF   1     LI        gr3=-1                                                                                                        403| 0029E0 lwz        80E40000   1     L4A        gr7=(*)_object._object.ob_refcnt(gr4,0)
    0| 002948 lwz        80010078   1     L4A       gr0=#stack(gr1,120)                                                                                           401| 0029E4 addi       39060001   1     AI         gr8=gr6,1
  668| 00294C addi       38210070   1     AI        gr1=gr1,112                                                                                                   401| 0029E8 stw        911E0000   1     ST4A       _Py_RefTotal(gr30,0)=gr8
    0| 002950 mtspr      7C0803A6   1     LLR       lr=gr0                                                                                                        403| 0029EC addi       38070001   1     AI         gr0=gr7,1
  668| 002954 bclr       4E800020   3     BA        lr                                                                                                            403| 0029F0 stw        90040000   1     ST4A       (*)_object._object.ob_refcnt(gr4,0)=gr0
     |               Tag Table                                                                                                                                    482| 0029F4 bc         41820018   0     BT         CL.1263,cr0,0x4/eq,taken=30%(30,70)
     | 002958        00000000 00002041 80000300 00000000 00000138 000C6765                                                                                        401| 0029F8 addi       39060002   1     AI         gr8=gr6,2
     | 002970        6E5F7365 745F6E61 6D65                                                                                                                       401| 0029FC stw        911E0000   1     ST4A       _Py_RefTotal(gr30,0)=gr8
     |               Instruction count           78                                                                                                               403| 002A00 lwz        80C50000   1     L4A        gr6=(*)_object._object.ob_refcnt(gr5,0)
     |               Straight-line exec time     82                                                                                                               403| 002A04 addi       38060001   2     AI         gr0=gr6,1
 GPR's set/used:   s-us sss- ---- ----  ---- ---- ---- ----                                                                                                       403| 002A08 stw        90050000   1     ST4A       (*)_object._object.ob_refcnt(gr5,0)=gr0
 FPR's set/used:   ---- ---- ---- ----  ---- ---- ---- ----                                                                                                       484|                                CL.1263:
 CCR's set/used:   ---- ----                                                                                                                                      482| 002A0C cmpwi      2C030000   1     C4         cr0=gr3,0
     | 000000                             PDEF     gen_get_name                                                                                                   482| 002A10 bc         41820018   1     BT         CL.1266,cr0,0x4/eq,taken=30%(30,70)
  649|                                    PROC      op,_unused_ignored,gr3,gr4                                                                                    401| 002A14 addi       38080001   2     AI         gr0=gr8,1
  651| 002980 lwz        80630018   1     L4A       gr3=(*)aggr#3.gi_name(gr3,24)                                                                                 401| 002A18 stw        901E0000   1     ST4A       _Py_RefTotal(gr30,0)=gr0
  401| 002984 lwz        80820004   1     L4A       gr4=._Py_RefTotal(gr2,0)                                                                                      403| 002A1C lwz        80A30000   1     L4A        gr5=(*)_object._object.ob_refcnt(gr3,0)
  401| 002988 lwz        80A40000   2     L4A       gr5=<s117:d0:l4>(gr4,0)                                                                                       403| 002A20 addi       38050001   2     AI         gr0=gr5,1
  403| 00298C lwz        80C30000   1     L4A       gr6=(*)_object._object.ob_refcnt(gr3,0)                                                                       403| 002A24 stw        90030000   1     ST4A       (*)_object._object.ob_refcnt(gr3,0)=gr0
  401| 002990 addi       38050001   1     AI        gr0=gr5,1                                                                                                     484|                                CL.1266:
  401| 002994 stw        90040000   1     ST4A      <s117:d0:l4>(gr4,0)=gr0                                                                                       623| 002A28 lwz        80640004   1     L4A        gr3=(*)_object._object.ob_type(gr4,4)
  403| 002998 addi       38860001   1     AI        gr4=gr6,1                                                                                                     617| 002A2C bl         4BFFD5D5   0     CALL       gr3=PyType_GetFlags,1,(*)_typeobject",gr3,#ProcAlias",PyType_GetFlags",fcr",gr1,cr[01567]",gr0",gr4"-gr12"
  403| 00299C stw        90830000   1     ST4A      (*)_object._object.ob_refcnt(gr3,0)=gr4                                                                       617| 002A30 ori        60000000   1
  653| 0029A0 bclr       4E800020   0     BA        lr                                                                                                            617| 002A34 andis.     74608000   1     RN4_R      gr0,cr0=gr3,0,0xFFFFFFFF80000000
     |               Tag Table                                                                                                                                    483| 002A38 bc         41820068   1     BT         CL.247,cr0,0x4/eq,taken=50%(0,0)
     | 0029A4        00000000 00002040 00000200 00000000 00000024 000C6765                                                                                        483| 002A3C lwz        806100A0   2     L4A        gr3=typ(gr1,160)
     | 0029BC        6E5F6765 745F6E61 6D65                                                                                                                       617| 002A40 bl         4BFFD5C1   0     CALL       gr3=PyType_GetFlags,1,(*)_typeobject",gr3,#ProcAlias",PyType_GetFlags",fcr",gr1,cr[01567]",gr0",gr4"-gr12"
     |               Instruction count            9                                                                                                               617| 002A44 ori        60000000   1
     |               Straight-line exec time      9                                                                                                               617| 002A48 andis.     74604000   1     RN4_R      gr0,cr0=gr3,0,0x40000000







Wed Apr 15 07:30:04 CDT 2020  Page 107


 GPR's set/used:   ssus ssss ssss s---  ---- ---- ---- ----                                                                                                       483| 002A4C bc         41820054   1     BT         CL.247,cr0,0x4/eq,taken=50%(0,0)
 FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----                                                                                                       484| 002A50 addi       386100A0   2     LA         gr3=typ(gr1,160)
 CCR's set/used:   ss-- -sss                                                                                                                                      484| 002A54 addi       388100A4   1     LA         gr4=val(gr1,164)
     | 000000                             PDEF     gen_repr                                                                                                       484| 002A58 addi       38A100A8   1     LA         gr5=tb(gr1,168)
  642|                                    PROC      gen,gr3                                                                                                       484| 002A5C bl         4BFFD5A5   0     CALL       PyErr_NormalizeException,3,(*)_object*",gr3,(*)_object*",gr4,(*)_object*",gr5,#ProcAlias",(*)_object",(*)_
    0| 0029E0 mfspr      7C0802A6   1     LFLR      gr0=lr                                                                                                        484| 002A60 ori        60000000   1
  644| 0029E4 lwz        8083001C   1     L4A       gr4=(*)aggr#3.gi_qualname(gr3,28)                                                                               0| 002A64 lwz        806100A0   1     L4A        gr3=typ(gr1,160)
  644| 0029E8 ori        60650000   1     LR        gr5=gr3                                                                                                         0| 002A68 lwz        808100A4   1     L4A        gr4=val(gr1,164)
  644| 0029EC lwz        80620018   1     L4A       gr3=.+CONSTANT_AREA(gr2,0)                                                                                      0| 002A6C lwz        80A100A8   1     L4A        gr5=tb(gr1,168)
  644| 0029F0 addi       386316C8   2     AI        gr3=gr3,5832                                                                                                  512|                                CL.248:
    0| 0029F4 stw        90010008   1     ST4A      #stack(gr1,8)=gr0                                                                                             514| 002A70 bl         4BFFD591   0     CALL       PyErr_Restore,3,(*)_object",gr3,(*)_object",gr4,(*)_object",gr5,#ProcAlias",PyErr_Restore",fcr",gr1,cr[015
    0| 0029F8 stwu       9421FFC0   1     ST4U      gr1,#stack(gr1,-64)=gr1                                                                                       514| 002A74 ori        60000000   1
  644| 0029FC bl         4BFFD605   0     CALL      gr3=PyUnicode_FromFormat,3,gr3,(*)_object",gr4,(*)aggr#3",gr5,#ProcAlias",PyUnicode_FromFormat",fcr",gr1,cr   515| 002A78 ori        63E30000   1     LR         gr3=gr31
  644| 002A00 ori        60000000   1                                                                                                                             515| 002A7C lwz        80820008   1     L4A        gr4=._Py_NoneStruct(gr2,0)
    0| 002A04 lwz        80010048   1     L4A       gr0=#stack(gr1,72)                                                                                            515| 002A80 addi       38A00001   1     LI         gr5=1
  646| 002A08 addi       38210040   1     AI        gr1=gr1,64                                                                                                    515| 002A84 addi       38C00000   1     LI         gr6=0
    0| 002A0C mtspr      7C0803A6   1     LLR       lr=gr0                                                                                                        515| 002A88 bl         48000BF9   0     CALL       gr3=gen_send_ex,4,(*)aggr#3",gr3,(*)_object",gr4-gr6,#ProcAlias",gen_send_ex",fcr",gr1,cr[01567]",gr0",gr4
  646| 002A10 bclr       4E800020   3     BA        lr                                                                                                              0| 002A8C lwz        83C10078   1     L4A        gr30=#stack(gr1,120)
     |               Tag Table                                                                                                                                      0| 002A90 lwz        80010088   1     L4A        gr0=#stack(gr1,136)
     | 002A14        00000000 00002041 80000100 00000000 00000034 00086765                                                                                        523| 002A94 addi       38210080   1     AI         gr1=gr1,128
     | 002A2C        6E5F7265 7072                                                                                                                                  0| 002A98 mtspr      7C0803A6   1     LLR        lr=gr0
     |               Instruction count           13                                                                                                               523| 002A9C bclr       4E800020   3     BA         lr
     |               Straight-line exec time     15                                                                                                               484|                                CL.247:
 GPR's set/used:   su-s ssss ssss s---  ---- ---- ---- ----                                                                                                       486| 002AA0 lwz        806100A0   1     L4A        gr3=typ(gr1,160)
 FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----                                                                                                       486| 002AA4 lwz        80630004   2     L4A        gr3=(*)_object._object.ob_type(gr3,4)
 CCR's set/used:   ss-- -sss                                                                                                                                      617| 002AA8 bl         4BFFD559   0     CALL       gr3=PyType_GetFlags,1,(*)_typeobject",gr3,#ProcAlias",PyType_GetFlags",fcr",gr1,cr[01567]",gr0",gr4"-gr12"
     | 000000                             PDEF     gen_iternext                                                                                                   617| 002AAC ori        60000000   1
  542|                                    PROC      gen,gr3                                                                                                       617| 002AB0 andis.     74604000   1     RN4_R      gr0,cr0=gr3,0,0x40000000
  544| 002A40 addi       38800000   1     LI        gr4=0                                                                                                         486| 002AB4 bc         41820220   1     BT         CL.249,cr0,0x4/eq,taken=40%(40,60)
  544| 002A44 addi       38A00000   1     LI        gr5=0                                                                                                         488| 002AB8 lwz        80A100A4   2     L4A        gr5=val(gr1,164)
  544| 002A48 addi       38C00000   1     LI        gr6=0                                                                                                         488| 002ABC cmpwi      2C050000   2     C4         cr0=gr5,0
  545| 002A4C b          48000E14   0     CALLF     gr3=gen_send_ex,4,(*)aggr#3",gr3,(*)_object",gr4-gr6,#ProcAlias",gen_send_ex",fcr",gr1,cr[01567]",gr0",gr4"   488| 002AC0 bc         41820098   1     BT         CL.1279,cr0,0x4/eq,taken=50%(0,0)
  545|                                CL.677:                                                                                                                     488| 002AC4 lwz        80020008   1     L4A        gr0=._Py_NoneStruct(gr2,0)
     |               Tag Table                                                                                                                                    488| 002AC8 cmplw      7C802840   2     CL4        cr1=gr0,gr5
     | 002A50        00000000 00002040 00000100 00000000 00000010 000C6765                                                                                        488| 002ACC bc         408600A8   1     BF         CL.2253,cr1,0x4/eq,taken=40%(40,60)
     | 002A68        6E5F6974 65726E65 7874                                                                                                                         0| 002AD0 lwz        80DE0000   1     L4A        gr6=_Py_RefTotal(gr30,0)
     |               Instruction count            4                                                                                                               417| 002AD4 lwz        80650000   1     L4A        gr3=(*)_object._object.ob_refcnt(gr5,0)
     |               Straight-line exec time      3                                                                                                                 0| 002AD8 lwz        80820018   1     L4A        gr4=.+CONSTANT_AREA(gr2,0)
 GPR's set/used:   ssus ssss ssss s---  ---- ---- ---- ---s                                                                                                       415| 002ADC addi       38C6FFFF   1     AI         gr6=gr6,-1
 FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----                                                                                                       415| 002AE0 stw        90DE0000   1     ST4A       _Py_RefTotal(gr30,0)=gr6
 CCR's set/used:   ss-- -sss                                                                                                                                      417| 002AE4 addi       3803FFFF   1     AI         gr0=gr3,-1
     | 000000                             PDEF     gen_throw                                                                                                      417| 002AE8 stw        90050000   1     ST4A       (*)_object._object.ob_refcnt(gr5,0)=gr0
  527|                                    PROC      gen,args,gr3,gr4                                                                                              408| 002AEC addi       38641124   1     AI         gr3=gr4,4388
    0| 002A80 mfspr      7C0802A6   1     LFLR      gr0=lr                                                                                                        417| 002AF0 cmpwi      2C000000   1     C4         cr0=gr0,0
  533| 002A84 lwz        80A20018   1     L4A       gr5=.+CONSTANT_AREA(gr2,0)                                                                                    417| 002AF4 bc         4182006C   1     BT         CL.1278,cr0,0x4/eq,taken=40%(40,60)
  533| 002A88 addi       38C00003   1     LI        gr6=3                                                                                                         419| 002AF8 bc         41800054   1     BT         CL.2254,cr0,0x1/lt,taken=40%(40,60)
    0| 002A8C stw        90010008   1     ST4A      #stack(gr1,8)=gr0                                                                                             493|                                CL.1277:
    0| 002A90 stw        93E1FFFC   1     ST4A      #stack(gr1,-4)=gr31                                                                                           496| 002AFC lwz        808100A0   1     L4A        gr4=typ(gr1,160)
  530| 002A94 addi       38000000   1     LI        gr0=0                                                                                                         401| 002B00 addi       38060001   1     AI         gr0=gr6,1
    0| 002A98 ori        607F0000   1     LR        gr31=gr3                                                                                                      500| 002B04 lwz        80A100A8   1     L4A        gr5=tb(gr1,168)
    0| 002A9C stwu       9421FFB0   1     ST4U      gr1,#stack(gr1,-80)=gr1                                                                                       496| 002B08 stw        908100A4   1     ST4A       val(gr1,164)=gr4
  533| 002AA0 ori        60830000   1     LR        gr3=gr4                                                                                                       401| 002B0C stw        901E0000   1     ST4A       _Py_RefTotal(gr30,0)=gr0
  533| 002AA4 addi       39210040   1     AI        gr9=gr1,64                                                                                                    500| 002B10 cmpwi      2C050000   1     C4         cr0=gr5,0
  533| 002AA8 addi       38E10048   1     AI        gr7=gr1,72                                                                                                    497| 002B14 lwz        80640004   1     L4A        gr3=(*)_object._object.ob_type(gr4,4)
  533| 002AAC addi       39010044   1     AI        gr8=gr1,68                                                                                                    497| 002B18 stw        906100A0   2     ST4A       typ(gr1,160)=gr3
  533| 002AB0 addi       38850E4C   1     AI        gr4=gr5,3660                                                                                                  403| 002B1C lwz        80C30000   1     L4A        gr6=(*)_object._object.ob_refcnt(gr3,0)







Wed Apr 15 07:30:04 CDT 2020  Page 108


  533| 002AB4 addi       38A00001   1     LI        gr5=1                                                                                                         403| 002B20 addi       38060001   2     AI         gr0=gr6,1
  531| 002AB8 stw        90010044   1     ST4A      val(gr1,68)=gr0                                                                                               403| 002B24 stw        90030000   1     ST4A       (*)_object._object.ob_refcnt(gr3,0)=gr0
  530| 002ABC stw        90010040   1     ST4A      tb(gr1,64)=gr0                                                                                                500| 002B28 bc         4082FF48   0     BF         CL.248,cr0,0x4/eq,taken=60%(60,40)
  533| 002AC0 bl         4BFFD541   0     CALL      gr3=PyArg_UnpackTuple,7,(*)_object",gr3-gr6,typ",gr7,val",gr8,tb",gr9,#ProcAlias",(*)_object",(*)_object",(   502| 002B2C ori        60830000   1     LR         gr3=gr4
  533| 002AC4 ori        60000000   1                                                                                                                             502| 002B30 bl         4BFFD4D1   0     CALL       gr3=PyException_GetTraceback,1,(*)_object",gr3,#ProcAlias",PyException_GetTraceback",fcr",gr1,cr[01567]",g
  533| 002AC8 cmpwi      2C030000   1     C4        cr0=gr3,0                                                                                                     502| 002B34 ori        60000000   1
  534| 002ACC addi       38600000   1     LI        gr3=0                                                                                                         502| 002B38 ori        60650000   1     LR         gr5=gr3
  533| 002AD0 bc         41820048   0     BT        CL.2222,cr0,0x4/eq,taken=60%(60,40)                                                                           502| 002B3C stw        906100A8   1     ST4A       tb(gr1,168)=gr3
  537| 002AD4 lwz        80A10048   2     L4A       gr5=typ(gr1,72)                                                                                                 0| 002B40 lwz        808100A4   1     L4A        gr4=val(gr1,164)
  537| 002AD8 ori        63E30000   1     LR        gr3=gr31                                                                                                        0| 002B44 lwz        806100A0   1     L4A        gr3=typ(gr1,160)
  537| 002ADC addi       38800001   1     LI        gr4=1                                                                                                           0| 002B48 b          4BFFFF28   0     B          CL.248,-1
  537| 002AE0 lwz        80C10044   1     L4A       gr6=val(gr1,68)                                                                                                 0|                                CL.2254:
  537| 002AE4 lwz        80E10040   1     L4A       gr7=tb(gr1,64)                                                                                                420| 002B4C addi       388001EC   1     LI         gr4=492
  537| 002AE8 stw        9361FFEC   1     ST4A      #stack_prune(gr1,-20)=gr27                                                                                    420| 002B50 bl         4BFFD4B1   0     CALL       _Py_NegativeRefcount,3,(*)Cuchar",gr3,gr4,(*)_object",gr5,#ProcAlias",_Py_NegativeRefcount",fcr",gr1,cr[01
  537| 002AEC stw        9381FFF0   1     ST4A      #stack_prune(gr1,-16)=gr28                                                                                    420| 002B54 ori        60000000   1
  537| 002AF0 stw        93A1FFF4   1     ST4A      #stack_prune(gr1,-12)=gr29                                                                                    421|                                CL.1279:
  537| 002AF4 bl         4800006D   0     CALL      gr3=IPRA.$_gen_throw,5,(*)aggr#3",gr3,gr4,(*)_object",gr5,(*)_object",gr6,(*)_object",gr7,#ProcAlias",IPRA.     0| 002B58 lwz        80DE0000   1     L4A        gr6=_Py_RefTotal(gr30,0)
  537| 002AF8 lwz        83A1FFF4   1     L4A       gr29=#stack_prune(gr1,-12)                                                                                      0| 002B5C b          4BFFFFA0   0     B          CL.1277,-1
  537| 002AFC lwz        8381FFF0   1     L4A       gr28=#stack_prune(gr1,-16)                                                                                    423|                                CL.1278:
  537| 002B00 lwz        8361FFEC   1     L4A       gr27=#stack_prune(gr1,-20)                                                                                    425| 002B60 ori        60A30000   1     LR         gr3=gr5
    0| 002B04 lwz        83E1004C   1     L4A       gr31=#stack(gr1,76)                                                                                           425| 002B64 bl         4BFFD49D   0     CALL       _Py_Dealloc,1,(*)_object",gr3,#ProcAlias",_Py_Dealloc",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",
    0| 002B08 lwz        80010058   1     L4A       gr0=#stack(gr1,88)                                                                                            425| 002B68 ori        60000000   1
  538| 002B0C addi       38210050   1     AI        gr1=gr1,80                                                                                                      0| 002B6C lwz        80DE0000   1     L4A        gr6=_Py_RefTotal(gr30,0)
    0| 002B10 mtspr      7C0803A6   1     LLR       lr=gr0                                                                                                          0| 002B70 b          4BFFFF8C   0     B          CL.1277,-1
  538| 002B14 bclr       4E800020   3     BA        lr                                                                                                              0|                                CL.2253:
    0|                                CL.2222:                                                                                                                    489| 002B74 lwz        806200B4   1     L4A        gr3=.PyExc_TypeError(gr2,0)
    0| 002B18 lwz        80010058   1     L4A       gr0=#stack(gr1,88)                                                                                            489| 002B78 lwz        83E20018   1     L4A        gr31=.+CONSTANT_AREA(gr2,0)
    0| 002B1C lwz        83E1004C   1     L4A       gr31=#stack(gr1,76)                                                                                           489| 002B7C addi       389F12A4   2     AI         gr4=gr31,4772
  538| 002B20 addi       38210050   1     AI        gr1=gr1,80                                                                                                    489| 002B80 lwz        80630000   1     L4A        gr3=PyExc_TypeError(gr3,0)
    0| 002B24 mtspr      7C0803A6   1     LLR       lr=gr0                                                                                                        489| 002B84 bl         4BFFD47D   0     CALL       PyErr_SetString,2,(*)_object",gr3,gr4,#ProcAlias",PyErr_SetString",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0
  538| 002B28 bclr       4E800020   3     BA        lr                                                                                                            489| 002B88 ori        60000000   1
     |               Tag Table                                                                                                                                    519| 002B8C lwz        80A100A0   1     L4A        gr5=typ(gr1,160)
     | 002B2C        00000000 00002041 80010200 00000000 000000AC 00096765                                                                                        408| 002B90 addi       387F1110   1     AI         gr3=gr31,4368
     | 002B44        6E5F7468 726F77                                                                                                                              415| 002B94 lwz        809E0000   1     L4A        gr4=_Py_RefTotal(gr30,0)
     |               Instruction count           43                                                                                                               415| 002B98 addi       3804FFFF   2     AI         gr0=gr4,-1
     |               Straight-line exec time     45                                                                                                               415| 002B9C stw        901E0000   1     ST4A       _Py_RefTotal(gr30,0)=gr0
 GPR's set/used:   ssus ssss ssss s---  ---- ---- ---s ssss                                                                                                       417| 002BA0 lwz        80850000   1     L4A        gr4=(*)_object._object.ob_refcnt(gr5,0)
 FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----                                                                                                       417| 002BA4 addi       3804FFFF   2     AI         gr0=gr4,-1
 CCR's set/used:   ss-- -sss                                                                                                                                      417| 002BA8 stw        90050000   1     ST4A       (*)_object._object.ob_refcnt(gr5,0)=gr0
     | 000000                             PDEF     IPRA.$_gen_throw                                                                                               417| 002BAC cmpwi      2C000000   1     C4         cr0=gr0,0
  399|                                    PROC      gen,close_on_genexit,typ,val,tb,gr3-gr7                                                                       417| 002BB0 bc         41820114   1     BT         CL.1284,cr0,0x4/eq,taken=40%(40,60)
    0| 002B60 mfspr      7C0802A6   1     LFLR      gr0=lr                                                                                                          0| 002BB4 bc         40800010   1     BF         CL.1285,cr0,0x1/lt,taken=50%(0,0)
    0| 002B64 stw        90010008   2     ST4A      #stack(gr1,8)=gr0                                                                                               0|                                CL.2231:
    0| 002B68 ori        607F0000   1     LR        gr31=gr3                                                                                                      420| 002BB8 addi       38800207   1     LI         gr4=519
    0| 002B6C stw        93C1FFF8   1     ST4A      #stack(gr1,-8)=gr30                                                                                           420| 002BBC bl         4BFFD445   0     CALL       _Py_NegativeRefcount,3,(*)Cuchar",gr3,gr4,(*)_object",gr5,#ProcAlias",_Py_NegativeRefcount",fcr",gr1,cr[01
    0| 002B70 ori        609D0000   1     LR        gr29=gr4                                                                                                      420| 002BC0 ori        60000000   1
    0| 002B74 stwu       9421FF50   1     ST4U      gr1,#stack(gr1,-176)=gr1                                                                                      421|                                CL.1285:
    0| 002B78 stw        90A100D0   1     ST4A      typ(gr1,208)=gr5                                                                                              520| 002BC4 lwz        80A100A4   1     L4A        gr5=val(gr1,164)
    0| 002B7C stw        90C100D4   1     ST4A      val(gr1,212)=gr6                                                                                                0| 002BC8 or.        7CA02B79   2     LR_R       gr0,cr0=gr5
    0| 002B80 stw        90E100D8   1     ST4A      tb(gr1,216)=gr7                                                                                               491| 002BCC bc         4182002C   1     BT         CL.1288,cr0,0x4/eq,taken=30%(30,70)
  402| 002B84 bl         48002E7D   0     CALL      gr3=_PyGen_yf,1,(*)aggr#3",gr3,#ProcAlias",_PyGen_yf",fcr",gr1,cr[01567]",gr0",gr4"-gr12",fp0"-fp13",mq",lr   408| 002BD0 addi       387F1124   1     AI         gr3=gr31,4388
  405| 002B88 cmpwi      2C030000   1     C4        cr0=gr3,0                                                                                                     415| 002BD4 lwz        809E0000   1     L4A        gr4=_Py_RefTotal(gr30,0)
  405| 002B8C bc         408203CC   1     BF        CL.2200,cr0,0x4/eq,taken=40%(40,60)                                                                           415| 002BD8 addi       3804FFFF   2     AI         gr0=gr4,-1
    0|                                CL.2221:                                                                                                                    415| 002BDC stw        901E0000   1     ST4A       _Py_RefTotal(gr30,0)=gr0
  467|                                throw_here:                                                                                                                 417| 002BE0 lwz        80850000   1     L4A        gr4=(*)_object._object.ob_refcnt(gr5,0)
  470| 002B90 lwz        806100D8   1     L4A       gr3=tb(gr1,216)                                                                                               417| 002BE4 addi       3804FFFF   2     AI         gr0=gr4,-1







Wed Apr 15 07:30:04 CDT 2020  Page 109


  470| 002B94 lwz        80020008   1     L4A       gr0=._Py_NoneStruct(gr2,0)                                                                                    417| 002BE8 stw        90050000   1     ST4A       (*)_object._object.ob_refcnt(gr5,0)=gr0
    0| 002B98 ori        60640000   1     LR        gr4=gr3                                                                                                       417| 002BEC cmpwi      2C000000   1     C4         cr0=gr0,0
  470| 002B9C cmplw      7C001840   1     CL4       cr0=gr0,gr3                                                                                                   417| 002BF0 bc         418200C4   1     BT         CL.1289,cr0,0x4/eq,taken=40%(40,60)
  470| 002BA0 bc         40820370   1     BF        CL.244,cr0,0x4/eq,taken=50%(0,0)                                                                              419| 002BF4 bc         418000B0   1     BT         CL.2255,cr0,0x1/lt,taken=40%(40,60)
  471| 002BA4 addi       38600000   2     LI        gr3=0                                                                                                         493|                                CL.1288:
  471| 002BA8 stw        906100D8   1     ST4A      tb(gr1,216)=gr3                                                                                               521| 002BF8 lwz        80A100A8   1     L4A        gr5=tb(gr1,168)
  477|                                CL.245:                                                                                                                       0| 002BFC or.        7CA02B79   2     LR_R       gr0,cr0=gr5
  479| 002BAC lwz        808100D0   1     L4A       gr4=typ(gr1,208)                                                                                              491| 002C00 bc         4182008C   1     BT         CL.2239,cr0,0x4/eq,taken=30%(30,70)
  401| 002BB0 lwz        83C20004   1     L4A       gr30=._Py_RefTotal(gr2,0)                                                                                     408| 002C04 addi       387F1124   1     AI         gr3=gr31,4388
  480| 002BB4 lwz        80A100D4   1     L4A       gr5=val(gr1,212)                                                                                              415| 002C08 lwz        809E0000   1     L4A        gr4=_Py_RefTotal(gr30,0)
    0| 002BB8 or.        7CA02B79   2     LR_R      gr0,cr0=gr5                                                                                                   415| 002C0C addi       3804FFFF   2     AI         gr0=gr4,-1
  401| 002BBC lwz        80DE0000   1     L4A       gr6=<s117:d0:l4>(gr30,0)                                                                                      415| 002C10 stw        901E0000   1     ST4A       _Py_RefTotal(gr30,0)=gr0
  403| 002BC0 lwz        80E40000   1     L4A       gr7=(*)_object._object.ob_refcnt(gr4,0)                                                                       417| 002C14 lwz        80850000   1     L4A        gr4=(*)_object._object.ob_refcnt(gr5,0)
  401| 002BC4 addi       39060001   1     AI        gr8=gr6,1                                                                                                     417| 002C18 addi       3804FFFF   2     AI         gr0=gr4,-1
  401| 002BC8 stw        911E0000   1     ST4A      <s117:d0:l4>(gr30,0)=gr8                                                                                      417| 002C1C stw        90050000   1     ST4A       (*)_object._object.ob_refcnt(gr5,0)=gr0
  403| 002BCC addi       38070001   1     AI        gr0=gr7,1                                                                                                     417| 002C20 cmpwi      2C000000   1     C4         cr0=gr0,0
  403| 002BD0 stw        90040000   1     ST4A      (*)_object._object.ob_refcnt(gr4,0)=gr0                                                                       417| 002C24 bc         41820044   1     BT         CL.1295,cr0,0x4/eq,taken=40%(40,60)
  482| 002BD4 bc         41820018   0     BT        CL.1263,cr0,0x4/eq,taken=30%(30,70)                                                                           419| 002C28 bc         4180001C   1     BT         CL.2256,cr0,0x1/lt,taken=40%(40,60)
  401| 002BD8 addi       39060002   1     AI        gr8=gr6,2                                                                                                     522| 002C2C addi       38600000   1     LI         gr3=0
  401| 002BDC stw        911E0000   1     ST4A      <s117:d0:l4>(gr30,0)=gr8                                                                                        0| 002C30 lwz        83C10078   1     L4A        gr30=#stack(gr1,120)
  403| 002BE0 lwz        80C50000   1     L4A       gr6=(*)_object._object.ob_refcnt(gr5,0)                                                                         0| 002C34 lwz        80010088   1     L4A        gr0=#stack(gr1,136)
  403| 002BE4 addi       38060001   2     AI        gr0=gr6,1                                                                                                     523| 002C38 addi       38210080   1     AI         gr1=gr1,128
  403| 002BE8 stw        90050000   1     ST4A      (*)_object._object.ob_refcnt(gr5,0)=gr0                                                                         0| 002C3C mtspr      7C0803A6   1     LLR        lr=gr0
  484|                                CL.1263:                                                                                                                    523| 002C40 bclr       4E800020   3     BA         lr
  482| 002BEC cmpwi      2C030000   1     C4        cr0=gr3,0                                                                                                       0|                                CL.2256:
  482| 002BF0 bc         41820018   1     BT        CL.1266,cr0,0x4/eq,taken=30%(30,70)                                                                           420| 002C44 addi       388001EC   1     LI         gr4=492
  401| 002BF4 addi       38080001   2     AI        gr0=gr8,1                                                                                                     420| 002C48 bl         4BFFD3B9   0     CALL       _Py_NegativeRefcount,3,(*)Cuchar",gr3,gr4,(*)_object",gr5,#ProcAlias",_Py_NegativeRefcount",fcr",gr1,cr[01
  401| 002BF8 stw        901E0000   1     ST4A      <s117:d0:l4>(gr30,0)=gr0                                                                                      420| 002C4C ori        60000000   1
  403| 002BFC lwz        80A30000   1     L4A       gr5=(*)_object._object.ob_refcnt(gr3,0)                                                                       522| 002C50 addi       38600000   1     LI         gr3=0
  403| 002C00 addi       38050001   2     AI        gr0=gr5,1                                                                                                       0| 002C54 lwz        83C10078   1     L4A        gr30=#stack(gr1,120)
  403| 002C04 stw        90030000   1     ST4A      (*)_object._object.ob_refcnt(gr3,0)=gr0                                                                         0| 002C58 lwz        80010088   1     L4A        gr0=#stack(gr1,136)
  484|                                CL.1266:                                                                                                                    523| 002C5C addi       38210080   1     AI         gr1=gr1,128
  623| 002C08 lwz        80640004   1     L4A       gr3=(*)_object._object.ob_type(gr4,4)                                                                           0| 002C60 mtspr      7C0803A6   1     LLR        lr=gr0
  617| 002C0C bl         4BFFD3F5   0     CALL      gr3=PyType_GetFlags,1,(*)_typeobject",gr3,#ProcAlias",PyType_GetFlags",fcr",gr1,cr[01567]",gr0",gr4"-gr12",   523| 002C64 bclr       4E800020   3     BA         lr
  617| 002C10 ori        60000000   1                                                                                                                             423|                                CL.1295:
  617| 002C14 andis.     74608000   1     RN4_R     gr0,cr0=gr3,0,0xFFFFFFFF80000000                                                                              425| 002C68 ori        60A30000   1     LR         gr3=gr5
  483| 002C18 bc         41820068   1     BT        CL.247,cr0,0x4/eq,taken=50%(0,0)                                                                              425| 002C6C bl         4BFFD395   0     CALL       _Py_Dealloc,1,(*)_object",gr3,#ProcAlias",_Py_Dealloc",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",
  483| 002C1C lwz        806100D0   2     L4A       gr3=typ(gr1,208)                                                                                              425| 002C70 ori        60000000   1
  617| 002C20 bl         4BFFD3E1   0     CALL      gr3=PyType_GetFlags,1,(*)_typeobject",gr3,#ProcAlias",PyType_GetFlags",fcr",gr1,cr[01567]",gr0",gr4"-gr12",   522| 002C74 addi       38600000   1     LI         gr3=0
  617| 002C24 ori        60000000   1                                                                                                                               0| 002C78 lwz        83C10078   1     L4A        gr30=#stack(gr1,120)
  483| 002C28 andis.     74604000   1     RN4_R     gr0,cr0=gr3,0,0x40000000                                                                                        0| 002C7C lwz        80010088   1     L4A        gr0=#stack(gr1,136)
  483| 002C2C bc         41820054   1     BT        CL.247,cr0,0x4/eq,taken=50%(0,0)                                                                              523| 002C80 addi       38210080   1     AI         gr1=gr1,128
  484| 002C30 addi       38A100D8   2     LA        gr5=tb(gr1,216)                                                                                                 0| 002C84 mtspr      7C0803A6   1     LLR        lr=gr0
  484| 002C34 addi       388100D4   1     LA        gr4=val(gr1,212)                                                                                              523| 002C88 bclr       4E800020   3     BA         lr
  484| 002C38 addi       386100D0   1     LA        gr3=typ(gr1,208)                                                                                                0|                                CL.2239:
  484| 002C3C bl         4BFFD3C5   0     CALL      PyErr_NormalizeException,3,(*)_object*",gr3,(*)_object*",gr4,(*)_object*",gr5,#ProcAlias",(*)_object",(*)_o   522| 002C8C addi       38600000   1     LI         gr3=0
  484| 002C40 ori        60000000   1                                                                                                                               0| 002C90 lwz        83C10078   1     L4A        gr30=#stack(gr1,120)
    0| 002C44 lwz        806100D0   1     L4A       gr3=typ(gr1,208)                                                                                                0| 002C94 lwz        80010088   1     L4A        gr0=#stack(gr1,136)
    0| 002C48 lwz        808100D4   1     L4A       gr4=val(gr1,212)                                                                                              523| 002C98 addi       38210080   1     AI         gr1=gr1,128
    0| 002C4C lwz        80A100D8   1     L4A       gr5=tb(gr1,216)                                                                                                 0| 002C9C mtspr      7C0803A6   1     LLR        lr=gr0
  512|                                CL.248:                                                                                                                     523| 002CA0 bclr       4E800020   3     BA         lr
  514| 002C50 bl         4BFFD3B1   0     CALL      PyErr_Restore,3,(*)_object",gr3,(*)_object",gr4,(*)_object",gr5,#ProcAlias",PyErr_Restore",fcr",gr1,cr[0156     0|                                CL.2255:
  514| 002C54 ori        60000000   1                                                                                                                             420| 002CA4 addi       388001EC   1     LI         gr4=492
  515| 002C58 ori        63E30000   1     LR        gr3=gr31                                                                                                      420| 002CA8 bl         4BFFD359   0     CALL       _Py_NegativeRefcount,3,(*)Cuchar",gr3,gr4,(*)_object",gr5,#ProcAlias",_Py_NegativeRefcount",fcr",gr1,cr[01
  515| 002C5C lwz        80820008   1     L4A       gr4=._Py_NoneStruct(gr2,0)                                                                                    420| 002CAC ori        60000000   1
  515| 002C60 addi       38A00001   1     LI        gr5=1                                                                                                         423| 002CB0 b          4BFFFF48   0     B          CL.1288,-1







Wed Apr 15 07:30:04 CDT 2020  Page 110


  515| 002C64 addi       38C00000   1     LI        gr6=0                                                                                                         423|                                CL.1289:
  515| 002C68 bl         48000BF9   0     CALL      gr3=gen_send_ex,4,(*)aggr#3",gr3,(*)_object",gr4-gr6,#ProcAlias",gen_send_ex",fcr",gr1,cr[01567]",gr0",gr4"   425| 002CB4 ori        60A30000   1     LR         gr3=gr5
  523| 002C6C addi       382100B0   1     AI        gr1=gr1,176                                                                                                   425| 002CB8 bl         4BFFD349   0     CALL       _Py_Dealloc,1,(*)_object",gr3,#ProcAlias",_Py_Dealloc",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",
    0| 002C70 lwz        83C1FFF8   1     L4A       gr30=#stack(gr1,-8)                                                                                           425| 002CBC ori        60000000   1
    0| 002C74 lwz        80010008   1     L4A       gr0=#stack(gr1,8)                                                                                               0| 002CC0 b          4BFFFF38   0     B          CL.1288,-1
    0| 002C78 mtspr      7C0803A6   2     LLR       lr=gr0                                                                                                        423|                                CL.1284:
  523| 002C7C bclr       4E800020   3     BA        lr                                                                                                            425| 002CC4 ori        60A30000   1     LR         gr3=gr5
  484|                                CL.247:                                                                                                                     425| 002CC8 bl         4BFFD339   0     CALL       _Py_Dealloc,1,(*)_object",gr3,#ProcAlias",_Py_Dealloc",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",
  486| 002C80 lwz        806100D0   1     L4A       gr3=typ(gr1,208)                                                                                              425| 002CCC ori        60000000   1
  486| 002C84 lwz        80630004   2     L4A       gr3=(*)_object._object.ob_type(gr3,4)                                                                           0| 002CD0 b          4BFFFEF4   0     B          CL.1285,-1
  617| 002C88 bl         4BFFD379   0     CALL      gr3=PyType_GetFlags,1,(*)_typeobject",gr3,#ProcAlias",PyType_GetFlags",fcr",gr1,cr[01567]",gr0",gr4"-gr12",   504|                                CL.249:
  617| 002C8C ori        60000000   1                                                                                                                             507| 002CD4 lwz        806200B4   1     L4A        gr3=.PyExc_TypeError(gr2,0)
  486| 002C90 andis.     74604000   1     RN4_R     gr0,cr0=gr3,0,0x40000000                                                                                      507| 002CD8 lwz        80A100A0   1     L4A        gr5=typ(gr1,160)
  486| 002C94 bc         41820228   1     BT        CL.249,cr0,0x4/eq,taken=40%(40,60)                                                                            507| 002CDC lwz        83E20018   1     L4A        gr31=.+CONSTANT_AREA(gr2,0)
  488| 002C98 lwz        80A100D4   2     L4A       gr5=val(gr1,212)                                                                                              507| 002CE0 addi       389F12D8   2     AI         gr4=gr31,4824
  488| 002C9C cmpwi      2C050000   2     C4        cr0=gr5,0                                                                                                     507| 002CE4 lwz        80630000   1     L4A        gr3=PyExc_TypeError(gr3,0)
  488| 002CA0 bc         41820214   1     BT        CL.1646,cr0,0x4/eq,taken=50%(0,0)                                                                             507| 002CE8 lwz        80A50004   1     L4A        gr5=(*)_object._object.ob_type(gr5,4)
  488| 002CA4 lwz        80020008   1     L4A       gr0=._Py_NoneStruct(gr2,0)                                                                                    507| 002CEC lwz        80A5000C   2     L4A        gr5=(*)_typeobject._typeobject.tp_name(gr5,12)
  488| 002CA8 cmplw      7C802840   2     CL4       cr1=gr0,gr5                                                                                                   507| 002CF0 bl         4BFFD311   0     CALL       gr3=PyErr_Format,3,(*)_object",gr3,gr4,(*)Cuchar",gr5,#ProcAlias",PyErr_Format",fcr",gr1,cr[01567]",gr0",g
  488| 002CAC bc         408600A8   1     BF        CL.2214,cr1,0x4/eq,taken=40%(40,60)                                                                           507| 002CF4 ori        60000000   1
    0| 002CB0 lwz        80DE0000   1     L4A       gr6=<s117:d0:l4>(gr30,0)                                                                                      519| 002CF8 lwz        80A100A0   1     L4A        gr5=typ(gr1,160)
  417| 002CB4 lwz        80650000   1     L4A       gr3=(*)_object._object.ob_refcnt(gr5,0)                                                                       408| 002CFC addi       387F1110   1     AI         gr3=gr31,4368
    0| 002CB8 lwz        80820018   1     L4A       gr4=.+CONSTANT_AREA(gr2,0)                                                                                    415| 002D00 lwz        809E0000   1     L4A        gr4=_Py_RefTotal(gr30,0)
  415| 002CBC addi       38C6FFFF   1     AI        gr6=gr6,-1                                                                                                    415| 002D04 addi       3804FFFF   2     AI         gr0=gr4,-1
  415| 002CC0 stw        90DE0000   1     ST4A      <s117:d0:l4>(gr30,0)=gr6                                                                                      415| 002D08 stw        901E0000   1     ST4A       _Py_RefTotal(gr30,0)=gr0
  417| 002CC4 addi       3803FFFF   1     AI        gr0=gr3,-1                                                                                                    417| 002D0C lwz        80850000   1     L4A        gr4=(*)_object._object.ob_refcnt(gr5,0)
  417| 002CC8 stw        90050000   1     ST4A      (*)_object._object.ob_refcnt(gr5,0)=gr0                                                                       417| 002D10 addi       3804FFFF   2     AI         gr0=gr4,-1
  408| 002CCC addi       38641124   1     AI        gr3=gr4,4388                                                                                                  417| 002D14 stw        90050000   1     ST4A       (*)_object._object.ob_refcnt(gr5,0)=gr0
  417| 002CD0 cmpwi      2C000000   1     C4        cr0=gr0,0                                                                                                     417| 002D18 cmpwi      2C000000   1     C4         cr0=gr0,0
  417| 002CD4 bc         4182006C   1     BT        CL.1278,cr0,0x4/eq,taken=40%(40,60)                                                                           417| 002D1C bc         4182FFA8   1     BT         CL.1284,cr0,0x4/eq,taken=40%(40,60)
  419| 002CD8 bc         41800054   1     BT        CL.2215,cr0,0x1/lt,taken=40%(40,60)                                                                           419| 002D20 bc         4180FE98   1     BT         CL.2231,cr0,0x1/lt,taken=40%(40,60)
  493|                                CL.1277:                                                                                                                    419| 002D24 b          4BFFFEA0   1     B          CL.1285,-1
  496| 002CDC lwz        808100D0   1     L4A       gr4=typ(gr1,208)                                                                                              472|                                CL.244:
  401| 002CE0 addi       38060001   1     AI        gr0=gr6,1                                                                                                     473| 002D28 cmpwi      2C040000   1     C4         cr0=gr4,0
  500| 002CE4 lwz        80A100D8   1     L4A       gr5=tb(gr1,216)                                                                                               473| 002D2C bc         4182FCA0   1     BT         CL.245,cr0,0x4/eq,taken=30%(30,70)
  496| 002CE8 stw        908100D4   1     ST4A      val(gr1,212)=gr4                                                                                              473| 002D30 lwz        800200D0   2     L4A        gr0=.PyTraceBack_Type(gr2,0)
  401| 002CEC stw        901E0000   1     ST4A      <s117:d0:l4>(gr30,0)=gr0                                                                                      128| 002D34 lwz        80830004   1     L4A        gr4=(*)C_object._object.ob_type(gr3,4)
  500| 002CF0 cmpwi      2C050000   1     C4        cr0=gr5,0                                                                                                     128| 002D38 cmplw      7C040040   2     CL4        cr0=gr4,gr0
  497| 002CF4 lwz        80640004   1     L4A       gr3=(*)_object._object.ob_type(gr4,4)                                                                         473| 002D3C bc         4182FC90   1     BT         CL.245,cr0,0x4/eq,taken=70%(70,30)
  497| 002CF8 stw        906100D0   2     ST4A      typ(gr1,208)=gr3                                                                                              474| 002D40 lwz        806200B4   1     L4A        gr3=.PyExc_TypeError(gr2,0)
  403| 002CFC lwz        80C30000   1     L4A       gr6=(*)_object._object.ob_refcnt(gr3,0)                                                                       474| 002D44 lwz        80820018   1     L4A        gr4=.+CONSTANT_AREA(gr2,0)
  403| 002D00 addi       38060001   2     AI        gr0=gr6,1                                                                                                     474| 002D48 addi       38841270   2     AI         gr4=gr4,4720
  403| 002D04 stw        90030000   1     ST4A      (*)_object._object.ob_refcnt(gr3,0)=gr0                                                                       474| 002D4C lwz        80630000   1     L4A        gr3=PyExc_TypeError(gr3,0)
  500| 002D08 bc         4082FF48   0     BF        CL.248,cr0,0x4/eq,taken=60%(60,40)                                                                            474| 002D50 bl         4BFFD2B1   0     CALL       PyErr_SetString,2,(*)_object",gr3,gr4,#ProcAlias",PyErr_SetString",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0
  502| 002D0C ori        60830000   1     LR        gr3=gr4                                                                                                       474| 002D54 ori        60000000   1
  502| 002D10 bl         4BFFD2F1   0     CALL      gr3=PyException_GetTraceback,1,(*)_object",gr3,#ProcAlias",PyException_GetTraceback",fcr",gr1,cr[01567]",gr   476| 002D58 addi       38600000   1     LI         gr3=0
  502| 002D14 ori        60000000   1                                                                                                                               0| 002D5C lwz        83C10078   1     L4A        gr30=#stack(gr1,120)
  502| 002D18 ori        60650000   1     LR        gr5=gr3                                                                                                         0| 002D60 lwz        80010088   1     L4A        gr0=#stack(gr1,136)
  502| 002D1C stw        906100D8   1     ST4A      tb(gr1,216)=gr3                                                                                               523| 002D64 addi       38210080   1     AI         gr1=gr1,128
    0| 002D20 lwz        808100D4   1     L4A       gr4=val(gr1,212)                                                                                                0| 002D68 mtspr      7C0803A6   1     LLR        lr=gr0
    0| 002D24 lwz        806100D0   1     L4A       gr3=typ(gr1,208)                                                                                              523| 002D6C bclr       4E800020   3     BA         lr
    0| 002D28 b          4BFFFF28   0     B         CL.248,-1                                                                                                       0|                                CL.2240:
    0|                                CL.2215:                                                                                                                    402| 002D70 addi       3B800001   1     LI         gr28=1
  420| 002D2C addi       388001EC   1     LI        gr4=492                                                                                                       408| 002D74 lwz        80820028   1     L4A        gr4=.PyExc_GeneratorExit(gr2,0)
  420| 002D30 bl         4BFFD2D1   0     CALL      _Py_NegativeRefcount,3,(*)Cuchar",gr3,gr4,(*)_object",gr5,#ProcAlias",_Py_NegativeRefcount",fcr",gr1,cr[015   405| 002D78 ori        607E0000   1     LR         gr30=gr3
  420| 002D34 ori        60000000   1                                                                                                                             408| 002D7C lwz        806100A0   1     L4A        gr3=typ(gr1,160)







Wed Apr 15 07:30:04 CDT 2020  Page 111


    0| 002D38 lwz        80DE0000   1     L4A       gr6=<s117:d0:l4>(gr30,0)                                                                                      408| 002D80 lwz        80840000   1     L4A        gr4=PyExc_GeneratorExit(gr4,0)
  423| 002D3C b          4BFFFFA0   0     B         CL.1277,-1                                                                                                    408| 002D84 bl         4BFFD27D   0     CALL       gr3=PyErr_GivenExceptionMatches,2,(*)_object",gr3,(*)_object",gr4,#ProcAlias",PyErr_GivenExceptionMatches"
  423|                                CL.1278:                                                                                                                    408| 002D88 ori        60000000   1
  425| 002D40 ori        60A30000   1     LR        gr3=gr5                                                                                                       408| 002D8C cmpwi      2C030000   1     C4         cr0=gr3,0
  425| 002D44 bl         4BFFD2BD   0     CALL      _Py_Dealloc,1,(*)_object",gr3,#ProcAlias",_Py_Dealloc",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",l   408| 002D90 bc         4182000C   1     BT         CL.228,cr0,0x4/eq,taken=50%(0,0)
  425| 002D48 ori        60000000   1                                                                                                                             409| 002D94 cmpwi      2C1D0000   2     C4         cr0=gr29,0
    0| 002D4C lwz        80DE0000   1     L4A       gr6=<s117:d0:l4>(gr30,0)                                                                                      409| 002D98 bc         4082040C   1     BF         CL.2241,cr0,0x4/eq,taken=40%(40,60)
    0| 002D50 b          4BFFFF8C   0     B         CL.1277,-1                                                                                                    422|                                CL.228:
    0|                                CL.2214:                                                                                                                    423| 002D9C lwz        800200D4   1     L4A        gr0=.PyGen_Type(gr2,0)
  489| 002D54 lwz        806200B4   1     L4A       gr3=.PyExc_TypeError(gr2,0)                                                                                   128| 002DA0 lwz        807E0004   1     L4A        gr3=(*)C_object._object.ob_type(gr30,4)
  489| 002D58 lwz        83E20018   1     L4A       gr31=.+CONSTANT_AREA(gr2,0)                                                                                   128| 002DA4 cmplw      7C030040   2     CL4        cr0=gr3,gr0
  489| 002D5C addi       389F12A4   2     AI        gr4=gr31,4772                                                                                                 423| 002DA8 bc         4182039C   1     BT         CL.232,cr0,0x4/eq,taken=40%(40,60)
  489| 002D60 lwz        80630000   1     L4A       gr3=<s145:d0:l4>(gr3,0)                                                                                       423| 002DAC lwz        800200D8   1     L4A        gr0=.PyCoro_Type(gr2,0)
  489| 002D64 bl         4BFFD29D   0     CALL      PyErr_SetString,2,(*)_object",gr3,gr4,#ProcAlias",PyErr_SetString",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"   128| 002DB0 cmplw      7C030040   2     CL4        cr0=gr3,gr0
  489| 002D68 ori        60000000   1                                                                                                                             423| 002DB4 bc         41820390   1     BT         CL.232,cr0,0x4/eq,taken=50%(0,0)
  519| 002D6C lwz        80A100D0   1     L4A       gr5=typ(gr1,208)                                                                                              434| 002DB8 lwz        80820020   1     L4A        gr4=.$STATIC(gr2,0)
  408| 002D70 addi       387F1110   1     AI        gr3=gr31,4368                                                                                                 434| 002DBC ori        63C30000   1     LR         gr3=gr30
  415| 002D74 lwz        809E0000   1     L4A       gr4=<s117:d0:l4>(gr30,0)                                                                                      434| 002DC0 addi       38A10058   1     AI         gr5=gr1,88
  415| 002D78 addi       3804FFFF   2     AI        gr0=gr4,-1                                                                                                    434| 002DC4 addi       38840050   1     AI         gr4=gr4,80
  415| 002D7C stw        901E0000   1     ST4A      <s117:d0:l4>(gr30,0)=gr0                                                                                      434| 002DC8 bl         4BFFD239   0     CALL       gr3=_PyObject_LookupAttrId,3,(*)_object",gr3,(*)_Py_Identifier",gr4,(*)_object*",gr5,#ProcAlias",(*)_objec
  417| 002D80 lwz        80850000   1     L4A       gr4=(*)_object._object.ob_refcnt(gr5,0)                                                                       434| 002DCC ori        60000000   1
  417| 002D84 addi       3804FFFF   2     AI        gr0=gr4,-1                                                                                                    434| 002DD0 cmpwi      2C030000   1     C4         cr0=gr3,0
  417| 002D88 stw        90050000   1     ST4A      (*)_object._object.ob_refcnt(gr5,0)=gr0                                                                         0| 002DD4 lwz        83A20004   1     L4A        gr29=._Py_RefTotal(gr2,0)
  417| 002D8C cmpwi      2C000000   1     C4        cr0=gr0,0                                                                                                       0| 002DD8 lwz        83620018   1     L4A        gr27=.+CONSTANT_AREA(gr2,0)
  417| 002D90 bc         41820114   1     BT        CL.1284,cr0,0x4/eq,taken=40%(40,60)                                                                           434| 002DDC bc         418002DC   0     BT         CL.2244,cr0,0x1/lt,taken=40%(40,60)
    0| 002D94 bc         40800010   1     BF        CL.1285,cr0,0x1/lt,taken=50%(0,0)                                                                             438| 002DE0 lwz        80610058   2     L4A        gr3=meth(gr1,88)
    0|                                CL.2192:                                                                                                                    438| 002DE4 cmpwi      2C030000   2     C4         cr0=gr3,0
  420| 002D98 addi       38800207   1     LI        gr4=519                                                                                                       438| 002DE8 bc         41820280   1     BT         CL.2246,cr0,0x4/eq,taken=30%(30,70)
  420| 002D9C bl         4BFFD265   0     CALL      _Py_NegativeRefcount,3,(*)Cuchar",gr3,gr4,(*)_object",gr5,#ProcAlias",_Py_NegativeRefcount",fcr",gr1,cr[015   443| 002DEC lwz        808100A0   1     L4A        gr4=typ(gr1,160)
  420| 002DA0 ori        60000000   1                                                                                                                             443| 002DF0 lwz        80A100A4   1     L4A        gr5=val(gr1,164)
  421|                                CL.1285:                                                                                                                    442| 002DF4 stb        9B9F000C   1     ST1Z       (*)aggr#3.gi_running(gr31,12)=gr28
  520| 002DA4 lwz        80A100D4   1     L4A       gr5=val(gr1,212)                                                                                              443| 002DF8 addi       38E00000   1     LI         gr7=0
    0| 002DA8 or.        7CA02B79   2     LR_R      gr0,cr0=gr5                                                                                                   443| 002DFC lwz        80C100A8   1     L4A        gr6=tb(gr1,168)
  491| 002DAC bc         4182002C   1     BT        CL.1288,cr0,0x4/eq,taken=30%(30,70)                                                                           443| 002E00 bl         4BFFD201   0     CALL       gr3=PyObject_CallFunctionObjArgs,5,(*)_object",gr3,(*)_object",gr4,(*)_object",gr5,(*)_object",gr6,gr7,#Pr
  408| 002DB0 addi       387F1124   1     AI        gr3=gr31,4388                                                                                                 443| 002E04 ori        60000000   1
  415| 002DB4 lwz        809E0000   1     L4A       gr4=<s117:d0:l4>(gr30,0)                                                                                      443| 002E08 ori        607C0000   1     LR         gr28=gr3
  415| 002DB8 addi       3804FFFF   2     AI        gr0=gr4,-1                                                                                                    444| 002E0C addi       38000000   1     LI         gr0=0
  417| 002DBC lwz        80850000   1     L4A       gr4=(*)_object._object.ob_refcnt(gr5,0)                                                                       445| 002E10 lwz        80A10058   1     L4A        gr5=meth(gr1,88)
  415| 002DC0 stw        901E0000   1     ST4A      <s117:d0:l4>(gr30,0)=gr0                                                                                      415| 002E14 lwz        807D0000   1     L4A        gr3=_Py_RefTotal(gr29,0)
  417| 002DC4 addi       3804FFFF   1     AI        gr0=gr4,-1                                                                                                    415| 002E18 addi       3863FFFF   2     AI         gr3=gr3,-1
  417| 002DC8 stw        90050000   1     ST4A      (*)_object._object.ob_refcnt(gr5,0)=gr0                                                                       415| 002E1C stw        907D0000   1     ST4A       _Py_RefTotal(gr29,0)=gr3
  417| 002DCC cmpwi      2C000000   1     C4        cr0=gr0,0                                                                                                     444| 002E20 stb        981F000C   1     ST1Z       (*)aggr#3.gi_running(gr31,12)=gr0
  417| 002DD0 bc         418200C4   1     BT        CL.1289,cr0,0x4/eq,taken=40%(40,60)                                                                           417| 002E24 lwz        80850000   1     L4A        gr4=(*)_object._object.ob_refcnt(gr5,0)
  419| 002DD4 bc         418000B0   1     BT        CL.2216,cr0,0x1/lt,taken=40%(40,60)                                                                           417| 002E28 addi       3804FFFF   2     AI         gr0=gr4,-1
  493|                                CL.1288:                                                                                                                    417| 002E2C stw        90050000   1     ST4A       (*)_object._object.ob_refcnt(gr5,0)=gr0
  521| 002DD8 lwz        80A100D8   1     L4A       gr5=tb(gr1,216)                                                                                               417| 002E30 cmpwi      2C000000   1     C4         cr0=gr0,0
    0| 002DDC or.        7CA02B79   2     LR_R      gr0,cr0=gr5                                                                                                   417| 002E34 bc         4182021C   1     BT         CL.1244,cr0,0x4/eq,taken=40%(40,60)
  491| 002DE0 bc         4182008C   1     BT        CL.2199,cr0,0x4/eq,taken=30%(30,70)                                                                           419| 002E38 bc         418001FC   1     BT         CL.2248,cr0,0x1/lt,taken=40%(40,60)
  408| 002DE4 addi       387F1124   1     AI        gr3=gr31,4388                                                                                                 415| 002E3C addi       3803FFFF   1     AI         gr0=gr3,-1
  415| 002DE8 lwz        809E0000   1     L4A       gr4=<s117:d0:l4>(gr30,0)                                                                                      421|                                CL.1245:
  415| 002DEC addi       3804FFFF   2     AI        gr0=gr4,-1                                                                                                    415| 002E40 stw        901D0000   1     ST4A       _Py_RefTotal(gr29,0)=gr0
  417| 002DF0 lwz        80850000   1     L4A       gr4=(*)_object._object.ob_refcnt(gr5,0)                                                                       417| 002E44 lwz        807E0000   1     L4A        gr3=(*)_object._object.ob_refcnt(gr30,0)
  415| 002DF4 stw        901E0000   1     ST4A      <s117:d0:l4>(gr30,0)=gr0                                                                                      417| 002E48 addi       3803FFFF   2     AI         gr0=gr3,-1
  417| 002DF8 addi       3804FFFF   1     AI        gr0=gr4,-1                                                                                                    417| 002E4C stw        901E0000   1     ST4A       (*)_object._object.ob_refcnt(gr30,0)=gr0
  417| 002DFC stw        90050000   1     ST4A      (*)_object._object.ob_refcnt(gr5,0)=gr0                                                                       417| 002E50 cmpwi      2C000000   1     C4         cr0=gr0,0
  417| 002E00 cmpwi      2C000000   1     C4        cr0=gr0,0                                                                                                     417| 002E54 bc         418201D0   1     BT         CL.1248,cr0,0x4/eq,taken=40%(40,60)







Wed Apr 15 07:30:04 CDT 2020  Page 112


  417| 002E04 bc         41820044   1     BT        CL.1295,cr0,0x4/eq,taken=40%(40,60)                                                                             0| 002E58 bc         40800018   1     BF         CL.1249,cr0,0x1/lt,taken=50%(0,0)
  419| 002E08 bc         4180001C   1     BT        CL.2217,cr0,0x1/lt,taken=40%(40,60)                                                                             0|                                CL.2230:
  522| 002E0C addi       38600000   2     LI        gr3=0                                                                                                         420| 002E5C addi       387B1110   1     AI         gr3=gr27,4368
  523| 002E10 addi       382100B0   1     AI        gr1=gr1,176                                                                                                   420| 002E60 addi       388001BF   1     LI         gr4=447
    0| 002E14 lwz        83C1FFF8   1     L4A       gr30=#stack(gr1,-8)                                                                                           420| 002E64 ori        63C50000   1     LR         gr5=gr30
    0| 002E18 lwz        80010008   1     L4A       gr0=#stack(gr1,8)                                                                                             420| 002E68 bl         4BFFD199   0     CALL       _Py_NegativeRefcount,3,(*)Cuchar",gr3,gr4,(*)_object",gr5,#ProcAlias",_Py_NegativeRefcount",fcr",gr1,cr[01
    0| 002E1C mtspr      7C0803A6   2     LLR       lr=gr0                                                                                                        420| 002E6C ori        60000000   1
  523| 002E20 bclr       4E800020   3     BA        lr                                                                                                            421|                                CL.1249:
    0|                                CL.2217:                                                                                                                    448| 002E70 cmpwi      2C1C0000   1     C4         cr0=gr28,0
  420| 002E24 addi       388001EC   1     LI        gr4=492                                                                                                       448| 002E74 bc         40820198   1     BF         CL.2235,cr0,0x4/eq,taken=50%(0,0)
  420| 002E28 bl         4BFFD1D9   0     CALL      _Py_NegativeRefcount,3,(*)Cuchar",gr3,gr4,(*)_object",gr5,#ProcAlias",_Py_NegativeRefcount",fcr",gr1,cr[015   451| 002E78 lwz        809F0008   2     L4A        gr4=(*)aggr#3.gi_frame(gr31,8)
  420| 002E2C ori        60000000   1                                                                                                                             451| 002E7C lwz        80640024   2     L4A        gr3=(*)_frame._frame.f_stacktop(gr4,36)
  522| 002E30 addi       38600000   1     LI        gr3=0                                                                                                         451| 002E80 addi       3863FFFC   2     AI         gr3=gr3,-4
  523| 002E34 addi       382100B0   1     AI        gr1=gr1,176                                                                                                   451| 002E84 stw        90640024   1     ST4A       (*)_frame._frame.f_stacktop(gr4,36)=gr3
    0| 002E38 lwz        83C1FFF8   1     L4A       gr30=#stack(gr1,-8)                                                                                           451| 002E88 lwz        83830000   1     L4A        gr28=(*)_object*(gr3,0)
    0| 002E3C lwz        80010008   1     L4A       gr0=#stack(gr1,8)                                                                                             452| 002E8C cmplw      7C1EE040   2     CL4        cr0=gr30,gr28
    0| 002E40 mtspr      7C0803A6   2     LLR       lr=gr0                                                                                                        452| 002E90 bc         40820164   1     BF         CL.2249,cr0,0x4/eq,taken=40%(40,60)
  523| 002E44 bclr       4E800020   3     BA        lr                                                                                                            452|                                CL.239:
  423|                                CL.1295:                                                                                                                    415| 002E94 lwz        807D0000   1     L4A        gr3=_Py_RefTotal(gr29,0)
  425| 002E48 ori        60A30000   1     LR        gr3=gr5                                                                                                       417| 002E98 lwz        809C0000   1     L4A        gr4=(*)_object._object.ob_refcnt(gr28,0)
  425| 002E4C bl         4BFFD1B5   0     CALL      _Py_Dealloc,1,(*)_object",gr3,#ProcAlias",_Py_Dealloc",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",l   415| 002E9C addi       3803FFFF   1     AI         gr0=gr3,-1
  425| 002E50 ori        60000000   1                                                                                                                             415| 002EA0 stw        901D0000   1     ST4A       _Py_RefTotal(gr29,0)=gr0
  522| 002E54 addi       38600000   1     LI        gr3=0                                                                                                         417| 002EA4 addi       3864FFFF   1     AI         gr3=gr4,-1
  523| 002E58 addi       382100B0   1     AI        gr1=gr1,176                                                                                                   417| 002EA8 stw        907C0000   1     ST4A       (*)_object._object.ob_refcnt(gr28,0)=gr3
    0| 002E5C lwz        83C1FFF8   1     L4A       gr30=#stack(gr1,-8)                                                                                           417| 002EAC cmpwi      2C030000   1     C4         cr0=gr3,0
    0| 002E60 lwz        80010008   1     L4A       gr0=#stack(gr1,8)                                                                                             417| 002EB0 bc         41820134   1     BT         CL.1252,cr0,0x4/eq,taken=40%(40,60)
    0| 002E64 mtspr      7C0803A6   2     LLR       lr=gr0                                                                                                        419| 002EB4 bc         41800118   1     BT         CL.2250,cr0,0x1/lt,taken=40%(40,60)
  523| 002E68 bclr       4E800020   3     BA        lr                                                                                                            421|                                CL.1253:
    0|                                CL.2199:                                                                                                                    455| 002EB8 lwz        809F0008   1     L4A        gr4=(*)aggr#3.gi_frame(gr31,8)
  522| 002E6C addi       38600000   1     LI        gr3=0                                                                                                         455| 002EBC lwz        80640034   2     L4A        gr3=(*)_frame._frame.f_lasti(gr4,52)
  523| 002E70 addi       382100B0   1     AI        gr1=gr1,176                                                                                                   455| 002EC0 cmpwi      2C030000   2     C4         cr0=gr3,0
    0| 002E74 lwz        83C1FFF8   1     L4A       gr30=#stack(gr1,-8)                                                                                           455| 002EC4 bc         418000E8   1     BT         CL.2251,cr0,0x1/lt,taken=40%(40,60)
    0| 002E78 lwz        80010008   1     L4A       gr0=#stack(gr1,8)                                                                                             455|                                CL.241:
    0| 002E7C mtspr      7C0803A6   2     LLR       lr=gr0                                                                                                        456| 002EC8 addi       38030002   1     AI         gr0=gr3,2
  523| 002E80 bclr       4E800020   3     BA        lr                                                                                                            456| 002ECC stw        90040034   1     ST4A       (*)_frame._frame.f_lasti(gr4,52)=gr0
    0|                                CL.2216:                                                                                                                    457| 002ED0 addi       38610060   1     AI         gr3=gr1,96
  420| 002E84 addi       388001EC   1     LI        gr4=492                                                                                                       457| 002ED4 bl         48002BED   0     CALL       gr3=_PyGen_FetchStopIterationValue,1,(*)_object*",gr3,#ProcAlias",(*)_object",_PyGen_FetchStopIterationVal
  420| 002E88 bl         4BFFD179   0     CALL      _Py_NegativeRefcount,3,(*)Cuchar",gr3,gr4,(*)_object",gr5,#ProcAlias",_Py_NegativeRefcount",fcr",gr1,cr[015   457| 002ED8 cmpwi      2C030000   1     C4         cr0=gr3,0
  420| 002E8C ori        60000000   1                                                                                                                             457| 002EDC bc         408200A8   1     BF         CL.242,cr0,0x4/eq,taken=50%(0,0)
  423| 002E90 b          4BFFFF48   0     B         CL.1288,-1                                                                                                    458| 002EE0 lwz        80810060   2     L4A        gr4=val(gr1,96)
  423|                                CL.1289:                                                                                                                    458| 002EE4 addi       38A00000   1     LI         gr5=0
  425| 002E94 ori        60A30000   1     LR        gr3=gr5                                                                                                       458| 002EE8 ori        63E30000   1     LR         gr3=gr31
  425| 002E98 bl         4BFFD169   0     CALL      _Py_Dealloc,1,(*)_object",gr3,#ProcAlias",_Py_Dealloc",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",l   458| 002EEC addi       38C00000   1     LI         gr6=0
  425| 002E9C ori        60000000   1                                                                                                                             458| 002EF0 bl         48000791   0     CALL       gr3=gen_send_ex,4,(*)aggr#3",gr3,(*)_object",gr4-gr6,#ProcAlias",gen_send_ex",fcr",gr1,cr[01567]",gr0",gr4
    0| 002EA0 b          4BFFFF38   0     B         CL.1288,-1                                                                                                    458| 002EF4 ori        607C0000   1     LR         gr28=gr3
  423|                                CL.1284:                                                                                                                    459| 002EF8 lwz        80A10060   1     L4A        gr5=val(gr1,96)
  425| 002EA4 ori        60A30000   1     LR        gr3=gr5                                                                                                       415| 002EFC lwz        807D0000   1     L4A        gr3=_Py_RefTotal(gr29,0)
  425| 002EA8 bl         4BFFD159   0     CALL      _Py_Dealloc,1,(*)_object",gr3,#ProcAlias",_Py_Dealloc",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",l   415| 002F00 addi       3803FFFF   2     AI         gr0=gr3,-1
  425| 002EAC ori        60000000   1                                                                                                                             415| 002F04 stw        901D0000   1     ST4A       _Py_RefTotal(gr29,0)=gr0
    0| 002EB0 b          4BFFFEF4   0     B         CL.1285,-1                                                                                                    417| 002F08 lwz        80650000   1     L4A        gr3=(*)_object._object.ob_refcnt(gr5,0)
  492|                                CL.1646:                                                                                                                    417| 002F0C addi       3803FFFF   2     AI         gr0=gr3,-1
    0| 002EB4 lwz        80DE0000   1     L4A       gr6=<s117:d0:l4>(gr30,0)                                                                                      417| 002F10 stw        90050000   1     ST4A       (*)_object._object.ob_refcnt(gr5,0)=gr0
    0| 002EB8 b          4BFFFE24   0     B         CL.1277,-1                                                                                                    417| 002F14 cmpwi      2C000000   1     C4         cr0=gr0,0
  504|                                CL.249:                                                                                                                     417| 002F18 bc         41820048   1     BT         CL.1256,cr0,0x4/eq,taken=40%(40,60)
  507| 002EBC lwz        806200B4   1     L4A       gr3=.PyExc_TypeError(gr2,0)                                                                                   419| 002F1C bc         4180001C   1     BT         CL.2252,cr0,0x1/lt,taken=40%(40,60)
  507| 002EC0 lwz        80A100D0   1     L4A       gr5=typ(gr1,208)                                                                                              464| 002F20 ori        63830000   1     LR         gr3=gr28







Wed Apr 15 07:30:04 CDT 2020  Page 113


  507| 002EC4 lwz        83E20018   1     L4A       gr31=.+CONSTANT_AREA(gr2,0)                                                                                     0| 002F24 lwz        83C10078   1     L4A        gr30=#stack(gr1,120)
  507| 002EC8 addi       389F12D8   2     AI        gr4=gr31,4824                                                                                                   0| 002F28 lwz        80010088   1     L4A        gr0=#stack(gr1,136)
  507| 002ECC lwz        80630000   1     L4A       gr3=<s145:d0:l4>(gr3,0)                                                                                       523| 002F2C addi       38210080   1     AI         gr1=gr1,128
  507| 002ED0 lwz        80A50004   1     L4A       gr5=(*)_object._object.ob_type(gr5,4)                                                                           0| 002F30 mtspr      7C0803A6   1     LLR        lr=gr0
  507| 002ED4 lwz        80A5000C   2     L4A       gr5=(*)_typeobject._typeobject.tp_name(gr5,12)                                                                523| 002F34 bclr       4E800020   3     BA         lr
  507| 002ED8 bl         4BFFD129   0     CALL      gr3=PyErr_Format,3,(*)_object",gr3,gr4,(*)Cuchar",gr5,#ProcAlias",PyErr_Format",fcr",gr1,cr[01567]",gr0",gr     0|                                CL.2252:
  507| 002EDC ori        60000000   1                                                                                                                             420| 002F38 addi       387B1110   1     AI         gr3=gr27,4368
  519| 002EE0 lwz        80A100D0   1     L4A       gr5=typ(gr1,208)                                                                                              420| 002F3C addi       388001CB   1     LI         gr4=459
  408| 002EE4 addi       387F1110   1     AI        gr3=gr31,4368                                                                                                 420| 002F40 bl         4BFFD0C1   0     CALL       _Py_NegativeRefcount,3,(*)Cuchar",gr3,gr4,(*)_object",gr5,#ProcAlias",_Py_NegativeRefcount",fcr",gr1,cr[01
  415| 002EE8 lwz        809E0000   1     L4A       gr4=<s117:d0:l4>(gr30,0)                                                                                      420| 002F44 ori        60000000   1
  415| 002EEC addi       3804FFFF   2     AI        gr0=gr4,-1                                                                                                    464| 002F48 ori        63830000   1     LR         gr3=gr28
  415| 002EF0 stw        901E0000   1     ST4A      <s117:d0:l4>(gr30,0)=gr0                                                                                        0| 002F4C lwz        83C10078   1     L4A        gr30=#stack(gr1,120)
  417| 002EF4 lwz        80850000   1     L4A       gr4=(*)_object._object.ob_refcnt(gr5,0)                                                                         0| 002F50 lwz        80010088   1     L4A        gr0=#stack(gr1,136)
  417| 002EF8 addi       3804FFFF   2     AI        gr0=gr4,-1                                                                                                    523| 002F54 addi       38210080   1     AI         gr1=gr1,128
  417| 002EFC stw        90050000   1     ST4A      (*)_object._object.ob_refcnt(gr5,0)=gr0                                                                         0| 002F58 mtspr      7C0803A6   1     LLR        lr=gr0
  417| 002F00 cmpwi      2C000000   1     C4        cr0=gr0,0                                                                                                     523| 002F5C bclr       4E800020   3     BA         lr
  417| 002F04 bc         4182FFA0   1     BT        CL.1284,cr0,0x4/eq,taken=40%(40,60)                                                                           423|                                CL.1256:
  419| 002F08 bc         4180FE90   1     BT        CL.2192,cr0,0x1/lt,taken=40%(40,60)                                                                           425| 002F60 ori        60A30000   1     LR         gr3=gr5
  419| 002F0C b          4BFFFE98   1     B         CL.1285,-1                                                                                                    425| 002F64 bl         4BFFD09D   0     CALL       _Py_Dealloc,1,(*)_object",gr3,#ProcAlias",_Py_Dealloc",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",
  472|                                CL.244:                                                                                                                     425| 002F68 ori        60000000   1
  473| 002F10 cmpwi      2C040000   1     C4        cr0=gr4,0                                                                                                     464| 002F6C ori        63830000   1     LR         gr3=gr28
  473| 002F14 bc         4182FC98   1     BT        CL.245,cr0,0x4/eq,taken=30%(30,70)                                                                              0| 002F70 lwz        83C10078   1     L4A        gr30=#stack(gr1,120)
  473| 002F18 lwz        800200D0   2     L4A       gr0=.PyTraceBack_Type(gr2,0)                                                                                    0| 002F74 lwz        80010088   1     L4A        gr0=#stack(gr1,136)
  128| 002F1C lwz        80830004   1     L4A       gr4=(*)C_object._object.ob_type(gr3,4)                                                                        523| 002F78 addi       38210080   1     AI         gr1=gr1,128
  128| 002F20 cmplw      7C040040   2     CL4       cr0=gr4,gr0                                                                                                     0| 002F7C mtspr      7C0803A6   1     LLR        lr=gr0
  473| 002F24 bc         4182FC88   1     BT        CL.245,cr0,0x4/eq,taken=70%(70,30)                                                                            523| 002F80 bclr       4E800020   3     BA         lr
  474| 002F28 lwz        806200B4   1     L4A       gr3=.PyExc_TypeError(gr2,0)                                                                                   460|                                CL.242:
  474| 002F2C lwz        80820018   1     L4A       gr4=.+CONSTANT_AREA(gr2,0)                                                                                    461| 002F84 lwz        80820008   1     L4A        gr4=._Py_NoneStruct(gr2,0)
  474| 002F30 addi       38841270   2     AI        gr4=gr4,4720                                                                                                  461| 002F88 ori        63E30000   1     LR         gr3=gr31
  474| 002F34 lwz        80630000   1     L4A       gr3=<s145:d0:l4>(gr3,0)                                                                                       461| 002F8C addi       38A00001   1     LI         gr5=1
  474| 002F38 bl         4BFFD0C9   0     CALL      PyErr_SetString,2,(*)_object",gr3,gr4,#ProcAlias",PyErr_SetString",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"   461| 002F90 addi       38C00000   1     LI         gr6=0
  474| 002F3C ori        60000000   1                                                                                                                             461| 002F94 bl         480006ED   0     CALL       gr3=gen_send_ex,4,(*)aggr#3",gr3,(*)_object",gr4-gr6,#ProcAlias",gen_send_ex",fcr",gr1,cr[01567]",gr0",gr4
  476| 002F40 addi       38600000   1     LI        gr3=0                                                                                                           0| 002F98 lwz        83C10078   1     L4A        gr30=#stack(gr1,120)
  523| 002F44 addi       382100B0   1     AI        gr1=gr1,176                                                                                                     0| 002F9C lwz        80010088   1     L4A        gr0=#stack(gr1,136)
    0| 002F48 lwz        83C1FFF8   1     L4A       gr30=#stack(gr1,-8)                                                                                           523| 002FA0 addi       38210080   1     AI         gr1=gr1,128
    0| 002F4C lwz        80010008   1     L4A       gr0=#stack(gr1,8)                                                                                               0| 002FA4 mtspr      7C0803A6   1     LLR        lr=gr0
    0| 002F50 mtspr      7C0803A6   2     LLR       lr=gr0                                                                                                        523| 002FA8 bclr       4E800020   3     BA         lr
  523| 002F54 bclr       4E800020   3     BA        lr                                                                                                              0|                                CL.2251:
    0|                                CL.2200:                                                                                                                    455| 002FAC addi       387B1254   1     AI         gr3=gr27,4692
  402| 002F58 addi       3B800001   1     LI        gr28=1                                                                                                        455| 002FB0 addi       389B1110   1     AI         gr4=gr27,4368
  408| 002F5C lwz        80820028   1     L4A       gr4=.PyExc_GeneratorExit(gr2,0)                                                                               455| 002FB4 addi       38A001C7   1     LI         gr5=455
  402| 002F60 ori        607E0000   1     LR        gr30=gr3                                                                                                      455| 002FB8 bl         4BFFD049   0     CALL       __assert,3,gr3-gr5,#ProcAlias",__assert",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",lr",fcr",xer",
  408| 002F64 lwz        806100D0   1     L4A       gr3=typ(gr1,208)                                                                                              455| 002FBC ori        60000000   1
  408| 002F68 lwz        80840000   1     L4A       gr4=<s141:d0:l4>(gr4,0)                                                                                         0| 002FC0 lwz        809F0008   1     L4A        gr4=(*)aggr#3.gi_frame(gr31,8)
  408| 002F6C bl         4BFFD095   0     CALL      gr3=PyErr_GivenExceptionMatches,2,(*)_object",gr3,(*)_object",gr4,#ProcAlias",PyErr_GivenExceptionMatches",     0| 002FC4 lwz        80640034   2     L4A        gr3=(*)_frame._frame.f_lasti(gr4,52)
  408| 002F70 ori        60000000   1                                                                                                                               0| 002FC8 b          4BFFFF00   0     B          CL.241,-1
  408| 002F74 cmpwi      2C030000   1     C4        cr0=gr3,0                                                                                                       0|                                CL.2250:
  408| 002F78 bc         4182000C   1     BT        CL.228,cr0,0x4/eq,taken=50%(0,0)                                                                              420| 002FCC addi       387B1110   1     AI         gr3=gr27,4368
  409| 002F7C cmpwi      2C1D0000   2     C4        cr0=gr29,0                                                                                                    420| 002FD0 addi       388001C5   1     LI         gr4=453
  409| 002F80 bc         408203E8   1     BF        CL.2201,cr0,0x4/eq,taken=40%(40,60)                                                                           420| 002FD4 ori        63850000   1     LR         gr5=gr28
  422|                                CL.228:                                                                                                                     420| 002FD8 bl         4BFFD029   0     CALL       _Py_NegativeRefcount,3,(*)Cuchar",gr3,gr4,(*)_object",gr5,#ProcAlias",_Py_NegativeRefcount",fcr",gr1,cr[01
  423| 002F84 lwz        800200D4   1     L4A       gr0=.PyGen_Type(gr2,0)                                                                                        420| 002FDC ori        60000000   1
  128| 002F88 lwz        807E0004   1     L4A       gr3=(*)C_object._object.ob_type(gr30,4)                                                                       423| 002FE0 b          4BFFFED8   0     B          CL.1253,-1
  128| 002F8C cmplw      7C030040   2     CL4       cr0=gr3,gr0                                                                                                   423|                                CL.1252:
  423| 002F90 bc         41820398   1     BT        CL.232,cr0,0x4/eq,taken=40%(40,60)                                                                            425| 002FE4 ori        63830000   1     LR         gr3=gr28
  423| 002F94 lwz        800200D8   1     L4A       gr0=.PyCoro_Type(gr2,0)                                                                                       425| 002FE8 bl         4BFFD019   0     CALL       _Py_Dealloc,1,(*)_object",gr3,#ProcAlias",_Py_Dealloc",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",







Wed Apr 15 07:30:04 CDT 2020  Page 114


  128| 002F98 cmplw      7C030040   2     CL4       cr0=gr3,gr0                                                                                                   425| 002FEC ori        60000000   1
  423| 002F9C bc         4182038C   1     BT        CL.232,cr0,0x4/eq,taken=50%(0,0)                                                                                0| 002FF0 b          4BFFFEC8   0     B          CL.1253,-1
  434| 002FA0 lwz        80820020   1     L4A       gr4=.$STATIC(gr2,0)                                                                                             0|                                CL.2249:
  434| 002FA4 ori        63C30000   1     LR        gr3=gr30                                                                                                      452| 002FF4 addi       387B1248   1     AI         gr3=gr27,4680
  434| 002FA8 addi       38A1005C   1     AI        gr5=gr1,92                                                                                                    452| 002FF8 addi       389B1110   1     AI         gr4=gr27,4368
  434| 002FAC addi       38840050   1     AI        gr4=gr4,80                                                                                                    452| 002FFC addi       38A001C4   1     LI         gr5=452
  434| 002FB0 bl         4BFFD051   0     CALL      gr3=_PyObject_LookupAttrId,3,(*)_object",gr3,(*)_Py_Identifier",gr4,(*)_object*",gr5,#ProcAlias",(*)_object   452| 003000 bl         4BFFD001   0     CALL       __assert,3,gr3-gr5,#ProcAlias",__assert",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",lr",fcr",xer",
  434| 002FB4 ori        60000000   1                                                                                                                             452| 003004 ori        60000000   1
  434| 002FB8 cmpwi      2C030000   1     C4        cr0=gr3,0                                                                                                       0| 003008 b          4BFFFE8C   0     B          CL.239,-1
    0| 002FBC lwz        83A20004   1     L4A       gr29=._Py_RefTotal(gr2,0)                                                                                       0|                                CL.2235:
    0| 002FC0 lwz        83620018   1     L4A       gr27=.+CONSTANT_AREA(gr2,0)                                                                                   464| 00300C ori        63830000   1     LR         gr3=gr28
  434| 002FC4 bc         418002D8   0     BT        CL.2204,cr0,0x1/lt,taken=40%(40,60)                                                                             0| 003010 lwz        83C10078   1     L4A        gr30=#stack(gr1,120)
  438| 002FC8 lwz        8061005C   2     L4A       gr3=meth(gr1,92)                                                                                                0| 003014 lwz        80010088   1     L4A        gr0=#stack(gr1,136)
  438| 002FCC cmpwi      2C030000   2     C4        cr0=gr3,0                                                                                                     523| 003018 addi       38210080   1     AI         gr1=gr1,128
  438| 002FD0 bc         4182027C   1     BT        CL.2206,cr0,0x4/eq,taken=30%(30,70)                                                                             0| 00301C mtspr      7C0803A6   1     LLR        lr=gr0
  443| 002FD4 lwz        808100D0   1     L4A       gr4=typ(gr1,208)                                                                                              523| 003020 bclr       4E800020   3     BA         lr
  443| 002FD8 lwz        80A100D4   1     L4A       gr5=val(gr1,212)                                                                                              423|                                CL.1248:
  442| 002FDC stb        9B9F000C   1     ST1Z      (*)aggr#3.gi_running(gr31,12)=gr28                                                                            425| 003024 ori        63C30000   1     LR         gr3=gr30
  443| 002FE0 addi       38E00000   1     LI        gr7=0                                                                                                         425| 003028 bl         4BFFCFD9   0     CALL       _Py_Dealloc,1,(*)_object",gr3,#ProcAlias",_Py_Dealloc",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",
  443| 002FE4 lwz        80C100D8   1     L4A       gr6=tb(gr1,216)                                                                                               425| 00302C ori        60000000   1
  443| 002FE8 bl         4BFFD019   0     CALL      gr3=PyObject_CallFunctionObjArgs,5,(*)_object",gr3,(*)_object",gr4,(*)_object",gr5,(*)_object",gr6,gr7,#Pro     0| 003030 b          4BFFFE40   0     B          CL.1249,-1
  443| 002FEC ori        60000000   1                                                                                                                               0|                                CL.2248:
  443| 002FF0 ori        607C0000   1     LR        gr28=gr3                                                                                                      420| 003034 addi       387B1110   1     AI         gr3=gr27,4368
  444| 002FF4 addi       38000000   1     LI        gr0=0                                                                                                         420| 003038 addi       388001BD   1     LI         gr4=445
  445| 002FF8 lwz        80A1005C   1     L4A       gr5=meth(gr1,92)                                                                                              420| 00303C bl         4BFFCFC5   0     CALL       _Py_NegativeRefcount,3,(*)Cuchar",gr3,gr4,(*)_object",gr5,#ProcAlias",_Py_NegativeRefcount",fcr",gr1,cr[01
  415| 002FFC lwz        807D0000   1     L4A       gr3=<s117:d0:l4>(gr29,0)                                                                                      420| 003040 ori        60000000   1
  415| 003000 addi       3863FFFF   2     AI        gr3=gr3,-1                                                                                                      0| 003044 lwz        807D0000   1     L4A        gr3=_Py_RefTotal(gr29,0)
  415| 003004 stw        907D0000   1     ST4A      <s117:d0:l4>(gr29,0)=gr3                                                                                      415| 003048 addi       3803FFFF   2     AI         gr0=gr3,-1
  444| 003008 stb        981F000C   1     ST1Z      (*)aggr#3.gi_running(gr31,12)=gr0                                                                             423| 00304C b          4BFFFDF4   0     B          CL.1245,-1
  417| 00300C lwz        80850000   1     L4A       gr4=(*)_object._object.ob_refcnt(gr5,0)                                                                       423|                                CL.1244:
  417| 003010 addi       3804FFFF   2     AI        gr0=gr4,-1                                                                                                    425| 003050 ori        60A30000   1     LR         gr3=gr5
  417| 003014 stw        90050000   1     ST4A      (*)_object._object.ob_refcnt(gr5,0)=gr0                                                                       425| 003054 bl         4BFFCFAD   0     CALL       _Py_Dealloc,1,(*)_object",gr3,#ProcAlias",_Py_Dealloc",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",
  417| 003018 cmpwi      2C000000   1     C4        cr0=gr0,0                                                                                                     425| 003058 ori        60000000   1
  417| 00301C bc         4182021C   1     BT        CL.1244,cr0,0x4/eq,taken=40%(40,60)                                                                             0| 00305C lwz        807D0000   1     L4A        gr3=_Py_RefTotal(gr29,0)
  419| 003020 bc         41800200   1     BT        CL.2208,cr0,0x1/lt,taken=40%(40,60)                                                                           415| 003060 addi       3803FFFF   2     AI         gr0=gr3,-1
  446|                                CL.234:                                                                                                                       0| 003064 b          4BFFFDDC   0     B          CL.1245,-1
  415| 003024 addi       3803FFFF   1     AI        gr0=gr3,-1                                                                                                      0|                                CL.2246:
  415| 003028 stw        901D0000   1     ST4A      <s117:d0:l4>(gr29,0)=gr0                                                                                      415| 003068 lwz        807D0000   1     L4A        gr3=_Py_RefTotal(gr29,0)
  417| 00302C lwz        807E0000   1     L4A       gr3=(*)_object._object.ob_refcnt(gr30,0)                                                                      417| 00306C lwz        809E0000   1     L4A        gr4=(*)_object._object.ob_refcnt(gr30,0)
  417| 003030 addi       3803FFFF   2     AI        gr0=gr3,-1                                                                                                    415| 003070 addi       3803FFFF   1     AI         gr0=gr3,-1
  417| 003034 stw        901E0000   1     ST4A      (*)_object._object.ob_refcnt(gr30,0)=gr0                                                                      415| 003074 stw        901D0000   1     ST4A       _Py_RefTotal(gr29,0)=gr0
  417| 003038 cmpwi      2C000000   1     C4        cr0=gr0,0                                                                                                     417| 003078 addi       3864FFFF   1     AI         gr3=gr4,-1
  417| 00303C bc         418201D4   1     BT        CL.1248,cr0,0x4/eq,taken=40%(40,60)                                                                           417| 00307C stw        907E0000   1     ST4A       (*)_object._object.ob_refcnt(gr30,0)=gr3
  419| 003040 bc         418001B8   1     BT        CL.2209,cr0,0x1/lt,taken=40%(40,60)                                                                           417| 003080 cmpwi      2C030000   1     C4         cr0=gr3,0
  421|                                CL.1249:                                                                                                                    417| 003084 bc         41820024   1     BT         CL.1240,cr0,0x4/eq,taken=40%(40,60)
  448| 003044 cmpwi      2C1C0000   1     C4        cr0=gr28,0                                                                                                    419| 003088 bc         41800008   1     BT         CL.2247,cr0,0x1/lt,taken=40%(40,60)
  448| 003048 bc         40820198   1     BF        CL.2196,cr0,0x4/eq,taken=50%(0,0)                                                                               0| 00308C b          4BFFF924   2     B          throw_here,-1
  451| 00304C lwz        809F0008   2     L4A       gr4=(*)aggr#3.gi_frame(gr31,8)                                                                                  0|                                CL.2247:
  451| 003050 lwz        80640024   2     L4A       gr3=(*)_frame._frame.f_stacktop(gr4,36)                                                                       420| 003090 addi       387B1110   1     AI         gr3=gr27,4368
  451| 003054 addi       3863FFFC   2     AI        gr3=gr3,-4                                                                                                    420| 003094 addi       388001B7   1     LI         gr4=439
  451| 003058 stw        90640024   1     ST4A      (*)_frame._frame.f_stacktop(gr4,36)=gr3                                                                       420| 003098 ori        63C50000   1     LR         gr5=gr30
  451| 00305C lwz        83830000   1     L4A       gr28=(*)_object*(gr3,0)                                                                                       420| 00309C bl         4BFFCF65   0     CALL       _Py_NegativeRefcount,3,(*)Cuchar",gr3,gr4,(*)_object",gr5,#ProcAlias",_Py_NegativeRefcount",fcr",gr1,cr[01
  452| 003060 cmplw      7C1EE040   2     CL4       cr0=gr30,gr28                                                                                                 420| 0030A0 ori        60000000   1
  452| 003064 bc         40820164   1     BF        CL.2210,cr0,0x4/eq,taken=40%(40,60)                                                                           423| 0030A4 b          4BFFF90C   0     B          throw_here,-1
  452|                                CL.239:                                                                                                                     423|                                CL.1240:
  415| 003068 lwz        807D0000   1     L4A       gr3=<s117:d0:l4>(gr29,0)                                                                                      425| 0030A8 ori        63C30000   1     LR         gr3=gr30







Wed Apr 15 07:30:04 CDT 2020  Page 115


  417| 00306C lwz        809C0000   1     L4A       gr4=(*)_object._object.ob_refcnt(gr28,0)                                                                      425| 0030AC bl         4BFFCF55   0     CALL       _Py_Dealloc,1,(*)_object",gr3,#ProcAlias",_Py_Dealloc",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",
  415| 003070 addi       3803FFFF   1     AI        gr0=gr3,-1                                                                                                    425| 0030B0 ori        60000000   1
  415| 003074 stw        901D0000   1     ST4A      <s117:d0:l4>(gr29,0)=gr0                                                                                      440| 0030B4 b          4BFFF8FC   0     B          throw_here,-1
  417| 003078 addi       3864FFFF   1     AI        gr3=gr4,-1                                                                                                      0|                                CL.2244:
  417| 00307C stw        907C0000   1     ST4A      (*)_object._object.ob_refcnt(gr28,0)=gr3                                                                      417| 0030B8 lwz        807E0000   1     L4A        gr3=(*)_object._object.ob_refcnt(gr30,0)
  417| 003080 cmpwi      2C030000   1     C4        cr0=gr3,0                                                                                                     417| 0030BC addi       3803FFFF   2     AI         gr0=gr3,-1
  417| 003084 bc         41820134   1     BT        CL.1252,cr0,0x4/eq,taken=40%(40,60)                                                                           417| 0030C0 stw        901E0000   1     ST4A       (*)_object._object.ob_refcnt(gr30,0)=gr0
  419| 003088 bc         41800118   1     BT        CL.2211,cr0,0x1/lt,taken=40%(40,60)                                                                           415| 0030C4 lwz        807D0000   1     L4A        gr3=_Py_RefTotal(gr29,0)
  421|                                CL.1253:                                                                                                                    415| 0030C8 addi       3863FFFF   2     AI         gr3=gr3,-1
  455| 00308C lwz        809F0008   1     L4A       gr4=(*)aggr#3.gi_frame(gr31,8)                                                                                415| 0030CC stw        907D0000   1     ST4A       _Py_RefTotal(gr29,0)=gr3
  455| 003090 lwz        80640034   2     L4A       gr3=(*)_frame._frame.f_lasti(gr4,52)                                                                          417| 0030D0 cmpwi      2C000000   1     C4         cr0=gr0,0
  455| 003094 cmpwi      2C030000   2     C4        cr0=gr3,0                                                                                                     417| 0030D4 bc         4182004C   1     BT         CL.1236,cr0,0x4/eq,taken=40%(40,60)
  455| 003098 bc         418000E8   1     BT        CL.2212,cr0,0x1/lt,taken=40%(40,60)                                                                           419| 0030D8 bc         4180001C   1     BT         CL.2245,cr0,0x1/lt,taken=40%(40,60)
  455|                                CL.241:                                                                                                                     522| 0030DC addi       38600000   1     LI         gr3=0
  456| 00309C addi       38030002   1     AI        gr0=gr3,2                                                                                                       0| 0030E0 lwz        83C10078   1     L4A        gr30=#stack(gr1,120)
  456| 0030A0 stw        90040034   1     ST4A      (*)_frame._frame.f_lasti(gr4,52)=gr0                                                                            0| 0030E4 lwz        80010088   1     L4A        gr0=#stack(gr1,136)
  457| 0030A4 addi       38610064   1     AI        gr3=gr1,100                                                                                                   523| 0030E8 addi       38210080   1     AI         gr1=gr1,128
  457| 0030A8 bl         480029F9   0     CALL      gr3=_PyGen_FetchStopIterationValue,1,(*)_object*",gr3,#ProcAlias",(*)_object",_PyGen_FetchStopIterationValu     0| 0030EC mtspr      7C0803A6   1     LLR        lr=gr0
  457| 0030AC cmpwi      2C030000   1     C4        cr0=gr3,0                                                                                                     523| 0030F0 bclr       4E800020   3     BA         lr
  457| 0030B0 bc         408200A8   1     BF        CL.242,cr0,0x4/eq,taken=50%(0,0)                                                                                0|                                CL.2245:
  458| 0030B4 lwz        80810064   2     L4A       gr4=val(gr1,100)                                                                                              420| 0030F4 addi       387B1110   1     AI         gr3=gr27,4368
  458| 0030B8 addi       38A00000   1     LI        gr5=0                                                                                                         420| 0030F8 addi       388001B3   1     LI         gr4=435
  458| 0030BC ori        63E30000   1     LR        gr3=gr31                                                                                                      420| 0030FC ori        63C50000   1     LR         gr5=gr30
  458| 0030C0 addi       38C00000   1     LI        gr6=0                                                                                                         420| 003100 bl         4BFFCF01   0     CALL       _Py_NegativeRefcount,3,(*)Cuchar",gr3,gr4,(*)_object",gr5,#ProcAlias",_Py_NegativeRefcount",fcr",gr1,cr[01
  458| 0030C4 bl         4800079D   0     CALL      gr3=gen_send_ex,4,(*)aggr#3",gr3,(*)_object",gr4-gr6,#ProcAlias",gen_send_ex",fcr",gr1,cr[01567]",gr0",gr4"   420| 003104 ori        60000000   1
  458| 0030C8 ori        607C0000   1     LR        gr28=gr3                                                                                                      522| 003108 addi       38600000   1     LI         gr3=0
  459| 0030CC lwz        80A10064   1     L4A       gr5=val(gr1,100)                                                                                                0| 00310C lwz        83C10078   1     L4A        gr30=#stack(gr1,120)
  415| 0030D0 lwz        807D0000   1     L4A       gr3=<s117:d0:l4>(gr29,0)                                                                                        0| 003110 lwz        80010088   1     L4A        gr0=#stack(gr1,136)
  415| 0030D4 addi       3803FFFF   2     AI        gr0=gr3,-1                                                                                                    523| 003114 addi       38210080   1     AI         gr1=gr1,128
  415| 0030D8 stw        901D0000   1     ST4A      <s117:d0:l4>(gr29,0)=gr0                                                                                        0| 003118 mtspr      7C0803A6   1     LLR        lr=gr0
  417| 0030DC lwz        80650000   1     L4A       gr3=(*)_object._object.ob_refcnt(gr5,0)                                                                       523| 00311C bclr       4E800020   3     BA         lr
  417| 0030E0 addi       3803FFFF   2     AI        gr0=gr3,-1                                                                                                    423|                                CL.1236:
  417| 0030E4 stw        90050000   1     ST4A      (*)_object._object.ob_refcnt(gr5,0)=gr0                                                                       425| 003120 ori        63C30000   1     LR         gr3=gr30
  417| 0030E8 cmpwi      2C000000   1     C4        cr0=gr0,0                                                                                                     425| 003124 bl         4BFFCEDD   0     CALL       _Py_Dealloc,1,(*)_object",gr3,#ProcAlias",_Py_Dealloc",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",
  417| 0030EC bc         41820048   1     BT        CL.1256,cr0,0x4/eq,taken=40%(40,60)                                                                           425| 003128 ori        60000000   1
  419| 0030F0 bc         4180001C   1     BT        CL.2213,cr0,0x1/lt,taken=40%(40,60)                                                                           522| 00312C addi       38600000   1     LI         gr3=0
  464| 0030F4 ori        63830000   1     LR        gr3=gr28                                                                                                        0| 003130 lwz        83C10078   1     L4A        gr30=#stack(gr1,120)
  523| 0030F8 addi       382100B0   1     AI        gr1=gr1,176                                                                                                     0| 003134 lwz        80010088   1     L4A        gr0=#stack(gr1,136)
    0| 0030FC lwz        83C1FFF8   1     L4A       gr30=#stack(gr1,-8)                                                                                           523| 003138 addi       38210080   1     AI         gr1=gr1,128
    0| 003100 lwz        80010008   1     L4A       gr0=#stack(gr1,8)                                                                                               0| 00313C mtspr      7C0803A6   1     LLR        lr=gr0
    0| 003104 mtspr      7C0803A6   2     LLR       lr=gr0                                                                                                        523| 003140 bclr       4E800020   3     BA         lr
  523| 003108 bclr       4E800020   3     BA        lr                                                                                                            423|                                CL.232:
    0|                                CL.2213:                                                                                                                    428| 003144 lwz        80A100A0   1     L4A        gr5=typ(gr1,160)
  420| 00310C addi       387B1110   1     AI        gr3=gr27,4368                                                                                                 428| 003148 lwz        80C100A4   1     L4A        gr6=val(gr1,164)
  420| 003110 addi       388001CB   1     LI        gr4=459                                                                                                       428| 00314C ori        63C30000   1     LR         gr3=gr30
  420| 003114 bl         4BFFCEED   0     CALL      _Py_NegativeRefcount,3,(*)Cuchar",gr3,gr4,(*)_object",gr5,#ProcAlias",_Py_NegativeRefcount",fcr",gr1,cr[015   428| 003150 ori        63A40000   1     LR         gr4=gr29
  420| 003118 ori        60000000   1                                                                                                                             425| 003154 stb        9B9F000C   1     ST1Z       (*)aggr#3.gi_running(gr31,12)=gr28
  464| 00311C ori        63830000   1     LR        gr3=gr28                                                                                                      428| 003158 lwz        80E100A8   1     L4A        gr7=tb(gr1,168)
  523| 003120 addi       382100B0   1     AI        gr1=gr1,176                                                                                                   428| 00315C stw        93E1FFFC   1     ST4A       #stack_prune(gr1,-4)=gr31
    0| 003124 lwz        83C1FFF8   1     L4A       gr30=#stack(gr1,-8)                                                                                           428| 003160 bl         4BFFF821   0     CALL       gr3=IPRA.$_gen_throw,5,(*)aggr#3",gr3,gr4,(*)_object",gr5,(*)_object",gr6,(*)_object",gr7,#ProcAlias",IPRA
    0| 003128 lwz        80010008   1     L4A       gr0=#stack(gr1,8)                                                                                             428| 003164 lwz        83E1FFFC   1     L4A        gr31=#stack_prune(gr1,-4)
    0| 00312C mtspr      7C0803A6   2     LLR       lr=gr0                                                                                                        428| 003168 ori        607C0000   1     LR         gr28=gr3
  523| 003130 bclr       4E800020   3     BA        lr                                                                                                            430| 00316C addi       38000000   1     LI         gr0=0
  423|                                CL.1256:                                                                                                                    415| 003170 lwz        83A20004   1     L4A        gr29=._Py_RefTotal(gr2,0)
  425| 003134 ori        60A30000   1     LR        gr3=gr5                                                                                                       417| 003174 lwz        807E0000   1     L4A        gr3=(*)_object._object.ob_refcnt(gr30,0)
  425| 003138 bl         4BFFCEC9   0     CALL      _Py_Dealloc,1,(*)_object",gr3,#ProcAlias",_Py_Dealloc",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",l     0| 003178 lwz        83620018   1     L4A        gr27=.+CONSTANT_AREA(gr2,0)







Wed Apr 15 07:30:04 CDT 2020  Page 116


  425| 00313C ori        60000000   1                                                                                                                             417| 00317C addi       3883FFFF   1     AI         gr4=gr3,-1
  464| 003140 ori        63830000   1     LR        gr3=gr28                                                                                                      417| 003180 stw        909E0000   1     ST4A       (*)_object._object.ob_refcnt(gr30,0)=gr4
  523| 003144 addi       382100B0   1     AI        gr1=gr1,176                                                                                                   430| 003184 stb        981F000C   1     ST1Z       (*)aggr#3.gi_running(gr31,12)=gr0
    0| 003148 lwz        83C1FFF8   1     L4A       gr30=#stack(gr1,-8)                                                                                           415| 003188 lwz        807D0000   1     L4A        gr3=_Py_RefTotal(gr29,0)
    0| 00314C lwz        80010008   1     L4A       gr0=#stack(gr1,8)                                                                                             415| 00318C addi       3803FFFF   2     AI         gr0=gr3,-1
    0| 003150 mtspr      7C0803A6   2     LLR       lr=gr0                                                                                                        415| 003190 stw        901D0000   1     ST4A       _Py_RefTotal(gr29,0)=gr0
  523| 003154 bclr       4E800020   3     BA        lr                                                                                                            417| 003194 cmpwi      2C040000   1     C4         cr0=gr4,0
  460|                                CL.242:                                                                                                                     417| 003198 bc         4182FE8C   1     BT         CL.1248,cr0,0x4/eq,taken=40%(40,60)
  461| 003158 lwz        80820008   1     L4A       gr4=._Py_NoneStruct(gr2,0)                                                                                    419| 00319C bc         4180FCC0   1     BT         CL.2230,cr0,0x1/lt,taken=40%(40,60)
  461| 00315C ori        63E30000   1     LR        gr3=gr31                                                                                                      419| 0031A0 b          4BFFFCD0   1     B          CL.1249,-1
  461| 003160 addi       38A00001   1     LI        gr5=1                                                                                                           0|                                CL.2241:
  461| 003164 addi       38C00000   1     LI        gr6=0                                                                                                         415| 0031A4 stb        9B9F000C   1     ST1Z       (*)aggr#3.gi_running(gr31,12)=gr28
  461| 003168 bl         480006F9   0     CALL      gr3=gen_send_ex,4,(*)aggr#3",gr3,(*)_object",gr4-gr6,#ProcAlias",gen_send_ex",fcr",gr1,cr[01567]",gr0",gr4"   416| 0031A8 ori        63C30000   1     LR         gr3=gr30
  523| 00316C addi       382100B0   1     AI        gr1=gr1,176                                                                                                   416| 0031AC stw        93E1FFFC   1     ST4A       #stack_prune(gr1,-4)=gr31
    0| 003170 lwz        83C1FFF8   1     L4A       gr30=#stack(gr1,-8)                                                                                           416| 0031B0 bl         480000D1   0     CALL       gr3=IPRA.$gen_close_iter,1,(*)_object",gr3,#ProcAlias",IPRA.$gen_close_iter",fcr",gr1,cr[01567]",gr0",gr4"
    0| 003174 lwz        80010008   1     L4A       gr0=#stack(gr1,8)                                                                                             416| 0031B4 lwz        83E1FFFC   1     L4A        gr31=#stack_prune(gr1,-4)
    0| 003178 mtspr      7C0803A6   2     LLR       lr=gr0                                                                                                        416| 0031B8 ori        607D0000   1     LR         gr29=gr3
  523| 00317C bclr       4E800020   3     BA        lr                                                                                                            417| 0031BC addi       38000000   1     LI         gr0=0
    0|                                CL.2212:                                                                                                                    415| 0031C0 lwz        80820004   1     L4A        gr4=._Py_RefTotal(gr2,0)
  455| 003180 addi       387B1254   1     AI        gr3=gr27,4692                                                                                                 417| 0031C4 lwz        807E0000   1     L4A        gr3=(*)_object._object.ob_refcnt(gr30,0)
  455| 003184 addi       389B1110   1     AI        gr4=gr27,4368                                                                                                   0| 0031C8 lwz        80A20018   1     L4A        gr5=.+CONSTANT_AREA(gr2,0)
  455| 003188 addi       38A001C7   1     LI        gr5=455                                                                                                       417| 0031CC addi       38C3FFFF   1     AI         gr6=gr3,-1
  455| 00318C bl         4BFFCE75   0     CALL      __assert,3,gr3-gr5,#ProcAlias",__assert",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",lr",fcr",xer",f   417| 0031D0 stw        90DE0000   1     ST4A       (*)_object._object.ob_refcnt(gr30,0)=gr6
  455| 003190 ori        60000000   1                                                                                                                             417| 0031D4 stb        981F000C   1     ST1Z       (*)aggr#3.gi_running(gr31,12)=gr0
    0| 003194 lwz        809F0008   1     L4A       gr4=(*)aggr#3.gi_frame(gr31,8)                                                                                408| 0031D8 addi       38651110   1     AI         gr3=gr5,4368
    0| 003198 lwz        80640034   2     L4A       gr3=(*)_frame._frame.f_lasti(gr4,52)                                                                          415| 0031DC lwz        80A40000   1     L4A        gr5=_Py_RefTotal(gr4,0)
    0| 00319C b          4BFFFF00   0     B         CL.241,-1                                                                                                     415| 0031E0 addi       3805FFFF   2     AI         gr0=gr5,-1
    0|                                CL.2211:                                                                                                                    415| 0031E4 stw        90040000   1     ST4A       _Py_RefTotal(gr4,0)=gr0
  420| 0031A0 addi       387B1110   1     AI        gr3=gr27,4368                                                                                                 417| 0031E8 cmpwi      2C060000   1     C4         cr0=gr6,0
  420| 0031A4 addi       388001C5   1     LI        gr4=453                                                                                                       417| 0031EC bc         4182004C   1     BT         CL.1228,cr0,0x4/eq,taken=40%(40,60)
  420| 0031A8 ori        63850000   1     LR        gr5=gr28                                                                                                      419| 0031F0 bc         41800034   1     BT         CL.2242,cr0,0x1/lt,taken=40%(40,60)
  420| 0031AC bl         4BFFCE55   0     CALL      _Py_NegativeRefcount,3,(*)Cuchar",gr3,gr4,(*)_object",gr5,#ProcAlias",_Py_NegativeRefcount",fcr",gr1,cr[015   421|                                CL.1229:
  420| 0031B0 ori        60000000   1                                                                                                                             419| 0031F4 cmpwi      2C1D0000   1     C4         cr0=gr29,0
  423| 0031B4 b          4BFFFED8   0     B         CL.1253,-1                                                                                                    419| 0031F8 bc         4080F7B8   1     BF         CL.2261,cr0,0x1/lt,taken=70%(70,30)
  423|                                CL.1252:                                                                                                                    420| 0031FC lwz        80820008   2     L4A        gr4=._Py_NoneStruct(gr2,0)
  425| 0031B8 ori        63830000   1     LR        gr3=gr28                                                                                                      420| 003200 ori        63E30000   1     LR         gr3=gr31
  425| 0031BC bl         4BFFCE45   0     CALL      _Py_Dealloc,1,(*)_object",gr3,#ProcAlias",_Py_Dealloc",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",l   420| 003204 addi       38A00001   1     LI         gr5=1
  425| 0031C0 ori        60000000   1                                                                                                                             420| 003208 addi       38C00000   1     LI         gr6=0
    0| 0031C4 b          4BFFFEC8   0     B         CL.1253,-1                                                                                                    420| 00320C bl         48000475   0     CALL       gr3=gen_send_ex,4,(*)aggr#3",gr3,(*)_object",gr4-gr6,#ProcAlias",gen_send_ex",fcr",gr1,cr[01567]",gr0",gr4
    0|                                CL.2210:                                                                                                                      0| 003210 lwz        83C10078   1     L4A        gr30=#stack(gr1,120)
  452| 0031C8 addi       387B1248   1     AI        gr3=gr27,4680                                                                                                   0| 003214 lwz        80010088   1     L4A        gr0=#stack(gr1,136)
  452| 0031CC addi       389B1110   1     AI        gr4=gr27,4368                                                                                                 523| 003218 addi       38210080   1     AI         gr1=gr1,128
  452| 0031D0 addi       38A001C4   1     LI        gr5=452                                                                                                         0| 00321C mtspr      7C0803A6   1     LLR        lr=gr0
  452| 0031D4 bl         4BFFCE2D   0     CALL      __assert,3,gr3-gr5,#ProcAlias",__assert",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",lr",fcr",xer",f   523| 003220 bclr       4E800020   3     BA         lr
  452| 0031D8 ori        60000000   1                                                                                                                               0|                                CL.2242:
    0| 0031DC b          4BFFFE8C   0     B         CL.239,-1                                                                                                     420| 003224 addi       388001A2   1     LI         gr4=418
    0|                                CL.2196:                                                                                                                    420| 003228 ori        63C50000   1     LR         gr5=gr30
  464| 0031E0 ori        63830000   1     LR        gr3=gr28                                                                                                      420| 00322C bl         4BFFCDD5   0     CALL       _Py_NegativeRefcount,3,(*)Cuchar",gr3,gr4,(*)_object",gr5,#ProcAlias",_Py_NegativeRefcount",fcr",gr1,cr[01
  523| 0031E4 addi       382100B0   1     AI        gr1=gr1,176                                                                                                   420| 003230 ori        60000000   1
    0| 0031E8 lwz        83C1FFF8   1     L4A       gr30=#stack(gr1,-8)                                                                                           423| 003234 b          4BFFFFC0   0     B          CL.1229,-1
    0| 0031EC lwz        80010008   1     L4A       gr0=#stack(gr1,8)                                                                                             423|                                CL.1228:
    0| 0031F0 mtspr      7C0803A6   2     LLR       lr=gr0                                                                                                        425| 003238 ori        63C30000   1     LR         gr3=gr30
  523| 0031F4 bclr       4E800020   3     BA        lr                                                                                                            425| 00323C bl         4BFFCDC5   0     CALL       _Py_Dealloc,1,(*)_object",gr3,#ProcAlias",_Py_Dealloc",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",
    0|                                CL.2209:                                                                                                                    425| 003240 ori        60000000   1
  420| 0031F8 addi       387B1110   1     AI        gr3=gr27,4368                                                                                                   0| 003244 b          4BFFFFB0   0     B          CL.1229,-1
  420| 0031FC addi       388001BF   1     LI        gr4=447                                                                                                          |               Tag Table







Wed Apr 15 07:30:04 CDT 2020  Page 117


  420| 003200 ori        63C50000   1     LR        gr5=gr30                                                                                                         | 003248        00000000 00002041 80050501 00000000 000008C8 00104950
  420| 003204 bl         4BFFCDFD   0     CALL      _Py_NegativeRefcount,3,(*)Cuchar",gr3,gr4,(*)_object",gr5,#ProcAlias",_Py_NegativeRefcount",fcr",gr1,cr[015      | 003260        52412E24 5F67656E 5F746872 6F77
  420| 003208 ori        60000000   1                                                                                                                                |               Instruction count          562
  423| 00320C b          4BFFFE38   0     B         CL.1249,-1                                                                                                       |               Straight-line exec time    583
  423|                                CL.1248:                                                                                                                   GPR's set/used:   ssus ssss ssss s---  ---- ---- ---- ssss
  425| 003210 ori        63C30000   1     LR        gr3=gr30                                                                                                     FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----
  425| 003214 bl         4BFFCDED   0     CALL      _Py_Dealloc,1,(*)_object",gr3,#ProcAlias",_Py_Dealloc",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",l  CCR's set/used:   ss-- -sss
  425| 003218 ori        60000000   1                                                                                                                                | 000000                             PDEF       IPRA.$gen_close_iter
    0| 00321C b          4BFFFE28   0     B         CL.1249,-1                                                                                                    305|                                    PROC       yf,gr3
    0|                                CL.2208:                                                                                                                      0| 003280 mfspr      7C0802A6   1     LFLR       gr0=lr
  420| 003220 addi       387B1110   1     AI        gr3=gr27,4368                                                                                                 310| 003284 lwz        80A200D4   1     L4A        gr5=.PyGen_Type(gr2,0)
  420| 003224 addi       388001BD   1     LI        gr4=445                                                                                                       128| 003288 lwz        80C30004   1     L4A        gr6=(*)C_object._object.ob_type(gr3,4)
  420| 003228 bl         4BFFCDD9   0     CALL      _Py_NegativeRefcount,3,(*)Cuchar",gr3,gr4,(*)_object",gr5,#ProcAlias",_Py_NegativeRefcount",fcr",gr1,cr[015     0| 00328C stwu       9421FF70   1     ST4U       gr1,#stack(gr1,-144)=gr1
  420| 00322C ori        60000000   1                                                                                                                             311| 003290 addi       38800000   1     LI         gr4=0
    0| 003230 lwz        807D0000   1     L4A       gr3=<s117:d0:l4>(gr29,0)                                                                                      128| 003294 cmplw      7C862840   1     CL4        cr1=gr6,gr5
  423| 003234 b          4BFFFDF0   0     B         CL.234,-1                                                                                                       0| 003298 stw        90010098   1     ST4A       #stack(gr1,152)=gr0
  423|                                CL.1244:                                                                                                                      0| 00329C ori        607F0000   1     LR         gr31=gr3
  425| 003238 ori        60A30000   1     LR        gr3=gr5                                                                                                         0| 0032A0 stw        93C10088   1     ST4A       #stack(gr1,136)=gr30
  425| 00323C bl         4BFFCDC5   0     CALL      _Py_Dealloc,1,(*)_object",gr3,#ProcAlias",_Py_Dealloc",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",l   310| 0032A4 lwz        800200D8   1     L4A        gr0=.PyCoro_Type(gr2,0)
  425| 003240 ori        60000000   1                                                                                                                             118| 0032A8 stw        90410014   1     ST4A       #cur_toc(gr1,20)=gr2
    0| 003244 lwz        807D0000   1     L4A       gr3=<s117:d0:l4>(gr29,0)                                                                                      128| 0032AC cmplw      7C060040   1     CL4        cr0=gr6,gr0
    0| 003248 b          4BFFFDDC   0     B         CL.234,-1                                                                                                     310| 0032B0 bc         41860364   0     BT         CL.259,cr1,0x4/eq,taken=40%(40,60)
    0|                                CL.2206:                                                                                                                    307| 0032B4 addi       3BC00000   2     LI         gr30=0
  415| 00324C lwz        807D0000   1     L4A       gr3=<s117:d0:l4>(gr29,0)                                                                                      317| 0032B8 lwz        80C20020   1     L4A        gr6=.$STATIC(gr2,0)
  417| 003250 lwz        809E0000   1     L4A       gr4=(*)_object._object.ob_refcnt(gr30,0)                                                                      317| 0032BC addi       38A1004C   1     AI         gr5=gr1,76
  415| 003254 addi       3803FFFF   1     AI        gr0=gr3,-1                                                                                                    310| 0032C0 bc         41820354   0     BT         CL.259,cr0,0x4/eq,taken=50%(0,0)
  415| 003258 stw        901D0000   1     ST4A      <s117:d0:l4>(gr29,0)=gr0                                                                                      317| 0032C4 addi       38860060   2     AI         gr4=gr6,96
  417| 00325C addi       3864FFFF   1     AI        gr3=gr4,-1                                                                                                    317| 0032C8 bl         4BFFCD39   0     CALL       gr3=_PyObject_LookupAttrId,3,(*)_object",gr3,(*)_Py_Identifier",gr4,(*)_object*",gr5,#ProcAlias",(*)_objec
  417| 003260 stw        907E0000   1     ST4A      (*)_object._object.ob_refcnt(gr30,0)=gr3                                                                      317| 0032CC ori        60000000   1
  417| 003264 cmpwi      2C030000   1     C4        cr0=gr3,0                                                                                                     317| 0032D0 cmpwi      2C030000   1     C4         cr0=gr3,0
  417| 003268 bc         41820024   1     BT        CL.1240,cr0,0x4/eq,taken=40%(40,60)                                                                           320| 0032D4 lwz        8381004C   1     L4A        gr28=meth(gr1,76)
  419| 00326C bc         41800008   1     BT        CL.2207,cr0,0x1/lt,taken=40%(40,60)                                                                           317| 0032D8 bc         41800318   0     BT         CL.1762,cr0,0x1/lt,taken=40%(40,60)
    0| 003270 b          4BFFF920   2     B         throw_here,-1                                                                                                 320| 0032DC cmpwi      2C1C0000   2     C4         cr0=gr28,0
    0|                                CL.2207:                                                                                                                    320| 0032E0 bc         41820304   1     BT         CL.2086,cr0,0x4/eq,taken=50%(0,0)
  420| 003274 addi       387B1110   1     AI        gr3=gr27,4368                                                                                                   0|                                CL.1744:
  420| 003278 addi       388001B7   1     LI        gr4=439                                                                                                       171| 0032E4 bl         4BFFCD1D   0     CALL       gr3=PyThreadState_Get,0,#ProcAlias",PyThreadState_Get",fcr",gr1,cr[01567]",gr0",gr4"-gr12",fp0"-fp13",mq",
  420| 00327C ori        63C50000   1     LR        gr5=gr30                                                                                                      171| 0032E8 ori        60000000   1
  420| 003280 bl         4BFFCD81   0     CALL      _Py_NegativeRefcount,3,(*)Cuchar",gr3,gr4,(*)_object",gr5,#ProcAlias",_Py_NegativeRefcount",fcr",gr1,cr[015    72| 0032EC cmpwi      2C1C0000   1     C4         cr0=gr28,0
  420| 003284 ori        60000000   1                                                                                                                             172| 0032F0 ori        607F0000   1     LR         gr31=gr3
  423| 003288 b          4BFFF908   0     B         throw_here,-1                                                                                                  72| 0032F4 bc         418202BC   0     BT         CL.1763,cr0,0x4/eq,taken=30%(30,70)
  423|                                CL.1240:                                                                                                                     73| 0032F8 lwz        83DC0004   2     L4A        gr30=(*)_object._object.ob_type(gr28,4)
  425| 00328C ori        63C30000   1     LR        gr3=gr30                                                                                                      617| 0032FC ori        63C30000   2     LR         gr3=gr30
  425| 003290 bl         4BFFCD71   0     CALL      _Py_Dealloc,1,(*)_object",gr3,#ProcAlias",_Py_Dealloc",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",l   617| 003300 bl         4BFFCD01   0     CALL       gr3=PyType_GetFlags,1,(*)_typeobject",gr3,#ProcAlias",PyType_GetFlags",fcr",gr1,cr[01567]",gr0",gr4"-gr12"
  425| 003294 ori        60000000   1                                                                                                                             617| 003304 ori        60000000   1
  440| 003298 b          4BFFF8F8   0     B         throw_here,-1                                                                                                  74| 003308 andi.      70600800   1     RN4_R      gr0,cr0=gr3,0,0x800
    0|                                CL.2204:                                                                                                                     74| 00330C bc         40820148   1     BF         CL.1004,cr0,0x4/eq,taken=40%(40,60)
  417| 00329C lwz        807E0000   1     L4A       gr3=(*)_object._object.ob_refcnt(gr30,0)                                                                        0|                                CL.1746:
  417| 0032A0 addi       3803FFFF   2     AI        gr0=gr3,-1                                                                                                    116| 003310 ori        63E30000   1     LR         gr3=gr31
  417| 0032A4 stw        901E0000   1     ST4A      (*)_object._object.ob_refcnt(gr30,0)=gr0                                                                      116| 003314 addi       38A00000   1     LI         gr5=0
  415| 0032A8 lwz        807D0000   1     L4A       gr3=<s117:d0:l4>(gr29,0)                                                                                      116| 003318 ori        63840000   1     LR         gr4=gr28
  415| 0032AC addi       3863FFFF   2     AI        gr3=gr3,-1                                                                                                    116| 00331C addi       38C00000   1     LI         gr6=0
  415| 0032B0 stw        907D0000   1     ST4A      <s117:d0:l4>(gr29,0)=gr3                                                                                      116| 003320 addi       38E00000   1     LI         gr7=0
  417| 0032B4 cmpwi      2C000000   1     C4        cr0=gr0,0                                                                                                     116| 003324 bl         4BFFCCDD   0     CALL       gr3=_PyObject_MakeTpCall,5,(*)_ts",gr3,(*)_object",gr4,(*)_object*C",gr5,gr6,(*)_object",gr7,#ProcAlias",(
  417| 0032B8 bc         4182004C   1     BT        CL.1236,cr0,0x4/eq,taken=40%(40,60)                                                                           116| 003328 ori        60000000   1
  419| 0032BC bc         4180001C   1     BT        CL.2205,cr0,0x1/lt,taken=40%(40,60)                                                                           116| 00332C ori        607E0000   1     LR         gr30=gr3
  522| 0032C0 addi       38600000   1     LI        gr3=0                                                                                                         322| 003330 lwz        80A1004C   1     L4A        gr5=meth(gr1,76)







Wed Apr 15 07:30:04 CDT 2020  Page 118


  523| 0032C4 addi       382100B0   1     AI        gr1=gr1,176                                                                                                   415| 003334 lwz        80820004   1     L4A        gr4=._Py_RefTotal(gr2,0)
    0| 0032C8 lwz        83C1FFF8   1     L4A       gr30=#stack(gr1,-8)                                                                                             0| 003338 lwz        80620018   1     L4A        gr3=.+CONSTANT_AREA(gr2,0)
    0| 0032CC lwz        80010008   1     L4A       gr0=#stack(gr1,8)                                                                                             408| 00333C addi       38631110   2     AI         gr3=gr3,4368
    0| 0032D0 mtspr      7C0803A6   2     LLR       lr=gr0                                                                                                        417| 003340 lwz        80C50000   1     L4A        gr6=(*)_object._object.ob_refcnt(gr5,0)
  523| 0032D4 bclr       4E800020   3     BA        lr                                                                                                            415| 003344 lwz        80E40000   1     L4A        gr7=_Py_RefTotal(gr4,0)
    0|                                CL.2205:                                                                                                                    417| 003348 addi       3806FFFF   1     AI         gr0=gr6,-1
  420| 0032D8 addi       387B1110   1     AI        gr3=gr27,4368                                                                                                 417| 00334C stw        90050000   1     ST4A       (*)_object._object.ob_refcnt(gr5,0)=gr0
  420| 0032DC addi       388001B3   1     LI        gr4=435                                                                                                       415| 003350 addi       38C7FFFF   1     AI         gr6=gr7,-1
  420| 0032E0 ori        63C50000   1     LR        gr5=gr30                                                                                                      415| 003354 stw        90C40000   1     ST4A       _Py_RefTotal(gr4,0)=gr6
  420| 0032E4 bl         4BFFCD1D   0     CALL      _Py_NegativeRefcount,3,(*)Cuchar",gr3,gr4,(*)_object",gr5,#ProcAlias",_Py_NegativeRefcount",fcr",gr1,cr[015   417| 003358 cmpwi      2C000000   1     C4         cr0=gr0,0
  420| 0032E8 ori        60000000   1                                                                                                                             417| 00335C bc         418200E0   1     BT         CL.2087,cr0,0x4/eq,taken=40%(40,60)
  522| 0032EC addi       38600000   1     LI        gr3=0                                                                                                         419| 003360 bc         408000D0   1     BF         CL.1754,cr0,0x1/lt,taken=50%(0,0)
  523| 0032F0 addi       382100B0   1     AI        gr1=gr1,176                                                                                                     0|                                CL.1753:
    0| 0032F4 lwz        83C1FFF8   1     L4A       gr30=#stack(gr1,-8)                                                                                           420| 003364 addi       38800142   1     LI         gr4=322
    0| 0032F8 lwz        80010008   1     L4A       gr0=#stack(gr1,8)                                                                                             420| 003368 bl         4BFFCC99   0     CALL       _Py_NegativeRefcount,3,(*)Cuchar",gr3,gr4,(*)_object",gr5,#ProcAlias",_Py_NegativeRefcount",fcr",gr1,cr[01
    0| 0032FC mtspr      7C0803A6   2     LLR       lr=gr0                                                                                                        420| 00336C ori        60000000   1
  523| 003300 bclr       4E800020   3     BA        lr                                                                                                            323| 003370 cmpwi      2C1E0000   1     C4         cr0=gr30,0
  423|                                CL.1236:                                                                                                                    323| 003374 bc         418200A4   1     BT         CL.1758,cr0,0x4/eq,taken=30%(30,70)
  425| 003304 ori        63C30000   1     LR        gr3=gr30                                                                                                      313|                                CL.261:
  425| 003308 bl         4BFFCCF9   0     CALL      _Py_Dealloc,1,(*)_object",gr3,#ProcAlias",_Py_Dealloc",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",l   491| 003378 cmpwi      2C1E0000   1     C4         cr0=gr30,0
  425| 00330C ori        60000000   1                                                                                                                             491| 00337C bc         41820038   1     BT         CL.1759,cr0,0x4/eq,taken=30%(30,70)
  522| 003310 addi       38600000   1     LI        gr3=0                                                                                                           0|                                CL.1757:
  523| 003314 addi       382100B0   1     AI        gr1=gr1,176                                                                                                   415| 003380 lwz        80820004   1     L4A        gr4=._Py_RefTotal(gr2,0)
    0| 003318 lwz        83C1FFF8   1     L4A       gr30=#stack(gr1,-8)                                                                                           417| 003384 lwz        80BE0000   1     L4A        gr5=(*)_object._object.ob_refcnt(gr30,0)
    0| 00331C lwz        80010008   1     L4A       gr0=#stack(gr1,8)                                                                                               0| 003388 lwz        80620018   1     L4A        gr3=.+CONSTANT_AREA(gr2,0)
    0| 003320 mtspr      7C0803A6   2     LLR       lr=gr0                                                                                                        417| 00338C cmpwi      2C050001   1     C4         cr0=gr5,1
  523| 003324 bclr       4E800020   3     BA        lr                                                                                                            417| 003390 addi       3805FFFF   1     AI         gr0=gr5,-1
  423|                                CL.232:                                                                                                                     408| 003394 addi       38631124   1     AI         gr3=gr3,4388
  428| 003328 lwz        80A100D0   1     L4A       gr5=typ(gr1,208)                                                                                              417| 003398 stw        901E0000   1     ST4A       (*)_object._object.ob_refcnt(gr30,0)=gr0
  428| 00332C lwz        80C100D4   1     L4A       gr6=val(gr1,212)                                                                                              415| 00339C lwz        80A40000   1     L4A        gr5=_Py_RefTotal(gr4,0)
  428| 003330 ori        63C30000   1     LR        gr3=gr30                                                                                                      415| 0033A0 addi       38A5FFFF   2     AI         gr5=gr5,-1
  428| 003334 ori        63A40000   1     LR        gr4=gr29                                                                                                      415| 0033A4 stw        90A40000   1     ST4A       _Py_RefTotal(gr4,0)=gr5
  425| 003338 stb        9B9F000C   1     ST1Z      (*)aggr#3.gi_running(gr31,12)=gr28                                                                            417| 0033A8 cmpwi      2C800000   1     C4         cr1=gr0,0
  428| 00333C lwz        80E100D8   1     L4A       gr7=tb(gr1,216)                                                                                               417| 0033AC bc         41820048   0     BT         CL.1023,cr0,0x4/eq,taken=40%(40,60)
  428| 003340 stw        93E1FFFC   1     ST4A      #stack_prune(gr1,-4)=gr31                                                                                     419| 0033B0 bc         4184001C   1     BT         CL.2094,cr1,0x1/lt,taken=40%(40,60)
  428| 003344 bl         4BFFF81D   0     CALL      gr3=IPRA.$_gen_throw,5,(*)aggr#3",gr3,gr4,(*)_object",gr5,(*)_object",gr6,(*)_object",gr7,#ProcAlias",IPRA.     0|                                CL.1759:
  428| 003348 lwz        83E1FFFC   1     L4A       gr31=#stack_prune(gr1,-4)                                                                                     328| 0033B4 addi       38600000   1     LI         gr3=0
  428| 00334C ori        607C0000   1     LR        gr28=gr3                                                                                                        0| 0033B8 lwz        83C10088   1     L4A        gr30=#stack(gr1,136)
  430| 003350 addi       38000000   1     LI        gr0=0                                                                                                           0| 0033BC lwz        80010098   1     L4A        gr0=#stack(gr1,152)
    0| 003354 lwz        83A20004   1     L4A       gr29=._Py_RefTotal(gr2,0)                                                                                     329| 0033C0 addi       38210090   1     AI         gr1=gr1,144
    0| 003358 lwz        83620018   1     L4A       gr27=.+CONSTANT_AREA(gr2,0)                                                                                     0| 0033C4 mtspr      7C0803A6   1     LLR        lr=gr0
  430| 00335C stb        981F000C   1     ST1Z      (*)aggr#3.gi_running(gr31,12)=gr0                                                                             329| 0033C8 bclr       4E800020   3     BA         lr
    0| 003360 lwz        807D0000   1     L4A       gr3=<s117:d0:l4>(gr29,0)                                                                                        0|                                CL.2094:
    0| 003364 b          4BFFFCC0   0     B         CL.234,-1                                                                                                     420| 0033CC addi       388001EC   1     LI         gr4=492
    0|                                CL.2201:                                                                                                                    420| 0033D0 ori        63C50000   1     LR         gr5=gr30
  415| 003368 stb        9B9F000C   1     ST1Z      (*)aggr#3.gi_running(gr31,12)=gr28                                                                            420| 0033D4 bl         4BFFCC2D   0     CALL       _Py_NegativeRefcount,3,(*)Cuchar",gr3,gr4,(*)_object",gr5,#ProcAlias",_Py_NegativeRefcount",fcr",gr1,cr[01
  416| 00336C ori        63C30000   1     LR        gr3=gr30                                                                                                      420| 0033D8 ori        60000000   1
  416| 003370 stw        93E1FFFC   1     ST4A      #stack_prune(gr1,-4)=gr31                                                                                     328| 0033DC addi       38600000   1     LI         gr3=0
  416| 003374 bl         480000CD   0     CALL      gr3=IPRA.$gen_close_iter,1,(*)_object",gr3,#ProcAlias",IPRA.$gen_close_iter",fcr",gr1,cr[01567]",gr0",gr4"-     0| 0033E0 lwz        83C10088   1     L4A        gr30=#stack(gr1,136)
  416| 003378 lwz        83E1FFFC   1     L4A       gr31=#stack_prune(gr1,-4)                                                                                       0| 0033E4 lwz        80010098   1     L4A        gr0=#stack(gr1,152)
  416| 00337C ori        607D0000   1     LR        gr29=gr3                                                                                                      329| 0033E8 addi       38210090   1     AI         gr1=gr1,144
  417| 003380 addi       38000000   1     LI        gr0=0                                                                                                           0| 0033EC mtspr      7C0803A6   1     LLR        lr=gr0
  415| 003384 lwz        80820004   1     L4A       gr4=._Py_RefTotal(gr2,0)                                                                                      329| 0033F0 bclr       4E800020   3     BA         lr
  417| 003388 lwz        807E0000   1     L4A       gr3=(*)_object._object.ob_refcnt(gr30,0)                                                                      423|                                CL.1023:
    0| 00338C lwz        80A20018   1     L4A       gr5=.+CONSTANT_AREA(gr2,0)                                                                                    425| 0033F4 ori        63C30000   1     LR         gr3=gr30
  417| 003390 addi       38C3FFFF   1     AI        gr6=gr3,-1                                                                                                    425| 0033F8 bl         4BFFCC09   0     CALL       _Py_Dealloc,1,(*)_object",gr3,#ProcAlias",_Py_Dealloc",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",







Wed Apr 15 07:30:04 CDT 2020  Page 119


  417| 003394 stw        90DE0000   1     ST4A      (*)_object._object.ob_refcnt(gr30,0)=gr6                                                                      425| 0033FC ori        60000000   1
  417| 003398 stb        981F000C   1     ST1Z      (*)aggr#3.gi_running(gr31,12)=gr0                                                                             328| 003400 addi       38600000   1     LI         gr3=0
  408| 00339C addi       38651110   1     AI        gr3=gr5,4368                                                                                                    0| 003404 lwz        83C10088   1     L4A        gr30=#stack(gr1,136)
  415| 0033A0 lwz        80A40000   1     L4A       gr5=<s117:d0:l4>(gr4,0)                                                                                         0| 003408 lwz        80010098   1     L4A        gr0=#stack(gr1,152)
  415| 0033A4 addi       3805FFFF   2     AI        gr0=gr5,-1                                                                                                    329| 00340C addi       38210090   1     AI         gr1=gr1,144
  415| 0033A8 stw        90040000   1     ST4A      <s117:d0:l4>(gr4,0)=gr0                                                                                         0| 003410 mtspr      7C0803A6   1     LLR        lr=gr0
  417| 0033AC cmpwi      2C060000   1     C4        cr0=gr6,0                                                                                                     329| 003414 bclr       4E800020   3     BA         lr
  417| 0033B0 bc         4182004C   1     BT        CL.1228,cr0,0x4/eq,taken=40%(40,60)                                                                             0|                                CL.1758:
  419| 0033B4 bc         41800034   1     BT        CL.2202,cr0,0x1/lt,taken=40%(40,60)                                                                           313| 003418 addi       3860FFFF   1     LI         gr3=-1
  421|                                CL.1229:                                                                                                                      0| 00341C lwz        83C10088   1     L4A        gr30=#stack(gr1,136)
  419| 0033B8 cmpwi      2C1D0000   1     C4        cr0=gr29,0                                                                                                      0| 003420 lwz        80010098   1     L4A        gr0=#stack(gr1,152)
  419| 0033BC bc         4080F7D4   1     BF        CL.2221,cr0,0x1/lt,taken=70%(70,30)                                                                           329| 003424 addi       38210090   1     AI         gr1=gr1,144
  420| 0033C0 lwz        80820008   2     L4A       gr4=._Py_NoneStruct(gr2,0)                                                                                      0| 003428 mtspr      7C0803A6   1     LLR        lr=gr0
  420| 0033C4 ori        63E30000   1     LR        gr3=gr31                                                                                                      329| 00342C bclr       4E800020   3     BA         lr
  420| 0033C8 addi       38A00001   1     LI        gr5=1                                                                                                           0|                                CL.1754:
  420| 0033CC addi       38C00000   1     LI        gr6=0                                                                                                         323| 003430 cmpwi      2C1E0000   1     C4         cr0=gr30,0
  420| 0033D0 bl         48000491   0     CALL      gr3=gen_send_ex,4,(*)aggr#3",gr3,(*)_object",gr4-gr6,#ProcAlias",gen_send_ex",fcr",gr1,cr[01567]",gr0",gr4"   323| 003434 bc         4182FFE4   1     BT         CL.1758,cr0,0x4/eq,taken=30%(30,70)
  523| 0033D4 addi       382100B0   1     AI        gr1=gr1,176                                                                                                     0| 003438 b          4BFFFF40   1     B          CL.261,-1
    0| 0033D8 lwz        83C1FFF8   1     L4A       gr30=#stack(gr1,-8)                                                                                             0|                                CL.2087:
    0| 0033DC lwz        80010008   1     L4A       gr0=#stack(gr1,8)                                                                                             425| 00343C ori        60A30000   1     LR         gr3=gr5
    0| 0033E0 mtspr      7C0803A6   2     LLR       lr=gr0                                                                                                        425| 003440 bl         4BFFCBC1   0     CALL       _Py_Dealloc,1,(*)_object",gr3,#ProcAlias",_Py_Dealloc",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",
  523| 0033E4 bclr       4E800020   3     BA        lr                                                                                                            425| 003444 ori        60000000   1
    0|                                CL.2202:                                                                                                                    323| 003448 cmpwi      2C1E0000   1     C4         cr0=gr30,0
  420| 0033E8 addi       388001A2   1     LI        gr4=418                                                                                                       323| 00344C bc         4182FFCC   1     BT         CL.1758,cr0,0x4/eq,taken=30%(30,70)
  420| 0033EC ori        63C50000   1     LR        gr5=gr30                                                                                                        0| 003450 b          4BFFFF28   1     B          CL.261,-1
  420| 0033F0 bl         4BFFCC11   0     CALL      _Py_NegativeRefcount,3,(*)Cuchar",gr3,gr4,(*)_object",gr5,#ProcAlias",_Py_NegativeRefcount",fcr",gr1,cr[015    76|                                CL.1004:
  420| 0033F4 ori        60000000   1                                                                                                                              77| 003454 ori        63830000   1     LR         gr3=gr28
  423| 0033F8 b          4BFFFFC0   0     B         CL.1229,-1                                                                                                     77| 003458 bl         4BFFCBA9   0     CALL       gr3=PyCallable_Check,1,(*)_object",gr3,#ProcAlias",PyCallable_Check",fcr",gr1,cr[01567]",gr0",gr4"-gr12",f
  423|                                CL.1228:                                                                                                                     77| 00345C ori        60000000   1
  425| 0033FC ori        63C30000   1     LR        gr3=gr30                                                                                                       77| 003460 cmpwi      2C030000   1     C4         cr0=gr3,0
  425| 003400 bl         4BFFCC01   0     CALL      _Py_Dealloc,1,(*)_object",gr3,#ProcAlias",_Py_Dealloc",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",l    78| 003464 lwz        83BE001C   1     L4A        gr29=(*)_typeobject._typeobject.tp_vectorcall_offset(gr30,28)
  425| 003404 ori        60000000   1                                                                                                                               0| 003468 ori        63A00000   2     LR         gr0=gr29
    0| 003408 b          4BFFFFB0   0     B         CL.1229,-1                                                                                                     77| 00346C bc         4182011C   0     BT         CL.1764,cr0,0x4/eq,taken=40%(40,60)
     |               Tag Table                                                                                                                                     79| 003470 cmpwi      2C000000   1     C4         cr0=gr0,0
     | 00340C        00000000 00002041 80050501 00000000 000008AC 00104950                                                                                         79| 003474 bc         408100EC   1     BF         CL.1750,cr0,0x2/gt,taken=40%(40,60)
     | 003424        52412E24 5F67656E 5F746872 6F77                                                                                                                0|                                CL.1751:
     |               Instruction count          555                                                                                                                81| 003478 lwzx       7CFCE82E   1     L4A        gr7=(*)_object*()*(gr28,gr29,0)
     |               Straight-line exec time    585                                                                                                                 0| 00347C or.        7CE03B79   2     LR_R       gr0,cr0=gr7
 GPR's set/used:   ssus ssss ssss s---  ---- ---- ---- ssss                                                                                                       114| 003480 bc         41820088   1     BT         CL.2093,cr0,0x4/eq,taken=30%(30,70)
 FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----                                                                                                         0|                                CL.2099:
 CCR's set/used:   ss-- -sss                                                                                                                                      118| 003484 ori        63830000   1     LR         gr3=gr28
     | 000000                             PDEF     IPRA.$gen_close_iter                                                                                           118| 003488 lwz        80070000   1     L4A        gr0=#fnc_adr(gr7,0)
  305|                                    PROC      yf,gr3                                                                                                        118| 00348C lwz        81670008   1     L4A        gr11=#new_env(gr7,8)
    0| 003440 mfspr      7C0802A6   1     LFLR      gr0=lr                                                                                                        118| 003490 addi       38A00000   1     LI         gr5=0
  310| 003444 lwz        80A200D4   1     L4A       gr5=.PyGen_Type(gr2,0)                                                                                        118| 003494 addi       38800000   1     LI         gr4=0
  128| 003448 lwz        80E30004   1     L4A       gr7=(*)C_object._object.ob_type(gr3,4)                                                                        118| 003498 addi       38C00000   1     LI         gr6=0
    0| 00344C ori        60660000   1     LR        gr6=gr3                                                                                                       118| 00349C mtspr      7C0903A6   1     LCTR       ctr=gr0
  311| 003450 addi       38800000   1     LI        gr4=0                                                                                                         118| 0034A0 lwz        80470004   1     CALL       gr3=gr7,4,(*)_object",gr3,(*)_object*C",gr4,gr5,(*)_object",gr6,#ProcAlias",(*)_object",fcr",(*)_object*()
  128| 003454 cmplw      7C872840   1     CL4       cr1=gr7,gr5                                                                                                   118| 0034A4 bcctrl     4E800421   0
    0| 003458 stw        90010008   1     ST4A      #stack(gr1,8)=gr0                                                                                             118| 0034A8 lwz        80410014   1
    0| 00345C stw        93C1FFF8   1     ST4A      #stack(gr1,-8)=gr30                                                                                           118| 0034AC ori        60650000   1     LR         gr5=gr3
  310| 003460 lwz        800200D8   1     L4A       gr0=.PyCoro_Type(gr2,0)                                                                                       119| 0034B0 ori        63E30000   1     LR         gr3=gr31
    0| 003464 stwu       9421FF30   1     ST4U      gr1,#stack(gr1,-208)=gr1                                                                                      119| 0034B4 addi       38C00000   1     LI         gr6=0
  128| 003468 cmplw      7C070040   1     CL4       cr0=gr7,gr0                                                                                                   119| 0034B8 ori        63840000   1     LR         gr4=gr28
  118| 00346C stw        90410014   1     ST4A      #cur_toc(gr1,20)=gr2                                                                                          119| 0034BC bl         4BFFCB45   0     CALL       gr3=_Py_CheckFunctionResult,4,(*)_ts",gr3,(*)_object",gr4,(*)_object",gr5,(*)Cuchar",gr6,#ProcAlias",_Py_C
  310| 003470 bc         41860390   0     BT        CL.259,cr1,0x4/eq,taken=40%(40,60)                                                                            119| 0034C0 ori        60000000   1







Wed Apr 15 07:30:04 CDT 2020  Page 120


  307| 003474 addi       3BE00000   2     LI        gr31=0                                                                                                        119| 0034C4 ori        607E0000   1     LR         gr30=gr3
  317| 003478 lwz        80E20020   1     L4A       gr7=.$STATIC(gr2,0)                                                                                           322| 0034C8 lwz        80A1004C   1     L4A        gr5=meth(gr1,76)
  317| 00347C addi       38A1004C   1     AI        gr5=gr1,76                                                                                                    415| 0034CC lwz        80820004   1     L4A        gr4=._Py_RefTotal(gr2,0)
  310| 003480 bc         41820380   0     BT        CL.259,cr0,0x4/eq,taken=50%(0,0)                                                                                0| 0034D0 lwz        80620018   1     L4A        gr3=.+CONSTANT_AREA(gr2,0)
    0| 003484 stw        90C100B4   2     ST4A      #parameter_store0(gr1,180)=gr6                                                                                408| 0034D4 addi       38631110   2     AI         gr3=gr3,4368
  317| 003488 addi       38870060   1     AI        gr4=gr7,96                                                                                                    417| 0034D8 lwz        80C50000   1     L4A        gr6=(*)_object._object.ob_refcnt(gr5,0)
  317| 00348C bl         4BFFCB75   0     CALL      gr3=_PyObject_LookupAttrId,3,(*)_object",gr3,(*)_Py_Identifier",gr4,(*)_object*",gr5,#ProcAlias",(*)_object   415| 0034DC lwz        80E40000   1     L4A        gr7=_Py_RefTotal(gr4,0)
  317| 003490 ori        60000000   1                                                                                                                             417| 0034E0 addi       3806FFFF   1     AI         gr0=gr6,-1
  317| 003494 cmpwi      2C030000   1     C4        cr0=gr3,0                                                                                                     417| 0034E4 stw        90050000   1     ST4A       (*)_object._object.ob_refcnt(gr5,0)=gr0
  320| 003498 lwz        8381004C   1     L4A       gr28=meth(gr1,76)                                                                                             415| 0034E8 addi       38C7FFFF   1     AI         gr6=gr7,-1
  317| 00349C lwz        80C100B4   1     L4A       gr6=#parameter_store0(gr1,180)                                                                                415| 0034EC stw        90C40000   1     ST4A       _Py_RefTotal(gr4,0)=gr6
  317| 0034A0 bc         4180033C   0     BT        CL.1640,cr0,0x1/lt,taken=40%(40,60)                                                                           417| 0034F0 cmpwi      2C000000   1     C4         cr0=gr0,0
  320| 0034A4 cmpwi      2C1C0000   2     C4        cr0=gr28,0                                                                                                    417| 0034F4 bc         4182FF48   1     BT         CL.2087,cr0,0x4/eq,taken=40%(40,60)
  320| 0034A8 bc         41820328   1     BT        CL.2035,cr0,0x4/eq,taken=50%(0,0)                                                                             419| 0034F8 bc         4180FE6C   1     BT         CL.1753,cr0,0x1/lt,taken=40%(40,60)
    0|                                CL.1622:                                                                                                                    323| 0034FC cmpwi      2C1E0000   2     C4         cr0=gr30,0
  171| 0034AC bl         4BFFCB55   0     CALL      gr3=PyThreadState_Get,0,#ProcAlias",PyThreadState_Get",fcr",gr1,cr[01567]",gr0",gr4"-gr12",fp0"-fp13",mq",l   323| 003500 bc         4182FF18   1     BT         CL.1758,cr0,0x4/eq,taken=30%(30,70)
  171| 0034B0 ori        60000000   1                                                                                                                               0| 003504 b          4BFFFE74   1     B          CL.261,-1
   72| 0034B4 cmpwi      2C1C0000   1     C4        cr0=gr28,0                                                                                                      0|                                CL.2093:
  171| 0034B8 ori        607F0000   1     LR        gr31=gr3                                                                                                      116| 003508 ori        63E30000   1     LR         gr3=gr31
   72| 0034BC bc         418202E0   0     BT        CL.1641,cr0,0x4/eq,taken=30%(30,70)                                                                           116| 00350C addi       38A00000   1     LI         gr5=0
   73| 0034C0 lwz        83DC0004   2     L4A       gr30=(*)_object._object.ob_type(gr28,4)                                                                       116| 003510 ori        63840000   1     LR         gr4=gr28
  617| 0034C4 ori        63C30000   2     LR        gr3=gr30                                                                                                      116| 003514 addi       38C00000   1     LI         gr6=0
  617| 0034C8 bl         4BFFCB39   0     CALL      gr3=PyType_GetFlags,1,(*)_typeobject",gr3,#ProcAlias",PyType_GetFlags",fcr",gr1,cr[01567]",gr0",gr4"-gr12",   116| 003518 addi       38E00000   1     LI         gr7=0
  617| 0034CC ori        60000000   1                                                                                                                             116| 00351C bl         4BFFCAE5   0     CALL       gr3=_PyObject_MakeTpCall,5,(*)_ts",gr3,(*)_object",gr4,(*)_object*C",gr5,gr6,(*)_object",gr7,#ProcAlias",(
   74| 0034D0 andi.      70600800   1     RN4_R     gr0,cr0=gr3,0,0x800                                                                                           116| 003520 ori        60000000   1
   74| 0034D4 bc         40820138   1     BF        CL.1004,cr0,0x4/eq,taken=40%(40,60)                                                                           116| 003524 ori        607E0000   1     LR         gr30=gr3
    0|                                CL.2050:                                                                                                                    322| 003528 lwz        80A1004C   1     L4A        gr5=meth(gr1,76)
  116| 0034D8 ori        63E30000   1     LR        gr3=gr31                                                                                                      415| 00352C lwz        80820004   1     L4A        gr4=._Py_RefTotal(gr2,0)
  116| 0034DC addi       38A00000   1     LI        gr5=0                                                                                                           0| 003530 lwz        80620018   1     L4A        gr3=.+CONSTANT_AREA(gr2,0)
  116| 0034E0 ori        63840000   1     LR        gr4=gr28                                                                                                      408| 003534 addi       38631110   2     AI         gr3=gr3,4368
    0| 0034E4 lwz        83C100C8   1     L4A       gr30=#stack(gr1,200)                                                                                          417| 003538 lwz        80C50000   1     L4A        gr6=(*)_object._object.ob_refcnt(gr5,0)
  116| 0034E8 addi       38C00000   1     LI        gr6=0                                                                                                         415| 00353C lwz        80E40000   1     L4A        gr7=_Py_RefTotal(gr4,0)
  116| 0034EC addi       38E00000   1     LI        gr7=0                                                                                                         417| 003540 addi       3806FFFF   1     AI         gr0=gr6,-1
  116| 0034F0 bl         4BFFCB11   0     CALL      gr3=_PyObject_MakeTpCall,5,(*)_ts",gr3,(*)_object",gr4,(*)_object*C",gr5,gr6,(*)_object",gr7,#ProcAlias",(*   417| 003544 stw        90050000   1     ST4A       (*)_object._object.ob_refcnt(gr5,0)=gr0
  116| 0034F4 ori        60000000   1                                                                                                                             415| 003548 addi       38C7FFFF   1     AI         gr6=gr7,-1
  321| 0034F8 ori        607F0000   1     LR        gr31=gr3                                                                                                      415| 00354C stw        90C40000   1     ST4A       _Py_RefTotal(gr4,0)=gr6
  322| 0034FC lwz        80A1004C   1     L4A       gr5=meth(gr1,76)                                                                                              417| 003550 cmpwi      2C000000   1     C4         cr0=gr0,0
  415| 003500 lwz        80820004   1     L4A       gr4=._Py_RefTotal(gr2,0)                                                                                      417| 003554 bc         4182FEE8   1     BT         CL.2087,cr0,0x4/eq,taken=40%(40,60)
    0| 003504 lwz        80620018   1     L4A       gr3=.+CONSTANT_AREA(gr2,0)                                                                                      0| 003558 bc         4080FED8   1     BF         CL.1754,cr0,0x1/lt,taken=50%(0,0)
  408| 003508 addi       38631110   2     AI        gr3=gr3,4368                                                                                                    0| 00355C b          4BFFFE08   1     B          CL.1753,-1
  417| 00350C lwz        80C50000   1     L4A       gr6=(*)_object._object.ob_refcnt(gr5,0)                                                                         0|                                CL.1750:
  415| 003510 lwz        80E40000   1     L4A       gr7=<s117:d0:l4>(gr4,0)                                                                                        79| 003560 addi       38A0004F   1     LI         gr5=79
  417| 003514 addi       3806FFFF   1     AI        gr0=gr6,-1                                                                                                     79| 003564 lwz        80620018   1     L4A        gr3=.+CONSTANT_AREA(gr2,0)
  417| 003518 stw        90050000   1     ST4A      (*)_object._object.ob_refcnt(gr5,0)=gr0                                                                        79| 003568 addi       38831174   2     AI         gr4=gr3,4468
  415| 00351C addi       38C7FFFF   1     AI        gr6=gr7,-1                                                                                                     79| 00356C addi       386311C4   1     AI         gr3=gr3,4548
  415| 003520 stw        90C40000   1     ST4A      <s117:d0:l4>(gr4,0)=gr6                                                                                        79| 003570 bl         4BFFCA91   0     CALL       __assert,3,gr3-gr5,#ProcAlias",__assert",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",lr",fcr",xer",
  417| 003524 cmpwi      2C000000   1     C4        cr0=gr0,0                                                                                                      79| 003574 ori        60000000   1
  417| 003528 bc         418200CC   1     BT        CL.2036,cr0,0x4/eq,taken=40%(40,60)                                                                            81| 003578 lwzx       7CFCE82E   1     L4A        gr7=(*)_object*()*(gr28,gr29,0)
  419| 00352C bc         408000BC   1     BF        CL.1632,cr0,0x1/lt,taken=50%(0,0)                                                                               0| 00357C or.        7CE03B79   2     LR_R       gr0,cr0=gr7
    0|                                CL.1631:                                                                                                                    114| 003580 bc         4182FF88   1     BT         CL.2093,cr0,0x4/eq,taken=30%(30,70)
  420| 003530 addi       38800142   1     LI        gr4=322                                                                                                         0| 003584 b          4BFFFF00   1     B          CL.2099,-1
  420| 003534 bl         4BFFCACD   0     CALL      _Py_NegativeRefcount,3,(*)Cuchar",gr3,gr4,(*)_object",gr5,#ProcAlias",_Py_NegativeRefcount",fcr",gr1,cr[015     0|                                CL.1764:
  420| 003538 ori        60000000   1                                                                                                                              77| 003588 addi       38A0004D   1     LI         gr5=77
  323| 00353C cmpwi      2C1F0000   1     C4        cr0=gr31,0                                                                                                     77| 00358C lwz        80620018   1     L4A        gr3=.+CONSTANT_AREA(gr2,0)
  323| 003540 bc         41820094   1     BT        CL.1636,cr0,0x4/eq,taken=30%(30,70)                                                                            77| 003590 addi       38831174   2     AI         gr4=gr3,4468
  313|                                CL.261:                                                                                                                      77| 003594 addi       386311A8   1     AI         gr3=gr3,4520







Wed Apr 15 07:30:04 CDT 2020  Page 121


  491| 003544 cmpwi      2C1F0000   1     C4        cr0=gr31,0                                                                                                     77| 003598 bl         4BFFCA69   0     CALL       __assert,3,gr3-gr5,#ProcAlias",__assert",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",lr",fcr",xer",
  491| 003548 bc         41820034   1     BT        CL.1637,cr0,0x4/eq,taken=30%(30,70)                                                                            77| 00359C ori        60000000   1
    0|                                CL.1635:                                                                                                                     78| 0035A0 lwz        83BE001C   1     L4A        gr29=(*)_typeobject._typeobject.tp_vectorcall_offset(gr30,28)
  415| 00354C lwz        80820004   1     L4A       gr4=._Py_RefTotal(gr2,0)                                                                                        0| 0035A4 or.        7FA0EB79   2     LR_R       gr0,cr0=gr29
  417| 003550 lwz        80BF0000   1     L4A       gr5=(*)_object._object.ob_refcnt(gr31,0)                                                                       79| 0035A8 bc         4081FFB8   1     BF         CL.1750,cr0,0x2/gt,taken=40%(40,60)
    0| 003554 lwz        80620018   1     L4A       gr3=.+CONSTANT_AREA(gr2,0)                                                                                     79| 0035AC b          4BFFFECC   1     B          CL.1751,-1
  417| 003558 addi       3805FFFF   1     AI        gr0=gr5,-1                                                                                                      0|                                CL.1763:
  417| 00355C stw        901F0000   1     ST4A      (*)_object._object.ob_refcnt(gr31,0)=gr0                                                                       72| 0035B0 addi       38A00048   1     LI         gr5=72
  408| 003560 addi       38631124   1     AI        gr3=gr3,4388                                                                                                   72| 0035B4 lwz        80620018   1     L4A        gr3=.+CONSTANT_AREA(gr2,0)
  415| 003564 lwz        80A40000   1     L4A       gr5=<s117:d0:l4>(gr4,0)                                                                                        72| 0035B8 addi       38831174   2     AI         gr4=gr3,4468
  415| 003568 addi       38C5FFFF   2     AI        gr6=gr5,-1                                                                                                     72| 0035BC addi       38631194   1     AI         gr3=gr3,4500
  415| 00356C stw        90C40000   1     ST4A      <s117:d0:l4>(gr4,0)=gr6                                                                                        72| 0035C0 bl         4BFFCA41   0     CALL       __assert,3,gr3-gr5,#ProcAlias",__assert",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",lr",fcr",xer",
  417| 003570 cmpwi      2C000000   1     C4        cr0=gr0,0                                                                                                      72| 0035C4 ori        60000000   1
  417| 003574 bc         41820040   1     BT        CL.1023,cr0,0x4/eq,taken=40%(40,60)                                                                            73| 0035C8 lwz        83DC0004   1     L4A        gr30=(*)_object._object.ob_type(gr28,4)
  419| 003578 bc         41800018   1     BT        CL.2045,cr0,0x1/lt,taken=40%(40,60)                                                                           617| 0035CC ori        63C30000   2     LR         gr3=gr30
    0|                                CL.1637:                                                                                                                    617| 0035D0 bl         4BFFCA31   0     CALL       gr3=PyType_GetFlags,1,(*)_typeobject",gr3,#ProcAlias",PyType_GetFlags",fcr",gr1,cr[01567]",gr0",gr4"-gr12"
  328| 00357C addi       38600000   1     LI        gr3=0                                                                                                         617| 0035D4 ori        60000000   1
  329| 003580 addi       382100D0   1     AI        gr1=gr1,208                                                                                                    74| 0035D8 andi.      70600800   1     RN4_R      gr0,cr0=gr3,0,0x800
    0| 003584 lwz        80010008   1     L4A       gr0=#stack(gr1,8)                                                                                              74| 0035DC bc         4082FE78   1     BF         CL.1004,cr0,0x4/eq,taken=50%(0,0)
    0| 003588 mtspr      7C0803A6   2     LLR       lr=gr0                                                                                                          0| 0035E0 b          4BFFFD30   1     B          CL.1746,-1
  329| 00358C bclr       4E800020   3     BA        lr                                                                                                              0|                                CL.2086:
    0|                                CL.2045:                                                                                                                      0|                                CL.1742:
  420| 003590 addi       388001EC   1     LI        gr4=492                                                                                                       491| 0035E4 cmpwi      2C1E0000   1     C4         cr0=gr30,0
  420| 003594 ori        63E50000   1     LR        gr5=gr31                                                                                                      491| 0035E8 bc         4182FDCC   1     BT         CL.1759,cr0,0x4/eq,taken=30%(30,70)
  420| 003598 bl         4BFFCA69   0     CALL      _Py_NegativeRefcount,3,(*)Cuchar",gr3,gr4,(*)_object",gr5,#ProcAlias",_Py_NegativeRefcount",fcr",gr1,cr[015     0| 0035EC b          4BFFFD94   1     B          CL.1757,-1
  420| 00359C ori        60000000   1                                                                                                                               0|                                CL.1762:
  328| 0035A0 addi       38600000   1     LI        gr3=0                                                                                                         318| 0035F0 ori        63E30000   1     LR         gr3=gr31
  329| 0035A4 addi       382100D0   1     AI        gr1=gr1,208                                                                                                   318| 0035F4 bl         4BFFCA0D   0     CALL       PyErr_WriteUnraisable,1,(*)_object",gr3,#ProcAlias",PyErr_WriteUnraisable",fcr",gr1,cr[01567]",gr0",gr3"-g
    0| 0035A8 lwz        80010008   1     L4A       gr0=#stack(gr1,8)                                                                                             318| 0035F8 ori        60000000   1
    0| 0035AC mtspr      7C0803A6   2     LLR       lr=gr0                                                                                                        320| 0035FC lwz        8381004C   1     L4A        gr28=meth(gr1,76)
  329| 0035B0 bclr       4E800020   3     BA        lr                                                                                                            320| 003600 cmpwi      2C1C0000   2     C4         cr0=gr28,0
  423|                                CL.1023:                                                                                                                    320| 003604 bc         4082FCE0   1     BF         CL.1744,cr0,0x4/eq,taken=40%(40,60)
  425| 0035B4 ori        63E30000   1     LR        gr3=gr31                                                                                                      491| 003608 cmpwi      2C1E0000   2     C4         cr0=gr30,0
  425| 0035B8 bl         4BFFCA49   0     CALL      _Py_Dealloc,1,(*)_object",gr3,#ProcAlias",_Py_Dealloc",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",l   491| 00360C bc         4182FDA8   1     BT         CL.1759,cr0,0x4/eq,taken=30%(30,70)
  425| 0035BC ori        60000000   1                                                                                                                               0| 003610 b          4BFFFD70   1     B          CL.1757,-1
  328| 0035C0 addi       38600000   1     LI        gr3=0                                                                                                         310|                                CL.259:
  329| 0035C4 addi       382100D0   1     AI        gr1=gr1,208                                                                                                   311| 003614 bl         4800154D   0     CALL       gr3=gen_close,2,(*)aggr#3",gr3,(*)_object",gr4,#ProcAlias",gen_close",fcr",gr1,cr[01567]",gr0",gr4"-gr12",
    0| 0035C8 lwz        80010008   1     L4A       gr0=#stack(gr1,8)                                                                                             312| 003618 or.        7C7E1B79   1     LR_R       gr30,cr0=gr3
    0| 0035CC mtspr      7C0803A6   2     LLR       lr=gr0                                                                                                        312| 00361C bc         4082FFC8   1     BF         CL.1742,cr0,0x4/eq,taken=70%(70,30)
  329| 0035D0 bclr       4E800020   3     BA        lr                                                                                                            313| 003620 addi       3860FFFF   2     LI         gr3=-1
    0|                                CL.1636:                                                                                                                      0| 003624 lwz        83C10088   1     L4A        gr30=#stack(gr1,136)
  313| 0035D4 addi       3860FFFF   1     LI        gr3=-1                                                                                                          0| 003628 lwz        80010098   1     L4A        gr0=#stack(gr1,152)
  329| 0035D8 addi       382100D0   1     AI        gr1=gr1,208                                                                                                   329| 00362C addi       38210090   1     AI         gr1=gr1,144
    0| 0035DC lwz        80010008   1     L4A       gr0=#stack(gr1,8)                                                                                               0| 003630 mtspr      7C0803A6   1     LLR        lr=gr0
    0| 0035E0 mtspr      7C0803A6   2     LLR       lr=gr0                                                                                                        329| 003634 bclr       4E800020   3     BA         lr
  329| 0035E4 bclr       4E800020   3     BA        lr                                                                                                               |               Tag Table
    0|                                CL.1632:                                                                                                                       | 003638        00000000 00002041 80040100 00000000 000003B8 00144950
  323| 0035E8 cmpwi      2C1F0000   1     C4        cr0=gr31,0                                                                                                       | 003650        52412E24 67656E5F 636C6F73 655F6974 6572
  323| 0035EC bc         4182FFE8   1     BT        CL.1636,cr0,0x4/eq,taken=30%(30,70)                                                                              |               Instruction count          238
    0| 0035F0 b          4BFFFF54   1     B         CL.261,-1                                                                                                        |               Straight-line exec time    245
    0|                                CL.2036:                                                                                                                   GPR's set/used:   ssus ssss ssss s---  ---- ---- ssss ssss
  425| 0035F4 ori        60A30000   1     LR        gr3=gr5                                                                                                      FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----
  425| 0035F8 bl         4BFFCA09   0     CALL      _Py_Dealloc,1,(*)_object",gr3,#ProcAlias",_Py_Dealloc",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",l  CCR's set/used:   ss-- ssss
  425| 0035FC ori        60000000   1                                                                                                                                | 000000                             PDEF       gen_send_ex
  323| 003600 cmpwi      2C1F0000   1     C4        cr0=gr31,0                                                                                                    154|                                    PROC       gen,arg,exc,closing,gr3-gr6
  323| 003604 bc         4182FFD0   1     BT        CL.1636,cr0,0x4/eq,taken=30%(30,70)                                                                             0| 003680 mfcr       7D800026   1     LFCR       gr12=cr4,4







Wed Apr 15 07:30:04 CDT 2020  Page 122


    0| 003608 b          4BFFFF3C   1     B         CL.261,-1                                                                                                       0| 003684 mfspr      7C0802A6   1     LFLR       gr0=lr
   76|                                CL.1004:                                                                                                                      0| 003688 stw        91810004   1     ST4A       #stack(gr1,4)=gr12
   77| 00360C ori        63830000   1     LR        gr3=gr28                                                                                                        0| 00368C stwu       9421FF50   1     ST4U       gr1,#stack(gr1,-176)=gr1
   77| 003610 bl         4BFFC9F1   0     CALL      gr3=PyCallable_Check,1,(*)_object",gr3,#ProcAlias",PyCallable_Check",fcr",gr1,cr[01567]",gr0",gr4"-gr12",fp     0| 003690 stw        900100B8   1     ST4A       #stack(gr1,184)=gr0
   77| 003614 ori        60000000   1                                                                                                                               0| 003694 stw        93E100AC   1     ST4A       #stack(gr1,172)=gr31
   77| 003618 cmpwi      2C030000   1     C4        cr0=gr3,0                                                                                                       0| 003698 ori        607F0000   1     LR         gr31=gr3
   78| 00361C lwz        83BE001C   1     L4A       gr29=(*)_typeobject._typeobject.tp_vectorcall_offset(gr30,28)                                                   0| 00369C stw        93C100A8   1     ST4A       #stack(gr1,168)=gr30
    0| 003620 ori        63A00000   2     LR        gr0=gr29                                                                                                        0| 0036A0 stw        93A100A4   1     ST4A       #stack(gr1,164)=gr29
   77| 003624 bc         41820120   0     BT        CL.1642,cr0,0x4/eq,taken=40%(40,60)                                                                             0| 0036A4 ori        60BD0000   1     LR         gr29=gr5
   79| 003628 cmpwi      2C000000   1     C4        cr0=gr0,0                                                                                                       0| 0036A8 stw        938100A0   1     ST4A       #stack(gr1,160)=gr28
    0| 00362C lwz        83C100C8   1     L4A       gr30=#stack(gr1,200)                                                                                            0| 0036AC stw        9361009C   1     ST4A       #stack(gr1,156)=gr27
   79| 003630 bc         408100EC   0     BF        CL.1628,cr0,0x2/gt,taken=40%(40,60)                                                                            53| 0036B0 addi       3B600001   1     LI         gr27=1
    0|                                CL.1629:                                                                                                                      0| 0036B4 stw        93410098   1     ST4A       #stack(gr1,152)=gr26
   81| 003634 lwzx       7CFCE82E   1     L4A       gr7=(*)_object*()*(gr28,gr29,0)                                                                                 0| 0036B8 stw        93210094   1     ST4A       #stack(gr1,148)=gr25
    0| 003638 or.        7CE03B79   2     LR_R      gr0,cr0=gr7                                                                                                     0| 0036BC stw        93010090   1     ST4A       #stack(gr1,144)=gr24
  114| 00363C bc         41820088   1     BT        CL.2044,cr0,0x4/eq,taken=30%(30,70)                                                                            40| 0036C0 stw        90410014   1     ST4A       #cur_toc(gr1,20)=gr2
    0|                                CL.2049:                                                                                                                     67| 0036C4 lwz        806200A4   1     L4A        gr3=._PyRuntime(gr2,0)
  118| 003640 ori        63830000   1     LR        gr3=gr28                                                                                                      160| 0036C8 lbz        881F000C   1     L1Z        gr0=(*)aggr#3.gi_running(gr31,12)
  118| 003644 lwz        80070000   1     L4A       gr0=#fnc_adr(gr7,0)                                                                                           160| 0036CC cmpwi      2C000000   2     C4         cr0=gr0,0
  118| 003648 lwz        81670008   1     L4A       gr11=#new_env(gr7,8)                                                                                           54| 0036D0 lwz        838301A0   1     L4A        gr28=(*)pyruntimestate._Py_atomic_address._value(gr3,416)
  118| 00364C addi       38A00000   1     LI        gr5=0                                                                                                         160| 0036D4 bc         41820074   0     BT         CL.267,cr0,0x4/eq,taken=50%(0,0)
  118| 003650 addi       38800000   1     LI        gr4=0                                                                                                         162| 0036D8 lwz        800200D8   1     L4A        gr0=.PyCoro_Type(gr2,0)
  118| 003654 addi       38C00000   1     LI        gr6=0                                                                                                         128| 0036DC lwz        80BF0004   1     L4A        gr5=(*)C_object._object.ob_type(gr31,4)
  118| 003658 mtspr      7C0903A6   1     LCTR      ctr=gr0                                                                                                       161| 0036E0 lwz        80620018   1     L4A        gr3=.+CONSTANT_AREA(gr2,0)
  118| 00365C lwz        80470004   1     CALL      gr3=gr7,4,(*)_object",gr3,(*)_object*C",gr4,gr5,(*)_object",gr6,#ProcAlias",(*)_object",fcr",(*)_object*()"   128| 0036E4 cmplw      7C050040   1     CL4        cr0=gr5,gr0
  118| 003660 bcctrl     4E800421   0                                                                                                                             161| 0036E8 addi       38830CA0   1     AI         gr4=gr3,3232
  118| 003664 lwz        80410014   1                                                                                                                               0| 0036EC lwz        83A100A4   1     L4A        gr29=#stack(gr1,164)
  118| 003668 ori        60650000   1     LR        gr5=gr3                                                                                                         0| 0036F0 lwz        838100A0   1     L4A        gr28=#stack(gr1,160)
  119| 00366C ori        63E30000   1     LR        gr3=gr31                                                                                                        0| 0036F4 lwz        8361009C   1     L4A        gr27=#stack(gr1,156)
  119| 003670 addi       38C00000   1     LI        gr6=0                                                                                                         162| 0036F8 bc         40820038   0     BF         CL.268,cr0,0x4/eq,taken=50%(0,0)
  119| 003674 ori        63840000   1     LR        gr4=gr28                                                                                                      163| 0036FC addi       38830CBC   2     AI         gr4=gr3,3260
  119| 003678 bl         4BFFC989   0     CALL      gr3=_Py_CheckFunctionResult,4,(*)_ts",gr3,(*)_object",gr4,(*)_object",gr5,(*)Cuchar",gr6,#ProcAlias",_Py_Ch     0| 003700 lwz        83E100AC   1     L4A        gr31=#stack(gr1,172)
  119| 00367C ori        60000000   1                                                                                                                             167|                                CL.269:
  321| 003680 ori        607F0000   1     LR        gr31=gr3                                                                                                      168| 003704 lwz        806200DC   1     L4A        gr3=.PyExc_ValueError(gr2,0)
  322| 003684 lwz        80A1004C   1     L4A       gr5=meth(gr1,76)                                                                                              168| 003708 lwz        80630000   2     L4A        gr3=PyExc_ValueError(gr3,0)
  415| 003688 lwz        80820004   1     L4A       gr4=._Py_RefTotal(gr2,0)                                                                                      168| 00370C bl         4BFFC8F5   0     CALL       PyErr_SetString,2,(*)_object",gr3,(*)Cuchar",gr4,#ProcAlias",PyErr_SetString",fcr",gr1,cr[01567]",gr0",gr3
    0| 00368C lwz        80620018   1     L4A       gr3=.+CONSTANT_AREA(gr2,0)                                                                                    168| 003710 ori        60000000   1
  408| 003690 addi       38631110   2     AI        gr3=gr3,4368                                                                                                  169| 003714 addi       38600000   1     LI         gr3=0
  417| 003694 lwz        80C50000   1     L4A       gr6=(*)_object._object.ob_refcnt(gr5,0)                                                                         0| 003718 lwz        800100B8   1     L4A        gr0=#stack(gr1,184)
  415| 003698 lwz        80E40000   1     L4A       gr7=<s117:d0:l4>(gr4,0)                                                                                       284| 00371C lwz        818100B4   1     L4A        gr12=#stack(gr1,180)
  417| 00369C addi       3806FFFF   1     AI        gr0=gr6,-1                                                                                                    284| 003720 addi       382100B0   1     AI         gr1=gr1,176
  417| 0036A0 stw        90050000   1     ST4A      (*)_object._object.ob_refcnt(gr5,0)=gr0                                                                         0| 003724 mtspr      7C0803A6   1     LLR        lr=gr0
  415| 0036A4 addi       38C7FFFF   1     AI        gr6=gr7,-1                                                                                                    284| 003728 mtcrf      7D808120   1     MTCRF      cr4=gr12
  415| 0036A8 stw        90C40000   1     ST4A      <s117:d0:l4>(gr4,0)=gr6                                                                                       284| 00372C bclr       4E800020   2     BA         lr
  417| 0036AC cmpwi      2C000000   1     C4        cr0=gr0,0                                                                                                     164|                                CL.268:
  417| 0036B0 bc         4182FF44   1     BT        CL.2036,cr0,0x4/eq,taken=40%(40,60)                                                                           165| 003730 lwz        800200E0   1     L4A        gr0=.PyAsyncGen_Type(gr2,0)
  419| 0036B4 bc         4180FE7C   1     BT        CL.1631,cr0,0x1/lt,taken=40%(40,60)                                                                             0| 003734 lwz        83E100AC   1     L4A        gr31=#stack(gr1,172)
  323| 0036B8 cmpwi      2C1F0000   2     C4        cr0=gr31,0                                                                                                    128| 003738 cmplw      7C050040   1     CL4        cr0=gr5,gr0
  323| 0036BC bc         4182FF18   1     BT        CL.1636,cr0,0x4/eq,taken=30%(30,70)                                                                           165| 00373C bc         4082FFC8   1     BF         CL.269,cr0,0x4/eq,taken=50%(0,0)
    0| 0036C0 b          4BFFFE84   1     B         CL.261,-1                                                                                                     166| 003740 addi       38830CD8   2     AI         gr4=gr3,3288
    0|                                CL.2044:                                                                                                                      0| 003744 b          4BFFFFC0   0     B          CL.269,-1
  116| 0036C4 ori        63E30000   1     LR        gr3=gr31                                                                                                      170|                                CL.267:
  116| 0036C8 addi       38A00000   1     LI        gr5=0                                                                                                         157| 003748 lwz        83DF0008   1     L4A        gr30=(*)aggr#3.gi_frame(gr31,8)
  116| 0036CC ori        63840000   1     LR        gr4=gr28                                                                                                        0| 00374C or.        7FC0F379   2     LR_R       gr0,cr0=gr30
  116| 0036D0 addi       38C00000   1     LI        gr6=0                                                                                                         171| 003750 bc         4182065C   1     BT         CL.2061,cr0,0x4/eq,taken=30%(30,70)
  116| 0036D4 addi       38E00000   1     LI        gr7=0                                                                                                         171| 003754 lwz        807E0024   1     L4A        gr3=(*)_frame._frame.f_stacktop(gr30,36)







Wed Apr 15 07:30:04 CDT 2020  Page 123


  116| 0036D8 bl         4BFFC929   0     CALL      gr3=_PyObject_MakeTpCall,5,(*)_ts",gr3,(*)_object",gr4,(*)_object*C",gr5,gr6,(*)_object",gr7,#ProcAlias",(*   171| 003758 cmpwi      2C030000   2     C4         cr0=gr3,0
  116| 0036DC ori        60000000   1                                                                                                                             171| 00375C bc         41820650   1     BT         CL.2061,cr0,0x4/eq,taken=50%(0,0)
  321| 0036E0 ori        607F0000   1     LR        gr31=gr3                                                                                                      193| 003760 lwz        801E0034   1     L4A        gr0=(*)_frame._frame.f_lasti(gr30,52)
  322| 0036E4 lwz        80A1004C   1     L4A       gr5=meth(gr1,76)                                                                                              193| 003764 cmpwi      2C00FFFF   2     C4         cr0=gr0,-1
  415| 0036E8 lwz        80820004   1     L4A       gr4=._Py_RefTotal(gr2,0)                                                                                      193| 003768 bc         41820590   1     BT         CL.2065,cr0,0x4/eq,taken=40%(40,60)
    0| 0036EC lwz        80620018   1     L4A       gr3=.+CONSTANT_AREA(gr2,0)                                                                                    209| 00376C lwz        80A20008   1     L4A        gr5=._Py_NoneStruct(gr2,0)
  408| 0036F0 addi       38631110   2     AI        gr3=gr3,4368                                                                                                    0| 003770 cmplwi     28040000   1     CL4        cr0=gr4,0
  417| 0036F4 lwz        80C50000   1     L4A       gr6=(*)_object._object.ob_refcnt(gr5,0)                                                                       209| 003774 bc         41820008   1     BT         CL.1714,cr0,0x4/eq,taken=50%(0,0)
  415| 0036F8 lwz        80E40000   1     L4A       gr7=<s117:d0:l4>(gr4,0)                                                                                       209| 003778 ori        60850000   2     LR         gr5=gr4
  417| 0036FC addi       3806FFFF   1     AI        gr0=gr6,-1                                                                                                    209|                                CL.1714:
  417| 003700 stw        90050000   1     ST4A      (*)_object._object.ob_refcnt(gr5,0)=gr0                                                                       401| 00377C lwz        80820004   1     L4A        gr4=._Py_RefTotal(gr2,0)
  415| 003704 addi       38C7FFFF   1     AI        gr6=gr7,-1                                                                                                    403| 003780 lwz        80C50000   1     L4A        gr6=(*)_object._object.ob_refcnt(gr5,0)
  415| 003708 stw        90C40000   1     ST4A      <s117:d0:l4>(gr4,0)=gr6                                                                                       211| 003784 addi       38030004   1     AI         gr0=gr3,4
  417| 00370C cmpwi      2C000000   1     C4        cr0=gr0,0                                                                                                     211| 003788 stw        901E0024   1     ST4A       (*)_frame._frame.f_stacktop(gr30,36)=gr0
  417| 003710 bc         4182FEE4   1     BT        CL.2036,cr0,0x4/eq,taken=40%(40,60)                                                                           211| 00378C stw        90A30000   1     ST4A       (*)_object*(gr3,0)=gr5
    0| 003714 bc         4080FED4   1     BF        CL.1632,cr0,0x1/lt,taken=50%(0,0)                                                                             403| 003790 addi       38060001   1     AI         gr0=gr6,1
    0| 003718 b          4BFFFE18   1     B         CL.1631,-1                                                                                                    403| 003794 stw        90050000   1     ST4A       (*)_object._object.ob_refcnt(gr5,0)=gr0
    0|                                CL.1628:                                                                                                                    401| 003798 lwz        80640000   1     L4A        gr3=_Py_RefTotal(gr4,0)
   79| 00371C addi       38A0004F   1     LI        gr5=79                                                                                                        401| 00379C addi       38030001   2     AI         gr0=gr3,1
   79| 003720 lwz        80620018   1     L4A       gr3=.+CONSTANT_AREA(gr2,0)                                                                                    401| 0037A0 stw        90040000   1     ST4A       _Py_RefTotal(gr4,0)=gr0
   79| 003724 addi       38831174   2     AI        gr4=gr3,4468                                                                                                  206|                                CL.279:
   79| 003728 addi       386311C4   1     AI        gr3=gr3,4548                                                                                                  216| 0037A4 lwz        807C000C   1     L4A        gr3=(*)_ts._ts.frame(gr28,12)
   79| 00372C bl         4BFFC8D5   0     CALL      __assert,3,gr3-gr5,#ProcAlias",__assert",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",lr",fcr",xer",f     0| 0037A8 or.        7C601B79   2     LR_R       gr0,cr0=gr3
   79| 003730 ori        60000000   1                                                                                                                             482| 0037AC bc         41820020   1     BT         CL.911,cr0,0x4/eq,taken=30%(30,70)
   81| 003734 lwzx       7CFCE82E   1     L4A       gr7=(*)_object*()*(gr28,gr29,0)                                                                               401| 0037B0 lwz        80A20004   1     L4A        gr5=._Py_RefTotal(gr2,0)
    0| 003738 or.        7CE03B79   2     LR_R      gr0,cr0=gr7                                                                                                   403| 0037B4 lwz        80830000   1     L4A        gr4=(*)_object._object.ob_refcnt(gr3,0)
  114| 00373C bc         4182FF88   1     BT        CL.2044,cr0,0x4/eq,taken=30%(30,70)                                                                           403| 0037B8 addi       38040001   2     AI         gr0=gr4,1
    0| 003740 b          4BFFFF00   1     B         CL.2049,-1                                                                                                    401| 0037BC lwz        80850000   1     L4A        gr4=_Py_RefTotal(gr5,0)
    0|                                CL.1642:                                                                                                                    403| 0037C0 stw        90030000   1     ST4A       (*)_object._object.ob_refcnt(gr3,0)=gr0
   77| 003744 addi       38A0004D   1     LI        gr5=77                                                                                                        401| 0037C4 addi       38040001   1     AI         gr0=gr4,1
   77| 003748 lwz        80620018   1     L4A       gr3=.+CONSTANT_AREA(gr2,0)                                                                                    401| 0037C8 stw        90050000   1     ST4A       _Py_RefTotal(gr5,0)=gr0
   77| 00374C addi       38831174   2     AI        gr4=gr3,4468                                                                                                  484|                                CL.911:
   77| 003750 addi       386311A8   1     AI        gr3=gr3,4520                                                                                                  217| 0037CC lwz        801E000C   1     L4A        gr0=(*)_frame._frame.f_back(gr30,12)
   77| 003754 bl         4BFFC8AD   0     CALL      __assert,3,gr3-gr5,#ProcAlias",__assert",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",lr",fcr",xer",f   217| 0037D0 cmpwi      2C000000   2     C4         cr0=gr0,0
   77| 003758 ori        60000000   1                                                                                                                             217| 0037D4 bc         40820504   1     BF         CL.2066,cr0,0x4/eq,taken=40%(40,60)
   78| 00375C lwz        83BE001C   1     L4A       gr29=(*)_typeobject._typeobject.tp_vectorcall_offset(gr30,28)                                                 217|                                CL.287:
    0| 003760 or.        7FA0EB79   2     LR_R      gr0,cr0=gr29                                                                                                  218| 0037D8 stw        907E000C   1     ST4A       (*)_frame._frame.f_back(gr30,12)=gr3
   79| 003764 bc         4081000C   1     BF        CL.2043,cr0,0x2/gt,taken=40%(40,60)                                                                           220| 0037DC stb        9B7F000C   1     ST1Z       (*)aggr#3.gi_running(gr31,12)=gr27
    0| 003768 lwz        83C100C8   1     L4A       gr30=#stack(gr1,200)                                                                                          222| 0037E0 addi       381F0020   1     AI         gr0=gr31,32
    0| 00376C b          4BFFFEC8   0     B         CL.1629,-1                                                                                                     40| 0037E4 ori        63A50000   1     LR         gr5=gr29
    0|                                CL.2043:                                                                                                                    221| 0037E8 lwz        80FC0050   1     L4A        gr7=(*)_ts._ts.exc_info(gr28,80)
   79| 003770 addi       38A0004F   1     LI        gr5=79                                                                                                         40| 0037EC lwz        80DC0008   1     L4A        gr6=(*)_ts._ts.interp(gr28,8)
   79| 003774 lwz        80620018   1     L4A       gr3=.+CONSTANT_AREA(gr2,0)                                                                                     40| 0037F0 ori        63830000   1     LR         gr3=gr28
    0| 003778 lwz        83C100C8   1     L4A       gr30=#stack(gr1,200)                                                                                           40| 0037F4 ori        63C40000   1     LR         gr4=gr30
   79| 00377C addi       38831174   1     AI        gr4=gr3,4468                                                                                                  221| 0037F8 stw        90FF002C   1     ST4A       (*)aggr#3._err_stackitem.previous_item(gr31,44)=gr7
   79| 003780 addi       386311C4   1     AI        gr3=gr3,4548                                                                                                  222| 0037FC stw        901C0050   1     ST4A       (*)_ts._ts.exc_info(gr28,80)=gr0
   79| 003784 bl         4BFFC87D   0     CALL      __assert,3,gr3-gr5,#ProcAlias",__assert",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",lr",fcr",xer",f    40| 003800 lwz        80C60304   1     L4A        gr6=(*)_is._is.eval_frame(gr6,772)
   79| 003788 ori        60000000   1                                                                                                                              40| 003804 lwz        80060000   2     L4A        gr0=#fnc_adr(gr6,0)
   81| 00378C lwzx       7CFCE82E   1     L4A       gr7=(*)_object*()*(gr28,gr29,0)                                                                                40| 003808 lwz        81660008   1     L4A        gr11=#new_env(gr6,8)
    0| 003790 or.        7CE03B79   2     LR_R      gr0,cr0=gr7                                                                                                    40| 00380C mtspr      7C0903A6   1     LCTR       ctr=gr0
  114| 003794 bc         4182FF30   1     BT        CL.2044,cr0,0x4/eq,taken=30%(30,70)                                                                            40| 003810 lwz        80460004   1     CALL       gr3=gr6,3,(*)_ts",gr3,(*)_frame",gr4,gr5,#ProcAlias",fcr",(*)_object*()",gr1,cr[01567]",gr0",gr4"-gr12",fp
    0| 003798 b          4BFFFEA8   1     B         CL.2049,-1                                                                                                     40| 003814 bcctrl     4E800421   0
    0|                                CL.1641:                                                                                                                     40| 003818 lwz        80410014   1
   72| 00379C addi       38A00048   1     LI        gr5=72                                                                                                        223| 00381C ori        607D0000   1     LR         gr29=gr3
   72| 0037A0 lwz        80620018   1     L4A       gr3=.+CONSTANT_AREA(gr2,0)                                                                                    225| 003820 addi       3B000000   1     LI         gr24=0
   72| 0037A4 addi       38831174   2     AI        gr4=gr3,4468                                                                                                  231| 003824 lwz        80BE000C   1     L4A        gr5=(*)_frame._frame.f_back(gr30,12)







Wed Apr 15 07:30:04 CDT 2020  Page 124


   72| 0037A8 addi       38631194   1     AI        gr3=gr3,4500                                                                                                  231| 003828 lwz        807C000C   1     L4A        gr3=(*)_ts._ts.frame(gr28,12)
   72| 0037AC bl         4BFFC855   0     CALL      __assert,3,gr3-gr5,#ProcAlias",__assert",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",lr",fcr",xer",f   224| 00382C lwz        809F002C   1     L4A        gr4=(*)aggr#3._err_stackitem.previous_item(gr31,44)
   72| 0037B0 ori        60000000   1                                                                                                                             224| 003830 stw        909C0050   2     ST4A       (*)_ts._ts.exc_info(gr28,80)=gr4
   73| 0037B4 lwz        83DC0004   1     L4A       gr30=(*)_object._object.ob_type(gr28,4)                                                                         0| 003834 ori        60A00000   1     LR         gr0=gr5
  617| 0037B8 ori        63C30000   2     LR        gr3=gr30                                                                                                      231| 003838 cmplw      7C032840   1     CL4        cr0=gr3,gr5
  617| 0037BC bl         4BFFC845   0     CALL      gr3=PyType_GetFlags,1,(*)_typeobject",gr3,#ProcAlias",PyType_GetFlags",fcr",gr1,cr[01567]",gr0",gr4"-gr12",   225| 00383C stw        931F002C   1     ST4A       (*)aggr#3._err_stackitem.previous_item(gr31,44)=gr24
  617| 0037C0 ori        60000000   1                                                                                                                             226| 003840 stb        9B1F000C   1     ST1Z       (*)aggr#3.gi_running(gr31,12)=gr24
   74| 0037C4 andi.      70600800   1     RN4_R     gr0,cr0=gr3,0,0x800                                                                                           231| 003844 bc         40820470   0     BF         CL.2067,cr0,0x4/eq,taken=40%(40,60)
   74| 0037C8 bc         4082FE44   1     BF        CL.1004,cr0,0x4/eq,taken=50%(0,0)                                                                             231|                                CL.289:
    0| 0037CC b          4BFFFD0C   1     B         CL.2050,-1                                                                                                    232| 003848 cmpwi      2C000000   1     C4         cr0=gr0,0
    0|                                CL.2035:                                                                                                                    232| 00384C bc         41820038   1     BT         CL.294,cr0,0x4/eq,taken=50%(0,0)
    0|                                CL.1634:                                                                                                                    415| 003850 lwz        80820004   2     L4A        gr4=._Py_RefTotal(gr2,0)
  491| 0037D0 cmpwi      2C1F0000   1     C4        cr0=gr31,0                                                                                                    417| 003854 lwz        80C50000   1     L4A        gr6=(*)_object._object.ob_refcnt(gr5,0)
  491| 0037D4 bc         4182FDA8   1     BT        CL.1637,cr0,0x4/eq,taken=30%(30,70)                                                                             0| 003858 lwz        80620018   1     L4A        gr3=.+CONSTANT_AREA(gr2,0)
    0| 0037D8 b          4BFFFD74   1     B         CL.1635,-1                                                                                                    232| 00385C stw        931E000C   1     ST4A       (*)_frame._frame.f_back(gr30,12)=gr24
    0|                                CL.1640:                                                                                                                    417| 003860 addi       3806FFFF   1     AI         gr0=gr6,-1
  318| 0037DC ori        60C30000   1     LR        gr3=gr6                                                                                                       417| 003864 stw        90050000   1     ST4A       (*)_object._object.ob_refcnt(gr5,0)=gr0
  318| 0037E0 bl         4BFFC821   0     CALL      PyErr_WriteUnraisable,1,(*)_object",gr3,#ProcAlias",PyErr_WriteUnraisable",fcr",gr1,cr[01567]",gr0",gr3"-gr   408| 003868 addi       38631110   1     AI         gr3=gr3,4368
  318| 0037E4 ori        60000000   1                                                                                                                             415| 00386C lwz        80C40000   1     L4A        gr6=_Py_RefTotal(gr4,0)
  320| 0037E8 lwz        8381004C   1     L4A       gr28=meth(gr1,76)                                                                                             415| 003870 addi       38C6FFFF   2     AI         gr6=gr6,-1
  320| 0037EC cmpwi      2C1C0000   2     C4        cr0=gr28,0                                                                                                    415| 003874 stw        90C40000   1     ST4A       _Py_RefTotal(gr4,0)=gr6
  320| 0037F0 bc         4082FCBC   1     BF        CL.1622,cr0,0x4/eq,taken=40%(40,60)                                                                           417| 003878 cmpwi      2C000000   1     C4         cr0=gr0,0
  491| 0037F4 cmpwi      2C1F0000   2     C4        cr0=gr31,0                                                                                                    417| 00387C bc         41820428   1     BT         CL.916,cr0,0x4/eq,taken=40%(40,60)
  491| 0037F8 bc         4182FD84   1     BT        CL.1637,cr0,0x4/eq,taken=30%(30,70)                                                                           419| 003880 bc         41800414   1     BT         CL.2068,cr0,0x1/lt,taken=40%(40,60)
    0| 0037FC b          4BFFFD50   1     B         CL.1635,-1                                                                                                    232|                                CL.294:
  310|                                CL.259:                                                                                                                     236| 003884 cmpwi      2E1D0000   1     C4         cr4=gr29,0
  311| 003800 bl         48001541   0     CALL      gr3=gen_close,2,(*)aggr#3",gr3,(*)_object",gr4,#ProcAlias",gen_close",fcr",gr1,cr[01567]",gr0",gr4"-gr12",f   236| 003888 bc         41920350   1     BT         CL.1583,cr4,0x4/eq,taken=40%(40,60)
  311| 003804 or.        7C7F1B79   1     LR_R      gr31,cr0=gr3                                                                                                  236| 00388C lwz        801E0024   2     L4A        gr0=(*)_frame._frame.f_stacktop(gr30,36)
  312| 003808 bc         4082FFC8   1     BF        CL.1634,cr0,0x4/eq,taken=70%(70,30)                                                                           236| 003890 cmpwi      2C000000   2     C4         cr0=gr0,0
  329| 00380C addi       382100D0   2     AI        gr1=gr1,208                                                                                                   236| 003894 bc         4082006C   1     BF         CL.296,cr0,0x4/eq,taken=50%(0,0)
  313| 003810 addi       3860FFFF   1     LI        gr3=-1                                                                                                        237| 003898 lwz        80020008   1     L4A        gr0=._Py_NoneStruct(gr2,0)
    0| 003814 lwz        80010008   1     L4A       gr0=#stack(gr1,8)                                                                                               0| 00389C lwz        806200E0   1     L4A        gr3=.PyAsyncGen_Type(gr2,0)
    0| 003818 mtspr      7C0803A6   2     LLR       lr=gr0                                                                                                          0| 0038A0 lwz        809F0004   1     L4A        gr4=(*)C_object._object.ob_type(gr31,4)
  329| 00381C bclr       4E800020   3     BA        lr                                                                                                            237| 0038A4 cmplw      7C00E840   1     CL4        cr0=gr0,gr29
     |               Tag Table                                                                                                                                    237| 0038A8 bc         408202F8   1     BF         CL.297,cr0,0x4/eq,taken=50%(0,0)
     | 003820        00000000 00002041 80040100 00000000 000003E0 00144950                                                                                        128| 0038AC cmplw      7C041840   2     CL4        cr0=gr4,gr3
     | 003838        52412E24 67656E5F 636C6F73 655F6974 6572                                                                                                     239| 0038B0 bc         408202DC   1     BF         CL.298,cr0,0x4/eq,taken=50%(0,0)
     |               Instruction count          248                                                                                                               240| 0038B4 lwz        80620024   2     L4A        gr3=.PyExc_StopAsyncIteration(gr2,0)
     |               Straight-line exec time    259                                                                                                               240| 0038B8 lwz        80630000   2     L4A        gr3=PyExc_StopAsyncIteration(gr3,0)
 GPR's set/used:   ssus ssss ssss s---  ---- ---- ssss ssss                                                                                                       240| 0038BC bl         4BFFC745   0     CALL       PyErr_SetNone,1,(*)_object",gr3,#ProcAlias",PyErr_SetNone",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",
 FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----                                                                                                       240| 0038C0 ori        60000000   1
 CCR's set/used:   ss-- ssss                                                                                                                                      244|                                CL.299:
     | 000000                             PDEF     gen_send_ex                                                                                                    251| 0038C4 ori        63A50000   1     LR         gr5=gr29
  154|                                    PROC      gen,arg,exc,closing,gr3-gr6                                                                                   251| 0038C8 addi       3BA00000   1     LI         gr29=0
    0| 003860 mfspr      7C0802A6   1     LFLR      gr0=lr                                                                                                          0| 0038CC lwz        80620018   1     L4A        gr3=.+CONSTANT_AREA(gr2,0)
    0| 003864 mfcr       7D800026   1     LFCR      gr12=cr4,4                                                                                                    415| 0038D0 lwz        80820004   1     L4A        gr4=._Py_RefTotal(gr2,0)
    0| 003868 stw        90010008   1     ST4A      #stack(gr1,8)=gr0                                                                                             408| 0038D4 addi       38631110   1     AI         gr3=gr3,4368
    0| 00386C stw        93E1FFFC   1     ST4A      #stack(gr1,-4)=gr31                                                                                           417| 0038D8 lwz        80C50000   1     L4A        gr6=(*)_object._object.ob_refcnt(gr5,0)
    0| 003870 ori        607F0000   1     LR        gr31=gr3                                                                                                      415| 0038DC lwz        80E40000   1     L4A        gr7=_Py_RefTotal(gr4,0)
    0| 003874 stw        93C1FFF8   1     ST4A      #stack(gr1,-8)=gr30                                                                                           417| 0038E0 addi       3806FFFF   1     AI         gr0=gr6,-1
    0| 003878 stw        93A1FFF4   1     ST4A      #stack(gr1,-12)=gr29                                                                                          417| 0038E4 stw        90050000   1     ST4A       (*)_object._object.ob_refcnt(gr5,0)=gr0
    0| 00387C ori        60BD0000   1     LR        gr29=gr5                                                                                                      415| 0038E8 addi       38C7FFFF   1     AI         gr6=gr7,-1
    0| 003880 stw        9381FFF0   1     ST4A      #stack(gr1,-16)=gr28                                                                                          415| 0038EC stw        90C40000   1     ST4A       _Py_RefTotal(gr4,0)=gr6
    0| 003884 stw        9361FFEC   1     ST4A      #stack(gr1,-20)=gr27                                                                                          417| 0038F0 cmpwi      2C000000   1     C4         cr0=gr0,0
   53| 003888 addi       3B600001   1     LI        gr27=1                                                                                                        417| 0038F4 bc         41820288   1     BT         CL.924,cr0,0x4/eq,taken=40%(40,60)
    0| 00388C stw        9341FFE8   1     ST4A      #stack(gr1,-24)=gr26                                                                                          419| 0038F8 bc         41800274   1     BT         CL.2070,cr0,0x1/lt,taken=40%(40,60)







Wed Apr 15 07:30:04 CDT 2020  Page 125


    0| 003890 stw        9321FFE4   1     ST4A      #stack(gr1,-28)=gr25                                                                                            0|                                CL.1584:
    0| 003894 stw        9301FFE0   1     ST4A      #stack(gr1,-32)=gr24                                                                                            0| 0038FC cmpwi      2E1D0000   1     C4         cr4=gr29,0
    0| 003898 stw        91810004   1     ST4A      #stack(gr1,4)=gr12                                                                                            252|                                CL.296:
   67| 00389C lwz        806200A4   1     L4A       gr3=._PyRuntime(gr2,0)                                                                                        274| 003900 bc         41920010   0     BT         CL.314,cr4,0x4/eq,taken=50%(0,0)
  160| 0038A0 lbz        881F000C   1     L1Z       gr0=(*)aggr#3.gi_running(gr31,12)                                                                             274| 003904 lwz        801E0024   2     L4A        gr0=(*)_frame._frame.f_stacktop(gr30,36)
    0| 0038A4 stwu       9421FF20   1     ST4U      gr1,#stack(gr1,-224)=gr1                                                                                      274| 003908 cmpwi      2C000000   2     C4         cr0=gr0,0
  160| 0038A8 cmpwi      2C000000   1     C4        cr0=gr0,0                                                                                                     274| 00390C bc         4082022C   1     BF         CL.2058,cr0,0x4/eq,taken=50%(0,0)
   40| 0038AC stw        90410014   1     ST4A      #cur_toc(gr1,20)=gr2                                                                                          274|                                CL.314:
   54| 0038B0 lwz        838301A0   1     L4A       gr28=<s149:d416:l4>(gr3,416)                                                                                  106| 003910 lwz        80BF0020   1     L4A        gr5=(*)_err_stackitem._err_stackitem.exc_type(gr31,32)
  160| 0038B4 bc         41820074   0     BT        CL.267,cr0,0x4/eq,taken=50%(0,0)                                                                                0| 003914 lwz        83820004   1     L4A        gr28=._Py_RefTotal(gr2,0)
  162| 0038B8 lwz        800200D8   2     L4A       gr0=.PyCoro_Type(gr2,0)                                                                                         0| 003918 or.        7CA02B79   1     LR_R       gr0,cr0=gr5
  128| 0038BC lwz        80BF0004   1     L4A       gr5=(*)C_object._object.ob_type(gr31,4)                                                                       107| 00391C lwz        837F0024   1     L4A        gr27=(*)_err_stackitem._err_stackitem.exc_value(gr31,36)
  161| 0038C0 lwz        80620018   1     L4A       gr3=.+CONSTANT_AREA(gr2,0)                                                                                    108| 003920 lwz        835F0028   1     L4A        gr26=(*)_err_stackitem._err_stackitem.exc_traceback(gr31,40)
  128| 0038C4 cmplw      7C050040   1     CL4       cr0=gr5,gr0                                                                                                   109| 003924 stw        931F0020   1     ST4A       (*)_err_stackitem._err_stackitem.exc_type(gr31,32)=gr24
    0| 0038C8 lwz        83A100D4   1     L4A       gr29=#stack(gr1,212)                                                                                            0| 003928 lwz        83220018   1     L4A        gr25=.+CONSTANT_AREA(gr2,0)
  161| 0038CC addi       38830CA0   1     AI        gr4=gr3,3232                                                                                                  110| 00392C stw        931F0024   1     ST4A       (*)_err_stackitem._err_stackitem.exc_value(gr31,36)=gr24
    0| 0038D0 lwz        838100D0   1     L4A       gr28=#stack(gr1,208)                                                                                          111| 003930 stw        931F0028   1     ST4A       (*)_err_stackitem._err_stackitem.exc_traceback(gr31,40)=gr24
    0| 0038D4 lwz        836100CC   1     L4A       gr27=#stack(gr1,204)                                                                                            0| 003934 lwz        809C0000   1     L4A        gr4=_Py_RefTotal(gr28,0)
  162| 0038D8 bc         40820038   0     BF        CL.268,cr0,0x4/eq,taken=50%(0,0)                                                                              491| 003938 bc         4182002C   0     BT         CL.934,cr0,0x4/eq,taken=30%(30,70)
  163| 0038DC addi       38830CBC   2     AI        gr4=gr3,3260                                                                                                  408| 00393C addi       38791124   2     AI         gr3=gr25,4388
    0| 0038E0 lwz        83E100DC   1     L4A       gr31=#stack(gr1,220)                                                                                          417| 003940 lwz        80C50000   1     L4A        gr6=(*)_object._object.ob_refcnt(gr5,0)
  167|                                CL.269:                                                                                                                     415| 003944 addi       3884FFFF   1     AI         gr4=gr4,-1
  168| 0038E4 lwz        806200DC   1     L4A       gr3=.PyExc_ValueError(gr2,0)                                                                                  415| 003948 stw        909C0000   1     ST4A       _Py_RefTotal(gr28,0)=gr4
  168| 0038E8 lwz        80630000   2     L4A       gr3=<s147:d0:l4>(gr3,0)                                                                                       417| 00394C addi       3806FFFF   1     AI         gr0=gr6,-1
  168| 0038EC bl         4BFFC715   0     CALL      PyErr_SetString,2,(*)_object",gr3,(*)Cuchar",gr4,#ProcAlias",PyErr_SetString",fcr",gr1,cr[01567]",gr0",gr3"   417| 003950 stw        90050000   1     ST4A       (*)_object._object.ob_refcnt(gr5,0)=gr0
  168| 0038F0 ori        60000000   1                                                                                                                             417| 003954 cmpwi      2C060001   1     C4         cr0=gr6,1
  169| 0038F4 addi       38600000   1     LI        gr3=0                                                                                                         417| 003958 cmpwi      2C800000   1     C4         cr1=gr0,0
    0| 0038F8 lwz        800100E8   1     L4A       gr0=#stack(gr1,232)                                                                                           417| 00395C bc         418201C8   0     BT         CL.935,cr0,0x4/eq,taken=40%(40,60)
  284| 0038FC lwz        818100E4   1     L4A       gr12=#stack(gr1,228)                                                                                          419| 003960 bc         418401B0   1     BT         CL.2071,cr1,0x1/lt,taken=40%(40,60)
  284| 003900 addi       382100E0   1     AI        gr1=gr1,224                                                                                                   493|                                CL.934:
    0| 003904 mtspr      7C0803A6   1     LLR       lr=gr0                                                                                                        491| 003964 cmpwi      2C1B0000   1     C4         cr0=gr27,0
  284| 003908 mtcrf      7D808120   1     MTCRF     cr4=gr12                                                                                                      491| 003968 bc         4182002C   1     BT         CL.940,cr0,0x4/eq,taken=30%(30,70)
  284| 00390C bclr       4E800020   2     BA        lr                                                                                                            408| 00396C addi       38791124   2     AI         gr3=gr25,4388
  164|                                CL.268:                                                                                                                     415| 003970 addi       3884FFFF   1     AI         gr4=gr4,-1
  165| 003910 lwz        800200E0   1     L4A       gr0=.PyAsyncGen_Type(gr2,0)                                                                                   415| 003974 stw        909C0000   1     ST4A       _Py_RefTotal(gr28,0)=gr4
    0| 003914 lwz        83E100DC   1     L4A       gr31=#stack(gr1,220)                                                                                          417| 003978 lwz        80BB0000   1     L4A        gr5=(*)_object._object.ob_refcnt(gr27,0)
  128| 003918 cmplw      7C050040   1     CL4       cr0=gr5,gr0                                                                                                   417| 00397C addi       3805FFFF   2     AI         gr0=gr5,-1
  165| 00391C bc         4082FFC8   1     BF        CL.269,cr0,0x4/eq,taken=50%(0,0)                                                                              417| 003980 stw        901B0000   1     ST4A       (*)_object._object.ob_refcnt(gr27,0)=gr0
  166| 003920 addi       38830CD8   2     AI        gr4=gr3,3288                                                                                                  417| 003984 cmpwi      2C050001   1     C4         cr0=gr5,1
    0| 003924 b          4BFFFFC0   0     B         CL.269,-1                                                                                                     417| 003988 cmpwi      2C800000   1     C4         cr1=gr0,0
  170|                                CL.267:                                                                                                                     417| 00398C bc         41820170   0     BT         CL.941,cr0,0x4/eq,taken=40%(40,60)
  157| 003928 lwz        83DF0008   1     L4A       gr30=(*)aggr#3.gi_frame(gr31,8)                                                                               419| 003990 bc         41840154   1     BT         CL.2072,cr1,0x1/lt,taken=40%(40,60)
    0| 00392C or.        7FC0F379   2     LR_R      gr0,cr0=gr30                                                                                                  493|                                CL.940:
  171| 003930 bc         41820650   1     BT        CL.2010,cr0,0x4/eq,taken=30%(30,70)                                                                           491| 003994 cmpwi      2C1A0000   1     C4         cr0=gr26,0
  171| 003934 lwz        807E0024   1     L4A       gr3=(*)_frame._frame.f_stacktop(gr30,36)                                                                      491| 003998 bc         4182002C   1     BT         CL.2060,cr0,0x4/eq,taken=30%(30,70)
  171| 003938 cmpwi      2C030000   2     C4        cr0=gr3,0                                                                                                     408| 00399C addi       38791124   2     AI         gr3=gr25,4388
  171| 00393C bc         41820644   1     BT        CL.2010,cr0,0x4/eq,taken=50%(0,0)                                                                             415| 0039A0 addi       3884FFFF   1     AI         gr4=gr4,-1
  193| 003940 lwz        801E0034   1     L4A       gr0=(*)_frame._frame.f_lasti(gr30,52)                                                                         415| 0039A4 stw        909C0000   1     ST4A       _Py_RefTotal(gr28,0)=gr4
  193| 003944 cmpwi      2C00FFFF   2     C4        cr0=gr0,-1                                                                                                    417| 0039A8 lwz        80BA0000   1     L4A        gr5=(*)_object._object.ob_refcnt(gr26,0)
  193| 003948 bc         41820584   1     BT        CL.2014,cr0,0x4/eq,taken=40%(40,60)                                                                           417| 0039AC addi       3805FFFF   2     AI         gr0=gr5,-1
  209| 00394C lwz        80A20008   1     L4A       gr5=._Py_NoneStruct(gr2,0)                                                                                    417| 0039B0 stw        901A0000   1     ST4A       (*)_object._object.ob_refcnt(gr26,0)=gr0
    0| 003950 cmplwi     28040000   1     CL4       cr0=gr4,0                                                                                                     417| 0039B4 cmpwi      2C050001   1     C4         cr0=gr5,1
  209| 003954 bc         41820008   1     BT        CL.1590,cr0,0x4/eq,taken=50%(0,0)                                                                             417| 0039B8 cmpwi      2C800000   1     C4         cr1=gr0,0
  209| 003958 ori        60850000   2     LR        gr5=gr4                                                                                                       417| 0039BC bc         41820110   0     BT         CL.947,cr0,0x4/eq,taken=40%(40,60)
  209|                                CL.1590:                                                                                                                    419| 0039C0 bc         418400F0   1     BT         CL.2073,cr1,0x1/lt,taken=40%(40,60)
  401| 00395C lwz        80820004   1     L4A       gr4=._Py_RefTotal(gr2,0)                                                                                        0|                                CL.2060:







Wed Apr 15 07:30:04 CDT 2020  Page 126


  403| 003960 lwz        80C50000   1     L4A       gr6=(*)_object._object.ob_refcnt(gr5,0)                                                                         0| 0039C4 lwz        83410098   1     L4A        gr26=#stack(gr1,152)
  211| 003964 addi       38030004   1     AI        gr0=gr3,4                                                                                                     493|                                CL.946:
  211| 003968 stw        901E0024   1     ST4A      (*)_frame._frame.f_stacktop(gr30,36)=gr0                                                                      278| 0039C8 lwz        80BF0008   1     L4A        gr5=(*)aggr#3.gi_frame(gr31,8)
  211| 00396C stw        90A30000   1     ST4A      (*)_object*(gr3,0)=gr5                                                                                        408| 0039CC addi       38791110   1     AI         gr3=gr25,4368
  403| 003970 addi       38060001   1     AI        gr0=gr6,1                                                                                                     415| 0039D0 addi       3804FFFF   1     AI         gr0=gr4,-1
  403| 003974 stw        90050000   1     ST4A      (*)_object._object.ob_refcnt(gr5,0)=gr0                                                                       417| 0039D4 lwz        809E0000   1     L4A        gr4=(*)_object._object.ob_refcnt(gr30,0)
  401| 003978 lwz        80640000   1     L4A       gr3=<s117:d0:l4>(gr4,0)                                                                                       279| 0039D8 stw        931F0008   1     ST4A       (*)aggr#3.gi_frame(gr31,8)=gr24
  401| 00397C addi       38030001   2     AI        gr0=gr3,1                                                                                                     415| 0039DC stw        901C0000   1     ST4A       _Py_RefTotal(gr28,0)=gr0
  401| 003980 stw        90040000   1     ST4A      <s117:d0:l4>(gr4,0)=gr0                                                                                       417| 0039E0 addi       3804FFFF   1     AI         gr0=gr4,-1
  206|                                CL.279:                                                                                                                     417| 0039E4 stw        901E0000   1     ST4A       (*)_object._object.ob_refcnt(gr30,0)=gr0
  216| 003984 lwz        807C000C   1     L4A       gr3=(*)_ts._ts.frame(gr28,12)                                                                                 278| 0039E8 stw        93050030   1     ST4A       (*)_frame._frame.f_gen(gr5,48)=gr24
    0| 003988 or.        7C601B79   2     LR_R      gr0,cr0=gr3                                                                                                   417| 0039EC cmpwi      2C000000   1     C4         cr0=gr0,0
  482| 00398C bc         41820020   1     BT        CL.911,cr0,0x4/eq,taken=30%(30,70)                                                                            417| 0039F0 bc         4182007C   1     BT         CL.953,cr0,0x4/eq,taken=40%(40,60)
  401| 003990 lwz        80A20004   1     L4A       gr5=._Py_RefTotal(gr2,0)                                                                                        0| 0039F4 lwz        83E100AC   2     L4A        gr31=#stack(gr1,172)
  403| 003994 lwz        80830000   1     L4A       gr4=(*)_object._object.ob_refcnt(gr3,0)                                                                         0| 0039F8 lwz        83210094   1     L4A        gr25=#stack(gr1,148)
  403| 003998 addi       38040001   2     AI        gr0=gr4,1                                                                                                       0| 0039FC lwz        83010090   1     L4A        gr24=#stack(gr1,144)
  401| 00399C lwz        80850000   1     L4A       gr4=<s117:d0:l4>(gr5,0)                                                                                       419| 003A00 bc         41800030   0     BT         CL.2074,cr0,0x1/lt,taken=40%(40,60)
  403| 0039A0 stw        90030000   1     ST4A      (*)_object._object.ob_refcnt(gr3,0)=gr0                                                                       283| 003A04 ori        63A30000   2     LR         gr3=gr29
  401| 0039A4 addi       38040001   1     AI        gr0=gr4,1                                                                                                       0| 003A08 lwz        83C100A8   1     L4A        gr30=#stack(gr1,168)
  401| 0039A8 stw        90050000   1     ST4A      <s117:d0:l4>(gr5,0)=gr0                                                                                         0| 003A0C lwz        8361009C   1     L4A        gr27=#stack(gr1,156)
  484|                                CL.911:                                                                                                                       0| 003A10 lwz        800100B8   1     L4A        gr0=#stack(gr1,184)
  217| 0039AC lwz        801E000C   1     L4A       gr0=(*)_frame._frame.f_back(gr30,12)                                                                            0| 003A14 lwz        838100A0   1     L4A        gr28=#stack(gr1,160)
  217| 0039B0 cmpwi      2C000000   2     C4        cr0=gr0,0                                                                                                       0| 003A18 lwz        83A100A4   1     L4A        gr29=#stack(gr1,164)
  217| 0039B4 bc         408204F8   1     BF        CL.2015,cr0,0x4/eq,taken=40%(40,60)                                                                           284| 003A1C lwz        818100B4   1     L4A        gr12=#stack(gr1,180)
  217|                                CL.287:                                                                                                                     284| 003A20 addi       382100B0   1     AI         gr1=gr1,176
  218| 0039B8 stw        907E000C   1     ST4A      (*)_frame._frame.f_back(gr30,12)=gr3                                                                            0| 003A24 mtspr      7C0803A6   1     LLR        lr=gr0
  220| 0039BC stb        9B7F000C   1     ST1Z      (*)aggr#3.gi_running(gr31,12)=gr27                                                                            284| 003A28 mtcrf      7D808120   1     MTCRF      cr4=gr12
  222| 0039C0 addi       381F0020   1     AI        gr0=gr31,32                                                                                                   284| 003A2C bclr       4E800020   2     BA         lr
   40| 0039C4 ori        63A50000   1     LR        gr5=gr29                                                                                                        0|                                CL.2074:
  221| 0039C8 lwz        80FC0050   1     L4A       gr7=(*)_ts._ts.exc_info(gr28,80)                                                                              420| 003A30 addi       38800118   1     LI         gr4=280
   40| 0039CC lwz        80DC0008   1     L4A       gr6=(*)_ts._ts.interp(gr28,8)                                                                                 420| 003A34 ori        63C50000   1     LR         gr5=gr30
   40| 0039D0 ori        63830000   1     LR        gr3=gr28                                                                                                      420| 003A38 bl         4BFFC5C9   0     CALL       _Py_NegativeRefcount,3,(*)Cuchar",gr3,gr4,(*)_object",gr5,#ProcAlias",_Py_NegativeRefcount",fcr",gr1,cr[01
   40| 0039D4 ori        63C40000   1     LR        gr4=gr30                                                                                                      420| 003A3C ori        60000000   1
  221| 0039D8 stw        90FF002C   1     ST4A      (*)aggr#3._err_stackitem.previous_item(gr31,44)=gr7                                                           283| 003A40 ori        63A30000   1     LR         gr3=gr29
  222| 0039DC stw        901C0050   1     ST4A      (*)_ts._ts.exc_info(gr28,80)=gr0                                                                                0| 003A44 lwz        83C100A8   1     L4A        gr30=#stack(gr1,168)
   40| 0039E0 lwz        80C60304   1     L4A       gr6=(*)_is._is.eval_frame(gr6,772)                                                                              0| 003A48 lwz        8361009C   1     L4A        gr27=#stack(gr1,156)
   40| 0039E4 lwz        80060000   2     L4A       gr0=#fnc_adr(gr6,0)                                                                                             0| 003A4C lwz        800100B8   1     L4A        gr0=#stack(gr1,184)
   40| 0039E8 lwz        81660008   1     L4A       gr11=#new_env(gr6,8)                                                                                            0| 003A50 lwz        838100A0   1     L4A        gr28=#stack(gr1,160)
   40| 0039EC mtspr      7C0903A6   1     LCTR      ctr=gr0                                                                                                         0| 003A54 lwz        83A100A4   1     L4A        gr29=#stack(gr1,164)
   40| 0039F0 lwz        80460004   1     CALL      gr3=gr6,3,(*)_ts",gr3,(*)_frame",gr4,gr5,#ProcAlias",fcr",(*)_object*()",gr1,cr[01567]",gr0",gr4"-gr12",fp0   284| 003A58 lwz        818100B4   1     L4A        gr12=#stack(gr1,180)
   40| 0039F4 bcctrl     4E800421   0                                                                                                                             284| 003A5C addi       382100B0   1     AI         gr1=gr1,176
   40| 0039F8 lwz        80410014   1                                                                                                                               0| 003A60 mtspr      7C0803A6   1     LLR        lr=gr0
  223| 0039FC ori        607D0000   1     LR        gr29=gr3                                                                                                      284| 003A64 mtcrf      7D808120   1     MTCRF      cr4=gr12
  225| 003A00 addi       3B000000   1     LI        gr24=0                                                                                                        284| 003A68 bclr       4E800020   2     BA         lr
  231| 003A04 lwz        80BE000C   1     L4A       gr5=(*)_frame._frame.f_back(gr30,12)                                                                          423|                                CL.953:
  231| 003A08 lwz        807C000C   1     L4A       gr3=(*)_ts._ts.frame(gr28,12)                                                                                 425| 003A6C ori        63C30000   1     LR         gr3=gr30
  224| 003A0C lwz        809F002C   1     L4A       gr4=(*)aggr#3._err_stackitem.previous_item(gr31,44)                                                             0| 003A70 lwz        83E100AC   1     L4A        gr31=#stack(gr1,172)
  224| 003A10 stw        909C0050   2     ST4A      (*)_ts._ts.exc_info(gr28,80)=gr4                                                                                0| 003A74 lwz        83210094   1     L4A        gr25=#stack(gr1,148)
    0| 003A14 ori        60A00000   1     LR        gr0=gr5                                                                                                         0| 003A78 lwz        83010090   1     L4A        gr24=#stack(gr1,144)
  231| 003A18 cmplw      7C032840   1     CL4       cr0=gr3,gr5                                                                                                   425| 003A7C bl         4BFFC585   0     CALL       _Py_Dealloc,1,(*)_object",gr3,#ProcAlias",_Py_Dealloc",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",
  225| 003A1C stw        931F002C   1     ST4A      (*)aggr#3._err_stackitem.previous_item(gr31,44)=gr24                                                          425| 003A80 ori        60000000   1
  226| 003A20 stb        9B1F000C   1     ST1Z      (*)aggr#3.gi_running(gr31,12)=gr24                                                                            283| 003A84 ori        63A30000   1     LR         gr3=gr29
  231| 003A24 bc         40820464   0     BF        CL.2016,cr0,0x4/eq,taken=40%(40,60)                                                                             0| 003A88 lwz        83C100A8   1     L4A        gr30=#stack(gr1,168)
  231|                                CL.289:                                                                                                                       0| 003A8C lwz        8361009C   1     L4A        gr27=#stack(gr1,156)
  232| 003A28 cmpwi      2C000000   1     C4        cr0=gr0,0                                                                                                       0| 003A90 lwz        800100B8   1     L4A        gr0=#stack(gr1,184)
  232| 003A2C bc         41820038   1     BT        CL.294,cr0,0x4/eq,taken=50%(0,0)                                                                                0| 003A94 lwz        838100A0   1     L4A        gr28=#stack(gr1,160)







Wed Apr 15 07:30:04 CDT 2020  Page 127


  415| 003A30 lwz        80820004   2     L4A       gr4=._Py_RefTotal(gr2,0)                                                                                        0| 003A98 lwz        83A100A4   1     L4A        gr29=#stack(gr1,164)
  417| 003A34 lwz        80C50000   1     L4A       gr6=(*)_object._object.ob_refcnt(gr5,0)                                                                       284| 003A9C lwz        818100B4   1     L4A        gr12=#stack(gr1,180)
    0| 003A38 lwz        80620018   1     L4A       gr3=.+CONSTANT_AREA(gr2,0)                                                                                    284| 003AA0 addi       382100B0   1     AI         gr1=gr1,176
  232| 003A3C stw        931E000C   1     ST4A      (*)_frame._frame.f_back(gr30,12)=gr24                                                                           0| 003AA4 mtspr      7C0803A6   1     LLR        lr=gr0
  417| 003A40 addi       3806FFFF   1     AI        gr0=gr6,-1                                                                                                    284| 003AA8 mtcrf      7D808120   1     MTCRF      cr4=gr12
  417| 003A44 stw        90050000   1     ST4A      (*)_object._object.ob_refcnt(gr5,0)=gr0                                                                       284| 003AAC bclr       4E800020   2     BA         lr
  408| 003A48 addi       38631110   1     AI        gr3=gr3,4368                                                                                                    0|                                CL.2073:
  415| 003A4C lwz        80C40000   1     L4A       gr6=<s117:d0:l4>(gr4,0)                                                                                       420| 003AB0 addi       388001EC   1     LI         gr4=492
  415| 003A50 addi       38C6FFFF   2     AI        gr6=gr6,-1                                                                                                    420| 003AB4 ori        63450000   1     LR         gr5=gr26
  415| 003A54 stw        90C40000   1     ST4A      <s117:d0:l4>(gr4,0)=gr6                                                                                       420| 003AB8 bl         4BFFC549   0     CALL       _Py_NegativeRefcount,3,(*)Cuchar",gr3,gr4,(*)_object",gr5,#ProcAlias",_Py_NegativeRefcount",fcr",gr1,cr[01
  417| 003A58 cmpwi      2C000000   1     C4        cr0=gr0,0                                                                                                     420| 003ABC ori        60000000   1
  417| 003A5C bc         4182041C   1     BT        CL.916,cr0,0x4/eq,taken=40%(40,60)                                                                              0| 003AC0 lwz        809C0000   1     L4A        gr4=_Py_RefTotal(gr28,0)
  419| 003A60 bc         41800408   1     BT        CL.2017,cr0,0x1/lt,taken=40%(40,60)                                                                             0| 003AC4 lwz        83410098   1     L4A        gr26=#stack(gr1,152)
  232|                                CL.294:                                                                                                                       0| 003AC8 b          4BFFFF00   0     B          CL.946,-1
  236| 003A64 cmpwi      2E1D0000   1     C4        cr4=gr29,0                                                                                                    423|                                CL.947:
  236| 003A68 bc         41920344   1     BT        CL.1585,cr4,0x4/eq,taken=40%(40,60)                                                                           425| 003ACC ori        63430000   1     LR         gr3=gr26
  236| 003A6C lwz        801E0024   2     L4A       gr0=(*)_frame._frame.f_stacktop(gr30,36)                                                                      425| 003AD0 bl         4BFFC531   0     CALL       _Py_Dealloc,1,(*)_object",gr3,#ProcAlias",_Py_Dealloc",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",
  236| 003A70 cmpwi      2C000000   2     C4        cr0=gr0,0                                                                                                     425| 003AD4 ori        60000000   1
  236| 003A74 bc         4082006C   1     BF        CL.296,cr0,0x4/eq,taken=50%(0,0)                                                                                0| 003AD8 lwz        809C0000   1     L4A        gr4=_Py_RefTotal(gr28,0)
  237| 003A78 lwz        80020008   1     L4A       gr0=._Py_NoneStruct(gr2,0)                                                                                      0| 003ADC lwz        83410098   1     L4A        gr26=#stack(gr1,152)
    0| 003A7C lwz        806200E0   1     L4A       gr3=.PyAsyncGen_Type(gr2,0)                                                                                     0| 003AE0 b          4BFFFEE8   0     B          CL.946,-1
    0| 003A80 lwz        809F0004   1     L4A       gr4=(*)C_object._object.ob_type(gr31,4)                                                                         0|                                CL.2072:
  237| 003A84 cmplw      7C00E840   1     CL4       cr0=gr0,gr29                                                                                                  420| 003AE4 addi       388001EC   1     LI         gr4=492
  237| 003A88 bc         408202EC   1     BF        CL.297,cr0,0x4/eq,taken=50%(0,0)                                                                              420| 003AE8 ori        63650000   1     LR         gr5=gr27
  128| 003A8C cmplw      7C041840   2     CL4       cr0=gr4,gr3                                                                                                   420| 003AEC bl         4BFFC515   0     CALL       _Py_NegativeRefcount,3,(*)Cuchar",gr3,gr4,(*)_object",gr5,#ProcAlias",_Py_NegativeRefcount",fcr",gr1,cr[01
  239| 003A90 bc         408202D0   1     BF        CL.298,cr0,0x4/eq,taken=50%(0,0)                                                                              420| 003AF0 ori        60000000   1
  240| 003A94 lwz        80620024   2     L4A       gr3=.PyExc_StopAsyncIteration(gr2,0)                                                                            0| 003AF4 lwz        809C0000   1     L4A        gr4=_Py_RefTotal(gr28,0)
  240| 003A98 lwz        80630000   2     L4A       gr3=<s137:d0:l4>(gr3,0)                                                                                         0| 003AF8 b          4BFFFE9C   0     B          CL.940,-1
  240| 003A9C bl         4BFFC565   0     CALL      PyErr_SetNone,1,(*)_object",gr3,#ProcAlias",PyErr_SetNone",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",m   423|                                CL.941:
  240| 003AA0 ori        60000000   1                                                                                                                             425| 003AFC ori        63630000   1     LR         gr3=gr27
  244|                                CL.299:                                                                                                                     425| 003B00 bl         4BFFC501   0     CALL       _Py_Dealloc,1,(*)_object",gr3,#ProcAlias",_Py_Dealloc",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",
  251| 003AA4 ori        63A50000   1     LR        gr5=gr29                                                                                                      425| 003B04 ori        60000000   1
  251| 003AA8 addi       3BA00000   1     LI        gr29=0                                                                                                          0| 003B08 lwz        809C0000   1     L4A        gr4=_Py_RefTotal(gr28,0)
    0| 003AAC lwz        80620018   1     L4A       gr3=.+CONSTANT_AREA(gr2,0)                                                                                      0| 003B0C b          4BFFFE88   0     B          CL.940,-1
  415| 003AB0 lwz        80820004   1     L4A       gr4=._Py_RefTotal(gr2,0)                                                                                        0|                                CL.2071:
  408| 003AB4 addi       38631110   1     AI        gr3=gr3,4368                                                                                                  420| 003B10 addi       388001EC   1     LI         gr4=492
  417| 003AB8 lwz        80C50000   1     L4A       gr6=(*)_object._object.ob_refcnt(gr5,0)                                                                       420| 003B14 bl         4BFFC4ED   0     CALL       _Py_NegativeRefcount,3,(*)Cuchar",gr3,gr4,(*)_object",gr5,#ProcAlias",_Py_NegativeRefcount",fcr",gr1,cr[01
  415| 003ABC lwz        80E40000   1     L4A       gr7=<s117:d0:l4>(gr4,0)                                                                                       420| 003B18 ori        60000000   1
  417| 003AC0 addi       3806FFFF   1     AI        gr0=gr6,-1                                                                                                      0| 003B1C lwz        809C0000   1     L4A        gr4=_Py_RefTotal(gr28,0)
  417| 003AC4 stw        90050000   1     ST4A      (*)_object._object.ob_refcnt(gr5,0)=gr0                                                                         0| 003B20 b          4BFFFE44   0     B          CL.934,-1
  415| 003AC8 addi       38C7FFFF   1     AI        gr6=gr7,-1                                                                                                    423|                                CL.935:
  415| 003ACC stw        90C40000   1     ST4A      <s117:d0:l4>(gr4,0)=gr6                                                                                       425| 003B24 ori        60A30000   1     LR         gr3=gr5
  417| 003AD0 cmpwi      2C000000   1     C4        cr0=gr0,0                                                                                                     425| 003B28 bl         4BFFC4D9   0     CALL       _Py_Dealloc,1,(*)_object",gr3,#ProcAlias",_Py_Dealloc",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",
  417| 003AD4 bc         4182027C   1     BT        CL.924,cr0,0x4/eq,taken=40%(40,60)                                                                            425| 003B2C ori        60000000   1
  419| 003AD8 bc         41800268   1     BT        CL.2019,cr0,0x1/lt,taken=40%(40,60)                                                                             0| 003B30 lwz        809C0000   1     L4A        gr4=_Py_RefTotal(gr28,0)
    0|                                CL.1586:                                                                                                                      0| 003B34 b          4BFFFE30   0     B          CL.934,-1
    0| 003ADC cmpwi      2E1D0000   1     C4        cr4=gr29,0                                                                                                      0|                                CL.2058:
  252|                                CL.296:                                                                                                                     283| 003B38 ori        63A30000   1     LR         gr3=gr29
  274| 003AE0 bc         41920010   0     BT        CL.314,cr4,0x4/eq,taken=50%(0,0)                                                                                0| 003B3C lwz        83E100AC   1     L4A        gr31=#stack(gr1,172)
  274| 003AE4 lwz        801E0024   2     L4A       gr0=(*)_frame._frame.f_stacktop(gr30,36)                                                                        0| 003B40 lwz        83C100A8   1     L4A        gr30=#stack(gr1,168)
  274| 003AE8 cmpwi      2C000000   2     C4        cr0=gr0,0                                                                                                       0| 003B44 lwz        83010090   1     L4A        gr24=#stack(gr1,144)
  274| 003AEC bc         40820220   1     BF        CL.2007,cr0,0x4/eq,taken=50%(0,0)                                                                               0| 003B48 lwz        8361009C   1     L4A        gr27=#stack(gr1,156)
  274|                                CL.314:                                                                                                                       0| 003B4C lwz        800100B8   1     L4A        gr0=#stack(gr1,184)
  106| 003AF0 lwz        80BF0020   1     L4A       gr5=(*)_err_stackitem._err_stackitem.exc_type(gr31,32)                                                          0| 003B50 lwz        838100A0   1     L4A        gr28=#stack(gr1,160)
    0| 003AF4 lwz        83820004   1     L4A       gr28=._Py_RefTotal(gr2,0)                                                                                       0| 003B54 lwz        83A100A4   1     L4A        gr29=#stack(gr1,164)
  107| 003AF8 lwz        837F0024   1     L4A       gr27=(*)_err_stackitem._err_stackitem.exc_value(gr31,36)                                                      284| 003B58 lwz        818100B4   1     L4A        gr12=#stack(gr1,180)







Wed Apr 15 07:30:04 CDT 2020  Page 128


  108| 003AFC lwz        835F0028   1     L4A       gr26=(*)_err_stackitem._err_stackitem.exc_traceback(gr31,40)                                                  284| 003B5C addi       382100B0   1     AI         gr1=gr1,176
  109| 003B00 stw        931F0020   1     ST4A      (*)_err_stackitem._err_stackitem.exc_type(gr31,32)=gr24                                                         0| 003B60 mtspr      7C0803A6   1     LLR        lr=gr0
    0| 003B04 or.        7CA02B79   1     LR_R      gr0,cr0=gr5                                                                                                   284| 003B64 mtcrf      7D808120   1     MTCRF      cr4=gr12
    0| 003B08 lwz        83220018   1     L4A       gr25=.+CONSTANT_AREA(gr2,0)                                                                                   284| 003B68 bclr       4E800020   2     BA         lr
  110| 003B0C stw        931F0024   1     ST4A      (*)_err_stackitem._err_stackitem.exc_value(gr31,36)=gr24                                                        0|                                CL.2070:
  111| 003B10 stw        931F0028   1     ST4A      (*)_err_stackitem._err_stackitem.exc_traceback(gr31,40)=gr24                                                  420| 003B6C addi       388000FB   1     LI         gr4=251
    0| 003B14 lwz        80DC0000   1     L4A       gr6=<s117:d0:l4>(gr28,0)                                                                                      420| 003B70 bl         4BFFC491   0     CALL       _Py_NegativeRefcount,3,(*)Cuchar",gr3,gr4,(*)_object",gr5,#ProcAlias",_Py_NegativeRefcount",fcr",gr1,cr[01
  491| 003B18 bc         41820028   0     BT        CL.934,cr0,0x4/eq,taken=30%(30,70)                                                                            420| 003B74 ori        60000000   1
  408| 003B1C addi       38791124   2     AI        gr3=gr25,4388                                                                                                 423| 003B78 b          4BFFFD98   0     B          CL.314,-1
  417| 003B20 lwz        80850000   1     L4A       gr4=(*)_object._object.ob_refcnt(gr5,0)                                                                       423|                                CL.924:
  415| 003B24 addi       38C6FFFF   1     AI        gr6=gr6,-1                                                                                                    425| 003B7C ori        60A30000   1     LR         gr3=gr5
  415| 003B28 stw        90DC0000   1     ST4A      <s117:d0:l4>(gr28,0)=gr6                                                                                      425| 003B80 bl         4BFFC481   0     CALL       _Py_Dealloc,1,(*)_object",gr3,#ProcAlias",_Py_Dealloc",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",
  417| 003B2C addi       3804FFFF   1     AI        gr0=gr4,-1                                                                                                    425| 003B84 ori        60000000   1
  417| 003B30 stw        90050000   1     ST4A      (*)_object._object.ob_refcnt(gr5,0)=gr0                                                                       274| 003B88 b          4BFFFD88   0     B          CL.314
  417| 003B34 cmpwi      2C000000   1     C4        cr0=gr0,0                                                                                                     241|                                CL.298:
  417| 003B38 bc         418201C0   1     BT        CL.935,cr0,0x4/eq,taken=40%(40,60)                                                                            243| 003B8C lwz        8062002C   1     L4A        gr3=.PyExc_StopIteration(gr2,0)
  419| 003B3C bc         418001A8   1     BT        CL.2020,cr0,0x1/lt,taken=40%(40,60)                                                                           243| 003B90 lwz        80630000   2     L4A        gr3=PyExc_StopIteration(gr3,0)
  493|                                CL.934:                                                                                                                     243| 003B94 bl         4BFFC46D   0     CALL       PyErr_SetNone,1,(*)_object",gr3,#ProcAlias",PyErr_SetNone",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",
  491| 003B40 cmpwi      2C1B0000   1     C4        cr0=gr27,0                                                                                                    243| 003B98 ori        60000000   1
  491| 003B44 bc         41820028   1     BT        CL.940,cr0,0x4/eq,taken=30%(30,70)                                                                            245| 003B9C b          4BFFFD28   0     B          CL.299,-1
  415| 003B48 addi       38C6FFFF   2     AI        gr6=gr6,-1                                                                                                    245|                                CL.297:
  415| 003B4C stw        90DC0000   1     ST4A      <s117:d0:l4>(gr28,0)=gr6                                                                                      128| 003BA0 cmplw      7C041840   1     CL4        cr0=gr4,gr3
  408| 003B50 addi       38791124   1     AI        gr3=gr25,4388                                                                                                 248| 003BA4 bc         41820010   1     BT         CL.2069,cr0,0x4/eq,taken=40%(40,60)
  417| 003B54 lwz        809B0000   1     L4A       gr4=(*)_object._object.ob_refcnt(gr27,0)                                                                      249| 003BA8 ori        63A30000   2     LR         gr3=gr29
  417| 003B58 addi       3804FFFF   2     AI        gr0=gr4,-1                                                                                                    249| 003BAC bl         48002255   0     CALL       gr3=_PyGen_SetStopIterationValue,1,(*)_object",gr3,#ProcAlias",_PyGen_SetStopIterationValue",fcr",gr1,cr[0
  417| 003B5C stw        901B0000   1     ST4A      (*)_object._object.ob_refcnt(gr27,0)=gr0                                                                        0| 003BB0 b          4BFFFD14   0     B          CL.299,-1
  417| 003B60 cmpwi      2C000000   1     C4        cr0=gr0,0                                                                                                       0|                                CL.2069:
  417| 003B64 bc         4182016C   1     BT        CL.941,cr0,0x4/eq,taken=40%(40,60)                                                                            248| 003BB4 lwz        80820018   1     L4A        gr4=.+CONSTANT_AREA(gr2,0)
  419| 003B68 bc         41800150   1     BT        CL.2021,cr0,0x1/lt,taken=40%(40,60)                                                                           248| 003BB8 addi       38A000F8   1     LI         gr5=248
  493|                                CL.940:                                                                                                                     248| 003BBC addi       38641228   1     AI         gr3=gr4,4648
  491| 003B6C cmpwi      2C1A0000   1     C4        cr0=gr26,0                                                                                                    248| 003BC0 addi       38841110   1     AI         gr4=gr4,4368
  491| 003B70 bc         41820028   1     BT        CL.2009,cr0,0x4/eq,taken=30%(30,70)                                                                           248| 003BC4 bl         4BFFC43D   0     CALL       __assert,3,gr3-gr5,#ProcAlias",__assert",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",lr",fcr",xer",
  415| 003B74 addi       38C6FFFF   2     AI        gr6=gr6,-1                                                                                                    248| 003BC8 ori        60000000   1
  415| 003B78 stw        90DC0000   1     ST4A      <s117:d0:l4>(gr28,0)=gr6                                                                                      249| 003BCC ori        63A30000   1     LR         gr3=gr29
  408| 003B7C addi       38791124   1     AI        gr3=gr25,4388                                                                                                 249| 003BD0 bl         48002231   0     CALL       gr3=_PyGen_SetStopIterationValue,1,(*)_object",gr3,#ProcAlias",_PyGen_SetStopIterationValue",fcr",gr1,cr[0
  417| 003B80 lwz        809A0000   1     L4A       gr4=(*)_object._object.ob_refcnt(gr26,0)                                                                        0| 003BD4 b          4BFFFCF0   0     B          CL.299,-1
  417| 003B84 addi       3804FFFF   2     AI        gr0=gr4,-1                                                                                                    252|                                CL.1583:
  417| 003B88 stw        901A0000   1     ST4A      (*)_object._object.ob_refcnt(gr26,0)=gr0                                                                      253| 003BD8 lwz        8062002C   1     L4A        gr3=.PyExc_StopIteration(gr2,0)
  417| 003B8C cmpwi      2C000000   1     C4        cr0=gr0,0                                                                                                     253| 003BDC lwz        80630000   2     L4A        gr3=PyExc_StopIteration(gr3,0)
  417| 003B90 bc         41820110   1     BT        CL.947,cr0,0x4/eq,taken=40%(40,60)                                                                            253| 003BE0 bl         4BFFC421   0     CALL       gr3=PyErr_ExceptionMatches,1,(*)_object",gr3,#ProcAlias",PyErr_ExceptionMatches",fcr",gr1,cr[01567]",gr0",
  419| 003B94 bc         418000F0   1     BT        CL.2022,cr0,0x1/lt,taken=40%(40,60)                                                                           253| 003BE4 ori        60000000   1
    0|                                CL.2009:                                                                                                                    253| 003BE8 cmpwi      2C030000   1     C4         cr0=gr3,0
    0| 003B98 lwz        834100C8   1     L4A       gr26=#stack(gr1,200)                                                                                          253| 003BEC bc         41820060   1     BT         CL.308,cr0,0x4/eq,taken=50%(0,0)
  493|                                CL.946:                                                                                                                     255| 003BF0 lwz        800200D8   2     L4A        gr0=.PyCoro_Type(gr2,0)
  278| 003B9C lwz        809F0008   1     L4A       gr4=(*)aggr#3.gi_frame(gr31,8)                                                                                128| 003BF4 lwz        807F0004   1     L4A        gr3=(*)C_object._object.ob_type(gr31,4)
  408| 003BA0 addi       38791110   1     AI        gr3=gr25,4368                                                                                                 254| 003BF8 lwz        80820018   1     L4A        gr4=.+CONSTANT_AREA(gr2,0)
  415| 003BA4 addi       3806FFFF   1     AI        gr0=gr6,-1                                                                                                    128| 003BFC cmplw      7C030040   1     CL4        cr0=gr3,gr0
  417| 003BA8 lwz        80BE0000   1     L4A       gr5=(*)_object._object.ob_refcnt(gr30,0)                                                                      254| 003C00 addi       38A40D70   1     AI         gr5=gr4,3440
  279| 003BAC stw        931F0008   1     ST4A      (*)aggr#3.gi_frame(gr31,8)=gr24                                                                               255| 003C04 bc         40820020   0     BF         CL.309,cr0,0x4/eq,taken=50%(0,0)
  415| 003BB0 stw        901C0000   1     ST4A      <s117:d0:l4>(gr28,0)=gr0                                                                                      256| 003C08 addi       38A40D90   2     AI         gr5=gr4,3472
  417| 003BB4 addi       3805FFFF   1     AI        gr0=gr5,-1                                                                                                    260|                                CL.310:
  417| 003BB8 stw        901E0000   1     ST4A      (*)_object._object.ob_refcnt(gr30,0)=gr0                                                                      261| 003C0C lwz        8062001C   1     L4A        gr3=.PyExc_RuntimeError(gr2,0)
  278| 003BBC stw        93040030   1     ST4A      (*)_frame._frame.f_gen(gr4,48)=gr24                                                                           261| 003C10 addi       38841244   1     AI         gr4=gr4,4676
  417| 003BC0 cmpwi      2C000000   1     C4        cr0=gr0,0                                                                                                     261| 003C14 lwz        80630000   1     L4A        gr3=PyExc_RuntimeError(gr3,0)
  417| 003BC4 bc         4182007C   1     BT        CL.953,cr0,0x4/eq,taken=40%(40,60)                                                                            261| 003C18 bl         4BFFC3E9   0     CALL       gr3=_PyErr_FormatFromCause,3,(*)_object",gr3,gr4,(*)Cuchar",gr5,#ProcAlias",_PyErr_FormatFromCause",fcr",g
    0| 003BC8 lwz        83E100DC   2     L4A       gr31=#stack(gr1,220)                                                                                          261| 003C1C ori        60000000   1







Wed Apr 15 07:30:04 CDT 2020  Page 129


    0| 003BCC lwz        832100C4   1     L4A       gr25=#stack(gr1,196)                                                                                          263| 003C20 b          4BFFFCF0   0     B          CL.314,-1
    0| 003BD0 lwz        830100C0   1     L4A       gr24=#stack(gr1,192)                                                                                          257|                                CL.309:
  419| 003BD4 bc         41800030   0     BT        CL.2023,cr0,0x1/lt,taken=40%(40,60)                                                                           258| 003C24 lwz        800200E0   1     L4A        gr0=.PyAsyncGen_Type(gr2,0)
  283| 003BD8 ori        63A30000   2     LR        gr3=gr29                                                                                                      128| 003C28 cmplw      7C030040   2     CL4        cr0=gr3,gr0
    0| 003BDC lwz        83C100D8   1     L4A       gr30=#stack(gr1,216)                                                                                          258| 003C2C bc         4082FFE0   1     BF         CL.310,cr0,0x4/eq,taken=50%(0,0)
    0| 003BE0 lwz        836100CC   1     L4A       gr27=#stack(gr1,204)                                                                                          259| 003C30 addi       38A40DB0   1     AI         gr5=gr4,3504
    0| 003BE4 lwz        800100E8   1     L4A       gr0=#stack(gr1,232)                                                                                           261| 003C34 lwz        8062001C   1     L4A        gr3=.PyExc_RuntimeError(gr2,0)
    0| 003BE8 lwz        838100D0   1     L4A       gr28=#stack(gr1,208)                                                                                          261| 003C38 addi       38841244   1     AI         gr4=gr4,4676
    0| 003BEC lwz        83A100D4   1     L4A       gr29=#stack(gr1,212)                                                                                          261| 003C3C lwz        80630000   1     L4A        gr3=PyExc_RuntimeError(gr3,0)
  284| 003BF0 lwz        818100E4   1     L4A       gr12=#stack(gr1,228)                                                                                          261| 003C40 bl         4BFFC3C1   0     CALL       gr3=_PyErr_FormatFromCause,3,(*)_object",gr3,gr4,(*)Cuchar",gr5,#ProcAlias",_PyErr_FormatFromCause",fcr",g
  284| 003BF4 addi       382100E0   1     AI        gr1=gr1,224                                                                                                   261| 003C44 ori        60000000   1
    0| 003BF8 mtspr      7C0803A6   1     LLR       lr=gr0                                                                                                        263| 003C48 b          4BFFFCC8   0     B          CL.314,-1
  284| 003BFC mtcrf      7D808120   1     MTCRF     cr4=gr12                                                                                                      263|                                CL.308:
  284| 003C00 bclr       4E800020   2     BA        lr                                                                                                            264| 003C4C lwz        800200E0   1     L4A        gr0=.PyAsyncGen_Type(gr2,0)
    0|                                CL.2023:                                                                                                                    128| 003C50 lwz        807F0004   1     L4A        gr3=(*)C_object._object.ob_type(gr31,4)
  420| 003C04 addi       38800118   1     LI        gr4=280                                                                                                       128| 003C54 cmplw      7C030040   2     CL4        cr0=gr3,gr0
  420| 003C08 ori        63C50000   1     LR        gr5=gr30                                                                                                      264| 003C58 bc         4082FCA4   1     BF         CL.1584,cr0,0x4/eq,taken=60%(60,40)
  420| 003C0C bl         4BFFC3F5   0     CALL      _Py_NegativeRefcount,3,(*)Cuchar",gr3,gr4,(*)_object",gr5,#ProcAlias",_Py_NegativeRefcount",fcr",gr1,cr[015   265| 003C5C lwz        80620024   1     L4A        gr3=.PyExc_StopAsyncIteration(gr2,0)
  420| 003C10 ori        60000000   1                                                                                                                             265| 003C60 lwz        80630000   2     L4A        gr3=PyExc_StopAsyncIteration(gr3,0)
  283| 003C14 ori        63A30000   1     LR        gr3=gr29                                                                                                      265| 003C64 bl         4BFFC39D   0     CALL       gr3=PyErr_ExceptionMatches,1,(*)_object",gr3,#ProcAlias",PyErr_ExceptionMatches",fcr",gr1,cr[01567]",gr0",
    0| 003C18 lwz        83C100D8   1     L4A       gr30=#stack(gr1,216)                                                                                          265| 003C68 ori        60000000   1
    0| 003C1C lwz        836100CC   1     L4A       gr27=#stack(gr1,204)                                                                                          265| 003C6C cmpwi      2C030000   1     C4         cr0=gr3,0
    0| 003C20 lwz        800100E8   1     L4A       gr0=#stack(gr1,232)                                                                                           265| 003C70 bc         4182FC8C   1     BT         CL.1584,cr0,0x4/eq,taken=60%(60,40)
    0| 003C24 lwz        838100D0   1     L4A       gr28=#stack(gr1,208)                                                                                          270| 003C74 lwz        80A20018   2     L4A        gr5=.+CONSTANT_AREA(gr2,0)
    0| 003C28 lwz        83A100D4   1     L4A       gr29=#stack(gr1,212)                                                                                          271| 003C78 lwz        8062001C   1     L4A        gr3=.PyExc_RuntimeError(gr2,0)
  284| 003C2C lwz        818100E4   1     L4A       gr12=#stack(gr1,228)                                                                                          271| 003C7C addi       38851244   1     AI         gr4=gr5,4676
  284| 003C30 addi       382100E0   1     AI        gr1=gr1,224                                                                                                   270| 003C80 addi       38A50DD8   1     AI         gr5=gr5,3544
    0| 003C34 mtspr      7C0803A6   1     LLR       lr=gr0                                                                                                        271| 003C84 lwz        80630000   1     L4A        gr3=PyExc_RuntimeError(gr3,0)
  284| 003C38 mtcrf      7D808120   1     MTCRF     cr4=gr12                                                                                                      271| 003C88 bl         4BFFC379   0     CALL       gr3=_PyErr_FormatFromCause,3,(*)_object",gr3,gr4,(*)Cuchar",gr5,#ProcAlias",_PyErr_FormatFromCause",fcr",g
  284| 003C3C bclr       4E800020   2     BA        lr                                                                                                            271| 003C8C ori        60000000   1
  423|                                CL.953:                                                                                                                       0| 003C90 b          4BFFFC80   0     B          CL.314
  425| 003C40 ori        63C30000   1     LR        gr3=gr30                                                                                                        0|                                CL.2068:
    0| 003C44 lwz        83E100DC   1     L4A       gr31=#stack(gr1,220)                                                                                          420| 003C94 addi       388000E8   1     LI         gr4=232
    0| 003C48 lwz        832100C4   1     L4A       gr25=#stack(gr1,196)                                                                                          420| 003C98 bl         4BFFC369   0     CALL       _Py_NegativeRefcount,3,(*)Cuchar",gr3,gr4,(*)_object",gr5,#ProcAlias",_Py_NegativeRefcount",fcr",gr1,cr[01
    0| 003C4C lwz        830100C0   1     L4A       gr24=#stack(gr1,192)                                                                                          420| 003C9C ori        60000000   1
  425| 003C50 bl         4BFFC3B1   0     CALL      _Py_Dealloc,1,(*)_object",gr3,#ProcAlias",_Py_Dealloc",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",l   423| 003CA0 b          4BFFFBE4   0     B          CL.294,-1
  425| 003C54 ori        60000000   1                                                                                                                             423|                                CL.916:
  283| 003C58 ori        63A30000   1     LR        gr3=gr29                                                                                                      425| 003CA4 ori        60A30000   1     LR         gr3=gr5
    0| 003C5C lwz        83C100D8   1     L4A       gr30=#stack(gr1,216)                                                                                          425| 003CA8 bl         4BFFC359   0     CALL       _Py_Dealloc,1,(*)_object",gr3,#ProcAlias",_Py_Dealloc",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",
    0| 003C60 lwz        836100CC   1     L4A       gr27=#stack(gr1,204)                                                                                          425| 003CAC ori        60000000   1
    0| 003C64 lwz        800100E8   1     L4A       gr0=#stack(gr1,232)                                                                                             0| 003CB0 b          4BFFFBD4   0     B          CL.294,-1
    0| 003C68 lwz        838100D0   1     L4A       gr28=#stack(gr1,208)                                                                                            0|                                CL.2067:
    0| 003C6C lwz        83A100D4   1     L4A       gr29=#stack(gr1,212)                                                                                          231| 003CB4 lwz        80820018   1     L4A        gr4=.+CONSTANT_AREA(gr2,0)
  284| 003C70 lwz        818100E4   1     L4A       gr12=#stack(gr1,228)                                                                                          231| 003CB8 addi       38A000E7   1     LI         gr5=231
  284| 003C74 addi       382100E0   1     AI        gr1=gr1,224                                                                                                   231| 003CBC addi       3864120C   1     AI         gr3=gr4,4620
    0| 003C78 mtspr      7C0803A6   1     LLR       lr=gr0                                                                                                        231| 003CC0 addi       38841110   1     AI         gr4=gr4,4368
  284| 003C7C mtcrf      7D808120   1     MTCRF     cr4=gr12                                                                                                      231| 003CC4 bl         4BFFC33D   0     CALL       __assert,3,gr3-gr5,#ProcAlias",__assert",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",lr",fcr",xer",
  284| 003C80 bclr       4E800020   2     BA        lr                                                                                                            231| 003CC8 ori        60000000   1
    0|                                CL.2022:                                                                                                                      0| 003CCC lwz        80BE000C   1     L4A        gr5=(*)_frame._frame.f_back(gr30,12)
  420| 003C84 addi       388001EC   1     LI        gr4=492                                                                                                         0| 003CD0 ori        60A00000   2     LR         gr0=gr5
  420| 003C88 ori        63450000   1     LR        gr5=gr26                                                                                                        0| 003CD4 b          4BFFFB74   0     B          CL.289,-1
  420| 003C8C bl         4BFFC375   0     CALL      _Py_NegativeRefcount,3,(*)Cuchar",gr3,gr4,(*)_object",gr5,#ProcAlias",_Py_NegativeRefcount",fcr",gr1,cr[015     0|                                CL.2066:
  420| 003C90 ori        60000000   1                                                                                                                             217| 003CD8 lwz        80820018   1     L4A        gr4=.+CONSTANT_AREA(gr2,0)
    0| 003C94 lwz        80DC0000   1     L4A       gr6=<s117:d0:l4>(gr28,0)                                                                                      217| 003CDC addi       38A000D9   1     LI         gr5=217
    0| 003C98 lwz        834100C8   1     L4A       gr26=#stack(gr1,200)                                                                                          217| 003CE0 addi       386411F8   1     AI         gr3=gr4,4600
  423| 003C9C b          4BFFFF00   0     B         CL.946,-1                                                                                                     217| 003CE4 addi       38841110   1     AI         gr4=gr4,4368







Wed Apr 15 07:30:04 CDT 2020  Page 130


  423|                                CL.947:                                                                                                                     217| 003CE8 bl         4BFFC319   0     CALL       __assert,3,gr3-gr5,#ProcAlias",__assert",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",lr",fcr",xer",
  425| 003CA0 ori        63430000   1     LR        gr3=gr26                                                                                                      217| 003CEC ori        60000000   1
  425| 003CA4 bl         4BFFC35D   0     CALL      _Py_Dealloc,1,(*)_object",gr3,#ProcAlias",_Py_Dealloc",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",l     0| 003CF0 lwz        807C000C   1     L4A        gr3=(*)_ts._ts.frame(gr28,12)
  425| 003CA8 ori        60000000   1                                                                                                                               0| 003CF4 b          4BFFFAE4   0     B          CL.287,-1
    0| 003CAC lwz        80DC0000   1     L4A       gr6=<s117:d0:l4>(gr28,0)                                                                                        0|                                CL.2065:
    0| 003CB0 lwz        834100C8   1     L4A       gr26=#stack(gr1,200)                                                                                          194| 003CF8 cmpwi      2C040000   1     C4         cr0=gr4,0
    0| 003CB4 b          4BFFFEE8   0     B         CL.946,-1                                                                                                     194| 003CFC bc         4182FAA8   1     BT         CL.279,cr0,0x4/eq,taken=50%(0,0)
    0|                                CL.2021:                                                                                                                    194| 003D00 lwz        80020008   2     L4A        gr0=._Py_NoneStruct(gr2,0)
  420| 003CB8 addi       388001EC   1     LI        gr4=492                                                                                                       194| 003D04 cmplw      7C040040   2     CL4        cr0=gr4,gr0
  420| 003CBC ori        63650000   1     LR        gr5=gr27                                                                                                      194| 003D08 bc         4182FA9C   1     BT         CL.279,cr0,0x4/eq,taken=50%(0,0)
  420| 003CC0 bl         4BFFC341   0     CALL      _Py_NegativeRefcount,3,(*)Cuchar",gr3,gr4,(*)_object",gr5,#ProcAlias",_Py_NegativeRefcount",fcr",gr1,cr[015   197| 003D0C lwz        800200D8   1     L4A        gr0=.PyCoro_Type(gr2,0)
  420| 003CC4 ori        60000000   1                                                                                                                             128| 003D10 lwz        80BF0004   1     L4A        gr5=(*)C_object._object.ob_type(gr31,4)
    0| 003CC8 lwz        80DC0000   1     L4A       gr6=<s117:d0:l4>(gr28,0)                                                                                        0| 003D14 lwz        83C100A8   1     L4A        gr30=#stack(gr1,168)
  423| 003CCC b          4BFFFEA0   0     B         CL.940,-1                                                                                                     195| 003D18 lwz        80620018   1     L4A        gr3=.+CONSTANT_AREA(gr2,0)
  423|                                CL.941:                                                                                                                       0| 003D1C lwz        83A100A4   1     L4A        gr29=#stack(gr1,164)
  425| 003CD0 ori        63630000   1     LR        gr3=gr27                                                                                                        0| 003D20 lwz        838100A0   1     L4A        gr28=#stack(gr1,160)
  425| 003CD4 bl         4BFFC32D   0     CALL      _Py_Dealloc,1,(*)_object",gr3,#ProcAlias",_Py_Dealloc",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",l   128| 003D24 cmplw      7C050040   1     CL4        cr0=gr5,gr0
  425| 003CD8 ori        60000000   1                                                                                                                               0| 003D28 lwz        8361009C   1     L4A        gr27=#stack(gr1,156)
    0| 003CDC lwz        80DC0000   1     L4A       gr6=<s117:d0:l4>(gr28,0)                                                                                      195| 003D2C addi       38830CFC   1     AI         gr4=gr3,3324
    0| 003CE0 b          4BFFFE8C   0     B         CL.940,-1                                                                                                     197| 003D30 bc         4082003C   0     BF         CL.280,cr0,0x4/eq,taken=50%(0,0)
    0|                                CL.2020:                                                                                                                    198| 003D34 lwz        80620020   2     L4A        gr3=.$STATIC(gr2,0)
  420| 003CE4 addi       388001EC   1     LI        gr4=492                                                                                                         0| 003D38 lwz        83E100AC   1     L4A        gr31=#stack(gr1,172)
  420| 003CE8 bl         4BFFC319   0     CALL      _Py_NegativeRefcount,3,(*)Cuchar",gr3,gr4,(*)_object",gr5,#ProcAlias",_Py_NegativeRefcount",fcr",gr1,cr[015   198| 003D3C lwz        80830000   1     L4A        gr4=NON_INIT_CORO_MSG(gr3,0)
  420| 003CEC ori        60000000   1                                                                                                                             203|                                CL.281:
    0| 003CF0 lwz        80DC0000   1     L4A       gr6=<s117:d0:l4>(gr28,0)                                                                                      204| 003D40 lwz        806200B4   1     L4A        gr3=.PyExc_TypeError(gr2,0)
  423| 003CF4 b          4BFFFE4C   0     B         CL.934,-1                                                                                                     204| 003D44 lwz        80630000   2     L4A        gr3=PyExc_TypeError(gr3,0)
  423|                                CL.935:                                                                                                                     204| 003D48 bl         4BFFC2B9   0     CALL       PyErr_SetString,2,(*)_object",gr3,(*)Cuchar",gr4,#ProcAlias",PyErr_SetString",fcr",gr1,cr[01567]",gr0",gr3
  425| 003CF8 ori        60A30000   1     LR        gr3=gr5                                                                                                       204| 003D4C ori        60000000   1
  425| 003CFC bl         4BFFC305   0     CALL      _Py_Dealloc,1,(*)_object",gr3,#ProcAlias",_Py_Dealloc",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",l   205| 003D50 addi       38600000   1     LI         gr3=0
  425| 003D00 ori        60000000   1                                                                                                                               0| 003D54 lwz        800100B8   1     L4A        gr0=#stack(gr1,184)
    0| 003D04 lwz        80DC0000   1     L4A       gr6=<s117:d0:l4>(gr28,0)                                                                                      284| 003D58 lwz        818100B4   1     L4A        gr12=#stack(gr1,180)
    0| 003D08 b          4BFFFE38   0     B         CL.934,-1                                                                                                     284| 003D5C addi       382100B0   1     AI         gr1=gr1,176
    0|                                CL.2007:                                                                                                                      0| 003D60 mtspr      7C0803A6   1     LLR        lr=gr0
  283| 003D0C ori        63A30000   1     LR        gr3=gr29                                                                                                      284| 003D64 mtcrf      7D808120   1     MTCRF      cr4=gr12
    0| 003D10 lwz        83E100DC   1     L4A       gr31=#stack(gr1,220)                                                                                          284| 003D68 bclr       4E800020   2     BA         lr
    0| 003D14 lwz        83C100D8   1     L4A       gr30=#stack(gr1,216)                                                                                          199|                                CL.280:
    0| 003D18 lwz        830100C0   1     L4A       gr24=#stack(gr1,192)                                                                                          200| 003D6C lwz        800200E0   1     L4A        gr0=.PyAsyncGen_Type(gr2,0)
    0| 003D1C lwz        836100CC   1     L4A       gr27=#stack(gr1,204)                                                                                            0| 003D70 lwz        83E100AC   1     L4A        gr31=#stack(gr1,172)
    0| 003D20 lwz        800100E8   1     L4A       gr0=#stack(gr1,232)                                                                                           128| 003D74 cmplw      7C050040   1     CL4        cr0=gr5,gr0
    0| 003D24 lwz        838100D0   1     L4A       gr28=#stack(gr1,208)                                                                                          200| 003D78 bc         4082FFC8   1     BF         CL.281,cr0,0x4/eq,taken=50%(0,0)
    0| 003D28 lwz        83A100D4   1     L4A       gr29=#stack(gr1,212)                                                                                          201| 003D7C addi       38830D34   2     AI         gr4=gr3,3380
  284| 003D2C lwz        818100E4   1     L4A       gr12=#stack(gr1,228)                                                                                          204| 003D80 lwz        806200B4   1     L4A        gr3=.PyExc_TypeError(gr2,0)
  284| 003D30 addi       382100E0   1     AI        gr1=gr1,224                                                                                                   204| 003D84 lwz        80630000   2     L4A        gr3=PyExc_TypeError(gr3,0)
    0| 003D34 mtspr      7C0803A6   1     LLR       lr=gr0                                                                                                        204| 003D88 bl         4BFFC279   0     CALL       PyErr_SetString,2,(*)_object",gr3,(*)Cuchar",gr4,#ProcAlias",PyErr_SetString",fcr",gr1,cr[01567]",gr0",gr3
  284| 003D38 mtcrf      7D808120   1     MTCRF     cr4=gr12                                                                                                      204| 003D8C ori        60000000   1
  284| 003D3C bclr       4E800020   2     BA        lr                                                                                                            205| 003D90 addi       38600000   1     LI         gr3=0
    0|                                CL.2019:                                                                                                                      0| 003D94 lwz        800100B8   1     L4A        gr0=#stack(gr1,184)
  420| 003D40 addi       388000FB   1     LI        gr4=251                                                                                                       284| 003D98 lwz        818100B4   1     L4A        gr12=#stack(gr1,180)
  420| 003D44 bl         4BFFC2BD   0     CALL      _Py_NegativeRefcount,3,(*)Cuchar",gr3,gr4,(*)_object",gr5,#ProcAlias",_Py_NegativeRefcount",fcr",gr1,cr[015   284| 003D9C addi       382100B0   1     AI         gr1=gr1,176
  420| 003D48 ori        60000000   1                                                                                                                               0| 003DA0 mtspr      7C0803A6   1     LLR        lr=gr0
  274| 003D4C b          4BFFFDA4   0     B         CL.314                                                                                                        284| 003DA4 mtcrf      7D808120   1     MTCRF      cr4=gr12
  423|                                CL.924:                                                                                                                     284| 003DA8 bclr       4E800020   2     BA         lr
  425| 003D50 ori        60A30000   1     LR        gr3=gr5                                                                                                         0|                                CL.2061:
  425| 003D54 bl         4BFFC2AD   0     CALL      _Py_Dealloc,1,(*)_object",gr3,#ProcAlias",_Py_Dealloc",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",l   172| 003DAC lwz        800200D8   1     L4A        gr0=.PyCoro_Type(gr2,0)
  425| 003D58 ori        60000000   1                                                                                                                             128| 003DB0 lwz        807F0004   1     L4A        gr3=(*)C_object._object.ob_type(gr31,4)
  274| 003D5C b          4BFFFD94   0     B         CL.314                                                                                                          0| 003DB4 lwz        83C100A8   1     L4A        gr30=#stack(gr1,168)







Wed Apr 15 07:30:04 CDT 2020  Page 131


  241|                                CL.298:                                                                                                                       0| 003DB8 lwz        83A100A4   1     L4A        gr29=#stack(gr1,164)
  243| 003D60 lwz        8062002C   1     L4A       gr3=.PyExc_StopIteration(gr2,0)                                                                                 0| 003DBC lwz        838100A0   1     L4A        gr28=#stack(gr1,160)
  243| 003D64 lwz        80630000   2     L4A       gr3=<s139:d0:l4>(gr3,0)                                                                                         0| 003DC0 lwz        8361009C   1     L4A        gr27=#stack(gr1,156)
  243| 003D68 bl         4BFFC299   0     CALL      PyErr_SetNone,1,(*)_object",gr3,#ProcAlias",PyErr_SetNone",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",m   128| 003DC4 cmplw      7C030040   1     CL4        cr0=gr3,gr0
  243| 003D6C ori        60000000   1                                                                                                                             172| 003DC8 bc         408200B8   1     BF         CL.2064,cr0,0x4/eq,taken=50%(0,0)
  245| 003D70 b          4BFFFD34   0     B         CL.299,-1                                                                                                     172| 003DCC cmpwi      2C060000   2     C4         cr0=gr6,0
  245|                                CL.297:                                                                                                                       0| 003DD0 lwz        83E100AC   1     L4A        gr31=#stack(gr1,172)
  128| 003D74 cmplw      7C041840   1     CL4       cr0=gr4,gr3                                                                                                   172| 003DD4 bc         41820078   0     BT         CL.2075,cr0,0x4/eq,taken=40%(40,60)
  248| 003D78 bc         41820010   1     BT        CL.2018,cr0,0x4/eq,taken=40%(40,60)                                                                           179|                                CL.273:
  249| 003D7C ori        63A30000   2     LR        gr3=gr29                                                                                                      180| 003DD8 cmpwi      2C040000   1     C4         cr0=gr4,0
  249| 003D80 bl         48002061   0     CALL      gr3=_PyGen_SetStopIterationValue,1,(*)_object",gr3,#ProcAlias",_PyGen_SetStopIterationValue",fcr",gr1,cr[01   180| 003DDC bc         41820030   1     BT         CL.274,cr0,0x4/eq,taken=50%(0,0)
    0| 003D84 b          4BFFFD20   0     B         CL.299,-1                                                                                                     180| 003DE0 cmpwi      2C050000   2     C4         cr0=gr5,0
    0|                                CL.2018:                                                                                                                    180| 003DE4 bc         40820028   1     BF         CL.274,cr0,0x4/eq,taken=50%(0,0)
  248| 003D88 lwz        80820018   1     L4A       gr4=.+CONSTANT_AREA(gr2,0)                                                                                    183| 003DE8 lwz        800200E0   2     L4A        gr0=.PyAsyncGen_Type(gr2,0)
  248| 003D8C addi       38A000F8   1     LI        gr5=248                                                                                                       128| 003DEC cmplw      7C030040   2     CL4        cr0=gr3,gr0
  248| 003D90 addi       38641228   1     AI        gr3=gr4,4648                                                                                                  183| 003DF0 bc         40820030   1     BF         CL.276,cr0,0x4/eq,taken=50%(0,0)
  248| 003D94 addi       38841110   1     AI        gr4=gr4,4368                                                                                                  184| 003DF4 lwz        80620024   1     L4A        gr3=.PyExc_StopAsyncIteration(gr2,0)
  248| 003D98 bl         4BFFC269   0     CALL      __assert,3,gr3-gr5,#ProcAlias",__assert",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",lr",fcr",xer",f   184| 003DF8 lwz        80630000   2     L4A        gr3=PyExc_StopAsyncIteration(gr3,0)
  248| 003D9C ori        60000000   1                                                                                                                             184| 003DFC bl         4BFFC205   0     CALL       PyErr_SetNone,1,(*)_object",gr3,#ProcAlias",PyErr_SetNone",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",
  249| 003DA0 ori        63A30000   1     LR        gr3=gr29                                                                                                      184| 003E00 ori        60000000   1
  249| 003DA4 bl         4800203D   0     CALL      gr3=_PyGen_SetStopIterationValue,1,(*)_object",gr3,#ProcAlias",_PyGen_SetStopIterationValue",fcr",gr1,cr[01     0| 003E04 lwz        800100B8   1     L4A        gr0=#stack(gr1,184)
    0| 003DA8 b          4BFFFCFC   0     B         CL.299,-1                                                                                                       0| 003E08 mtspr      7C0803A6   2     LLR        lr=gr0
  252|                                CL.1585:                                                                                                                    189|                                CL.274:
  253| 003DAC lwz        8062002C   1     L4A       gr3=.PyExc_StopIteration(gr2,0)                                                                               284| 003E0C lwz        818100B4   1     L4A        gr12=#stack(gr1,180)
  253| 003DB0 lwz        80630000   2     L4A       gr3=<s139:d0:l4>(gr3,0)                                                                                       190| 003E10 addi       38600000   1     LI         gr3=0
  253| 003DB4 bl         4BFFC24D   0     CALL      gr3=PyErr_ExceptionMatches,1,(*)_object",gr3,#ProcAlias",PyErr_ExceptionMatches",fcr",gr1,cr[01567]",gr0",g   284| 003E14 addi       382100B0   1     AI         gr1=gr1,176
  253| 003DB8 ori        60000000   1                                                                                                                             284| 003E18 mtcrf      7D808120   1     MTCRF      cr4=gr12
  253| 003DBC cmpwi      2C030000   1     C4        cr0=gr3,0                                                                                                     284| 003E1C bclr       4E800020   0     BA         lr
  253| 003DC0 bc         41820060   1     BT        CL.308,cr0,0x4/eq,taken=50%(0,0)                                                                              185|                                CL.276:
  255| 003DC4 lwz        800200D8   2     L4A       gr0=.PyCoro_Type(gr2,0)                                                                                       187| 003E20 lwz        8062002C   1     L4A        gr3=.PyExc_StopIteration(gr2,0)
  128| 003DC8 lwz        807F0004   1     L4A       gr3=(*)C_object._object.ob_type(gr31,4)                                                                       187| 003E24 lwz        80630000   2     L4A        gr3=PyExc_StopIteration(gr3,0)
  254| 003DCC lwz        80820018   1     L4A       gr4=.+CONSTANT_AREA(gr2,0)                                                                                    187| 003E28 bl         4BFFC1D9   0     CALL       PyErr_SetNone,1,(*)_object",gr3,#ProcAlias",PyErr_SetNone",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",
  128| 003DD0 cmplw      7C030040   1     CL4       cr0=gr3,gr0                                                                                                   187| 003E2C ori        60000000   1
  254| 003DD4 addi       38A40D70   1     AI        gr5=gr4,3440                                                                                                  190| 003E30 addi       38600000   1     LI         gr3=0
  255| 003DD8 bc         40820020   0     BF        CL.309,cr0,0x4/eq,taken=50%(0,0)                                                                                0| 003E34 lwz        800100B8   1     L4A        gr0=#stack(gr1,184)
  256| 003DDC addi       38A40D90   2     AI        gr5=gr4,3472                                                                                                  284| 003E38 lwz        818100B4   1     L4A        gr12=#stack(gr1,180)
  260|                                CL.310:                                                                                                                     284| 003E3C addi       382100B0   1     AI         gr1=gr1,176
  261| 003DE0 lwz        8062001C   1     L4A       gr3=.PyExc_RuntimeError(gr2,0)                                                                                  0| 003E40 mtspr      7C0803A6   1     LLR        lr=gr0
  261| 003DE4 addi       38841244   1     AI        gr4=gr4,4676                                                                                                  284| 003E44 mtcrf      7D808120   1     MTCRF      cr4=gr12
  261| 003DE8 lwz        80630000   1     L4A       gr3=<s143:d0:l4>(gr3,0)                                                                                       284| 003E48 bclr       4E800020   2     BA         lr
  261| 003DEC bl         4BFFC215   0     CALL      gr3=_PyErr_FormatFromCause,3,(*)_object",gr3,gr4,(*)Cuchar",gr5,#ProcAlias",_PyErr_FormatFromCause",fcr",gr     0|                                CL.2075:
  261| 003DF0 ori        60000000   1                                                                                                                             176| 003E4C lwz        8062001C   1     L4A        gr3=.PyExc_RuntimeError(gr2,0)
  263| 003DF4 b          4BFFFCFC   0     B         CL.314,-1                                                                                                     176| 003E50 lwz        80820018   1     L4A        gr4=.+CONSTANT_AREA(gr2,0)
  257|                                CL.309:                                                                                                                     176| 003E54 addi       388411D0   2     AI         gr4=gr4,4560
  258| 003DF8 lwz        800200E0   1     L4A       gr0=.PyAsyncGen_Type(gr2,0)                                                                                   176| 003E58 lwz        80630000   1     L4A        gr3=PyExc_RuntimeError(gr3,0)
  128| 003DFC cmplw      7C030040   2     CL4       cr0=gr3,gr0                                                                                                   176| 003E5C bl         4BFFC1A5   0     CALL       PyErr_SetString,2,(*)_object",gr3,gr4,#ProcAlias",PyErr_SetString",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0
  258| 003E00 bc         4082FFE0   1     BF        CL.310,cr0,0x4/eq,taken=50%(0,0)                                                                              176| 003E60 ori        60000000   1
  259| 003E04 addi       38A40DB0   1     AI        gr5=gr4,3504                                                                                                  190| 003E64 addi       38600000   1     LI         gr3=0
  261| 003E08 lwz        8062001C   1     L4A       gr3=.PyExc_RuntimeError(gr2,0)                                                                                  0| 003E68 lwz        800100B8   1     L4A        gr0=#stack(gr1,184)
  261| 003E0C addi       38841244   1     AI        gr4=gr4,4676                                                                                                  284| 003E6C lwz        818100B4   1     L4A        gr12=#stack(gr1,180)
  261| 003E10 lwz        80630000   1     L4A       gr3=<s143:d0:l4>(gr3,0)                                                                                       284| 003E70 addi       382100B0   1     AI         gr1=gr1,176
  261| 003E14 bl         4BFFC1ED   0     CALL      gr3=_PyErr_FormatFromCause,3,(*)_object",gr3,gr4,(*)Cuchar",gr5,#ProcAlias",_PyErr_FormatFromCause",fcr",gr     0| 003E74 mtspr      7C0803A6   1     LLR        lr=gr0
  261| 003E18 ori        60000000   1                                                                                                                             284| 003E78 mtcrf      7D808120   1     MTCRF      cr4=gr12
  263| 003E1C b          4BFFFCD4   0     B         CL.314,-1                                                                                                     284| 003E7C bclr       4E800020   2     BA         lr
  263|                                CL.308:                                                                                                                       0|                                CL.2064:
  264| 003E20 lwz        800200E0   1     L4A       gr0=.PyAsyncGen_Type(gr2,0)                                                                                     0| 003E80 lwz        83E100AC   1     L4A        gr31=#stack(gr1,172)







Wed Apr 15 07:30:04 CDT 2020  Page 132


  128| 003E24 lwz        807F0004   1     L4A       gr3=(*)C_object._object.ob_type(gr31,4)                                                                         0| 003E84 b          4BFFFF54   0     B          CL.273,-1
  128| 003E28 cmplw      7C030040   2     CL4       cr0=gr3,gr0                                                                                                      |               Tag Table
  264| 003E2C bc         4082FCB0   1     BF        CL.1586,cr0,0x4/eq,taken=60%(60,40)                                                                              | 003E88        00000000 00002043 80080400 00000000 00000808 000B6765
  265| 003E30 lwz        80620024   1     L4A       gr3=.PyExc_StopAsyncIteration(gr2,0)                                                                             | 003EA0        6E5F7365 6E645F65 78
  265| 003E34 lwz        80630000   2     L4A       gr3=<s137:d0:l4>(gr3,0)                                                                                          |               Instruction count          514
  265| 003E38 bl         4BFFC1C9   0     CALL      gr3=PyErr_ExceptionMatches,1,(*)_object",gr3,#ProcAlias",PyErr_ExceptionMatches",fcr",gr1,cr[01567]",gr0",g      |               Straight-line exec time    513
  265| 003E3C ori        60000000   1                                                                                                                            GPR's set/used:   ssus ssss ssss s---  ---- ---- --ss ssss
  265| 003E40 cmpwi      2C030000   1     C4        cr0=gr3,0                                                                                                    FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----
  265| 003E44 bc         4182FC98   1     BT        CL.1586,cr0,0x4/eq,taken=60%(60,40)                                                                          CCR's set/used:   ss-- -sss
  270| 003E48 lwz        80820018   2     L4A       gr4=.+CONSTANT_AREA(gr2,0)                                                                                       | 000000                             PDEF       gen_dealloc
  271| 003E4C lwz        8062001C   1     L4A       gr3=.PyExc_RuntimeError(gr2,0)                                                                                118|                                    PROC       gen,gr3
  270| 003E50 addi       38A40DD8   1     AI        gr5=gr4,3544                                                                                                    0| 003EC0 mfspr      7C0802A6   1     LFLR       gr0=lr
  271| 003E54 addi       38841244   1     AI        gr4=gr4,4676                                                                                                    0| 003EC4 stwu       9421FFB0   1     ST4U       gr1,#stack(gr1,-80)=gr1
  271| 003E58 lwz        80630000   1     L4A       gr3=<s143:d0:l4>(gr3,0)                                                                                         0| 003EC8 stw        90010058   1     ST4A       #stack(gr1,88)=gr0
  271| 003E5C bl         4BFFC1A5   0     CALL      gr3=_PyErr_FormatFromCause,3,(*)_object",gr3,gr4,(*)Cuchar",gr5,#ProcAlias",_PyErr_FormatFromCause",fcr",gr     0| 003ECC stw        93E1004C   1     ST4A       #stack(gr1,76)=gr31
  271| 003E60 ori        60000000   1                                                                                                                               0| 003ED0 ori        607F0000   1     LR         gr31=gr3
    0| 003E64 b          4BFFFC8C   0     B         CL.314                                                                                                          0| 003ED4 stw        93C10048   1     ST4A       #stack(gr1,72)=gr30
    0|                                CL.2017:                                                                                                                      0| 003ED8 stw        93A10044   1     ST4A       #stack(gr1,68)=gr29
  420| 003E68 addi       388000E8   1     LI        gr4=232                                                                                                         0| 003EDC stw        93810040   1     ST4A       #stack(gr1,64)=gr28
  420| 003E6C bl         4BFFC195   0     CALL      _Py_NegativeRefcount,3,(*)Cuchar",gr3,gr4,(*)_object",gr5,#ProcAlias",_Py_NegativeRefcount",fcr",gr1,cr[015     0| 003EE0 stw        9361003C   1     ST4A       #stack(gr1,60)=gr27
  420| 003E70 ori        60000000   1                                                                                                                               0| 003EE4 lwz        83C20018   1     L4A        gr30=.+CONSTANT_AREA(gr2,0)
  423| 003E74 b          4BFFFBF0   0     B         CL.294,-1                                                                                                      64| 003EE8 lwz        8003FFF8   1     L4A        gr0=(*)_object%##2(gr3,-8)
  423|                                CL.916:                                                                                                                       0| 003EEC stw        93410038   1     ST4A       #stack(gr1,56)=gr26
  425| 003E78 ori        60A30000   1     LR        gr3=gr5                                                                                                        64| 003EF0 cmpwi      2C000000   1     C4         cr0=gr0,0
  425| 003E7C bl         4BFFC185   0     CALL      _Py_Dealloc,1,(*)_object",gr3,#ProcAlias",_Py_Dealloc",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",l    64| 003EF4 bc         41820568   1     BT         CL.2192,cr0,0x4/eq,taken=10%(10,90)
  425| 003E80 ori        60000000   1                                                                                                                              69| 003EF8 lwz        80C3FFFC   2     L4A        gr6=(*)aggr#2._gc_prev(gr3,-4)
    0| 003E84 b          4BFFFBE0   0     B         CL.294,-1                                                                                                      70| 003EFC lwz        8063FFF8   1     L4A        gr3=(*)aggr#2._gc_next(gr3,-8)
    0|                                CL.2016:                                                                                                                    124| 003F00 lwz        80BF0014   1     L4A        gr5=(*)aggr#3.gi_weakreflist(gr31,20)
  231| 003E88 lwz        80820018   1     L4A       gr4=.+CONSTANT_AREA(gr2,0)                                                                                     68| 003F04 addi       3BBFFFF8   1     AI         gr29=gr31,-8
  231| 003E8C addi       38A000E7   1     LI        gr5=231                                                                                                        73| 003F08 addi       3B400000   1     LI         gr26=0
  231| 003E90 addi       3864120C   1     AI        gr3=gr4,4620                                                                                                   69| 003F0C rlwinm     54C4003A   1     RN4        gr4=gr6,0,0xFFFFFFFC
  231| 003E94 addi       38841110   1     AI        gr4=gr4,4368                                                                                                  124| 003F10 cmpwi      2C050000   1     C4         cr0=gr5,0
  231| 003E98 bl         4BFFC169   0     CALL      __assert,3,gr3-gr5,#ProcAlias",__assert",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",lr",fcr",xer",f    72| 003F14 lwz        80A30004   1     L4A        gr5=(*)aggr#2._gc_prev(gr3,4)
  231| 003E9C ori        60000000   1                                                                                                                              71| 003F18 stw        90640000   1     ST4A       (*)aggr#2._gc_next(gr4,0)=gr3
    0| 003EA0 lwz        80BE000C   1     L4A       gr5=(*)_frame._frame.f_back(gr30,12)                                                                           73| 003F1C stw        935FFFF8   1     ST4A       (*)aggr#2._gc_next(gr31,-8)=gr26
    0| 003EA4 ori        60A00000   2     LR        gr0=gr5                                                                                                        72| 003F20 rlwimi     50C5003A   1     RI4        gr5=gr6,0,gr5,0xFFFFFFFC
    0| 003EA8 b          4BFFFB80   0     B         CL.289,-1                                                                                                      72| 003F24 stw        90A30004   1     ST4A       (*)aggr#2._gc_prev(gr3,4)=gr5
    0|                                CL.2015:                                                                                                                     74| 003F28 lwz        807FFFFC   1     L4A        gr3=(*)aggr#2._gc_prev(gr31,-4)
  217| 003EAC lwz        80820018   1     L4A       gr4=.+CONSTANT_AREA(gr2,0)                                                                                     74| 003F2C rlwinm     546407FE   2     RN4        gr4=gr3,0,0x1
  217| 003EB0 addi       38A000D9   1     LI        gr5=217                                                                                                        74| 003F30 stw        909FFFFC   1     ST4A       (*)aggr#2._gc_prev(gr31,-4)=gr4
  217| 003EB4 addi       386411F8   1     AI        gr3=gr4,4600                                                                                                  124| 003F34 bc         40820514   0     BF         CL.2193,cr0,0x4/eq,taken=40%(40,60)
  217| 003EB8 addi       38841110   1     AI        gr4=gr4,4368                                                                                                  125|                                CL.317:
  217| 003EBC bl         4BFFC145   0     CALL      __assert,3,gr3-gr5,#ProcAlias",__assert",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",lr",fcr",xer",f    30| 003F38 cmpwi      2C000000   1     C4         cr0=gr0,0
  217| 003EC0 ori        60000000   1                                                                                                                              30| 003F3C bc         408204E8   1     BF         CL.2194,cr0,0x4/eq,taken=10%(10,90)
    0| 003EC4 lwz        807C000C   1     L4A       gr3=(*)_ts._ts.frame(gr28,12)                                                                                  35| 003F40 lwz        807FFFFC   2     L4A        gr3=(*)aggr#2._gc_prev(gr31,-4)
    0| 003EC8 b          4BFFFAF0   0     B         CL.287,-1                                                                                                      35| 003F44 andi.      70600002   2     RN4_R      gr0,cr0=gr3,0,0x2
    0|                                CL.2014:                                                                                                                     35| 003F48 bc         408204B8   1     BF         CL.2195,cr0,0x4/eq,taken=10%(10,90)
  194| 003ECC cmpwi      2C040000   1     C4        cr0=gr4,0                                                                                                      67| 003F4C lwz        808200A4   1     L4A        gr4=._PyRuntime(gr2,0)
  194| 003ED0 bc         4182FAB4   1     BT        CL.279,cr0,0x4/eq,taken=50%(0,0)                                                                               54| 003F50 lwz        808401A0   2     L4A        gr4=(*)pyruntimestate._Py_atomic_address._value(gr4,416)
  194| 003ED4 lwz        80020008   2     L4A       gr0=._Py_NoneStruct(gr2,0)                                                                                     41| 003F54 lwz        80840008   2     L4A        gr4=(*)_ts._ts.interp(gr4,8)
  194| 003ED8 cmplw      7C040040   2     CL4       cr0=gr4,gr0                                                                                                    41| 003F58 lwz        83840188   2     L4A        gr28=(*)_is._gc_runtime_state.generation0(gr4,392)
  194| 003EDC bc         4182FAA8   1     BT        CL.279,cr0,0x4/eq,taken=50%(0,0)                                                                               42| 003F5C lwz        837C0004   2     L4A        gr27=(*)aggr#2._gc_prev(gr28,4)
  197| 003EE0 lwz        800200D8   1     L4A       gr0=.PyCoro_Type(gr2,0)                                                                                        44| 003F60 andi.      73600003   2     RN4_R      gr0,cr0=gr27,0,0xFFFFFFFF00000003
  128| 003EE4 lwz        80BF0004   1     L4A       gr5=(*)C_object._object.ob_type(gr31,4)                                                                        43| 003F64 stw        93BB0000   1     ST4A       (*)aggr#2._gc_next(gr27,0)=gr29
    0| 003EE8 lwz        83C100D8   1     L4A       gr30=#stack(gr1,216)                                                                                           44| 003F68 bc         4082047C   0     BF         CL.2196,cr0,0x4/eq,taken=40%(40,60)
  195| 003EEC lwz        80620018   1     L4A       gr3=.+CONSTANT_AREA(gr2,0)                                                                                     44|                                CL.1168:







Wed Apr 15 07:30:04 CDT 2020  Page 133


    0| 003EF0 lwz        83A100D4   1     L4A       gr29=#stack(gr1,212)                                                                                           44| 003F6C rlwinm     546007BE   1     RN4        gr0=gr3,0,0x3
    0| 003EF4 lwz        838100D0   1     L4A       gr28=#stack(gr1,208)                                                                                           45| 003F70 stw        939FFFF8   1     ST4A       (*)aggr#2._gc_next(gr31,-8)=gr28
  128| 003EF8 cmplw      7C050040   1     CL4       cr0=gr5,gr0                                                                                                   129| 003F74 ori        63E30000   1     LR         gr3=gr31
    0| 003EFC lwz        836100CC   1     L4A       gr27=#stack(gr1,204)                                                                                           44| 003F78 or         7C04DB78   1     O          gr4=gr0,gr27
  195| 003F00 addi       38830CFC   1     AI        gr4=gr3,3324                                                                                                   44| 003F7C stw        909FFFFC   1     ST4A       (*)aggr#2._gc_prev(gr31,-4)=gr4
  197| 003F04 bc         4082003C   0     BF        CL.280,cr0,0x4/eq,taken=50%(0,0)                                                                               46| 003F80 stw        93BC0004   1     ST4A       (*)aggr#2._gc_prev(gr28,4)=gr29
  198| 003F08 lwz        80620020   2     L4A       gr3=.$STATIC(gr2,0)                                                                                           129| 003F84 bl         4BFFC07D   0     CALL       gr3=PyObject_CallFinalizerFromDealloc,1,(*)_object",gr3,#ProcAlias",PyObject_CallFinalizerFromDealloc",fcr
    0| 003F0C lwz        83E100DC   1     L4A       gr31=#stack(gr1,220)                                                                                          129| 003F88 ori        60000000   1
  198| 003F10 lwz        80830000   1     L4A       gr4=NON_INIT_CORO_MSG(gr3,0)                                                                                  129| 003F8C cmpwi      2C030000   1     C4         cr0=gr3,0
  203|                                CL.281:                                                                                                                     129| 003F90 bc         4082042C   1     BF         CL.2190,cr0,0x4/eq,taken=30%(30,70)
  204| 003F14 lwz        806200B4   1     L4A       gr3=.PyExc_TypeError(gr2,0)                                                                                    64| 003F94 lwz        807FFFF8   2     L4A        gr3=(*)_object%##2(gr31,-8)
  204| 003F18 lwz        80630000   2     L4A       gr3=<s145:d0:l4>(gr3,0)                                                                                         0| 003F98 or.        7C601B79   2     LR_R       gr0,cr0=gr3
  204| 003F1C bl         4BFFC0E5   0     CALL      PyErr_SetString,2,(*)_object",gr3,(*)Cuchar",gr4,#ProcAlias",PyErr_SetString",fcr",gr1,cr[01567]",gr0",gr3"     0| 003F9C lwz        8361003C   1     L4A        gr27=#stack(gr1,60)
  204| 003F20 ori        60000000   1                                                                                                                              64| 003FA0 bc         418203F8   0     BT         CL.2197,cr0,0x4/eq,taken=10%(10,90)
  205| 003F24 addi       38600000   1     LI        gr3=0                                                                                                         133| 003FA4 lwz        80A200E0   1     L4A        gr5=.PyAsyncGen_Type(gr2,0)
    0| 003F28 lwz        800100E8   1     L4A       gr0=#stack(gr1,232)                                                                                           128| 003FA8 lwz        80FF0004   1     L4A        gr7=(*)C_object._object.ob_type(gr31,4)
  284| 003F2C lwz        818100E4   1     L4A       gr12=#stack(gr1,228)                                                                                           72| 003FAC lwz        80C30004   1     L4A        gr6=(*)aggr#2._gc_prev(gr3,4)
  284| 003F30 addi       382100E0   1     AI        gr1=gr1,224                                                                                                   128| 003FB0 cmplw      7C072840   1     CL4        cr0=gr7,gr5
    0| 003F34 mtspr      7C0803A6   1     LLR       lr=gr0                                                                                                         69| 003FB4 lwz        801FFFFC   1     L4A        gr0=(*)aggr#2._gc_prev(gr31,-4)
  284| 003F38 mtcrf      7D808120   1     MTCRF     cr4=gr12                                                                                                       69| 003FB8 rlwinm     5404003A   2     RN4        gr4=gr0,0,0xFFFFFFFC
  284| 003F3C bclr       4E800020   2     BA        lr                                                                                                             72| 003FBC rlwimi     5006003A   1     RI4        gr6=gr0,0,gr6,0xFFFFFFFC
  199|                                CL.280:                                                                                                                      72| 003FC0 stw        90C30004   1     ST4A       (*)aggr#2._gc_prev(gr3,4)=gr6
  200| 003F40 lwz        800200E0   1     L4A       gr0=.PyAsyncGen_Type(gr2,0)                                                                                    74| 003FC4 lwz        801FFFFC   1     L4A        gr0=(*)aggr#2._gc_prev(gr31,-4)
    0| 003F44 lwz        83E100DC   1     L4A       gr31=#stack(gr1,220)                                                                                           71| 003FC8 stw        90640000   1     ST4A       (*)aggr#2._gc_next(gr4,0)=gr3
  128| 003F48 cmplw      7C050040   1     CL4       cr0=gr5,gr0                                                                                                    73| 003FCC stw        935FFFF8   1     ST4A       (*)aggr#2._gc_next(gr31,-8)=gr26
  200| 003F4C bc         4082FFC8   1     BF        CL.281,cr0,0x4/eq,taken=50%(0,0)                                                                               74| 003FD0 rlwinm     540007FE   1     RN4        gr0=gr0,0,0x1
  201| 003F50 addi       38830D34   2     AI        gr4=gr3,3380                                                                                                   74| 003FD4 stw        901FFFFC   1     ST4A       (*)aggr#2._gc_prev(gr31,-4)=gr0
  204| 003F54 lwz        806200B4   1     L4A       gr3=.PyExc_TypeError(gr2,0)                                                                                   133| 003FD8 bc         4082003C   0     BF         CL.319,cr0,0x4/eq,taken=50%(0,0)
  204| 003F58 lwz        80630000   2     L4A       gr3=<s145:d0:l4>(gr3,0)                                                                                       137| 003FDC lwz        80BF0030   1     L4A        gr5=(*)aggr#4.ag_finalizer(gr31,48)
  204| 003F5C bl         4BFFC0A5   0     CALL      PyErr_SetString,2,(*)_object",gr3,(*)Cuchar",gr4,#ProcAlias",PyErr_SetString",fcr",gr1,cr[01567]",gr0",gr3"     0| 003FE0 or.        7CA02B79   2     LR_R       gr0,cr0=gr5
  204| 003F60 ori        60000000   1                                                                                                                             137| 003FE4 bc         41820030   1     BT         CL.319,cr0,0x4/eq,taken=50%(0,0)
  205| 003F64 addi       38600000   1     LI        gr3=0                                                                                                         137| 003FE8 stw        935F0030   1     ST4A       (*)aggr#4.ag_finalizer(gr31,48)=gr26
    0| 003F68 lwz        800100E8   1     L4A       gr0=#stack(gr1,232)                                                                                           415| 003FEC lwz        80820004   1     L4A        gr4=._Py_RefTotal(gr2,0)
  284| 003F6C lwz        818100E4   1     L4A       gr12=#stack(gr1,228)                                                                                          417| 003FF0 lwz        80650000   1     L4A        gr3=(*)_object._object.ob_refcnt(gr5,0)
  284| 003F70 addi       382100E0   1     AI        gr1=gr1,224                                                                                                   417| 003FF4 addi       3803FFFF   2     AI         gr0=gr3,-1
    0| 003F74 mtspr      7C0803A6   1     LLR       lr=gr0                                                                                                        415| 003FF8 lwz        80640000   1     L4A        gr3=_Py_RefTotal(gr4,0)
  284| 003F78 mtcrf      7D808120   1     MTCRF     cr4=gr12                                                                                                      417| 003FFC stw        90050000   1     ST4A       (*)_object._object.ob_refcnt(gr5,0)=gr0
  284| 003F7C bclr       4E800020   2     BA        lr                                                                                                            415| 004000 addi       3863FFFF   1     AI         gr3=gr3,-1
    0|                                CL.2010:                                                                                                                    415| 004004 stw        90640000   1     ST4A       _Py_RefTotal(gr4,0)=gr3
  172| 003F80 lwz        800200D8   1     L4A       gr0=.PyCoro_Type(gr2,0)                                                                                       417| 004008 cmpwi      2C000000   1     C4         cr0=gr0,0
  128| 003F84 lwz        807F0004   1     L4A       gr3=(*)C_object._object.ob_type(gr31,4)                                                                       417| 00400C bc         4182037C   1     BT         CL.1183,cr0,0x4/eq,taken=40%(40,60)
    0| 003F88 lwz        83C100D8   1     L4A       gr30=#stack(gr1,216)                                                                                          419| 004010 bc         41800364   1     BT         CL.2198,cr0,0x1/lt,taken=40%(40,60)
    0| 003F8C lwz        83A100D4   1     L4A       gr29=#stack(gr1,212)                                                                                          138|                                CL.319:
    0| 003F90 lwz        838100D0   1     L4A       gr28=#stack(gr1,208)                                                                                          139| 004014 lwz        80BF0008   1     L4A        gr5=(*)aggr#3.gi_frame(gr31,8)
    0| 003F94 lwz        836100CC   1     L4A       gr27=#stack(gr1,204)                                                                                            0| 004018 or.        7CA02B79   2     LR_R       gr0,cr0=gr5
  128| 003F98 cmplw      7C030040   1     CL4       cr0=gr3,gr0                                                                                                   139| 00401C bc         41820034   1     BT         CL.324,cr0,0x4/eq,taken=30%(30,70)
  172| 003F9C bc         408200B8   1     BF        CL.2013,cr0,0x4/eq,taken=50%(0,0)                                                                             141| 004020 stw        935F0008   1     ST4A       (*)aggr#3.gi_frame(gr31,8)=gr26
  172| 003FA0 cmpwi      2C060000   2     C4        cr0=gr6,0                                                                                                     415| 004024 lwz        80620004   1     L4A        gr3=._Py_RefTotal(gr2,0)
    0| 003FA4 lwz        83E100DC   1     L4A       gr31=#stack(gr1,220)                                                                                          140| 004028 stw        93450030   1     ST4A       (*)_frame._frame.f_gen(gr5,48)=gr26
  172| 003FA8 bc         41820078   0     BT        CL.2024,cr0,0x4/eq,taken=40%(40,60)                                                                           417| 00402C lwz        80850000   1     L4A        gr4=(*)_object._object.ob_refcnt(gr5,0)
  179|                                CL.273:                                                                                                                     415| 004030 lwz        80C30000   1     L4A        gr6=_Py_RefTotal(gr3,0)
  180| 003FAC cmpwi      2C040000   1     C4        cr0=gr4,0                                                                                                     417| 004034 addi       3804FFFF   1     AI         gr0=gr4,-1
  180| 003FB0 bc         41820030   1     BT        CL.274,cr0,0x4/eq,taken=50%(0,0)                                                                              417| 004038 stw        90050000   1     ST4A       (*)_object._object.ob_refcnt(gr5,0)=gr0
  180| 003FB4 cmpwi      2C050000   2     C4        cr0=gr5,0                                                                                                     415| 00403C addi       3886FFFF   1     AI         gr4=gr6,-1
  180| 003FB8 bc         40820028   1     BF        CL.274,cr0,0x4/eq,taken=50%(0,0)                                                                              415| 004040 stw        90830000   1     ST4A       _Py_RefTotal(gr3,0)=gr4
  183| 003FBC lwz        800200E0   2     L4A       gr0=.PyAsyncGen_Type(gr2,0)                                                                                   417| 004044 cmpwi      2C000000   1     C4         cr0=gr0,0







Wed Apr 15 07:30:04 CDT 2020  Page 134


  128| 003FC0 cmplw      7C030040   2     CL4       cr0=gr3,gr0                                                                                                   417| 004048 bc         4182031C   1     BT         CL.1187,cr0,0x4/eq,taken=40%(40,60)
  183| 003FC4 bc         40820030   1     BF        CL.276,cr0,0x4/eq,taken=50%(0,0)                                                                              419| 00404C bc         41800304   1     BT         CL.2199,cr0,0x1/lt,taken=40%(40,60)
  184| 003FC8 lwz        80620024   1     L4A       gr3=.PyExc_StopAsyncIteration(gr2,0)                                                                          142|                                CL.324:
  184| 003FCC lwz        80630000   2     L4A       gr3=<s137:d0:l4>(gr3,0)                                                                                       143| 004050 lwz        80DF0010   1     L4A        gr6=(*)aggr#3.gi_code(gr31,16)
  184| 003FD0 bl         4BFFC031   0     CALL      PyErr_SetNone,1,(*)_object",gr3,#ProcAlias",PyErr_SetNone",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",m     0| 004054 ori        60C30000   2     LR         gr3=gr6
  184| 003FD4 ori        60000000   1                                                                                                                             143| 004058 lwz        8006001C   1     L4A        gr0=(*)aggr#5.co_flags(gr6,28)
    0| 003FD8 lwz        800100E8   1     L4A       gr0=#stack(gr1,232)                                                                                           143| 00405C andi.      70000080   2     RN4_R      gr0,cr0=gr0,0,0x80
    0| 003FDC mtspr      7C0803A6   2     LLR       lr=gr0                                                                                                        143| 004060 bc         4182003C   1     BT         CL.329,cr0,0x4/eq,taken=50%(0,0)
  189|                                CL.274:                                                                                                                     144| 004064 lwz        80BF0030   1     L4A        gr5=(*)aggr#6.cr_origin(gr31,48)
  284| 003FE0 lwz        818100E4   1     L4A       gr12=#stack(gr1,228)                                                                                            0| 004068 or.        7CA02B79   2     LR_R       gr0,cr0=gr5
  190| 003FE4 addi       38600000   1     LI        gr3=0                                                                                                         144| 00406C bc         41820030   1     BT         CL.329,cr0,0x4/eq,taken=50%(0,0)
  284| 003FE8 addi       382100E0   1     AI        gr1=gr1,224                                                                                                   144| 004070 stw        935F0030   1     ST4A       (*)aggr#6.cr_origin(gr31,48)=gr26
  284| 003FEC mtcrf      7D808120   1     MTCRF     cr4=gr12                                                                                                      415| 004074 lwz        80E20004   1     L4A        gr7=._Py_RefTotal(gr2,0)
  284| 003FF0 bclr       4E800020   0     BA        lr                                                                                                            417| 004078 lwz        80850000   1     L4A        gr4=(*)_object._object.ob_refcnt(gr5,0)
  185|                                CL.276:                                                                                                                     417| 00407C addi       3804FFFF   2     AI         gr0=gr4,-1
  187| 003FF4 lwz        8062002C   1     L4A       gr3=.PyExc_StopIteration(gr2,0)                                                                               415| 004080 lwz        80870000   1     L4A        gr4=_Py_RefTotal(gr7,0)
  187| 003FF8 lwz        80630000   2     L4A       gr3=<s139:d0:l4>(gr3,0)                                                                                       417| 004084 stw        90050000   1     ST4A       (*)_object._object.ob_refcnt(gr5,0)=gr0
  187| 003FFC bl         4BFFC005   0     CALL      PyErr_SetNone,1,(*)_object",gr3,#ProcAlias",PyErr_SetNone",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",m   415| 004088 addi       3884FFFF   1     AI         gr4=gr4,-1
  187| 004000 ori        60000000   1                                                                                                                             415| 00408C stw        90870000   1     ST4A       _Py_RefTotal(gr7,0)=gr4
  190| 004004 addi       38600000   1     LI        gr3=0                                                                                                         417| 004090 cmpwi      2C000000   1     C4         cr0=gr0,0
    0| 004008 lwz        800100E8   1     L4A       gr0=#stack(gr1,232)                                                                                           417| 004094 bc         418202A4   1     BT         CL.1191,cr0,0x4/eq,taken=40%(40,60)
  284| 00400C lwz        818100E4   1     L4A       gr12=#stack(gr1,228)                                                                                          419| 004098 bc         41800284   1     BT         CL.2200,cr0,0x1/lt,taken=40%(40,60)
  284| 004010 addi       382100E0   1     AI        gr1=gr1,224                                                                                                   145|                                CL.329:
    0| 004014 mtspr      7C0803A6   1     LLR       lr=gr0                                                                                                        146| 00409C cmpwi      2C030000   1     C4         cr0=gr3,0
  284| 004018 mtcrf      7D808120   1     MTCRF     cr4=gr12                                                                                                      146| 0040A0 bc         41820030   1     BT         CL.338,cr0,0x4/eq,taken=50%(0,0)
  284| 00401C bclr       4E800020   2     BA        lr                                                                                                            415| 0040A4 lwz        80820004   2     L4A        gr4=._Py_RefTotal(gr2,0)
    0|                                CL.2024:                                                                                                                    417| 0040A8 lwz        80660000   1     L4A        gr3=(*)_object._object.ob_refcnt(gr6,0)
  176| 004020 lwz        8062001C   1     L4A       gr3=.PyExc_RuntimeError(gr2,0)                                                                                146| 0040AC stw        935F0010   1     ST4A       (*)aggr#3.gi_code(gr31,16)=gr26
  176| 004024 lwz        80820018   1     L4A       gr4=.+CONSTANT_AREA(gr2,0)                                                                                    417| 0040B0 addi       3803FFFF   1     AI         gr0=gr3,-1
  176| 004028 addi       388411D0   2     AI        gr4=gr4,4560                                                                                                  417| 0040B4 stw        90060000   1     ST4A       (*)_object._object.ob_refcnt(gr6,0)=gr0
  176| 00402C lwz        80630000   1     L4A       gr3=<s143:d0:l4>(gr3,0)                                                                                       415| 0040B8 lwz        80640000   1     L4A        gr3=_Py_RefTotal(gr4,0)
  176| 004030 bl         4BFFBFD1   0     CALL      PyErr_SetString,2,(*)_object",gr3,gr4,#ProcAlias",PyErr_SetString",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"   415| 0040BC addi       3863FFFF   2     AI         gr3=gr3,-1
  176| 004034 ori        60000000   1                                                                                                                             415| 0040C0 stw        90640000   1     ST4A       _Py_RefTotal(gr4,0)=gr3
  190| 004038 addi       38600000   1     LI        gr3=0                                                                                                         417| 0040C4 cmpwi      2C000000   1     C4         cr0=gr0,0
    0| 00403C lwz        800100E8   1     L4A       gr0=#stack(gr1,232)                                                                                           417| 0040C8 bc         41820244   1     BT         CL.1195,cr0,0x4/eq,taken=40%(40,60)
  284| 004040 lwz        818100E4   1     L4A       gr12=#stack(gr1,228)                                                                                          419| 0040CC bc         41800228   1     BT         CL.2201,cr0,0x1/lt,taken=40%(40,60)
  284| 004044 addi       382100E0   1     AI        gr1=gr1,224                                                                                                   146|                                CL.338:
    0| 004048 mtspr      7C0803A6   1     LLR       lr=gr0                                                                                                        147| 0040D0 lwz        80BF0018   1     L4A        gr5=(*)aggr#3.gi_name(gr31,24)
  284| 00404C mtcrf      7D808120   1     MTCRF     cr4=gr12                                                                                                        0| 0040D4 or.        7CA02B79   2     LR_R       gr0,cr0=gr5
  284| 004050 bclr       4E800020   2     BA        lr                                                                                                            147| 0040D8 bc         41820030   1     BT         CL.342,cr0,0x4/eq,taken=50%(0,0)
    0|                                CL.2013:                                                                                                                    147| 0040DC stw        935F0018   1     ST4A       (*)aggr#3.gi_name(gr31,24)=gr26
    0| 004054 lwz        83E100DC   1     L4A       gr31=#stack(gr1,220)                                                                                          415| 0040E0 lwz        80820004   1     L4A        gr4=._Py_RefTotal(gr2,0)
    0| 004058 b          4BFFFF54   0     B         CL.273,-1                                                                                                     417| 0040E4 lwz        80650000   1     L4A        gr3=(*)_object._object.ob_refcnt(gr5,0)
     |               Tag Table                                                                                                                                    417| 0040E8 addi       3803FFFF   2     AI         gr0=gr3,-1
     | 00405C        00000000 00002043 80080400 00000000 000007FC 000B6765                                                                                        415| 0040EC lwz        80640000   1     L4A        gr3=_Py_RefTotal(gr4,0)
     | 004074        6E5F7365 6E645F65 78                                                                                                                         417| 0040F0 stw        90050000   1     ST4A       (*)_object._object.ob_refcnt(gr5,0)=gr0
     |               Instruction count          511                                                                                                               415| 0040F4 addi       3863FFFF   1     AI         gr3=gr3,-1
     |               Straight-line exec time    513                                                                                                               415| 0040F8 stw        90640000   1     ST4A       _Py_RefTotal(gr4,0)=gr3
 GPR's set/used:   ssus ssss ssss s---  ---- ---- --ss ssss                                                                                                       417| 0040FC cmpwi      2C000000   1     C4         cr0=gr0,0
 FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----                                                                                                       417| 004100 bc         418201E4   1     BT         CL.1199,cr0,0x4/eq,taken=40%(40,60)
 CCR's set/used:   ss-- -sss                                                                                                                                      419| 004104 bc         418001CC   1     BT         CL.2202,cr0,0x1/lt,taken=40%(40,60)
     | 000000                             PDEF     gen_dealloc                                                                                                    147|                                CL.342:
  118|                                    PROC      gen,gr3                                                                                                       148| 004108 lwz        80BF001C   1     L4A        gr5=(*)aggr#3.gi_qualname(gr31,28)
    0| 004080 mfspr      7C0802A6   1     LFLR      gr0=lr                                                                                                          0| 00410C or.        7CA02B79   2     LR_R       gr0,cr0=gr5
    0| 004084 stw        90010008   2     ST4A      #stack(gr1,8)=gr0                                                                                             148| 004110 bc         41820030   1     BT         CL.346,cr0,0x4/eq,taken=50%(0,0)
    0| 004088 stw        93E1FFFC   1     ST4A      #stack(gr1,-4)=gr31                                                                                           148| 004114 stw        935F001C   1     ST4A       (*)aggr#3.gi_qualname(gr31,28)=gr26







Wed Apr 15 07:30:04 CDT 2020  Page 135


    0| 00408C ori        607F0000   1     LR        gr31=gr3                                                                                                      415| 004118 lwz        80820004   1     L4A        gr4=._Py_RefTotal(gr2,0)
    0| 004090 stw        93C1FFF8   1     ST4A      #stack(gr1,-8)=gr30                                                                                           417| 00411C lwz        80650000   1     L4A        gr3=(*)_object._object.ob_refcnt(gr5,0)
    0| 004094 stw        93A1FFF4   1     ST4A      #stack(gr1,-12)=gr29                                                                                          417| 004120 addi       3803FFFF   2     AI         gr0=gr3,-1
    0| 004098 stw        9381FFF0   1     ST4A      #stack(gr1,-16)=gr28                                                                                          415| 004124 lwz        80640000   1     L4A        gr3=_Py_RefTotal(gr4,0)
    0| 00409C stw        9361FFEC   1     ST4A      #stack(gr1,-20)=gr27                                                                                          417| 004128 stw        90050000   1     ST4A       (*)_object._object.ob_refcnt(gr5,0)=gr0
    0| 0040A0 lwz        83C20018   1     L4A       gr30=.+CONSTANT_AREA(gr2,0)                                                                                   415| 00412C addi       3863FFFF   1     AI         gr3=gr3,-1
   64| 0040A4 lwz        8003FFF8   1     L4A       gr0=(*)_object%##2(gr3,-8)                                                                                    415| 004130 stw        90640000   1     ST4A       _Py_RefTotal(gr4,0)=gr3
    0| 0040A8 stw        9341FFE8   1     ST4A      #stack(gr1,-24)=gr26                                                                                          417| 004134 cmpwi      2C000000   1     C4         cr0=gr0,0
    0| 0040AC stwu       9421FFB0   1     ST4U      gr1,#stack(gr1,-80)=gr1                                                                                       417| 004138 bc         41820188   1     BT         CL.1203,cr0,0x4/eq,taken=40%(40,60)
   64| 0040B0 cmpwi      2C000000   1     C4        cr0=gr0,0                                                                                                     419| 00413C bc         41800170   1     BT         CL.2203,cr0,0x1/lt,taken=40%(40,60)
   64| 0040B4 bc         41820560   1     BT        CL.2155,cr0,0x4/eq,taken=10%(10,90)                                                                           148|                                CL.346:
   69| 0040B8 lwz        80A3FFFC   1     L4A       gr5=(*)aggr#2._gc_prev(gr3,-4)                                                                                106| 004140 lwz        80BF0020   1     L4A        gr5=(*)_err_stackitem._err_stackitem.exc_type(gr31,32)
   68| 0040BC addi       3BBFFFF8   1     AI        gr29=gr31,-8                                                                                                  107| 004144 lwz        83BF0024   1     L4A        gr29=(*)_err_stackitem._err_stackitem.exc_value(gr31,36)
   70| 0040C0 lwz        8063FFF8   1     L4A       gr3=(*)aggr#2._gc_next(gr3,-8)                                                                                  0| 004148 or.        7CA02B79   1     LR_R       gr0,cr0=gr5
   73| 0040C4 addi       3B400000   1     LI        gr26=0                                                                                                        108| 00414C lwz        839F0028   1     L4A        gr28=(*)_err_stackitem._err_stackitem.exc_traceback(gr31,40)
  124| 0040C8 lwz        801F0014   1     L4A       gr0=(*)aggr#3.gi_weakreflist(gr31,20)                                                                         109| 004150 stw        935F0020   1     ST4A       (*)_err_stackitem._err_stackitem.exc_type(gr31,32)=gr26
   69| 0040CC rlwinm     54A4003A   1     RN4       gr4=gr5,0,0xFFFFFFFC                                                                                          110| 004154 stw        935F0024   1     ST4A       (*)_err_stackitem._err_stackitem.exc_value(gr31,36)=gr26
  124| 0040D0 cmpwi      2C000000   1     C4        cr0=gr0,0                                                                                                     111| 004158 stw        935F0028   1     ST4A       (*)_err_stackitem._err_stackitem.exc_traceback(gr31,40)=gr26
   71| 0040D4 stw        90640000   1     ST4A      (*)aggr#2._gc_next(gr4,0)=gr3                                                                                 491| 00415C bc         41820148   0     BT         CL.2189,cr0,0x4/eq,taken=30%(30,70)
   73| 0040D8 stw        935FFFF8   1     ST4A      (*)aggr#2._gc_next(gr31,-8)=gr26                                                                              408| 004160 addi       387E1124   2     AI         gr3=gr30,4388
   72| 0040DC lwz        80030004   1     L4A       gr0=(*)aggr#2._gc_prev(gr3,4)                                                                                 415| 004164 lwz        80C20004   1     L4A        gr6=._Py_RefTotal(gr2,0)
   72| 0040E0 rlwimi     50A0003A   2     RI4       gr0=gr5,0,gr0,0xFFFFFFFC                                                                                        0| 004168 lwz        83410038   1     L4A        gr26=#stack(gr1,56)
   72| 0040E4 stw        90030004   1     ST4A      (*)aggr#2._gc_prev(gr3,4)=gr0                                                                                 417| 00416C lwz        80850000   1     L4A        gr4=(*)_object._object.ob_refcnt(gr5,0)
   74| 0040E8 lwz        807FFFFC   1     L4A       gr3=(*)aggr#2._gc_prev(gr31,-4)                                                                               417| 004170 addi       3804FFFF   2     AI         gr0=gr4,-1
   74| 0040EC rlwinm     546007FE   2     RN4       gr0=gr3,0,0x1                                                                                                 417| 004174 stw        90050000   1     ST4A       (*)_object._object.ob_refcnt(gr5,0)=gr0
   74| 0040F0 stw        901FFFFC   1     ST4A      (*)aggr#2._gc_prev(gr31,-4)=gr0                                                                               417| 004178 cmpwi      2C040001   1     C4         cr0=gr4,1
  124| 0040F4 bc         40820510   0     BF        CL.2156,cr0,0x4/eq,taken=40%(40,60)                                                                           415| 00417C lwz        80860000   1     L4A        gr4=_Py_RefTotal(gr6,0)
  125|                                CL.317:                                                                                                                     415| 004180 addi       3884FFFF   2     AI         gr4=gr4,-1
   30| 0040F8 lwz        801FFFF8   1     L4A       gr0=(*)_object%##2(gr31,-8)                                                                                   415| 004184 stw        90860000   1     ST4A       _Py_RefTotal(gr6,0)=gr4
   30| 0040FC cmpwi      2C000000   2     C4        cr0=gr0,0                                                                                                     417| 004188 cmpwi      2C800000   1     C4         cr1=gr0,0
   30| 004100 bc         408204E0   1     BF        CL.2157,cr0,0x4/eq,taken=10%(10,90)                                                                           417| 00418C bc         41820108   0     BT         CL.1208,cr0,0x4/eq,taken=40%(40,60)
   35| 004104 lwz        807FFFFC   1     L4A       gr3=(*)aggr#2._gc_prev(gr31,-4)                                                                               419| 004190 bc         418400F4   1     BT         CL.2204,cr1,0x1/lt,taken=40%(40,60)
   35| 004108 andi.      70600002   2     RN4_R     gr0,cr0=gr3,0,0x2                                                                                             493|                                CL.1207:
   35| 00410C bc         408204B0   1     BF        CL.2158,cr0,0x4/eq,taken=10%(10,90)                                                                           491| 004194 cmpwi      2C1D0000   1     C4         cr0=gr29,0
   67| 004110 lwz        808200A4   1     L4A       gr4=._PyRuntime(gr2,0)                                                                                        491| 004198 bc         41820034   1     BT         CL.1213,cr0,0x4/eq,taken=30%(30,70)
   54| 004114 lwz        808401A0   2     L4A       gr4=<s149:d416:l4>(gr4,416)                                                                                   408| 00419C addi       387E1124   2     AI         gr3=gr30,4388
   41| 004118 lwz        80840008   2     L4A       gr4=(*)_ts._ts.interp(gr4,8)                                                                                  415| 0041A0 lwz        80A20004   1     L4A        gr5=._Py_RefTotal(gr2,0)
   41| 00411C lwz        83840188   2     L4A       gr28=(*)_is._gc_runtime_state.generation0(gr4,392)                                                            417| 0041A4 lwz        809D0000   1     L4A        gr4=(*)_object._object.ob_refcnt(gr29,0)
   42| 004120 lwz        837C0004   2     L4A       gr27=(*)aggr#2._gc_prev(gr28,4)                                                                               417| 0041A8 addi       3804FFFF   2     AI         gr0=gr4,-1
   44| 004124 andi.      73600003   2     RN4_R     gr0,cr0=gr27,0,0xFFFFFFFF00000003                                                                             417| 0041AC stw        901D0000   1     ST4A       (*)_object._object.ob_refcnt(gr29,0)=gr0
   43| 004128 stw        93BB0000   1     ST4A      (*)aggr#2._gc_next(gr27,0)=gr29                                                                               417| 0041B0 cmpwi      2C040001   1     C4         cr0=gr4,1
   44| 00412C bc         40820474   0     BF        CL.2159,cr0,0x4/eq,taken=40%(40,60)                                                                           415| 0041B4 lwz        80850000   1     L4A        gr4=_Py_RefTotal(gr5,0)
   44|                                CL.1168:                                                                                                                    415| 0041B8 addi       3884FFFF   2     AI         gr4=gr4,-1
   44| 004130 rlwinm     546007BE   1     RN4       gr0=gr3,0,0x3                                                                                                 415| 0041BC stw        90850000   1     ST4A       _Py_RefTotal(gr5,0)=gr4
   45| 004134 stw        939FFFF8   1     ST4A      (*)aggr#2._gc_next(gr31,-8)=gr28                                                                              417| 0041C0 cmpwi      2C800000   1     C4         cr1=gr0,0
  129| 004138 ori        63E30000   1     LR        gr3=gr31                                                                                                      417| 0041C4 bc         418200B0   0     BT         CL.1214,cr0,0x4/eq,taken=40%(40,60)
   44| 00413C or         7C04DB78   1     O         gr4=gr0,gr27                                                                                                  419| 0041C8 bc         41840098   1     BT         CL.2205,cr1,0x1/lt,taken=40%(40,60)
   44| 004140 stw        909FFFFC   1     ST4A      (*)aggr#2._gc_prev(gr31,-4)=gr4                                                                               493|                                CL.1213:
   46| 004144 stw        93BC0004   1     ST4A      (*)aggr#2._gc_prev(gr28,4)=gr29                                                                               491| 0041CC cmpwi      2C1C0000   1     C4         cr0=gr28,0
  129| 004148 bl         4BFFBEB9   0     CALL      gr3=PyObject_CallFinalizerFromDealloc,1,(*)_object",gr3,#ProcAlias",PyObject_CallFinalizerFromDealloc",fcr"   491| 0041D0 bc         41820088   1     BT         CL.2191,cr0,0x4/eq,taken=30%(30,70)
  129| 00414C ori        60000000   1                                                                                                                             408| 0041D4 addi       387E1124   2     AI         gr3=gr30,4388
  129| 004150 cmpwi      2C030000   1     C4        cr0=gr3,0                                                                                                     415| 0041D8 lwz        80A20004   1     L4A        gr5=._Py_RefTotal(gr2,0)
  129| 004154 bc         40820424   1     BF        CL.2153,cr0,0x4/eq,taken=30%(30,70)                                                                           417| 0041DC lwz        809C0000   1     L4A        gr4=(*)_object._object.ob_refcnt(gr28,0)
   64| 004158 lwz        801FFFF8   2     L4A       gr0=(*)_object%##2(gr31,-8)                                                                                   417| 0041E0 addi       3804FFFF   2     AI         gr0=gr4,-1
    0| 00415C lwz        8361003C   1     L4A       gr27=#stack(gr1,60)                                                                                           417| 0041E4 stw        901C0000   1     ST4A       (*)_object._object.ob_refcnt(gr28,0)=gr0
   64| 004160 cmpwi      2C000000   1     C4        cr0=gr0,0                                                                                                     417| 0041E8 cmpwi      2C040001   1     C4         cr0=gr4,1







Wed Apr 15 07:30:04 CDT 2020  Page 136


   64| 004164 bc         418203F0   1     BT        CL.2160,cr0,0x4/eq,taken=10%(10,90)                                                                           415| 0041EC lwz        80850000   1     L4A        gr4=_Py_RefTotal(gr5,0)
  133| 004168 lwz        800200E0   2     L4A       gr0=.PyAsyncGen_Type(gr2,0)                                                                                   415| 0041F0 addi       3884FFFF   2     AI         gr4=gr4,-1
  128| 00416C lwz        80BF0004   1     L4A       gr5=(*)C_object._object.ob_type(gr31,4)                                                                       415| 0041F4 stw        90850000   1     ST4A       _Py_RefTotal(gr5,0)=gr4
  128| 004170 cmplw      7C050040   2     CL4       cr0=gr5,gr0                                                                                                   417| 0041F8 cmpwi      2C800000   1     C4         cr1=gr0,0
   70| 004174 lwz        807FFFF8   1     L4A       gr3=(*)aggr#2._gc_next(gr31,-8)                                                                               417| 0041FC bc         41820048   0     BT         CL.1220,cr0,0x4/eq,taken=40%(40,60)
   69| 004178 lwz        80DFFFFC   1     L4A       gr6=(*)aggr#2._gc_prev(gr31,-4)                                                                                 0| 004200 lwz        83C10048   1     L4A        gr30=#stack(gr1,72)
   69| 00417C rlwinm     54C4003A   2     RN4       gr4=gr6,0,0xFFFFFFFC                                                                                          419| 004204 bc         4184002C   0     BT         CL.2206,cr1,0x1/lt,taken=40%(40,60)
   72| 004180 lwz        80030004   1     L4A       gr0=(*)aggr#2._gc_prev(gr3,4)                                                                                 493|                                CL.1219:
   72| 004184 rlwimi     50C0003A   2     RI4       gr0=gr6,0,gr0,0xFFFFFFFC                                                                                      150| 004208 ori        63E30000   1     LR         gr3=gr31
   71| 004188 stw        90640000   1     ST4A      (*)aggr#2._gc_next(gr4,0)=gr3                                                                                 150| 00420C bl         4BFFBDF5   0     CALL       PyObject_GC_Del,1,(*)void",gr3,#ProcAlias",PyObject_GC_Del",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13"
   72| 00418C stw        90030004   1     ST4A      (*)aggr#2._gc_prev(gr3,4)=gr0                                                                                 150| 004210 ori        60000000   1
   73| 004190 stw        935FFFF8   1     ST4A      (*)aggr#2._gc_next(gr31,-8)=gr26                                                                                0| 004214 lwz        83810040   1     L4A        gr28=#stack(gr1,64)
   74| 004194 lwz        807FFFFC   1     L4A       gr3=(*)aggr#2._gc_prev(gr31,-4)                                                                                 0| 004218 lwz        83A10044   1     L4A        gr29=#stack(gr1,68)
   74| 004198 rlwinm     546007FE   2     RN4       gr0=gr3,0,0x1                                                                                                   0| 00421C lwz        83E1004C   1     L4A        gr31=#stack(gr1,76)
   74| 00419C stw        901FFFFC   1     ST4A      (*)aggr#2._gc_prev(gr31,-4)=gr0                                                                                 0| 004220 lwz        80010058   1     L4A        gr0=#stack(gr1,88)
  133| 0041A0 bc         4082003C   0     BF        CL.319,cr0,0x4/eq,taken=50%(0,0)                                                                              151| 004224 addi       38210050   1     AI         gr1=gr1,80
  137| 0041A4 lwz        80BF0030   1     L4A       gr5=(*)aggr#4.ag_finalizer(gr31,48)                                                                             0| 004228 mtspr      7C0803A6   1     LLR        lr=gr0
    0| 0041A8 or.        7CA02B79   2     LR_R      gr0,cr0=gr5                                                                                                   151| 00422C bclr       4E800020   3     BA         lr
  137| 0041AC bc         41820030   1     BT        CL.319,cr0,0x4/eq,taken=50%(0,0)                                                                                0|                                CL.2206:
  137| 0041B0 stw        935F0030   1     ST4A      (*)aggr#4.ag_finalizer(gr31,48)=gr26                                                                          420| 004230 addi       388001EC   1     LI         gr4=492
  415| 0041B4 lwz        80820004   1     L4A       gr4=._Py_RefTotal(gr2,0)                                                                                      420| 004234 ori        63850000   1     LR         gr5=gr28
  417| 0041B8 lwz        80650000   1     L4A       gr3=(*)_object._object.ob_refcnt(gr5,0)                                                                       420| 004238 bl         4BFFBDC9   0     CALL       _Py_NegativeRefcount,3,(*)Cuchar",gr3,gr4,(*)_object",gr5,#ProcAlias",_Py_NegativeRefcount",fcr",gr1,cr[01
  417| 0041BC addi       3803FFFF   2     AI        gr0=gr3,-1                                                                                                    420| 00423C ori        60000000   1
  415| 0041C0 lwz        80640000   1     L4A       gr3=<s117:d0:l4>(gr4,0)                                                                                       423| 004240 b          4BFFFFC8   0     B          CL.1219,-1
  417| 0041C4 stw        90050000   1     ST4A      (*)_object._object.ob_refcnt(gr5,0)=gr0                                                                       423|                                CL.1220:
  415| 0041C8 addi       3863FFFF   1     AI        gr3=gr3,-1                                                                                                    425| 004244 ori        63830000   1     LR         gr3=gr28
  415| 0041CC stw        90640000   1     ST4A      <s117:d0:l4>(gr4,0)=gr3                                                                                         0| 004248 lwz        83C10048   1     L4A        gr30=#stack(gr1,72)
  417| 0041D0 cmpwi      2C000000   1     C4        cr0=gr0,0                                                                                                     425| 00424C bl         4BFFBDB5   0     CALL       _Py_Dealloc,1,(*)_object",gr3,#ProcAlias",_Py_Dealloc",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",
  417| 0041D4 bc         41820370   1     BT        CL.1183,cr0,0x4/eq,taken=40%(40,60)                                                                           425| 004250 ori        60000000   1
  419| 0041D8 bc         41800358   1     BT        CL.2161,cr0,0x1/lt,taken=40%(40,60)                                                                             0| 004254 b          4BFFFFB4   0     B          CL.1219,-1
  138|                                CL.319:                                                                                                                       0|                                CL.2191:
  139| 0041DC lwz        80BF0008   1     L4A       gr5=(*)aggr#3.gi_frame(gr31,8)                                                                                  0| 004258 lwz        83C10048   1     L4A        gr30=#stack(gr1,72)
    0| 0041E0 or.        7CA02B79   2     LR_R      gr0,cr0=gr5                                                                                                     0| 00425C b          4BFFFFAC   0     B          CL.1219,-1
  139| 0041E4 bc         41820034   1     BT        CL.324,cr0,0x4/eq,taken=30%(30,70)                                                                              0|                                CL.2205:
  141| 0041E8 stw        935F0008   1     ST4A      (*)aggr#3.gi_frame(gr31,8)=gr26                                                                               420| 004260 addi       388001EC   1     LI         gr4=492
  415| 0041EC lwz        80620004   1     L4A       gr3=._Py_RefTotal(gr2,0)                                                                                      420| 004264 ori        63A50000   1     LR         gr5=gr29
  140| 0041F0 stw        93450030   1     ST4A      (*)_frame._frame.f_gen(gr5,48)=gr26                                                                           420| 004268 bl         4BFFBD99   0     CALL       _Py_NegativeRefcount,3,(*)Cuchar",gr3,gr4,(*)_object",gr5,#ProcAlias",_Py_NegativeRefcount",fcr",gr1,cr[01
  417| 0041F4 lwz        80850000   1     L4A       gr4=(*)_object._object.ob_refcnt(gr5,0)                                                                       420| 00426C ori        60000000   1
  415| 0041F8 lwz        80C30000   1     L4A       gr6=<s117:d0:l4>(gr3,0)                                                                                       423| 004270 b          4BFFFF5C   0     B          CL.1213,-1
  417| 0041FC addi       3804FFFF   1     AI        gr0=gr4,-1                                                                                                    423|                                CL.1214:
  417| 004200 stw        90050000   1     ST4A      (*)_object._object.ob_refcnt(gr5,0)=gr0                                                                       425| 004274 ori        63A30000   1     LR         gr3=gr29
  415| 004204 addi       3886FFFF   1     AI        gr4=gr6,-1                                                                                                    425| 004278 bl         4BFFBD89   0     CALL       _Py_Dealloc,1,(*)_object",gr3,#ProcAlias",_Py_Dealloc",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",
  415| 004208 stw        90830000   1     ST4A      <s117:d0:l4>(gr3,0)=gr4                                                                                       425| 00427C ori        60000000   1
  417| 00420C cmpwi      2C000000   1     C4        cr0=gr0,0                                                                                                       0| 004280 b          4BFFFF4C   0     B          CL.1213,-1
  417| 004210 bc         41820310   1     BT        CL.1187,cr0,0x4/eq,taken=40%(40,60)                                                                             0|                                CL.2204:
  419| 004214 bc         418002F8   1     BT        CL.2162,cr0,0x1/lt,taken=40%(40,60)                                                                           420| 004284 addi       388001EC   1     LI         gr4=492
  142|                                CL.324:                                                                                                                     420| 004288 bl         4BFFBD79   0     CALL       _Py_NegativeRefcount,3,(*)Cuchar",gr3,gr4,(*)_object",gr5,#ProcAlias",_Py_NegativeRefcount",fcr",gr1,cr[01
  143| 004218 lwz        80DF0010   1     L4A       gr6=(*)aggr#3.gi_code(gr31,16)                                                                                420| 00428C ori        60000000   1
    0| 00421C ori        60C30000   2     LR        gr3=gr6                                                                                                       423| 004290 b          4BFFFF04   0     B          CL.1207,-1
  143| 004220 lwz        8006001C   1     L4A       gr0=(*)aggr#5.co_flags(gr6,28)                                                                                423|                                CL.1208:
  143| 004224 andi.      70000080   2     RN4_R     gr0,cr0=gr0,0,0x80                                                                                            425| 004294 ori        60A30000   1     LR         gr3=gr5
  143| 004228 bc         4182003C   1     BT        CL.329,cr0,0x4/eq,taken=50%(0,0)                                                                              425| 004298 bl         4BFFBD69   0     CALL       _Py_Dealloc,1,(*)_object",gr3,#ProcAlias",_Py_Dealloc",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",
  144| 00422C lwz        80BF0030   1     L4A       gr5=(*)aggr#6.cr_origin(gr31,48)                                                                              425| 00429C ori        60000000   1
    0| 004230 or.        7CA02B79   2     LR_R      gr0,cr0=gr5                                                                                                     0| 0042A0 b          4BFFFEF4   0     B          CL.1207,-1
  144| 004234 bc         41820030   1     BT        CL.329,cr0,0x4/eq,taken=50%(0,0)                                                                                0|                                CL.2189:
  144| 004238 stw        935F0030   1     ST4A      (*)aggr#6.cr_origin(gr31,48)=gr26                                                                               0| 0042A4 lwz        83410038   1     L4A        gr26=#stack(gr1,56)







Wed Apr 15 07:30:04 CDT 2020  Page 137


  415| 00423C lwz        80E20004   1     L4A       gr7=._Py_RefTotal(gr2,0)                                                                                        0| 0042A8 b          4BFFFEEC   0     B          CL.1207,-1
  417| 004240 lwz        80850000   1     L4A       gr4=(*)_object._object.ob_refcnt(gr5,0)                                                                         0|                                CL.2203:
  417| 004244 addi       3804FFFF   2     AI        gr0=gr4,-1                                                                                                    420| 0042AC addi       387E1110   1     AI         gr3=gr30,4368
  415| 004248 lwz        80870000   1     L4A       gr4=<s117:d0:l4>(gr7,0)                                                                                       420| 0042B0 addi       38800094   1     LI         gr4=148
  417| 00424C stw        90050000   1     ST4A      (*)_object._object.ob_refcnt(gr5,0)=gr0                                                                       420| 0042B4 bl         4BFFBD4D   0     CALL       _Py_NegativeRefcount,3,(*)Cuchar",gr3,gr4,(*)_object",gr5,#ProcAlias",_Py_NegativeRefcount",fcr",gr1,cr[01
  415| 004250 addi       3884FFFF   1     AI        gr4=gr4,-1                                                                                                    420| 0042B8 ori        60000000   1
  415| 004254 stw        90870000   1     ST4A      <s117:d0:l4>(gr7,0)=gr4                                                                                       423| 0042BC b          4BFFFE84   0     B          CL.346,-1
  417| 004258 cmpwi      2C000000   1     C4        cr0=gr0,0                                                                                                     423|                                CL.1203:
  417| 00425C bc         41820298   1     BT        CL.1191,cr0,0x4/eq,taken=40%(40,60)                                                                           425| 0042C0 ori        60A30000   1     LR         gr3=gr5
  419| 004260 bc         41800278   1     BT        CL.2163,cr0,0x1/lt,taken=40%(40,60)                                                                           425| 0042C4 bl         4BFFBD3D   0     CALL       _Py_Dealloc,1,(*)_object",gr3,#ProcAlias",_Py_Dealloc",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",
  145|                                CL.329:                                                                                                                     425| 0042C8 ori        60000000   1
  146| 004264 cmpwi      2C030000   1     C4        cr0=gr3,0                                                                                                       0| 0042CC b          4BFFFE74   0     B          CL.346,-1
  146| 004268 bc         41820030   1     BT        CL.338,cr0,0x4/eq,taken=50%(0,0)                                                                                0|                                CL.2202:
  415| 00426C lwz        80820004   2     L4A       gr4=._Py_RefTotal(gr2,0)                                                                                      420| 0042D0 addi       387E1110   1     AI         gr3=gr30,4368
  417| 004270 lwz        80660000   1     L4A       gr3=(*)_object._object.ob_refcnt(gr6,0)                                                                       420| 0042D4 addi       38800093   1     LI         gr4=147
  146| 004274 stw        935F0010   1     ST4A      (*)aggr#3.gi_code(gr31,16)=gr26                                                                               420| 0042D8 bl         4BFFBD29   0     CALL       _Py_NegativeRefcount,3,(*)Cuchar",gr3,gr4,(*)_object",gr5,#ProcAlias",_Py_NegativeRefcount",fcr",gr1,cr[01
  417| 004278 addi       3803FFFF   1     AI        gr0=gr3,-1                                                                                                    420| 0042DC ori        60000000   1
  417| 00427C stw        90060000   1     ST4A      (*)_object._object.ob_refcnt(gr6,0)=gr0                                                                       423| 0042E0 b          4BFFFE28   0     B          CL.342,-1
  415| 004280 lwz        80640000   1     L4A       gr3=<s117:d0:l4>(gr4,0)                                                                                       423|                                CL.1199:
  415| 004284 addi       3863FFFF   2     AI        gr3=gr3,-1                                                                                                    425| 0042E4 ori        60A30000   1     LR         gr3=gr5
  415| 004288 stw        90640000   1     ST4A      <s117:d0:l4>(gr4,0)=gr3                                                                                       425| 0042E8 bl         4BFFBD19   0     CALL       _Py_Dealloc,1,(*)_object",gr3,#ProcAlias",_Py_Dealloc",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",
  417| 00428C cmpwi      2C000000   1     C4        cr0=gr0,0                                                                                                     425| 0042EC ori        60000000   1
  417| 004290 bc         41820238   1     BT        CL.1195,cr0,0x4/eq,taken=40%(40,60)                                                                             0| 0042F0 b          4BFFFE18   0     B          CL.342,-1
  419| 004294 bc         4180021C   1     BT        CL.2164,cr0,0x1/lt,taken=40%(40,60)                                                                             0|                                CL.2201:
  146|                                CL.338:                                                                                                                     420| 0042F4 addi       387E1110   1     AI         gr3=gr30,4368
  147| 004298 lwz        80BF0018   1     L4A       gr5=(*)aggr#3.gi_name(gr31,24)                                                                                420| 0042F8 addi       38800092   1     LI         gr4=146
    0| 00429C or.        7CA02B79   2     LR_R      gr0,cr0=gr5                                                                                                   420| 0042FC ori        60C50000   1     LR         gr5=gr6
  147| 0042A0 bc         41820030   1     BT        CL.342,cr0,0x4/eq,taken=50%(0,0)                                                                              420| 004300 bl         4BFFBD01   0     CALL       _Py_NegativeRefcount,3,(*)Cuchar",gr3,gr4,(*)_object",gr5,#ProcAlias",_Py_NegativeRefcount",fcr",gr1,cr[01
  147| 0042A4 stw        935F0018   1     ST4A      (*)aggr#3.gi_name(gr31,24)=gr26                                                                               420| 004304 ori        60000000   1
  415| 0042A8 lwz        80820004   1     L4A       gr4=._Py_RefTotal(gr2,0)                                                                                      423| 004308 b          4BFFFDC8   0     B          CL.338,-1
  417| 0042AC lwz        80650000   1     L4A       gr3=(*)_object._object.ob_refcnt(gr5,0)                                                                       423|                                CL.1195:
  417| 0042B0 addi       3803FFFF   2     AI        gr0=gr3,-1                                                                                                    425| 00430C ori        60C30000   1     LR         gr3=gr6
  415| 0042B4 lwz        80640000   1     L4A       gr3=<s117:d0:l4>(gr4,0)                                                                                       425| 004310 bl         4BFFBCF1   0     CALL       _Py_Dealloc,1,(*)_object",gr3,#ProcAlias",_Py_Dealloc",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",
  417| 0042B8 stw        90050000   1     ST4A      (*)_object._object.ob_refcnt(gr5,0)=gr0                                                                       425| 004314 ori        60000000   1
  415| 0042BC addi       3863FFFF   1     AI        gr3=gr3,-1                                                                                                      0| 004318 b          4BFFFDB8   0     B          CL.338,-1
  415| 0042C0 stw        90640000   1     ST4A      <s117:d0:l4>(gr4,0)=gr3                                                                                         0|                                CL.2200:
  417| 0042C4 cmpwi      2C000000   1     C4        cr0=gr0,0                                                                                                     420| 00431C addi       387E1110   1     AI         gr3=gr30,4368
  417| 0042C8 bc         418201D8   1     BT        CL.1199,cr0,0x4/eq,taken=40%(40,60)                                                                           420| 004320 addi       38800090   1     LI         gr4=144
  419| 0042CC bc         418001C0   1     BT        CL.2165,cr0,0x1/lt,taken=40%(40,60)                                                                           420| 004324 bl         4BFFBCDD   0     CALL       _Py_NegativeRefcount,3,(*)Cuchar",gr3,gr4,(*)_object",gr5,#ProcAlias",_Py_NegativeRefcount",fcr",gr1,cr[01
  147|                                CL.342:                                                                                                                     420| 004328 ori        60000000   1
  148| 0042D0 lwz        80BF001C   1     L4A       gr5=(*)aggr#3.gi_qualname(gr31,28)                                                                              0| 00432C lwz        80DF0010   1     L4A        gr6=(*)aggr#3.gi_code(gr31,16)
    0| 0042D4 or.        7CA02B79   2     LR_R      gr0,cr0=gr5                                                                                                     0| 004330 ori        60C30000   2     LR         gr3=gr6
  148| 0042D8 bc         41820030   1     BT        CL.346,cr0,0x4/eq,taken=50%(0,0)                                                                              423| 004334 b          4BFFFD68   0     B          CL.329,-1
  148| 0042DC stw        935F001C   1     ST4A      (*)aggr#3.gi_qualname(gr31,28)=gr26                                                                           423|                                CL.1191:
  415| 0042E0 lwz        80820004   1     L4A       gr4=._Py_RefTotal(gr2,0)                                                                                      425| 004338 ori        60A30000   1     LR         gr3=gr5
  417| 0042E4 lwz        80650000   1     L4A       gr3=(*)_object._object.ob_refcnt(gr5,0)                                                                       425| 00433C bl         4BFFBCC5   0     CALL       _Py_Dealloc,1,(*)_object",gr3,#ProcAlias",_Py_Dealloc",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",
  417| 0042E8 addi       3803FFFF   2     AI        gr0=gr3,-1                                                                                                    425| 004340 ori        60000000   1
  415| 0042EC lwz        80640000   1     L4A       gr3=<s117:d0:l4>(gr4,0)                                                                                         0| 004344 lwz        80DF0010   1     L4A        gr6=(*)aggr#3.gi_code(gr31,16)
  417| 0042F0 stw        90050000   1     ST4A      (*)_object._object.ob_refcnt(gr5,0)=gr0                                                                         0| 004348 ori        60C30000   2     LR         gr3=gr6
  415| 0042F4 addi       3863FFFF   1     AI        gr3=gr3,-1                                                                                                      0| 00434C b          4BFFFD50   0     B          CL.329,-1
  415| 0042F8 stw        90640000   1     ST4A      <s117:d0:l4>(gr4,0)=gr3                                                                                         0|                                CL.2199:
  417| 0042FC cmpwi      2C000000   1     C4        cr0=gr0,0                                                                                                     420| 004350 addi       387E1110   1     AI         gr3=gr30,4368
  417| 004300 bc         4182017C   1     BT        CL.1203,cr0,0x4/eq,taken=40%(40,60)                                                                           420| 004354 addi       3880008D   1     LI         gr4=141
  419| 004304 bc         41800164   1     BT        CL.2166,cr0,0x1/lt,taken=40%(40,60)                                                                           420| 004358 bl         4BFFBCA9   0     CALL       _Py_NegativeRefcount,3,(*)Cuchar",gr3,gr4,(*)_object",gr5,#ProcAlias",_Py_NegativeRefcount",fcr",gr1,cr[01
  148|                                CL.346:                                                                                                                     420| 00435C ori        60000000   1
  106| 004308 lwz        80BF0020   1     L4A       gr5=(*)_err_stackitem._err_stackitem.exc_type(gr31,32)                                                        423| 004360 b          4BFFFCF0   0     B          CL.324,-1







Wed Apr 15 07:30:04 CDT 2020  Page 138


  107| 00430C lwz        83BF0024   1     L4A       gr29=(*)_err_stackitem._err_stackitem.exc_value(gr31,36)                                                      423|                                CL.1187:
  108| 004310 lwz        839F0028   1     L4A       gr28=(*)_err_stackitem._err_stackitem.exc_traceback(gr31,40)                                                  425| 004364 ori        60A30000   1     LR         gr3=gr5
  109| 004314 stw        935F0020   1     ST4A      (*)_err_stackitem._err_stackitem.exc_type(gr31,32)=gr26                                                       425| 004368 bl         4BFFBC99   0     CALL       _Py_Dealloc,1,(*)_object",gr3,#ProcAlias",_Py_Dealloc",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",
  110| 004318 stw        935F0024   1     ST4A      (*)_err_stackitem._err_stackitem.exc_value(gr31,36)=gr26                                                      425| 00436C ori        60000000   1
    0| 00431C or.        7CA02B79   1     LR_R      gr0,cr0=gr5                                                                                                     0| 004370 b          4BFFFCE0   0     B          CL.324,-1
  111| 004320 stw        935F0028   1     ST4A      (*)_err_stackitem._err_stackitem.exc_traceback(gr31,40)=gr26                                                    0|                                CL.2198:
  491| 004324 bc         4182013C   0     BT        CL.2152,cr0,0x4/eq,taken=30%(30,70)                                                                           420| 004374 addi       387E1110   1     AI         gr3=gr30,4368
  408| 004328 addi       387E1124   2     AI        gr3=gr30,4388                                                                                                 420| 004378 addi       38800089   1     LI         gr4=137
  415| 00432C lwz        80C20004   1     L4A       gr6=._Py_RefTotal(gr2,0)                                                                                      420| 00437C bl         4BFFBC85   0     CALL       _Py_NegativeRefcount,3,(*)Cuchar",gr3,gr4,(*)_object",gr5,#ProcAlias",_Py_NegativeRefcount",fcr",gr1,cr[01
    0| 004330 lwz        83410038   1     L4A       gr26=#stack(gr1,56)                                                                                           420| 004380 ori        60000000   1
  417| 004334 lwz        80850000   1     L4A       gr4=(*)_object._object.ob_refcnt(gr5,0)                                                                       423| 004384 b          4BFFFC90   0     B          CL.319,-1
  417| 004338 addi       3804FFFF   2     AI        gr0=gr4,-1                                                                                                    423|                                CL.1183:
  417| 00433C stw        90050000   1     ST4A      (*)_object._object.ob_refcnt(gr5,0)=gr0                                                                       425| 004388 ori        60A30000   1     LR         gr3=gr5
  415| 004340 lwz        80860000   1     L4A       gr4=<s117:d0:l4>(gr6,0)                                                                                       425| 00438C bl         4BFFBC75   0     CALL       _Py_Dealloc,1,(*)_object",gr3,#ProcAlias",_Py_Dealloc",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",
  415| 004344 addi       3884FFFF   2     AI        gr4=gr4,-1                                                                                                    425| 004390 ori        60000000   1
  415| 004348 stw        90860000   1     ST4A      <s117:d0:l4>(gr6,0)=gr4                                                                                         0| 004394 b          4BFFFC80   0     B          CL.319,-1
  417| 00434C cmpwi      2C000000   1     C4        cr0=gr0,0                                                                                                       0|                                CL.2197:
  417| 004350 bc         41820100   1     BT        CL.1208,cr0,0x4/eq,taken=40%(40,60)                                                                            64| 004398 ori        63E30000   1     LR         gr3=gr31
  419| 004354 bc         418000EC   1     BT        CL.2167,cr0,0x1/lt,taken=40%(40,60)                                                                            64| 00439C addi       389E13E4   1     AI         gr4=gr30,5092
  493|                                CL.1207:                                                                                                                     64| 0043A0 addi       38BE140C   1     AI         gr5=gr30,5132
  491| 004358 cmpwi      2C1D0000   1     C4        cr0=gr29,0                                                                                                     64| 0043A4 addi       38DE1110   1     AI         gr6=gr30,4368
  491| 00435C bc         41820030   1     BT        CL.1213,cr0,0x4/eq,taken=30%(30,70)                                                                            64| 0043A8 addi       38E00084   1     LI         gr7=132
  408| 004360 addi       387E1124   2     AI        gr3=gr30,4388                                                                                                  64| 0043AC addi       391E1438   1     AI         gr8=gr30,5176
  415| 004364 lwz        80A20004   1     L4A       gr5=._Py_RefTotal(gr2,0)                                                                                       64| 0043B0 bl         4BFFBC51   0     CALL       _PyObject_AssertFailed,6,(*)_object",gr3-gr5,(*)Cuchar",gr6-gr8,#ProcAlias",_PyObject_AssertFailed",fcr",g
  417| 004368 lwz        809D0000   1     L4A       gr4=(*)_object._object.ob_refcnt(gr29,0)                                                                       64| 0043B4 ori        60000000   1
  417| 00436C addi       3804FFFF   2     AI        gr0=gr4,-1                                                                                                     64| 0043B8 tw         7C8E7008   1     TRAP       9
  417| 004370 stw        901D0000   1     ST4A      (*)_object._object.ob_refcnt(gr29,0)=gr0                                                                        0|                                CL.2190:
  415| 004374 lwz        80850000   1     L4A       gr4=<s117:d0:l4>(gr5,0)                                                                                         0| 0043BC lwz        83E1004C   1     L4A        gr31=#stack(gr1,76)
  415| 004378 addi       3884FFFF   2     AI        gr4=gr4,-1                                                                                                      0| 0043C0 lwz        83C10048   1     L4A        gr30=#stack(gr1,72)
  415| 00437C stw        90850000   1     ST4A      <s117:d0:l4>(gr5,0)=gr4                                                                                         0| 0043C4 lwz        83A10044   1     L4A        gr29=#stack(gr1,68)
  417| 004380 cmpwi      2C000000   1     C4        cr0=gr0,0                                                                                                       0| 0043C8 lwz        83810040   1     L4A        gr28=#stack(gr1,64)
  417| 004384 bc         418200AC   1     BT        CL.1214,cr0,0x4/eq,taken=40%(40,60)                                                                             0| 0043CC lwz        8361003C   1     L4A        gr27=#stack(gr1,60)
  419| 004388 bc         41800094   1     BT        CL.2168,cr0,0x1/lt,taken=40%(40,60)                                                                             0| 0043D0 lwz        83410038   1     L4A        gr26=#stack(gr1,56)
  493|                                CL.1213:                                                                                                                      0| 0043D4 lwz        80010058   1     L4A        gr0=#stack(gr1,88)
  491| 00438C cmpwi      2C1C0000   1     C4        cr0=gr28,0                                                                                                    151| 0043D8 addi       38210050   1     AI         gr1=gr1,80
  491| 004390 bc         41820084   1     BT        CL.2154,cr0,0x4/eq,taken=30%(30,70)                                                                             0| 0043DC mtspr      7C0803A6   1     LLR        lr=gr0
  408| 004394 addi       387E1124   2     AI        gr3=gr30,4388                                                                                                 151| 0043E0 bclr       4E800020   3     BA         lr
  415| 004398 lwz        80A20004   1     L4A       gr5=._Py_RefTotal(gr2,0)                                                                                        0|                                CL.2196:
  417| 00439C lwz        809C0000   1     L4A       gr4=(*)_object._object.ob_refcnt(gr28,0)                                                                       44| 0043E4 addi       387E15E4   1     AI         gr3=gr30,5604
  417| 0043A0 addi       3804FFFF   2     AI        gr0=gr4,-1                                                                                                     44| 0043E8 addi       389E1610   1     AI         gr4=gr30,5648
  417| 0043A4 stw        901C0000   1     ST4A      (*)_object._object.ob_refcnt(gr28,0)=gr0                                                                       44| 0043EC addi       38A0002C   1     LI         gr5=44
  415| 0043A8 lwz        80850000   1     L4A       gr4=<s117:d0:l4>(gr5,0)                                                                                        44| 0043F0 bl         4BFFBC11   0     CALL       __assert,3,gr3-gr5,#ProcAlias",__assert",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",lr",fcr",xer",
  415| 0043AC addi       3884FFFF   2     AI        gr4=gr4,-1                                                                                                     44| 0043F4 ori        60000000   1
  415| 0043B0 stw        90850000   1     ST4A      <s117:d0:l4>(gr5,0)=gr4                                                                                         0| 0043F8 lwz        807FFFFC   1     L4A        gr3=(*)aggr#2._gc_prev(gr31,-4)
  417| 0043B4 cmpwi      2C000000   1     C4        cr0=gr0,0                                                                                                       0| 0043FC b          4BFFFB70   0     B          CL.1168,-1
  417| 0043B8 bc         41820048   1     BT        CL.1220,cr0,0x4/eq,taken=40%(40,60)                                                                             0|                                CL.2195:
    0| 0043BC lwz        83C10048   1     L4A       gr30=#stack(gr1,72)                                                                                            35| 004400 ori        63E30000   1     LR         gr3=gr31
  419| 0043C0 bc         4180002C   0     BT        CL.2169,cr0,0x1/lt,taken=40%(40,60)                                                                            35| 004404 addi       389E1594   1     AI         gr4=gr30,5524
  493|                                CL.1219:                                                                                                                     35| 004408 addi       38BE15B0   1     AI         gr5=gr30,5552
  150| 0043C4 ori        63E30000   1     LR        gr3=gr31                                                                                                       35| 00440C addi       38DE1110   1     AI         gr6=gr30,4368
  150| 0043C8 bl         4BFFBC39   0     CALL      PyObject_GC_Del,1,(*)void",gr3,#ProcAlias",PyObject_GC_Del",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",    35| 004410 addi       38E0007F   1     LI         gr7=127
  150| 0043CC ori        60000000   1                                                                                                                              35| 004414 addi       391E1580   1     AI         gr8=gr30,5504
    0| 0043D0 lwz        83810040   1     L4A       gr28=#stack(gr1,64)                                                                                            35| 004418 bl         4BFFBBE9   0     CALL       _PyObject_AssertFailed,6,(*)_object",gr3-gr5,(*)Cuchar",gr6-gr8,#ProcAlias",_PyObject_AssertFailed",fcr",g
    0| 0043D4 lwz        83A10044   1     L4A       gr29=#stack(gr1,68)                                                                                            35| 00441C ori        60000000   1
    0| 0043D8 lwz        83E1004C   1     L4A       gr31=#stack(gr1,76)                                                                                            35| 004420 tw         7C8E7008   1     TRAP       9
  151| 0043DC addi       38210050   1     AI        gr1=gr1,80                                                                                                      0|                                CL.2194:







Wed Apr 15 07:30:04 CDT 2020  Page 139


    0| 0043E0 lwz        80010008   1     L4A       gr0=#stack(gr1,8)                                                                                              30| 004424 ori        63E30000   1     LR         gr3=gr31
    0| 0043E4 mtspr      7C0803A6   2     LLR       lr=gr0                                                                                                         30| 004428 addi       389E1528   1     AI         gr4=gr30,5416
  151| 0043E8 bclr       4E800020   3     BA        lr                                                                                                             30| 00442C addi       38BE1550   1     AI         gr5=gr30,5456
    0|                                CL.2169:                                                                                                                     30| 004430 addi       38DE1110   1     AI         gr6=gr30,4368
  420| 0043EC addi       388001EC   1     LI        gr4=492                                                                                                        30| 004434 addi       38E0007F   1     LI         gr7=127
  420| 0043F0 ori        63850000   1     LR        gr5=gr28                                                                                                       30| 004438 addi       391E1580   1     AI         gr8=gr30,5504
  420| 0043F4 bl         4BFFBC0D   0     CALL      _Py_NegativeRefcount,3,(*)Cuchar",gr3,gr4,(*)_object",gr5,#ProcAlias",_Py_NegativeRefcount",fcr",gr1,cr[015    30| 00443C bl         4BFFBBC5   0     CALL       _PyObject_AssertFailed,6,(*)_object",gr3-gr5,(*)Cuchar",gr6-gr8,#ProcAlias",_PyObject_AssertFailed",fcr",g
  420| 0043F8 ori        60000000   1                                                                                                                              30| 004440 ori        60000000   1
  423| 0043FC b          4BFFFFC8   0     B         CL.1219,-1                                                                                                     30| 004444 tw         7C8E7008   1     TRAP       9
  423|                                CL.1220:                                                                                                                      0|                                CL.2193:
  425| 004400 ori        63830000   1     LR        gr3=gr28                                                                                                      125| 004448 ori        63E30000   1     LR         gr3=gr31
    0| 004404 lwz        83C10048   1     L4A       gr30=#stack(gr1,72)                                                                                           125| 00444C bl         4BFFBBB5   0     CALL       PyObject_ClearWeakRefs,1,(*)_object",gr3,#ProcAlias",PyObject_ClearWeakRefs",fcr",gr1,cr[01567]",gr0",gr3"
  425| 004408 bl         4BFFBBF9   0     CALL      _Py_Dealloc,1,(*)_object",gr3,#ProcAlias",_Py_Dealloc",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",l   125| 004450 ori        60000000   1
  425| 00440C ori        60000000   1                                                                                                                               0| 004454 lwz        801FFFF8   1     L4A        gr0=(*)_object%##2(gr31,-8)
    0| 004410 b          4BFFFFB4   0     B         CL.1219,-1                                                                                                      0| 004458 b          4BFFFAE0   0     B          CL.317,-1
    0|                                CL.2154:                                                                                                                      0|                                CL.2192:
    0| 004414 lwz        83C10048   1     L4A       gr30=#stack(gr1,72)                                                                                            64| 00445C addi       389E13E4   1     AI         gr4=gr30,5092
    0| 004418 b          4BFFFFAC   0     B         CL.1219,-1                                                                                                     64| 004460 addi       38BE140C   1     AI         gr5=gr30,5132
    0|                                CL.2168:                                                                                                                     64| 004464 addi       38DE1110   1     AI         gr6=gr30,4368
  420| 00441C addi       388001EC   1     LI        gr4=492                                                                                                        64| 004468 addi       38E0007A   1     LI         gr7=122
  420| 004420 ori        63A50000   1     LR        gr5=gr29                                                                                                       64| 00446C addi       391E1438   1     AI         gr8=gr30,5176
  420| 004424 bl         4BFFBBDD   0     CALL      _Py_NegativeRefcount,3,(*)Cuchar",gr3,gr4,(*)_object",gr5,#ProcAlias",_Py_NegativeRefcount",fcr",gr1,cr[015    64| 004470 bl         4BFFBB91   0     CALL       _PyObject_AssertFailed,6,(*)_object",gr3-gr5,(*)Cuchar",gr6-gr8,#ProcAlias",_PyObject_AssertFailed",fcr",g
  420| 004428 ori        60000000   1                                                                                                                              64| 004474 ori        60000000   1
  423| 00442C b          4BFFFF60   0     B         CL.1213,-1                                                                                                     64| 004478 tw         7C8E7008   1     TRAP       9
  423|                                CL.1214:                                                                                                                       | 00447C b          48000000   0
  425| 004430 ori        63A30000   1     LR        gr3=gr29                                                                                                         |               Tag Table
  425| 004434 bl         4BFFBBCD   0     CALL      _Py_Dealloc,1,(*)_object",gr3,#ProcAlias",_Py_Dealloc",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",l      | 004480        00000000 00002041 80060100 00000000 000005C0 000B6765
  425| 004438 ori        60000000   1                                                                                                                                | 004498        6E5F6465 616C6C6F 63
    0| 00443C b          4BFFFF50   0     B         CL.1213,-1                                                                                                       |               Instruction count          368
    0|                                CL.2167:                                                                                                                       |               Straight-line exec time    350
  420| 004440 addi       388001EC   1     LI        gr4=492                                                                                                      GPR's set/used:   ssus ssss ssss s---  ---- ---- ---- -sss
  420| 004444 bl         4BFFBBBD   0     CALL      _Py_NegativeRefcount,3,(*)Cuchar",gr3,gr4,(*)_object",gr5,#ProcAlias",_Py_NegativeRefcount",fcr",gr1,cr[015  FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----
  420| 004448 ori        60000000   1                                                                                                                            CCR's set/used:   ss-- -sss
  423| 00444C b          4BFFFF0C   0     B         CL.1207,-1                                                                                                       | 000000                             PDEF       gen_traverse
  423|                                CL.1208:                                                                                                                     31|                                    PROC       gen,visit,arg,gr3-gr5
  425| 004450 ori        60A30000   1     LR        gr3=gr5                                                                                                         0| 0044C0 mfspr      7C0802A6   1     LFLR       gr0=lr
  425| 004454 bl         4BFFBBAD   0     CALL      _Py_Dealloc,1,(*)_object",gr3,#ProcAlias",_Py_Dealloc",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",l     0| 0044C4 stwu       9421FF80   1     ST4U       gr1,#stack(gr1,-128)=gr1
  425| 004458 ori        60000000   1                                                                                                                               0| 0044C8 stw        90010088   1     ST4A       #stack(gr1,136)=gr0
    0| 00445C b          4BFFFEFC   0     B         CL.1207,-1                                                                                                      0| 0044CC stw        93E1007C   1     ST4A       #stack(gr1,124)=gr31
    0|                                CL.2152:                                                                                                                      0| 0044D0 ori        607F0000   1     LR         gr31=gr3
    0| 004460 lwz        83410038   1     L4A       gr26=#stack(gr1,56)                                                                                             0| 0044D4 stw        93C10078   1     ST4A       #stack(gr1,120)=gr30
    0| 004464 b          4BFFFEF4   0     B         CL.1207,-1                                                                                                      0| 0044D8 stw        93A10074   1     ST4A       #stack(gr1,116)=gr29
    0|                                CL.2166:                                                                                                                      0| 0044DC ori        60BE0000   1     LR         gr30=gr5
  420| 004468 addi       387E1110   1     AI        gr3=gr30,4368                                                                                                   0| 0044E0 ori        609D0000   1     LR         gr29=gr4
  420| 00446C addi       38800094   1     LI        gr4=148                                                                                                        33| 0044E4 stw        90410014   1     ST4A       #cur_toc(gr1,20)=gr2
  420| 004470 bl         4BFFBB91   0     CALL      _Py_NegativeRefcount,3,(*)Cuchar",gr3,gr4,(*)_object",gr5,#ProcAlias",_Py_NegativeRefcount",fcr",gr1,cr[015    33| 0044E8 ori        60A40000   1     LR         gr4=gr5
  420| 004474 ori        60000000   1                                                                                                                              33| 0044EC lwz        80630008   1     L4A        gr3=(*)aggr#3.gi_frame(gr3,8)
  423| 004478 b          4BFFFE90   0     B         CL.346,-1                                                                                                      33| 0044F0 cmpwi      2C030000   2     C4         cr0=gr3,0
  423|                                CL.1203:                                                                                                                     33| 0044F4 bc         418201F0   1     BT         CL.2267,cr0,0x4/eq,taken=30%(30,70)
  425| 00447C ori        60A30000   1     LR        gr3=gr5                                                                                                        33| 0044F8 lwz        801D0000   1     L4A        gr0=#fnc_adr(gr29,0)
  425| 004480 bl         4BFFBB81   0     CALL      _Py_Dealloc,1,(*)_object",gr3,#ProcAlias",_Py_Dealloc",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",l    33| 0044FC lwz        817D0008   1     L4A        gr11=#new_env(gr29,8)
  425| 004484 ori        60000000   1                                                                                                                              33| 004500 mtspr      7C0903A6   1     LCTR       ctr=gr0
    0| 004488 b          4BFFFE80   0     B         CL.346,-1                                                                                                      33| 004504 lwz        805D0004   1     CALL       gr3=gr29,2,(*)_object",gr3,(*)void",gr4,#ProcAlias",fcr",(*)int()",gr1,cr[01567]",gr0",gr4"-gr12",fp0"-fp1
    0|                                CL.2165:                                                                                                                     33| 004508 bcctrl     4E800421   0
  420| 00448C addi       387E1110   1     AI        gr3=gr30,4368                                                                                                  33| 00450C lwz        80410014   1
  420| 004490 addi       38800093   1     LI        gr4=147                                                                                                        33| 004510 cmpwi      2C030000   1     C4         cr0=gr3,0







Wed Apr 15 07:30:04 CDT 2020  Page 140


  420| 004494 bl         4BFFBB6D   0     CALL      _Py_NegativeRefcount,3,(*)Cuchar",gr3,gr4,(*)_object",gr5,#ProcAlias",_Py_NegativeRefcount",fcr",gr1,cr[015    33| 004514 bc         40820178   1     BF         CL.2264,cr0,0x4/eq,taken=30%(30,70)
  420| 004498 ori        60000000   1                                                                                                                              34| 004518 lwz        807F0010   2     L4A        gr3=(*)aggr#3.gi_code(gr31,16)
  423| 00449C b          4BFFFE34   0     B         CL.342,-1                                                                                                      34| 00451C cmpwi      2C030000   2     C4         cr0=gr3,0
  423|                                CL.1199:                                                                                                                     34| 004520 bc         41820028   1     BT         CL.359,cr0,0x4/eq,taken=50%(0,0)
  425| 0044A0 ori        60A30000   1     LR        gr3=gr5                                                                                                         0|                                CL.1899:
  425| 0044A4 bl         4BFFBB5D   0     CALL      _Py_Dealloc,1,(*)_object",gr3,#ProcAlias",_Py_Dealloc",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",l    34| 004524 ori        63C40000   1     LR         gr4=gr30
  425| 0044A8 ori        60000000   1                                                                                                                              34| 004528 lwz        801D0000   1     L4A        gr0=#fnc_adr(gr29,0)
    0| 0044AC b          4BFFFE24   0     B         CL.342,-1                                                                                                      34| 00452C lwz        817D0008   1     L4A        gr11=#new_env(gr29,8)
    0|                                CL.2164:                                                                                                                     34| 004530 mtspr      7C0903A6   1     LCTR       ctr=gr0
  420| 0044B0 addi       387E1110   1     AI        gr3=gr30,4368                                                                                                  34| 004534 lwz        805D0004   1     CALL       gr3=gr29,2,(*)_object",gr3,(*)void",gr4,#ProcAlias",fcr",(*)int()",gr1,cr[01567]",gr0",gr4"-gr12",fp0"-fp1
  420| 0044B4 addi       38800092   1     LI        gr4=146                                                                                                        34| 004538 bcctrl     4E800421   0
  420| 0044B8 ori        60C50000   1     LR        gr5=gr6                                                                                                        34| 00453C lwz        80410014   1
  420| 0044BC bl         4BFFBB45   0     CALL      _Py_NegativeRefcount,3,(*)Cuchar",gr3,gr4,(*)_object",gr5,#ProcAlias",_Py_NegativeRefcount",fcr",gr1,cr[015    34| 004540 cmpwi      2C030000   1     C4         cr0=gr3,0
  420| 0044C0 ori        60000000   1                                                                                                                              34| 004544 bc         40820148   1     BF         CL.2264,cr0,0x4/eq,taken=30%(30,70)
  423| 0044C4 b          4BFFFDD4   0     B         CL.338,-1                                                                                                      34|                                CL.359:
  423|                                CL.1195:                                                                                                                     35| 004548 ori        63C40000   1     LR         gr4=gr30
  425| 0044C8 ori        60C30000   1     LR        gr3=gr6                                                                                                        35| 00454C lwz        807F0018   1     L4A        gr3=(*)aggr#3.gi_name(gr31,24)
  425| 0044CC bl         4BFFBB35   0     CALL      _Py_Dealloc,1,(*)_object",gr3,#ProcAlias",_Py_Dealloc",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",l    35| 004550 cmpwi      2C030000   2     C4         cr0=gr3,0
  425| 0044D0 ori        60000000   1                                                                                                                              35| 004554 bc         41820180   1     BT         CL.2269,cr0,0x4/eq,taken=30%(30,70)
    0| 0044D4 b          4BFFFDC4   0     B         CL.338,-1                                                                                                      35| 004558 lwz        801D0000   1     L4A        gr0=#fnc_adr(gr29,0)
    0|                                CL.2163:                                                                                                                     35| 00455C lwz        817D0008   1     L4A        gr11=#new_env(gr29,8)
  420| 0044D8 addi       387E1110   1     AI        gr3=gr30,4368                                                                                                  35| 004560 mtspr      7C0903A6   1     LCTR       ctr=gr0
  420| 0044DC addi       38800090   1     LI        gr4=144                                                                                                        35| 004564 lwz        805D0004   1     CALL       gr3=gr29,2,(*)_object",gr3,(*)void",gr4,#ProcAlias",fcr",(*)int()",gr1,cr[01567]",gr0",gr4"-gr12",fp0"-fp1
  420| 0044E0 bl         4BFFBB21   0     CALL      _Py_NegativeRefcount,3,(*)Cuchar",gr3,gr4,(*)_object",gr5,#ProcAlias",_Py_NegativeRefcount",fcr",gr1,cr[015    35| 004568 bcctrl     4E800421   0
  420| 0044E4 ori        60000000   1                                                                                                                              35| 00456C lwz        80410014   1
    0| 0044E8 lwz        80DF0010   1     L4A       gr6=(*)aggr#3.gi_code(gr31,16)                                                                                 35| 004570 cmpwi      2C030000   1     C4         cr0=gr3,0
    0| 0044EC ori        60C30000   2     LR        gr3=gr6                                                                                                        35| 004574 bc         40820118   1     BF         CL.2264,cr0,0x4/eq,taken=30%(30,70)
  423| 0044F0 b          4BFFFD74   0     B         CL.329,-1                                                                                                      36| 004578 lwz        807F001C   2     L4A        gr3=(*)aggr#3.gi_qualname(gr31,28)
  423|                                CL.1191:                                                                                                                     36| 00457C cmpwi      2C030000   2     C4         cr0=gr3,0
  425| 0044F4 ori        60A30000   1     LR        gr3=gr5                                                                                                        36| 004580 bc         41820028   1     BT         CL.369,cr0,0x4/eq,taken=50%(0,0)
  425| 0044F8 bl         4BFFBB09   0     CALL      _Py_Dealloc,1,(*)_object",gr3,#ProcAlias",_Py_Dealloc",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",l     0|                                CL.1902:
  425| 0044FC ori        60000000   1                                                                                                                              36| 004584 ori        63C40000   1     LR         gr4=gr30
    0| 004500 lwz        80DF0010   1     L4A       gr6=(*)aggr#3.gi_code(gr31,16)                                                                                 36| 004588 lwz        801D0000   1     L4A        gr0=#fnc_adr(gr29,0)
    0| 004504 ori        60C30000   2     LR        gr3=gr6                                                                                                        36| 00458C lwz        817D0008   1     L4A        gr11=#new_env(gr29,8)
    0| 004508 b          4BFFFD5C   0     B         CL.329,-1                                                                                                      36| 004590 mtspr      7C0903A6   1     LCTR       ctr=gr0
    0|                                CL.2162:                                                                                                                     36| 004594 lwz        805D0004   1     CALL       gr3=gr29,2,(*)_object",gr3,(*)void",gr4,#ProcAlias",fcr",(*)int()",gr1,cr[01567]",gr0",gr4"-gr12",fp0"-fp1
  420| 00450C addi       387E1110   1     AI        gr3=gr30,4368                                                                                                  36| 004598 bcctrl     4E800421   0
  420| 004510 addi       3880008D   1     LI        gr4=141                                                                                                        36| 00459C lwz        80410014   1
  420| 004514 bl         4BFFBAED   0     CALL      _Py_NegativeRefcount,3,(*)Cuchar",gr3,gr4,(*)_object",gr5,#ProcAlias",_Py_NegativeRefcount",fcr",gr1,cr[015    36| 0045A0 cmpwi      2C030000   1     C4         cr0=gr3,0
  420| 004518 ori        60000000   1                                                                                                                              36| 0045A4 bc         408200E8   1     BF         CL.2264,cr0,0x4/eq,taken=30%(30,70)
  423| 00451C b          4BFFFCFC   0     B         CL.324,-1                                                                                                      36|                                CL.369:
  423|                                CL.1187:                                                                                                                     24| 0045A8 ori        63C40000   1     LR         gr4=gr30
  425| 004520 ori        60A30000   1     LR        gr3=gr5                                                                                                        24| 0045AC lwz        807F0020   1     L4A        gr3=(*)_err_stackitem._err_stackitem.exc_type(gr31,32)
  425| 004524 bl         4BFFBADD   0     CALL      _Py_Dealloc,1,(*)_object",gr3,#ProcAlias",_Py_Dealloc",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",l    24| 0045B0 cmpwi      2C030000   2     C4         cr0=gr3,0
  425| 004528 ori        60000000   1                                                                                                                              24| 0045B4 bc         41820110   1     BT         CL.2271,cr0,0x4/eq,taken=30%(30,70)
    0| 00452C b          4BFFFCEC   0     B         CL.324,-1                                                                                                      24| 0045B8 lwz        801D0000   1     L4A        gr0=#fnc_adr(gr29,0)
    0|                                CL.2161:                                                                                                                     24| 0045BC lwz        817D0008   1     L4A        gr11=#new_env(gr29,8)
  420| 004530 addi       387E1110   1     AI        gr3=gr30,4368                                                                                                  24| 0045C0 mtspr      7C0903A6   1     LCTR       ctr=gr0
  420| 004534 addi       38800089   1     LI        gr4=137                                                                                                        24| 0045C4 lwz        805D0004   1     CALL       gr3=gr29,2,(*)_object",gr3,(*)void",gr4,#ProcAlias",fcr",(*)int()",gr1,cr[01567]",gr0",gr4"-gr12",fp0"-fp1
  420| 004538 bl         4BFFBAC9   0     CALL      _Py_NegativeRefcount,3,(*)Cuchar",gr3,gr4,(*)_object",gr5,#ProcAlias",_Py_NegativeRefcount",fcr",gr1,cr[015    24| 0045C8 bcctrl     4E800421   0
  420| 00453C ori        60000000   1                                                                                                                              24| 0045CC lwz        80410014   1
  423| 004540 b          4BFFFC9C   0     B         CL.319,-1                                                                                                      24| 0045D0 cmpwi      2C030000   1     C4         cr0=gr3,0
  423|                                CL.1183:                                                                                                                     24| 0045D4 bc         408200D4   1     BF         CL.2272,cr0,0x4/eq,taken=30%(30,70)
  425| 004544 ori        60A30000   1     LR        gr3=gr5                                                                                                        25| 0045D8 lwz        807F0024   2     L4A        gr3=(*)_err_stackitem._err_stackitem.exc_value(gr31,36)
  425| 004548 bl         4BFFBAB9   0     CALL      _Py_Dealloc,1,(*)_object",gr3,#ProcAlias",_Py_Dealloc",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",l    25| 0045DC cmpwi      2C030000   2     C4         cr0=gr3,0
  425| 00454C ori        60000000   1                                                                                                                              25| 0045E0 bc         41820028   1     BT         CL.1140,cr0,0x4/eq,taken=50%(0,0)







Wed Apr 15 07:30:04 CDT 2020  Page 141


    0| 004550 b          4BFFFC8C   0     B         CL.319,-1                                                                                                       0|                                CL.1905:
    0|                                CL.2160:                                                                                                                     25| 0045E4 ori        63C40000   1     LR         gr4=gr30
   64| 004554 ori        63E30000   1     LR        gr3=gr31                                                                                                       25| 0045E8 lwz        801D0000   1     L4A        gr0=#fnc_adr(gr29,0)
   64| 004558 addi       389E13E4   1     AI        gr4=gr30,5092                                                                                                  25| 0045EC lwz        817D0008   1     L4A        gr11=#new_env(gr29,8)
   64| 00455C addi       38BE140C   1     AI        gr5=gr30,5132                                                                                                  25| 0045F0 mtspr      7C0903A6   1     LCTR       ctr=gr0
   64| 004560 addi       38DE1110   1     AI        gr6=gr30,4368                                                                                                  25| 0045F4 lwz        805D0004   1     CALL       gr3=gr29,2,(*)_object",gr3,(*)void",gr4,#ProcAlias",fcr",(*)int()",gr1,cr[01567]",gr0",gr4"-gr12",fp0"-fp1
   64| 004564 addi       38E00084   1     LI        gr7=132                                                                                                        25| 0045F8 bcctrl     4E800421   0
   64| 004568 addi       391E1438   1     AI        gr8=gr30,5176                                                                                                  25| 0045FC lwz        80410014   1
   64| 00456C bl         4BFFBA95   0     CALL      _PyObject_AssertFailed,6,(*)_object",gr3-gr5,(*)Cuchar",gr6-gr8,#ProcAlias",_PyObject_AssertFailed",fcr",gr    25| 004600 cmpwi      2C030000   1     C4         cr0=gr3,0
   64| 004570 ori        60000000   1                                                                                                                              25| 004604 bc         40820088   1     BF         CL.2264,cr0,0x4/eq,taken=50%(0,0)
   64| 004574 tw         7C8E7008   1     TRAP      9                                                                                                              25|                                CL.1140:
    0|                                CL.2153:                                                                                                                     26| 004608 ori        63C40000   1     LR         gr4=gr30
    0| 004578 lwz        83E1004C   1     L4A       gr31=#stack(gr1,76)                                                                                            26| 00460C lwz        807F0028   1     L4A        gr3=(*)_err_stackitem._err_stackitem.exc_traceback(gr31,40)
    0| 00457C lwz        83C10048   1     L4A       gr30=#stack(gr1,72)                                                                                            26| 004610 cmpwi      2C030000   2     C4         cr0=gr3,0
    0| 004580 lwz        83A10044   1     L4A       gr29=#stack(gr1,68)                                                                                            26| 004614 bc         41820058   1     BT         CL.2273,cr0,0x4/eq,taken=30%(30,70)
    0| 004584 lwz        83810040   1     L4A       gr28=#stack(gr1,64)                                                                                            26| 004618 lwz        801D0000   1     L4A        gr0=#fnc_adr(gr29,0)
    0| 004588 lwz        8361003C   1     L4A       gr27=#stack(gr1,60)                                                                                            26| 00461C lwz        817D0008   1     L4A        gr11=#new_env(gr29,8)
    0| 00458C lwz        83410038   1     L4A       gr26=#stack(gr1,56)                                                                                             0| 004620 lwz        83E1007C   1     L4A        gr31=#stack(gr1,124)
  151| 004590 addi       38210050   1     AI        gr1=gr1,80                                                                                                      0| 004624 lwz        83C10078   1     L4A        gr30=#stack(gr1,120)
    0| 004594 lwz        80010008   1     L4A       gr0=#stack(gr1,8)                                                                                              26| 004628 mtspr      7C0903A6   1     LCTR       ctr=gr0
    0| 004598 mtspr      7C0803A6   2     LLR       lr=gr0                                                                                                         26| 00462C lwz        805D0004   1     CALL       gr3=gr29,2,(*)_object",gr3,(*)void",gr4,#ProcAlias",fcr",(*)int()",gr1,cr[01567]",gr0",gr4"-gr12",fp0"-fp1
  151| 00459C bclr       4E800020   3     BA        lr                                                                                                             26| 004630 bcctrl     4E800421   0
    0|                                CL.2159:                                                                                                                     26| 004634 lwz        80410014   1
   44| 0045A0 addi       387E15E4   1     AI        gr3=gr30,5604                                                                                                  26| 004638 cmpwi      2C030000   1     C4         cr0=gr3,0
   44| 0045A4 addi       389E1610   1     AI        gr4=gr30,5648                                                                                                  26| 00463C bc         41820018   1     BT         CL.1908,cr0,0x4/eq,taken=50%(0,0)
   44| 0045A8 addi       38A0002C   1     LI        gr5=44                                                                                                          0| 004640 lwz        83A10074   2     L4A        gr29=#stack(gr1,116)
   44| 0045AC bl         4BFFBA55   0     CALL      __assert,3,gr3-gr5,#ProcAlias",__assert",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",lr",fcr",xer",f     0| 004644 lwz        80010088   1     L4A        gr0=#stack(gr1,136)
   44| 0045B0 ori        60000000   1                                                                                                                              40| 004648 addi       38210080   1     AI         gr1=gr1,128
    0| 0045B4 lwz        807FFFFC   1     L4A       gr3=(*)aggr#2._gc_prev(gr31,-4)                                                                                 0| 00464C mtspr      7C0803A6   1     LLR        lr=gr0
    0| 0045B8 b          4BFFFB78   0     B         CL.1168,-1                                                                                                     40| 004650 bclr       4E800020   3     BA         lr
    0|                                CL.2158:                                                                                                                      0|                                CL.1908:
   35| 0045BC ori        63E30000   1     LR        gr3=gr31                                                                                                       27| 004654 addi       38600000   1     LI         gr3=0
   35| 0045C0 addi       389E1594   1     AI        gr4=gr30,5524                                                                                                   0| 004658 lwz        83A10074   1     L4A        gr29=#stack(gr1,116)
   35| 0045C4 addi       38BE15B0   1     AI        gr5=gr30,5552                                                                                                   0| 00465C lwz        80010088   1     L4A        gr0=#stack(gr1,136)
   35| 0045C8 addi       38DE1110   1     AI        gr6=gr30,4368                                                                                                  40| 004660 addi       38210080   1     AI         gr1=gr1,128
   35| 0045CC addi       38E0007F   1     LI        gr7=127                                                                                                         0| 004664 mtspr      7C0803A6   1     LLR        lr=gr0
   35| 0045D0 addi       391E1580   1     AI        gr8=gr30,5504                                                                                                  40| 004668 bclr       4E800020   3     BA         lr
   35| 0045D4 bl         4BFFBA2D   0     CALL      _PyObject_AssertFailed,6,(*)_object",gr3-gr5,(*)Cuchar",gr6-gr8,#ProcAlias",_PyObject_AssertFailed",fcr",gr     0|                                CL.2273:
   35| 0045D8 ori        60000000   1                                                                                                                              27| 00466C addi       38600000   1     LI         gr3=0
   35| 0045DC tw         7C8E7008   1     TRAP      9                                                                                                               0| 004670 lwz        83E1007C   1     L4A        gr31=#stack(gr1,124)
    0|                                CL.2157:                                                                                                                      0| 004674 lwz        83C10078   1     L4A        gr30=#stack(gr1,120)
   30| 0045E0 ori        63E30000   1     LR        gr3=gr31                                                                                                        0| 004678 lwz        83A10074   1     L4A        gr29=#stack(gr1,116)
   30| 0045E4 addi       389E1528   1     AI        gr4=gr30,5416                                                                                                   0| 00467C lwz        80010088   1     L4A        gr0=#stack(gr1,136)
   30| 0045E8 addi       38BE1550   1     AI        gr5=gr30,5456                                                                                                  40| 004680 addi       38210080   1     AI         gr1=gr1,128
   30| 0045EC addi       38DE1110   1     AI        gr6=gr30,4368                                                                                                   0| 004684 mtspr      7C0803A6   1     LLR        lr=gr0
   30| 0045F0 addi       38E0007F   1     LI        gr7=127                                                                                                        40| 004688 bclr       4E800020   3     BA         lr
   30| 0045F4 addi       391E1580   1     AI        gr8=gr30,5504                                                                                                   0|                                CL.2264:
   30| 0045F8 bl         4BFFBA09   0     CALL      _PyObject_AssertFailed,6,(*)_object",gr3-gr5,(*)Cuchar",gr6-gr8,#ProcAlias",_PyObject_AssertFailed",fcr",gr     0| 00468C lwz        83E1007C   1     L4A        gr31=#stack(gr1,124)
   30| 0045FC ori        60000000   1                                                                                                                               0| 004690 lwz        83C10078   1     L4A        gr30=#stack(gr1,120)
   30| 004600 tw         7C8E7008   1     TRAP      9                                                                                                               0| 004694 lwz        83A10074   1     L4A        gr29=#stack(gr1,116)
    0|                                CL.2156:                                                                                                                      0| 004698 lwz        80010088   1     L4A        gr0=#stack(gr1,136)
  125| 004604 ori        63E30000   1     LR        gr3=gr31                                                                                                       40| 00469C addi       38210080   1     AI         gr1=gr1,128
  125| 004608 bl         4BFFB9F9   0     CALL      PyObject_ClearWeakRefs,1,(*)_object",gr3,#ProcAlias",PyObject_ClearWeakRefs",fcr",gr1,cr[01567]",gr0",gr3"-     0| 0046A0 mtspr      7C0803A6   1     LLR        lr=gr0
  125| 00460C ori        60000000   1                                                                                                                              40| 0046A4 bclr       4E800020   3     BA         lr
    0| 004610 b          4BFFFAE8   0     B         CL.317,-1                                                                                                       0|                                CL.2272:
    0|                                CL.2155:                                                                                                                      0| 0046A8 lwz        83E1007C   1     L4A        gr31=#stack(gr1,124)







Wed Apr 15 07:30:04 CDT 2020  Page 142


   64| 004614 addi       389E13E4   1     AI        gr4=gr30,5092                                                                                                   0| 0046AC lwz        83C10078   1     L4A        gr30=#stack(gr1,120)
   64| 004618 addi       38BE140C   1     AI        gr5=gr30,5132                                                                                                   0| 0046B0 lwz        83A10074   1     L4A        gr29=#stack(gr1,116)
   64| 00461C addi       38DE1110   1     AI        gr6=gr30,4368                                                                                                   0| 0046B4 lwz        80010088   1     L4A        gr0=#stack(gr1,136)
   64| 004620 addi       38E0007A   1     LI        gr7=122                                                                                                        40| 0046B8 addi       38210080   1     AI         gr1=gr1,128
   64| 004624 addi       391E1438   1     AI        gr8=gr30,5176                                                                                                   0| 0046BC mtspr      7C0803A6   1     LLR        lr=gr0
   64| 004628 bl         4BFFB9D9   0     CALL      _PyObject_AssertFailed,6,(*)_object",gr3-gr5,(*)Cuchar",gr6-gr8,#ProcAlias",_PyObject_AssertFailed",fcr",gr    40| 0046C0 bclr       4E800020   3     BA         lr
   64| 00462C ori        60000000   1                                                                                                                               0|                                CL.2271:
   64| 004630 tw         7C8E7008   1     TRAP      9                                                                                                              25| 0046C4 lwz        807F0024   1     L4A        gr3=(*)_err_stackitem._err_stackitem.exc_value(gr31,36)
     | 004634 b          48000000   0                                                                                                                              25| 0046C8 cmpwi      2C030000   2     C4         cr0=gr3,0
     |               Tag Table                                                                                                                                     25| 0046CC bc         4182FF3C   1     BT         CL.1140,cr0,0x4/eq,taken=50%(0,0)
     | 004638        00000000 00002041 80060100 00000000 000005B8 000B6765                                                                                          0| 0046D0 b          4BFFFF14   1     B          CL.1905,-1
     | 004650        6E5F6465 616C6C6F 63                                                                                                                           0|                                CL.2269:
     |               Instruction count          366                                                                                                                36| 0046D4 lwz        807F001C   1     L4A        gr3=(*)aggr#3.gi_qualname(gr31,28)
     |               Straight-line exec time    358                                                                                                                36| 0046D8 cmpwi      2C030000   2     C4         cr0=gr3,0
 GPR's set/used:   ssus ssss ssss s---  ---- ---- ---- -sss                                                                                                        36| 0046DC bc         4182FECC   1     BT         CL.369,cr0,0x4/eq,taken=50%(0,0)
 FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----                                                                                                         0| 0046E0 b          4BFFFEA4   1     B          CL.1902,-1
 CCR's set/used:   ss-- -sss                                                                                                                                        0|                                CL.2267:
     | 000000                             PDEF     gen_traverse                                                                                                    34| 0046E4 lwz        807F0010   1     L4A        gr3=(*)aggr#3.gi_code(gr31,16)
   31|                                    PROC      gen,visit,arg,gr3-gr5                                                                                          34| 0046E8 cmpwi      2C030000   2     C4         cr0=gr3,0
    0| 004660 mfspr      7C0802A6   1     LFLR      gr0=lr                                                                                                         34| 0046EC bc         4182FE5C   1     BT         CL.359,cr0,0x4/eq,taken=50%(0,0)
    0| 004664 stw        90010008   2     ST4A      #stack(gr1,8)=gr0                                                                                               0| 0046F0 b          4BFFFE34   1     B          CL.1899,-1
    0| 004668 stw        93E1FFFC   1     ST4A      #stack(gr1,-4)=gr31                                                                                              |               Tag Table
    0| 00466C ori        607F0000   1     LR        gr31=gr3                                                                                                         | 0046F4        00000000 00002041 80030300 00000000 00000234 000C6765
    0| 004670 stw        93C1FFF8   1     ST4A      #stack(gr1,-8)=gr30                                                                                              | 00470C        6E5F7472 61766572 7365
    0| 004674 stw        93A1FFF4   1     ST4A      #stack(gr1,-12)=gr29                                                                                             |               Instruction count          141
    0| 004678 ori        60BE0000   1     LR        gr30=gr5                                                                                                         |               Straight-line exec time    158
    0| 00467C ori        609D0000   1     LR        gr29=gr4                                                                                                     GPR's set/used:   ssus ssss ssss s---  ---- ---- ---- ssss
    0| 004680 stwu       9421FF80   1     ST4U      gr1,#stack(gr1,-128)=gr1                                                                                     FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----
   33| 004684 ori        60A40000   1     LR        gr4=gr5                                                                                                      CCR's set/used:   ss-- -sss
   33| 004688 lwz        80630008   1     L4A       gr3=(*)aggr#3.gi_frame(gr3,8)                                                                                    | 000000                             PDEF       IPRA.$async_gen_athrow_new
   33| 00468C cmpwi      2C030000   2     C4        cr0=gr3,0                                                                                                    2042|                                    PROC       gen,args,gr3,gr4
   33| 004690 stw        90410014   1     ST4A      #cur_toc(gr1,20)=gr2                                                                                            0| 004720 mfspr      7C0802A6   1     LFLR       gr0=lr
   33| 004694 bc         418201F0   0     BT        CL.2227,cr0,0x4/eq,taken=30%(30,70)                                                                             0| 004724 stwu       9421FFB0   1     ST4U       gr1,#stack(gr1,-80)=gr1
   33| 004698 lwz        801D0000   1     L4A       gr0=#fnc_adr(gr29,0)                                                                                            0| 004728 stw        90010058   1     ST4A       #stack(gr1,88)=gr0
   33| 00469C lwz        817D0008   1     L4A       gr11=#new_env(gr29,8)                                                                                           0| 00472C ori        607F0000   1     LR         gr31=gr3
   33| 0046A0 mtspr      7C0903A6   1     LCTR      ctr=gr0                                                                                                         0| 004730 stw        93A10044   1     ST4A       #stack(gr1,68)=gr29
   33| 0046A4 lwz        805D0004   1     CALL      gr3=gr29,2,(*)_object",gr3,(*)void",gr4,#ProcAlias",fcr",(*)int()",gr1,cr[01567]",gr0",gr4"-gr12",fp0"-fp13     0| 004734 ori        609E0000   1     LR         gr30=gr4
   33| 0046A8 bcctrl     4E800421   0                                                                                                                               0| 004738 stw        93810040   1     ST4A       #stack(gr1,64)=gr28
   33| 0046AC lwz        80410014   1                                                                                                                            2045| 00473C lwz        806200EC   1     L4A        gr3=._PyAsyncGenAThrow_Type(gr2,0)
   33| 0046B0 cmpwi      2C030000   1     C4        cr0=gr3,0                                                                                                    2045| 004740 bl         4BFFB8C1   0     CALL       gr3=_PyObject_GC_New,1,(*)_typeobject",gr3,#ProcAlias",_PyObject_GC_New",fcr",gr1,cr[01567]",gr0",gr4"-gr1
   33| 0046B4 bc         40820178   1     BF        CL.2224,cr0,0x4/eq,taken=30%(30,70)                                                                          2045| 004744 ori        60000000   1
   34| 0046B8 lwz        807F0010   2     L4A       gr3=(*)aggr#3.gi_code(gr31,16)                                                                               2046| 004748 cmpwi      2C030000   1     C4         cr0=gr3,0
   34| 0046BC cmpwi      2C030000   2     C4        cr0=gr3,0                                                                                                    2046| 00474C bc         41820164   1     BT         CL.1875,cr0,0x4/eq,taken=30%(30,70)
   34| 0046C0 bc         41820028   1     BT        CL.359,cr0,0x4/eq,taken=50%(0,0)                                                                              401| 004750 lwz        80820004   2     L4A        gr4=._Py_RefTotal(gr2,0)
    0|                                CL.1810:                                                                                                                   2046| 004754 ori        607C0000   1     LR         gr28=gr3
   34| 0046C4 ori        63C40000   1     LR        gr4=gr30                                                                                                      403| 004758 lwz        807F0000   1     L4A        gr3=(*)_object._object.ob_refcnt(gr31,0)
   34| 0046C8 lwz        801D0000   1     L4A       gr0=#fnc_adr(gr29,0)                                                                                          482| 00475C cmpwi      2C1E0000   1     C4         cr0=gr30,0
   34| 0046CC lwz        817D0008   1     L4A       gr11=#new_env(gr29,8)                                                                                         403| 004760 addi       38630001   1     AI         gr3=gr3,1
   34| 0046D0 mtspr      7C0903A6   1     LCTR      ctr=gr0                                                                                                       403| 004764 stw        907F0000   1     ST4A       (*)_object._object.ob_refcnt(gr31,0)=gr3
   34| 0046D4 lwz        805D0004   1     CALL      gr3=gr29,2,(*)_object",gr3,(*)void",gr4,#ProcAlias",fcr",(*)int()",gr1,cr[01567]",gr0",gr4"-gr12",fp0"-fp13  2049| 004768 stw        93FC0008   1     ST4A       (*)aggr#E.agt_gen(gr28,8)=gr31
   34| 0046D8 bcctrl     4E800421   0                                                                                                                            2050| 00476C stw        93DC000C   1     ST4A       (*)aggr#E.agt_args(gr28,12)=gr30
   34| 0046DC lwz        80410014   1                                                                                                                             401| 004770 lwz        80C40000   1     L4A        gr6=_Py_RefTotal(gr4,0)
   34| 0046E0 cmpwi      2C030000   1     C4        cr0=gr3,0                                                                                                     401| 004774 addi       38E60001   2     AI         gr7=gr6,1
   34| 0046E4 bc         40820148   1     BF        CL.2224,cr0,0x4/eq,taken=30%(30,70)                                                                           401| 004778 stw        90E40000   1     ST4A       _Py_RefTotal(gr4,0)=gr7
   34|                                CL.359:                                                                                                                       0| 00477C lwz        80010058   1     L4A        gr0=#stack(gr1,88)
   35| 0046E8 ori        63C40000   1     LR        gr4=gr30                                                                                                        0| 004780 mtspr      7C0803A6   2     LLR        lr=gr0







Wed Apr 15 07:30:04 CDT 2020  Page 143


   35| 0046EC lwz        807F0018   1     L4A       gr3=(*)aggr#3.gi_name(gr31,24)                                                                               2051| 004784 addi       38000000   1     LI         gr0=0
   35| 0046F0 cmpwi      2C030000   2     C4        cr0=gr3,0                                                                                                    2051| 004788 stw        901C0010   1     ST4A       (*)aggr#E.agt_state(gr28,16)=gr0
   35| 0046F4 bc         41820180   1     BT        CL.2229,cr0,0x4/eq,taken=30%(30,70)                                                                           482| 00478C bc         4182010C   0     BT         CL.1871,cr0,0x4/eq,taken=30%(30,70)
   35| 0046F8 lwz        801D0000   1     L4A       gr0=#fnc_adr(gr29,0)                                                                                           30| 004790 lwz        80BCFFF8   1     L4A        gr5=(*)_object%##2(gr28,-8)
   35| 0046FC lwz        817D0008   1     L4A       gr11=#new_env(gr29,8)                                                                                         401| 004794 addi       38060002   1     AI         gr0=gr6,2
   35| 004700 mtspr      7C0903A6   1     LCTR      ctr=gr0                                                                                                       403| 004798 lwz        807E0000   1     L4A        gr3=(*)_object._object.ob_refcnt(gr30,0)
   35| 004704 lwz        805D0004   1     CALL      gr3=gr29,2,(*)_object",gr3,(*)void",gr4,#ProcAlias",fcr",(*)int()",gr1,cr[01567]",gr0",gr4"-gr12",fp0"-fp13     0| 00479C lwz        81020018   1     L4A        gr8=.+CONSTANT_AREA(gr2,0)
   35| 004708 bcctrl     4E800421   0                                                                                                                             401| 0047A0 stw        90040000   1     ST4A       _Py_RefTotal(gr4,0)=gr0
   35| 00470C lwz        80410014   1                                                                                                                              30| 0047A4 cmpwi      2C050000   1     C4         cr0=gr5,0
   35| 004710 cmpwi      2C030000   1     C4        cr0=gr3,0                                                                                                     403| 0047A8 addi       38030001   1     AI         gr0=gr3,1
   35| 004714 bc         40820118   1     BF        CL.2224,cr0,0x4/eq,taken=30%(30,70)                                                                           403| 0047AC stw        901E0000   1     ST4A       (*)_object._object.ob_refcnt(gr30,0)=gr0
   36| 004718 lwz        807F001C   2     L4A       gr3=(*)aggr#3.gi_qualname(gr31,28)                                                                             27| 0047B0 addi       38C81110   1     AI         gr6=gr8,4368
   36| 00471C cmpwi      2C030000   2     C4        cr0=gr3,0                                                                                                      30| 0047B4 bc         41820024   0     BT         CL.1419,cr0,0x4/eq,taken=50%(0,0)
   36| 004720 bc         41820028   1     BT        CL.369,cr0,0x4/eq,taken=50%(0,0)                                                                                0|                                CL.1872:
    0|                                CL.1813:                                                                                                                     30| 0047B8 ori        63830000   1     LR         gr3=gr28
   36| 004724 ori        63C40000   1     LR        gr4=gr30                                                                                                       30| 0047BC addi       38881528   1     AI         gr4=gr8,5416
   36| 004728 lwz        801D0000   1     L4A       gr0=#fnc_adr(gr29,0)                                                                                           30| 0047C0 addi       38A81550   1     AI         gr5=gr8,5456
   36| 00472C lwz        817D0008   1     L4A       gr11=#new_env(gr29,8)                                                                                          30| 0047C4 addi       38E00806   1     LI         gr7=2054
   36| 004730 mtspr      7C0903A6   1     LCTR      ctr=gr0                                                                                                        30| 0047C8 addi       39081580   1     AI         gr8=gr8,5504
   36| 004734 lwz        805D0004   1     CALL      gr3=gr29,2,(*)_object",gr3,(*)void",gr4,#ProcAlias",fcr",(*)int()",gr1,cr[01567]",gr0",gr4"-gr12",fp0"-fp13    30| 0047CC bl         4BFFB835   0     CALL       _PyObject_AssertFailed,6,(*)_object",gr3-gr5,(*)Cuchar",gr6-gr8,#ProcAlias",_PyObject_AssertFailed",fcr",g
   36| 004738 bcctrl     4E800421   0                                                                                                                              30| 0047D0 ori        60000000   1
   36| 00473C lwz        80410014   1                                                                                                                              30| 0047D4 tw         7C8E7008   1     TRAP       9
   36| 004740 cmpwi      2C030000   1     C4        cr0=gr3,0                                                                                                      30|                                CL.1419:
   36| 004744 bc         408200E8   1     BF        CL.2224,cr0,0x4/eq,taken=30%(30,70)                                                                            34| 0047D8 addi       3BFCFFF8   1     AI         gr31=gr28,-8
   36|                                CL.369:                                                                                                                      35| 0047DC lwz        801CFFFC   1     L4A        gr0=(*)aggr#2._gc_prev(gr28,-4)
   24| 004748 ori        63C40000   1     LR        gr4=gr30                                                                                                       35| 0047E0 andi.      70030002   2     RN4_R      gr3,cr0=gr0,0,0x2
   24| 00474C lwz        807F0020   1     L4A       gr3=(*)_err_stackitem._err_stackitem.exc_type(gr31,32)                                                         35| 0047E4 bc         40820094   1     BF         CL.1876,cr0,0x4/eq,taken=10%(10,90)
   24| 004750 cmpwi      2C030000   2     C4        cr0=gr3,0                                                                                                      67| 0047E8 lwz        808200A4   1     L4A        gr4=._PyRuntime(gr2,0)
   24| 004754 bc         41820110   1     BT        CL.2231,cr0,0x4/eq,taken=30%(30,70)                                                                            54| 0047EC lwz        806401A0   2     L4A        gr3=(*)pyruntimestate._Py_atomic_address._value(gr4,416)
   24| 004758 lwz        801D0000   1     L4A       gr0=#fnc_adr(gr29,0)                                                                                           41| 0047F0 lwz        80630008   2     L4A        gr3=(*)_ts._ts.interp(gr3,8)
   24| 00475C lwz        817D0008   1     L4A       gr11=#new_env(gr29,8)                                                                                          41| 0047F4 lwz        83C30188   2     L4A        gr30=(*)_is._gc_runtime_state.generation0(gr3,392)
   24| 004760 mtspr      7C0903A6   1     LCTR      ctr=gr0                                                                                                        42| 0047F8 lwz        83BE0004   2     L4A        gr29=(*)aggr#2._gc_prev(gr30,4)
   24| 004764 lwz        805D0004   1     CALL      gr3=gr29,2,(*)_object",gr3,(*)void",gr4,#ProcAlias",fcr",(*)int()",gr1,cr[01567]",gr0",gr4"-gr12",fp0"-fp13    44| 0047FC andi.      73A30003   2     RN4_R      gr3,cr0=gr29,0,0xFFFFFFFF00000003
   24| 004768 bcctrl     4E800421   0                                                                                                                              43| 004800 stw        93FD0000   1     ST4A       (*)aggr#2._gc_next(gr29,0)=gr31
   24| 00476C lwz        80410014   1                                                                                                                              44| 004804 bc         4082002C   0     BF         CL.2298,cr0,0x4/eq,taken=40%(40,60)
   24| 004770 cmpwi      2C030000   1     C4        cr0=gr3,0                                                                                                      44| 004808 rlwinm     540007BE   1     RN4        gr0=gr0,0,0x3
   24| 004774 bc         408200D4   1     BF        CL.2232,cr0,0x4/eq,taken=30%(30,70)                                                                            45| 00480C stw        93DCFFF8   1     ST4A       (*)aggr#2._gc_next(gr28,-8)=gr30
   25| 004778 lwz        807F0024   2     L4A       gr3=(*)_err_stackitem._err_stackitem.exc_value(gr31,36)                                                        44| 004810 or         7C04EB78   1     O          gr4=gr0,gr29
   25| 00477C cmpwi      2C030000   2     C4        cr0=gr3,0                                                                                                    2055| 004814 ori        63830000   1     LR         gr3=gr28
   25| 004780 bc         41820028   1     BT        CL.1140,cr0,0x4/eq,taken=50%(0,0)                                                                              44| 004818 stw        909CFFFC   1     ST4A       (*)aggr#2._gc_prev(gr28,-4)=gr4
    0|                                CL.1816:                                                                                                                     46| 00481C stw        93FE0004   1     ST4A       (*)aggr#2._gc_prev(gr30,4)=gr31
   25| 004784 ori        63C40000   1     LR        gr4=gr30                                                                                                        0| 004820 lwz        83810040   1     L4A        gr28=#stack(gr1,64)
   25| 004788 lwz        801D0000   1     L4A       gr0=#fnc_adr(gr29,0)                                                                                            0| 004824 lwz        83A10044   1     L4A        gr29=#stack(gr1,68)
   25| 00478C lwz        817D0008   1     L4A       gr11=#new_env(gr29,8)                                                                                        2056| 004828 addi       38210050   1     AI         gr1=gr1,80
   25| 004790 mtspr      7C0903A6   1     LCTR      ctr=gr0                                                                                                      2056| 00482C bclr       4E800020   0     BA         lr
   25| 004794 lwz        805D0004   1     CALL      gr3=gr29,2,(*)_object",gr3,(*)void",gr4,#ProcAlias",fcr",(*)int()",gr1,cr[01567]",gr0",gr4"-gr12",fp0"-fp13     0|                                CL.2298:
   25| 004798 bcctrl     4E800421   0                                                                                                                              44| 004830 addi       386815E4   1     AI         gr3=gr8,5604
   25| 00479C lwz        80410014   1                                                                                                                              44| 004834 addi       38881610   1     AI         gr4=gr8,5648
   25| 0047A0 cmpwi      2C030000   1     C4        cr0=gr3,0                                                                                                      44| 004838 addi       38A0002C   1     LI         gr5=44
   25| 0047A4 bc         40820088   1     BF        CL.2224,cr0,0x4/eq,taken=50%(0,0)                                                                              44| 00483C bl         4BFFB7C5   0     CALL       __assert,3,gr3-gr5,#ProcAlias",__assert",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",lr",fcr",xer",
   25|                                CL.1140:                                                                                                                     44| 004840 ori        60000000   1
   26| 0047A8 ori        63C40000   1     LR        gr4=gr30                                                                                                        0| 004844 lwz        801CFFFC   1     L4A        gr0=(*)aggr#2._gc_prev(gr28,-4)
   26| 0047AC lwz        807F0028   1     L4A       gr3=(*)_err_stackitem._err_stackitem.exc_traceback(gr31,40)                                                    45| 004848 stw        93DCFFF8   1     ST4A       (*)aggr#2._gc_next(gr28,-8)=gr30
   26| 0047B0 cmpwi      2C030000   2     C4        cr0=gr3,0                                                                                                    2055| 00484C ori        63830000   1     LR         gr3=gr28
   26| 0047B4 bc         41820058   1     BT        CL.2233,cr0,0x4/eq,taken=30%(30,70)                                                                            44| 004850 rlwinm     540007BE   1     RN4        gr0=gr0,0,0x3
   26| 0047B8 lwz        801D0000   1     L4A       gr0=#fnc_adr(gr29,0)                                                                                           44| 004854 or         7C04EB78   1     O          gr4=gr0,gr29







Wed Apr 15 07:30:04 CDT 2020  Page 144


   26| 0047BC lwz        817D0008   1     L4A       gr11=#new_env(gr29,8)                                                                                          44| 004858 stw        909CFFFC   1     ST4A       (*)aggr#2._gc_prev(gr28,-4)=gr4
    0| 0047C0 lwz        83E1007C   1     L4A       gr31=#stack(gr1,124)                                                                                           46| 00485C stw        93FE0004   1     ST4A       (*)aggr#2._gc_prev(gr30,4)=gr31
    0| 0047C4 lwz        83C10078   1     L4A       gr30=#stack(gr1,120)                                                                                            0| 004860 lwz        83810040   1     L4A        gr28=#stack(gr1,64)
   26| 0047C8 mtspr      7C0903A6   1     LCTR      ctr=gr0                                                                                                         0| 004864 lwz        80010058   1     L4A        gr0=#stack(gr1,88)
   26| 0047CC lwz        805D0004   1     CALL      gr3=gr29,2,(*)_object",gr3,(*)void",gr4,#ProcAlias",fcr",(*)int()",gr1,cr[01567]",gr0",gr4"-gr12",fp0"-fp13     0| 004868 lwz        83A10044   1     L4A        gr29=#stack(gr1,68)
   26| 0047D0 bcctrl     4E800421   0                                                                                                                               0| 00486C mtspr      7C0803A6   1     LLR        lr=gr0
   26| 0047D4 lwz        80410014   1                                                                                                                            2056| 004870 addi       38210050   1     AI         gr1=gr1,80
   26| 0047D8 cmpwi      2C030000   1     C4        cr0=gr3,0                                                                                                    2056| 004874 bclr       4E800020   2     BA         lr
   26| 0047DC bc         41820018   1     BT        CL.1819,cr0,0x4/eq,taken=50%(0,0)                                                                               0|                                CL.1876:
    0| 0047E0 lwz        83A10074   2     L4A       gr29=#stack(gr1,116)                                                                                           35| 004878 ori        63830000   1     LR         gr3=gr28
   40| 0047E4 addi       38210080   1     AI        gr1=gr1,128                                                                                                    35| 00487C addi       38881594   1     AI         gr4=gr8,5524
    0| 0047E8 lwz        80010008   1     L4A       gr0=#stack(gr1,8)                                                                                              35| 004880 addi       38A815B0   1     AI         gr5=gr8,5552
    0| 0047EC mtspr      7C0803A6   2     LLR       lr=gr0                                                                                                         35| 004884 addi       38E00806   1     LI         gr7=2054
   40| 0047F0 bclr       4E800020   3     BA        lr                                                                                                             35| 004888 addi       39081580   1     AI         gr8=gr8,5504
    0|                                CL.1819:                                                                                                                     35| 00488C bl         4BFFB775   0     CALL       _PyObject_AssertFailed,6,(*)_object",gr3-gr5,(*)Cuchar",gr6-gr8,#ProcAlias",_PyObject_AssertFailed",fcr",g
   27| 0047F4 addi       38600000   1     LI        gr3=0                                                                                                          35| 004890 ori        60000000   1
    0| 0047F8 lwz        83A10074   1     L4A       gr29=#stack(gr1,116)                                                                                           35| 004894 tw         7C8E7008   1     TRAP       9
   40| 0047FC addi       38210080   1     AI        gr1=gr1,128                                                                                                     0|                                CL.1871:
    0| 004800 lwz        80010008   1     L4A       gr0=#stack(gr1,8)                                                                                               0| 004898 lwz        81020018   1     L4A        gr8=.+CONSTANT_AREA(gr2,0)
    0| 004804 mtspr      7C0803A6   2     LLR       lr=gr0                                                                                                         30| 00489C lwz        801CFFF8   1     L4A        gr0=(*)_object%##2(gr28,-8)
   40| 004808 bclr       4E800020   3     BA        lr                                                                                                             27| 0048A0 addi       38C81110   1     AI         gr6=gr8,4368
    0|                                CL.2233:                                                                                                                     30| 0048A4 cmpwi      2C000000   1     C4         cr0=gr0,0
   27| 00480C addi       38600000   1     LI        gr3=0                                                                                                          30| 0048A8 bc         4182FF30   1     BT         CL.1419,cr0,0x4/eq,taken=50%(0,0)
    0| 004810 lwz        83E1007C   1     L4A       gr31=#stack(gr1,124)                                                                                            0| 0048AC b          4BFFFF0C   1     B          CL.1872,-1
    0| 004814 lwz        83C10078   1     L4A       gr30=#stack(gr1,120)                                                                                            0|                                CL.1875:
    0| 004818 lwz        83A10074   1     L4A       gr29=#stack(gr1,116)                                                                                         2047| 0048B0 addi       38600000   1     LI         gr3=0
   40| 00481C addi       38210080   1     AI        gr1=gr1,128                                                                                                     0| 0048B4 lwz        80010058   1     L4A        gr0=#stack(gr1,88)
    0| 004820 lwz        80010008   1     L4A       gr0=#stack(gr1,8)                                                                                               0| 0048B8 mtspr      7C0803A6   2     LLR        lr=gr0
    0| 004824 mtspr      7C0803A6   2     LLR       lr=gr0                                                                                                       2056| 0048BC addi       38210050   1     AI         gr1=gr1,80
   40| 004828 bclr       4E800020   3     BA        lr                                                                                                           2056| 0048C0 bclr       4E800020   2     BA         lr
    0|                                CL.2224:                                                                                                                       |               Tag Table
    0| 00482C lwz        83E1007C   1     L4A       gr31=#stack(gr1,124)                                                                                             | 0048C4        00000000 00002041 80040200 00000000 000001A4 001A4950
    0| 004830 lwz        83C10078   1     L4A       gr30=#stack(gr1,120)                                                                                             | 0048DC        52412E24 6173796E 635F6765 6E5F6174 68726F77 5F6E6577
    0| 004834 lwz        83A10074   1     L4A       gr29=#stack(gr1,116)                                                                                             |               Instruction count          105
   40| 004838 addi       38210080   1     AI        gr1=gr1,128                                                                                                      |               Straight-line exec time    109
    0| 00483C lwz        80010008   1     L4A       gr0=#stack(gr1,8)                                                                                            GPR's set/used:   ssus ssss ssss s---  ---- ---- ---- ssss
    0| 004840 mtspr      7C0803A6   2     LLR       lr=gr0                                                                                                       FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----
   40| 004844 bclr       4E800020   3     BA        lr                                                                                                           CCR's set/used:   ss-- -sss
    0|                                CL.2232:                                                                                                                       | 000000                             PDEF       IPRA.$async_gen_asend_new
    0| 004848 lwz        83E1007C   1     L4A       gr31=#stack(gr1,124)                                                                                         1652|                                    PROC       gen,sendval,gr3,gr4
    0| 00484C lwz        83C10078   1     L4A       gr30=#stack(gr1,120)                                                                                            0| 004900 mfspr      7C0802A6   1     LFLR       gr0=lr
    0| 004850 lwz        83A10074   1     L4A       gr29=#stack(gr1,116)                                                                                            0| 004904 stwu       9421FFB0   1     ST4U       gr1,#stack(gr1,-80)=gr1
   40| 004854 addi       38210080   1     AI        gr1=gr1,128                                                                                                     0| 004908 stw        90010058   1     ST4A       #stack(gr1,88)=gr0
    0| 004858 lwz        80010008   1     L4A       gr0=#stack(gr1,8)                                                                                               0| 00490C ori        607F0000   1     LR         gr31=gr3
    0| 00485C mtspr      7C0803A6   2     LLR       lr=gr0                                                                                                          0| 004910 stw        93A10044   1     ST4A       #stack(gr1,68)=gr29
   40| 004860 bclr       4E800020   3     BA        lr                                                                                                              0| 004914 ori        609E0000   1     LR         gr30=gr4
    0|                                CL.2231:                                                                                                                      0| 004918 stw        93810040   1     ST4A       #stack(gr1,64)=gr28
   25| 004864 lwz        807F0024   1     L4A       gr3=(*)_err_stackitem._err_stackitem.exc_value(gr31,36)                                                      1655| 00491C lwz        80620020   1     L4A        gr3=.$STATIC(gr2,0)
   25| 004868 cmpwi      2C030000   2     C4        cr0=gr3,0                                                                                                    1655| 004920 lwz        8083000C   2     L4A        gr4=ag_asend_freelist_free(gr3,12)
   25| 00486C bc         4182FF3C   1     BT        CL.1140,cr0,0x4/eq,taken=50%(0,0)                                                                            1655| 004924 cmpwi      2C040000   2     C4         cr0=gr4,0
    0| 004870 b          4BFFFF14   1     B         CL.1816,-1                                                                                                   1655| 004928 bc         4182019C   1     BT         CL.393,cr0,0x4/eq,taken=50%(0,0)
    0|                                CL.2229:                                                                                                                   1657| 00492C lwz        80A20044   1     L4A        gr5=.$STATIC_BSS(gr2,0)
   36| 004874 lwz        807F001C   1     L4A       gr3=(*)aggr#3.gi_qualname(gr31,28)                                                                           1656| 004930 addi       3804FFFF   1     AI         gr0=gr4,-1
   36| 004878 cmpwi      2C030000   2     C4        cr0=gr3,0                                                                                                    1656| 004934 stw        9003000C   1     ST4A       ag_asend_freelist_free(gr3,12)=gr0
   36| 00487C bc         4182FECC   1     BT        CL.369,cr0,0x4/eq,taken=50%(0,0)                                                                             1657| 004938 rlwinm     5403103A   1     SLL4       gr3=gr0,2
    0| 004880 b          4BFFFEA4   1     B         CL.1813,-1                                                                                                   1657| 00493C addi       38850140   1     AI         gr4=gr5,320







Wed Apr 15 07:30:04 CDT 2020  Page 145


    0|                                CL.2227:                                                                                                                   1657| 004940 lwzx       7F84182E   1     L4A        gr28=ag_asend_freelist[]0(gr4,gr3,0)
   34| 004884 lwz        807F0010   1     L4A       gr3=(*)aggr#3.gi_code(gr31,16)                                                                               1658| 004944 ori        63830000   2     LR         gr3=gr28
   34| 004888 cmpwi      2C030000   2     C4        cr0=gr3,0                                                                                                    1658| 004948 bl         4BFFB6B9   0     CALL       _Py_NewReference,1,(*)_object",gr3,#ProcAlias",_Py_NewReference",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-
   34| 00488C bc         4182FE5C   1     BT        CL.359,cr0,0x4/eq,taken=50%(0,0)                                                                             1658| 00494C ori        60000000   1
    0| 004890 b          4BFFFE34   1     B         CL.1810,-1                                                                                                    403| 004950 lwz        809F0000   1     L4A        gr4=(*)_object._object.ob_refcnt(gr31,0)
     |               Tag Table                                                                                                                                    482| 004954 cmpwi      2C1E0000   1     C4         cr0=gr30,0
     | 004894        00000000 00002041 80030300 00000000 00000234 000C6765                                                                                        401| 004958 lwz        80620004   1     L4A        gr3=._Py_RefTotal(gr2,0)
     | 0048AC        6E5F7472 61766572 7365                                                                                                                      1667| 00495C stw        93FC0008   1     ST4A       (*)aggr#D.ags_gen(gr28,8)=gr31
     |               Instruction count          141                                                                                                               403| 004960 addi       38040001   1     AI         gr0=gr4,1
     |               Straight-line exec time    163                                                                                                               403| 004964 stw        901F0000   1     ST4A       (*)_object._object.ob_refcnt(gr31,0)=gr0
 GPR's set/used:   ssus ssss ssss s---  ---- ---- ---- ssss                                                                                                       401| 004968 lwz        80830000   1     L4A        gr4=_Py_RefTotal(gr3,0)
 FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----                                                                                                       401| 00496C addi       38040001   2     AI         gr0=gr4,1
 CCR's set/used:   ss-- -sss                                                                                                                                      401| 004970 stw        90030000   1     ST4A       _Py_RefTotal(gr3,0)=gr0
     | 000000                             PDEF     async_gen_athrow_new                                                                                           482| 004974 bc         41820124   0     BT         CL.2293,cr0,0x4/eq,taken=30%(30,70)
 2042|                                    PROC      gen,args,gr3,gr4                                                                                                0| 004978 lwz        80010058   1     L4A        gr0=#stack(gr1,88)
    0| 0048C0 mfspr      7C0802A6   1     LFLR      gr0=lr                                                                                                          0| 00497C mtspr      7C0803A6   2     LLR        lr=gr0
    0| 0048C4 stw        90010008   2     ST4A      #stack(gr1,8)=gr0                                                                                               0|                                CL.1886:
    0| 0048C8 stw        93E1FFFC   1     ST4A      #stack(gr1,-4)=gr31                                                                                            30| 004980 lwz        80BCFFF8   1     L4A        gr5=(*)_object%##2(gr28,-8)
    0| 0048CC ori        607F0000   1     LR        gr31=gr3                                                                                                        0| 004984 lwz        81020018   1     L4A        gr8=.+CONSTANT_AREA(gr2,0)
    0| 0048D0 stw        93C1FFF8   1     ST4A      #stack(gr1,-8)=gr30                                                                                           401| 004988 addi       38040002   1     AI         gr0=gr4,2
    0| 0048D4 stw        93A1FFF4   1     ST4A      #stack(gr1,-12)=gr29                                                                                         1672| 00498C addi       38C00000   1     LI         gr6=0
    0| 0048D8 ori        609E0000   1     LR        gr30=gr4                                                                                                      403| 004990 lwz        809E0000   1     L4A        gr4=(*)_object._object.ob_refcnt(gr30,0)
    0| 0048DC stw        9381FFF0   1     ST4A      #stack(gr1,-16)=gr28                                                                                         1670| 004994 stw        93DC000C   1     ST4A       (*)aggr#D.ags_sendval(gr28,12)=gr30
 2045| 0048E0 lwz        806200EC   1     L4A       gr3=._PyAsyncGenAThrow_Type(gr2,0)                                                                             30| 004998 cmpwi      2C050000   1     C4         cr0=gr5,0
    0| 0048E4 stwu       9421FFB0   1     ST4U      gr1,#stack(gr1,-80)=gr1                                                                                       403| 00499C addi       38640001   1     AI         gr3=gr4,1
 2045| 0048E8 bl         4BFFB719   0     CALL      gr3=_PyObject_GC_New,1,(*)_typeobject",gr3,#ProcAlias",_PyObject_GC_New",fcr",gr1,cr[01567]",gr0",gr4"-gr12   403| 0049A0 stw        907E0000   1     ST4A       (*)_object._object.ob_refcnt(gr30,0)=gr3
 2045| 0048EC ori        60000000   1                                                                                                                             401| 0049A4 lwz        80620004   1     L4A        gr3=._Py_RefTotal(gr2,0)
 2046| 0048F0 cmpwi      2C030000   1     C4        cr0=gr3,0                                                                                                    1672| 0049A8 stw        90DC0010   1     ST4A       (*)aggr#D.ags_state(gr28,16)=gr6
 2046| 0048F4 bc         41820174   1     BT        CL.1782,cr0,0x4/eq,taken=30%(30,70)                                                                            27| 0049AC addi       38C81110   1     AI         gr6=gr8,4368
  401| 0048F8 lwz        80820004   2     L4A       gr4=._Py_RefTotal(gr2,0)                                                                                      401| 0049B0 stw        90030000   1     ST4A       _Py_RefTotal(gr3,0)=gr0
 2045| 0048FC ori        607C0000   1     LR        gr28=gr3                                                                                                       30| 0049B4 bc         408200C4   0     BF         CL.1888,cr0,0x4/eq,taken=10%(10,90)
  403| 004900 lwz        807F0000   1     L4A       gr3=(*)_object._object.ob_refcnt(gr31,0)                                                                       30|                                CL.1400:
  482| 004904 cmpwi      2C1E0000   1     C4        cr0=gr30,0                                                                                                     34| 0049B8 addi       3BFCFFF8   1     AI         gr31=gr28,-8
  403| 004908 addi       38630001   1     AI        gr3=gr3,1                                                                                                      35| 0049BC lwz        801CFFFC   1     L4A        gr0=(*)aggr#2._gc_prev(gr28,-4)
  403| 00490C stw        907F0000   1     ST4A      (*)_object._object.ob_refcnt(gr31,0)=gr3                                                                       35| 0049C0 andi.      70030002   2     RN4_R      gr3,cr0=gr0,0,0x2
 2049| 004910 stw        93FC0008   1     ST4A      (*)aggr#E.agt_gen(gr28,8)=gr31                                                                                 35| 0049C4 bc         40820094   1     BF         CL.1891,cr0,0x4/eq,taken=10%(10,90)
 2050| 004914 stw        93DC000C   1     ST4A      (*)aggr#E.agt_args(gr28,12)=gr30                                                                               67| 0049C8 lwz        808200A4   1     L4A        gr4=._PyRuntime(gr2,0)
  401| 004918 lwz        80C40000   1     L4A       gr6=<s117:d0:l4>(gr4,0)                                                                                        54| 0049CC lwz        806401A0   2     L4A        gr3=(*)pyruntimestate._Py_atomic_address._value(gr4,416)
  401| 00491C addi       38E60001   2     AI        gr7=gr6,1                                                                                                      41| 0049D0 lwz        80630008   2     L4A        gr3=(*)_ts._ts.interp(gr3,8)
  401| 004920 stw        90E40000   1     ST4A      <s117:d0:l4>(gr4,0)=gr7                                                                                        41| 0049D4 lwz        83C30188   2     L4A        gr30=(*)_is._gc_runtime_state.generation0(gr3,392)
    0| 004924 lwz        80010058   1     L4A       gr0=#stack(gr1,88)                                                                                             42| 0049D8 lwz        83BE0004   2     L4A        gr29=(*)aggr#2._gc_prev(gr30,4)
    0| 004928 mtspr      7C0803A6   2     LLR       lr=gr0                                                                                                         44| 0049DC andi.      73A30003   2     RN4_R      gr3,cr0=gr29,0,0xFFFFFFFF00000003
 2051| 00492C addi       38000000   1     LI        gr0=0                                                                                                          43| 0049E0 stw        93FD0000   1     ST4A       (*)aggr#2._gc_next(gr29,0)=gr31
 2051| 004930 stw        901C0010   1     ST4A      (*)aggr#E.agt_state(gr28,16)=gr0                                                                               44| 0049E4 bc         4082002C   0     BF         CL.2295,cr0,0x4/eq,taken=40%(40,60)
  482| 004934 bc         4182011C   0     BT        CL.1777,cr0,0x4/eq,taken=30%(30,70)                                                                            44| 0049E8 rlwinm     540007BE   1     RN4        gr0=gr0,0,0x3
   30| 004938 lwz        80BCFFF8   1     L4A       gr5=(*)_object%##2(gr28,-8)                                                                                    45| 0049EC stw        93DCFFF8   1     ST4A       (*)aggr#2._gc_next(gr28,-8)=gr30
  401| 00493C addi       38060002   1     AI        gr0=gr6,2                                                                                                      44| 0049F0 or         7C04EB78   1     O          gr4=gr0,gr29
  403| 004940 lwz        807E0000   1     L4A       gr3=(*)_object._object.ob_refcnt(gr30,0)                                                                     1675| 0049F4 ori        63830000   1     LR         gr3=gr28
    0| 004944 lwz        81020018   1     L4A       gr8=.+CONSTANT_AREA(gr2,0)                                                                                     44| 0049F8 stw        909CFFFC   1     ST4A       (*)aggr#2._gc_prev(gr28,-4)=gr4
  401| 004948 stw        90040000   1     ST4A      <s117:d0:l4>(gr4,0)=gr0                                                                                        46| 0049FC stw        93FE0004   1     ST4A       (*)aggr#2._gc_prev(gr30,4)=gr31
   30| 00494C cmpwi      2C050000   1     C4        cr0=gr5,0                                                                                                       0| 004A00 lwz        83810040   1     L4A        gr28=#stack(gr1,64)
  403| 004950 addi       38030001   1     AI        gr0=gr3,1                                                                                                       0| 004A04 lwz        83A10044   1     L4A        gr29=#stack(gr1,68)
  403| 004954 stw        901E0000   1     ST4A      (*)_object._object.ob_refcnt(gr30,0)=gr0                                                                     1676| 004A08 addi       38210050   1     AI         gr1=gr1,80
   27| 004958 addi       38C81110   1     AI        gr6=gr8,4368                                                                                                 1676| 004A0C bclr       4E800020   0     BA         lr
   30| 00495C bc         41820024   0     BT        CL.1419,cr0,0x4/eq,taken=50%(0,0)                                                                               0|                                CL.2295:
    0|                                CL.1778:                                                                                                                     44| 004A10 addi       386815E4   1     AI         gr3=gr8,5604







Wed Apr 15 07:30:04 CDT 2020  Page 146


   30| 004960 ori        63830000   1     LR        gr3=gr28                                                                                                       44| 004A14 addi       38881610   1     AI         gr4=gr8,5648
   30| 004964 addi       38881528   1     AI        gr4=gr8,5416                                                                                                   44| 004A18 addi       38A0002C   1     LI         gr5=44
   30| 004968 addi       38A81550   1     AI        gr5=gr8,5456                                                                                                   44| 004A1C bl         4BFFB5E5   0     CALL       __assert,3,gr3-gr5,#ProcAlias",__assert",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",lr",fcr",xer",
   30| 00496C addi       38E00806   1     LI        gr7=2054                                                                                                       44| 004A20 ori        60000000   1
   30| 004970 addi       39081580   1     AI        gr8=gr8,5504                                                                                                    0| 004A24 lwz        801CFFFC   1     L4A        gr0=(*)aggr#2._gc_prev(gr28,-4)
   30| 004974 bl         4BFFB68D   0     CALL      _PyObject_AssertFailed,6,(*)_object",gr3-gr5,(*)Cuchar",gr6-gr8,#ProcAlias",_PyObject_AssertFailed",fcr",gr    45| 004A28 stw        93DCFFF8   1     ST4A       (*)aggr#2._gc_next(gr28,-8)=gr30
   30| 004978 ori        60000000   1                                                                                                                            1675| 004A2C ori        63830000   1     LR         gr3=gr28
   30| 00497C tw         7C8E7008   1     TRAP      9                                                                                                              44| 004A30 rlwinm     540007BE   1     RN4        gr0=gr0,0,0x3
   30|                                CL.1419:                                                                                                                     44| 004A34 or         7C04EB78   1     O          gr4=gr0,gr29
   34| 004980 addi       3BFCFFF8   1     AI        gr31=gr28,-8                                                                                                   44| 004A38 stw        909CFFFC   1     ST4A       (*)aggr#2._gc_prev(gr28,-4)=gr4
   35| 004984 lwz        801CFFFC   1     L4A       gr0=(*)aggr#2._gc_prev(gr28,-4)                                                                                46| 004A3C stw        93FE0004   1     ST4A       (*)aggr#2._gc_prev(gr30,4)=gr31
   35| 004988 andi.      70030002   2     RN4_R     gr3,cr0=gr0,0,0x2                                                                                               0| 004A40 lwz        83810040   1     L4A        gr28=#stack(gr1,64)
   35| 00498C bc         408200A4   1     BF        CL.1783,cr0,0x4/eq,taken=10%(10,90)                                                                             0| 004A44 lwz        80010058   1     L4A        gr0=#stack(gr1,88)
   67| 004990 lwz        808200A4   1     L4A       gr4=._PyRuntime(gr2,0)                                                                                          0| 004A48 lwz        83A10044   1     L4A        gr29=#stack(gr1,68)
   54| 004994 lwz        806401A0   2     L4A       gr3=<s149:d416:l4>(gr4,416)                                                                                     0| 004A4C mtspr      7C0803A6   1     LLR        lr=gr0
   41| 004998 lwz        80630008   2     L4A       gr3=(*)_ts._ts.interp(gr3,8)                                                                                 1676| 004A50 addi       38210050   1     AI         gr1=gr1,80
   41| 00499C lwz        83C30188   2     L4A       gr30=(*)_is._gc_runtime_state.generation0(gr3,392)                                                           1676| 004A54 bclr       4E800020   2     BA         lr
   42| 0049A0 lwz        83BE0004   2     L4A       gr29=(*)aggr#2._gc_prev(gr30,4)                                                                                 0|                                CL.1891:
   44| 0049A4 andi.      73A30003   2     RN4_R     gr3,cr0=gr29,0,0xFFFFFFFF00000003                                                                              35| 004A58 ori        63830000   1     LR         gr3=gr28
   43| 0049A8 stw        93FD0000   1     ST4A      (*)aggr#2._gc_next(gr29,0)=gr31                                                                                35| 004A5C addi       38881594   1     AI         gr4=gr8,5524
   44| 0049AC bc         40820034   0     BF        CL.2257,cr0,0x4/eq,taken=40%(40,60)                                                                            35| 004A60 addi       38A815B0   1     AI         gr5=gr8,5552
   44| 0049B0 rlwinm     540007BE   1     RN4       gr0=gr0,0,0x3                                                                                                  35| 004A64 addi       38E0068A   1     LI         gr7=1674
   45| 0049B4 stw        93DCFFF8   1     ST4A      (*)aggr#2._gc_next(gr28,-8)=gr30                                                                               35| 004A68 addi       39081580   1     AI         gr8=gr8,5504
   44| 0049B8 or         7C04EB78   1     O         gr4=gr0,gr29                                                                                                   35| 004A6C bl         4BFFB595   0     CALL       _PyObject_AssertFailed,6,(*)_object",gr3-gr5,(*)Cuchar",gr6-gr8,#ProcAlias",_PyObject_AssertFailed",fcr",g
 2055| 0049BC ori        63830000   1     LR        gr3=gr28                                                                                                       35| 004A70 ori        60000000   1
   44| 0049C0 stw        909CFFFC   1     ST4A      (*)aggr#2._gc_prev(gr28,-4)=gr4                                                                                35| 004A74 tw         7C8E7008   1     TRAP       9
   46| 0049C4 stw        93FE0004   1     ST4A      (*)aggr#2._gc_prev(gr30,4)=gr31                                                                                 0|                                CL.1888:
    0| 0049C8 lwz        83810040   1     L4A       gr28=#stack(gr1,64)                                                                                            30| 004A78 ori        63830000   1     LR         gr3=gr28
    0| 0049CC lwz        83A10044   1     L4A       gr29=#stack(gr1,68)                                                                                            30| 004A7C addi       38881528   1     AI         gr4=gr8,5416
 2056| 0049D0 addi       38210050   1     AI        gr1=gr1,80                                                                                                     30| 004A80 addi       38A81550   1     AI         gr5=gr8,5456
    0| 0049D4 lwz        83C1FFF8   1     L4A       gr30=#stack(gr1,-8)                                                                                            30| 004A84 addi       38E0068A   1     LI         gr7=1674
    0| 0049D8 lwz        83E1FFFC   1     L4A       gr31=#stack(gr1,-4)                                                                                            30| 004A88 addi       39081580   1     AI         gr8=gr8,5504
 2056| 0049DC bclr       4E800020   0     BA        lr                                                                                                             30| 004A8C bl         4BFFB575   0     CALL       _PyObject_AssertFailed,6,(*)_object",gr3-gr5,(*)Cuchar",gr6-gr8,#ProcAlias",_PyObject_AssertFailed",fcr",g
    0|                                CL.2257:                                                                                                                     30| 004A90 ori        60000000   1
   44| 0049E0 addi       386815E4   1     AI        gr3=gr8,5604                                                                                                   30| 004A94 tw         7C8E7008   1     TRAP       9
   44| 0049E4 addi       38881610   1     AI        gr4=gr8,5648                                                                                                    0|                                CL.2293:
   44| 0049E8 addi       38A0002C   1     LI        gr5=44                                                                                                          0| 004A98 lwz        80010058   1     L4A        gr0=#stack(gr1,88)
   44| 0049EC bl         4BFFB615   0     CALL      __assert,3,gr3-gr5,#ProcAlias",__assert",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",lr",fcr",xer",f     0| 004A9C mtspr      7C0803A6   2     LLR        lr=gr0
   44| 0049F0 ori        60000000   1                                                                                                                               0|                                CL.1887:
    0| 0049F4 lwz        801CFFFC   1     L4A       gr0=(*)aggr#2._gc_prev(gr28,-4)                                                                                 0| 004AA0 lwz        81020018   1     L4A        gr8=.+CONSTANT_AREA(gr2,0)
   45| 0049F8 stw        93DCFFF8   1     ST4A      (*)aggr#2._gc_next(gr28,-8)=gr30                                                                               30| 004AA4 lwz        807CFFF8   1     L4A        gr3=(*)_object%##2(gr28,-8)
 2055| 0049FC ori        63830000   1     LR        gr3=gr28                                                                                                     1672| 004AA8 addi       38000000   1     LI         gr0=0
   44| 004A00 rlwinm     540007BE   1     RN4       gr0=gr0,0,0x3                                                                                                1670| 004AAC stw        93DC000C   1     ST4A       (*)aggr#D.ags_sendval(gr28,12)=gr30
   44| 004A04 or         7C04EB78   1     O         gr4=gr0,gr29                                                                                                   27| 004AB0 addi       38C81110   1     AI         gr6=gr8,4368
   44| 004A08 stw        909CFFFC   1     ST4A      (*)aggr#2._gc_prev(gr28,-4)=gr4                                                                                30| 004AB4 cmpwi      2C030000   1     C4         cr0=gr3,0
   46| 004A0C stw        93FE0004   1     ST4A      (*)aggr#2._gc_prev(gr30,4)=gr31                                                                              1672| 004AB8 stw        901C0010   1     ST4A       (*)aggr#D.ags_state(gr28,16)=gr0
    0| 004A10 lwz        83810040   1     L4A       gr28=#stack(gr1,64)                                                                                            30| 004ABC bc         4182FEFC   0     BT         CL.1400,cr0,0x4/eq,taken=50%(0,0)
    0| 004A14 lwz        80010058   1     L4A       gr0=#stack(gr1,88)                                                                                              0| 004AC0 b          4BFFFFB8   1     B          CL.1888,-1
    0| 004A18 lwz        83A10044   1     L4A       gr29=#stack(gr1,68)                                                                                          1659|                                CL.393:
 2056| 004A1C addi       38210050   1     AI        gr1=gr1,80                                                                                                   1660| 004AC4 lwz        80620060   1     L4A        gr3=._PyAsyncGenASend_Type(gr2,0)
    0| 004A20 mtspr      7C0803A6   1     LLR       lr=gr0                                                                                                       1660| 004AC8 bl         4BFFB539   0     CALL       gr3=_PyObject_GC_New,1,(*)_typeobject",gr3,#ProcAlias",_PyObject_GC_New",fcr",gr1,cr[01567]",gr0",gr4"-gr1
    0| 004A24 lwz        83C1FFF8   1     L4A       gr30=#stack(gr1,-8)                                                                                          1660| 004ACC ori        60000000   1
    0| 004A28 lwz        83E1FFFC   1     L4A       gr31=#stack(gr1,-4)                                                                                          1661| 004AD0 cmpwi      2C030000   1     C4         cr0=gr3,0
 2056| 004A2C bclr       4E800020   1     BA        lr                                                                                                           1661| 004AD4 bc         4182003C   1     BT         CL.2294,cr0,0x4/eq,taken=30%(30,70)
    0|                                CL.1783:                                                                                                                    403| 004AD8 lwz        809F0000   2     L4A        gr4=(*)_object._object.ob_refcnt(gr31,0)
   35| 004A30 ori        63830000   1     LR        gr3=gr28                                                                                                     1661| 004ADC ori        607C0000   1     LR         gr28=gr3







Wed Apr 15 07:30:04 CDT 2020  Page 147


   35| 004A34 addi       38881594   1     AI        gr4=gr8,5524                                                                                                    0| 004AE0 lwz        80010058   1     L4A        gr0=#stack(gr1,88)
   35| 004A38 addi       38A815B0   1     AI        gr5=gr8,5552                                                                                                  482| 004AE4 cmpwi      2C1E0000   1     C4         cr0=gr30,0
   35| 004A3C addi       38E00806   1     LI        gr7=2054                                                                                                     1667| 004AE8 stw        93E30008   1     ST4A       (*)aggr#D.ags_gen(gr3,8)=gr31
   35| 004A40 addi       39081580   1     AI        gr8=gr8,5504                                                                                                  401| 004AEC lwz        80620004   1     L4A        gr3=._Py_RefTotal(gr2,0)
   35| 004A44 bl         4BFFB5BD   0     CALL      _PyObject_AssertFailed,6,(*)_object",gr3-gr5,(*)Cuchar",gr6-gr8,#ProcAlias",_PyObject_AssertFailed",fcr",gr     0| 004AF0 mtspr      7C0803A6   1     LLR        lr=gr0
   35| 004A48 ori        60000000   1                                                                                                                             403| 004AF4 addi       38040001   1     AI         gr0=gr4,1
   35| 004A4C tw         7C8E7008   1     TRAP      9                                                                                                             403| 004AF8 stw        901F0000   1     ST4A       (*)_object._object.ob_refcnt(gr31,0)=gr0
    0|                                CL.1777:                                                                                                                    401| 004AFC lwz        80830000   1     L4A        gr4=_Py_RefTotal(gr3,0)
    0| 004A50 lwz        81020018   1     L4A       gr8=.+CONSTANT_AREA(gr2,0)                                                                                    401| 004B00 addi       38040001   2     AI         gr0=gr4,1
   30| 004A54 lwz        801CFFF8   1     L4A       gr0=(*)_object%##2(gr28,-8)                                                                                   401| 004B04 stw        90030000   1     ST4A       _Py_RefTotal(gr3,0)=gr0
   27| 004A58 addi       38C81110   1     AI        gr6=gr8,4368                                                                                                  482| 004B08 bc         4182FF98   0     BT         CL.1887,cr0,0x4/eq,taken=30%(30,70)
   30| 004A5C cmpwi      2C000000   1     C4        cr0=gr0,0                                                                                                       0| 004B0C b          4BFFFE74   0     B          CL.1886,-1
   30| 004A60 bc         4182FF20   1     BT        CL.1419,cr0,0x4/eq,taken=50%(0,0)                                                                               0|                                CL.2294:
    0| 004A64 b          4BFFFEFC   1     B         CL.1778,-1                                                                                                   1662| 004B10 addi       38600000   1     LI         gr3=0
    0|                                CL.1782:                                                                                                                      0| 004B14 lwz        80010058   1     L4A        gr0=#stack(gr1,88)
 2047| 004A68 addi       38600000   1     LI        gr3=0                                                                                                           0| 004B18 mtspr      7C0803A6   2     LLR        lr=gr0
    0| 004A6C lwz        80010058   1     L4A       gr0=#stack(gr1,88)                                                                                           1676| 004B1C addi       38210050   1     AI         gr1=gr1,80
 2056| 004A70 addi       38210050   1     AI        gr1=gr1,80                                                                                                   1676| 004B20 bclr       4E800020   2     BA         lr
    0| 004A74 mtspr      7C0803A6   1     LLR       lr=gr0                                                                                                           |               Tag Table
    0| 004A78 lwz        83C1FFF8   1     L4A       gr30=#stack(gr1,-8)                                                                                              | 004B24        00000000 00002041 80040200 00000000 00000224 00194950
    0| 004A7C lwz        83E1FFFC   1     L4A       gr31=#stack(gr1,-4)                                                                                              | 004B3C        52412E24 6173796E 635F6765 6E5F6173 656E645F 6E6577
 2056| 004A80 bclr       4E800020   1     BA        lr                                                                                                               |               Instruction count          137
     |               Tag Table                                                                                                                                       |               Straight-line exec time    142
     | 004A84        00000000 00002041 80040200 00000000 000001C4 00146173                                                                                       GPR's set/used:   ssus ssss ssss s---  ---- ---- ---- -sss
     | 004A9C        796E635F 67656E5F 61746872 6F775F6E 6577                                                                                                    FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----
     |               Instruction count          113                                                                                                              CCR's set/used:   ss-- -sss
     |               Straight-line exec time    115                                                                                                                  | 000000                             PDEF       gen_close
 GPR's set/used:   ssus ssss ssss s---  ---- ---- ---- ssss                                                                                                       359|                                    PROC       gen,args,gr3,gr4
 FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----                                                                                                         0| 004B60 mfspr      7C0802A6   1     LFLR       gr0=lr
 CCR's set/used:   ss-- -sss                                                                                                                                        0| 004B64 stwu       9421FFB0   1     ST4U       gr1,#stack(gr1,-80)=gr1
     | 000000                             PDEF     async_gen_asend_new                                                                                              0| 004B68 stw        90010058   1     ST4A       #stack(gr1,88)=gr0
 1652|                                    PROC      gen,sendval,gr3,gr4                                                                                             0| 004B6C stw        93E1004C   1     ST4A       #stack(gr1,76)=gr31
    0| 004AC0 mfspr      7C0802A6   1     LFLR      gr0=lr                                                                                                          0| 004B70 stw        93C10048   1     ST4A       #stack(gr1,72)=gr30
    0| 004AC4 stw        90010008   2     ST4A      #stack(gr1,8)=gr0                                                                                               0| 004B74 stw        93A10044   1     ST4A       #stack(gr1,68)=gr29
    0| 004AC8 stw        93E1FFFC   1     ST4A      #stack(gr1,-4)=gr31                                                                                             0| 004B78 ori        607D0000   1     LR         gr29=gr3
    0| 004ACC ori        607F0000   1     LR        gr31=gr3                                                                                                      362| 004B7C bl         48000D65   0     CALL       gr3=_PyGen_yf,1,(*)aggr#3",gr3,#ProcAlias",_PyGen_yf",fcr",gr1,cr[01567]",gr0",gr4"-gr12",fp0"-fp13",mq",l
    0| 004AD0 stw        93C1FFF8   1     ST4A      #stack(gr1,-8)=gr30                                                                                           363| 004B80 addi       3BE00000   1     LI         gr31=0
    0| 004AD4 stw        93A1FFF4   1     ST4A      #stack(gr1,-12)=gr29                                                                                          365| 004B84 cmpwi      2C030000   1     C4         cr0=gr3,0
    0| 004AD8 ori        609E0000   1     LR        gr30=gr4                                                                                                      365| 004B88 bc         408201B4   1     BF         CL.2105,cr0,0x4/eq,taken=40%(40,60)
    0| 004ADC stw        9381FFF0   1     ST4A      #stack(gr1,-16)=gr28                                                                                            0|                                CL.1727:
 1655| 004AE0 lwz        80620020   1     L4A       gr3=.$STATIC(gr2,0)                                                                                           371| 004B8C cmpwi      2C1F0000   1     C4         cr0=gr31,0
    0| 004AE4 stwu       9421FF70   1     ST4U      gr1,#stack(gr1,-144)=gr1                                                                                      371| 004B90 bc         41820178   1     BT         CL.1728,cr0,0x4/eq,taken=50%(0,0)
 1655| 004AE8 lwz        8083000C   1     L4A       gr4=ag_asend_freelist_free(gr3,12)                                                                              0|                                CL.1730:
 1655| 004AEC cmpwi      2C040000   2     C4        cr0=gr4,0                                                                                                     373| 004B94 ori        63A30000   1     LR         gr3=gr29
 1655| 004AF0 bc         418201AC   1     BT        CL.393,cr0,0x4/eq,taken=50%(0,0)                                                                              373| 004B98 lwz        83E20008   1     L4A        gr31=._Py_NoneStruct(gr2,0)
 1657| 004AF4 lwz        80A20044   1     L4A       gr5=.$STATIC_BSS(gr2,0)                                                                                       373| 004B9C addi       38A00001   1     LI         gr5=1
 1656| 004AF8 addi       3804FFFF   1     AI        gr0=gr4,-1                                                                                                    373| 004BA0 addi       38C00001   1     LI         gr6=1
 1656| 004AFC stw        9003000C   1     ST4A      ag_asend_freelist_free(gr3,12)=gr0                                                                            373| 004BA4 ori        63E40000   1     LR         gr4=gr31
 1657| 004B00 rlwinm     5403103A   1     SLL4      gr3=gr0,2                                                                                                     373| 004BA8 bl         4BFFEAD9   0     CALL       gr3=gen_send_ex,4,(*)aggr#3",gr3,(*)_object",gr4-gr6,#ProcAlias",gen_send_ex",fcr",gr1,cr[01567]",gr0",gr4
 1657| 004B04 addi       38850140   1     AI        gr4=gr5,320                                                                                                   374| 004BAC cmpwi      2C030000   1     C4         cr0=gr3,0
 1657| 004B08 lwzx       7F84182E   1     L4A       gr28=ag_asend_freelist[]0(gr4,gr3,0)                                                                          374| 004BB0 bc         418200E4   1     BT         CL.2101,cr0,0x4/eq,taken=40%(40,60)
 1658| 004B0C ori        63830000   2     LR        gr3=gr28                                                                                                        0|                                CL.1731:
 1658| 004B10 bl         4BFFB4F1   0     CALL      _Py_NewReference,1,(*)_object",gr3,#ProcAlias",_Py_NewReference",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-f   374| 004BB4 ori        60650000   1     LR         gr5=gr3
 1658| 004B14 ori        60000000   1                                                                                                                             376| 004BB8 lwz        806200D8   1     L4A        gr3=.PyCoro_Type(gr2,0)
  403| 004B18 lwz        809F0000   1     L4A       gr4=(*)_object._object.ob_refcnt(gr31,0)                                                                      415| 004BBC lwz        80820004   1     L4A        gr4=._Py_RefTotal(gr2,0)
  482| 004B1C cmpwi      2C1E0000   1     C4        cr0=gr30,0                                                                                                    128| 004BC0 lwz        801D0004   1     L4A        gr0=(*)C_object._object.ob_type(gr29,4)







Wed Apr 15 07:30:04 CDT 2020  Page 148


  401| 004B20 lwz        80620004   1     L4A       gr3=._Py_RefTotal(gr2,0)                                                                                      378| 004BC4 lwz        810200E0   1     L4A        gr8=.PyAsyncGen_Type(gr2,0)
 1667| 004B24 stw        93FC0008   1     ST4A      (*)aggr#D.ags_gen(gr28,8)=gr31                                                                                375| 004BC8 lwz        80E20018   1     L4A        gr7=.+CONSTANT_AREA(gr2,0)
  403| 004B28 addi       38040001   1     AI        gr0=gr4,1                                                                                                     415| 004BCC ori        60860000   1     LR         gr6=gr4
  403| 004B2C stw        901F0000   1     ST4A      (*)_object._object.ob_refcnt(gr31,0)=gr0                                                                      128| 004BD0 cmplw      7C001840   1     CL4        cr0=gr0,gr3
  401| 004B30 lwz        80830000   1     L4A       gr4=<s117:d0:l4>(gr3,0)                                                                                       417| 004BD4 lwz        81450000   1     L4A        gr10=(*)_object._object.ob_refcnt(gr5,0)
  401| 004B34 addi       38040001   2     AI        gr0=gr4,1                                                                                                     128| 004BD8 cmplw      7C804040   1     CL4        cr1=gr0,gr8
  401| 004B38 stw        90030000   1     ST4A      <s117:d0:l4>(gr3,0)=gr0                                                                                       375| 004BDC addi       3BE70E0C   1     AI         gr31=gr7,3596
  482| 004B3C bc         41820134   0     BT        CL.2252,cr0,0x4/eq,taken=30%(30,70)                                                                           415| 004BE0 lwz        81040000   1     L4A        gr8=_Py_RefTotal(gr4,0)
    0| 004B40 lwz        80010098   1     L4A       gr0=#stack(gr1,152)                                                                                           408| 004BE4 addi       38671110   1     AI         gr3=gr7,4368
    0| 004B44 mtspr      7C0803A6   2     LLR       lr=gr0                                                                                                        415| 004BE8 ori        61090000   1     LR         gr9=gr8
    0|                                CL.1795:                                                                                                                    376| 004BEC bc         4182007C   0     BT         CL.1738,cr0,0x4/eq,taken=50%(0,0)
   30| 004B48 lwz        80BCFFF8   1     L4A       gr5=(*)_object%##2(gr28,-8)                                                                                   379| 004BF0 lwz        80C20020   2     L4A        gr6=.$STATIC(gr2,0)
    0| 004B4C lwz        81020018   1     L4A       gr8=.+CONSTANT_AREA(gr2,0)                                                                                      0| 004BF4 lwz        83A10044   1     L4A        gr29=#stack(gr1,68)
  401| 004B50 addi       38040002   1     AI        gr0=gr4,2                                                                                                     378| 004BF8 bc         40860008   0     BF         CL.1726,cr1,0x4/eq,taken=50%(0,0)
 1672| 004B54 addi       38C00000   1     LI        gr6=0                                                                                                         379| 004BFC lwz        83E60004   2     L4A        gr31=ASYNC_GEN_IGNORED_EXIT_MSG(gr6,4)
  403| 004B58 lwz        809E0000   1     L4A       gr4=(*)_object._object.ob_refcnt(gr30,0)                                                                        0|                                CL.1726:
 1670| 004B5C stw        93DC000C   1     ST4A      (*)aggr#D.ags_sendval(gr28,12)=gr30                                                                           415| 004C00 addi       3808FFFF   1     AI         gr0=gr8,-1
   30| 004B60 cmpwi      2C050000   1     C4        cr0=gr5,0                                                                                                     415| 004C04 stw        90040000   1     ST4A       _Py_RefTotal(gr4,0)=gr0
  403| 004B64 addi       38640001   1     AI        gr3=gr4,1                                                                                                     417| 004C08 addi       388AFFFF   1     AI         gr4=gr10,-1
  403| 004B68 stw        907E0000   1     ST4A      (*)_object._object.ob_refcnt(gr30,0)=gr3                                                                      417| 004C0C stw        90850000   1     ST4A       (*)_object._object.ob_refcnt(gr5,0)=gr4
  401| 004B6C lwz        80620004   1     L4A       gr3=._Py_RefTotal(gr2,0)                                                                                      417| 004C10 cmpwi      2C040000   1     C4         cr0=gr4,0
 1672| 004B70 stw        90DC0010   1     ST4A      (*)aggr#D.ags_state(gr28,16)=gr6                                                                              417| 004C14 bc         41820044   1     BT         CL.1036,cr0,0x4/eq,taken=40%(40,60)
   27| 004B74 addi       38C81110   1     AI        gr6=gr8,4368                                                                                                    0| 004C18 bc         41800030   1     BT         CL.1740,cr0,0x1/lt,taken=40%(40,60)
  401| 004B78 stw        90030000   1     ST4A      <s117:d0:l4>(gr3,0)=gr0                                                                                         0|                                CL.1734:
   30| 004B7C bc         408200D4   0     BF        CL.1797,cr0,0x4/eq,taken=10%(10,90)                                                                           382| 004C1C lwz        8062001C   1     L4A        gr3=.PyExc_RuntimeError(gr2,0)
   30|                                CL.1400:                                                                                                                    382| 004C20 ori        63E40000   1     LR         gr4=gr31
   34| 004B80 addi       3BFCFFF8   1     AI        gr31=gr28,-8                                                                                                  382| 004C24 lwz        80630000   1     L4A        gr3=PyExc_RuntimeError(gr3,0)
   35| 004B84 lwz        801CFFFC   1     L4A       gr0=(*)aggr#2._gc_prev(gr28,-4)                                                                               382| 004C28 bl         4BFFB3D9   0     CALL       PyErr_SetString,2,(*)_object",gr3,(*)Cuchar",gr4,#ProcAlias",PyErr_SetString",fcr",gr1,cr[01567]",gr0",gr3
   35| 004B88 andi.      70030002   2     RN4_R     gr3,cr0=gr0,0,0x2                                                                                             382| 004C2C ori        60000000   1
   35| 004B8C bc         408200A4   1     BF        CL.1800,cr0,0x4/eq,taken=10%(10,90)                                                                           383| 004C30 addi       38600000   1     LI         gr3=0
   67| 004B90 lwz        808200A4   1     L4A       gr4=._PyRuntime(gr2,0)                                                                                        391|                                CL.674:
   54| 004B94 lwz        806401A0   2     L4A       gr3=<s149:d416:l4>(gr4,416)                                                                                     0| 004C34 lwz        83E1004C   1     L4A        gr31=#stack(gr1,76)
   41| 004B98 lwz        80630008   2     L4A       gr3=(*)_ts._ts.interp(gr3,8)                                                                                    0| 004C38 lwz        80010058   1     L4A        gr0=#stack(gr1,88)
   41| 004B9C lwz        83C30188   2     L4A       gr30=(*)_is._gc_runtime_state.generation0(gr3,392)                                                            391| 004C3C addi       38210050   1     AI         gr1=gr1,80
   42| 004BA0 lwz        83BE0004   2     L4A       gr29=(*)aggr#2._gc_prev(gr30,4)                                                                                 0| 004C40 mtspr      7C0803A6   1     LLR        lr=gr0
   44| 004BA4 andi.      73A30003   2     RN4_R     gr3,cr0=gr29,0,0xFFFFFFFF00000003                                                                             391| 004C44 bclr       4E800020   3     BA         lr
   43| 004BA8 stw        93FD0000   1     ST4A      (*)aggr#2._gc_next(gr29,0)=gr31                                                                                 0|                                CL.1740:
   44| 004BAC bc         40820034   0     BF        CL.2254,cr0,0x4/eq,taken=40%(40,60)                                                                           420| 004C48 addi       3880017D   1     LI         gr4=381
   44| 004BB0 rlwinm     540007BE   1     RN4       gr0=gr0,0,0x3                                                                                                 420| 004C4C bl         4BFFB3B5   0     CALL       _Py_NegativeRefcount,3,(*)Cuchar",gr3,gr4,(*)_object",gr5,#ProcAlias",_Py_NegativeRefcount",fcr",gr1,cr[01
   45| 004BB4 stw        93DCFFF8   1     ST4A      (*)aggr#2._gc_next(gr28,-8)=gr30                                                                              420| 004C50 ori        60000000   1
   44| 004BB8 or         7C04EB78   1     O         gr4=gr0,gr29                                                                                                  382| 004C54 b          4BFFFFC8   0     B          CL.1734,-1
 1675| 004BBC ori        63830000   1     LR        gr3=gr28                                                                                                      423|                                CL.1036:
   44| 004BC0 stw        909CFFFC   1     ST4A      (*)aggr#2._gc_prev(gr28,-4)=gr4                                                                               425| 004C58 ori        60A30000   1     LR         gr3=gr5
   46| 004BC4 stw        93FE0004   1     ST4A      (*)aggr#2._gc_prev(gr30,4)=gr31                                                                               425| 004C5C bl         4BFFB3A5   0     CALL       _Py_Dealloc,1,(*)_object",gr3,#ProcAlias",_Py_Dealloc",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",
    0| 004BC8 lwz        83810080   1     L4A       gr28=#stack(gr1,128)                                                                                          425| 004C60 ori        60000000   1
    0| 004BCC lwz        83A10084   1     L4A       gr29=#stack(gr1,132)                                                                                            0| 004C64 b          4BFFFFB8   0     B          CL.1734,-1
 1676| 004BD0 addi       38210090   1     AI        gr1=gr1,144                                                                                                     0|                                CL.1738:
    0| 004BD4 lwz        83C1FFF8   1     L4A       gr30=#stack(gr1,-8)                                                                                           415| 004C68 addi       3809FFFF   1     AI         gr0=gr9,-1
    0| 004BD8 lwz        83E1FFFC   1     L4A       gr31=#stack(gr1,-4)                                                                                           415| 004C6C stw        90060000   1     ST4A       _Py_RefTotal(gr6,0)=gr0
 1676| 004BDC bclr       4E800020   0     BA        lr                                                                                                            417| 004C70 ori        61440000   1     LR         gr4=gr10
    0|                                CL.2254:                                                                                                                    377| 004C74 addi       3BE70E2C   1     AI         gr31=gr7,3628
   44| 004BE0 addi       386815E4   1     AI        gr3=gr8,5604                                                                                                    0| 004C78 lwz        83A10044   1     L4A        gr29=#stack(gr1,68)
   44| 004BE4 addi       38881610   1     AI        gr4=gr8,5648                                                                                                  417| 004C7C addi       3804FFFF   1     AI         gr0=gr4,-1
   44| 004BE8 addi       38A0002C   1     LI        gr5=44                                                                                                        417| 004C80 stw        90050000   1     ST4A       (*)_object._object.ob_refcnt(gr5,0)=gr0
   44| 004BEC bl         4BFFB415   0     CALL      __assert,3,gr3-gr5,#ProcAlias",__assert",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",lr",fcr",xer",f   417| 004C84 cmpwi      2C000000   1     C4         cr0=gr0,0
   44| 004BF0 ori        60000000   1                                                                                                                             417| 004C88 bc         4182FFD0   1     BT         CL.1036,cr0,0x4/eq,taken=40%(40,60)







Wed Apr 15 07:30:04 CDT 2020  Page 149


    0| 004BF4 lwz        801CFFFC   1     L4A       gr0=(*)aggr#2._gc_prev(gr28,-4)                                                                                 0| 004C8C bc         4180FFBC   1     BT         CL.1740,cr0,0x1/lt,taken=40%(40,60)
   45| 004BF8 stw        93DCFFF8   1     ST4A      (*)aggr#2._gc_next(gr28,-8)=gr30                                                                                0| 004C90 b          4BFFFF8C   2     B          CL.1734,-1
 1675| 004BFC ori        63830000   1     LR        gr3=gr28                                                                                                        0|                                CL.2101:
   44| 004C00 rlwinm     540007BE   1     RN4       gr0=gr0,0,0x3                                                                                                 385| 004C94 lwz        8062002C   1     L4A        gr3=.PyExc_StopIteration(gr2,0)
   44| 004C04 or         7C04EB78   1     O         gr4=gr0,gr29                                                                                                    0| 004C98 lwz        83A10044   1     L4A        gr29=#stack(gr1,68)
   44| 004C08 stw        909CFFFC   1     ST4A      (*)aggr#2._gc_prev(gr28,-4)=gr4                                                                               385| 004C9C lwz        80630000   1     L4A        gr3=PyExc_StopIteration(gr3,0)
   46| 004C0C stw        93FE0004   1     ST4A      (*)aggr#2._gc_prev(gr30,4)=gr31                                                                               385| 004CA0 bl         4BFFB361   0     CALL       gr3=PyErr_ExceptionMatches,1,(*)_object",gr3,#ProcAlias",PyErr_ExceptionMatches",fcr",gr1,cr[01567]",gr0",
    0| 004C10 lwz        83810080   1     L4A       gr28=#stack(gr1,128)                                                                                          385| 004CA4 ori        60000000   1
    0| 004C14 lwz        80010098   1     L4A       gr0=#stack(gr1,152)                                                                                           386| 004CA8 lwz        80820028   1     L4A        gr4=.PyExc_GeneratorExit(gr2,0)
    0| 004C18 lwz        83A10084   1     L4A       gr29=#stack(gr1,132)                                                                                          385| 004CAC cmpwi      2C030000   1     C4         cr0=gr3,0
 1676| 004C1C addi       38210090   1     AI        gr1=gr1,144                                                                                                   385| 004CB0 bc         4082001C   1     BF         CL.2107,cr0,0x4/eq,taken=30%(30,70)
    0| 004C20 mtspr      7C0803A6   1     LLR       lr=gr0                                                                                                        386| 004CB4 lwz        80640000   2     L4A        gr3=PyExc_GeneratorExit(gr4,0)
    0| 004C24 lwz        83C1FFF8   1     L4A       gr30=#stack(gr1,-8)                                                                                           386| 004CB8 bl         4BFFB349   0     CALL       gr3=PyErr_ExceptionMatches,1,(*)_object",gr3,#ProcAlias",PyErr_ExceptionMatches",fcr",gr1,cr[01567]",gr0",
    0| 004C28 lwz        83E1FFFC   1     L4A       gr31=#stack(gr1,-4)                                                                                           386| 004CBC ori        60000000   1
 1676| 004C2C bclr       4E800020   1     BA        lr                                                                                                            386| 004CC0 cmpwi      2C030000   1     C4         cr0=gr3,0
    0|                                CL.1800:                                                                                                                    390| 004CC4 addi       38600000   1     LI         gr3=0
   35| 004C30 ori        63830000   1     LR        gr3=gr28                                                                                                      386| 004CC8 bc         4182FF6C   0     BT         CL.674,cr0,0x4/eq,taken=60%(60,40)
   35| 004C34 addi       38881594   1     AI        gr4=gr8,5524                                                                                                    0|                                CL.2107:
   35| 004C38 addi       38A815B0   1     AI        gr5=gr8,5552                                                                                                  387| 004CCC bl         4BFFB335   0     CALL       PyErr_Clear,0,#ProcAlias",PyErr_Clear",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",lr",fcr",xer",fs
   35| 004C3C addi       38E0068A   1     LI        gr7=1674                                                                                                      387| 004CD0 ori        60000000   1
   35| 004C40 addi       39081580   1     AI        gr8=gr8,5504                                                                                                  401| 004CD4 lwz        80A20004   1     L4A        gr5=._Py_RefTotal(gr2,0)
   35| 004C44 bl         4BFFB3BD   0     CALL      _PyObject_AssertFailed,6,(*)_object",gr3-gr5,(*)Cuchar",gr6-gr8,#ProcAlias",_PyObject_AssertFailed",fcr",gr   403| 004CD8 lwz        809F0000   1     L4A        gr4=_Py_NoneStruct%##1(gr31,0)
   35| 004C48 ori        60000000   1                                                                                                                             388| 004CDC lwz        80620008   1     L4A        gr3=._Py_NoneStruct(gr2,0)
   35| 004C4C tw         7C8E7008   1     TRAP      9                                                                                                             403| 004CE0 addi       38040001   1     AI         gr0=gr4,1
    0|                                CL.1797:                                                                                                                    403| 004CE4 stw        901F0000   1     ST4A       _Py_NoneStruct%##1(gr31,0)=gr0
   30| 004C50 ori        63830000   1     LR        gr3=gr28                                                                                                        0| 004CE8 lwz        83E1004C   1     L4A        gr31=#stack(gr1,76)
   30| 004C54 addi       38881528   1     AI        gr4=gr8,5416                                                                                                  401| 004CEC lwz        80850000   1     L4A        gr4=_Py_RefTotal(gr5,0)
   30| 004C58 addi       38A81550   1     AI        gr5=gr8,5456                                                                                                  401| 004CF0 addi       38040001   2     AI         gr0=gr4,1
   30| 004C5C addi       38E0068A   1     LI        gr7=1674                                                                                                      401| 004CF4 stw        90050000   1     ST4A       _Py_RefTotal(gr5,0)=gr0
   30| 004C60 addi       39081580   1     AI        gr8=gr8,5504                                                                                                    0| 004CF8 lwz        80010058   1     L4A        gr0=#stack(gr1,88)
   30| 004C64 bl         4BFFB39D   0     CALL      _PyObject_AssertFailed,6,(*)_object",gr3-gr5,(*)Cuchar",gr6-gr8,#ProcAlias",_PyObject_AssertFailed",fcr",gr   391| 004CFC addi       38210050   1     AI         gr1=gr1,80
   30| 004C68 ori        60000000   1                                                                                                                               0| 004D00 mtspr      7C0803A6   1     LLR        lr=gr0
   30| 004C6C tw         7C8E7008   1     TRAP      9                                                                                                             391| 004D04 bclr       4E800020   3     BA         lr
    0|                                CL.2252:                                                                                                                      0|                                CL.1728:
    0| 004C70 lwz        80010098   1     L4A       gr0=#stack(gr1,152)                                                                                           372| 004D08 lwz        80620028   1     L4A        gr3=.PyExc_GeneratorExit(gr2,0)
    0| 004C74 mtspr      7C0803A6   2     LLR       lr=gr0                                                                                                        372| 004D0C lwz        80630000   2     L4A        gr3=PyExc_GeneratorExit(gr3,0)
    0|                                CL.1796:                                                                                                                    372| 004D10 bl         4BFFB2F1   0     CALL       PyErr_SetNone,1,(*)_object",gr3,#ProcAlias",PyErr_SetNone",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",
    0| 004C78 lwz        81020018   1     L4A       gr8=.+CONSTANT_AREA(gr2,0)                                                                                    372| 004D14 ori        60000000   1
   30| 004C7C lwz        807CFFF8   1     L4A       gr3=(*)_object%##2(gr28,-8)                                                                                   373| 004D18 ori        63A30000   1     LR         gr3=gr29
 1672| 004C80 addi       38000000   1     LI        gr0=0                                                                                                         373| 004D1C lwz        80820008   1     L4A        gr4=._Py_NoneStruct(gr2,0)
 1670| 004C84 stw        93DC000C   1     ST4A      (*)aggr#D.ags_sendval(gr28,12)=gr30                                                                           373| 004D20 addi       38A00001   1     LI         gr5=1
   27| 004C88 addi       38C81110   1     AI        gr6=gr8,4368                                                                                                  373| 004D24 addi       38C00001   1     LI         gr6=1
   30| 004C8C cmpwi      2C030000   1     C4        cr0=gr3,0                                                                                                     373| 004D28 ori        609F0000   1     LR         gr31=gr4
 1672| 004C90 stw        901C0010   1     ST4A      (*)aggr#D.ags_state(gr28,16)=gr0                                                                              373| 004D2C bl         4BFFE955   0     CALL       gr3=gen_send_ex,4,(*)aggr#3",gr3,(*)_object",gr4-gr6,#ProcAlias",gen_send_ex",fcr",gr1,cr[01567]",gr0",gr4
   30| 004C94 bc         4182FEEC   0     BT        CL.1400,cr0,0x4/eq,taken=50%(0,0)                                                                             374| 004D30 cmpwi      2C030000   1     C4         cr0=gr3,0
    0| 004C98 b          4BFFFFB8   1     B         CL.1797,-1                                                                                                    374| 004D34 bc         4082FE80   1     BF         CL.1731,cr0,0x4/eq,taken=60%(60,40)
 1659|                                CL.393:                                                                                                                       0| 004D38 b          4BFFFF5C   1     B          CL.2101,-1
 1660| 004C9C lwz        80620060   1     L4A       gr3=._PyAsyncGenASend_Type(gr2,0)                                                                               0|                                CL.2105:
 1660| 004CA0 bl         4BFFB361   0     CALL      gr3=_PyObject_GC_New,1,(*)_typeobject",gr3,#ProcAlias",_PyObject_GC_New",fcr",gr1,cr[01567]",gr0",gr4"-gr12   365| 004D3C ori        607E0000   1     LR         gr30=gr3
 1660| 004CA4 ori        60000000   1                                                                                                                             366| 004D40 addi       38000001   1     LI         gr0=1
 1661| 004CA8 cmpwi      2C030000   1     C4        cr0=gr3,0                                                                                                     366| 004D44 stb        981D000C   1     ST1Z       (*)aggr#3.gi_running(gr29,12)=gr0
 1661| 004CAC bc         4182003C   1     BT        CL.2253,cr0,0x4/eq,taken=30%(30,70)                                                                           367| 004D48 stw        9381FFF0   1     ST4A       #stack_prune(gr1,-16)=gr28
  403| 004CB0 lwz        809F0000   2     L4A       gr4=(*)_object._object.ob_refcnt(gr31,0)                                                                      367| 004D4C stw        93A1FFF4   1     ST4A       #stack_prune(gr1,-12)=gr29
 1660| 004CB4 ori        607C0000   1     LR        gr28=gr3                                                                                                      367| 004D50 bl         4BFFE531   0     CALL       gr3=IPRA.$gen_close_iter,1,(*)_object",gr3,#ProcAlias",IPRA.$gen_close_iter",fcr",gr1,cr[01567]",gr0",gr4"
    0| 004CB8 lwz        80010098   1     L4A       gr0=#stack(gr1,152)                                                                                           367| 004D54 lwz        83A1FFF4   1     L4A        gr29=#stack_prune(gr1,-12)
  482| 004CBC cmpwi      2C1E0000   1     C4        cr0=gr30,0                                                                                                    367| 004D58 lwz        8381FFF0   1     L4A        gr28=#stack_prune(gr1,-16)







Wed Apr 15 07:30:04 CDT 2020  Page 150


 1667| 004CC0 stw        93E30008   1     ST4A      (*)aggr#D.ags_gen(gr3,8)=gr31                                                                                 368| 004D5C addi       38000000   1     LI         gr0=0
  401| 004CC4 lwz        80620004   1     L4A       gr3=._Py_RefTotal(gr2,0)                                                                                      417| 004D60 lwz        809E0000   1     L4A        gr4=(*)_object._object.ob_refcnt(gr30,0)
    0| 004CC8 mtspr      7C0803A6   1     LLR       lr=gr0                                                                                                        367| 004D64 ori        607F0000   1     LR         gr31=gr3
  403| 004CCC addi       38040001   1     AI        gr0=gr4,1                                                                                                     415| 004D68 lwz        80A20004   1     L4A        gr5=._Py_RefTotal(gr2,0)
  403| 004CD0 stw        901F0000   1     ST4A      (*)_object._object.ob_refcnt(gr31,0)=gr0                                                                        0| 004D6C lwz        80620018   1     L4A        gr3=.+CONSTANT_AREA(gr2,0)
  401| 004CD4 lwz        80830000   1     L4A       gr4=<s117:d0:l4>(gr3,0)                                                                                       417| 004D70 addi       3884FFFF   1     AI         gr4=gr4,-1
  401| 004CD8 addi       38040001   2     AI        gr0=gr4,1                                                                                                     417| 004D74 stw        909E0000   1     ST4A       (*)_object._object.ob_refcnt(gr30,0)=gr4
  401| 004CDC stw        90030000   1     ST4A      <s117:d0:l4>(gr3,0)=gr0                                                                                       408| 004D78 addi       38631110   1     AI         gr3=gr3,4368
  482| 004CE0 bc         4182FF98   0     BT        CL.1796,cr0,0x4/eq,taken=30%(30,70)                                                                           368| 004D7C stb        981D000C   1     ST1Z       (*)aggr#3.gi_running(gr29,12)=gr0
    0| 004CE4 b          4BFFFE64   0     B         CL.1795,-1                                                                                                    415| 004D80 lwz        80C50000   1     L4A        gr6=_Py_RefTotal(gr5,0)
    0|                                CL.2253:                                                                                                                    415| 004D84 addi       3806FFFF   2     AI         gr0=gr6,-1
 1662| 004CE8 addi       38600000   1     LI        gr3=0                                                                                                         417| 004D88 cmpwi      2C040000   1     C4         cr0=gr4,0
    0| 004CEC lwz        80010098   1     L4A       gr0=#stack(gr1,152)                                                                                           415| 004D8C stw        90050000   1     ST4A       _Py_RefTotal(gr5,0)=gr0
 1676| 004CF0 addi       38210090   1     AI        gr1=gr1,144                                                                                                   417| 004D90 bc         41820038   0     BT         CL.1028,cr0,0x4/eq,taken=40%(40,60)
    0| 004CF4 mtspr      7C0803A6   1     LLR       lr=gr0                                                                                                        419| 004D94 bc         4180000C   0     BT         CL.2106,cr0,0x1/lt,taken=40%(40,60)
    0| 004CF8 lwz        83C1FFF8   1     L4A       gr30=#stack(gr1,-8)                                                                                             0| 004D98 lwz        83C10048   2     L4A        gr30=#stack(gr1,72)
    0| 004CFC lwz        83E1FFFC   1     L4A       gr31=#stack(gr1,-4)                                                                                             0| 004D9C b          4BFFFDF0   0     B          CL.1727,-1
 1676| 004D00 bclr       4E800020   1     BA        lr                                                                                                              0|                                CL.2106:
     |               Tag Table                                                                                                                                    420| 004DA0 addi       38800171   1     LI         gr4=369
     | 004D04        00000000 00002041 80040200 00000000 00000244 00136173                                                                                        420| 004DA4 ori        63C50000   1     LR         gr5=gr30
     | 004D1C        796E635F 67656E5F 6173656E 645F6E65 77                                                                                                       420| 004DA8 bl         4BFFB259   0     CALL       _Py_NegativeRefcount,3,(*)Cuchar",gr3,gr4,(*)_object",gr5,#ProcAlias",_Py_NegativeRefcount",fcr",gr1,cr[01
     |               Instruction count          145                                                                                                               420| 004DAC ori        60000000   1
     |               Straight-line exec time    147                                                                                                               371| 004DB0 cmpwi      2C1F0000   1     C4         cr0=gr31,0
 GPR's set/used:   ssus ssss ssss s---  ---- ---- ---- -sss                                                                                                       371| 004DB4 bc         4082000C   1     BF         CL.2104,cr0,0x4/eq,taken=40%(40,60)
 FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----                                                                                                         0| 004DB8 lwz        83C10048   2     L4A        gr30=#stack(gr1,72)
 CCR's set/used:   ss-- -sss                                                                                                                                        0| 004DBC b          4BFFFF4C   0     B          CL.1728,-1
     | 000000                             PDEF     gen_close                                                                                                        0|                                CL.2104:
  359|                                    PROC      gen,args,gr3,gr4                                                                                                0| 004DC0 lwz        83C10048   1     L4A        gr30=#stack(gr1,72)
    0| 004D40 mfspr      7C0802A6   1     LFLR      gr0=lr                                                                                                          0| 004DC4 b          4BFFFDD0   0     B          CL.1730,-1
    0| 004D44 stw        90010008   2     ST4A      #stack(gr1,8)=gr0                                                                                             423|                                CL.1028:
    0| 004D48 stw        93E1FFFC   1     ST4A      #stack(gr1,-4)=gr31                                                                                           425| 004DC8 ori        63C30000   1     LR         gr3=gr30
    0| 004D4C stw        93C1FFF8   1     ST4A      #stack(gr1,-8)=gr30                                                                                           425| 004DCC bl         4BFFB235   0     CALL       _Py_Dealloc,1,(*)_object",gr3,#ProcAlias",_Py_Dealloc",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",
    0| 004D50 stw        93A1FFF4   1     ST4A      #stack(gr1,-12)=gr29                                                                                          425| 004DD0 ori        60000000   1
    0| 004D54 ori        607D0000   1     LR        gr29=gr3                                                                                                        0| 004DD4 lwz        83C10048   1     L4A        gr30=#stack(gr1,72)
    0| 004D58 stwu       9421FFB0   1     ST4U      gr1,#stack(gr1,-80)=gr1                                                                                         0| 004DD8 b          4BFFFDB4   0     B          CL.1727,-1
  362| 004D5C bl         48000CA5   0     CALL      gr3=_PyGen_yf,1,(*)aggr#3",gr3,#ProcAlias",_PyGen_yf",fcr",gr1,cr[01567]",gr0",gr4"-gr12",fp0"-fp13",mq",lr      |               Tag Table
  363| 004D60 addi       3BE00000   1     LI        gr31=0                                                                                                           | 004DDC        00000000 00002041 80030200 00000000 0000027C 00096765
  365| 004D64 cmpwi      2C030000   1     C4        cr0=gr3,0                                                                                                        | 004DF4        6E5F636C 6F7365
  365| 004D68 bc         408201DC   1     BF        CL.2055,cr0,0x4/eq,taken=40%(40,60)                                                                              |               Instruction count          159
    0|                                CL.1602:                                                                                                                       |               Straight-line exec time    148
  371| 004D6C cmpwi      2C1F0000   1     C4        cr0=gr31,0                                                                                                   GPR's set/used:   ssus ssss ssss s---  ---- ---- ---s ssss
  371| 004D70 bc         418201A0   1     BT        CL.1603,cr0,0x4/eq,taken=50%(0,0)                                                                            FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----
    0|                                CL.1605:                                                                                                                   CCR's set/used:   ss-- -sss
  373| 004D74 ori        63A30000   1     LR        gr3=gr29                                                                                                         | 000000                             PDEF       PyAsyncGen_ClearFreeLists
  373| 004D78 lwz        83E20008   1     L4A       gr31=._Py_NoneStruct(gr2,0)                                                                                  1433|                                    PROC
  373| 004D7C addi       38A00001   1     LI        gr5=1                                                                                                           0| 004E00 mfspr      7C0802A6   1     LFLR       gr0=lr
  373| 004D80 addi       38C00001   1     LI        gr6=1                                                                                                           0| 004E04 stwu       9421FFB0   1     ST4U       gr1,#stack(gr1,-80)=gr1
  373| 004D84 ori        63E40000   1     LR        gr4=gr31                                                                                                        0| 004E08 stw        90010058   1     ST4A       #stack(gr1,88)=gr0
  373| 004D88 bl         4BFFEAD9   0     CALL      gr3=gen_send_ex,4,(*)aggr#3",gr3,(*)_object",gr4-gr6,#ProcAlias",gen_send_ex",fcr",gr1,cr[01567]",gr0",gr4"     0| 004E0C stw        93E1004C   1     ST4A       #stack(gr1,76)=gr31
  374| 004D8C cmpwi      2C030000   1     C4        cr0=gr3,0                                                                                                       0| 004E10 stw        93C10048   1     ST4A       #stack(gr1,72)=gr30
  374| 004D90 bc         4182010C   1     BT        CL.2051,cr0,0x4/eq,taken=40%(40,60)                                                                             0| 004E14 stw        93A10044   1     ST4A       #stack(gr1,68)=gr29
    0|                                CL.1606:                                                                                                                      0| 004E18 stw        93810040   1     ST4A       #stack(gr1,64)=gr28
  373| 004D94 ori        60650000   1     LR        gr5=gr3                                                                                                         0| 004E1C stw        9361003C   1     ST4A       #stack(gr1,60)=gr27
  376| 004D98 lwz        812200D8   1     L4A       gr9=.PyCoro_Type(gr2,0)                                                                                      1435| 004E20 lwz        83E20020   1     L4A        gr31=.$STATIC(gr2,0)
  415| 004D9C lwz        80820004   1     L4A       gr4=._Py_RefTotal(gr2,0)                                                                                     1435| 004E24 lwz        807F0008   2     L4A        gr3=ag_value_freelist_free(gr31,8)
  128| 004DA0 lwz        801D0004   1     L4A       gr0=(*)C_object._object.ob_type(gr29,4)                                                                      1435| 004E28 lwz        809F000C   1     L4A        gr4=ag_asend_freelist_free(gr31,12)







Wed Apr 15 07:30:04 CDT 2020  Page 151


  378| 004DA4 lwz        810200E0   1     L4A       gr8=.PyAsyncGen_Type(gr2,0)                                                                                  1435| 004E2C add        7F632214   2     A          gr27=gr3,gr4
  375| 004DA8 lwz        80E20018   1     L4A       gr7=.+CONSTANT_AREA(gr2,0)                                                                                   1437| 004E30 cmpwi      2C030000   1     C4         cr0=gr3,0
  415| 004DAC ori        60860000   1     LR        gr6=gr4                                                                                                      1437| 004E34 bc         418201CC   1     BT         CL.1845,cr0,0x4/eq,taken=50%(0,0)
  417| 004DB0 lwz        81430000   1     L4A       gr10=(*)_object._object.ob_refcnt(gr3,0)                                                                        0| 004E38 lwz        83C20044   1     L4A        gr30=.$STATIC_BSS(gr2,0)
  128| 004DB4 cmplw      7C004840   1     CL4       cr0=gr0,gr9                                                                                                  1439| 004E3C addi       3803FFFF   1     AI         gr0=gr3,-1
  128| 004DB8 cmplw      7C804040   1     CL4       cr1=gr0,gr8                                                                                                     0| 004E40 lwz        83A20018   1     L4A        gr29=.+CONSTANT_AREA(gr2,0)
  375| 004DBC addi       3BE70E0C   1     AI        gr31=gr7,3596                                                                                                1440| 004E44 addi       38A005A0   1     LI         gr5=1440
  415| 004DC0 lwz        81040000   1     L4A       gr8=<s117:d0:l4>(gr4,0)                                                                                      1439| 004E48 stw        901F0008   1     ST4A       ag_value_freelist_free(gr31,8)=gr0
  415| 004DC4 ori        61090000   2     LR        gr9=gr8                                                                                                      1439| 004E4C rlwinm     5406103A   1     SLL4       gr6=gr0,2
  376| 004DC8 bc         418200AC   0     BT        CL.1613,cr0,0x4/eq,taken=50%(0,0)                                                                            1440| 004E50 addi       387D1450   1     AI         gr3=gr29,5200
  379| 004DCC lwz        80C20020   1     L4A       gr6=.$STATIC(gr2,0)                                                                                          1440| 004E54 addi       389D1110   1     AI         gr4=gr29,4368
    0| 004DD0 lwz        83A10044   1     L4A       gr29=#stack(gr1,68)                                                                                          1439| 004E58 lwzx       7F9E302E   1     L4A        gr28=ag_value_freelist[]0(gr30,gr6,0)
  378| 004DD4 bc         40860008   0     BF        CL.1607,cr1,0x4/eq,taken=50%(0,0)                                                                             128| 004E5C lwz        80C20014   1     L4A        gr6=._PyAsyncGenWrappedValue_Type(gr2,0)
  379| 004DD8 lwz        83E60004   2     L4A       gr31=ASYNC_GEN_IGNORED_EXIT_MSG(gr6,4)                                                                        128| 004E60 lwz        801C0004   1     L4A        gr0=(*)C_object._object.ob_type(gr28,4)
    0|                                CL.1607:                                                                                                                    128| 004E64 cmplw      7C003040   2     CL4        cr0=gr0,gr6
  415| 004DDC addi       3808FFFF   1     AI        gr0=gr8,-1                                                                                                   1440| 004E68 bc         40820048   1     BF         CL.1848,cr0,0x4/eq,taken=50%(0,0)
  415| 004DE0 stw        90040000   1     ST4A      <s117:d0:l4>(gr4,0)=gr0                                                                                         0|                                CL.2307:
  417| 004DE4 addi       388AFFFF   1     AI        gr4=gr10,-1                                                                                                  1441| 004E6C ori        63830000   1     LR         gr3=gr28
  417| 004DE8 stw        90850000   1     ST4A      (*)_object._object.ob_refcnt(gr5,0)=gr4                                                                      1441| 004E70 bl         4BFFB191   0     CALL       PyObject_GC_Del,1,(*)void",gr3,#ProcAlias",PyObject_GC_Del",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13"
  417| 004DEC cmpwi      2C040000   1     C4        cr0=gr4,0                                                                                                    1441| 004E74 ori        60000000   1
  417| 004DF0 bc         41820074   1     BT        CL.1036,cr0,0x4/eq,taken=40%(40,60)                                                                          1437| 004E78 lwz        807F0008   1     L4A        gr3=ag_value_freelist_free(gr31,8)
    0|                                CL.1608:                                                                                                                   1437| 004E7C cmpwi      2C030000   2     C4         cr0=gr3,0
  420| 004DF4 addi       38671110   1     AI        gr3=gr7,4368                                                                                                 1437| 004E80 bc         41820080   1     BT         CL.1843,cr0,0x4/eq,taken=20%(20,80)
  419| 004DF8 cmpwi      2C040000   1     C4        cr0=gr4,0                                                                                                    1440| 004E84 addi       389D1110   1     AI         gr4=gr29,4368
  420| 004DFC addi       3880017D   1     LI        gr4=381                                                                                                      1439| 004E88 addi       3803FFFF   1     AI         gr0=gr3,-1
  419| 004E00 bc         40800038   0     BF        CL.2057,cr0,0x1/lt,taken=30%(30,70)                                                                          1439| 004E8C stw        901F0008   1     ST4A       ag_value_freelist_free(gr31,8)=gr0
  420| 004E04 bl         4BFFB1FD   1     CALL      _Py_NegativeRefcount,3,(*)Cuchar",gr3,gr4,(*)_object",gr5,#ProcAlias",_Py_NegativeRefcount",fcr",gr1,cr[015  1440| 004E90 addi       387D1450   1     AI         gr3=gr29,5200
  420| 004E08 ori        60000000   1                                                                                                                            1439| 004E94 rlwinm     5406103A   1     SLL4       gr6=gr0,2
    0|                                CL.1609:                                                                                                                   1440| 004E98 addi       38A005A0   1     LI         gr5=1440
  382| 004E0C lwz        8062001C   1     L4A       gr3=.PyExc_RuntimeError(gr2,0)                                                                               1439| 004E9C lwzx       7F9E302E   1     L4A        gr28=ag_value_freelist[]0(gr30,gr6,0)
  382| 004E10 ori        63E40000   1     LR        gr4=gr31                                                                                                      128| 004EA0 lwz        80C20014   1     L4A        gr6=._PyAsyncGenWrappedValue_Type(gr2,0)
  382| 004E14 lwz        80630000   1     L4A       gr3=<s143:d0:l4>(gr3,0)                                                                                       128| 004EA4 lwz        801C0004   1     L4A        gr0=(*)C_object._object.ob_type(gr28,4)
  382| 004E18 bl         4BFFB1E9   0     CALL      PyErr_SetString,2,(*)_object",gr3,(*)Cuchar",gr4,#ProcAlias",PyErr_SetString",fcr",gr1,cr[01567]",gr0",gr3"   128| 004EA8 cmplw      7C003040   2     CL4        cr0=gr0,gr6
  382| 004E1C ori        60000000   1                                                                                                                               0| 004EAC bc         4182FFC0   1     BT         CL.2307,cr0,0x4/eq,taken=50%(0,0)
  383| 004E20 addi       38600000   1     LI        gr3=0                                                                                                           0|                                CL.1848:
  391|                                CL.674:                                                                                                                    1440| 004EB0 bl         4BFFB151   0     CALL       __assert,3,gr3-gr5,#ProcAlias",__assert",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",lr",fcr",xer",
  391| 004E24 addi       38210050   1     AI        gr1=gr1,80                                                                                                   1440| 004EB4 ori        60000000   1
    0| 004E28 lwz        83E1FFFC   1     L4A       gr31=#stack(gr1,-4)                                                                                          1441| 004EB8 ori        63830000   1     LR         gr3=gr28
    0| 004E2C lwz        80010008   1     L4A       gr0=#stack(gr1,8)                                                                                            1441| 004EBC bl         4BFFB145   0     CALL       PyObject_GC_Del,1,(*)void",gr3,#ProcAlias",PyObject_GC_Del",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13"
    0| 004E30 mtspr      7C0803A6   2     LLR       lr=gr0                                                                                                       1441| 004EC0 ori        60000000   1
  391| 004E34 bclr       4E800020   3     BA        lr                                                                                                           1437| 004EC4 lwz        807F0008   1     L4A        gr3=ag_value_freelist_free(gr31,8)
    0|                                CL.2057:                                                                                                                   1437| 004EC8 cmpwi      2C030000   2     C4         cr0=gr3,0
  382| 004E38 lwz        80A2001C   1     L4A       gr5=.PyExc_RuntimeError(gr2,0)                                                                               1437| 004ECC bc         41820034   1     BT         CL.1843,cr0,0x4/eq,taken=20%(20,80)
  382| 004E3C ori        63E40000   1     LR        gr4=gr31                                                                                                     1440| 004ED0 addi       389D1110   1     AI         gr4=gr29,4368
  382| 004E40 lwz        80650000   1     L4A       gr3=<s143:d0:l4>(gr5,0)                                                                                      1439| 004ED4 addi       3803FFFF   1     AI         gr0=gr3,-1
  382| 004E44 bl         4BFFB1BD   0     CALL      PyErr_SetString,2,(*)_object",gr3,(*)Cuchar",gr4,#ProcAlias",PyErr_SetString",fcr",gr1,cr[01567]",gr0",gr3"  1439| 004ED8 stw        901F0008   1     ST4A       ag_value_freelist_free(gr31,8)=gr0
  382| 004E48 ori        60000000   1                                                                                                                            1440| 004EDC addi       387D1450   1     AI         gr3=gr29,5200
  383| 004E4C addi       38600000   1     LI        gr3=0                                                                                                        1439| 004EE0 rlwinm     5406103A   1     SLL4       gr6=gr0,2
  391| 004E50 addi       38210050   1     AI        gr1=gr1,80                                                                                                   1440| 004EE4 addi       38A005A0   1     LI         gr5=1440
    0| 004E54 lwz        83E1FFFC   1     L4A       gr31=#stack(gr1,-4)                                                                                          1439| 004EE8 lwzx       7F9E302E   1     L4A        gr28=ag_value_freelist[]0(gr30,gr6,0)
    0| 004E58 lwz        80010008   1     L4A       gr0=#stack(gr1,8)                                                                                             128| 004EEC lwz        80C20014   1     L4A        gr6=._PyAsyncGenWrappedValue_Type(gr2,0)
    0| 004E5C mtspr      7C0803A6   2     LLR       lr=gr0                                                                                                        128| 004EF0 lwz        801C0004   1     L4A        gr0=(*)C_object._object.ob_type(gr28,4)
  391| 004E60 bclr       4E800020   3     BA        lr                                                                                                            128| 004EF4 cmplw      7C003040   2     CL4        cr0=gr0,gr6
  423|                                CL.1036:                                                                                                                      0| 004EF8 bc         4082FFB8   1     BF         CL.1848,cr0,0x4/eq,taken=50%(0,0)
  425| 004E64 ori        60A30000   1     LR        gr3=gr5                                                                                                         0| 004EFC b          4BFFFF70   1     B          CL.2307,-1
  425| 004E68 bl         4BFFB199   0     CALL      _Py_Dealloc,1,(*)_object",gr3,#ProcAlias",_Py_Dealloc",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",l     0|                                CL.1843:







Wed Apr 15 07:30:04 CDT 2020  Page 152


  425| 004E6C ori        60000000   1                                                                                                                               0| 004F00 lwz        809F000C   1     L4A        gr4=ag_asend_freelist_free(gr31,12)
    0| 004E70 b          4BFFFF9C   0     B         CL.1609,-1                                                                                                   1444| 004F04 cmpwi      2C040000   2     C4         cr0=gr4,0
    0|                                CL.1613:                                                                                                                   1444| 004F08 bc         418200D0   1     BT         CL.2310,cr0,0x4/eq,taken=20%(20,80)
  415| 004E74 addi       3809FFFF   1     AI        gr0=gr9,-1                                                                                                      0|                                CL.1846:
  415| 004E78 stw        90060000   1     ST4A      <s117:d0:l4>(gr6,0)=gr0                                                                                         0| 004F0C lwz        80620044   1     L4A        gr3=.$STATIC_BSS(gr2,0)
  417| 004E7C ori        61440000   1     LR        gr4=gr10                                                                                                     1446| 004F10 addi       3804FFFF   1     AI         gr0=gr4,-1
  377| 004E80 addi       3BE70E2C   1     AI        gr31=gr7,3628                                                                                                1447| 004F14 addi       38A005A7   1     LI         gr5=1447
    0| 004E84 lwz        83A10044   1     L4A       gr29=#stack(gr1,68)                                                                                             0| 004F18 lwz        83C20018   1     L4A        gr30=.+CONSTANT_AREA(gr2,0)
  417| 004E88 addi       3884FFFF   1     AI        gr4=gr4,-1                                                                                                   1446| 004F1C stw        901F000C   1     ST4A       ag_asend_freelist_free(gr31,12)=gr0
  417| 004E8C stw        90850000   1     ST4A      (*)_object._object.ob_refcnt(gr5,0)=gr4                                                                      1446| 004F20 rlwinm     5406103A   1     SLL4       gr6=gr0,2
  417| 004E90 cmpwi      2C040000   1     C4        cr0=gr4,0                                                                                                    1446| 004F24 addi       3BA30140   1     AI         gr29=gr3,320
  417| 004E94 bc         4182FFD0   1     BT        CL.1036,cr0,0x4/eq,taken=40%(40,60)                                                                          1447| 004F28 addi       387E1500   1     AI         gr3=gr30,5376
    0| 004E98 b          4BFFFF5C   1     B         CL.1608,-1                                                                                                   1447| 004F2C addi       389E1110   1     AI         gr4=gr30,4368
    0|                                CL.2051:                                                                                                                   1446| 004F30 lwzx       7F9D302E   1     L4A        gr28=ag_asend_freelist[]0(gr29,gr6,0)
  385| 004E9C lwz        8062002C   1     L4A       gr3=.PyExc_StopIteration(gr2,0)                                                                               128| 004F34 lwz        80C20060   1     L4A        gr6=._PyAsyncGenASend_Type(gr2,0)
    0| 004EA0 lwz        83A10044   1     L4A       gr29=#stack(gr1,68)                                                                                           128| 004F38 lwz        801C0004   1     L4A        gr0=(*)C_object._object.ob_type(gr28,4)
  385| 004EA4 lwz        80630000   1     L4A       gr3=<s139:d0:l4>(gr3,0)                                                                                       128| 004F3C cmplw      7C003040   2     CL4        cr0=gr0,gr6
  385| 004EA8 bl         4BFFB159   0     CALL      gr3=PyErr_ExceptionMatches,1,(*)_object",gr3,#ProcAlias",PyErr_ExceptionMatches",fcr",gr1,cr[01567]",gr0",g  1447| 004F40 bc         40820048   1     BF         CL.1849,cr0,0x4/eq,taken=50%(0,0)
  385| 004EAC ori        60000000   1                                                                                                                               0|                                CL.2308:
  386| 004EB0 lwz        80820028   1     L4A       gr4=.PyExc_GeneratorExit(gr2,0)                                                                              1448| 004F44 ori        63830000   1     LR         gr3=gr28
  385| 004EB4 cmpwi      2C030000   1     C4        cr0=gr3,0                                                                                                    1448| 004F48 bl         4BFFB0B9   0     CALL       PyObject_GC_Del,1,(*)void",gr3,#ProcAlias",PyObject_GC_Del",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13"
  385| 004EB8 bc         4082001C   1     BF        CL.2058,cr0,0x4/eq,taken=30%(30,70)                                                                          1448| 004F4C ori        60000000   1
  386| 004EBC lwz        80640000   2     L4A       gr3=<s141:d0:l4>(gr4,0)                                                                                      1444| 004F50 lwz        809F000C   1     L4A        gr4=ag_asend_freelist_free(gr31,12)
  386| 004EC0 bl         4BFFB141   0     CALL      gr3=PyErr_ExceptionMatches,1,(*)_object",gr3,#ProcAlias",PyErr_ExceptionMatches",fcr",gr1,cr[01567]",gr0",g  1444| 004F54 cmpwi      2C040000   2     C4         cr0=gr4,0
  386| 004EC4 ori        60000000   1                                                                                                                            1444| 004F58 bc         41820080   1     BT         CL.2310,cr0,0x4/eq,taken=20%(20,80)
  386| 004EC8 cmpwi      2C030000   1     C4        cr0=gr3,0                                                                                                    1447| 004F5C addi       387E1500   1     AI         gr3=gr30,5376
  390| 004ECC addi       38600000   1     LI        gr3=0                                                                                                        1446| 004F60 addi       3804FFFF   1     AI         gr0=gr4,-1
  386| 004ED0 bc         4182FF54   0     BT        CL.674,cr0,0x4/eq,taken=60%(60,40)                                                                           1446| 004F64 stw        901F000C   1     ST4A       ag_asend_freelist_free(gr31,12)=gr0
    0|                                CL.2058:                                                                                                                   1447| 004F68 addi       389E1110   1     AI         gr4=gr30,4368
  387| 004ED4 bl         4BFFB12D   0     CALL      PyErr_Clear,0,#ProcAlias",PyErr_Clear",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",lr",fcr",xer",fsr  1446| 004F6C rlwinm     5406103A   1     SLL4       gr6=gr0,2
  387| 004ED8 ori        60000000   1                                                                                                                            1447| 004F70 addi       38A005A7   1     LI         gr5=1447
  401| 004EDC lwz        80A20004   1     L4A       gr5=._Py_RefTotal(gr2,0)                                                                                     1446| 004F74 lwzx       7F9D302E   1     L4A        gr28=ag_asend_freelist[]0(gr29,gr6,0)
  403| 004EE0 lwz        809F0000   1     L4A       gr4=<s119:d0:l4>(gr31,0)                                                                                      128| 004F78 lwz        80C20060   1     L4A        gr6=._PyAsyncGenASend_Type(gr2,0)
  391| 004EE4 addi       38210050   1     AI        gr1=gr1,80                                                                                                    128| 004F7C lwz        801C0004   1     L4A        gr0=(*)C_object._object.ob_type(gr28,4)
  388| 004EE8 lwz        80620008   1     L4A       gr3=._Py_NoneStruct(gr2,0)                                                                                    128| 004F80 cmplw      7C003040   2     CL4        cr0=gr0,gr6
  403| 004EEC addi       38040001   1     AI        gr0=gr4,1                                                                                                       0| 004F84 bc         4182FFC0   1     BT         CL.2308,cr0,0x4/eq,taken=50%(0,0)
  403| 004EF0 stw        901F0000   1     ST4A      <s119:d0:l4>(gr31,0)=gr0                                                                                        0|                                CL.1849:
    0| 004EF4 lwz        83E1FFFC   1     L4A       gr31=#stack(gr1,-4)                                                                                          1447| 004F88 bl         4BFFB079   0     CALL       __assert,3,gr3-gr5,#ProcAlias",__assert",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",lr",fcr",xer",
  401| 004EF8 lwz        80850000   1     L4A       gr4=<s117:d0:l4>(gr5,0)                                                                                      1447| 004F8C ori        60000000   1
  401| 004EFC addi       38040001   2     AI        gr0=gr4,1                                                                                                    1448| 004F90 ori        63830000   1     LR         gr3=gr28
  401| 004F00 stw        90050000   1     ST4A      <s117:d0:l4>(gr5,0)=gr0                                                                                      1448| 004F94 bl         4BFFB06D   0     CALL       PyObject_GC_Del,1,(*)void",gr3,#ProcAlias",PyObject_GC_Del",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13"
    0| 004F04 lwz        80010008   1     L4A       gr0=#stack(gr1,8)                                                                                            1448| 004F98 ori        60000000   1
    0| 004F08 mtspr      7C0803A6   2     LLR       lr=gr0                                                                                                       1444| 004F9C lwz        809F000C   1     L4A        gr4=ag_asend_freelist_free(gr31,12)
  391| 004F0C bclr       4E800020   3     BA        lr                                                                                                           1444| 004FA0 cmpwi      2C040000   2     C4         cr0=gr4,0
    0|                                CL.1603:                                                                                                                   1444| 004FA4 bc         41820034   1     BT         CL.2310,cr0,0x4/eq,taken=20%(20,80)
  372| 004F10 lwz        80620028   1     L4A       gr3=.PyExc_GeneratorExit(gr2,0)                                                                              1447| 004FA8 addi       387E1500   1     AI         gr3=gr30,5376
  372| 004F14 lwz        80630000   2     L4A       gr3=<s141:d0:l4>(gr3,0)                                                                                      1446| 004FAC addi       3804FFFF   1     AI         gr0=gr4,-1
  372| 004F18 bl         4BFFB0E9   0     CALL      PyErr_SetNone,1,(*)_object",gr3,#ProcAlias",PyErr_SetNone",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",m  1446| 004FB0 stw        901F000C   1     ST4A       ag_asend_freelist_free(gr31,12)=gr0
  372| 004F1C ori        60000000   1                                                                                                                            1447| 004FB4 addi       389E1110   1     AI         gr4=gr30,4368
  373| 004F20 ori        63A30000   1     LR        gr3=gr29                                                                                                     1446| 004FB8 rlwinm     5406103A   1     SLL4       gr6=gr0,2
  373| 004F24 lwz        80820008   1     L4A       gr4=._Py_NoneStruct(gr2,0)                                                                                   1447| 004FBC addi       38A005A7   1     LI         gr5=1447
  373| 004F28 addi       38A00001   1     LI        gr5=1                                                                                                        1446| 004FC0 lwzx       7F9D302E   1     L4A        gr28=ag_asend_freelist[]0(gr29,gr6,0)
  373| 004F2C addi       38C00001   1     LI        gr6=1                                                                                                         128| 004FC4 lwz        80C20060   1     L4A        gr6=._PyAsyncGenASend_Type(gr2,0)
  373| 004F30 ori        609F0000   1     LR        gr31=gr4                                                                                                      128| 004FC8 lwz        801C0004   1     L4A        gr0=(*)C_object._object.ob_type(gr28,4)
  373| 004F34 bl         4BFFE92D   0     CALL      gr3=gen_send_ex,4,(*)aggr#3",gr3,(*)_object",gr4-gr6,#ProcAlias",gen_send_ex",fcr",gr1,cr[01567]",gr0",gr4"   128| 004FCC cmplw      7C003040   2     CL4        cr0=gr0,gr6
  374| 004F38 cmpwi      2C030000   1     C4        cr0=gr3,0                                                                                                       0| 004FD0 bc         4082FFB8   1     BF         CL.1849,cr0,0x4/eq,taken=50%(0,0)







Wed Apr 15 07:30:04 CDT 2020  Page 153


  374| 004F3C bc         4082FE58   1     BF        CL.1606,cr0,0x4/eq,taken=60%(60,40)                                                                             0| 004FD4 b          4BFFFF70   1     B          CL.2308,-1
    0| 004F40 b          4BFFFF5C   1     B         CL.2051,-1                                                                                                      0|                                CL.2310:
    0|                                CL.2055:                                                                                                                   1451| 004FD8 ori        63630000   1     LR         gr3=gr27
  362| 004F44 ori        607E0000   1     LR        gr30=gr3                                                                                                        0| 004FDC lwz        83E1004C   1     L4A        gr31=#stack(gr1,76)
  366| 004F48 addi       38000001   1     LI        gr0=1                                                                                                           0| 004FE0 lwz        8361003C   1     L4A        gr27=#stack(gr1,60)
  366| 004F4C stb        981D000C   1     ST1Z      (*)aggr#3.gi_running(gr29,12)=gr0                                                                               0| 004FE4 lwz        80010058   1     L4A        gr0=#stack(gr1,88)
  367| 004F50 stw        9381FFF0   1     ST4A      #stack_prune(gr1,-16)=gr28                                                                                      0| 004FE8 lwz        83810040   1     L4A        gr28=#stack(gr1,64)
  367| 004F54 stw        93A1FFF4   1     ST4A      #stack_prune(gr1,-12)=gr29                                                                                      0| 004FEC lwz        83A10044   1     L4A        gr29=#stack(gr1,68)
  367| 004F58 bl         4BFFE4E9   0     CALL      gr3=IPRA.$gen_close_iter,1,(*)_object",gr3,#ProcAlias",IPRA.$gen_close_iter",fcr",gr1,cr[01567]",gr0",gr4"-     0| 004FF0 mtspr      7C0803A6   1     LLR        lr=gr0
  367| 004F5C lwz        83A1FFF4   1     L4A       gr29=#stack_prune(gr1,-12)                                                                                      0| 004FF4 lwz        83C10048   1     L4A        gr30=#stack(gr1,72)
  367| 004F60 lwz        8381FFF0   1     L4A       gr28=#stack_prune(gr1,-16)                                                                                   1452| 004FF8 addi       38210050   1     AI         gr1=gr1,80
  368| 004F64 addi       38000000   1     LI        gr0=0                                                                                                        1452| 004FFC bclr       4E800020   1     BA         lr
  417| 004F68 lwz        809E0000   1     L4A       gr4=(*)_object._object.ob_refcnt(gr30,0)                                                                        0|                                CL.1845:
  367| 004F6C ori        607F0000   1     LR        gr31=gr3                                                                                                     1444| 005000 cmpwi      2C040000   1     C4         cr0=gr4,0
  415| 004F70 lwz        80A20004   1     L4A       gr5=._Py_RefTotal(gr2,0)                                                                                     1444| 005004 bc         4082FF08   1     BF         CL.1846,cr0,0x4/eq,taken=50%(0,0)
    0| 004F74 lwz        80620018   1     L4A       gr3=.+CONSTANT_AREA(gr2,0)                                                                                      0| 005008 b          4BFFFFD0   1     B          CL.2310,-1
  417| 004F78 addi       3884FFFF   1     AI        gr4=gr4,-1                                                                                                       |               Tag Table
  417| 004F7C stw        909E0000   1     ST4A      (*)_object._object.ob_refcnt(gr30,0)=gr4                                                                         | 00500C        00000000 00002041 80050000 0000020C 00195079 4173796E
  408| 004F80 addi       38631110   1     AI        gr3=gr3,4368                                                                                                     | 005024        6347656E 5F436C65 61724672 65654C69 737473
  368| 004F84 stb        981D000C   1     ST1Z      (*)aggr#3.gi_running(gr29,12)=gr0                                                                                |               Instruction count          131
  415| 004F88 lwz        80C50000   1     L4A       gr6=<s117:d0:l4>(gr5,0)                                                                                          |               Straight-line exec time    138
  415| 004F8C addi       3806FFFF   2     AI        gr0=gr6,-1                                                                                                   GPR's set/used:   ssus ssss ssss s---  ---- ---- ---- ssss
  417| 004F90 cmpwi      2C040000   1     C4        cr0=gr4,0                                                                                                    FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----
  415| 004F94 stw        90050000   1     ST4A      <s117:d0:l4>(gr5,0)=gr0                                                                                      CCR's set/used:   ss-- -sss
  417| 004F98 bc         41820038   0     BT        CL.1028,cr0,0x4/eq,taken=40%(40,60)                                                                              | 000000                             PDEF       _PyAsyncGenValueWrapperNew
  419| 004F9C bc         4180000C   0     BT        CL.2056,cr0,0x1/lt,taken=40%(40,60)                                                                          1749|                                    PROC       val,gr3
    0| 004FA0 lwz        83C10048   2     L4A       gr30=#stack(gr1,72)                                                                                             0| 005040 mfspr      7C0802A6   1     LFLR       gr0=lr
    0| 004FA4 b          4BFFFDC8   0     B         CL.1602,-1                                                                                                      0| 005044 stwu       9421FFB0   1     ST4U       gr1,#stack(gr1,-80)=gr1
    0|                                CL.2056:                                                                                                                      0| 005048 stw        90010058   1     ST4A       #stack(gr1,88)=gr0
  420| 004FA8 addi       38800171   1     LI        gr4=369                                                                                                         0| 00504C stw        93E1004C   1     ST4A       #stack(gr1,76)=gr31
  420| 004FAC ori        63C50000   1     LR        gr5=gr30                                                                                                        0| 005050 or.        7C7F1B79   1     LR_R       gr31,cr0=gr3
  420| 004FB0 bl         4BFFB051   0     CALL      _Py_NegativeRefcount,3,(*)Cuchar",gr3,gr4,(*)_object",gr5,#ProcAlias",_Py_NegativeRefcount",fcr",gr1,cr[015     0| 005054 stw        93C10048   1     ST4A       #stack(gr1,72)=gr30
  420| 004FB4 ori        60000000   1                                                                                                                               0| 005058 stw        93A10044   1     ST4A       #stack(gr1,68)=gr29
  371| 004FB8 cmpwi      2C1F0000   1     C4        cr0=gr31,0                                                                                                      0| 00505C stw        93810040   1     ST4A       #stack(gr1,64)=gr28
  371| 004FBC bc         4082000C   1     BF        CL.2054,cr0,0x4/eq,taken=40%(40,60)                                                                          1752| 005060 bc         418201F8   0     BT         CL.1943,cr0,0x4/eq,taken=40%(40,60)
    0| 004FC0 lwz        83C10048   2     L4A       gr30=#stack(gr1,72)                                                                                          1754| 005064 lwz        80A20020   2     L4A        gr5=.$STATIC(gr2,0)
    0| 004FC4 b          4BFFFF4C   0     B         CL.1603,-1                                                                                                      0| 005068 lwz        80620014   1     L4A        gr3=._PyAsyncGenWrappedValue_Type(gr2,0)
    0|                                CL.2054:                                                                                                                   1754| 00506C lwz        80850008   1     L4A        gr4=ag_value_freelist_free(gr5,8)
    0| 004FC8 lwz        83C10048   1     L4A       gr30=#stack(gr1,72)                                                                                          1754| 005070 cmpwi      2C040000   2     C4         cr0=gr4,0
    0| 004FCC b          4BFFFDA8   0     B         CL.1605,-1                                                                                                   1754| 005074 bc         41820178   1     BT         CL.506,cr0,0x4/eq,taken=40%(40,60)
  423|                                CL.1028:                                                                                                                      0|                                CL.1938:
  425| 004FD0 ori        63C30000   1     LR        gr3=gr30                                                                                                     1755| 005078 addi       3804FFFF   1     AI         gr0=gr4,-1
  425| 004FD4 bl         4BFFB02D   0     CALL      _Py_Dealloc,1,(*)_object",gr3,#ProcAlias",_Py_Dealloc",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",l  1755| 00507C stw        90050008   1     ST4A       ag_value_freelist_free(gr5,8)=gr0
  425| 004FD8 ori        60000000   1                                                                                                                            1756| 005080 lwz        80820044   1     L4A        gr4=.$STATIC_BSS(gr2,0)
    0| 004FDC lwz        83C10048   1     L4A       gr30=#stack(gr1,72)                                                                                          1756| 005084 rlwinm     5405103A   1     SLL4       gr5=gr0,2
    0| 004FE0 b          4BFFFD8C   0     B         CL.1602,-1                                                                                                   1756| 005088 lwzx       7F84282E   1     L4A        gr28=ag_value_freelist[]0(gr4,gr5,0)
     |               Tag Table                                                                                                                                    128| 00508C lwz        801C0004   2     L4A        gr0=(*)C_object._object.ob_type(gr28,4)
     | 004FE4        00000000 00002041 80030200 00000000 000002A4 00096765                                                                                        128| 005090 cmplw      7C001840   2     CL4        cr0=gr0,gr3
     | 004FFC        6E5F636C 6F7365                                                                                                                             1757| 005094 bc         4082013C   1     BF         CL.2185,cr0,0x4/eq,taken=40%(40,60)
     |               Instruction count          169                                                                                                              1757|                                CL.508:
     |               Straight-line exec time    163                                                                                                              1758| 005098 ori        63830000   1     LR         gr3=gr28
 GPR's set/used:   ssus ssss ssss s---  ---- ---- --ss ssss                                                                                                      1758| 00509C bl         4BFFAF65   0     CALL       _Py_NewReference,1,(*)_object",gr3,#ProcAlias",_Py_NewReference",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-
 FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----                                                                                                      1758| 0050A0 ori        60000000   1
 CCR's set/used:   ss-- -sss                                                                                                                                      401| 0050A4 lwz        80620004   1     L4A        gr3=._Py_RefTotal(gr2,0)
     | 000000                             PDEF     PyAsyncGen_ClearFreeLists                                                                                       30| 0050A8 lwz        801CFFF8   1     L4A        gr0=(*)_object%##2(gr28,-8)
 1433|                                    PROC                                                                                                                    403| 0050AC lwz        809F0000   1     L4A        gr4=(*)_object._object.ob_refcnt(gr31,0)







Wed Apr 15 07:30:04 CDT 2020  Page 154


    0| 005020 mfspr      7C0802A6   1     LFLR      gr0=lr                                                                                                          0| 0050B0 lwz        81020018   1     L4A        gr8=.+CONSTANT_AREA(gr2,0)
    0| 005024 stw        90010008   2     ST4A      #stack(gr1,8)=gr0                                                                                            1766| 0050B4 stw        93FC0008   1     ST4A       (*)aggr#C.agw_val(gr28,8)=gr31
    0| 005028 stw        93E1FFFC   1     ST4A      #stack(gr1,-4)=gr31                                                                                            30| 0050B8 cmpwi      2C000000   1     C4         cr0=gr0,0
    0| 00502C stw        93C1FFF8   1     ST4A      #stack(gr1,-8)=gr30                                                                                           403| 0050BC addi       38040001   1     AI         gr0=gr4,1
    0| 005030 stw        93A1FFF4   1     ST4A      #stack(gr1,-12)=gr29                                                                                          403| 0050C0 stw        901F0000   1     ST4A       (*)_object._object.ob_refcnt(gr31,0)=gr0
    0| 005034 stw        9381FFF0   1     ST4A      #stack(gr1,-16)=gr28                                                                                           27| 0050C4 addi       38C81110   1     AI         gr6=gr8,4368
    0| 005038 stw        9361FFEC   1     ST4A      #stack(gr1,-20)=gr27                                                                                          401| 0050C8 lwz        80830000   1     L4A        gr4=_Py_RefTotal(gr3,0)
    0| 00503C stw        9341FFE8   1     ST4A      #stack(gr1,-24)=gr26                                                                                          401| 0050CC addi       38040001   2     AI         gr0=gr4,1
 1435| 005040 lwz        83E20020   1     L4A       gr31=.$STATIC(gr2,0)                                                                                          401| 0050D0 stw        90030000   1     ST4A       _Py_RefTotal(gr3,0)=gr0
    0| 005044 stwu       9421FFB0   1     ST4U      gr1,#stack(gr1,-80)=gr1                                                                                        30| 0050D4 bc         41820024   0     BT         CL.2184,cr0,0x4/eq,taken=50%(0,0)
 1435| 005048 lwz        807F0008   1     L4A       gr3=ag_value_freelist_free(gr31,8)                                                                              0|                                CL.1940:
 1435| 00504C lwz        809F000C   1     L4A       gr4=ag_asend_freelist_free(gr31,12)                                                                            30| 0050D8 ori        63830000   1     LR         gr3=gr28
 1435| 005050 add        7F432214   2     A         gr26=gr3,gr4                                                                                                   30| 0050DC addi       38881528   1     AI         gr4=gr8,5416
 1437| 005054 cmpwi      2C030000   1     C4        cr0=gr3,0                                                                                                      30| 0050E0 addi       38A81550   1     AI         gr5=gr8,5456
 1437| 005058 bc         418201C0   1     BT        CL.1768,cr0,0x4/eq,taken=50%(0,0)                                                                              30| 0050E4 addi       38E006E8   1     LI         gr7=1768
    0| 00505C lwz        83C20044   1     L4A       gr30=.$STATIC_BSS(gr2,0)                                                                                       30| 0050E8 addi       39081580   1     AI         gr8=gr8,5504
 1439| 005060 addi       3803FFFF   1     AI        gr0=gr3,-1                                                                                                     30| 0050EC bl         4BFFAF15   0     CALL       _PyObject_AssertFailed,6,(*)_object",gr3-gr5,(*)Cuchar",gr6-gr8,#ProcAlias",_PyObject_AssertFailed",fcr",g
    0| 005064 lwz        83A20014   1     L4A       gr29=._PyAsyncGenWrappedValue_Type(gr2,0)                                                                      30| 0050F0 ori        60000000   1
    0| 005068 lwz        83620018   1     L4A       gr27=.+CONSTANT_AREA(gr2,0)                                                                                    30| 0050F4 tw         7C8E7008   1     TRAP       9
 1440| 00506C addi       38A005A0   1     LI        gr5=1440                                                                                                        0|                                CL.2184:
 1439| 005070 stw        901F0008   1     ST4A      ag_value_freelist_free(gr31,8)=gr0                                                                              0| 0050F8 lwz        80010058   1     L4A        gr0=#stack(gr1,88)
 1439| 005074 rlwinm     5406103A   1     SLL4      gr6=gr0,2                                                                                                       0| 0050FC mtspr      7C0803A6   2     LLR        lr=gr0
 1440| 005078 addi       387B1450   1     AI        gr3=gr27,5200                                                                                                  30|                                CL.1114:
 1440| 00507C addi       389B1110   1     AI        gr4=gr27,4368                                                                                                  35| 005100 lwz        801CFFFC   1     L4A        gr0=(*)aggr#2._gc_prev(gr28,-4)
 1439| 005080 lwzx       7F9E302E   1     L4A       gr28=ag_value_freelist[]0(gr30,gr6,0)                                                                          34| 005104 addi       3BFCFFF8   1     AI         gr31=gr28,-8
  128| 005084 lwz        801C0004   2     L4A       gr0=(*)C_object._object.ob_type(gr28,4)                                                                        35| 005108 andi.      70030002   1     RN4_R      gr3,cr0=gr0,0,0x2
  128| 005088 cmplw      7C00E840   2     CL4       cr0=gr0,gr29                                                                                                   35| 00510C bc         408200A4   1     BF         CL.1944,cr0,0x4/eq,taken=10%(10,90)
 1440| 00508C bc         40820044   1     BF        CL.1771,cr0,0x4/eq,taken=50%(0,0)                                                                              67| 005110 lwz        808200A4   2     L4A        gr4=._PyRuntime(gr2,0)
    0|                                CL.2266:                                                                                                                     54| 005114 lwz        806401A0   2     L4A        gr3=(*)pyruntimestate._Py_atomic_address._value(gr4,416)
 1441| 005090 ori        63830000   1     LR        gr3=gr28                                                                                                       41| 005118 lwz        80630008   2     L4A        gr3=(*)_ts._ts.interp(gr3,8)
 1441| 005094 bl         4BFFAF6D   0     CALL      PyObject_GC_Del,1,(*)void",gr3,#ProcAlias",PyObject_GC_Del",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",    41| 00511C lwz        83C30188   2     L4A        gr30=(*)_is._gc_runtime_state.generation0(gr3,392)
 1441| 005098 ori        60000000   1                                                                                                                              42| 005120 lwz        83BE0004   2     L4A        gr29=(*)aggr#2._gc_prev(gr30,4)
 1437| 00509C lwz        807F0008   1     L4A       gr3=ag_value_freelist_free(gr31,8)                                                                             44| 005124 andi.      73A30003   2     RN4_R      gr3,cr0=gr29,0,0xFFFFFFFF00000003
 1437| 0050A0 cmpwi      2C030000   2     C4        cr0=gr3,0                                                                                                      43| 005128 stw        93FD0000   1     ST4A       (*)aggr#2._gc_next(gr29,0)=gr31
 1437| 0050A4 bc         41820078   1     BT        CL.1766,cr0,0x4/eq,taken=20%(20,80)                                                                            44| 00512C bc         40820034   0     BF         CL.2187,cr0,0x4/eq,taken=40%(40,60)
 1440| 0050A8 addi       389B1110   1     AI        gr4=gr27,4368                                                                                                  44| 005130 rlwinm     540007BE   1     RN4        gr0=gr0,0,0x3
 1439| 0050AC addi       3803FFFF   1     AI        gr0=gr3,-1                                                                                                     45| 005134 stw        93DCFFF8   1     ST4A       (*)aggr#2._gc_next(gr28,-8)=gr30
 1439| 0050B0 stw        901F0008   1     ST4A      ag_value_freelist_free(gr31,8)=gr0                                                                             44| 005138 or         7C04EB78   1     O          gr4=gr0,gr29
 1440| 0050B4 addi       387B1450   1     AI        gr3=gr27,5200                                                                                                1769| 00513C ori        63830000   1     LR         gr3=gr28
 1439| 0050B8 rlwinm     5406103A   1     SLL4      gr6=gr0,2                                                                                                      44| 005140 stw        909CFFFC   1     ST4A       (*)aggr#2._gc_prev(gr28,-4)=gr4
 1440| 0050BC addi       38A005A0   1     LI        gr5=1440                                                                                                       46| 005144 stw        93FE0004   1     ST4A       (*)aggr#2._gc_prev(gr30,4)=gr31
 1439| 0050C0 lwzx       7F9E302E   1     L4A       gr28=ag_value_freelist[]0(gr30,gr6,0)                                                                           0| 005148 lwz        83810040   1     L4A        gr28=#stack(gr1,64)
  128| 0050C4 lwz        801C0004   2     L4A       gr0=(*)C_object._object.ob_type(gr28,4)                                                                         0| 00514C lwz        83A10044   1     L4A        gr29=#stack(gr1,68)
  128| 0050C8 cmplw      7C00E840   2     CL4       cr0=gr0,gr29                                                                                                    0| 005150 lwz        83C10048   1     L4A        gr30=#stack(gr1,72)
    0| 0050CC bc         4182FFC4   1     BT        CL.2266,cr0,0x4/eq,taken=50%(0,0)                                                                               0| 005154 lwz        83E1004C   1     L4A        gr31=#stack(gr1,76)
    0|                                CL.1771:                                                                                                                   1770| 005158 addi       38210050   1     AI         gr1=gr1,80
 1440| 0050D0 bl         4BFFAF31   0     CALL      __assert,3,gr3-gr5,#ProcAlias",__assert",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",lr",fcr",xer",f  1770| 00515C bclr       4E800020   0     BA         lr
 1440| 0050D4 ori        60000000   1                                                                                                                               0|                                CL.2187:
 1441| 0050D8 ori        63830000   1     LR        gr3=gr28                                                                                                       44| 005160 addi       386815E4   1     AI         gr3=gr8,5604
 1441| 0050DC bl         4BFFAF25   0     CALL      PyObject_GC_Del,1,(*)void",gr3,#ProcAlias",PyObject_GC_Del",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",    44| 005164 addi       38881610   1     AI         gr4=gr8,5648
 1441| 0050E0 ori        60000000   1                                                                                                                              44| 005168 addi       38A0002C   1     LI         gr5=44
 1437| 0050E4 lwz        807F0008   1     L4A       gr3=ag_value_freelist_free(gr31,8)                                                                             44| 00516C bl         4BFFAE95   0     CALL       __assert,3,gr3-gr5,#ProcAlias",__assert",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",lr",fcr",xer",
 1437| 0050E8 cmpwi      2C030000   2     C4        cr0=gr3,0                                                                                                      44| 005170 ori        60000000   1
 1437| 0050EC bc         41820030   1     BT        CL.1766,cr0,0x4/eq,taken=20%(20,80)                                                                             0| 005174 lwz        801CFFFC   1     L4A        gr0=(*)aggr#2._gc_prev(gr28,-4)
 1440| 0050F0 addi       389B1110   1     AI        gr4=gr27,4368                                                                                                  45| 005178 stw        93DCFFF8   1     ST4A       (*)aggr#2._gc_next(gr28,-8)=gr30
 1439| 0050F4 addi       3803FFFF   1     AI        gr0=gr3,-1                                                                                                   1769| 00517C ori        63830000   1     LR         gr3=gr28







Wed Apr 15 07:30:04 CDT 2020  Page 155


 1439| 0050F8 stw        901F0008   1     ST4A      ag_value_freelist_free(gr31,8)=gr0                                                                             44| 005180 rlwinm     540007BE   1     RN4        gr0=gr0,0,0x3
 1440| 0050FC addi       387B1450   1     AI        gr3=gr27,5200                                                                                                  44| 005184 or         7C04EB78   1     O          gr4=gr0,gr29
 1439| 005100 rlwinm     5406103A   1     SLL4      gr6=gr0,2                                                                                                      44| 005188 stw        909CFFFC   1     ST4A       (*)aggr#2._gc_prev(gr28,-4)=gr4
 1440| 005104 addi       38A005A0   1     LI        gr5=1440                                                                                                       46| 00518C stw        93FE0004   1     ST4A       (*)aggr#2._gc_prev(gr30,4)=gr31
 1439| 005108 lwzx       7F9E302E   1     L4A       gr28=ag_value_freelist[]0(gr30,gr6,0)                                                                           0| 005190 lwz        83810040   1     L4A        gr28=#stack(gr1,64)
  128| 00510C lwz        801C0004   2     L4A       gr0=(*)C_object._object.ob_type(gr28,4)                                                                         0| 005194 lwz        80010058   1     L4A        gr0=#stack(gr1,88)
  128| 005110 cmplw      7C00E840   2     CL4       cr0=gr0,gr29                                                                                                    0| 005198 lwz        83A10044   1     L4A        gr29=#stack(gr1,68)
    0| 005114 bc         4082FFBC   1     BF        CL.1771,cr0,0x4/eq,taken=50%(0,0)                                                                               0| 00519C lwz        83C10048   1     L4A        gr30=#stack(gr1,72)
    0| 005118 b          4BFFFF78   1     B         CL.2266,-1                                                                                                      0| 0051A0 mtspr      7C0803A6   1     LLR        lr=gr0
    0|                                CL.1766:                                                                                                                      0| 0051A4 lwz        83E1004C   1     L4A        gr31=#stack(gr1,76)
    0| 00511C lwz        809F000C   1     L4A       gr4=ag_asend_freelist_free(gr31,12)                                                                          1770| 0051A8 addi       38210050   1     AI         gr1=gr1,80
 1444| 005120 cmpwi      2C040000   2     C4        cr0=gr4,0                                                                                                    1770| 0051AC bclr       4E800020   1     BA         lr
 1444| 005124 bc         418200C8   1     BT        CL.2269,cr0,0x4/eq,taken=20%(20,80)                                                                             0|                                CL.1944:
    0|                                CL.1769:                                                                                                                     35| 0051B0 ori        63830000   1     LR         gr3=gr28
    0| 005128 lwz        80620044   1     L4A       gr3=.$STATIC_BSS(gr2,0)                                                                                        35| 0051B4 addi       38881594   1     AI         gr4=gr8,5524
    0| 00512C lwz        83C20060   1     L4A       gr30=._PyAsyncGenASend_Type(gr2,0)                                                                             35| 0051B8 addi       38A815B0   1     AI         gr5=gr8,5552
 1446| 005130 addi       3804FFFF   1     AI        gr0=gr4,-1                                                                                                     35| 0051BC addi       38E006E8   1     LI         gr7=1768
 1447| 005134 addi       38A005A7   1     LI        gr5=1447                                                                                                       35| 0051C0 addi       39081580   1     AI         gr8=gr8,5504
    0| 005138 lwz        83A20018   1     L4A       gr29=.+CONSTANT_AREA(gr2,0)                                                                                    35| 0051C4 bl         4BFFAE3D   0     CALL       _PyObject_AssertFailed,6,(*)_object",gr3-gr5,(*)Cuchar",gr6-gr8,#ProcAlias",_PyObject_AssertFailed",fcr",g
 1446| 00513C stw        901F000C   1     ST4A      ag_asend_freelist_free(gr31,12)=gr0                                                                            35| 0051C8 ori        60000000   1
 1446| 005140 rlwinm     5406103A   1     SLL4      gr6=gr0,2                                                                                                      35| 0051CC tw         7C8E7008   1     TRAP       9
 1446| 005144 addi       3B830140   1     AI        gr28=gr3,320                                                                                                    0|                                CL.2185:
 1447| 005148 addi       387D1500   1     AI        gr3=gr29,5376                                                                                                1757| 0051D0 lwz        80820018   1     L4A        gr4=.+CONSTANT_AREA(gr2,0)
 1447| 00514C addi       389D1110   1     AI        gr4=gr29,4368                                                                                                1757| 0051D4 addi       38A006DD   1     LI         gr5=1757
 1446| 005150 lwzx       7F7C302E   1     L4A       gr27=ag_asend_freelist[]0(gr28,gr6,0)                                                                        1757| 0051D8 addi       38641450   1     AI         gr3=gr4,5200
  128| 005154 lwz        801B0004   2     L4A       gr0=(*)C_object._object.ob_type(gr27,4)                                                                      1757| 0051DC addi       38841110   1     AI         gr4=gr4,4368
  128| 005158 cmplw      7C00F040   2     CL4       cr0=gr0,gr30                                                                                                 1757| 0051E0 bl         4BFFAE21   0     CALL       __assert,3,gr3-gr5,#ProcAlias",__assert",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",lr",fcr",xer",
 1447| 00515C bc         40820044   1     BF        CL.1772,cr0,0x4/eq,taken=50%(0,0)                                                                            1757| 0051E4 ori        60000000   1
    0|                                CL.2267:                                                                                                                      0| 0051E8 b          4BFFFEB0   0     B          CL.508,-1
 1448| 005160 ori        63630000   1     LR        gr3=gr27                                                                                                     1759|                                CL.506:
 1448| 005164 bl         4BFFAE9D   0     CALL      PyObject_GC_Del,1,(*)void",gr3,#ProcAlias",PyObject_GC_Del",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",  1760| 0051EC bl         4BFFAE15   0     CALL       gr3=_PyObject_GC_New,1,(*)_typeobject",gr3,#ProcAlias",_PyObject_GC_New",fcr",gr1,cr[01567]",gr0",gr4"-gr1
 1448| 005168 ori        60000000   1                                                                                                                            1760| 0051F0 ori        60000000   1
 1444| 00516C lwz        809F000C   1     L4A       gr4=ag_asend_freelist_free(gr31,12)                                                                          1762| 0051F4 cmpwi      2C030000   1     C4         cr0=gr3,0
 1444| 005170 cmpwi      2C040000   2     C4        cr0=gr4,0                                                                                                    1762| 0051F8 bc         41820048   1     BT         CL.2186,cr0,0x4/eq,taken=30%(30,70)
 1444| 005174 bc         41820078   1     BT        CL.2269,cr0,0x4/eq,taken=20%(20,80)                                                                           403| 0051FC lwz        809F0000   2     L4A        gr4=(*)_object._object.ob_refcnt(gr31,0)
 1447| 005178 addi       387D1500   1     AI        gr3=gr29,5376                                                                                                   0| 005200 lwz        81020018   1     L4A        gr8=.+CONSTANT_AREA(gr2,0)
 1446| 00517C addi       3804FFFF   1     AI        gr0=gr4,-1                                                                                                      0| 005204 lwz        80010058   1     L4A        gr0=#stack(gr1,88)
 1446| 005180 stw        901F000C   1     ST4A      ag_asend_freelist_free(gr31,12)=gr0                                                                          1762| 005208 ori        607C0000   1     LR         gr28=gr3
 1447| 005184 addi       389D1110   1     AI        gr4=gr29,4368                                                                                                 401| 00520C lwz        80620004   1     L4A        gr3=._Py_RefTotal(gr2,0)
 1446| 005188 rlwinm     5406103A   1     SLL4      gr6=gr0,2                                                                                                     403| 005210 addi       38840001   1     AI         gr4=gr4,1
 1447| 00518C addi       38A005A7   1     LI        gr5=1447                                                                                                      403| 005214 stw        909F0000   1     ST4A       (*)_object._object.ob_refcnt(gr31,0)=gr4
 1446| 005190 lwzx       7F7C302E   1     L4A       gr27=ag_asend_freelist[]0(gr28,gr6,0)                                                                          27| 005218 addi       38C81110   1     AI         gr6=gr8,4368
  128| 005194 lwz        801B0004   2     L4A       gr0=(*)C_object._object.ob_type(gr27,4)                                                                         0| 00521C mtspr      7C0803A6   1     LLR        lr=gr0
  128| 005198 cmplw      7C00F040   2     CL4       cr0=gr0,gr30                                                                                                 1766| 005220 stw        93FC0008   1     ST4A       (*)aggr#C.agw_val(gr28,8)=gr31
    0| 00519C bc         4182FFC4   1     BT        CL.2267,cr0,0x4/eq,taken=50%(0,0)                                                                              30| 005224 lwz        801CFFF8   1     L4A        gr0=(*)_object%##2(gr28,-8)
    0|                                CL.1772:                                                                                                                    401| 005228 lwz        80830000   1     L4A        gr4=_Py_RefTotal(gr3,0)
 1447| 0051A0 bl         4BFFAE61   0     CALL      __assert,3,gr3-gr5,#ProcAlias",__assert",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",lr",fcr",xer",f    30| 00522C cmpwi      2C000000   1     C4         cr0=gr0,0
 1447| 0051A4 ori        60000000   1                                                                                                                             401| 005230 addi       38040001   1     AI         gr0=gr4,1
 1448| 0051A8 ori        63630000   1     LR        gr3=gr27                                                                                                      401| 005234 stw        90030000   1     ST4A       _Py_RefTotal(gr3,0)=gr0
 1448| 0051AC bl         4BFFAE55   0     CALL      PyObject_GC_Del,1,(*)void",gr3,#ProcAlias",PyObject_GC_Del",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",    30| 005238 bc         4082FEA0   0     BF         CL.1940,cr0,0x4/eq,taken=10%(10,90)
 1448| 0051B0 ori        60000000   1                                                                                                                              30| 00523C b          4BFFFEC4   1     B          CL.1114,-1
 1444| 0051B4 lwz        809F000C   1     L4A       gr4=ag_asend_freelist_free(gr31,12)                                                                             0|                                CL.2186:
 1444| 0051B8 cmpwi      2C040000   2     C4        cr0=gr4,0                                                                                                    1763| 005240 addi       38600000   1     LI         gr3=0
 1444| 0051BC bc         41820030   1     BT        CL.2269,cr0,0x4/eq,taken=20%(20,80)                                                                             0| 005244 lwz        80010058   1     L4A        gr0=#stack(gr1,88)
 1447| 0051C0 addi       387D1500   1     AI        gr3=gr29,5376                                                                                                   0| 005248 lwz        83E1004C   1     L4A        gr31=#stack(gr1,76)
 1446| 0051C4 addi       3804FFFF   1     AI        gr0=gr4,-1                                                                                                   1770| 00524C addi       38210050   1     AI         gr1=gr1,80







Wed Apr 15 07:30:04 CDT 2020  Page 156


 1446| 0051C8 stw        901F000C   1     ST4A      ag_asend_freelist_free(gr31,12)=gr0                                                                             0| 005250 mtspr      7C0803A6   1     LLR        lr=gr0
 1447| 0051CC addi       389D1110   1     AI        gr4=gr29,4368                                                                                                1770| 005254 bclr       4E800020   3     BA         lr
 1446| 0051D0 rlwinm     5406103A   1     SLL4      gr6=gr0,2                                                                                                       0|                                CL.1943:
 1447| 0051D4 addi       38A005A7   1     LI        gr5=1447                                                                                                     1752| 005258 lwz        80820018   1     L4A        gr4=.+CONSTANT_AREA(gr2,0)
 1446| 0051D8 lwzx       7F7C302E   1     L4A       gr27=ag_asend_freelist[]0(gr28,gr6,0)                                                                        1752| 00525C addi       38A006D8   1     LI         gr5=1752
  128| 0051DC lwz        801B0004   2     L4A       gr0=(*)C_object._object.ob_type(gr27,4)                                                                      1752| 005260 addi       386416E4   1     AI         gr3=gr4,5860
  128| 0051E0 cmplw      7C00F040   2     CL4       cr0=gr0,gr30                                                                                                 1752| 005264 addi       38841110   1     AI         gr4=gr4,4368
    0| 0051E4 bc         4082FFBC   1     BF        CL.1772,cr0,0x4/eq,taken=50%(0,0)                                                                            1752| 005268 bl         4BFFAD99   0     CALL       __assert,3,gr3-gr5,#ProcAlias",__assert",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",lr",fcr",xer",
    0| 0051E8 b          4BFFFF78   1     B         CL.2267,-1                                                                                                   1752| 00526C ori        60000000   1
    0|                                CL.2269:                                                                                                                   1754| 005270 lwz        80A20020   1     L4A        gr5=.$STATIC(gr2,0)
 1451| 0051EC ori        63430000   1     LR        gr3=gr26                                                                                                        0| 005274 lwz        80620014   1     L4A        gr3=._PyAsyncGenWrappedValue_Type(gr2,0)
    0| 0051F0 lwz        83E1004C   1     L4A       gr31=#stack(gr1,76)                                                                                          1754| 005278 lwz        80850008   1     L4A        gr4=ag_value_freelist_free(gr5,8)
    0| 0051F4 lwz        83410038   1     L4A       gr26=#stack(gr1,56)                                                                                          1754| 00527C cmpwi      2C040000   2     C4         cr0=gr4,0
    0| 0051F8 lwz        80010058   1     L4A       gr0=#stack(gr1,88)                                                                                           1754| 005280 bc         4182FF6C   1     BT         CL.506,cr0,0x4/eq,taken=40%(40,60)
    0| 0051FC lwz        8361003C   1     L4A       gr27=#stack(gr1,60)                                                                                             0| 005284 b          4BFFFDF4   1     B          CL.1938,-1
    0| 005200 lwz        83810040   1     L4A       gr28=#stack(gr1,64)                                                                                              |               Tag Table
    0| 005204 mtspr      7C0803A6   1     LLR       lr=gr0                                                                                                           | 005288        00000000 00002041 80040100 00000000 00000248 001A5F50
    0| 005208 lwz        83A10044   1     L4A       gr29=#stack(gr1,68)                                                                                              | 0052A0        79417379 6E634765 6E56616C 75655772 61707065 724E6577
    0| 00520C lwz        83C10048   1     L4A       gr30=#stack(gr1,72)                                                                                              |               Instruction count          146
 1452| 005210 addi       38210050   1     AI        gr1=gr1,80                                                                                                       |               Straight-line exec time    149
 1452| 005214 bclr       4E800020   0     BA        lr                                                                                                           GPR's set/used:   ssus ssss ssss s---  ---- ---- ---- ----
    0|                                CL.1768:                                                                                                                   FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----
 1444| 005218 cmpwi      2C040000   1     C4        cr0=gr4,0                                                                                                    CCR's set/used:   ss-- -sss
 1444| 00521C bc         4082FF0C   1     BF        CL.1769,cr0,0x4/eq,taken=50%(0,0)                                                                                | 000000                             PDEF       PyAsyncGen_New
    0| 005220 b          4BFFFFCC   1     B         CL.2269,-1                                                                                                   1416|                                    PROC       f,name,qualname,gr3-gr5
     |               Tag Table                                                                                                                                      0| 0052C0 mfspr      7C0802A6   1     LFLR       gr0=lr
     | 005224        00000000 00002041 80060000 00000204 00195079 4173796E                                                                                          0| 0052C4 stwu       9421FFC0   1     ST4U       gr1,#stack(gr1,-64)=gr1
     | 00523C        6347656E 5F436C65 61724672 65654C69 737473                                                                                                  1419| 0052C8 ori        60A60000   1     LR         gr6=gr5
     |               Instruction count          129                                                                                                              1419| 0052CC ori        60850000   1     LR         gr5=gr4
     |               Straight-line exec time    141                                                                                                              1419| 0052D0 ori        60640000   1     LR         gr4=gr3
 GPR's set/used:   ssus ssss ssss s---  ---- ---- ---- ssss                                                                                                      1419| 0052D4 lwz        806200E0   1     L4A        gr3=.PyAsyncGen_Type(gr2,0)
 FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----                                                                                                         0| 0052D8 stw        90010048   1     ST4A       #stack(gr1,72)=gr0
 CCR's set/used:   ss-- -sss                                                                                                                                     1419| 0052DC bl         4BFFCDE5   0     CALL       gr3=gen_new_with_qualname,4,(*)_typeobject",gr3,(*)_frame",gr4,(*)_object",gr5,(*)_object",gr6,#ProcAlias"
     | 000000                             PDEF     _PyAsyncGenValueWrapperNew                                                                                    1424| 0052E0 addi       38000000   1     LI         gr0=0
 1749|                                    PROC      val,gr3                                                                                                      1421| 0052E4 cmpwi      2C030000   1     C4         cr0=gr3,0
    0| 005260 mfspr      7C0802A6   1     LFLR      gr0=lr                                                                                                       1421| 0052E8 bc         41820024   1     BT         CL.1965,cr0,0x4/eq,taken=50%(0,0)
    0| 005264 stw        90010008   2     ST4A      #stack(gr1,8)=gr0                                                                                            1424| 0052EC stw        90030030   2     ST4A       (*)aggr#4.ag_finalizer(gr3,48)=gr0
    0| 005268 stw        93E1FFFC   1     ST4A      #stack(gr1,-4)=gr31                                                                                          1425| 0052F0 stw        90030038   1     ST4A       (*)aggr#4.ag_closed(gr3,56)=gr0
    0| 00526C or.        7C7F1B79   1     LR_R      gr31,cr0=gr3                                                                                                 1426| 0052F4 stw        90030034   1     ST4A       (*)aggr#4.ag_hooks_inited(gr3,52)=gr0
    0| 005270 stw        93C1FFF8   1     ST4A      #stack(gr1,-8)=gr30                                                                                          1427| 0052F8 stw        9003003C   1     ST4A       (*)aggr#4.ag_running_async(gr3,60)=gr0
    0| 005274 stw        93A1FFF4   1     ST4A      #stack(gr1,-12)=gr29                                                                                            0| 0052FC lwz        80810048   1     L4A        gr4=#stack(gr1,72)
    0| 005278 stw        9381FFF0   1     ST4A      #stack(gr1,-16)=gr28                                                                                         1429| 005300 addi       38210040   1     AI         gr1=gr1,64
    0| 00527C stwu       9421FFB0   1     ST4U      gr1,#stack(gr1,-80)=gr1                                                                                         0| 005304 mtspr      7C8803A6   1     LLR        lr=gr4
 1752| 005280 bc         418201F8   0     BT        CL.1858,cr0,0x4/eq,taken=40%(40,60)                                                                          1429| 005308 bclr       4E800020   3     BA         lr
 1754| 005284 lwz        80A20020   1     L4A       gr5=.$STATIC(gr2,0)                                                                                             0|                                CL.1965:
    0| 005288 lwz        80620014   1     L4A       gr3=._PyAsyncGenWrappedValue_Type(gr2,0)                                                                     1422| 00530C addi       38600000   1     LI         gr3=0
 1754| 00528C lwz        80850008   1     L4A       gr4=ag_value_freelist_free(gr5,8)                                                                               0| 005310 lwz        80010048   1     L4A        gr0=#stack(gr1,72)
 1754| 005290 cmpwi      2C040000   2     C4        cr0=gr4,0                                                                                                    1429| 005314 addi       38210040   1     AI         gr1=gr1,64
 1754| 005294 bc         41820178   1     BT        CL.506,cr0,0x4/eq,taken=40%(40,60)                                                                              0| 005318 mtspr      7C0803A6   1     LLR        lr=gr0
    0|                                CL.1853:                                                                                                                   1429| 00531C bclr       4E800020   3     BA         lr
 1755| 005298 addi       3804FFFF   1     AI        gr0=gr4,-1                                                                                                       |               Tag Table
 1755| 00529C stw        90050008   1     ST4A      ag_value_freelist_free(gr5,8)=gr0                                                                                | 005320        00000000 00002041 80000300 00000000 00000060 000E5079
 1756| 0052A0 lwz        80820044   1     L4A       gr4=.$STATIC_BSS(gr2,0)                                                                                          | 005338        4173796E 6347656E 5F4E6577
 1756| 0052A4 rlwinm     5405103A   1     SLL4      gr5=gr0,2                                                                                                        |               Instruction count           24
 1756| 0052A8 lwzx       7F84282E   1     L4A       gr28=ag_value_freelist[]0(gr4,gr5,0)                                                                             |               Straight-line exec time     28
  128| 0052AC lwz        801C0004   2     L4A       gr0=(*)C_object._object.ob_type(gr28,4)                                                                      GPR's set/used:   ssus ssss ssss s---  ---- ---- ---- ---s







Wed Apr 15 07:30:04 CDT 2020  Page 157


  128| 0052B0 cmplw      7C001840   2     CL4       cr0=gr0,gr3                                                                                                  FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----
 1757| 0052B4 bc         4082013C   1     BF        CL.2148,cr0,0x4/eq,taken=40%(40,60)                                                                          CCR's set/used:   ss-- -sss
 1757|                                CL.508:                                                                                                                        | 000000                             PDEF       PyCoro_New
 1758| 0052B8 ori        63830000   1     LR        gr3=gr28                                                                                                     1137|                                    PROC       f,name,qualname,gr3-gr5
 1758| 0052BC bl         4BFFAD45   0     CALL      _Py_NewReference,1,(*)_object",gr3,#ProcAlias",_Py_NewReference",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-f     0| 005360 mfspr      7C0802A6   1     LFLR       gr0=lr
 1758| 0052C0 ori        60000000   1                                                                                                                               0| 005364 stwu       9421FFC0   1     ST4U       gr1,#stack(gr1,-64)=gr1
  401| 0052C4 lwz        80620004   1     L4A       gr3=._Py_RefTotal(gr2,0)                                                                                        0| 005368 ori        60A60000   1     LR         gr6=gr5
   30| 0052C8 lwz        801CFFF8   1     L4A       gr0=(*)_object%##2(gr28,-8)                                                                                     0| 00536C ori        60850000   1     LR         gr5=gr4
  403| 0052CC lwz        809F0000   1     L4A       gr4=(*)_object._object.ob_refcnt(gr31,0)                                                                        0| 005370 stw        90010048   1     ST4A       #stack(gr1,72)=gr0
    0| 0052D0 lwz        81020018   1     L4A       gr8=.+CONSTANT_AREA(gr2,0)                                                                                      0| 005374 stw        93E1003C   1     ST4A       #stack(gr1,60)=gr31
 1766| 0052D4 stw        93FC0008   1     ST4A      (*)aggr#C.agw_val(gr28,8)=gr31                                                                                  0| 005378 ori        60600000   1     LR         gr0=gr3
   30| 0052D8 cmpwi      2C000000   1     C4        cr0=gr0,0                                                                                                    1139| 00537C lwz        806200D8   1     L4A        gr3=.PyCoro_Type(gr2,0)
  403| 0052DC addi       38040001   1     AI        gr0=gr4,1                                                                                                    1139| 005380 ori        60040000   1     LR         gr4=gr0
  403| 0052E0 stw        901F0000   1     ST4A      (*)_object._object.ob_refcnt(gr31,0)=gr0                                                                     1139| 005384 bl         4BFFCD3D   0     CALL       gr3=gen_new_with_qualname,4,(*)_typeobject",gr3,(*)_frame",gr4,(*)_object",gr5,(*)_object",gr6,#ProcAlias"
   27| 0052E4 addi       38C81110   1     AI        gr6=gr8,4368                                                                                                 1140| 005388 or.        7C7F1B79   1     LR_R       gr31,cr0=gr3
  401| 0052E8 lwz        80830000   1     L4A       gr4=<s117:d0:l4>(gr3,0)                                                                                        67| 00538C lwz        808200A4   1     L4A        gr4=._PyRuntime(gr2,0)
  401| 0052EC addi       38040001   2     AI        gr0=gr4,1                                                                                                    1140| 005390 bc         4182007C   0     BT         CL.1991,cr0,0x4/eq,taken=30%(30,70)
  401| 0052F0 stw        90030000   1     ST4A      <s117:d0:l4>(gr3,0)=gr0                                                                                        54| 005394 lwz        806401A0   2     L4A        gr3=(*)pyruntimestate._Py_atomic_address._value(gr4,416)
   30| 0052F4 bc         41820024   0     BT        CL.2147,cr0,0x4/eq,taken=50%(0,0)                                                                            1145| 005398 lwz        80630074   2     L4A        gr3=(*)_ts._ts.coroutine_origin_tracking_depth(gr3,116)
    0|                                CL.1855:                                                                                                                   1147| 00539C cmpwi      2C030000   2     C4         cr0=gr3,0
   30| 0052F8 ori        63830000   1     LR        gr3=gr28                                                                                                     1147| 0053A0 bc         418200C0   1     BT         CL.2182,cr0,0x4/eq,taken=30%(30,70)
   30| 0052FC addi       38881528   1     AI        gr4=gr8,5416                                                                                                 1150| 0053A4 bl         4BFFC4DD   1     CALL       gr3=compute_cr_origin,1,gr3,#ProcAlias",compute_cr_origin",fcr",gr1,cr[01567]",gr0",gr4"-gr12",fp0"-fp13",
   30| 005300 addi       38A81550   1     AI        gr5=gr8,5456                                                                                                 1152| 0053A8 cmpwi      2C030000   1     C4         cr0=gr3,0
   30| 005304 addi       38E006E8   1     LI        gr7=1768                                                                                                      415| 0053AC lwz        80820004   1     L4A        gr4=._Py_RefTotal(gr2,0)
   30| 005308 addi       39081580   1     AI        gr8=gr8,5504                                                                                                 1151| 0053B0 stw        907F0030   1     ST4A       (*)aggr#6.cr_origin(gr31,48)=gr3
   30| 00530C bl         4BFFACF5   0     CALL      _PyObject_AssertFailed,6,(*)_object",gr3-gr5,(*)Cuchar",gr6-gr8,#ProcAlias",_PyObject_AssertFailed",fcr",gr  1152| 0053B4 bc         40820094   0     BF         CL.1988,cr0,0x4/eq,taken=30%(30,70)
   30| 005310 ori        60000000   1                                                                                                                             417| 0053B8 lwz        80BF0000   2     L4A        gr5=(*)_object._object.ob_refcnt(gr31,0)
   30| 005314 tw         7C8E7008   1     TRAP      9                                                                                                               0| 0053BC lwz        80620018   1     L4A        gr3=.+CONSTANT_AREA(gr2,0)
    0|                                CL.2147:                                                                                                                    417| 0053C0 addi       3805FFFF   1     AI         gr0=gr5,-1
    0| 005318 lwz        80010058   1     L4A       gr0=#stack(gr1,88)                                                                                            417| 0053C4 stw        901F0000   1     ST4A       (*)_object._object.ob_refcnt(gr31,0)=gr0
    0| 00531C mtspr      7C0803A6   2     LLR       lr=gr0                                                                                                        408| 0053C8 addi       38631110   1     AI         gr3=gr3,4368
   30|                                CL.1114:                                                                                                                    415| 0053CC lwz        80A40000   1     L4A        gr5=_Py_RefTotal(gr4,0)
   35| 005320 lwz        801CFFFC   1     L4A       gr0=(*)aggr#2._gc_prev(gr28,-4)                                                                               415| 0053D0 addi       38A5FFFF   2     AI         gr5=gr5,-1
   34| 005324 addi       3BFCFFF8   1     AI        gr31=gr28,-8                                                                                                  415| 0053D4 stw        90A40000   1     ST4A       _Py_RefTotal(gr4,0)=gr5
   35| 005328 andi.      70030002   1     RN4_R     gr3,cr0=gr0,0,0x2                                                                                             417| 0053D8 cmpwi      2C000000   1     C4         cr0=gr0,0
   35| 00532C bc         408200A4   1     BF        CL.1859,cr0,0x4/eq,taken=10%(10,90)                                                                           417| 0053DC bc         41820048   1     BT         CL.1106,cr0,0x4/eq,taken=40%(40,60)
   67| 005330 lwz        808200A4   2     L4A       gr4=._PyRuntime(gr2,0)                                                                                        420| 0053E0 addi       38800481   1     LI         gr4=1153
   54| 005334 lwz        806401A0   2     L4A       gr3=<s149:d416:l4>(gr4,416)                                                                                   420| 0053E4 ori        63E50000   1     LR         gr5=gr31
   41| 005338 lwz        80630008   2     L4A       gr3=(*)_ts._ts.interp(gr3,8)                                                                                  419| 0053E8 bc         40800024   0     BF         CL.1991,cr0,0x1/lt,taken=30%(30,70)
   41| 00533C lwz        83C30188   2     L4A       gr30=(*)_is._gc_runtime_state.generation0(gr3,392)                                                              0| 0053EC lwz        83E1003C   2     L4A        gr31=#stack(gr1,60)
   42| 005340 lwz        83BE0004   2     L4A       gr29=(*)aggr#2._gc_prev(gr30,4)                                                                               420| 0053F0 bl         4BFFAC11   0     CALL       _Py_NegativeRefcount,3,(*)Cuchar",gr3,gr4,(*)_object",gr5,#ProcAlias",_Py_NegativeRefcount",fcr",gr1,cr[01
   44| 005344 andi.      73A30003   2     RN4_R     gr3,cr0=gr29,0,0xFFFFFFFF00000003                                                                             420| 0053F4 ori        60000000   1
   43| 005348 stw        93FD0000   1     ST4A      (*)aggr#2._gc_next(gr29,0)=gr31                                                                              1154| 0053F8 addi       38600000   1     LI         gr3=0
   44| 00534C bc         40820034   0     BF        CL.2150,cr0,0x4/eq,taken=40%(40,60)                                                                             0| 0053FC lwz        80010048   1     L4A        gr0=#stack(gr1,72)
   44| 005350 rlwinm     540007BE   1     RN4       gr0=gr0,0,0x3                                                                                                1159| 005400 addi       38210040   1     AI         gr1=gr1,64
   45| 005354 stw        93DCFFF8   1     ST4A      (*)aggr#2._gc_next(gr28,-8)=gr30                                                                                0| 005404 mtspr      7C0803A6   1     LLR        lr=gr0
   44| 005358 or         7C04EB78   1     O         gr4=gr0,gr29                                                                                                 1159| 005408 bclr       4E800020   3     BA         lr
 1769| 00535C ori        63830000   1     LR        gr3=gr28                                                                                                        0|                                CL.1991:
   44| 005360 stw        909CFFFC   1     ST4A      (*)aggr#2._gc_prev(gr28,-4)=gr4                                                                              1154| 00540C addi       38600000   1     LI         gr3=0
   46| 005364 stw        93FE0004   1     ST4A      (*)aggr#2._gc_prev(gr30,4)=gr31                                                                                 0| 005410 lwz        83E1003C   1     L4A        gr31=#stack(gr1,60)
    0| 005368 lwz        83810040   1     L4A       gr28=#stack(gr1,64)                                                                                             0| 005414 lwz        80010048   1     L4A        gr0=#stack(gr1,72)
    0| 00536C lwz        83A10044   1     L4A       gr29=#stack(gr1,68)                                                                                          1159| 005418 addi       38210040   1     AI         gr1=gr1,64
    0| 005370 lwz        83C10048   1     L4A       gr30=#stack(gr1,72)                                                                                             0| 00541C mtspr      7C0803A6   1     LLR        lr=gr0
    0| 005374 lwz        83E1004C   1     L4A       gr31=#stack(gr1,76)                                                                                          1159| 005420 bclr       4E800020   3     BA         lr
 1770| 005378 addi       38210050   1     AI        gr1=gr1,80                                                                                                    423|                                CL.1106:
 1770| 00537C bclr       4E800020   0     BA        lr                                                                                                            425| 005424 ori        63E30000   1     LR         gr3=gr31







Wed Apr 15 07:30:04 CDT 2020  Page 158


    0|                                CL.2150:                                                                                                                    425| 005428 bl         4BFFABD9   0     CALL       _Py_Dealloc,1,(*)_object",gr3,#ProcAlias",_Py_Dealloc",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",
   44| 005380 addi       386815E4   1     AI        gr3=gr8,5604                                                                                                  425| 00542C ori        60000000   1
   44| 005384 addi       38881610   1     AI        gr4=gr8,5648                                                                                                 1154| 005430 addi       38600000   1     LI         gr3=0
   44| 005388 addi       38A0002C   1     LI        gr5=44                                                                                                          0| 005434 lwz        83E1003C   1     L4A        gr31=#stack(gr1,60)
   44| 00538C bl         4BFFAC75   0     CALL      __assert,3,gr3-gr5,#ProcAlias",__assert",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",lr",fcr",xer",f     0| 005438 lwz        80010048   1     L4A        gr0=#stack(gr1,72)
   44| 005390 ori        60000000   1                                                                                                                            1159| 00543C addi       38210040   1     AI         gr1=gr1,64
    0| 005394 lwz        801CFFFC   1     L4A       gr0=(*)aggr#2._gc_prev(gr28,-4)                                                                                 0| 005440 mtspr      7C0803A6   1     LLR        lr=gr0
   45| 005398 stw        93DCFFF8   1     ST4A      (*)aggr#2._gc_next(gr28,-8)=gr30                                                                             1159| 005444 bclr       4E800020   3     BA         lr
 1769| 00539C ori        63830000   1     LR        gr3=gr28                                                                                                        0|                                CL.1988:
   44| 0053A0 rlwinm     540007BE   1     RN4       gr0=gr0,0,0x3                                                                                                1158| 005448 ori        63E30000   1     LR         gr3=gr31
   44| 0053A4 or         7C04EB78   1     O         gr4=gr0,gr29                                                                                                    0| 00544C lwz        83E1003C   1     L4A        gr31=#stack(gr1,60)
   44| 0053A8 stw        909CFFFC   1     ST4A      (*)aggr#2._gc_prev(gr28,-4)=gr4                                                                                 0| 005450 lwz        80010048   1     L4A        gr0=#stack(gr1,72)
   46| 0053AC stw        93FE0004   1     ST4A      (*)aggr#2._gc_prev(gr30,4)=gr31                                                                              1159| 005454 addi       38210040   1     AI         gr1=gr1,64
    0| 0053B0 lwz        83810040   1     L4A       gr28=#stack(gr1,64)                                                                                             0| 005458 mtspr      7C0803A6   1     LLR        lr=gr0
    0| 0053B4 lwz        80010058   1     L4A       gr0=#stack(gr1,88)                                                                                           1159| 00545C bclr       4E800020   3     BA         lr
    0| 0053B8 lwz        83A10044   1     L4A       gr29=#stack(gr1,68)                                                                                             0|                                CL.2182:
    0| 0053BC lwz        83C10048   1     L4A       gr30=#stack(gr1,72)                                                                                          1148| 005460 addi       38000000   1     LI         gr0=0
    0| 0053C0 mtspr      7C0803A6   1     LLR       lr=gr0                                                                                                       1158| 005464 ori        63E30000   1     LR         gr3=gr31
    0| 0053C4 lwz        83E1004C   1     L4A       gr31=#stack(gr1,76)                                                                                          1148| 005468 stw        901F0030   1     ST4A       (*)aggr#6.cr_origin(gr31,48)=gr0
 1770| 0053C8 addi       38210050   1     AI        gr1=gr1,80                                                                                                      0| 00546C lwz        83E1003C   1     L4A        gr31=#stack(gr1,60)
 1770| 0053CC bclr       4E800020   1     BA        lr                                                                                                              0| 005470 lwz        80010048   1     L4A        gr0=#stack(gr1,72)
    0|                                CL.1859:                                                                                                                   1159| 005474 addi       38210040   1     AI         gr1=gr1,64
   35| 0053D0 ori        63830000   1     LR        gr3=gr28                                                                                                        0| 005478 mtspr      7C0803A6   1     LLR        lr=gr0
   35| 0053D4 addi       38881594   1     AI        gr4=gr8,5524                                                                                                 1159| 00547C bclr       4E800020   3     BA         lr
   35| 0053D8 addi       38A815B0   1     AI        gr5=gr8,5552                                                                                                     |               Tag Table
   35| 0053DC addi       38E006E8   1     LI        gr7=1768                                                                                                         | 005480        00000000 00002041 80010300 00000000 00000120 000A5079
   35| 0053E0 addi       39081580   1     AI        gr8=gr8,5504                                                                                                     | 005498        436F726F 5F4E6577
   35| 0053E4 bl         4BFFAC1D   0     CALL      _PyObject_AssertFailed,6,(*)_object",gr3-gr5,(*)Cuchar",gr6-gr8,#ProcAlias",_PyObject_AssertFailed",fcr",gr      |               Instruction count           72
   35| 0053E8 ori        60000000   1                                                                                                                                |               Straight-line exec time     82
   35| 0053EC tw         7C8E7008   1     TRAP      9                                                                                                            GPR's set/used:   ssus ssss ssss s---  ---- ---- ---- ssss
    0|                                CL.2148:                                                                                                                   FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----
 1757| 0053F0 lwz        80820018   1     L4A       gr4=.+CONSTANT_AREA(gr2,0)                                                                                   CCR's set/used:   ss-- -sss
 1757| 0053F4 addi       38A006DD   1     LI        gr5=1757                                                                                                         | 000000                             PDEF       _PyCoro_GetAwaitableIter
 1757| 0053F8 addi       38641450   1     AI        gr3=gr4,5200                                                                                                  851|                                    PROC       o,gr3
 1757| 0053FC addi       38841110   1     AI        gr4=gr4,4368                                                                                                    0| 0054A0 mfspr      7C0802A6   1     LFLR       gr0=lr
 1757| 005400 bl         4BFFAC01   0     CALL      __assert,3,gr3-gr5,#ProcAlias",__assert",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",lr",fcr",xer",f   862| 0054A4 lwz        80C30004   1     L4A        gr6=(*)_object._object.ob_type(gr3,4)
 1757| 005404 ori        60000000   1                                                                                                                               0| 0054A8 stwu       9421FF90   1     ST4U       gr1,#stack(gr1,-112)=gr1
    0| 005408 b          4BFFFEB0   0     B         CL.508,-1                                                                                                       0| 0054AC stw        90010078   1     ST4A       #stack(gr1,120)=gr0
 1759|                                CL.506:                                                                                                                       0| 0054B0 stw        93E1006C   1     ST4A       #stack(gr1,108)=gr31
 1760| 00540C bl         4BFFABF5   0     CALL      gr3=_PyObject_GC_New,1,(*)_typeobject",gr3,#ProcAlias",_PyObject_GC_New",fcr",gr1,cr[01567]",gr0",gr4"-gr12     0| 0054B4 stw        93C10068   1     ST4A       #stack(gr1,104)=gr30
 1760| 005410 ori        60000000   1                                                                                                                               0| 0054B8 stw        93A10064   1     ST4A       #stack(gr1,100)=gr29
 1762| 005414 cmpwi      2C030000   1     C4        cr0=gr3,0                                                                                                     856| 0054BC lwz        83E200D8   1     L4A        gr31=.PyCoro_Type(gr2,0)
 1762| 005418 bc         41820048   1     BT        CL.2149,cr0,0x4/eq,taken=30%(30,70)                                                                           128| 0054C0 lwz        80030004   1     L4A        gr0=(*)C_object._object.ob_type(gr3,4)
  403| 00541C lwz        809F0000   2     L4A       gr4=(*)_object._object.ob_refcnt(gr31,0)                                                                        0| 0054C4 stw        93810060   1     ST4A       #stack(gr1,96)=gr28
    0| 005420 lwz        81020018   1     L4A       gr8=.+CONSTANT_AREA(gr2,0)                                                                                    833| 0054C8 lwz        83C200D4   1     L4A        gr30=.PyGen_Type(gr2,0)
    0| 005424 lwz        80010058   1     L4A       gr0=#stack(gr1,88)                                                                                            867| 0054CC stw        90410014   1     ST4A       #cur_toc(gr1,20)=gr2
 1760| 005428 ori        607C0000   1     LR        gr28=gr3                                                                                                      128| 0054D0 cmplw      7C00F840   1     CL4        cr0=gr0,gr31
  401| 00542C lwz        80620004   1     L4A       gr3=._Py_RefTotal(gr2,0)                                                                                      128| 0054D4 cmplw      7C80F040   1     CL4        cr1=gr0,gr30
  403| 005430 addi       38840001   1     AI        gr4=gr4,1                                                                                                     856| 0054D8 bc         41820330   0     BT         CL.2129,cr0,0x4/eq,taken=30%(30,70)
  403| 005434 stw        909F0000   1     ST4A      (*)_object._object.ob_refcnt(gr31,0)=gr4                                                                      833| 0054DC bc         40860014   1     BF         CL.1559,cr1,0x4/eq,taken=50%(0,0)
   27| 005438 addi       38C81110   1     AI        gr6=gr8,4368                                                                                                  834| 0054E0 lwz        80A30010   3     L4A        gr5=(*)_object%##3(gr3,16)
    0| 00543C mtspr      7C0803A6   1     LLR       lr=gr0                                                                                                        835| 0054E4 lwz        8005001C   2     L4A        gr0=(*)aggr#5.co_flags(gr5,28)
 1766| 005440 stw        93FC0008   1     ST4A      (*)aggr#C.agw_val(gr28,8)=gr31                                                                                835| 0054E8 andi.      70000100   2     RN4_R      gr0,cr0=gr0,0,0x100
   30| 005444 lwz        801CFFF8   1     L4A       gr0=(*)_object%##2(gr28,-8)                                                                                   835| 0054EC bc         408202F0   1     BF         CL.1995,cr0,0x4/eq,taken=30%(30,70)
  401| 005448 lwz        80830000   1     L4A       gr4=<s117:d0:l4>(gr3,0)                                                                                       838|                                CL.1559:
   30| 00544C cmpwi      2C000000   1     C4        cr0=gr0,0                                                                                                     863| 0054F0 lwz        80A60028   1     L4A        gr5=(*)_typeobject._typeobject.tp_as_async(gr6,40)







Wed Apr 15 07:30:04 CDT 2020  Page 159


  401| 005450 addi       38040001   1     AI        gr0=gr4,1                                                                                                       0| 0054F4 or.        7CA02B79   2     LR_R       gr0,cr0=gr5
  401| 005454 stw        90030000   1     ST4A      <s117:d0:l4>(gr3,0)=gr0                                                                                       863| 0054F8 bc         418202AC   1     BT         CL.2130,cr0,0x4/eq,taken=30%(30,70)
   30| 005458 bc         4082FEA0   0     BF        CL.1855,cr0,0x4/eq,taken=10%(10,90)                                                                           864| 0054FC lwz        80850000   1     L4A        gr4=(*)aggr#9.am_await(gr5,0)
   30| 00545C b          4BFFFEC4   1     B         CL.1114,-1                                                                                                      0| 005500 or.        7C802379   2     LR_R       gr0,cr0=gr4
    0|                                CL.2149:                                                                                                                    866| 005504 bc         41820268   1     BT         CL.2128,cr0,0x4/eq,taken=30%(30,70)
 1763| 005460 addi       38600000   1     LI        gr3=0                                                                                                         867| 005508 lwz        80040000   1     L4A        gr0=#fnc_adr(gr4,0)
    0| 005464 lwz        80010058   1     L4A       gr0=#stack(gr1,88)                                                                                            867| 00550C lwz        81640008   1     L4A        gr11=#new_env(gr4,8)
    0| 005468 lwz        83E1004C   1     L4A       gr31=#stack(gr1,76)                                                                                           867| 005510 mtspr      7C0903A6   1     LCTR       ctr=gr0
 1770| 00546C addi       38210050   1     AI        gr1=gr1,80                                                                                                    867| 005514 lwz        80440004   1     CALL       gr3=gr4,1,(*)_object",gr3,#ProcAlias",fcr",(*)_object*()",gr1,cr[01567]",gr0",gr4"-gr12",fp0"-fp13",mq",lr
    0| 005470 mtspr      7C0803A6   1     LLR       lr=gr0                                                                                                        867| 005518 bcctrl     4E800421   0
 1770| 005474 bclr       4E800020   3     BA        lr                                                                                                            867| 00551C lwz        80410014   1
    0|                                CL.1858:                                                                                                                    868| 005520 or.        7C7C1B79   1     LR_R       gr28,cr0=gr3
 1752| 005478 lwz        80820018   1     L4A       gr4=.+CONSTANT_AREA(gr2,0)                                                                                    868| 005524 bc         41820228   1     BT         CL.2127,cr0,0x4/eq,taken=30%(30,70)
 1752| 00547C addi       38A006D8   1     LI        gr5=1752                                                                                                      872| 005528 lwz        80A200B4   2     L4A        gr5=.PyExc_TypeError(gr2,0)
 1752| 005480 addi       386416E4   1     AI        gr3=gr4,5860                                                                                                  872| 00552C lwz        83A20018   1     L4A        gr29=.+CONSTANT_AREA(gr2,0)
 1752| 005484 addi       38841110   1     AI        gr4=gr4,4368                                                                                                    0| 005530 lwz        80010078   1     L4A        gr0=#stack(gr1,120)
 1752| 005488 bl         4BFFAB79   0     CALL      __assert,3,gr3-gr5,#ProcAlias",__assert",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",lr",fcr",xer",f     0| 005534 mtspr      7C0803A6   2     LLR        lr=gr0
 1752| 00548C ori        60000000   1                                                                                                                             128| 005538 lwz        80030004   1     L4A        gr0=(*)C_object._object.ob_type(gr3,4)
 1754| 005490 lwz        80A20020   1     L4A       gr5=.$STATIC(gr2,0)                                                                                           128| 00553C cmplw      7C00F040   2     CL4        cr0=gr0,gr30
    0| 005494 lwz        80620014   1     L4A       gr3=._PyAsyncGenWrappedValue_Type(gr2,0)                                                                      128| 005540 cmplw      7C80F840   1     CL4        cr1=gr0,gr31
 1754| 005498 lwz        80850008   1     L4A       gr4=ag_value_freelist_free(gr5,8)                                                                             869| 005544 bc         418601FC   1     BT         CL.2126,cr1,0x4/eq,taken=40%(40,60)
 1754| 00549C cmpwi      2C040000   2     C4        cr0=gr4,0                                                                                                     876| 005548 ori        60A40000   1     LR         gr4=gr5
 1754| 0054A0 bc         4182FF6C   1     BT        CL.506,cr0,0x4/eq,taken=40%(40,60)                                                                            875| 00554C ori        60060000   1     LR         gr6=gr0
    0| 0054A4 b          4BFFFDF4   1     B         CL.1853,-1                                                                                                      0| 005550 lwz        83E1006C   1     L4A        gr31=#stack(gr1,108)
     |               Tag Table                                                                                                                                      0| 005554 lwz        83C10068   1     L4A        gr30=#stack(gr1,104)
     | 0054A8        00000000 00002041 80040100 00000000 00000248 001A5F50                                                                                        833| 005558 bc         408201D8   0     BF         CL.1998,cr0,0x4/eq,taken=50%(0,0)
     | 0054C0        79417379 6E634765 6E56616C 75655772 61707065 724E6577                                                                                        834| 00555C lwz        80E30010   1     L4A        gr7=(*)_object%##3(gr3,16)
     |               Instruction count          146                                                                                                               835| 005560 lwz        8007001C   2     L4A        gr0=(*)aggr#5.co_flags(gr7,28)
     |               Straight-line exec time    149                                                                                                               835| 005564 andi.      70000100   2     RN4_R      gr0,cr0=gr0,0,0x100
 GPR's set/used:   ssus ssss ssss s---  ---- ---- ---- ----                                                                                                       835| 005568 bc         40820110   1     BF         CL.524,cr0,0x4/eq,taken=40%(40,60)
 FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----                                                                                                       875| 00556C lwz        80660070   1     L4A        gr3=(*)_typeobject._typeobject.tp_iternext(gr6,112)
 CCR's set/used:   ss-- -sss                                                                                                                                      875| 005570 cmpwi      2C030000   2     C4         cr0=gr3,0
     | 000000                             PDEF     PyAsyncGen_New                                                                                                 875| 005574 bc         41820010   1     BT         CL.531,cr0,0x4/eq,taken=40%(40,60)
 1416|                                    PROC      f,name,qualname,gr3-gr5                                                                                         0|                                CL.1999:
    0| 0054E0 mfspr      7C0802A6   1     LFLR      gr0=lr                                                                                                        875| 005578 lwz        80020108   1     L4A        gr0=._PyObject_NextNotImplemented(gr2,0)
 1419| 0054E4 ori        60A60000   1     LR        gr6=gr5                                                                                                       875| 00557C cmplw      7C030040   2     CL4        cr0=gr3,gr0
 1419| 0054E8 ori        60850000   1     LR        gr5=gr4                                                                                                       875| 005580 bc         408200E4   1     BF         CL.2131,cr0,0x4/eq,taken=30%(30,70)
 1419| 0054EC ori        60640000   1     LR        gr4=gr3                                                                                                       875|                                CL.531:
 1419| 0054F0 lwz        806200E0   1     L4A       gr3=.PyAsyncGen_Type(gr2,0)                                                                                   876| 005584 ori        63BF0000   1     LR         gr31=gr29
    0| 0054F4 stw        90010008   1     ST4A      #stack(gr1,8)=gr0                                                                                             876| 005588 lwz        80A6000C   1     L4A        gr5=(*)_typeobject._typeobject.tp_name(gr6,12)
    0| 0054F8 stwu       9421FFC0   1     ST4U      gr1,#stack(gr1,-64)=gr1                                                                                       876| 00558C lwz        80640000   1     L4A        gr3=PyExc_TypeError(gr4,0)
 1419| 0054FC bl         4BFFCDA5   0     CALL      gr3=gen_new_with_qualname,4,(*)_typeobject",gr3,(*)_frame",gr4,(*)_object",gr5,(*)_object",gr6,#ProcAlias",   876| 005590 addi       389F172C   1     AI         gr4=gr31,5932
 1424| 005500 addi       38000000   1     LI        gr0=0                                                                                                         876| 005594 bl         4BFFAA6D   0     CALL       gr3=PyErr_Format,3,(*)_object",gr3,gr4,(*)Cuchar",gr5,#ProcAlias",PyErr_Format",fcr",gr1,cr[01567]",gr0",g
 1421| 005504 cmpwi      2C030000   1     C4        cr0=gr3,0                                                                                                     876| 005598 ori        60000000   1
 1421| 005508 bc         41820024   1     BT        CL.1882,cr0,0x4/eq,taken=50%(0,0)                                                                             880| 00559C cmpwi      2C1C0000   1     C4         cr0=gr28,0
 1424| 00550C stw        90030030   2     ST4A      (*)aggr#4.ag_finalizer(gr3,48)=gr0                                                                            415| 0055A0 lwz        80820004   1     L4A        gr4=._Py_RefTotal(gr2,0)
 1425| 005510 stw        90030038   1     ST4A      (*)aggr#4.ag_closed(gr3,56)=gr0                                                                               880| 0055A4 ori        63850000   1     LR         gr5=gr28
 1426| 005514 stw        90030034   1     ST4A      (*)aggr#4.ag_hooks_inited(gr3,52)=gr0                                                                         880| 0055A8 bc         4182009C   0     BT         CL.2125,cr0,0x4/eq,taken=50%(0,0)
 1427| 005518 stw        9003003C   1     ST4A      (*)aggr#4.ag_running_async(gr3,60)=gr0                                                                        880| 0055AC addi       3B800000   2     LI         gr28=0
    0| 00551C lwz        80810048   1     L4A       gr4=#stack(gr1,72)                                                                                            408| 0055B0 addi       387F1110   1     AI         gr3=gr31,4368
 1429| 005520 addi       38210040   1     AI        gr1=gr1,64                                                                                                      0| 0055B4 lwz        83A10064   1     L4A        gr29=#stack(gr1,100)
    0| 005524 mtspr      7C8803A6   1     LLR       lr=gr4                                                                                                        417| 0055B8 lwz        80C50000   1     L4A        gr6=(*)_object._object.ob_refcnt(gr5,0)
 1429| 005528 bclr       4E800020   3     BA        lr                                                                                                            415| 0055BC lwz        80E40000   1     L4A        gr7=_Py_RefTotal(gr4,0)
    0|                                CL.1882:                                                                                                                    417| 0055C0 addi       3806FFFF   1     AI         gr0=gr6,-1
 1422| 00552C addi       38600000   1     LI        gr3=0                                                                                                         417| 0055C4 stw        90050000   1     ST4A       (*)_object._object.ob_refcnt(gr5,0)=gr0
    0| 005530 lwz        80010048   1     L4A       gr0=#stack(gr1,72)                                                                                            415| 0055C8 addi       38C7FFFF   1     AI         gr6=gr7,-1







Wed Apr 15 07:30:04 CDT 2020  Page 160


 1429| 005534 addi       38210040   1     AI        gr1=gr1,64                                                                                                    415| 0055CC stw        90C40000   1     ST4A       _Py_RefTotal(gr4,0)=gr6
    0| 005538 mtspr      7C0803A6   1     LLR       lr=gr0                                                                                                        417| 0055D0 cmpwi      2C000000   1     C4         cr0=gr0,0
 1429| 00553C bclr       4E800020   3     BA        lr                                                                                                            417| 0055D4 bc         41820048   1     BT         CL.1092,cr0,0x4/eq,taken=40%(40,60)
     |               Tag Table                                                                                                                                      0| 0055D8 lwz        83E1006C   2     L4A        gr31=#stack(gr1,108)
     | 005540        00000000 00002041 80000300 00000000 00000060 000E5079                                                                                        419| 0055DC bc         4180001C   0     BT         CL.2132,cr0,0x1/lt,taken=40%(40,60)
     | 005558        4173796E 6347656E 5F4E6577                                                                                                                     0|                                CL.2001:
     |               Instruction count           24                                                                                                               883| 0055E0 ori        63830000   1     LR         gr3=gr28
     |               Straight-line exec time     28                                                                                                                 0| 0055E4 lwz        83810060   1     L4A        gr28=#stack(gr1,96)
 GPR's set/used:   ssus ssss ssss s---  ---- ---- ---- ----                                                                                                         0| 0055E8 lwz        80010078   1     L4A        gr0=#stack(gr1,120)
 FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----                                                                                                       890| 0055EC addi       38210070   1     AI         gr1=gr1,112
 CCR's set/used:   ss-- -sss                                                                                                                                        0| 0055F0 mtspr      7C0803A6   1     LLR        lr=gr0
     | 000000                             PDEF     PyCoro_New                                                                                                     890| 0055F4 bclr       4E800020   3     BA         lr
 1137|                                    PROC      f,name,qualname,gr3-gr5                                                                                         0|                                CL.2132:
    0| 005580 mfspr      7C0802A6   1     LFLR      gr0=lr                                                                                                        420| 0055F8 addi       38800370   1     LI         gr4=880
    0| 005584 ori        60A60000   1     LR        gr6=gr5                                                                                                       420| 0055FC bl         4BFFAA05   0     CALL       _Py_NegativeRefcount,3,(*)Cuchar",gr3,gr4,(*)_object",gr5,#ProcAlias",_Py_NegativeRefcount",fcr",gr1,cr[01
    0| 005588 ori        60850000   1     LR        gr5=gr4                                                                                                       420| 005600 ori        60000000   1
    0| 00558C stw        90010008   1     ST4A      #stack(gr1,8)=gr0                                                                                             883| 005604 ori        63830000   1     LR         gr3=gr28
    0| 005590 ori        60600000   1     LR        gr0=gr3                                                                                                         0| 005608 lwz        83810060   1     L4A        gr28=#stack(gr1,96)
 1139| 005594 lwz        806200D8   1     L4A       gr3=.PyCoro_Type(gr2,0)                                                                                         0| 00560C lwz        80010078   1     L4A        gr0=#stack(gr1,120)
    0| 005598 stwu       9421FF90   1     ST4U      gr1,#stack(gr1,-112)=gr1                                                                                      890| 005610 addi       38210070   1     AI         gr1=gr1,112
 1139| 00559C ori        60040000   1     LR        gr4=gr0                                                                                                         0| 005614 mtspr      7C0803A6   1     LLR        lr=gr0
 1139| 0055A0 bl         4BFFCD01   0     CALL      gr3=gen_new_with_qualname,4,(*)_typeobject",gr3,(*)_frame",gr4,(*)_object",gr5,(*)_object",gr6,#ProcAlias",   890| 005618 bclr       4E800020   3     BA         lr
 1139| 0055A4 or.        7C651B79   1     LR_R      gr5,cr0=gr3                                                                                                   423|                                CL.1092:
   67| 0055A8 lwz        808200A4   1     L4A       gr4=._PyRuntime(gr2,0)                                                                                        425| 00561C ori        60A30000   1     LR         gr3=gr5
 1140| 0055AC bc         41820068   0     BT        CL.1946,cr0,0x4/eq,taken=30%(30,70)                                                                             0| 005620 lwz        83E1006C   1     L4A        gr31=#stack(gr1,108)
   54| 0055B0 lwz        806401A0   2     L4A       gr3=<s149:d416:l4>(gr4,416)                                                                                   425| 005624 bl         4BFFA9DD   0     CALL       _Py_Dealloc,1,(*)_object",gr3,#ProcAlias",_Py_Dealloc",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",
 1145| 0055B4 lwz        80630074   2     L4A       gr3=(*)_ts._ts.coroutine_origin_tracking_depth(gr3,116)                                                       425| 005628 ori        60000000   1
 1147| 0055B8 cmpwi      2C030000   2     C4        cr0=gr3,0                                                                                                     883| 00562C ori        63830000   1     LR         gr3=gr28
 1147| 0055BC bc         418200A0   1     BT        CL.2145,cr0,0x4/eq,taken=30%(30,70)                                                                             0| 005630 lwz        83810060   1     L4A        gr28=#stack(gr1,96)
 1149| 0055C0 stw        90A10064   1     ST4A      #parameter_store0(gr1,100)=gr5                                                                                  0| 005634 lwz        80010078   1     L4A        gr0=#stack(gr1,120)
 1150| 0055C4 bl         4BFFC45D   0     CALL      gr3=compute_cr_origin,1,gr3,#ProcAlias",compute_cr_origin",fcr",gr1,cr[01567]",gr0",gr4"-gr12",fp0"-fp13",m   890| 005638 addi       38210070   1     AI         gr1=gr1,112
 1152| 0055C8 cmpwi      2C030000   1     C4        cr0=gr3,0                                                                                                       0| 00563C mtspr      7C0803A6   1     LLR        lr=gr0
  415| 0055CC lwz        80820004   1     L4A       gr4=._Py_RefTotal(gr2,0)                                                                                      890| 005640 bclr       4E800020   3     BA         lr
 1150| 0055D0 lwz        80A10064   1     L4A       gr5=#parameter_store0(gr1,100)                                                                                  0|                                CL.2125:
 1151| 0055D4 stw        90650030   2     ST4A      (*)aggr#6.cr_origin(gr5,48)=gr3                                                                               883| 005644 ori        63830000   1     LR         gr3=gr28
 1152| 0055D8 bc         40820070   0     BF        CL.1944,cr0,0x4/eq,taken=30%(30,70)                                                                             0| 005648 lwz        83E1006C   1     L4A        gr31=#stack(gr1,108)
  417| 0055DC lwz        80C50000   1     L4A       gr6=(*)_object._object.ob_refcnt(gr5,0)                                                                         0| 00564C lwz        83A10064   1     L4A        gr29=#stack(gr1,100)
    0| 0055E0 lwz        80620018   1     L4A       gr3=.+CONSTANT_AREA(gr2,0)                                                                                      0| 005650 lwz        83810060   1     L4A        gr28=#stack(gr1,96)
  417| 0055E4 addi       3806FFFF   1     AI        gr0=gr6,-1                                                                                                      0| 005654 lwz        80010078   1     L4A        gr0=#stack(gr1,120)
  417| 0055E8 stw        90050000   1     ST4A      (*)_object._object.ob_refcnt(gr5,0)=gr0                                                                       890| 005658 addi       38210070   1     AI         gr1=gr1,112
  415| 0055EC lwz        80C40000   1     L4A       gr6=<s117:d0:l4>(gr4,0)                                                                                         0| 00565C mtspr      7C0803A6   1     LLR        lr=gr0
  408| 0055F0 addi       38631110   1     AI        gr3=gr3,4368                                                                                                  890| 005660 bclr       4E800020   3     BA         lr
  415| 0055F4 addi       38C6FFFF   1     AI        gr6=gr6,-1                                                                                                      0|                                CL.2131:
  415| 0055F8 stw        90C40000   1     ST4A      <s117:d0:l4>(gr4,0)=gr6                                                                                       883| 005664 ori        63830000   1     LR         gr3=gr28
  417| 0055FC cmpwi      2C000000   1     C4        cr0=gr0,0                                                                                                       0| 005668 lwz        83A10064   1     L4A        gr29=#stack(gr1,100)
  417| 005600 bc         41820028   1     BT        CL.1106,cr0,0x4/eq,taken=40%(40,60)                                                                             0| 00566C lwz        83810060   1     L4A        gr28=#stack(gr1,96)
  420| 005604 addi       38800481   2     LI        gr4=1153                                                                                                      890| 005670 addi       38210070   1     AI         gr1=gr1,112
  419| 005608 bc         4080000C   0     BF        CL.1946,cr0,0x1/lt,taken=30%(30,70)                                                                           890| 005674 bclr       4E800020   0     BA         lr
  420| 00560C bl         4BFFA9F5   1     CALL      _Py_NegativeRefcount,3,(*)Cuchar",gr3,gr4,(*)_object",gr5,#ProcAlias",_Py_NegativeRefcount",fcr",gr1,cr[015   869|                                CL.524:
  420| 005610 ori        60000000   1                                                                                                                             872| 005678 addi       389D1708   1     AI         gr4=gr29,5896
    0|                                CL.1946:                                                                                                                    872| 00567C lwz        80650000   1     L4A        gr3=PyExc_TypeError(gr5,0)
 1141| 005614 addi       38600000   1     LI        gr3=0                                                                                                         872| 005680 bl         4BFFA981   0     CALL       PyErr_SetString,2,(*)_object",gr3,gr4,#ProcAlias",PyErr_SetString",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0
 1159| 005618 addi       38210070   1     AI        gr1=gr1,112                                                                                                   872| 005684 ori        60000000   1
    0| 00561C lwz        80010008   1     L4A       gr0=#stack(gr1,8)                                                                                             874| 005688 cmpwi      2C1C0000   1     C4         cr0=gr28,0
    0| 005620 mtspr      7C0803A6   2     LLR       lr=gr0                                                                                                        415| 00568C lwz        80820004   1     L4A        gr4=._Py_RefTotal(gr2,0)
 1159| 005624 bclr       4E800020   3     BA        lr                                                                                                            874| 005690 ori        63850000   1     LR         gr5=gr28







Wed Apr 15 07:30:04 CDT 2020  Page 161


  423|                                CL.1106:                                                                                                                    874| 005694 bc         41820080   0     BT         CL.2124,cr0,0x4/eq,taken=50%(0,0)
  425| 005628 ori        60A30000   1     LR        gr3=gr5                                                                                                       874| 005698 addi       3B800000   2     LI         gr28=0
  425| 00562C bl         4BFFA9D5   0     CALL      _Py_Dealloc,1,(*)_object",gr3,#ProcAlias",_Py_Dealloc",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",l   408| 00569C addi       387D1110   1     AI         gr3=gr29,4368
  425| 005630 ori        60000000   1                                                                                                                             417| 0056A0 lwz        80C50000   1     L4A        gr6=(*)_object._object.ob_refcnt(gr5,0)
 1141| 005634 addi       38600000   1     LI        gr3=0                                                                                                         415| 0056A4 lwz        80E40000   1     L4A        gr7=_Py_RefTotal(gr4,0)
 1159| 005638 addi       38210070   1     AI        gr1=gr1,112                                                                                                   417| 0056A8 addi       3806FFFF   1     AI         gr0=gr6,-1
    0| 00563C lwz        80010008   1     L4A       gr0=#stack(gr1,8)                                                                                             417| 0056AC stw        90050000   1     ST4A       (*)_object._object.ob_refcnt(gr5,0)=gr0
    0| 005640 mtspr      7C0803A6   2     LLR       lr=gr0                                                                                                        415| 0056B0 addi       38C7FFFF   1     AI         gr6=gr7,-1
 1159| 005644 bclr       4E800020   3     BA        lr                                                                                                            415| 0056B4 stw        90C40000   1     ST4A       _Py_RefTotal(gr4,0)=gr6
    0|                                CL.1944:                                                                                                                    417| 0056B8 cmpwi      2C000000   1     C4         cr0=gr0,0
 1158| 005648 ori        60A30000   1     LR        gr3=gr5                                                                                                       417| 0056BC bc         41820030   1     BT         CL.1088,cr0,0x4/eq,taken=40%(40,60)
 1159| 00564C addi       38210070   1     AI        gr1=gr1,112                                                                                                     0| 0056C0 lwz        83A10064   2     L4A        gr29=#stack(gr1,100)
    0| 005650 lwz        80010008   1     L4A       gr0=#stack(gr1,8)                                                                                             419| 0056C4 bc         4080FF1C   0     BF         CL.2001,cr0,0x1/lt,taken=60%(60,40)
    0| 005654 mtspr      7C0803A6   2     LLR       lr=gr0                                                                                                        420| 0056C8 addi       3880036A   2     LI         gr4=874
 1159| 005658 bclr       4E800020   3     BA        lr                                                                                                            420| 0056CC bl         4BFFA935   0     CALL       _Py_NegativeRefcount,3,(*)Cuchar",gr3,gr4,(*)_object",gr5,#ProcAlias",_Py_NegativeRefcount",fcr",gr1,cr[01
    0|                                CL.2145:                                                                                                                    420| 0056D0 ori        60000000   1
 1148| 00565C addi       38000000   1     LI        gr0=0                                                                                                         883| 0056D4 ori        63830000   1     LR         gr3=gr28
 1159| 005660 addi       38210070   1     AI        gr1=gr1,112                                                                                                     0| 0056D8 lwz        83810060   1     L4A        gr28=#stack(gr1,96)
 1158| 005664 ori        60A30000   1     LR        gr3=gr5                                                                                                         0| 0056DC lwz        80010078   1     L4A        gr0=#stack(gr1,120)
 1148| 005668 stw        90050030   1     ST4A      (*)aggr#6.cr_origin(gr5,48)=gr0                                                                               890| 0056E0 addi       38210070   1     AI         gr1=gr1,112
    0| 00566C lwz        80010008   1     L4A       gr0=#stack(gr1,8)                                                                                               0| 0056E4 mtspr      7C0803A6   1     LLR        lr=gr0
    0| 005670 mtspr      7C0803A6   2     LLR       lr=gr0                                                                                                        890| 0056E8 bclr       4E800020   3     BA         lr
 1159| 005674 bclr       4E800020   3     BA        lr                                                                                                            423|                                CL.1088:
     |               Tag Table                                                                                                                                    425| 0056EC ori        60A30000   1     LR         gr3=gr5
     | 005678        00000000 00002041 80000300 00000000 000000F8 000A5079                                                                                          0| 0056F0 lwz        83A10064   1     L4A        gr29=#stack(gr1,100)
     | 005690        436F726F 5F4E6577                                                                                                                            425| 0056F4 bl         4BFFA90D   0     CALL       _Py_Dealloc,1,(*)_object",gr3,#ProcAlias",_Py_Dealloc",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",
     |               Instruction count           62                                                                                                               425| 0056F8 ori        60000000   1
     |               Straight-line exec time     73                                                                                                               883| 0056FC ori        63830000   1     LR         gr3=gr28
 GPR's set/used:   ssus ssss ssss s---  ---- ---- ---- --ss                                                                                                         0| 005700 lwz        83810060   1     L4A        gr28=#stack(gr1,96)
 FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----                                                                                                         0| 005704 lwz        80010078   1     L4A        gr0=#stack(gr1,120)
 CCR's set/used:   ss-- -sss                                                                                                                                      890| 005708 addi       38210070   1     AI         gr1=gr1,112
     | 000000                             PDEF     _PyCoro_GetAwaitableIter                                                                                         0| 00570C mtspr      7C0803A6   1     LLR        lr=gr0
  851|                                    PROC      o,gr3                                                                                                         890| 005710 bclr       4E800020   3     BA         lr
    0| 0056A0 mfspr      7C0802A6   1     LFLR      gr0=lr                                                                                                          0|                                CL.2124:
  128| 0056A4 lwz        80C30004   1     L4A       gr6=(*)C_object._object.ob_type(gr3,4)                                                                        883| 005714 ori        63830000   1     LR         gr3=gr28
  833| 0056A8 lwz        808200D4   1     L4A       gr4=.PyGen_Type(gr2,0)                                                                                          0| 005718 lwz        83A10064   1     L4A        gr29=#stack(gr1,100)
  862| 0056AC lwz        80E30004   1     L4A       gr7=(*)_object._object.ob_type(gr3,4)                                                                           0| 00571C lwz        83810060   1     L4A        gr28=#stack(gr1,96)
  128| 0056B0 cmplw      7C862040   1     CL4       cr1=gr6,gr4                                                                                                     0| 005720 lwz        80010078   1     L4A        gr0=#stack(gr1,120)
    0| 0056B4 stw        90010008   1     ST4A      #stack(gr1,8)=gr0                                                                                             890| 005724 addi       38210070   1     AI         gr1=gr1,112
    0| 0056B8 stw        93E1FFFC   1     ST4A      #stack(gr1,-4)=gr31                                                                                             0| 005728 mtspr      7C0803A6   1     LLR        lr=gr0
    0| 0056BC stw        93C1FFF8   1     ST4A      #stack(gr1,-8)=gr30                                                                                           890| 00572C bclr       4E800020   3     BA         lr
  856| 0056C0 lwz        800200D8   1     L4A       gr0=.PyCoro_Type(gr2,0)                                                                                         0|                                CL.1998:
    0| 0056C4 stwu       9421FF70   1     ST4U      gr1,#stack(gr1,-144)=gr1                                                                                      875| 005730 lwz        80660070   1     L4A        gr3=(*)_typeobject._typeobject.tp_iternext(gr6,112)
  128| 0056C8 cmplw      7C060040   1     CL4       cr0=gr6,gr0                                                                                                   875| 005734 cmpwi      2C030000   2     C4         cr0=gr3,0
  867| 0056CC stw        90410014   1     ST4A      #cur_toc(gr1,20)=gr2                                                                                          875| 005738 bc         4182FE4C   1     BT         CL.531,cr0,0x4/eq,taken=40%(40,60)
  856| 0056D0 bc         41820268   0     BT        CL.1954,cr0,0x4/eq,taken=30%(30,70)                                                                             0| 00573C b          4BFFFE3C   1     B          CL.1999,-1
  833| 0056D4 bc         40860014   1     BF        CL.1530,cr1,0x4/eq,taken=50%(0,0)                                                                               0|                                CL.2126:
  834| 0056D8 lwz        80C30010   3     L4A       gr6=(*)_object%##3(gr3,16)                                                                                      0| 005740 lwz        83E1006C   1     L4A        gr31=#stack(gr1,108)
  835| 0056DC lwz        80C6001C   2     L4A       gr6=(*)aggr#5.co_flags(gr6,28)                                                                                  0| 005744 lwz        83C10068   1     L4A        gr30=#stack(gr1,104)
  835| 0056E0 andi.      70C60100   2     RN4_R     gr6,cr0=gr6,0,0x100                                                                                             0| 005748 b          4BFFFF30   0     B          CL.524,-1
  835| 0056E4 bc         40820254   1     BF        CL.1954,cr0,0x4/eq,taken=30%(30,70)                                                                             0|                                CL.2127:
  838|                                CL.1530:                                                                                                                    883| 00574C ori        63830000   1     LR         gr3=gr28
  863| 0056E8 lwz        80C70028   1     L4A       gr6=(*)_typeobject._typeobject.tp_as_async(gr7,40)                                                              0| 005750 lwz        83E1006C   1     L4A        gr31=#stack(gr1,108)
    0| 0056EC or.        7CC83379   2     LR_R      gr8,cr0=gr6                                                                                                     0| 005754 lwz        83C10068   1     L4A        gr30=#stack(gr1,104)
  863| 0056F0 bc         41820218   1     BT        CL.2078,cr0,0x4/eq,taken=30%(30,70)                                                                             0| 005758 lwz        83810060   1     L4A        gr28=#stack(gr1,96)
  864| 0056F4 lwz        80A60000   1     L4A       gr5=(*)aggr#9.am_await(gr6,0)                                                                                   0| 00575C lwz        80010078   1     L4A        gr0=#stack(gr1,120)







Wed Apr 15 07:30:04 CDT 2020  Page 162


    0| 0056F8 or.        7CA62B79   2     LR_R      gr6,cr0=gr5                                                                                                   890| 005760 addi       38210070   1     AI         gr1=gr1,112
  866| 0056FC bc         418201DC   1     BT        CL.522,cr0,0x4/eq,taken=30%(30,70)                                                                              0| 005764 mtspr      7C0803A6   1     LLR        lr=gr0
    0| 005700 stw        90010080   1     ST4A      #parameter_store0(gr1,128)=gr0                                                                                890| 005768 bclr       4E800020   3     BA         lr
    0| 005704 stw        90810084   1     ST4A      #parameter_store1(gr1,132)=gr4                                                                                  0|                                CL.2128:
  867| 005708 lwz        80050000   1     L4A       gr0=#fnc_adr(gr5,0)                                                                                           886| 00576C lwz        806200B4   1     L4A        gr3=.PyExc_TypeError(gr2,0)
  867| 00570C lwz        81650008   1     L4A       gr11=#new_env(gr5,8)                                                                                          886| 005770 lwz        80820018   1     L4A        gr4=.+CONSTANT_AREA(gr2,0)
  867| 005710 mtspr      7C0903A6   1     LCTR      ctr=gr0                                                                                                         0| 005774 lwz        83E1006C   1     L4A        gr31=#stack(gr1,108)
  867| 005714 lwz        80450004   1     CALL      gr3=gr5,1,(*)_object",gr3,#ProcAlias",fcr",(*)_object*()",gr1,cr[01567]",gr0",gr4"-gr12",fp0"-fp13",mq",lr"     0| 005778 lwz        83C10068   1     L4A        gr30=#stack(gr1,104)
  867| 005718 bcctrl     4E800421   0                                                                                                                             886| 00577C lwz        80A6000C   1     L4A        gr5=(*)_typeobject._typeobject.tp_name(gr6,12)
  867| 00571C lwz        80410014   1                                                                                                                             886| 005780 addi       38841760   1     AI         gr4=gr4,5984
  867| 005720 or.        7C7E1B79   1     LR_R      gr30,cr0=gr3                                                                                                  886| 005784 lwz        80630000   1     L4A        gr3=PyExc_TypeError(gr3,0)
  867| 005724 lwz        80010080   1     L4A       gr0=#parameter_store0(gr1,128)                                                                                886| 005788 bl         4BFFA879   0     CALL       gr3=PyErr_Format,3,(*)_object",gr3,gr4,(*)Cuchar",gr5,#ProcAlias",PyErr_Format",fcr",gr1,cr[01567]",gr0",g
  867| 005728 lwz        80810084   1     L4A       gr4=#parameter_store1(gr1,132)                                                                                886| 00578C ori        60000000   1
  868| 00572C bc         418200B4   0     BT        CL.1960,cr0,0x4/eq,taken=30%(30,70)                                                                           889| 005790 addi       38600000   1     LI         gr3=0
  128| 005730 lwz        80C30004   2     L4A       gr6=(*)C_object._object.ob_type(gr3,4)                                                                          0| 005794 lwz        80010078   1     L4A        gr0=#stack(gr1,120)
  872| 005734 lwz        80A200B4   1     L4A       gr5=.PyExc_TypeError(gr2,0)                                                                                   890| 005798 addi       38210070   1     AI         gr1=gr1,112
  872| 005738 lwz        83E20018   1     L4A       gr31=.+CONSTANT_AREA(gr2,0)                                                                                     0| 00579C mtspr      7C0803A6   1     LLR        lr=gr0
  128| 00573C cmplw      7C062040   1     CL4       cr0=gr6,gr4                                                                                                   890| 0057A0 bclr       4E800020   3     BA         lr
  128| 005740 cmplw      7C860040   1     CL4       cr1=gr6,gr0                                                                                                     0|                                CL.2130:
  869| 005744 bc         41860110   1     BT        CL.524,cr1,0x4/eq,taken=40%(40,60)                                                                            886| 0057A4 lwz        806200B4   1     L4A        gr3=.PyExc_TypeError(gr2,0)
  875| 005748 lwz        80C30004   2     L4A       gr6=(*)_object._object.ob_type(gr3,4)                                                                         886| 0057A8 lwz        80820018   1     L4A        gr4=.+CONSTANT_AREA(gr2,0)
  876| 00574C ori        60A40000   1     LR        gr4=gr5                                                                                                         0| 0057AC lwz        83E1006C   1     L4A        gr31=#stack(gr1,108)
  833| 005750 bc         40820178   0     BF        CL.1957,cr0,0x4/eq,taken=50%(0,0)                                                                               0| 0057B0 lwz        83C10068   1     L4A        gr30=#stack(gr1,104)
  834| 005754 lwz        80E30010   2     L4A       gr7=(*)_object%##3(gr3,16)                                                                                    886| 0057B4 lwz        80A6000C   1     L4A        gr5=(*)_typeobject._typeobject.tp_name(gr6,12)
  875| 005758 lwz        80C30004   1     L4A       gr6=(*)_object._object.ob_type(gr3,4)                                                                         886| 0057B8 addi       38841760   1     AI         gr4=gr4,5984
  835| 00575C lwz        8007001C   1     L4A       gr0=(*)aggr#5.co_flags(gr7,28)                                                                                886| 0057BC lwz        80630000   1     L4A        gr3=PyExc_TypeError(gr3,0)
  835| 005760 andi.      70000100   2     RN4_R     gr0,cr0=gr0,0,0x100                                                                                           886| 0057C0 bl         4BFFA841   0     CALL       gr3=PyErr_Format,3,(*)_object",gr3,gr4,(*)Cuchar",gr5,#ProcAlias",PyErr_Format",fcr",gr1,cr[01567]",gr0",g
  835| 005764 bc         408200F0   1     BF        CL.524,cr0,0x4/eq,taken=40%(40,60)                                                                            886| 0057C4 ori        60000000   1
  875| 005768 lwz        80660070   1     L4A       gr3=(*)_typeobject._typeobject.tp_iternext(gr6,112)                                                           889| 0057C8 addi       38600000   1     LI         gr3=0
  875| 00576C cmpwi      2C030000   2     C4        cr0=gr3,0                                                                                                       0| 0057CC lwz        80010078   1     L4A        gr0=#stack(gr1,120)
  875| 005770 bc         41820010   1     BT        CL.531,cr0,0x4/eq,taken=40%(40,60)                                                                            890| 0057D0 addi       38210070   1     AI         gr1=gr1,112
    0|                                CL.1958:                                                                                                                      0| 0057D4 mtspr      7C0803A6   1     LLR        lr=gr0
  875| 005774 lwz        80020108   1     L4A       gr0=._PyObject_NextNotImplemented(gr2,0)                                                                      890| 0057D8 bclr       4E800020   3     BA         lr
  875| 005778 cmplw      7C030040   2     CL4       cr0=gr3,gr0                                                                                                     0|                                CL.1995:
  875| 00577C bc         408200BC   1     BF        CL.2074,cr0,0x4/eq,taken=30%(30,70)                                                                           401| 0057DC lwz        80A20004   1     L4A        gr5=._Py_RefTotal(gr2,0)
  875|                                CL.531:                                                                                                                     403| 0057E0 lwz        80830000   1     L4A        gr4=(*)_object._object.ob_refcnt(gr3,0)
  876| 005780 lwz        80A6000C   1     L4A       gr5=(*)_typeobject._typeobject.tp_name(gr6,12)                                                                  0| 0057E4 lwz        83E1006C   1     L4A        gr31=#stack(gr1,108)
  876| 005784 lwz        80640000   1     L4A       gr3=<s145:d0:l4>(gr4,0)                                                                                         0| 0057E8 lwz        83C10068   1     L4A        gr30=#stack(gr1,104)
  876| 005788 addi       389F172C   1     AI        gr4=gr31,5932                                                                                                 890| 0057EC addi       38210070   1     AI         gr1=gr1,112
  876| 00578C bl         4BFFA875   0     CALL      gr3=PyErr_Format,3,(*)_object",gr3,gr4,(*)Cuchar",gr5,#ProcAlias",PyErr_Format",fcr",gr1,cr[01567]",gr0",gr   403| 0057F0 addi       38040001   1     AI         gr0=gr4,1
  876| 005790 ori        60000000   1                                                                                                                             403| 0057F4 stw        90030000   1     ST4A       (*)_object._object.ob_refcnt(gr3,0)=gr0
  880| 005794 cmpwi      2C1E0000   1     C4        cr0=gr30,0                                                                                                    401| 0057F8 lwz        80850000   1     L4A        gr4=_Py_RefTotal(gr5,0)
  415| 005798 lwz        80820004   1     L4A       gr4=._Py_RefTotal(gr2,0)                                                                                      401| 0057FC addi       38040001   2     AI         gr0=gr4,1
  880| 00579C ori        63C50000   1     LR        gr5=gr30                                                                                                      401| 005800 stw        90050000   1     ST4A       _Py_RefTotal(gr5,0)=gr0
  880| 0057A0 bc         41820098   0     BT        CL.2074,cr0,0x4/eq,taken=30%(30,70)                                                                           890| 005804 bclr       4E800020   0     BA         lr
  880| 0057A4 addi       3BC00000   2     LI        gr30=0                                                                                                          0|                                CL.2129:
  408| 0057A8 addi       387F1110   1     AI        gr3=gr31,4368                                                                                                 401| 005808 lwz        80A20004   1     L4A        gr5=._Py_RefTotal(gr2,0)
  417| 0057AC lwz        80C50000   1     L4A       gr6=(*)_object._object.ob_refcnt(gr5,0)                                                                       403| 00580C lwz        80830000   1     L4A        gr4=(*)_object._object.ob_refcnt(gr3,0)
  415| 0057B0 lwz        80E40000   1     L4A       gr7=<s117:d0:l4>(gr4,0)                                                                                         0| 005810 lwz        83E1006C   1     L4A        gr31=#stack(gr1,108)
  417| 0057B4 addi       3806FFFF   1     AI        gr0=gr6,-1                                                                                                      0| 005814 lwz        83C10068   1     L4A        gr30=#stack(gr1,104)
  417| 0057B8 stw        90050000   1     ST4A      (*)_object._object.ob_refcnt(gr5,0)=gr0                                                                       890| 005818 addi       38210070   1     AI         gr1=gr1,112
  415| 0057BC addi       38C7FFFF   1     AI        gr6=gr7,-1                                                                                                    403| 00581C addi       38040001   1     AI         gr0=gr4,1
  415| 0057C0 stw        90C40000   1     ST4A      <s117:d0:l4>(gr4,0)=gr6                                                                                       403| 005820 stw        90030000   1     ST4A       (*)_object._object.ob_refcnt(gr3,0)=gr0
  417| 0057C4 cmpwi      2C000000   1     C4        cr0=gr0,0                                                                                                     401| 005824 lwz        80850000   1     L4A        gr4=_Py_RefTotal(gr5,0)
  417| 0057C8 bc         41820048   1     BT        CL.1088,cr0,0x4/eq,taken=40%(40,60)                                                                           401| 005828 addi       38040001   2     AI         gr0=gr4,1
  420| 0057CC addi       38800370   2     LI        gr4=880                                                                                                       401| 00582C stw        90050000   1     ST4A       _Py_RefTotal(gr5,0)=gr0







Wed Apr 15 07:30:04 CDT 2020  Page 163


    0| 0057D0 lwz        83E1008C   1     L4A       gr31=#stack(gr1,140)                                                                                          890| 005830 bclr       4E800020   0     BA         lr
  419| 0057D4 bc         40800024   0     BF        CL.2079,cr0,0x1/lt,taken=30%(30,70)                                                                              |               Tag Table
  420| 0057D8 bl         4BFFA829   1     CALL      _Py_NegativeRefcount,3,(*)Cuchar",gr3,gr4,(*)_object",gr5,#ProcAlias",_Py_NegativeRefcount",fcr",gr1,cr[015      | 005834        00000000 00002041 80040100 00000000 00000394 00185F50
  420| 0057DC ori        60000000   1                                                                                                                                | 00584C        79436F72 6F5F4765 74417761 69746162 6C654974 6572
    0|                                CL.1960:                                                                                                                       |               Instruction count          229
  883| 0057E0 ori        63C30000   1     LR        gr3=gr30                                                                                                         |               Straight-line exec time    251
    0| 0057E4 lwz        83C10088   1     L4A       gr30=#stack(gr1,136)                                                                                         GPR's set/used:   su-s ssss ssss s---  ---- ---- ---- ----
  890| 0057E8 addi       38210090   1     AI        gr1=gr1,144                                                                                                  FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----
    0| 0057EC lwz        80010008   1     L4A       gr0=#stack(gr1,8)                                                                                            CCR's set/used:   ss-- -sss
    0| 0057F0 mtspr      7C0803A6   2     LLR       lr=gr0                                                                                                           | 000000                             PDEF       _PyGen_Finalize
  890| 0057F4 bclr       4E800020   3     BA        lr                                                                                                             43|                                    PROC       self_130_92,gr3
    0|                                CL.2079:                                                                                                                     49| 005880 lwz        80830008   1     L4A        gr4=(*)aggr#3.gi_frame(gr3,8)
  883| 0057F8 addi       38600000   1     LI        gr3=0                                                                                                           0| 005884 or.        7C802379   2     LR_R       gr0,cr0=gr4
    0| 0057FC lwz        83C10088   1     L4A       gr30=#stack(gr1,136)                                                                                           49| 005888 bclr       4D820020   1     BT         CL.1556,cr0,0x4/eq,taken=30%(30,70)
  890| 005800 addi       38210090   1     AI        gr1=gr1,144                                                                                                    49| 00588C lwz        80040024   1     L4A        gr0=(*)_frame._frame.f_stacktop(gr4,36)
    0| 005804 lwz        80010008   1     L4A       gr0=#stack(gr1,8)                                                                                              49| 005890 cmpwi      2C000000   2     C4         cr0=gr0,0
    0| 005808 mtspr      7C0803A6   2     LLR       lr=gr0                                                                                                         49| 005894 bc         40820008   1     BF         CL.2123,cr0,0x4/eq,taken=40%(40,60)
  890| 00580C bclr       4E800020   3     BA        lr                                                                                                            100|                                CL.1556:
  423|                                CL.1088:                                                                                                                    100| 005898 bclr       4E800020   0     BA         lr
  425| 005810 ori        60A30000   1     LR        gr3=gr5                                                                                                         0|                                CL.2123:
    0| 005814 lwz        83E1008C   1     L4A       gr31=#stack(gr1,140)                                                                                            0| 00589C addi       38800000   1     LI         gr4=0
  425| 005818 bl         4BFFA7E9   0     CALL      _Py_Dealloc,1,(*)_object",gr3,#ProcAlias",_Py_Dealloc",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",l     0| 0058A0 ori        60650000   1     LR         gr5=gr3
  425| 00581C ori        60000000   1                                                                                                                             100| 0058A4 b          4800151C   0     CALLF      _PyGen_Finalize at AF130_92,3,gr3-gr5,fcr",_PyGen_Finalize at AF130_92",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13
  883| 005820 ori        63C30000   1     LR        gr3=gr30                                                                                                         |               Tag Table
    0| 005824 lwz        83C10088   1     L4A       gr30=#stack(gr1,136)                                                                                             | 0058A8        00000000 00002040 00000100 00000000 00000028 000F5F50
  890| 005828 addi       38210090   1     AI        gr1=gr1,144                                                                                                      | 0058C0        7947656E 5F46696E 616C697A 65
    0| 00582C lwz        80010008   1     L4A       gr0=#stack(gr1,8)                                                                                                |               Instruction count           10
    0| 005830 mtspr      7C0803A6   2     LLR       lr=gr0                                                                                                           |               Straight-line exec time     10
  890| 005834 bclr       4E800020   3     BA        lr                                                                                                           GPR's set/used:   ssus ssss ssss s---  ---- ---- ---- -sss
    0|                                CL.2074:                                                                                                                   FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----
  883| 005838 ori        63C30000   1     LR        gr3=gr30                                                                                                     CCR's set/used:   ss-- -sss
    0| 00583C lwz        83E1008C   1     L4A       gr31=#stack(gr1,140)                                                                                             | 000000                             PDEF       _PyGen_yf
    0| 005840 lwz        83C10088   1     L4A       gr30=#stack(gr1,136)                                                                                          332|                                    PROC       gen,gr3
  890| 005844 addi       38210090   1     AI        gr1=gr1,144                                                                                                     0| 0058E0 mfspr      7C0802A6   1     LFLR       gr0=lr
    0| 005848 lwz        80010008   1     L4A       gr0=#stack(gr1,8)                                                                                               0| 0058E4 stwu       9421FFB0   1     ST4U       gr1,#stack(gr1,-80)=gr1
    0| 00584C mtspr      7C0803A6   2     LLR       lr=gr0                                                                                                          0| 0058E8 stw        90010058   1     ST4A       #stack(gr1,88)=gr0
  890| 005850 bclr       4E800020   3     BA        lr                                                                                                              0| 0058EC stw        93E1004C   1     ST4A       #stack(gr1,76)=gr31
  869|                                CL.524:                                                                                                                     334| 0058F0 addi       3BE00000   1     LI         gr31=0
  872| 005854 addi       389F1708   1     AI        gr4=gr31,5896                                                                                                   0| 0058F4 stw        93C10048   1     ST4A       #stack(gr1,72)=gr30
  872| 005858 lwz        80650000   1     L4A       gr3=<s145:d0:l4>(gr5,0)                                                                                         0| 0058F8 stw        93A10044   1     ST4A       #stack(gr1,68)=gr29
  872| 00585C bl         4BFFA7A5   0     CALL      PyErr_SetString,2,(*)_object",gr3,gr4,#ProcAlias",PyErr_SetString",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"   335| 0058FC lwz        83C30008   1     L4A        gr30=(*)aggr#3.gi_frame(gr3,8)
  872| 005860 ori        60000000   1                                                                                                                               0| 005900 or.        7FC0F379   2     LR_R       gr0,cr0=gr30
  874| 005864 cmpwi      2C1E0000   1     C4        cr0=gr30,0                                                                                                    337| 005904 bc         41820134   1     BT         CL.2079,cr0,0x4/eq,taken=30%(30,70)
  415| 005868 lwz        80820004   1     L4A       gr4=._Py_RefTotal(gr2,0)                                                                                      337| 005908 lwz        801E0024   1     L4A        gr0=(*)_frame._frame.f_stacktop(gr30,36)
  874| 00586C ori        63C50000   1     LR        gr5=gr30                                                                                                      337| 00590C cmpwi      2C000000   2     C4         cr0=gr0,0
  874| 005870 bc         4182FFC8   0     BT        CL.2074,cr0,0x4/eq,taken=50%(0,0)                                                                             337| 005910 bc         41820128   1     BT         CL.2079,cr0,0x4/eq,taken=30%(30,70)
  874| 005874 addi       3BC00000   2     LI        gr30=0                                                                                                        338| 005914 lwz        807E0010   1     L4A        gr3=(*)_frame._frame.f_code(gr30,16)
  408| 005878 addi       387F1110   1     AI        gr3=gr31,4368                                                                                                 338| 005918 lwz        83A30024   2     L4A        gr29=(*)aggr#5.co_code(gr3,36)
  417| 00587C lwz        80C50000   1     L4A       gr6=(*)_object._object.ob_refcnt(gr5,0)                                                                         0| 00591C lwz        83E1004C   1     L4A        gr31=#stack(gr1,76)
  415| 005880 lwz        80E40000   1     L4A       gr7=<s117:d0:l4>(gr4,0)                                                                                       339| 005920 lwz        807D0004   1     L4A        gr3=(*)_object._object.ob_type(gr29,4)
  417| 005884 addi       3806FFFF   1     AI        gr0=gr6,-1                                                                                                    617| 005924 bl         4BFFA6DD   0     CALL       gr3=PyType_GetFlags,1,(*)_typeobject",gr3,#ProcAlias",PyType_GetFlags",fcr",gr1,cr[01567]",gr0",gr4"-gr12"
  417| 005888 stw        90050000   1     ST4A      (*)_object._object.ob_refcnt(gr5,0)=gr0                                                                       617| 005928 ori        60000000   1
  415| 00588C addi       38C7FFFF   1     AI        gr6=gr7,-1                                                                                                    341| 00592C lwz        809E0034   1     L4A        gr4=(*)_frame._frame.f_lasti(gr30,52)
  415| 005890 stw        90C40000   1     ST4A      <s117:d0:l4>(gr4,0)=gr6                                                                                       617| 005930 andis.     74600800   1     RN4_R      gr0,cr0=gr3,0,0x8000000
  417| 005894 cmpwi      2C000000   1     C4        cr0=gr0,0                                                                                                     341| 005934 cmpwi      2C840000   1     C4         cr1=gr4,0
  417| 005898 bc         4182FF78   1     BT        CL.1088,cr0,0x4/eq,taken=40%(40,60)                                                                           339| 005938 bc         418200C0   0     BT         CL.1695,cr0,0x4/eq,taken=40%(40,60)







Wed Apr 15 07:30:04 CDT 2020  Page 164


    0| 00589C lwz        83E1008C   2     L4A       gr31=#stack(gr1,140)                                                                                            0| 00593C lwz        80010058   2     L4A        gr0=#stack(gr1,88)
  419| 0058A0 bc         4080FF40   0     BF        CL.1960,cr0,0x1/lt,taken=60%(60,40)                                                                             0| 005940 mtspr      7C0803A6   2     LLR        lr=gr0
  420| 0058A4 addi       3880036A   2     LI        gr4=874                                                                                                       341| 005944 bc         41840064   0     BT         CL.2082,cr1,0x1/lt,taken=40%(40,60)
  420| 0058A8 bl         4BFFA759   0     CALL      _Py_NegativeRefcount,3,(*)Cuchar",gr3,gr4,(*)_object",gr5,#ProcAlias",_Py_NegativeRefcount",fcr",gr1,cr[015   347|                                CL.553:
  420| 0058AC ori        60000000   1                                                                                                                             349| 005948 addi       387D0012   1     AI         gr3=gr29,18
  883| 0058B0 ori        63C30000   1     LR        gr3=gr30                                                                                                      349| 00594C lbzx       7C0320AE   1     L1Z        gr0=(*)uchar(gr3,gr4,0)
    0| 0058B4 lwz        83C10088   1     L4A       gr30=#stack(gr1,136)                                                                                          401| 005950 lwz        80820004   1     L4A        gr4=._Py_RefTotal(gr2,0)
  890| 0058B8 addi       38210090   1     AI        gr1=gr1,144                                                                                                   349| 005954 cmpwi      2C000048   1     C4         cr0=gr0,72
    0| 0058BC lwz        80010008   1     L4A       gr0=#stack(gr1,8)                                                                                             401| 005958 lwz        80640000   1     L4A        gr3=_Py_RefTotal(gr4,0)
    0| 0058C0 mtspr      7C0803A6   2     LLR       lr=gr0                                                                                                        349| 00595C bc         40820038   0     BF         CL.2078,cr0,0x4/eq,taken=30%(30,70)
  890| 0058C4 bclr       4E800020   3     BA        lr                                                                                                            351| 005960 lwz        80BE0024   2     L4A        gr5=(*)_frame._frame.f_stacktop(gr30,36)
    0|                                CL.1957:                                                                                                                      0| 005964 lwz        83A10044   1     L4A        gr29=#stack(gr1,68)
  875| 0058C8 lwz        80660070   1     L4A       gr3=(*)_typeobject._typeobject.tp_iternext(gr6,112)                                                           401| 005968 addi       38030001   1     AI         gr0=gr3,1
  875| 0058CC cmpwi      2C030000   2     C4        cr0=gr3,0                                                                                                     401| 00596C stw        90040000   1     ST4A       _Py_RefTotal(gr4,0)=gr0
  875| 0058D0 bc         4182FEB0   1     BT        CL.531,cr0,0x4/eq,taken=40%(40,60)                                                                              0| 005970 lwz        83C10048   1     L4A        gr30=#stack(gr1,72)
    0| 0058D4 b          4BFFFEA0   1     B         CL.1958,-1                                                                                                    351| 005974 lwz        83E5FFFC   1     L4A        gr31=(*)_object*(gr5,-4)
  884|                                CL.522:                                                                                                                     403| 005978 lwz        807F0000   2     L4A        gr3=(*)_object._object.ob_refcnt(gr31,0)
  886| 0058D8 lwz        806200B4   1     L4A       gr3=.PyExc_TypeError(gr2,0)                                                                                   403| 00597C addi       38030001   2     AI         gr0=gr3,1
  886| 0058DC lwz        80820018   1     L4A       gr4=.+CONSTANT_AREA(gr2,0)                                                                                    403| 005980 stw        901F0000   1     ST4A       (*)_object._object.ob_refcnt(gr31,0)=gr0
  886| 0058E0 lwz        80A7000C   1     L4A       gr5=(*)_typeobject._typeobject.tp_name(gr7,12)                                                                355| 005984 ori        63E30000   1     LR         gr3=gr31
  886| 0058E4 addi       38841760   1     AI        gr4=gr4,5984                                                                                                    0| 005988 lwz        83E1004C   1     L4A        gr31=#stack(gr1,76)
  886| 0058E8 lwz        80630000   1     L4A       gr3=<s145:d0:l4>(gr3,0)                                                                                       356| 00598C addi       38210050   1     AI         gr1=gr1,80
  886| 0058EC bl         4BFFA715   0     CALL      gr3=PyErr_Format,3,(*)_object",gr3,gr4,(*)Cuchar",gr5,#ProcAlias",PyErr_Format",fcr",gr1,cr[01567]",gr0",gr   356| 005990 bclr       4E800020   0     BA         lr
  886| 0058F0 ori        60000000   1                                                                                                                               0|                                CL.2078:
  889| 0058F4 addi       38600000   1     LI        gr3=0                                                                                                         346| 005994 addi       38600000   1     LI         gr3=0
  890| 0058F8 addi       38210090   1     AI        gr1=gr1,144                                                                                                     0| 005998 lwz        83C10048   1     L4A        gr30=#stack(gr1,72)
    0| 0058FC lwz        80010008   1     L4A       gr0=#stack(gr1,8)                                                                                               0| 00599C lwz        83A10044   1     L4A        gr29=#stack(gr1,68)
    0| 005900 mtspr      7C0803A6   2     LLR       lr=gr0                                                                                                        356| 0059A0 addi       38210050   1     AI         gr1=gr1,80
  890| 005904 bclr       4E800020   3     BA        lr                                                                                                            356| 0059A4 bclr       4E800020   0     BA         lr
    0|                                CL.2078:                                                                                                                      0|                                CL.2082:
  886| 005908 lwz        806200B4   1     L4A       gr3=.PyExc_TypeError(gr2,0)                                                                                     0| 0059A8 lwz        83C10048   1     L4A        gr30=#stack(gr1,72)
  886| 00590C lwz        80820018   1     L4A       gr4=.+CONSTANT_AREA(gr2,0)                                                                                      0|                                CL.1691:
  886| 005910 lwz        80A7000C   1     L4A       gr5=(*)_typeobject._typeobject.tp_name(gr7,12)                                                                345| 0059AC addi       38A00159   1     LI         gr5=345
  886| 005914 addi       38841760   1     AI        gr4=gr4,5984                                                                                                  345| 0059B0 lbz        881D0010   1     L1Z        gr0=(*)uchar(gr29,16)
  886| 005918 lwz        80630000   1     L4A       gr3=<s145:d0:l4>(gr3,0)                                                                                       345| 0059B4 lwz        80820018   1     L4A        gr4=.+CONSTANT_AREA(gr2,0)
  886| 00591C bl         4BFFA6E5   0     CALL      gr3=PyErr_Format,3,(*)_object",gr3,gr4,(*)Cuchar",gr5,#ProcAlias",PyErr_Format",fcr",gr1,cr[01567]",gr0",gr   345| 0059B8 cmpwi      2C000048   1     C4         cr0=gr0,72
  886| 005920 ori        60000000   1                                                                                                                             345| 0059BC addi       38641150   1     AI         gr3=gr4,4432
  889| 005924 addi       38600000   1     LI        gr3=0                                                                                                         345| 0059C0 bc         40820028   0     BF         CL.2084,cr0,0x4/eq,taken=30%(30,70)
  890| 005928 addi       38210090   1     AI        gr1=gr1,144                                                                                                   345| 0059C4 addi       38841110   2     AI         gr4=gr4,4368
    0| 00592C lwz        80010008   1     L4A       gr0=#stack(gr1,8)                                                                                               0| 0059C8 lwz        83A10044   1     L4A        gr29=#stack(gr1,68)
    0| 005930 mtspr      7C0803A6   2     LLR       lr=gr0                                                                                                        345| 0059CC bl         4BFFA635   0     CALL       __assert,3,gr3-gr5,#ProcAlias",__assert",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",lr",fcr",xer",
  890| 005934 bclr       4E800020   3     BA        lr                                                                                                            345| 0059D0 ori        60000000   1
    0|                                CL.1954:                                                                                                                    346| 0059D4 addi       38600000   1     LI         gr3=0
  401| 005938 lwz        80A20004   1     L4A       gr5=._Py_RefTotal(gr2,0)                                                                                        0| 0059D8 lwz        80010058   1     L4A        gr0=#stack(gr1,88)
  403| 00593C lwz        80830000   1     L4A       gr4=(*)_object._object.ob_refcnt(gr3,0)                                                                       356| 0059DC addi       38210050   1     AI         gr1=gr1,80
  890| 005940 addi       38210090   1     AI        gr1=gr1,144                                                                                                     0| 0059E0 mtspr      7C0803A6   1     LLR        lr=gr0
  403| 005944 addi       38040001   1     AI        gr0=gr4,1                                                                                                     356| 0059E4 bclr       4E800020   3     BA         lr
  403| 005948 stw        90030000   1     ST4A      (*)_object._object.ob_refcnt(gr3,0)=gr0                                                                         0|                                CL.2084:
  401| 00594C lwz        80850000   1     L4A       gr4=<s117:d0:l4>(gr5,0)                                                                                       346| 0059E8 addi       38600000   1     LI         gr3=0
  401| 005950 addi       38040001   2     AI        gr0=gr4,1                                                                                                       0| 0059EC lwz        83A10044   1     L4A        gr29=#stack(gr1,68)
  401| 005954 stw        90050000   1     ST4A      <s117:d0:l4>(gr5,0)=gr0                                                                                       356| 0059F0 addi       38210050   1     AI         gr1=gr1,80
    0| 005958 lwz        80010008   1     L4A       gr0=#stack(gr1,8)                                                                                             356| 0059F4 bclr       4E800020   0     BA         lr
    0| 00595C mtspr      7C0803A6   2     LLR       lr=gr0                                                                                                          0|                                CL.1695:
  890| 005960 bclr       4E800020   3     BA        lr                                                                                                            339| 0059F8 addi       38A00153   1     LI         gr5=339
     |               Tag Table                                                                                                                                    339| 0059FC lwz        80620018   1     L4A        gr3=.+CONSTANT_AREA(gr2,0)
     | 005964        00000000 00002041 80020100 00000000 000002C4 00185F50                                                                                        339| 005A00 addi       38831110   2     AI         gr4=gr3,4368







Wed Apr 15 07:30:04 CDT 2020  Page 165


     | 00597C        79436F72 6F5F4765 74417761 69746162 6C654974 6572                                                                                            339| 005A04 addi       38631138   1     AI         gr3=gr3,4408
     |               Instruction count          177                                                                                                               339| 005A08 bl         4BFFA5F9   0     CALL       __assert,3,gr3-gr5,#ProcAlias",__assert",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",lr",fcr",xer",
     |               Straight-line exec time    206                                                                                                               339| 005A0C ori        60000000   1
 GPR's set/used:   su-s ssss ssss s---  ---- ---- ---- ----                                                                                                       341| 005A10 lwz        809E0034   1     L4A        gr4=(*)_frame._frame.f_lasti(gr30,52)
 FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----                                                                                                         0| 005A14 or.        7C802379   2     LR_R       gr0,cr0=gr4
 CCR's set/used:   ss-- -sss                                                                                                                                      341| 005A18 bc         41800010   1     BT         CL.2083,cr0,0x1/lt,taken=40%(40,60)
     | 000000                             PDEF     _PyGen_Finalize                                                                                                  0| 005A1C lwz        80010058   1     L4A        gr0=#stack(gr1,88)
   43|                                    PROC      self_125_92,gr3                                                                                                 0| 005A20 mtspr      7C0803A6   2     LLR        lr=gr0
   49| 0059A0 lwz        80830008   1     L4A       gr4=(*)aggr#3.gi_frame(gr3,8)                                                                                   0| 005A24 b          4BFFFF24   0     B          CL.553,-1
    0| 0059A4 or.        7C802379   2     LR_R      gr0,cr0=gr4                                                                                                     0|                                CL.2083:
   49| 0059A8 bclr       4D820020   1     BT        CL.1527,cr0,0x4/eq,taken=30%(30,70)                                                                             0| 005A28 lwz        80010058   1     L4A        gr0=#stack(gr1,88)
   49| 0059AC lwz        80040024   1     L4A       gr0=(*)_frame._frame.f_stacktop(gr4,36)                                                                         0| 005A2C lwz        83C10048   1     L4A        gr30=#stack(gr1,72)
   49| 0059B0 cmpwi      2C000000   2     C4        cr0=gr0,0                                                                                                       0| 005A30 mtspr      7C0803A6   1     LLR        lr=gr0
   49| 0059B4 bc         40820008   1     BF        CL.2073,cr0,0x4/eq,taken=40%(40,60)                                                                             0| 005A34 b          4BFFFF78   0     B          CL.1691,-1
  100|                                CL.1527:                                                                                                                      0|                                CL.2079:
  100| 0059B8 bclr       4E800020   0     BA        lr                                                                                                            355| 005A38 ori        63E30000   1     LR         gr3=gr31
    0|                                CL.2073:                                                                                                                      0| 005A3C lwz        83C10048   1     L4A        gr30=#stack(gr1,72)
    0| 0059BC ori        60640000   1     LR        gr4=gr3                                                                                                         0| 005A40 lwz        83E1004C   1     L4A        gr31=#stack(gr1,76)
    0| 0059C0 addi       38A00000   1     LI        gr5=0                                                                                                         356| 005A44 addi       38210050   1     AI         gr1=gr1,80
  100| 0059C4 b          48000E9C   0     CALLF     _PyGen_Finalize at AF125_92,3,gr3-gr5,fcr",_PyGen_Finalize at AF125_92",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13"   356| 005A48 bclr       4E800020   0     BA         lr
     |               Tag Table                                                                                                                                       |               Tag Table
     | 0059C8        00000000 00002040 00000100 00000000 00000028 000F5F50                                                                                           | 005A4C        00000000 00002041 80030100 00000000 0000016C 00095F50
     | 0059E0        7947656E 5F46696E 616C697A 65                                                                                                                   | 005A64        7947656E 5F7966
     |               Instruction count           10                                                                                                                  |               Instruction count           91
     |               Straight-line exec time     10                                                                                                                  |               Straight-line exec time     92
 GPR's set/used:   su-s ssss ssss s---  ---- ---- ---- ----                                                                                                      GPR's set/used:   su-s ssss ssss s---  ---- ---- ---- ----
 FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----                                                                                                      FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----
 CCR's set/used:   ss-- -sss                                                                                                                                     CCR's set/used:   ss-- -sss
     | 000000                             PDEF     _PyGen_yf                                                                                                         | 000000                             PDEF       _PyGen_Send
  332|                                    PROC      gen_121_93,gr3                                                                                                291|                                    PROC       gen,arg,gr3,gr4
  335| 005A00 lwz        80A30008   1     L4A       gr5=(*)aggr#3.gi_frame(gr3,8)                                                                                 293| 005A80 addi       38A00000   1     LI         gr5=0
    0| 005A04 or.        7CA02B79   2     LR_R      gr0,cr0=gr5                                                                                                   293| 005A84 addi       38C00000   1     LI         gr6=0
  337| 005A08 bc         41820010   1     BT        CL.1511,cr0,0x4/eq,taken=30%(30,70)                                                                           294| 005A88 b          4BFFDBF8   0     CALLF      gr3=gen_send_ex,4,(*)aggr#3",gr3,(*)_object",gr4-gr6,#ProcAlias",gen_send_ex",fcr",gr1,cr[01567]",gr0",gr4
  337| 005A0C lwz        80050024   1     L4A       gr0=(*)_frame._frame.f_stacktop(gr5,36)                                                                       294|                                CL.671:
  337| 005A10 cmpwi      2C000000   2     C4        cr0=gr0,0                                                                                                        |               Tag Table
  337| 005A14 bc         4082000C   1     BF        CL.2033,cr0,0x4/eq,taken=40%(40,60)                                                                              | 005A8C        00000000 00002040 00000200 00000000 0000000C 000B5F50
  353|                                CL.1511:                                                                                                                       | 005AA4        7947656E 5F53656E 64
  355| 005A18 addi       38600000   1     LI        gr3=0                                                                                                            |               Instruction count            3
  356| 005A1C bclr       4E800020   0     BA        lr                                                                                                               |               Straight-line exec time      2
    0|                                CL.2033:                                                                                                                   GPR's set/used:   ssus ssss ssss s---  ---- ---- ---- -sss
    0| 005A20 addi       38800000   1     LI        gr4=0                                                                                                        FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----
  356| 005A24 b          4800081C   0     CALLF     gr3=_PyGen_yf at AF121_93,3,gr3-gr5,fcr",_PyGen_yf at AF121_93",gr1,cr[01567]",gr0",gr4"-gr12",fp0"-fp13",mq",lr"  CCR's set/used:   ss-- -sss
     |               Tag Table                                                                                                                                       | 000000                             PDEF       _PyGen_FetchStopIterationValue
     | 005A28        00000000 00002040 00000100 00000000 00000028 00095F50                                                                                        593|                                    PROC       pvalue,gr3
     | 005A40        7947656E 5F7966                                                                                                                                0| 005AC0 mfspr      7C0802A6   1     LFLR       gr0=lr
     |               Instruction count           10                                                                                                                 0| 005AC4 stwu       9421FF90   1     ST4U       gr1,#stack(gr1,-112)=gr1
     |               Straight-line exec time     10                                                                                                                 0| 005AC8 stw        90010078   1     ST4A       #stack(gr1,120)=gr0
 GPR's set/used:   su-s ssss ssss s---  ---- ---- ---- ----                                                                                                         0| 005ACC stw        93E1006C   1     ST4A       #stack(gr1,108)=gr31
 FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----                                                                                                         0| 005AD0 stw        93C10068   1     ST4A       #stack(gr1,104)=gr30
 CCR's set/used:   ss-- -sss                                                                                                                                        0| 005AD4 stw        93A10064   1     ST4A       #stack(gr1,100)=gr29
     | 000000                             PDEF     _PyGen_Send                                                                                                      0| 005AD8 ori        607D0000   1     LR         gr29=gr3
  291|                                    PROC      gen,arg,gr3,gr4                                                                                               596| 005ADC addi       3BC00000   1     LI         gr30=0
  293| 005A60 addi       38A00000   1     LI        gr5=0                                                                                                         598| 005AE0 lwz        83E2002C   1     L4A        gr31=.PyExc_StopIteration(gr2,0)
  293| 005A64 addi       38C00000   1     LI        gr6=0                                                                                                         598| 005AE4 lwz        807F0000   2     L4A        gr3=PyExc_StopIteration(gr31,0)
  294| 005A68 b          4BFFDDF8   0     CALLF     gr3=gen_send_ex,4,(*)aggr#3",gr3,(*)_object",gr4-gr6,#ProcAlias",gen_send_ex",fcr",gr1,cr[01567]",gr0",gr4"   598| 005AE8 bl         4BFFA519   0     CALL       gr3=PyErr_ExceptionMatches,1,(*)_object",gr3,#ProcAlias",PyErr_ExceptionMatches",fcr",gr1,cr[01567]",gr0",
  294|                                CL.671:                                                                                                                     598| 005AEC ori        60000000   1







Wed Apr 15 07:30:04 CDT 2020  Page 166


     |               Tag Table                                                                                                                                    599| 005AF0 addi       38A10040   1     AI         gr5=gr1,64
     | 005A6C        00000000 00002040 00000200 00000000 0000000C 000B5F50                                                                                        599| 005AF4 addi       38810044   1     AI         gr4=gr1,68
     | 005A84        7947656E 5F53656E 64                                                                                                                         598| 005AF8 cmpwi      2C030000   1     C4         cr0=gr3,0
     |               Instruction count            3                                                                                                               599| 005AFC addi       38610048   1     AI         gr3=gr1,72
     |               Straight-line exec time      2                                                                                                               598| 005B00 bc         41820290   0     BT         CL.559,cr0,0x4/eq,taken=50%(0,0)
 GPR's set/used:   ssus ssss ssss s---  ---- ---- ---- -sss                                                                                                       599| 005B04 bl         4BFFA4FD   1     CALL       PyErr_Fetch,3,(*)_object*",gr3,(*)_object*",gr4,(*)_object*",gr5,#ProcAlias",(*)_object",(*)_object",(*)_o
 FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----                                                                                                       599| 005B08 ori        60000000   1
 CCR's set/used:   ss-- -sss                                                                                                                                      602| 005B0C lwz        80810048   1     L4A        gr4=et(gr1,72)
     | 000000                             PDEF     _PyGen_FetchStopIterationValue                                                                                 600| 005B10 lwz        80C10044   1     L4A        gr6=ev(gr1,68)
  593|                                    PROC      pvalue,gr3                                                                                                      0| 005B14 or.        7CC03379   2     LR_R       gr0,cr0=gr6
    0| 005AA0 mfspr      7C0802A6   1     LFLR      gr0=lr                                                                                                        600| 005B18 bc         418201AC   1     BT         CL.2222,cr0,0x4/eq,taken=30%(30,70)
    0| 005AA4 stw        90010008   2     ST4A      #stack(gr1,8)=gr0                                                                                               0| 005B1C lwz        83C10068   1     L4A        gr30=#stack(gr1,104)
    0| 005AA8 stw        93E1FFFC   1     ST4A      #stack(gr1,-4)=gr31                                                                                           128| 005B20 lwz        80060004   1     L4A        gr0=(*)C_object._object.ob_type(gr6,4)
    0| 005AAC stw        93C1FFF8   1     ST4A      #stack(gr1,-8)=gr30                                                                                           128| 005B24 cmplw      7C002040   2     CL4        cr0=gr0,gr4
    0| 005AB0 stw        93A1FFF4   1     ST4A      #stack(gr1,-12)=gr29                                                                                          602| 005B28 bc         40820158   1     BF         CL.2223,cr0,0x4/eq,taken=40%(40,60)
    0| 005AB4 ori        607D0000   1     LR        gr29=gr3                                                                                                        0|                                CL.2219:
  596| 005AB8 addi       3BC00000   1     LI        gr30=0                                                                                                        408| 005B2C addi       3880025D   1     LI         gr4=605
    0| 005ABC stwu       9421FF70   1     ST4U      gr1,#stack(gr1,-144)=gr1                                                                                      603| 005B30 lwz        83C60020   1     L4A        gr30=(*)aggr#8.value(gr6,32)
  598| 005AC0 lwz        83E2002C   1     L4A       gr31=.PyExc_StopIteration(gr2,0)                                                                                0| 005B34 lwz        80620018   1     L4A        gr3=.+CONSTANT_AREA(gr2,0)
  598| 005AC4 lwz        807F0000   2     L4A       gr3=<s139:d0:l4>(gr31,0)                                                                                        0| 005B38 lwz        83E1006C   1     L4A        gr31=#stack(gr1,108)
  598| 005AC8 bl         4BFFA539   0     CALL      gr3=PyErr_ExceptionMatches,1,(*)_object",gr3,#ProcAlias",PyErr_ExceptionMatches",fcr",gr1,cr[01567]",gr0",g   408| 005B3C addi       38631110   1     AI         gr3=gr3,4368
  598| 005ACC ori        60000000   1                                                                                                                             403| 005B40 lwz        80FE0000   1     L4A        gr7=(*)_object._object.ob_refcnt(gr30,0)
  599| 005AD0 addi       38A10040   1     AI        gr5=gr1,64                                                                                                    403| 005B44 addi       38070001   2     AI         gr0=gr7,1
  599| 005AD4 addi       38810044   1     AI        gr4=gr1,68                                                                                                    403| 005B48 stw        901E0000   1     ST4A       (*)_object._object.ob_refcnt(gr30,0)=gr0
  598| 005AD8 cmpwi      2C030000   1     C4        cr0=gr3,0                                                                                                     417| 005B4C lwz        80A60000   1     L4A        gr5=(*)_object._object.ob_refcnt(gr6,0)
  599| 005ADC addi       38610048   1     AI        gr3=gr1,72                                                                                                    417| 005B50 addi       3805FFFF   2     AI         gr0=gr5,-1
  598| 005AE0 bc         41820294   0     BT        CL.559,cr0,0x4/eq,taken=50%(0,0)                                                                              417| 005B54 stw        90060000   1     ST4A       (*)_object._object.ob_refcnt(gr6,0)=gr0
  599| 005AE4 bl         4BFFA51D   1     CALL      PyErr_Fetch,3,(*)_object*",gr3,(*)_object*",gr4,(*)_object*",gr5,#ProcAlias",(*)_object",(*)_object",(*)_ob   417| 005B58 cmpwi      2C000000   1     C4         cr0=gr0,0
  599| 005AE8 ori        60000000   1                                                                                                                             417| 005B5C bc         41820114   1     BT         CL.849,cr0,0x4/eq,taken=40%(40,60)
  602| 005AEC lwz        80810048   1     L4A       gr4=et(gr1,72)                                                                                                419| 005B60 bc         40800010   1     BF         CL.560,cr0,0x1/lt,taken=50%(0,0)
  600| 005AF0 lwz        80C10044   1     L4A       gr6=ev(gr1,68)                                                                                                420|                                CL.1577:
    0| 005AF4 or.        7CC03379   2     LR_R      gr0,cr0=gr6                                                                                                   420| 005B64 ori        60C50000   1     LR         gr5=gr6
  600| 005AF8 bc         418201B0   1     BT        CL.2182,cr0,0x4/eq,taken=30%(30,70)                                                                           420| 005B68 bl         4BFFA499   0     CALL       _Py_NegativeRefcount,3,(*)Cuchar",gr3,gr4,(*)_object",gr5,#ProcAlias",_Py_NegativeRefcount",fcr",gr1,cr[01
    0| 005AFC lwz        83C10088   1     L4A       gr30=#stack(gr1,136)                                                                                          420| 005B6C ori        60000000   1
  128| 005B00 lwz        80060004   1     L4A       gr0=(*)C_object._object.ob_type(gr6,4)                                                                        627|                                CL.560:
  128| 005B04 cmplw      7C002040   2     CL4       cr0=gr0,gr4                                                                                                   628| 005B70 lwz        80A10048   1     L4A        gr5=et(gr1,72)
  602| 005B08 bc         4082015C   1     BF        CL.2183,cr0,0x4/eq,taken=40%(40,60)                                                                           415| 005B74 lwz        80820004   1     L4A        gr4=._Py_RefTotal(gr2,0)
    0|                                CL.2179:                                                                                                                      0| 005B78 or.        7CA02B79   1     LR_R       gr0,cr0=gr5
  408| 005B0C addi       3880025D   1     LI        gr4=605                                                                                                         0| 005B7C lwz        80620018   1     L4A        gr3=.+CONSTANT_AREA(gr2,0)
  603| 005B10 lwz        83C60020   1     L4A       gr30=(*)aggr#8.value(gr6,32)                                                                                  491| 005B80 bc         4182002C   0     BT         CL.862,cr0,0x4/eq,taken=30%(30,70)
    0| 005B14 lwz        80620018   1     L4A       gr3=.+CONSTANT_AREA(gr2,0)                                                                                    408| 005B84 addi       38631124   2     AI         gr3=gr3,4388
    0| 005B18 lwz        83E1008C   1     L4A       gr31=#stack(gr1,140)                                                                                          415| 005B88 lwz        80C40000   1     L4A        gr6=_Py_RefTotal(gr4,0)
  408| 005B1C addi       38631110   1     AI        gr3=gr3,4368                                                                                                  417| 005B8C lwz        80E50000   1     L4A        gr7=(*)_object._object.ob_refcnt(gr5,0)
  403| 005B20 lwz        80FE0000   1     L4A       gr7=(*)_object._object.ob_refcnt(gr30,0)                                                                      415| 005B90 addi       3806FFFF   1     AI         gr0=gr6,-1
  403| 005B24 addi       38070001   2     AI        gr0=gr7,1                                                                                                     415| 005B94 stw        90040000   1     ST4A       _Py_RefTotal(gr4,0)=gr0
  403| 005B28 stw        901E0000   1     ST4A      (*)_object._object.ob_refcnt(gr30,0)=gr0                                                                      417| 005B98 addi       3887FFFF   1     AI         gr4=gr7,-1
  417| 005B2C lwz        80A60000   1     L4A       gr5=(*)_object._object.ob_refcnt(gr6,0)                                                                       417| 005B9C stw        90850000   1     ST4A       (*)_object._object.ob_refcnt(gr5,0)=gr4
  417| 005B30 addi       3805FFFF   2     AI        gr0=gr5,-1                                                                                                    417| 005BA0 cmpwi      2C040000   1     C4         cr0=gr4,0
  417| 005B34 stw        90060000   1     ST4A      (*)_object._object.ob_refcnt(gr6,0)=gr0                                                                       417| 005BA4 bc         418200BC   1     BT         CL.863,cr0,0x4/eq,taken=40%(40,60)
  417| 005B38 cmpwi      2C000000   1     C4        cr0=gr0,0                                                                                                     419| 005BA8 bc         418000A8   1     BT         CL.2227,cr0,0x1/lt,taken=40%(40,60)
  417| 005B3C bc         41820118   1     BT        CL.849,cr0,0x4/eq,taken=40%(40,60)                                                                            493|                                CL.862:
    0| 005B40 bc         41800104   1     BT        CL.2178,cr0,0x1/lt,taken=40%(40,60)                                                                           629| 005BAC lwz        80A10040   1     L4A        gr5=tb(gr1,64)
  627|                                CL.560:                                                                                                                     415| 005BB0 lwz        80E20004   1     L4A        gr7=._Py_RefTotal(gr2,0)
  628| 005B44 lwz        80A10048   1     L4A       gr5=et(gr1,72)                                                                                                  0| 005BB4 or.        7CA02B79   1     LR_R       gr0,cr0=gr5
  415| 005B48 lwz        80820004   1     L4A       gr4=._Py_RefTotal(gr2,0)                                                                                        0| 005BB8 lwz        80620018   1     L4A        gr3=.+CONSTANT_AREA(gr2,0)
    0| 005B4C lwz        80620018   1     L4A       gr3=.+CONSTANT_AREA(gr2,0)                                                                                    491| 005BBC bc         4182002C   0     BT         CL.569,cr0,0x4/eq,taken=30%(30,70)







Wed Apr 15 07:30:04 CDT 2020  Page 167


    0| 005B50 or.        7CA02B79   1     LR_R      gr0,cr0=gr5                                                                                                   408| 005BC0 addi       38631124   2     AI         gr3=gr3,4388
  491| 005B54 bc         4182002C   1     BT        CL.862,cr0,0x4/eq,taken=30%(30,70)                                                                            415| 005BC4 lwz        80870000   1     L4A        gr4=_Py_RefTotal(gr7,0)
  408| 005B58 addi       38631124   2     AI        gr3=gr3,4388                                                                                                  417| 005BC8 lwz        80C50000   1     L4A        gr6=(*)_object._object.ob_refcnt(gr5,0)
  415| 005B5C lwz        80C40000   1     L4A       gr6=<s117:d0:l4>(gr4,0)                                                                                       415| 005BCC addi       3804FFFF   1     AI         gr0=gr4,-1
  417| 005B60 lwz        80E50000   1     L4A       gr7=(*)_object._object.ob_refcnt(gr5,0)                                                                       415| 005BD0 stw        90070000   1     ST4A       _Py_RefTotal(gr7,0)=gr0
  415| 005B64 addi       3806FFFF   1     AI        gr0=gr6,-1                                                                                                    417| 005BD4 addi       3886FFFF   1     AI         gr4=gr6,-1
  415| 005B68 stw        90040000   1     ST4A      <s117:d0:l4>(gr4,0)=gr0                                                                                       417| 005BD8 stw        90850000   1     ST4A       (*)_object._object.ob_refcnt(gr5,0)=gr4
  417| 005B6C addi       3887FFFF   1     AI        gr4=gr7,-1                                                                                                    417| 005BDC cmpwi      2C040000   1     C4         cr0=gr4,0
  417| 005B70 stw        90850000   1     ST4A      (*)_object._object.ob_refcnt(gr5,0)=gr4                                                                       417| 005BE0 bc         41820060   1     BT         CL.869,cr0,0x4/eq,taken=40%(40,60)
  417| 005B74 cmpwi      2C040000   1     C4        cr0=gr4,0                                                                                                     419| 005BE4 bc         4180004C   1     BT         CL.2228,cr0,0x1/lt,taken=40%(40,60)
  417| 005B78 bc         418200BC   1     BT        CL.863,cr0,0x4/eq,taken=40%(40,60)                                                                            632|                                CL.569:
  419| 005B7C bc         418000A8   1     BT        CL.2188,cr0,0x1/lt,taken=40%(40,60)                                                                           638| 005BE8 addi       38600000   1     LI         gr3=0
  493|                                CL.862:                                                                                                                     633| 005BEC cmpwi      2C1E0000   1     C4         cr0=gr30,0
  629| 005B80 lwz        80A10040   1     L4A       gr5=tb(gr1,64)                                                                                                401| 005BF0 lwz        80820004   1     L4A        gr4=._Py_RefTotal(gr2,0)
  415| 005B84 lwz        80E20004   1     L4A       gr7=._Py_RefTotal(gr2,0)                                                                                      633| 005BF4 bc         40820020   0     BF         CL.571,cr0,0x4/eq,taken=50%(0,0)
    0| 005B88 lwz        80620018   1     L4A       gr3=.+CONSTANT_AREA(gr2,0)                                                                                    634| 005BF8 lwz        83C20008   2     L4A        gr30=._Py_NoneStruct(gr2,0)
    0| 005B8C or.        7CA02B79   1     LR_R      gr0,cr0=gr5                                                                                                   401| 005BFC lwz        80A40000   1     L4A        gr5=_Py_RefTotal(gr4,0)
  491| 005B90 bc         4182002C   1     BT        CL.569,cr0,0x4/eq,taken=30%(30,70)                                                                            403| 005C00 lwz        80DE0000   1     L4A        gr6=_Py_NoneStruct%##1(gr30,0)
  408| 005B94 addi       38631124   2     AI        gr3=gr3,4388                                                                                                  401| 005C04 addi       38050001   1     AI         gr0=gr5,1
  415| 005B98 lwz        80870000   1     L4A       gr4=<s117:d0:l4>(gr7,0)                                                                                       401| 005C08 stw        90040000   1     ST4A       _Py_RefTotal(gr4,0)=gr0
  417| 005B9C lwz        80C50000   1     L4A       gr6=(*)_object._object.ob_refcnt(gr5,0)                                                                       403| 005C0C addi       38860001   1     AI         gr4=gr6,1
  415| 005BA0 addi       3804FFFF   1     AI        gr0=gr4,-1                                                                                                    403| 005C10 stw        909E0000   1     ST4A       _Py_NoneStruct%##1(gr30,0)=gr4
  415| 005BA4 stw        90070000   1     ST4A      <s117:d0:l4>(gr7,0)=gr0                                                                                       636|                                CL.571:
  417| 005BA8 addi       3886FFFF   1     AI        gr4=gr6,-1                                                                                                    637| 005C14 stw        93DD0000   1     ST4A       (*)_object*(gr29,0)=gr30
  417| 005BAC stw        90850000   1     ST4A      (*)_object._object.ob_refcnt(gr5,0)=gr4                                                                         0| 005C18 lwz        83A10064   1     L4A        gr29=#stack(gr1,100)
  417| 005BB0 cmpwi      2C040000   1     C4        cr0=gr4,0                                                                                                       0| 005C1C lwz        83C10068   1     L4A        gr30=#stack(gr1,104)
  417| 005BB4 bc         41820060   1     BT        CL.869,cr0,0x4/eq,taken=40%(40,60)                                                                              0| 005C20 lwz        80010078   1     L4A        gr0=#stack(gr1,120)
  419| 005BB8 bc         4180004C   1     BT        CL.2189,cr0,0x1/lt,taken=40%(40,60)                                                                           639| 005C24 addi       38210070   1     AI         gr1=gr1,112
  632|                                CL.569:                                                                                                                       0| 005C28 mtspr      7C0803A6   1     LLR        lr=gr0
  638| 005BBC addi       38600000   1     LI        gr3=0                                                                                                         639| 005C2C bclr       4E800020   3     BA         lr
  633| 005BC0 cmpwi      2C1E0000   1     C4        cr0=gr30,0                                                                                                      0|                                CL.2228:
  401| 005BC4 lwz        80820004   1     L4A       gr4=._Py_RefTotal(gr2,0)                                                                                      420| 005C30 addi       388001EC   1     LI         gr4=492
  633| 005BC8 bc         40820020   0     BF        CL.571,cr0,0x4/eq,taken=50%(0,0)                                                                              420| 005C34 bl         4BFFA3CD   0     CALL       _Py_NegativeRefcount,3,(*)Cuchar",gr3,gr4,(*)_object",gr5,#ProcAlias",_Py_NegativeRefcount",fcr",gr1,cr[01
  634| 005BCC lwz        83C20008   2     L4A       gr30=._Py_NoneStruct(gr2,0)                                                                                   420| 005C38 ori        60000000   1
  401| 005BD0 lwz        80A40000   1     L4A       gr5=<s117:d0:l4>(gr4,0)                                                                                       423| 005C3C b          4BFFFFAC   0     B          CL.569,-1
  403| 005BD4 lwz        80DE0000   1     L4A       gr6=<s119:d0:l4>(gr30,0)                                                                                      423|                                CL.869:
  401| 005BD8 addi       38050001   1     AI        gr0=gr5,1                                                                                                     425| 005C40 ori        60A30000   1     LR         gr3=gr5
  401| 005BDC stw        90040000   1     ST4A      <s117:d0:l4>(gr4,0)=gr0                                                                                       425| 005C44 bl         4BFFA3BD   0     CALL       _Py_Dealloc,1,(*)_object",gr3,#ProcAlias",_Py_Dealloc",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",
  403| 005BE0 addi       38860001   1     AI        gr4=gr6,1                                                                                                     425| 005C48 ori        60000000   1
  403| 005BE4 stw        909E0000   1     ST4A      <s119:d0:l4>(gr30,0)=gr4                                                                                      630| 005C4C b          4BFFFF9C   0     B          CL.569,-1
  636|                                CL.571:                                                                                                                       0|                                CL.2227:
  637| 005BE8 stw        93DD0000   1     ST4A      (*)_object*(gr29,0)=gr30                                                                                      420| 005C50 addi       388001EC   1     LI         gr4=492
    0| 005BEC lwz        83A10084   1     L4A       gr29=#stack(gr1,132)                                                                                          420| 005C54 bl         4BFFA3AD   0     CALL       _Py_NegativeRefcount,3,(*)Cuchar",gr3,gr4,(*)_object",gr5,#ProcAlias",_Py_NegativeRefcount",fcr",gr1,cr[01
    0| 005BF0 lwz        83C10088   1     L4A       gr30=#stack(gr1,136)                                                                                          420| 005C58 ori        60000000   1
  639| 005BF4 addi       38210090   1     AI        gr1=gr1,144                                                                                                   423| 005C5C b          4BFFFF50   0     B          CL.862,-1
    0| 005BF8 lwz        80010008   1     L4A       gr0=#stack(gr1,8)                                                                                             423|                                CL.863:
    0| 005BFC mtspr      7C0803A6   2     LLR       lr=gr0                                                                                                        425| 005C60 ori        60A30000   1     LR         gr3=gr5
  639| 005C00 bclr       4E800020   3     BA        lr                                                                                                            425| 005C64 bl         4BFFA39D   0     CALL       _Py_Dealloc,1,(*)_object",gr3,#ProcAlias",_Py_Dealloc",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",
    0|                                CL.2189:                                                                                                                    425| 005C68 ori        60000000   1
  420| 005C04 addi       388001EC   1     LI        gr4=492                                                                                                         0| 005C6C b          4BFFFF40   0     B          CL.862,-1
  420| 005C08 bl         4BFFA3F9   0     CALL      _Py_NegativeRefcount,3,(*)Cuchar",gr3,gr4,(*)_object",gr5,#ProcAlias",_Py_NegativeRefcount",fcr",gr1,cr[015   423|                                CL.849:
  420| 005C0C ori        60000000   1                                                                                                                             425| 005C70 ori        60C30000   1     LR         gr3=gr6
  423| 005C10 b          4BFFFFAC   0     B         CL.569,-1                                                                                                     425| 005C74 bl         4BFFA38D   0     CALL       _Py_Dealloc,1,(*)_object",gr3,#ProcAlias",_Py_Dealloc",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",
  423|                                CL.869:                                                                                                                     425| 005C78 ori        60000000   1
  425| 005C14 ori        60A30000   1     LR        gr3=gr5                                                                                                         0| 005C7C b          4BFFFEF4   0     B          CL.560,-1
  425| 005C18 bl         4BFFA3E9   0     CALL      _Py_Dealloc,1,(*)_object",gr3,#ProcAlias",_Py_Dealloc",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",l     0|                                CL.2223:







Wed Apr 15 07:30:04 CDT 2020  Page 168


  425| 005C1C ori        60000000   1                                                                                                                             602| 005C80 ori        60030000   1     LR         gr3=gr0
  630| 005C20 b          4BFFFF9C   0     B         CL.569,-1                                                                                                     602| 005C84 bl         4BFFA37D   0     CALL       gr3=PyType_IsSubtype,2,(*)_typeobject",gr3,(*)_typeobject",gr4,#ProcAlias",PyType_IsSubtype",fcr",gr1,cr[0
    0|                                CL.2188:                                                                                                                    602| 005C88 ori        60000000   1
  420| 005C24 addi       388001EC   1     LI        gr4=492                                                                                                         0| 005C8C lwz        80C10044   1     L4A        gr6=ev(gr1,68)
  420| 005C28 bl         4BFFA3D9   0     CALL      _Py_NegativeRefcount,3,(*)Cuchar",gr3,gr4,(*)_object",gr5,#ProcAlias",_Py_NegativeRefcount",fcr",gr1,cr[015   606| 005C90 lwz        80010048   1     L4A        gr0=et(gr1,72)
  420| 005C2C ori        60000000   1                                                                                                                             602| 005C94 cmpwi      2C030000   1     C4         cr0=gr3,0
  423| 005C30 b          4BFFFF50   0     B         CL.862,-1                                                                                                     602| 005C98 bc         4082FE94   1     BF         CL.2219,cr0,0x4/eq,taken=50%(0,0)
  423|                                CL.863:                                                                                                                     606| 005C9C lwz        809F0000   2     L4A        gr4=PyExc_StopIteration(gr31,0)
  425| 005C34 ori        60A30000   1     LR        gr3=gr5                                                                                                       606| 005CA0 lwz        80610044   1     L4A        gr3=ev(gr1,68)
  425| 005C38 bl         4BFFA3C9   0     CALL      _Py_Dealloc,1,(*)_object",gr3,#ProcAlias",_Py_Dealloc",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",l   606| 005CA4 cmplw      7C040040   1     CL4        cr0=gr4,gr0
  425| 005C3C ori        60000000   1                                                                                                                             606| 005CA8 bc         40820028   1     BF         CL.564,cr0,0x4/eq,taken=50%(0,0)
    0| 005C40 b          4BFFFF40   0     B         CL.862,-1                                                                                                     606| 005CAC lwz        80630004   2     L4A        gr3=(*)_object._object.ob_type(gr3,4)
  419|                                CL.2178:                                                                                                                    617| 005CB0 bl         4BFFA351   0     CALL       gr3=PyType_GetFlags,1,(*)_typeobject",gr3,#ProcAlias",PyType_GetFlags",fcr",gr1,cr[01567]",gr0",gr4"-gr12"
  420| 005C44 ori        60C50000   1     LR        gr5=gr6                                                                                                       617| 005CB4 ori        60000000   1
  420| 005C48 bl         4BFFA3B9   0     CALL      _Py_NegativeRefcount,3,(*)Cuchar",gr3,gr4,(*)_object",gr5,#ProcAlias",_Py_NegativeRefcount",fcr",gr1,cr[015   615| 005CB8 lwz        83C10044   1     L4A        gr30=ev(gr1,68)
  420| 005C4C ori        60000000   1                                                                                                                             617| 005CBC andis.     74600400   1     RN4_R      gr0,cr0=gr3,0,0x4000000
  423| 005C50 b          4BFFFEF4   0     B         CL.560,-1                                                                                                     606| 005CC0 bc         4082000C   1     BF         CL.2224,cr0,0x4/eq,taken=40%(40,60)
  423|                                CL.849:                                                                                                                       0|                                CL.2222:
  425| 005C54 ori        60C30000   1     LR        gr3=gr6                                                                                                         0| 005CC4 lwz        83E1006C   1     L4A        gr31=#stack(gr1,108)
  425| 005C58 bl         4BFFA3A9   0     CALL      _Py_Dealloc,1,(*)_object",gr3,#ProcAlias",_Py_Dealloc",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",l     0| 005CC8 b          4BFFFEA8   0     B          CL.560,-1
  425| 005C5C ori        60000000   1                                                                                                                               0|                                CL.2224:
    0| 005C60 b          4BFFFEE4   0     B         CL.560,-1                                                                                                       0| 005CCC lwz        83C10068   1     L4A        gr30=#stack(gr1,104)
    0|                                CL.2183:                                                                                                                    616|                                CL.564:
  602| 005C64 lwz        80660004   1     L4A       gr3=(*)_object._object.ob_type(gr6,4)                                                                         618| 005CD0 addi       38610048   1     AI         gr3=gr1,72
  602| 005C68 bl         4BFFA399   0     CALL      gr3=PyType_IsSubtype,2,(*)_typeobject",gr3,(*)_typeobject",gr4,#ProcAlias",PyType_IsSubtype",fcr",gr1,cr[01   618| 005CD4 addi       38810044   1     AI         gr4=gr1,68
  602| 005C6C ori        60000000   1                                                                                                                             618| 005CD8 addi       38A10040   1     AI         gr5=gr1,64
    0| 005C70 lwz        80C10044   1     L4A       gr6=ev(gr1,68)                                                                                                618| 005CDC bl         4BFFA325   0     CALL       PyErr_NormalizeException,3,(*)_object*",gr3,(*)_object*",gr4,(*)_object*",gr5,#ProcAlias",(*)_object",(*)_
  606| 005C74 lwz        80010048   1     L4A       gr0=et(gr1,72)                                                                                                618| 005CE0 ori        60000000   1
  602| 005C78 cmpwi      2C030000   1     C4        cr0=gr3,0                                                                                                     619| 005CE4 lwz        809F0000   1     L4A        gr4=PyExc_StopIteration(gr31,0)
  602| 005C7C bc         4082FE90   1     BF        CL.2179,cr0,0x4/eq,taken=50%(0,0)                                                                             619| 005CE8 lwz        80C10044   1     L4A        gr6=ev(gr1,68)
  606| 005C80 lwz        809F0000   2     L4A       gr4=<s139:d0:l4>(gr31,0)                                                                                      128| 005CEC lwz        80060004   2     L4A        gr0=(*)C_object._object.ob_type(gr6,4)
  606| 005C84 lwz        80610044   1     L4A       gr3=ev(gr1,68)                                                                                                128| 005CF0 cmplw      7C002040   2     CL4        cr0=gr0,gr4
  606| 005C88 cmplw      7C040040   1     CL4       cr0=gr4,gr0                                                                                                   619| 005CF4 bc         4082007C   1     BF         CL.2225,cr0,0x4/eq,taken=40%(40,60)
  606| 005C8C bc         40820028   1     BF        CL.564,cr0,0x4/eq,taken=50%(0,0)                                                                              619|                                CL.566:
  606| 005C90 lwz        80630004   2     L4A       gr3=(*)_object._object.ob_type(gr3,4)                                                                         619| 005CF8 addi       3BE00001   1     LI         gr31=1
  617| 005C94 bl         4BFFA36D   0     CALL      gr3=PyType_GetFlags,1,(*)_typeobject",gr3,#ProcAlias",PyType_GetFlags",fcr",gr1,cr[01567]",gr0",gr4"-gr12",   619|                                CL.567:
  617| 005C98 ori        60000000   1                                                                                                                             408| 005CFC addi       38800271   1     LI         gr4=625
  615| 005C9C lwz        83C10044   1     L4A       gr30=ev(gr1,68)                                                                                               619| 005D00 cmpwi      2C1F0000   1     C4         cr0=gr31,0
  606| 005CA0 andis.     74600400   1     RN4_R     gr0,cr0=gr3,0,0x4000000                                                                                         0| 005D04 lwz        81020018   1     L4A        gr8=.+CONSTANT_AREA(gr2,0)
  606| 005CA4 bc         4082000C   1     BF        CL.2184,cr0,0x4/eq,taken=40%(40,60)                                                                           619| 005D08 bc         41820038   0     BT         CL.2226,cr0,0x4/eq,taken=30%(30,70)
    0|                                CL.2182:                                                                                                                    623| 005D0C lwz        83C60020   2     L4A        gr30=(*)aggr#8.value(gr6,32)
    0| 005CA8 lwz        83E1008C   1     L4A       gr31=#stack(gr1,140)                                                                                            0| 005D10 lwz        83E1006C   1     L4A        gr31=#stack(gr1,108)
    0| 005CAC b          4BFFFE98   0     B         CL.560,-1                                                                                                     408| 005D14 addi       38681110   1     AI         gr3=gr8,4368
    0|                                CL.2184:                                                                                                                    403| 005D18 lwz        80BE0000   1     L4A        gr5=(*)_object._object.ob_refcnt(gr30,0)
    0| 005CB0 lwz        83C10088   1     L4A       gr30=#stack(gr1,136)                                                                                          403| 005D1C addi       38050001   2     AI         gr0=gr5,1
  616|                                CL.564:                                                                                                                     403| 005D20 stw        901E0000   1     ST4A       (*)_object._object.ob_refcnt(gr30,0)=gr0
  618| 005CB4 addi       38610048   1     AI        gr3=gr1,72                                                                                                    417| 005D24 lwz        80A60000   1     L4A        gr5=(*)_object._object.ob_refcnt(gr6,0)
  618| 005CB8 addi       38810044   1     AI        gr4=gr1,68                                                                                                    417| 005D28 addi       3805FFFF   2     AI         gr0=gr5,-1
  618| 005CBC addi       38A10040   1     AI        gr5=gr1,64                                                                                                    417| 005D2C stw        90060000   1     ST4A       (*)_object._object.ob_refcnt(gr6,0)=gr0
  618| 005CC0 bl         4BFFA341   0     CALL      PyErr_NormalizeException,3,(*)_object*",gr3,(*)_object*",gr4,(*)_object*",gr5,#ProcAlias",(*)_object",(*)_o   417| 005D30 cmpwi      2C000000   1     C4         cr0=gr0,0
  618| 005CC4 ori        60000000   1                                                                                                                             417| 005D34 bc         4182FF3C   1     BT         CL.849,cr0,0x4/eq,taken=40%(40,60)
  619| 005CC8 lwz        809F0000   1     L4A       gr4=<s139:d0:l4>(gr31,0)                                                                                      419| 005D38 bc         4080FE38   1     BF         CL.560,cr0,0x1/lt,taken=50%(0,0)
  619| 005CCC lwz        80C10044   1     L4A       gr6=ev(gr1,68)                                                                                                420| 005D3C b          4BFFFE28   1     B          CL.1577,-1
  128| 005CD0 lwz        80060004   2     L4A       gr0=(*)C_object._object.ob_type(gr6,4)                                                                          0|                                CL.2226:
  128| 005CD4 cmplw      7C002040   2     CL4       cr0=gr0,gr4                                                                                                   620| 005D40 lwz        80610048   1     L4A        gr3=et(gr1,72)
  619| 005CD8 bc         4082007C   1     BF        CL.2185,cr0,0x4/eq,taken=40%(40,60)                                                                           620| 005D44 lwz        80A10040   1     L4A        gr5=tb(gr1,64)







Wed Apr 15 07:30:04 CDT 2020  Page 169


  619|                                CL.566:                                                                                                                     620| 005D48 ori        60C40000   1     LR         gr4=gr6
  619| 005CDC addi       3BE00001   1     LI        gr31=1                                                                                                          0| 005D4C lwz        83E1006C   1     L4A        gr31=#stack(gr1,108)
  619|                                CL.567:                                                                                                                       0| 005D50 lwz        83A10064   1     L4A        gr29=#stack(gr1,100)
  408| 005CE0 addi       38800271   1     LI        gr4=625                                                                                                       620| 005D54 bl         4BFFA2AD   0     CALL       PyErr_Restore,3,(*)_object",gr3,(*)_object",gr4,(*)_object",gr5,#ProcAlias",PyErr_Restore",fcr",gr1,cr[015
  619| 005CE4 cmpwi      2C1F0000   1     C4        cr0=gr31,0                                                                                                    620| 005D58 ori        60000000   1
    0| 005CE8 lwz        81020018   1     L4A       gr8=.+CONSTANT_AREA(gr2,0)                                                                                    621| 005D5C addi       3860FFFF   1     LI         gr3=-1
  619| 005CEC bc         41820038   0     BT        CL.2186,cr0,0x4/eq,taken=30%(30,70)                                                                             0| 005D60 lwz        80010078   1     L4A        gr0=#stack(gr1,120)
  623| 005CF0 lwz        83C60020   2     L4A       gr30=(*)aggr#8.value(gr6,32)                                                                                  639| 005D64 addi       38210070   1     AI         gr1=gr1,112
    0| 005CF4 lwz        83E1008C   1     L4A       gr31=#stack(gr1,140)                                                                                            0| 005D68 mtspr      7C0803A6   1     LLR        lr=gr0
  408| 005CF8 addi       38681110   1     AI        gr3=gr8,4368                                                                                                  639| 005D6C bclr       4E800020   3     BA         lr
  403| 005CFC lwz        80BE0000   1     L4A       gr5=(*)_object._object.ob_refcnt(gr30,0)                                                                        0|                                CL.2225:
  403| 005D00 addi       38050001   2     AI        gr0=gr5,1                                                                                                     619| 005D70 addi       3BE00000   1     LI         gr31=0
  403| 005D04 stw        901E0000   1     ST4A      (*)_object._object.ob_refcnt(gr30,0)=gr0                                                                      619| 005D74 ori        60030000   1     LR         gr3=gr0
  417| 005D08 lwz        80A60000   1     L4A       gr5=(*)_object._object.ob_refcnt(gr6,0)                                                                       619| 005D78 bl         4BFFA289   0     CALL       gr3=PyType_IsSubtype,2,(*)_typeobject",gr3,(*)_typeobject",gr4,#ProcAlias",PyType_IsSubtype",fcr",gr1,cr[0
  417| 005D0C addi       3805FFFF   2     AI        gr0=gr5,-1                                                                                                    619| 005D7C ori        60000000   1
  417| 005D10 stw        90060000   1     ST4A      (*)_object._object.ob_refcnt(gr6,0)=gr0                                                                         0| 005D80 lwz        80C10044   1     L4A        gr6=ev(gr1,68)
  417| 005D14 cmpwi      2C000000   1     C4        cr0=gr0,0                                                                                                     619| 005D84 cmpwi      2C030000   1     C4         cr0=gr3,0
  417| 005D18 bc         4182FF3C   1     BT        CL.849,cr0,0x4/eq,taken=50%(0,0)                                                                              619| 005D88 bc         4182FF74   1     BT         CL.567,cr0,0x4/eq,taken=50%(0,0)
  419| 005D1C bc         4180FF28   1     BT        CL.2178,cr0,0x1/lt,taken=40%(40,60)                                                                             0| 005D8C b          4BFFFF6C   1     B          CL.566,-1
  419| 005D20 b          4BFFFE24   1     B         CL.560,-1                                                                                                     630|                                CL.559:
    0|                                CL.2186:                                                                                                                      0| 005D90 lwz        83E1006C   1     L4A        gr31=#stack(gr1,108)
  620| 005D24 lwz        80610048   1     L4A       gr3=et(gr1,72)                                                                                                630| 005D94 bl         4BFFA26D   0     CALL       gr3=PyErr_Occurred,0,#ProcAlias",PyErr_Occurred",fcr",gr1,cr[01567]",gr0",gr4"-gr12",fp0"-fp13",mq",lr",fc
  620| 005D28 lwz        80A10040   1     L4A       gr5=tb(gr1,64)                                                                                                630| 005D98 ori        60000000   1
  620| 005D2C ori        60C40000   1     LR        gr4=gr6                                                                                                       630| 005D9C cmpwi      2C030000   1     C4         cr0=gr3,0
    0| 005D30 lwz        83E1008C   1     L4A       gr31=#stack(gr1,140)                                                                                          630| 005DA0 bc         4182FE48   1     BT         CL.569,cr0,0x4/eq,taken=70%(70,30)
    0| 005D34 lwz        83A10084   1     L4A       gr29=#stack(gr1,132)                                                                                          631| 005DA4 addi       3860FFFF   2     LI         gr3=-1
  620| 005D38 bl         4BFFA2C9   0     CALL      PyErr_Restore,3,(*)_object",gr3,(*)_object",gr4,(*)_object",gr5,#ProcAlias",PyErr_Restore",fcr",gr1,cr[0156     0| 005DA8 lwz        83C10068   1     L4A        gr30=#stack(gr1,104)
  620| 005D3C ori        60000000   1                                                                                                                               0| 005DAC lwz        83A10064   1     L4A        gr29=#stack(gr1,100)
  621| 005D40 addi       3860FFFF   1     LI        gr3=-1                                                                                                          0| 005DB0 lwz        80010078   1     L4A        gr0=#stack(gr1,120)
  639| 005D44 addi       38210090   1     AI        gr1=gr1,144                                                                                                   639| 005DB4 addi       38210070   1     AI         gr1=gr1,112
    0| 005D48 lwz        80010008   1     L4A       gr0=#stack(gr1,8)                                                                                               0| 005DB8 mtspr      7C0803A6   1     LLR        lr=gr0
    0| 005D4C mtspr      7C0803A6   2     LLR       lr=gr0                                                                                                        639| 005DBC bclr       4E800020   3     BA         lr
  639| 005D50 bclr       4E800020   3     BA        lr                                                                                                               |               Tag Table
    0|                                CL.2185:                                                                                                                       | 005DC0        00000000 00002041 80030100 00000000 00000300 001E5F50
  619| 005D54 addi       3BE00000   1     LI        gr31=0                                                                                                           | 005DD8        7947656E 5F466574 63685374 6F704974 65726174 696F6E56
  619| 005D58 lwz        80660004   1     L4A       gr3=(*)_object._object.ob_type(gr6,4)                                                                            | 005DF0        616C7565
  619| 005D5C bl         4BFFA2A5   0     CALL      gr3=PyType_IsSubtype,2,(*)_typeobject",gr3,(*)_typeobject",gr4,#ProcAlias",PyType_IsSubtype",fcr",gr1,cr[01      |               Instruction count          192
  619| 005D60 ori        60000000   1                                                                                                                                |               Straight-line exec time    190
    0| 005D64 lwz        80C10044   1     L4A       gr6=ev(gr1,68)                                                                                               GPR's set/used:   ssus ssss ssss s---  ---- ---- --ss ssss
  619| 005D68 cmpwi      2C030000   1     C4        cr0=gr3,0                                                                                                    FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----
  619| 005D6C bc         4182FF74   1     BT        CL.567,cr0,0x4/eq,taken=50%(0,0)                                                                             CCR's set/used:   ss-- -sss
    0| 005D70 b          4BFFFF6C   1     B         CL.566,-1                                                                                                        | 000000                             PDEF       _PyGen_SetStopIterationValue
  630|                                CL.559:                                                                                                                     554|                                    PROC       value,gr3
    0| 005D74 lwz        83E1008C   1     L4A       gr31=#stack(gr1,140)                                                                                            0| 005E00 mfspr      7C0802A6   1     LFLR       gr0=lr
  630| 005D78 bl         4BFFA289   0     CALL      gr3=PyErr_Occurred,0,#ProcAlias",PyErr_Occurred",fcr",gr1,cr[01567]",gr0",gr4"-gr12",fp0"-fp13",mq",lr",fcr     0| 005E04 stwu       9421FF60   1     ST4U       gr1,#stack(gr1,-160)=gr1
  630| 005D7C ori        60000000   1                                                                                                                               0| 005E08 stw        900100A8   1     ST4A       #stack(gr1,168)=gr0
  630| 005D80 cmpwi      2C030000   1     C4        cr0=gr3,0                                                                                                       0| 005E0C stw        93E1009C   1     ST4A       #stack(gr1,156)=gr31
  630| 005D84 bc         4182FE38   1     BT        CL.569,cr0,0x4/eq,taken=70%(70,30)                                                                              0| 005E10 stw        93C10098   1     ST4A       #stack(gr1,152)=gr30
  631| 005D88 addi       3860FFFF   2     LI        gr3=-1                                                                                                          0| 005E14 stw        93A10094   1     ST4A       #stack(gr1,148)=gr29
    0| 005D8C lwz        83C10088   1     L4A       gr30=#stack(gr1,136)                                                                                            0| 005E18 or.        7C7E1B79   1     LR_R       gr30,cr0=gr3
    0| 005D90 lwz        83A10084   1     L4A       gr29=#stack(gr1,132)                                                                                            0| 005E1C stw        93810090   1     ST4A       #stack(gr1,144)=gr28
  639| 005D94 addi       38210090   1     AI        gr1=gr1,144                                                                                                     0| 005E20 stw        9361008C   1     ST4A       #stack(gr1,140)=gr27
    0| 005D98 lwz        80010008   1     L4A       gr0=#stack(gr1,8)                                                                                               0| 005E24 stw        93410088   1     ST4A       #stack(gr1,136)=gr26
    0| 005D9C mtspr      7C0803A6   2     LLR       lr=gr0                                                                                                        118| 005E28 stw        90410014   1     ST4A       #cur_toc(gr1,20)=gr2
  639| 005DA0 bclr       4E800020   3     BA        lr                                                                                                            558| 005E2C bc         41820300   0     BT         CL.573,cr0,0x4/eq,taken=30%(30,70)
     |               Tag Table                                                                                                                                    559| 005E30 lwz        807E0004   2     L4A        gr3=(*)_object._object.ob_type(gr30,4)







Wed Apr 15 07:30:04 CDT 2020  Page 170


     | 005DA4        00000000 00002041 80030100 00000000 00000304 001E5F50                                                                                        617| 005E34 bl         4BFFA1CD   0     CALL       gr3=PyType_GetFlags,1,(*)_typeobject",gr3,#ProcAlias",PyType_GetFlags",fcr",gr1,cr[01567]",gr0",gr4"-gr12"
     | 005DBC        7947656E 5F466574 63685374 6F704974 65726174 696F6E56                                                                                        617| 005E38 ori        60000000   1
     | 005DD4        616C7565                                                                                                                                     574| 005E3C lwz        83E2002C   1     L4A        gr31=.PyExc_StopIteration(gr2,0)
     |               Instruction count          193                                                                                                               617| 005E40 andis.     74600400   1     RN4_R      gr0,cr0=gr3,0,0x4000000
     |               Straight-line exec time    196                                                                                                               559| 005E44 bc         40820314   1     BF         CL.1700,cr0,0x4/eq,taken=50%(0,0)
 GPR's set/used:   ssus ssss ssss s---  ---- ---- --ss ssss                                                                                                       559| 005E48 lwz        807E0004   2     L4A        gr3=(*)_object._object.ob_type(gr30,4)
 FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----                                                                                                       617| 005E4C bl         4BFFA1B5   0     CALL       gr3=PyType_GetFlags,1,(*)_typeobject",gr3,#ProcAlias",PyType_GetFlags",fcr",gr1,cr[01567]",gr0",gr4"-gr12"
 CCR's set/used:   ss-- -sss                                                                                                                                      617| 005E50 ori        60000000   1
     | 000000                             PDEF     _PyGen_SetStopIterationValue                                                                                   617| 005E54 andis.     74604000   1     RN4_R      gr0,cr0=gr3,0,0x40000000
  554|                                    PROC      value,gr3                                                                                                     559| 005E58 bc         418202D0   1     BT         CL.2046,cr0,0x4/eq,taken=30%(30,70)
    0| 005DE0 mfspr      7C0802A6   1     LFLR      gr0=lr                                                                                                        185| 005E5C stw        93C1007C   2     ST4A       _args(gr1,124)=gr30
    0| 005DE4 stw        90010008   2     ST4A      #stack(gr1,8)=gr0                                                                                             574| 005E60 lwz        835F0000   1     L4A        gr26=PyExc_StopIteration(gr31,0)
    0| 005DE8 stw        93E1FFFC   1     ST4A      #stack(gr1,-4)=gr31                                                                                           186| 005E64 bl         4BFFA19D   0     CALL       gr3=PyThreadState_Get,0,#ProcAlias",PyThreadState_Get",fcr",gr1,cr[01567]",gr0",gr4"-gr12",fp0"-fp13",mq",
    0| 005DEC or.        7C7F1B79   1     LR_R      gr31,cr0=gr3                                                                                                  186| 005E68 ori        60000000   1
    0| 005DF0 stw        93C1FFF8   1     ST4A      #stack(gr1,-8)=gr30                                                                                           188| 005E6C ori        607E0000   1     LR         gr30=gr3
    0| 005DF4 stw        93A1FFF4   1     ST4A      #stack(gr1,-12)=gr29                                                                                           72| 005E70 cmpwi      2C1A0000   1     C4         cr0=gr26,0
    0| 005DF8 stw        9381FFF0   1     ST4A      #stack(gr1,-16)=gr28                                                                                          187| 005E74 addis      3C608000   1     LIU        gr3=32768
    0| 005DFC stw        9361FFEC   1     ST4A      #stack(gr1,-20)=gr27                                                                                          187| 005E78 addi       3BA30001   1     AI         gr29=gr3,1
    0| 005E00 stw        9341FFE8   1     ST4A      #stack(gr1,-24)=gr26                                                                                           72| 005E7C bc         41820278   0     BT         CL.1701,cr0,0x4/eq,taken=30%(30,70)
    0| 005E04 stwu       9421FF30   1     ST4U      gr1,#stack(gr1,-208)=gr1                                                                                        0|                                CL.1703:
  118| 005E08 stw        90410014   1     ST4A      #cur_toc(gr1,20)=gr2                                                                                           73| 005E80 lwz        839A0004   1     L4A        gr28=(*)_object._object.ob_type(gr26,4)
  558| 005E0C bc         41820354   0     BT        CL.1993,cr0,0x4/eq,taken=30%(30,70)                                                                           617| 005E84 ori        63830000   2     LR         gr3=gr28
  559| 005E10 lwz        807F0004   1     L4A       gr3=(*)_object._object.ob_type(gr31,4)                                                                        617| 005E88 bl         4BFFA179   0     CALL       gr3=PyType_GetFlags,1,(*)_typeobject",gr3,#ProcAlias",PyType_GetFlags",fcr",gr1,cr[01567]",gr0",gr4"-gr12"
  617| 005E14 bl         4BFFA1ED   0     CALL      gr3=PyType_GetFlags,1,(*)_typeobject",gr3,#ProcAlias",PyType_GetFlags",fcr",gr1,cr[01567]",gr0",gr4"-gr12",   617| 005E8C ori        60000000   1
  617| 005E18 ori        60000000   1                                                                                                                              74| 005E90 andi.      70600800   1     RN4_R      gr0,cr0=gr3,0,0x800
  559| 005E1C andis.     74600400   1     RN4_R     gr0,cr0=gr3,0,0x4000000                                                                                        74| 005E94 bc         40820100   1     BF         CL.824,cr0,0x4/eq,taken=40%(40,60)
  559| 005E20 bc         4182032C   1     BT        CL.1579,cr0,0x4/eq,taken=50%(0,0)                                                                               0|                                CL.2056:
  564|                                CL.574:                                                                                                                     116| 005E98 ori        63C30000   1     LR         gr3=gr30
  574| 005E24 lwz        8342002C   1     L4A       gr26=.PyExc_StopIteration(gr2,0)                                                                              116| 005E9C ori        63440000   1     LR         gr4=gr26
  185| 005E28 stw        93E100AC   1     ST4A      _args(gr1,172)=gr31                                                                                           116| 005EA0 addi       38A1007C   1     AI         gr5=gr1,124
  574| 005E2C lwz        83FA0000   1     L4A       gr31=<s139:d0:l4>(gr26,0)                                                                                       0| 005EA4 lwz        83A10094   1     L4A        gr29=#stack(gr1,148)
  186| 005E30 bl         4BFFA1D1   0     CALL      gr3=PyThreadState_Get,0,#ProcAlias",PyThreadState_Get",fcr",gr1,cr[01567]",gr0",gr4"-gr12",fp0"-fp13",mq",l     0| 005EA8 lwz        83810090   1     L4A        gr28=#stack(gr1,144)
  186| 005E34 ori        60000000   1                                                                                                                             116| 005EAC addi       38C00001   1     LI         gr6=1
  187| 005E38 addis      3FC08000   1     LIU       gr30=32768                                                                                                    116| 005EB0 addi       38E00000   1     LI         gr7=0
  186| 005E3C ori        607D0000   1     LR        gr29=gr3                                                                                                      116| 005EB4 bl         4BFFA14D   0     CALL       gr3=_PyObject_MakeTpCall,5,(*)_ts",gr3,(*)_object",gr4,(*)_object*C",gr5,gr6,(*)_object",gr7,#ProcAlias",(
   72| 005E40 cmpwi      2C1F0000   1     C4        cr0=gr31,0                                                                                                    116| 005EB8 ori        60000000   1
   72| 005E44 bc         418202D4   1     BT        CL.1994,cr0,0x4/eq,taken=30%(30,70)                                                                           575| 005EBC or.        7C7E1B79   1     LR_R       gr30,cr0=gr3
   73| 005E48 lwz        839F0004   2     L4A       gr28=(*)_object._object.ob_type(gr31,4)                                                                       575| 005EC0 bc         418200B4   1     BT         CL.2047,cr0,0x4/eq,taken=30%(30,70)
  617| 005E4C ori        63830000   2     LR        gr3=gr28                                                                                                        0|                                CL.2055:
  617| 005E50 bl         4BFFA1B1   0     CALL      gr3=PyType_GetFlags,1,(*)_typeobject",gr3,#ProcAlias",PyType_GetFlags",fcr",gr1,cr[01567]",gr0",gr4"-gr12",     0| 005EC4 lwz        83410088   1     L4A        gr26=#stack(gr1,136)
  617| 005E54 ori        60000000   1                                                                                                                             577|                                CL.575:
   74| 005E58 andi.      70600800   1     RN4_R     gr0,cr0=gr3,0,0x800                                                                                           578| 005EC8 lwz        807F0000   1     L4A        gr3=PyExc_StopIteration(gr31,0)
   74| 005E5C bc         40820104   1     BF        CL.824,cr0,0x4/eq,taken=40%(40,60)                                                                            578| 005ECC ori        63C40000   1     LR         gr4=gr30
    0|                                CL.2005:                                                                                                                    578| 005ED0 bl         4BFFA131   0     CALL       PyErr_SetObject,2,(*)_object",gr3,(*)_object",gr4,#ProcAlias",PyErr_SetObject",fcr",gr1,cr[01567]",gr0",gr
  116| 005E60 ori        63A30000   1     LR        gr3=gr29                                                                                                      578| 005ED4 ori        60000000   1
  116| 005E64 ori        63E40000   1     LR        gr4=gr31                                                                                                      415| 005ED8 lwz        80820004   1     L4A        gr4=._Py_RefTotal(gr2,0)
  116| 005E68 addi       38A100AC   1     AI        gr5=gr1,172                                                                                                   417| 005EDC lwz        80BE0000   1     L4A        gr5=(*)_object._object.ob_refcnt(gr30,0)
    0| 005E6C lwz        83C100C8   1     L4A       gr30=#stack(gr1,200)                                                                                            0| 005EE0 lwz        80620018   1     L4A        gr3=.+CONSTANT_AREA(gr2,0)
    0| 005E70 lwz        838100C0   1     L4A       gr28=#stack(gr1,192)                                                                                          417| 005EE4 addi       3805FFFF   1     AI         gr0=gr5,-1
  116| 005E74 addi       38C00001   1     LI        gr6=1                                                                                                         417| 005EE8 stw        901E0000   1     ST4A       (*)_object._object.ob_refcnt(gr30,0)=gr0
  116| 005E78 addi       38E00000   1     LI        gr7=0                                                                                                         408| 005EEC addi       38631110   1     AI         gr3=gr3,4368
  116| 005E7C bl         4BFFA185   0     CALL      gr3=_PyObject_MakeTpCall,5,(*)_ts",gr3,(*)_object",gr4,(*)_object*C",gr5,gr6,(*)_object",gr7,#ProcAlias",(*   415| 005EF0 lwz        80A40000   1     L4A        gr5=_Py_RefTotal(gr4,0)
  116| 005E80 ori        60000000   1                                                                                                                             415| 005EF4 addi       38C5FFFF   2     AI         gr6=gr5,-1
  575| 005E84 cmpwi      2C030000   1     C4        cr0=gr3,0                                                                                                     415| 005EF8 stw        90C40000   1     ST4A       _Py_RefTotal(gr4,0)=gr6
  575| 005E88 bc         40820024   1     BF        CL.1991,cr0,0x4/eq,taken=40%(40,60)                                                                           417| 005EFC cmpwi      2C000000   1     C4         cr0=gr0,0
    0|                                CL.2004:                                                                                                                    417| 005F00 bc         4182004C   1     BT         CL.838,cr0,0x4/eq,taken=40%(40,60)







Wed Apr 15 07:30:04 CDT 2020  Page 171


  576| 005E8C addi       3860FFFF   1     LI        gr3=-1                                                                                                          0| 005F04 lwz        83E1009C   1     L4A        gr31=#stack(gr1,156)
    0| 005E90 lwz        83E100CC   1     L4A       gr31=#stack(gr1,204)                                                                                          419| 005F08 bc         4180001C   0     BT         CL.2051,cr0,0x1/lt,taken=40%(40,60)
    0| 005E94 lwz        83A100C4   1     L4A       gr29=#stack(gr1,196)                                                                                          580| 005F0C addi       38600000   2     LI         gr3=0
    0| 005E98 lwz        834100B8   1     L4A       gr26=#stack(gr1,184)                                                                                            0| 005F10 lwz        83C10098   1     L4A        gr30=#stack(gr1,152)
  581| 005E9C addi       382100D0   1     AI        gr1=gr1,208                                                                                                     0| 005F14 lwz        800100A8   1     L4A        gr0=#stack(gr1,168)
    0| 005EA0 lwz        80010008   1     L4A       gr0=#stack(gr1,8)                                                                                             581| 005F18 addi       382100A0   1     AI         gr1=gr1,160
    0| 005EA4 mtspr      7C0803A6   2     LLR       lr=gr0                                                                                                          0| 005F1C mtspr      7C0803A6   1     LLR        lr=gr0
  581| 005EA8 bclr       4E800020   3     BA        lr                                                                                                            581| 005F20 bclr       4E800020   3     BA         lr
    0|                                CL.1991:                                                                                                                      0|                                CL.2051:
  574| 005EAC ori        607F0000   1     LR        gr31=gr3                                                                                                      420| 005F24 addi       38800243   1     LI         gr4=579
  578| 005EB0 lwz        807A0000   1     L4A       gr3=<s139:d0:l4>(gr26,0)                                                                                      420| 005F28 ori        63C50000   1     LR         gr5=gr30
  578| 005EB4 ori        63E40000   1     LR        gr4=gr31                                                                                                      420| 005F2C bl         4BFFA0D5   0     CALL       _Py_NegativeRefcount,3,(*)Cuchar",gr3,gr4,(*)_object",gr5,#ProcAlias",_Py_NegativeRefcount",fcr",gr1,cr[01
    0| 005EB8 lwz        83A100C4   1     L4A       gr29=#stack(gr1,196)                                                                                          420| 005F30 ori        60000000   1
  578| 005EBC bl         4BFFA145   0     CALL      PyErr_SetObject,2,(*)_object",gr3,(*)_object",gr4,#ProcAlias",PyErr_SetObject",fcr",gr1,cr[01567]",gr0",gr3   580| 005F34 addi       38600000   1     LI         gr3=0
  578| 005EC0 ori        60000000   1                                                                                                                               0| 005F38 lwz        83C10098   1     L4A        gr30=#stack(gr1,152)
  415| 005EC4 lwz        80820004   1     L4A       gr4=._Py_RefTotal(gr2,0)                                                                                        0| 005F3C lwz        800100A8   1     L4A        gr0=#stack(gr1,168)
  417| 005EC8 lwz        80BF0000   1     L4A       gr5=(*)_object._object.ob_refcnt(gr31,0)                                                                      581| 005F40 addi       382100A0   1     AI         gr1=gr1,160
    0| 005ECC lwz        80620018   1     L4A       gr3=.+CONSTANT_AREA(gr2,0)                                                                                      0| 005F44 mtspr      7C0803A6   1     LLR        lr=gr0
  417| 005ED0 addi       3805FFFF   1     AI        gr0=gr5,-1                                                                                                    581| 005F48 bclr       4E800020   3     BA         lr
  417| 005ED4 stw        901F0000   1     ST4A      (*)_object._object.ob_refcnt(gr31,0)=gr0                                                                      423|                                CL.838:
  408| 005ED8 addi       38631110   1     AI        gr3=gr3,4368                                                                                                  425| 005F4C ori        63C30000   1     LR         gr3=gr30
  415| 005EDC lwz        80A40000   1     L4A       gr5=<s117:d0:l4>(gr4,0)                                                                                         0| 005F50 lwz        83E1009C   1     L4A        gr31=#stack(gr1,156)
  415| 005EE0 addi       38A5FFFF   2     AI        gr5=gr5,-1                                                                                                    425| 005F54 bl         4BFFA0AD   0     CALL       _Py_Dealloc,1,(*)_object",gr3,#ProcAlias",_Py_Dealloc",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",
  415| 005EE4 stw        90A40000   1     ST4A      <s117:d0:l4>(gr4,0)=gr5                                                                                       425| 005F58 ori        60000000   1
  417| 005EE8 cmpwi      2C000000   1     C4        cr0=gr0,0                                                                                                     580| 005F5C addi       38600000   1     LI         gr3=0
  417| 005EEC bc         4182004C   1     BT        CL.1986,cr0,0x4/eq,taken=40%(40,60)                                                                             0| 005F60 lwz        83C10098   1     L4A        gr30=#stack(gr1,152)
    0| 005EF0 lwz        834100B8   1     L4A       gr26=#stack(gr1,184)                                                                                            0| 005F64 lwz        800100A8   1     L4A        gr0=#stack(gr1,168)
    0| 005EF4 bc         4180001C   0     BT        CL.1581,cr0,0x1/lt,taken=40%(40,60)                                                                           581| 005F68 addi       382100A0   1     AI         gr1=gr1,160
  580| 005EF8 addi       38600000   2     LI        gr3=0                                                                                                           0| 005F6C mtspr      7C0803A6   1     LLR        lr=gr0
    0| 005EFC lwz        83E100CC   1     L4A       gr31=#stack(gr1,204)                                                                                          581| 005F70 bclr       4E800020   3     BA         lr
  581| 005F00 addi       382100D0   1     AI        gr1=gr1,208                                                                                                     0|                                CL.2047:
    0| 005F04 lwz        80010008   1     L4A       gr0=#stack(gr1,8)                                                                                             576| 005F74 addi       3860FFFF   1     LI         gr3=-1
    0| 005F08 mtspr      7C0803A6   2     LLR       lr=gr0                                                                                                          0| 005F78 lwz        83E1009C   1     L4A        gr31=#stack(gr1,156)
  581| 005F0C bclr       4E800020   3     BA        lr                                                                                                              0| 005F7C lwz        83C10098   1     L4A        gr30=#stack(gr1,152)
    0|                                CL.1581:                                                                                                                      0| 005F80 lwz        83410088   1     L4A        gr26=#stack(gr1,136)
  420| 005F10 addi       38800243   1     LI        gr4=579                                                                                                         0| 005F84 lwz        800100A8   1     L4A        gr0=#stack(gr1,168)
  420| 005F14 ori        63E50000   1     LR        gr5=gr31                                                                                                      581| 005F88 addi       382100A0   1     AI         gr1=gr1,160
  420| 005F18 bl         4BFFA0E9   0     CALL      _Py_NegativeRefcount,3,(*)Cuchar",gr3,gr4,(*)_object",gr5,#ProcAlias",_Py_NegativeRefcount",fcr",gr1,cr[015     0| 005F8C mtspr      7C0803A6   1     LLR        lr=gr0
  420| 005F1C ori        60000000   1                                                                                                                             581| 005F90 bclr       4E800020   3     BA         lr
  580| 005F20 addi       38600000   1     LI        gr3=0                                                                                                          76|                                CL.824:
    0| 005F24 lwz        83E100CC   1     L4A       gr31=#stack(gr1,204)                                                                                           77| 005F94 ori        63430000   1     LR         gr3=gr26
  581| 005F28 addi       382100D0   1     AI        gr1=gr1,208                                                                                                    77| 005F98 bl         4BFFA069   0     CALL       gr3=PyCallable_Check,1,(*)_object",gr3,#ProcAlias",PyCallable_Check",fcr",gr1,cr[01567]",gr0",gr4"-gr12",f
    0| 005F2C lwz        80010008   1     L4A       gr0=#stack(gr1,8)                                                                                              77| 005F9C ori        60000000   1
    0| 005F30 mtspr      7C0803A6   2     LLR       lr=gr0                                                                                                         77| 005FA0 cmpwi      2C030000   1     C4         cr0=gr3,0
  581| 005F34 bclr       4E800020   3     BA        lr                                                                                                             78| 005FA4 lwz        837C001C   1     L4A        gr27=(*)_typeobject._typeobject.tp_vectorcall_offset(gr28,28)
    0|                                CL.1986:                                                                                                                      0| 005FA8 ori        63600000   2     LR         gr0=gr27
  425| 005F38 ori        63E30000   1     LR        gr3=gr31                                                                                                       77| 005FAC bc         418200F0   0     BT         CL.1713,cr0,0x4/eq,taken=40%(40,60)
    0| 005F3C lwz        834100B8   1     L4A       gr26=#stack(gr1,184)                                                                                           79| 005FB0 cmpwi      2C000000   1     C4         cr0=gr0,0
  425| 005F40 bl         4BFFA0C1   0     CALL      _Py_Dealloc,1,(*)_object",gr3,#ProcAlias",_Py_Dealloc",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",l     0| 005FB4 lwz        83810090   1     L4A        gr28=#stack(gr1,144)
  425| 005F44 ori        60000000   1                                                                                                                              79| 005FB8 bc         408100BC   0     BF         CL.1708,cr0,0x2/gt,taken=40%(40,60)
  580| 005F48 addi       38600000   1     LI        gr3=0                                                                                                           0|                                CL.1709:
    0| 005F4C lwz        83E100CC   1     L4A       gr31=#stack(gr1,204)                                                                                           81| 005FBC lwzx       7CFAD82E   1     L4A        gr7=(*)_object*()*(gr26,gr27,0)
  581| 005F50 addi       382100D0   1     AI        gr1=gr1,208                                                                                                     0| 005FC0 or.        7CE03B79   2     LR_R       gr0,cr0=gr7
    0| 005F54 lwz        80010008   1     L4A       gr0=#stack(gr1,8)                                                                                             114| 005FC4 bc         41820080   1     BT         CL.2050,cr0,0x4/eq,taken=30%(30,70)
    0| 005F58 mtspr      7C0803A6   2     LLR       lr=gr0                                                                                                          0|                                CL.2054:
  581| 005F5C bclr       4E800020   3     BA        lr                                                                                                            118| 005FC8 ori        63430000   1     LR         gr3=gr26







Wed Apr 15 07:30:04 CDT 2020  Page 172


   76|                                CL.824:                                                                                                                     118| 005FCC lwz        80070000   1     L4A        gr0=#fnc_adr(gr7,0)
   77| 005F60 ori        63E30000   1     LR        gr3=gr31                                                                                                      118| 005FD0 lwz        81670008   1     L4A        gr11=#new_env(gr7,8)
   77| 005F64 bl         4BFFA09D   0     CALL      gr3=PyCallable_Check,1,(*)_object",gr3,#ProcAlias",PyCallable_Check",fcr",gr1,cr[01567]",gr0",gr4"-gr12",fp   118| 005FD4 ori        63A50000   1     LR         gr5=gr29
   77| 005F68 ori        60000000   1                                                                                                                               0| 005FD8 lwz        8361008C   1     L4A        gr27=#stack(gr1,140)
   77| 005F6C cmpwi      2C030000   1     C4        cr0=gr3,0                                                                                                     118| 005FDC addi       3881007C   1     AI         gr4=gr1,124
   78| 005F70 lwz        837C001C   1     L4A       gr27=(*)_typeobject._typeobject.tp_vectorcall_offset(gr28,28)                                                 118| 005FE0 addi       38C00000   1     LI         gr6=0
    0| 005F74 ori        63600000   2     LR        gr0=gr27                                                                                                      118| 005FE4 mtspr      7C0903A6   1     LCTR       ctr=gr0
   77| 005F78 bc         41820148   0     BT        CL.1580,cr0,0x4/eq,taken=40%(40,60)                                                                           118| 005FE8 lwz        80470004   1     CALL       gr3=gr7,4,(*)_object",gr3,(*)_object*C",gr4,gr5,(*)_object",gr6,#ProcAlias",(*)_object",fcr",(*)_object*()
   79| 005F7C cmpwi      2C000000   1     C4        cr0=gr0,0                                                                                                     118| 005FEC bcctrl     4E800421   0
    0| 005F80 lwz        838100C0   1     L4A       gr28=#stack(gr1,192)                                                                                          118| 005FF0 lwz        80410014   1
   79| 005F84 bc         40810114   0     BF        CL.1572,cr0,0x2/gt,taken=40%(40,60)                                                                           118| 005FF4 ori        60650000   1     LR         gr5=gr3
    0|                                CL.1573:                                                                                                                    119| 005FF8 ori        63C30000   1     LR         gr3=gr30
   81| 005F88 lwzx       7CFFD82E   1     L4A       gr7=(*)_object*()*(gr31,gr27,0)                                                                               119| 005FFC addi       38C00000   1     LI         gr6=0
    0| 005F8C or.        7CE03B79   2     LR_R      gr0,cr0=gr7                                                                                                   119| 006000 ori        63440000   1     LR         gr4=gr26
  114| 005F90 bc         418200D8   1     BT        CL.1997,cr0,0x4/eq,taken=30%(30,70)                                                                           119| 006004 bl         4BFF9FFD   0     CALL       gr3=_Py_CheckFunctionResult,4,(*)_ts",gr3,(*)_object",gr4,(*)_object",gr5,(*)Cuchar",gr6,#ProcAlias",_Py_C
    0|                                CL.2002:                                                                                                                    119| 006008 ori        60000000   1
  118| 005F94 ori        63E30000   1     LR        gr3=gr31                                                                                                      575| 00600C or.        7C7E1B79   1     LR_R       gr30,cr0=gr3
  118| 005F98 lwz        80070000   1     L4A       gr0=#fnc_adr(gr7,0)                                                                                           575| 006010 bc         41820010   1     BT         CL.1710,cr0,0x4/eq,taken=30%(30,70)
  118| 005F9C lwz        81670008   1     L4A       gr11=#new_env(gr7,8)                                                                                            0| 006014 lwz        83A10094   2     L4A        gr29=#stack(gr1,148)
  118| 005FA0 addi       38BE0001   1     AI        gr5=gr30,1                                                                                                      0| 006018 lwz        83410088   1     L4A        gr26=#stack(gr1,136)
    0| 005FA4 lwz        836100BC   1     L4A       gr27=#stack(gr1,188)                                                                                            0| 00601C b          4BFFFEAC   0     B          CL.575,-1
  118| 005FA8 addi       388100AC   1     AI        gr4=gr1,172                                                                                                     0|                                CL.1710:
  118| 005FAC addi       38C00000   1     LI        gr6=0                                                                                                         576| 006020 addi       3860FFFF   1     LI         gr3=-1
  118| 005FB0 mtspr      7C0903A6   1     LCTR      ctr=gr0                                                                                                         0| 006024 lwz        83E1009C   1     L4A        gr31=#stack(gr1,156)
  118| 005FB4 lwz        80470004   1     CALL      gr3=gr7,4,(*)_object",gr3,(*)_object*C",gr4,gr5,(*)_object",gr6,#ProcAlias",(*)_object",fcr",(*)_object*()"     0| 006028 lwz        83C10098   1     L4A        gr30=#stack(gr1,152)
  118| 005FB8 bcctrl     4E800421   0                                                                                                                               0| 00602C lwz        83A10094   1     L4A        gr29=#stack(gr1,148)
  118| 005FBC lwz        80410014   1                                                                                                                               0| 006030 lwz        83410088   1     L4A        gr26=#stack(gr1,136)
  118| 005FC0 ori        60650000   1     LR        gr5=gr3                                                                                                         0| 006034 lwz        800100A8   1     L4A        gr0=#stack(gr1,168)
  119| 005FC4 ori        63A30000   1     LR        gr3=gr29                                                                                                      581| 006038 addi       382100A0   1     AI         gr1=gr1,160
  119| 005FC8 addi       38C00000   1     LI        gr6=0                                                                                                           0| 00603C mtspr      7C0803A6   1     LLR        lr=gr0
  119| 005FCC ori        63E40000   1     LR        gr4=gr31                                                                                                      581| 006040 bclr       4E800020   3     BA         lr
  119| 005FD0 bl         4BFFA031   0     CALL      gr3=_Py_CheckFunctionResult,4,(*)_ts",gr3,(*)_object",gr4,(*)_object",gr5,(*)Cuchar",gr6,#ProcAlias",_Py_Ch     0|                                CL.2050:
  119| 005FD4 ori        60000000   1                                                                                                                             116| 006044 ori        63C30000   1     LR         gr3=gr30
  574| 005FD8 or.        7C7F1B79   1     LR_R      gr31,cr0=gr3                                                                                                  116| 006048 ori        63440000   1     LR         gr4=gr26
  575| 005FDC bc         41820068   1     BT        CL.1998,cr0,0x4/eq,taken=30%(30,70)                                                                           116| 00604C addi       38A1007C   1     AI         gr5=gr1,124
  578| 005FE0 lwz        807A0000   2     L4A       gr3=<s139:d0:l4>(gr26,0)                                                                                        0| 006050 lwz        83A10094   1     L4A        gr29=#stack(gr1,148)
  578| 005FE4 ori        63E40000   1     LR        gr4=gr31                                                                                                        0| 006054 lwz        8361008C   1     L4A        gr27=#stack(gr1,140)
    0| 005FE8 lwz        83C100C8   1     L4A       gr30=#stack(gr1,200)                                                                                          116| 006058 addi       38C00001   1     LI         gr6=1
    0| 005FEC lwz        83A100C4   1     L4A       gr29=#stack(gr1,196)                                                                                          116| 00605C addi       38E00000   1     LI         gr7=0
  578| 005FF0 bl         4BFFA011   0     CALL      PyErr_SetObject,2,(*)_object",gr3,(*)_object",gr4,#ProcAlias",PyErr_SetObject",fcr",gr1,cr[01567]",gr0",gr3   116| 006060 bl         4BFF9FA1   0     CALL       gr3=_PyObject_MakeTpCall,5,(*)_ts",gr3,(*)_object",gr4,(*)_object*C",gr5,gr6,(*)_object",gr7,#ProcAlias",(
  578| 005FF4 ori        60000000   1                                                                                                                             116| 006064 ori        60000000   1
  415| 005FF8 lwz        80820004   1     L4A       gr4=._Py_RefTotal(gr2,0)                                                                                      575| 006068 or.        7C7E1B79   1     LR_R       gr30,cr0=gr3
  417| 005FFC lwz        80BF0000   1     L4A       gr5=(*)_object._object.ob_refcnt(gr31,0)                                                                      575| 00606C bc         4182FF08   1     BT         CL.2047,cr0,0x4/eq,taken=30%(30,70)
    0| 006000 lwz        80620018   1     L4A       gr3=.+CONSTANT_AREA(gr2,0)                                                                                      0| 006070 b          4BFFFE54   1     B          CL.2055,-1
  417| 006004 addi       3805FFFF   1     AI        gr0=gr5,-1                                                                                                      0|                                CL.1708:
  417| 006008 stw        901F0000   1     ST4A      (*)_object._object.ob_refcnt(gr31,0)=gr0                                                                       79| 006074 addi       38A0004F   1     LI         gr5=79
  408| 00600C addi       38631110   1     AI        gr3=gr3,4368                                                                                                   79| 006078 lwz        80620018   1     L4A        gr3=.+CONSTANT_AREA(gr2,0)
  415| 006010 lwz        80A40000   1     L4A       gr5=<s117:d0:l4>(gr4,0)                                                                                        79| 00607C addi       38831174   2     AI         gr4=gr3,4468
  415| 006014 addi       38A5FFFF   2     AI        gr5=gr5,-1                                                                                                     79| 006080 addi       386311C4   1     AI         gr3=gr3,4548
  415| 006018 stw        90A40000   1     ST4A      <s117:d0:l4>(gr4,0)=gr5                                                                                        79| 006084 bl         4BFF9F7D   0     CALL       __assert,3,gr3-gr5,#ProcAlias",__assert",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",lr",fcr",xer",
  417| 00601C cmpwi      2C000000   1     C4        cr0=gr0,0                                                                                                      79| 006088 ori        60000000   1
  417| 006020 bc         4182FF18   1     BT        CL.1986,cr0,0x4/eq,taken=40%(40,60)                                                                            81| 00608C lwzx       7CFAD82E   1     L4A        gr7=(*)_object*()*(gr26,gr27,0)
    0| 006024 lwz        834100B8   1     L4A       gr26=#stack(gr1,184)                                                                                            0| 006090 or.        7CE03B79   2     LR_R       gr0,cr0=gr7
  419| 006028 bc         4180FEE8   0     BT        CL.1581,cr0,0x1/lt,taken=70%(70,30)                                                                           114| 006094 bc         4182FFB0   1     BT         CL.2050,cr0,0x4/eq,taken=30%(30,70)
  580| 00602C addi       38600000   2     LI        gr3=0                                                                                                           0| 006098 b          4BFFFF30   1     B          CL.2054,-1
    0| 006030 lwz        83E100CC   1     L4A       gr31=#stack(gr1,204)                                                                                            0|                                CL.1713:







Wed Apr 15 07:30:04 CDT 2020  Page 173


  581| 006034 addi       382100D0   1     AI        gr1=gr1,208                                                                                                    77| 00609C addi       38A0004D   1     LI         gr5=77
    0| 006038 lwz        80010008   1     L4A       gr0=#stack(gr1,8)                                                                                              77| 0060A0 lwz        80620018   1     L4A        gr3=.+CONSTANT_AREA(gr2,0)
    0| 00603C mtspr      7C0803A6   2     LLR       lr=gr0                                                                                                         77| 0060A4 addi       38831174   2     AI         gr4=gr3,4468
  581| 006040 bclr       4E800020   3     BA        lr                                                                                                             77| 0060A8 addi       386311A8   1     AI         gr3=gr3,4520
    0|                                CL.1998:                                                                                                                     77| 0060AC bl         4BFF9F55   0     CALL       __assert,3,gr3-gr5,#ProcAlias",__assert",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",lr",fcr",xer",
  576| 006044 addi       3860FFFF   1     LI        gr3=-1                                                                                                         77| 0060B0 ori        60000000   1
    0| 006048 lwz        83E100CC   1     L4A       gr31=#stack(gr1,204)                                                                                           78| 0060B4 lwz        837C001C   1     L4A        gr27=(*)_typeobject._typeobject.tp_vectorcall_offset(gr28,28)
    0| 00604C lwz        83C100C8   1     L4A       gr30=#stack(gr1,200)                                                                                            0| 0060B8 or.        7F60DB79   2     LR_R       gr0,cr0=gr27
    0| 006050 lwz        83A100C4   1     L4A       gr29=#stack(gr1,196)                                                                                           79| 0060BC bc         4081000C   1     BF         CL.2049,cr0,0x2/gt,taken=40%(40,60)
    0| 006054 lwz        834100B8   1     L4A       gr26=#stack(gr1,184)                                                                                            0| 0060C0 lwz        83810090   1     L4A        gr28=#stack(gr1,144)
  581| 006058 addi       382100D0   1     AI        gr1=gr1,208                                                                                                     0| 0060C4 b          4BFFFEF8   0     B          CL.1709,-1
    0| 00605C lwz        80010008   1     L4A       gr0=#stack(gr1,8)                                                                                               0|                                CL.2049:
    0| 006060 mtspr      7C0803A6   2     LLR       lr=gr0                                                                                                         79| 0060C8 addi       38A0004F   1     LI         gr5=79
  581| 006064 bclr       4E800020   3     BA        lr                                                                                                             79| 0060CC lwz        80620018   1     L4A        gr3=.+CONSTANT_AREA(gr2,0)
    0|                                CL.1997:                                                                                                                      0| 0060D0 lwz        83810090   1     L4A        gr28=#stack(gr1,144)
  116| 006068 ori        63A30000   1     LR        gr3=gr29                                                                                                       79| 0060D4 addi       38831174   1     AI         gr4=gr3,4468
  116| 00606C ori        63E40000   1     LR        gr4=gr31                                                                                                       79| 0060D8 addi       386311C4   1     AI         gr3=gr3,4548
  116| 006070 addi       38A100AC   1     AI        gr5=gr1,172                                                                                                    79| 0060DC bl         4BFF9F25   0     CALL       __assert,3,gr3-gr5,#ProcAlias",__assert",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",lr",fcr",xer",
    0| 006074 lwz        83C100C8   1     L4A       gr30=#stack(gr1,200)                                                                                           79| 0060E0 ori        60000000   1
    0| 006078 lwz        836100BC   1     L4A       gr27=#stack(gr1,188)                                                                                           81| 0060E4 lwzx       7CFAD82E   1     L4A        gr7=(*)_object*()*(gr26,gr27,0)
  116| 00607C addi       38C00001   1     LI        gr6=1                                                                                                           0| 0060E8 or.        7CE03B79   2     LR_R       gr0,cr0=gr7
  116| 006080 addi       38E00000   1     LI        gr7=0                                                                                                         114| 0060EC bc         4182FF58   1     BT         CL.2050,cr0,0x4/eq,taken=30%(30,70)
  116| 006084 bl         4BFF9F7D   0     CALL      gr3=_PyObject_MakeTpCall,5,(*)_ts",gr3,(*)_object",gr4,(*)_object*C",gr5,gr6,(*)_object",gr7,#ProcAlias",(*     0| 0060F0 b          4BFFFED8   1     B          CL.2054,-1
  116| 006088 ori        60000000   1                                                                                                                               0|                                CL.1701:
  575| 00608C cmpwi      2C030000   1     C4        cr0=gr3,0                                                                                                      72| 0060F4 addi       38A00048   1     LI         gr5=72
  575| 006090 bc         4082FE1C   1     BF        CL.1991,cr0,0x4/eq,taken=40%(40,60)                                                                            72| 0060F8 lwz        80620018   1     L4A        gr3=.+CONSTANT_AREA(gr2,0)
    0| 006094 b          4BFFFDF8   1     B         CL.2004,-1                                                                                                     72| 0060FC addi       38831174   2     AI         gr4=gr3,4468
    0|                                CL.1572:                                                                                                                     72| 006100 addi       38631194   1     AI         gr3=gr3,4500
   79| 006098 addi       38A0004F   1     LI        gr5=79                                                                                                         72| 006104 bl         4BFF9EFD   0     CALL       __assert,3,gr3-gr5,#ProcAlias",__assert",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",lr",fcr",xer",
   79| 00609C lwz        80620018   1     L4A       gr3=.+CONSTANT_AREA(gr2,0)                                                                                     72| 006108 ori        60000000   1
   79| 0060A0 addi       38831174   2     AI        gr4=gr3,4468                                                                                                   73| 00610C lwz        839A0004   1     L4A        gr28=(*)_object._object.ob_type(gr26,4)
   79| 0060A4 addi       386311C4   1     AI        gr3=gr3,4548                                                                                                  617| 006110 ori        63830000   2     LR         gr3=gr28
   79| 0060A8 bl         4BFF9F59   0     CALL      __assert,3,gr3-gr5,#ProcAlias",__assert",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",lr",fcr",xer",f   617| 006114 bl         4BFF9EED   0     CALL       gr3=PyType_GetFlags,1,(*)_typeobject",gr3,#ProcAlias",PyType_GetFlags",fcr",gr1,cr[01567]",gr0",gr4"-gr12"
   79| 0060AC ori        60000000   1                                                                                                                             617| 006118 ori        60000000   1
   81| 0060B0 lwzx       7CFFD82E   1     L4A       gr7=(*)_object*()*(gr31,gr27,0)                                                                                74| 00611C andi.      70600800   1     RN4_R      gr0,cr0=gr3,0,0x800
    0| 0060B4 or.        7CE03B79   2     LR_R      gr0,cr0=gr7                                                                                                    74| 006120 bc         4082FE74   1     BF         CL.824,cr0,0x4/eq,taken=50%(0,0)
  114| 0060B8 bc         4182FFB0   1     BT        CL.1997,cr0,0x4/eq,taken=30%(30,70)                                                                             0| 006124 b          4BFFFD74   1     B          CL.2056,-1
    0| 0060BC b          4BFFFED8   1     B         CL.2002,-1                                                                                                      0|                                CL.2046:
    0|                                CL.1580:                                                                                                                      0| 006128 lwz        83E1009C   1     L4A        gr31=#stack(gr1,156)
   77| 0060C0 addi       38A0004D   1     LI        gr5=77                                                                                                        559|                                CL.573:
   77| 0060C4 lwz        80620018   1     L4A       gr3=.+CONSTANT_AREA(gr2,0)                                                                                    562| 00612C lwz        8062002C   1     L4A        gr3=.PyExc_StopIteration(gr2,0)
   77| 0060C8 addi       38831174   2     AI        gr4=gr3,4468                                                                                                  562| 006130 ori        63C40000   1     LR         gr4=gr30
   77| 0060CC addi       386311A8   1     AI        gr3=gr3,4520                                                                                                  562| 006134 lwz        80630000   1     L4A        gr3=PyExc_StopIteration(gr3,0)
   77| 0060D0 bl         4BFF9F31   0     CALL      __assert,3,gr3-gr5,#ProcAlias",__assert",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",lr",fcr",xer",f   562| 006138 bl         4BFF9EC9   0     CALL       PyErr_SetObject,2,(*)_object",gr3,(*)_object",gr4,#ProcAlias",PyErr_SetObject",fcr",gr1,cr[01567]",gr0",gr
   77| 0060D4 ori        60000000   1                                                                                                                             562| 00613C ori        60000000   1
   78| 0060D8 lwz        837C001C   1     L4A       gr27=(*)_typeobject._typeobject.tp_vectorcall_offset(gr28,28)                                                 563| 006140 addi       38600000   1     LI         gr3=0
    0| 0060DC or.        7F60DB79   2     LR_R      gr0,cr0=gr27                                                                                                    0| 006144 lwz        83C10098   1     L4A        gr30=#stack(gr1,152)
   79| 0060E0 bc         4081000C   1     BF        CL.1996,cr0,0x2/gt,taken=40%(40,60)                                                                             0| 006148 lwz        800100A8   1     L4A        gr0=#stack(gr1,168)
    0| 0060E4 lwz        838100C0   1     L4A       gr28=#stack(gr1,192)                                                                                          581| 00614C addi       382100A0   1     AI         gr1=gr1,160
    0| 0060E8 b          4BFFFEA0   0     B         CL.1573,-1                                                                                                      0| 006150 mtspr      7C0803A6   1     LLR        lr=gr0
    0|                                CL.1996:                                                                                                                    581| 006154 bclr       4E800020   3     BA         lr
   79| 0060EC addi       38A0004F   1     LI        gr5=79                                                                                                          0|                                CL.1700:
   79| 0060F0 lwz        80620018   1     L4A       gr3=.+CONSTANT_AREA(gr2,0)                                                                                    574| 006158 lwz        835F0000   1     L4A        gr26=PyExc_StopIteration(gr31,0)
    0| 0060F4 lwz        838100C0   1     L4A       gr28=#stack(gr1,192)                                                                                          185| 00615C stw        93C1007C   1     ST4A       _args(gr1,124)=gr30
   79| 0060F8 addi       38831174   1     AI        gr4=gr3,4468                                                                                                  186| 006160 bl         4BFF9EA1   0     CALL       gr3=PyThreadState_Get,0,#ProcAlias",PyThreadState_Get",fcr",gr1,cr[01567]",gr0",gr4"-gr12",fp0"-fp13",mq",
   79| 0060FC addi       386311C4   1     AI        gr3=gr3,4548                                                                                                  186| 006164 ori        60000000   1







Wed Apr 15 07:30:04 CDT 2020  Page 174


   79| 006100 bl         4BFF9F01   0     CALL      __assert,3,gr3-gr5,#ProcAlias",__assert",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",lr",fcr",xer",f   188| 006168 ori        607E0000   1     LR         gr30=gr3
   79| 006104 ori        60000000   1                                                                                                                             187| 00616C addis      3C608000   1     LIU        gr3=32768
   81| 006108 lwzx       7CFFD82E   1     L4A       gr7=(*)_object*()*(gr31,gr27,0)                                                                                72| 006170 cmpwi      2C1A0000   1     C4         cr0=gr26,0
    0| 00610C or.        7CE03B79   2     LR_R      gr0,cr0=gr7                                                                                                   187| 006174 addi       3BA30001   1     AI         gr29=gr3,1
  114| 006110 bc         4182FF58   1     BT        CL.1997,cr0,0x4/eq,taken=30%(30,70)                                                                            72| 006178 bc         4182FF7C   0     BT         CL.1701,cr0,0x4/eq,taken=30%(30,70)
    0| 006114 b          4BFFFE80   1     B         CL.2002,-1                                                                                                      0| 00617C b          4BFFFD04   1     B          CL.1703,-1
    0|                                CL.1994:                                                                                                                       |               Tag Table
   72| 006118 addi       38A00048   1     LI        gr5=72                                                                                                           | 006180        00000000 00002041 80060100 00000000 00000380 001C5F50
   72| 00611C lwz        80620018   1     L4A       gr3=.+CONSTANT_AREA(gr2,0)                                                                                       | 006198        7947656E 5F536574 53746F70 49746572 6174696F 6E56616C
   72| 006120 addi       38831174   2     AI        gr4=gr3,4468                                                                                                     | 0061B0        7565
   72| 006124 addi       38631194   1     AI        gr3=gr3,4500                                                                                                     |               Instruction count          224
   72| 006128 bl         4BFF9ED9   0     CALL      __assert,3,gr3-gr5,#ProcAlias",__assert",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",lr",fcr",xer",f      |               Straight-line exec time    225
   72| 00612C ori        60000000   1                                                                                                                            GPR's set/used:   suus ssss ssss s---  ---- ---- ---- ----
   73| 006130 lwz        839F0004   1     L4A       gr28=(*)_object._object.ob_type(gr31,4)                                                                      FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----
  617| 006134 ori        63830000   2     LR        gr3=gr28                                                                                                     CCR's set/used:   ss-- -sss
  617| 006138 bl         4BFF9EC9   0     CALL      gr3=PyType_GetFlags,1,(*)_typeobject",gr3,#ProcAlias",PyType_GetFlags",fcr",gr1,cr[01567]",gr0",gr4"-gr12",      | 000000                             PDEF       PyGen_NewWithQualName
  617| 00613C ori        60000000   1                                                                                                                             812|                                    PROC       f,name,qualname,gr3-gr5
   74| 006140 andi.      70600800   1     RN4_R     gr0,cr0=gr3,0,0x800                                                                                           814| 0061C0 ori        60A60000   1     LR         gr6=gr5
   74| 006144 bc         4082FE1C   1     BF        CL.824,cr0,0x4/eq,taken=40%(40,60)                                                                            814| 0061C4 ori        60850000   1     LR         gr5=gr4
    0| 006148 b          4BFFFD18   1     B         CL.2005,-1                                                                                                    814| 0061C8 ori        60640000   1     LR         gr4=gr3
    0|                                CL.1579:                                                                                                                    814| 0061CC lwz        806200D4   1     L4A        gr3=.PyGen_Type(gr2,0)
  559| 00614C lwz        807F0004   1     L4A       gr3=(*)_object._object.ob_type(gr31,4)                                                                        815| 0061D0 b          4BFFBEF0   0     CALLF      gr3=gen_new_with_qualname,4,(*)_typeobject",gr3,(*)_frame",gr4,(*)_object",gr5,(*)_object",gr6,#ProcAlias"
  617| 006150 bl         4BFF9EB1   0     CALL      gr3=PyType_GetFlags,1,(*)_typeobject",gr3,#ProcAlias",PyType_GetFlags",fcr",gr1,cr[01567]",gr0",gr4"-gr12",   815|                                CL.687:
  617| 006154 ori        60000000   1                                                                                                                                |               Tag Table
  559| 006158 andis.     74604000   1     RN4_R     gr0,cr0=gr3,0,0x40000000                                                                                         | 0061D4        00000000 00002040 00000300 00000000 00000014 00155079
  559| 00615C bc         4082FCC8   1     BF        CL.574,cr0,0x4/eq,taken=70%(70,30)                                                                               | 0061EC        47656E5F 4E657757 69746851 75616C4E 616D65
    0|                                CL.1993:                                                                                                                       |               Instruction count            5
  562| 006160 lwz        8062002C   1     L4A       gr3=.PyExc_StopIteration(gr2,0)                                                                                  |               Straight-line exec time      4
  562| 006164 ori        63E40000   1     LR        gr4=gr31                                                                                                     GPR's set/used:   suus ssss ssss s---  ---- ---- ---- ----
  562| 006168 lwz        80630000   1     L4A       gr3=<s139:d0:l4>(gr3,0)                                                                                      FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----
  562| 00616C bl         4BFF9E95   0     CALL      PyErr_SetObject,2,(*)_object",gr3,(*)_object",gr4,#ProcAlias",PyErr_SetObject",fcr",gr1,cr[01567]",gr0",gr3  CCR's set/used:   ss-- -sss
  562| 006170 ori        60000000   1                                                                                                                                | 000000                             PDEF       PyGen_New
  563| 006174 addi       38600000   1     LI        gr3=0                                                                                                         818|                                    PROC       f,gr3
    0| 006178 lwz        83E100CC   1     L4A       gr31=#stack(gr1,204)                                                                                          820| 006200 ori        60640000   1     LR         gr4=gr3
  581| 00617C addi       382100D0   1     AI        gr1=gr1,208                                                                                                   820| 006204 lwz        806200D4   1     L4A        gr3=.PyGen_Type(gr2,0)
    0| 006180 lwz        80010008   1     L4A       gr0=#stack(gr1,8)                                                                                             820| 006208 addi       38A00000   1     LI         gr5=0
    0| 006184 mtspr      7C0803A6   2     LLR       lr=gr0                                                                                                        820| 00620C addi       38C00000   1     LI         gr6=0
  581| 006188 bclr       4E800020   3     BA        lr                                                                                                            821| 006210 b          4BFFBEB0   0     CALLF      gr3=gen_new_with_qualname,4,(*)_typeobject",gr3,(*)_frame",gr4,(*)_object",gr5,(*)_object",gr6,#ProcAlias"
     |               Tag Table                                                                                                                                    821|                                CL.688:
     | 00618C        00000000 00002041 80060100 00000000 000003AC 001C5F50                                                                                           |               Tag Table
     | 0061A4        7947656E 5F536574 53746F70 49746572 6174696F 6E56616C                                                                                           | 006214        00000000 00002040 00000100 00000000 00000014 00095079
     | 0061BC        7565                                                                                                                                            | 00622C        47656E5F 4E6577
     |               Instruction count          235                                                                                                                  |               Instruction count            5
     |               Straight-line exec time    248                                                                                                                  |               Straight-line exec time      4
 GPR's set/used:   suus ssss ssss s---  ---- ---- ---- ----                                                                                                      GPR's set/used:   ssus ssss ssss s---  ---- ---- ---- --ss
 FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----                                                                                                      FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----
 CCR's set/used:   ss-- -sss                                                                                                                                     CCR's set/used:   ss-- -sss
     | 000000                             PDEF     PyGen_NewWithQualName                                                                                             | 000000                             PDEF       async_gen_unwrap_value at AF121_15
  812|                                    PROC      f,name,qualname,gr3-gr5                                                                                      1462|                                    PROC       gen,result,gr3,gr4
  814| 0061C0 ori        60A60000   1     LR        gr6=gr5                                                                                                         0| 006240 mfspr      7C0802A6   1     LFLR       gr0=lr
  814| 0061C4 ori        60850000   1     LR        gr5=gr4                                                                                                         0| 006244 stwu       9421FFC0   1     ST4U       gr1,#stack(gr1,-64)=gr1
  814| 0061C8 ori        60640000   1     LR        gr4=gr3                                                                                                         0| 006248 stw        90010048   1     ST4A       #stack(gr1,72)=gr0
  814| 0061CC lwz        806200D4   1     L4A       gr3=.PyGen_Type(gr2,0)                                                                                          0| 00624C stw        93E1003C   1     ST4A       #stack(gr1,60)=gr31
  815| 0061D0 b          4BFFC0D0   0     CALLF     gr3=gen_new_with_qualname,4,(*)_typeobject",gr3,(*)_frame",gr4,(*)_object",gr5,(*)_object",gr6,#ProcAlias",     0| 006250 ori        607F0000   1     LR         gr31=gr3
  815|                                CL.687:                                                                                                                       0| 006254 stw        93C10038   1     ST4A       #stack(gr1,56)=gr30
     |               Tag Table                                                                                                                                      0| 006258 ori        609E0000   1     LR         gr30=gr4







Wed Apr 15 07:30:04 CDT 2020  Page 175


     | 0061D4        00000000 00002040 00000300 00000000 00000014 00155079                                                                                       1481| 00625C lwz        80640008   1     L4A        gr3=(*)aggr#C.agw_val(gr4,8)
     | 0061EC        47656E5F 4E657757 69746851 75616C4E 616D65                                                                                                  1481| 006260 bl         4BFFFBA1   0     CALL       gr3=_PyGen_SetStopIterationValue,1,(*)_object",gr3,#ProcAlias",_PyGen_SetStopIterationValue",fcr",gr1,cr[0
     |               Instruction count            5                                                                                                               415| 006264 lwz        80820004   1     L4A        gr4=._Py_RefTotal(gr2,0)
     |               Straight-line exec time      4                                                                                                                 0| 006268 lwz        80620018   1     L4A        gr3=.+CONSTANT_AREA(gr2,0)
 GPR's set/used:   suus ssss ssss s---  ---- ---- ---- ----                                                                                                       417| 00626C lwz        80BE0000   1     L4A        gr5=(*)_object._object.ob_refcnt(gr30,0)
 FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----                                                                                                       408| 006270 addi       38631110   1     AI         gr3=gr3,4368
 CCR's set/used:   ss-- -sss                                                                                                                                      417| 006274 addi       3805FFFF   1     AI         gr0=gr5,-1
     | 000000                             PDEF     PyGen_New                                                                                                      417| 006278 stw        901E0000   1     ST4A       (*)_object._object.ob_refcnt(gr30,0)=gr0
  818|                                    PROC      f,gr3                                                                                                         415| 00627C lwz        80A40000   1     L4A        gr5=_Py_RefTotal(gr4,0)
  820| 006200 ori        60640000   1     LR        gr4=gr3                                                                                                       415| 006280 addi       38C5FFFF   2     AI         gr6=gr5,-1
  820| 006204 lwz        806200D4   1     L4A       gr3=.PyGen_Type(gr2,0)                                                                                        415| 006284 stw        90C40000   1     ST4A       _Py_RefTotal(gr4,0)=gr6
  820| 006208 addi       38A00000   1     LI        gr5=0                                                                                                         417| 006288 cmpwi      2C000000   1     C4         cr0=gr0,0
  820| 00620C addi       38C00000   1     LI        gr6=0                                                                                                         417| 00628C bc         41820044   1     BT         CL.1454,cr0,0x4/eq,taken=40%(40,60)
  821| 006210 b          4BFFC090   0     CALLF     gr3=gen_new_with_qualname,4,(*)_typeobject",gr3,(*)_frame",gr4,(*)_object",gr5,(*)_object",gr6,#ProcAlias",     0| 006290 lwz        80010048   1     L4A        gr0=#stack(gr1,72)
  821|                                CL.688:                                                                                                                       0| 006294 mtspr      7C0803A6   2     LLR        lr=gr0
     |               Tag Table                                                                                                                                    419| 006298 bc         40800068   0     BF         CL.2324,cr0,0x1/lt,taken=60%(60,40)
     | 006214        00000000 00002040 00000100 00000000 00000014 00095079                                                                                        420| 00629C addi       388005CA   1     LI         gr4=1482
     | 00622C        47656E5F 4E6577                                                                                                                              420| 0062A0 ori        63C50000   1     LR         gr5=gr30
     |               Instruction count            5                                                                                                               420| 0062A4 bl         4BFF9D5D   0     CALL       _Py_NegativeRefcount,3,(*)Cuchar",gr3,gr4,(*)_object",gr5,#ProcAlias",_Py_NegativeRefcount",fcr",gr1,cr[01
     |               Straight-line exec time      4                                                                                                               420| 0062A8 ori        60000000   1
 GPR's set/used:   ssus ssss ssss s---  ---- ---- ---- --ss                                                                                                      1483| 0062AC addi       38000000   1     LI         gr0=0
 FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----                                                                                                      1483| 0062B0 addi       38600000   1     LI         gr3=0
 CCR's set/used:   ss-- -sss                                                                                                                                        0| 0062B4 lwz        83C10038   1     L4A        gr30=#stack(gr1,56)
     | 000000                             PDEF     _PyGen_yf at AF121_93                                                                                            1483| 0062B8 stw        901F003C   1     ST4A       (*)aggr#4.ag_running_async(gr31,60)=gr0
  332|                                    PROC      gen,yf,f,gr3-gr5                                                                                                0| 0062BC lwz        80010048   1     L4A        gr0=#stack(gr1,72)
    0| 006240 mfspr      7C0802A6   1     LFLR      gr0=lr                                                                                                          0| 0062C0 lwz        83E1003C   1     L4A        gr31=#stack(gr1,60)
  338| 006244 lwz        80650010   1     L4A       gr3=(*)_frame._frame.f_code(gr5,16)                                                                          1488| 0062C4 addi       38210040   1     AI         gr1=gr1,64
    0| 006248 stw        90010008   1     ST4A      #stack(gr1,8)=gr0                                                                                               0| 0062C8 mtspr      7C0803A6   1     LLR        lr=gr0
    0| 00624C stw        93E1FFFC   1     ST4A      #stack(gr1,-4)=gr31                                                                                          1488| 0062CC bclr       4E800020   3     BA         lr
    0| 006250 ori        60BF0000   1     LR        gr31=gr5                                                                                                      423|                                CL.1454:
    0| 006254 stw        93C1FFF8   1     ST4A      #stack(gr1,-8)=gr30                                                                                           425| 0062D0 ori        63C30000   1     LR         gr3=gr30
  338| 006258 lwz        83C30024   1     L4A       gr30=(*)aggr#5.co_code(gr3,36)                                                                                425| 0062D4 bl         4BFF9D2D   0     CALL       _Py_Dealloc,1,(*)_object",gr3,#ProcAlias",_Py_Dealloc",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",
    0| 00625C stwu       9421FFC0   1     ST4U      gr1,#stack(gr1,-64)=gr1                                                                                       425| 0062D8 ori        60000000   1
  339| 006260 lwz        807E0004   1     L4A       gr3=(*)_object._object.ob_type(gr30,4)                                                                       1483| 0062DC addi       38600000   1     LI         gr3=0
  617| 006264 bl         4BFF9D9D   0     CALL      gr3=PyType_GetFlags,1,(*)_typeobject",gr3,#ProcAlias",PyType_GetFlags",fcr",gr1,cr[01567]",gr0",gr4"-gr12",     0| 0062E0 lwz        83C10038   1     L4A        gr30=#stack(gr1,56)
  617| 006268 ori        60000000   1                                                                                                                               0| 0062E4 lwz        80010048   1     L4A        gr0=#stack(gr1,72)
  339| 00626C addi       389E0010   1     AI        gr4=gr30,16                                                                                                     0| 0062E8 mtspr      7C0803A6   2     LLR        lr=gr0
  341| 006270 lwz        80BF0034   1     L4A       gr5=(*)_frame._frame.f_lasti(gr31,52)                                                                        1483| 0062EC addi       38000000   1     LI         gr0=0
  339| 006274 andis.     74600800   1     RN4_R     gr0,cr0=gr3,0,0x8000000                                                                                      1483| 0062F0 stw        901F003C   1     ST4A       (*)aggr#4.ag_running_async(gr31,60)=gr0
  341| 006278 cmpwi      2C850000   1     C4        cr1=gr5,0                                                                                                       0| 0062F4 lwz        83E1003C   1     L4A        gr31=#stack(gr1,60)
  339| 00627C bc         418200B4   0     BT        CL.1552,cr0,0x4/eq,taken=40%(40,60)                                                                          1488| 0062F8 addi       38210040   1     AI         gr1=gr1,64
    0| 006280 lwz        80010048   2     L4A       gr0=#stack(gr1,72)                                                                                           1488| 0062FC bclr       4E800020   0     BA         lr
    0| 006284 mtspr      7C0803A6   2     LLR       lr=gr0                                                                                                          0|                                CL.2324:
  341| 006288 bc         41840058   0     BT        CL.2030,cr1,0x1/lt,taken=40%(40,60)                                                                          1483| 006300 addi       38000000   1     LI         gr0=0
    0| 00628C lwz        83C10038   1     L4A       gr30=#stack(gr1,56)                                                                                          1483| 006304 addi       38600000   1     LI         gr3=0
  347|                                CL.553:                                                                                                                       0| 006308 lwz        83C10038   1     L4A        gr30=#stack(gr1,56)
  349| 006290 addi       38650002   1     AI        gr3=gr5,2                                                                                                    1483| 00630C stw        901F003C   1     ST4A       (*)aggr#4.ag_running_async(gr31,60)=gr0
  349| 006294 lbzx       7C0418AE   1     L1Z       gr0=(*)uchar(gr4,gr3,0)                                                                                         0| 006310 lwz        83E1003C   1     L4A        gr31=#stack(gr1,60)
  401| 006298 lwz        80820004   1     L4A       gr4=._Py_RefTotal(gr2,0)                                                                                     1488| 006314 addi       38210040   1     AI         gr1=gr1,64
  349| 00629C cmpwi      2C000048   1     C4        cr0=gr0,72                                                                                                   1488| 006318 bclr       4E800020   0     BA         lr
  401| 0062A0 lwz        80640000   1     L4A       gr3=<s117:d0:l4>(gr4,0)                                                                                          |               Tag Table
  349| 0062A4 bc         4082002C   0     BF        CL.2029,cr0,0x4/eq,taken=50%(0,0)                                                                                | 00631C        00000000 00002041 80020200 00000000 000000DC 001F6173
  351| 0062A8 lwz        80BF0024   2     L4A       gr5=(*)_frame._frame.f_stacktop(gr31,36)                                                                         | 006334        796E635F 67656E5F 756E7772 61705F76 616C7565 40414631
    0| 0062AC lwz        83E1003C   1     L4A       gr31=#stack(gr1,60)                                                                                              | 00634C        32315F31 35
  356| 0062B0 addi       38210040   1     AI        gr1=gr1,64                                                                                                       |               Instruction count           55
  401| 0062B4 addi       38030001   1     AI        gr0=gr3,1                                                                                                        |               Straight-line exec time     54







Wed Apr 15 07:30:04 CDT 2020  Page 176


  401| 0062B8 stw        90040000   1     ST4A      <s117:d0:l4>(gr4,0)=gr0                                                                                      GPR's set/used:   ssus ssss ssss s---  ---- ---- ---- --ss
  351| 0062BC lwz        8065FFFC   1     L4A       gr3=(*)_object*(gr5,-4)                                                                                      FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----
  403| 0062C0 lwz        80830000   2     L4A       gr4=(*)_object._object.ob_refcnt(gr3,0)                                                                      CCR's set/used:   ss-- -sss
  403| 0062C4 addi       38040001   2     AI        gr0=gr4,1                                                                                                        | 000000                             PDEF       async_gen_unwrap_value at AF122_15
  403| 0062C8 stw        90030000   1     ST4A      (*)_object._object.ob_refcnt(gr3,0)=gr0                                                                      1462|                                    PROC       gen_121_15,result_121_15,gr3,gr4
  356| 0062CC bclr       4E800020   0     BA        lr                                                                                                              0| 006360 mfspr      7C0802A6   1     LFLR       gr0=lr
    0|                                CL.2029:                                                                                                                      0| 006364 stwu       9421FFC0   1     ST4U       gr1,#stack(gr1,-64)=gr1
  346| 0062D0 addi       38600000   1     LI        gr3=0                                                                                                           0| 006368 stw        90010048   1     ST4A       #stack(gr1,72)=gr0
    0| 0062D4 lwz        83E1003C   1     L4A       gr31=#stack(gr1,60)                                                                                             0| 00636C stw        93E1003C   1     ST4A       #stack(gr1,60)=gr31
  356| 0062D8 addi       38210040   1     AI        gr1=gr1,64                                                                                                      0| 006370 stw        93C10038   1     ST4A       #stack(gr1,56)=gr30
  356| 0062DC bclr       4E800020   0     BA        lr                                                                                                              0| 006374 ori        607E0000   1     LR         gr30=gr3
    0|                                CL.2030:                                                                                                                   1465| 006378 bl         4BFF9C89   0     CALL       gr3=PyErr_Occurred,0,#ProcAlias",PyErr_Occurred",fcr",gr1,cr[01567]",gr0",gr4"-gr12",fp0"-fp13",mq",lr",fc
    0| 0062E0 lwz        83E1003C   1     L4A       gr31=#stack(gr1,60)                                                                                          1465| 00637C ori        60000000   1
    0|                                CL.1549:                                                                                                                   1465| 006380 cmpwi      2C030000   1     C4         cr0=gr3,0
  345| 0062E4 addi       38A00159   1     LI        gr5=345                                                                                                         0| 006384 lwz        83E20024   1     L4A        gr31=.PyExc_StopAsyncIteration(gr2,0)
  345| 0062E8 lbz        881E0010   1     L1Z       gr0=(*)uchar(gr30,16)                                                                                        1465| 006388 bc         41820098   0     BT         CL.1775,cr0,0x4/eq,taken=50%(0,0)
  345| 0062EC lwz        80820018   1     L4A       gr4=.+CONSTANT_AREA(gr2,0)                                                                                   1469| 00638C lwz        807F0000   2     L4A        gr3=PyExc_StopAsyncIteration(gr31,0)
  345| 0062F0 cmpwi      2C000048   1     C4        cr0=gr0,72                                                                                                   1469| 006390 bl         4BFF9C71   0     CALL       gr3=PyErr_ExceptionMatches,1,(*)_object",gr3,#ProcAlias",PyErr_ExceptionMatches",fcr",gr1,cr[01567]",gr0",
  345| 0062F4 addi       38641150   1     AI        gr3=gr4,4432                                                                                                 1469| 006394 ori        60000000   1
  345| 0062F8 bc         40820028   0     BF        CL.2032,cr0,0x4/eq,taken=30%(30,70)                                                                          1469| 006398 cmpwi      2C030000   1     C4         cr0=gr3,0
  345| 0062FC addi       38841110   2     AI        gr4=gr4,4368                                                                                                 1469| 00639C bc         40820068   1     BF         CL.2325,cr0,0x4/eq,taken=30%(30,70)
    0| 006300 lwz        83C10038   1     L4A       gr30=#stack(gr1,56)                                                                                             0|                                CL.2327:
  345| 006304 bl         4BFF9CFD   0     CALL      __assert,3,gr3-gr5,#ProcAlias",__assert",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",lr",fcr",xer",f  1470| 0063A0 lwz        80620028   1     L4A        gr3=.PyExc_GeneratorExit(gr2,0)
  345| 006308 ori        60000000   1                                                                                                                               0| 0063A4 lwz        83E1003C   1     L4A        gr31=#stack(gr1,60)
  346| 00630C addi       38600000   1     LI        gr3=0                                                                                                        1470| 0063A8 lwz        80630000   1     L4A        gr3=PyExc_GeneratorExit(gr3,0)
    0| 006310 lwz        80010048   1     L4A       gr0=#stack(gr1,72)                                                                                           1470| 0063AC bl         4BFF9C55   0     CALL       gr3=PyErr_ExceptionMatches,1,(*)_object",gr3,#ProcAlias",PyErr_ExceptionMatches",fcr",gr1,cr[01567]",gr0",
  356| 006314 addi       38210040   1     AI        gr1=gr1,64                                                                                                   1470| 0063B0 ori        60000000   1
    0| 006318 mtspr      7C0803A6   1     LLR       lr=gr0                                                                                                       1475| 0063B4 addi       38000000   1     LI         gr0=0
  356| 00631C bclr       4E800020   3     BA        lr                                                                                                           1470| 0063B8 cmpwi      2C030000   1     C4         cr0=gr3,0
    0|                                CL.2032:                                                                                                                   1475| 0063BC addi       38600000   1     LI         gr3=0
  346| 006320 addi       38600000   1     LI        gr3=0                                                                                                        1470| 0063C0 bc         4082001C   0     BF         CL.1513,cr0,0x4/eq,taken=50%(0,0)
    0| 006324 lwz        83C10038   1     L4A       gr30=#stack(gr1,56)                                                                                          1475| 0063C4 stw        901E003C   2     ST4A       (*)aggr#4.ag_running_async(gr30,60)=gr0
  356| 006328 addi       38210040   1     AI        gr1=gr1,64                                                                                                      0| 0063C8 lwz        83C10038   1     L4A        gr30=#stack(gr1,56)
  356| 00632C bclr       4E800020   0     BA        lr                                                                                                              0| 0063CC lwz        80010048   1     L4A        gr0=#stack(gr1,72)
    0|                                CL.1552:                                                                                                                   1488| 0063D0 addi       38210040   1     AI         gr1=gr1,64
  339| 006330 addi       38A00153   1     LI        gr5=339                                                                                                         0| 0063D4 mtspr      7C0803A6   1     LLR        lr=gr0
  339| 006334 lwz        80620018   1     L4A       gr3=.+CONSTANT_AREA(gr2,0)                                                                                   1488| 0063D8 bclr       4E800020   3     BA         lr
  339| 006338 addi       38831110   2     AI        gr4=gr3,4368                                                                                                 1470|                                CL.1513:
  339| 00633C addi       38631138   1     AI        gr3=gr3,4408                                                                                                 1472| 0063DC addi       38000001   1     LI         gr0=1
  339| 006340 bl         4BFF9CC1   0     CALL      __assert,3,gr3-gr5,#ProcAlias",__assert",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",lr",fcr",xer",f  1475| 0063E0 addi       38800000   1     LI         gr4=0
  339| 006344 ori        60000000   1                                                                                                                            1475| 0063E4 addi       38600000   1     LI         gr3=0
  339| 006348 addi       389E0010   1     AI        gr4=gr30,16                                                                                                  1472| 0063E8 stw        901E0038   1     ST4A       (*)aggr#4.ag_closed(gr30,56)=gr0
  341| 00634C lwz        80BF0034   1     L4A       gr5=(*)_frame._frame.f_lasti(gr31,52)                                                                        1475| 0063EC stw        909E003C   1     ST4A       (*)aggr#4.ag_running_async(gr30,60)=gr4
  341| 006350 cmpwi      2C050000   2     C4        cr0=gr5,0                                                                                                       0|                                CL.2328:
  341| 006354 bc         41800014   1     BT        CL.2031,cr0,0x1/lt,taken=40%(40,60)                                                                             0| 0063F0 lwz        83C10038   1     L4A        gr30=#stack(gr1,56)
    0| 006358 lwz        80010048   1     L4A       gr0=#stack(gr1,72)                                                                                              0| 0063F4 lwz        80010048   1     L4A        gr0=#stack(gr1,72)
    0| 00635C lwz        83C10038   1     L4A       gr30=#stack(gr1,56)                                                                                          1488| 0063F8 addi       38210040   1     AI         gr1=gr1,64
    0| 006360 mtspr      7C0803A6   1     LLR       lr=gr0                                                                                                          0| 0063FC mtspr      7C0803A6   1     LLR        lr=gr0
    0| 006364 b          4BFFFF2C   0     B         CL.553,-1                                                                                                    1488| 006400 bclr       4E800020   3     BA         lr
    0|                                CL.2031:                                                                                                                      0|                                CL.2325:
    0| 006368 lwz        80010048   1     L4A       gr0=#stack(gr1,72)                                                                                           1472| 006404 addi       38000001   1     LI         gr0=1
    0| 00636C lwz        83E1003C   1     L4A       gr31=#stack(gr1,60)                                                                                          1475| 006408 addi       38800000   1     LI         gr4=0
    0| 006370 mtspr      7C0803A6   1     LLR       lr=gr0                                                                                                       1475| 00640C addi       38600000   1     LI         gr3=0
    0| 006374 b          4BFFFF70   0     B         CL.1549,-1                                                                                                      0| 006410 lwz        83E1003C   1     L4A        gr31=#stack(gr1,60)
     |               Tag Table                                                                                                                                   1472| 006414 stw        901E0038   1     ST4A       (*)aggr#4.ag_closed(gr30,56)=gr0
     | 006378        00000000 00002041 80020300 00000000 00000138 00125F50                                                                                       1475| 006418 stw        909E003C   1     ST4A       (*)aggr#4.ag_running_async(gr30,60)=gr4







Wed Apr 15 07:30:04 CDT 2020  Page 177


     | 006390        7947656E 5F796640 41463132 315F3933                                                                                                            0| 00641C b          4BFFFFD4   0     B          CL.2328,-1
     |               Instruction count           78                                                                                                                 0|                                CL.1775:
     |               Straight-line exec time     76                                                                                                              1466| 006420 lwz        807F0000   1     L4A        gr3=PyExc_StopAsyncIteration(gr31,0)
 GPR's set/used:   ssus ssss ssss s---  ---- ---- ---- ----                                                                                                      1466| 006424 bl         4BFF9BDD   0     CALL       PyErr_SetNone,1,(*)_object",gr3,#ProcAlias",PyErr_SetNone",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",
 FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----                                                                                                      1466| 006428 ori        60000000   1
 CCR's set/used:   ss-- -sss                                                                                                                                     1469| 00642C lwz        807F0000   1     L4A        gr3=PyExc_StopAsyncIteration(gr31,0)
     | 000000                             PDEF     async_gen_wrapped_val_traverse at AF122_7                                                                        1469| 006430 bl         4BFF9BD1   0     CALL       gr3=PyErr_ExceptionMatches,1,(*)_object",gr3,#ProcAlias",PyErr_ExceptionMatches",fcr",gr1,cr[01567]",gr0",
 1697|                                    PROC      o,visit,arg,gr3-gr5                                                                                          1469| 006434 ori        60000000   1
    0| 0063A0 mfspr      7C0802A6   1     LFLR      gr0=lr                                                                                                       1469| 006438 cmpwi      2C030000   1     C4         cr0=gr3,0
 1700| 0063A4 lwz        80630008   1     L4A       gr3=(*)aggr#C.agw_val(gr3,8)                                                                                 1469| 00643C bc         4082FFC8   1     BF         CL.2325,cr0,0x4/eq,taken=30%(30,70)
    0| 0063A8 ori        60860000   1     LR        gr6=gr4                                                                                                         0| 006440 b          4BFFFF60   1     B          CL.2327,-1
 1700| 0063AC ori        60A40000   1     LR        gr4=gr5                                                                                                          |               Tag Table
    0| 0063B0 stw        90010008   1     ST4A      #stack(gr1,8)=gr0                                                                                                | 006444        00000000 00002041 80020200 00000000 000000E4 001F6173
 1700| 0063B4 lwz        81660008   1     L4A       gr11=#new_env(gr6,8)                                                                                             | 00645C        796E635F 67656E5F 756E7772 61705F76 616C7565 40414631
 1700| 0063B8 lwz        80060000   1     L4A       gr0=#fnc_adr(gr6,0)                                                                                              | 006474        32325F31 35
    0| 0063BC stwu       9421FFB0   1     ST4U      gr1,#stack(gr1,-80)=gr1                                                                                          |               Instruction count           57
 1700| 0063C0 mtspr      7C0903A6   1     LCTR      ctr=gr0                                                                                                          |               Straight-line exec time     55
 1700| 0063C4 stw        90410014   1     ST4A      #cur_toc(gr1,20)=gr2                                                                                         GPR's set/used:   ssus ssss ssss s---  ---- ---- ---- ----
 1700| 0063C8 lwz        80460004   1     CALL      gr3=gr6,2,(*)_object",gr3,(*)void",gr4,#ProcAlias",fcr",(*)int()",gr1,cr[01567]",gr0",gr4"-gr12",fp0"-fp13"  FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----
 1700| 0063CC bcctrl     4E800421   0                                                                                                                            CCR's set/used:   ss-- -sss
 1700| 0063D0 lwz        80410014   1                                                                                                                                | 000000                             PDEF       async_gen_athrow_traverse at AF123_5
 1700| 0063D4 cmpwi      2C030000   1     C4        cr0=gr3,0                                                                                                    1787|                                    PROC       o,visit,arg,gr3-gr5
 1700| 0063D8 bc         40820018   1     BF        CL.2292,cr0,0x4/eq,taken=50%(0,0)                                                                               0| 006480 mfspr      7C0802A6   1     LFLR       gr0=lr
 1701| 0063DC addi       38600000   2     LI        gr3=0                                                                                                        1790| 006484 lwz        8063000C   1     L4A        gr3=(*)aggr#E.agt_args(gr3,12)
    0| 0063E0 lwz        80010058   1     L4A       gr0=#stack(gr1,88)                                                                                              0| 006488 stwu       9421FFB0   1     ST4U       gr1,#stack(gr1,-80)=gr1
 1702| 0063E4 addi       38210050   1     AI        gr1=gr1,80                                                                                                      0| 00648C ori        60860000   1     LR         gr6=gr4
    0| 0063E8 mtspr      7C0803A6   1     LLR       lr=gr0                                                                                                       1790| 006490 ori        60A40000   1     LR         gr4=gr5
 1702| 0063EC bclr       4E800020   3     BA        lr                                                                                                              0| 006494 stw        90010058   1     ST4A       #stack(gr1,88)=gr0
    0|                                CL.2292:                                                                                                                   1790| 006498 stw        90410014   1     ST4A       #cur_toc(gr1,20)=gr2
    0| 0063F0 lwz        80010058   1     L4A       gr0=#stack(gr1,88)                                                                                           1790| 00649C lwz        81660008   1     L4A        gr11=#new_env(gr6,8)
 1702| 0063F4 addi       38210050   1     AI        gr1=gr1,80                                                                                                   1790| 0064A0 lwz        80060000   1     L4A        gr0=#fnc_adr(gr6,0)
    0| 0063F8 mtspr      7C0803A6   1     LLR       lr=gr0                                                                                                       1790| 0064A4 mtspr      7C0903A6   2     LCTR       ctr=gr0
 1702| 0063FC bclr       4E800020   3     BA        lr                                                                                                           1790| 0064A8 lwz        80460004   1     CALL       gr3=gr6,2,(*)_object",gr3,(*)void",gr4,#ProcAlias",fcr",(*)int()",gr1,cr[01567]",gr0",gr4"-gr12",fp0"-fp13
     |               Tag Table                                                                                                                                   1790| 0064AC bcctrl     4E800421   0
     | 006400        00000000 00002041 80000300 00000000 00000060 00266173                                                                                       1790| 0064B0 lwz        80410014   1
     | 006418        796E635F 67656E5F 77726170 7065645F 76616C5F 74726176                                                                                       1790| 0064B4 cmpwi      2C030000   1     C4         cr0=gr3,0
     | 006430        65727365 40414631 32325F37                                                                                                                  1790| 0064B8 bc         40820018   1     BF         CL.2343,cr0,0x4/eq,taken=50%(0,0)
     |               Instruction count           24                                                                                                              1791| 0064BC addi       38600000   2     LI         gr3=0
     |               Straight-line exec time     28                                                                                                                 0| 0064C0 lwz        80010058   1     L4A        gr0=#stack(gr1,88)
 GPR's set/used:   ssus ssss ssss s---  ---- ---- ---s ssss                                                                                                      1792| 0064C4 addi       38210050   1     AI         gr1=gr1,80
 FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----                                                                                                         0| 0064C8 mtspr      7C0803A6   1     LLR        lr=gr0
 CCR's set/used:   ss-- -sss                                                                                                                                     1792| 0064CC bclr       4E800020   3     BA         lr
     | 000000                             PDEF     async_gen_init_hooks at AF123_21                                                                                    0|                                CL.2343:
 1242|                                    PROC      o,gr3                                                                                                           0| 0064D0 lwz        80010058   1     L4A        gr0=#stack(gr1,88)
   67| 006440 lwz        808200A4   1     L4A       gr4=._PyRuntime(gr2,0)                                                                                       1792| 0064D4 addi       38210050   1     AI         gr1=gr1,80
    0| 006444 mfspr      7C0802A6   1     LFLR      gr0=lr                                                                                                          0| 0064D8 mtspr      7C0803A6   1     LLR        lr=gr0
   54| 006448 lwz        808401A0   1     L4A       gr4=<s149:d416:l4>(gr4,416)                                                                                  1792| 0064DC bclr       4E800020   3     BA         lr
    0| 00644C stw        90010008   1     ST4A      #stack(gr1,8)=gr0                                                                                                |               Tag Table
    0| 006450 stw        93E1FFFC   1     ST4A      #stack(gr1,-4)=gr31                                                                                              | 0064E0        00000000 00002041 80000300 00000000 00000060 00216173
 1252| 006454 addi       38000001   1     LI        gr0=1                                                                                                            | 0064F8        796E635F 67656E5F 61746872 6F775F74 72617665 72736540
    0| 006458 stw        93C1FFF8   1     ST4A      #stack(gr1,-8)=gr30                                                                                              | 006510        41463132 335F35
    0| 00645C stw        93A1FFF4   1     ST4A      #stack(gr1,-12)=gr29                                                                                             |               Instruction count           24
    0| 006460 or.        7C7D1B79   1     LR_R      gr29,cr0=gr3                                                                                                     |               Straight-line exec time     29
    0| 006464 stw        9381FFF0   1     ST4A      #stack(gr1,-16)=gr28                                                                                         GPR's set/used:   ssus ssss ssss s---  ---- ---- ---- -sss
    0| 006468 stw        9361FFEC   1     ST4A      #stack(gr1,-20)=gr27                                                                                         FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----
  401| 00646C lwz        80620004   1     L4A       gr3=._Py_RefTotal(gr2,0)                                                                                     CCR's set/used:   ss-- -sss







Wed Apr 15 07:30:04 CDT 2020  Page 178


 1262| 006470 lwz        83C40078   1     L4A       gr30=(*)_ts._ts.async_gen_firstiter(gr4,120)                                                                     | 000000                             PDEF       async_gen_athrow_traverse at AF124_5
    0| 006474 stwu       9421FF20   1     ST4U      gr1,#stack(gr1,-224)=gr1                                                                                     1787|                                    PROC       o_123_5,visit_123_5,arg_123_5,gr3-gr5
 1252| 006478 stw        901D0034   1     ST4A      (*)aggr#4.ag_hooks_inited(gr29,52)=gr0                                                                          0| 006520 mfspr      7C0802A6   1     LFLR       gr0=lr
 1256| 00647C lwz        8084007C   1     L4A       gr4=(*)_ts._ts.async_gen_finalizer(gr4,124)                                                                     0| 006524 stwu       9421FFB0   1     ST4U       gr1,#stack(gr1,-80)=gr1
  401| 006480 ori        607F0000   1     LR        gr31=gr3                                                                                                        0| 006528 stw        90010058   1     ST4A       #stack(gr1,88)=gr0
    0| 006484 ori        63C60000   1     LR        gr6=gr30                                                                                                        0| 00652C stw        93E1004C   1     ST4A       #stack(gr1,76)=gr31
 1263| 006488 cmpwi      2C860000   1     C4        cr1=gr6,0                                                                                                       0| 006530 ori        607F0000   1     LR         gr31=gr3
  118| 00648C stw        90410014   1     ST4A      #cur_toc(gr1,20)=gr2                                                                                            0| 006534 stw        93C10048   1     ST4A       #stack(gr1,72)=gr30
  401| 006490 lwz        80A30000   1     L4A       gr5=<s117:d0:l4>(gr3,0)                                                                                         0| 006538 stw        93A10044   1     ST4A       #stack(gr1,68)=gr29
  401| 006494 addi       38050001   2     AI        gr0=gr5,1                                                                                                       0| 00653C ori        609E0000   1     LR         gr30=gr4
    0| 006498 ori        60850000   1     LR        gr5=gr4                                                                                                         0| 006540 ori        60BD0000   1     LR         gr29=gr5
 1257| 00649C cmpwi      2F050000   1     C4        cr6=gr5,0                                                                                                    1789| 006544 stw        90410014   1     ST4A       #cur_toc(gr1,20)=gr2
 1257| 0064A0 bc         419A0018   1     BT        CL.141,cr6,0x4/eq,taken=50%(0,0)                                                                             1789| 006548 ori        60A40000   1     LR         gr4=gr5
  401| 0064A4 stw        90030000   1     ST4A      <s117:d0:l4>(gr3,0)=gr0                                                                                      1789| 00654C lwz        80630008   1     L4A        gr3=(*)aggr#E.agt_gen(gr3,8)
 1259| 0064A8 stw        909D0030   1     ST4A      (*)aggr#4.ag_finalizer(gr29,48)=gr4                                                                          1789| 006550 lwz        801E0000   1     L4A        gr0=#fnc_adr(gr30,0)
  403| 0064AC lwz        80640000   1     L4A       gr3=(*)_object._object.ob_refcnt(gr4,0)                                                                      1789| 006554 lwz        817E0008   1     L4A        gr11=#new_env(gr30,8)
  403| 0064B0 addi       38030001   2     AI        gr0=gr3,1                                                                                                    1789| 006558 mtspr      7C0903A6   1     LCTR       ctr=gr0
  403| 0064B4 stw        90040000   1     ST4A      (*)_object._object.ob_refcnt(gr4,0)=gr0                                                                      1789| 00655C lwz        805E0004   1     CALL       gr3=gr30,2,(*)_object",gr3,(*)void",gr4,#ProcAlias",fcr",(*)int()",gr1,cr[01567]",gr0",gr4"-gr12",fp0"-fp1
 1260|                                CL.141:                                                                                                                    1789| 006560 bcctrl     4E800421   0
  401| 0064B8 lwz        807F0000   1     L4A       gr3=<s117:d0:l4>(gr31,0)                                                                                     1789| 006564 lwz        80410014   1
  403| 0064BC lwz        809E0000   1     L4A       gr4=(*)_object._object.ob_refcnt(gr30,0)                                                                     1789| 006568 cmpwi      2C030000   1     C4         cr0=gr3,0
 1263| 0064C0 bc         418602A8   0     BT        CL.2239,cr1,0x4/eq,taken=30%(30,70)                                                                          1789| 00656C bc         4082005C   1     BF         CL.2345,cr0,0x4/eq,taken=30%(30,70)
  401| 0064C4 addi       38030001   2     AI        gr0=gr3,1                                                                                                    1791| 006570 addi       38600000   2     LI         gr3=0
  401| 0064C8 stw        901F0000   1     ST4A      <s117:d0:l4>(gr31,0)=gr0                                                                                        0| 006574 lwz        80010058   1     L4A        gr0=#stack(gr1,88)
  403| 0064CC addi       38840001   1     AI        gr4=gr4,1                                                                                                       0| 006578 mtspr      7C0803A6   2     LLR        lr=gr0
  403| 0064D0 stw        909E0000   1     ST4A      (*)_object._object.ob_refcnt(gr30,0)=gr4                                                                     1790| 00657C lwz        801F000C   1     L4A        gr0=(*)aggr#E.agt_args(gr31,12)
  183| 0064D4 bc         41820278   0     BT        CL.2242,cr0,0x4/eq,taken=40%(40,60)                                                                          1790| 006580 cmpwi      2C000000   2     C4         cr0=gr0,0
  183|                                CL.1358:                                                                                                                   1790| 006584 bc         40820018   1     BF         CL.2346,cr0,0x4/eq,taken=40%(40,60)
  185| 0064D8 stw        93A100BC   1     ST4A      _args(gr1,188)=gr29                                                                                             0| 006588 lwz        83E1004C   1     L4A        gr31=#stack(gr1,76)
  186| 0064DC bl         4BFF9B25   0     CALL      gr3=PyThreadState_Get,0,#ProcAlias",PyThreadState_Get",fcr",gr1,cr[01567]",gr0",gr4"-gr12",fp0"-fp13",mq",l     0| 00658C lwz        83C10048   1     L4A        gr30=#stack(gr1,72)
  186| 0064E0 ori        60000000   1                                                                                                                               0| 006590 lwz        83A10044   1     L4A        gr29=#stack(gr1,68)
   72| 0064E4 cmpwi      2C1E0000   1     C4        cr0=gr30,0                                                                                                   1792| 006594 addi       38210050   1     AI         gr1=gr1,80
  187| 0064E8 addis      3FA08000   1     LIU       gr29=32768                                                                                                   1792| 006598 bclr       4E800020   0     BA         lr
  186| 0064EC ori        607B0000   1     LR        gr27=gr3                                                                                                        0|                                CL.2346:
   72| 0064F0 bc         41820240   0     BT        CL.2243,cr0,0x4/eq,taken=40%(40,60)                                                                             0| 00659C ori        63E30000   1     LR         gr3=gr31
   72|                                CL.1370:                                                                                                                      0| 0065A0 ori        63C40000   1     LR         gr4=gr30
   73| 0064F4 lwz        839E0004   1     L4A       gr28=(*)_object._object.ob_type(gr30,4)                                                                         0| 0065A4 ori        63A50000   1     LR         gr5=gr29
  617| 0064F8 ori        63830000   2     LR        gr3=gr28                                                                                                        0| 0065A8 bl         4BFFFED9   0     CALL       gr3=async_gen_athrow_traverse at AF123_5,3,gr3-gr5,fcr",async_gen_athrow_traverse at AF123_5",gr1,cr[01567]",gr0
  617| 0064FC bl         4BFF9B05   0     CALL      gr3=PyType_GetFlags,1,(*)_typeobject",gr3,#ProcAlias",PyType_GetFlags",fcr",gr1,cr[01567]",gr0",gr4"-gr12",     0| 0065AC lwz        83A10044   1     L4A        gr29=#stack(gr1,68)
  617| 006500 ori        60000000   1                                                                                                                               0| 0065B0 lwz        80010058   1     L4A        gr0=#stack(gr1,88)
   74| 006504 andi.      70600800   1     RN4_R     gr0,cr0=gr3,0,0x800                                                                                             0| 0065B4 lwz        83C10048   1     L4A        gr30=#stack(gr1,72)
   77| 006508 ori        63C30000   1     LR        gr3=gr30                                                                                                        0| 0065B8 lwz        83E1004C   1     L4A        gr31=#stack(gr1,76)
   74| 00650C bc         418201A0   0     BT        CL.1776,cr0,0x4/eq,taken=50%(0,0)                                                                            1792| 0065BC addi       38210050   1     AI         gr1=gr1,80
   77| 006510 bl         4BFF9AF1   1     CALL      gr3=PyCallable_Check,1,(*)_object",gr3,#ProcAlias",PyCallable_Check",fcr",gr1,cr[01567]",gr0",gr4"-gr12",fp     0| 0065C0 mtspr      7C0803A6   1     LLR        lr=gr0
   77| 006514 ori        60000000   1                                                                                                                            1792| 0065C4 bclr       4E800020   3     BA         lr
   77| 006518 cmpwi      2C030000   1     C4        cr0=gr3,0                                                                                                       0|                                CL.2345:
   77| 00651C bc         418201F8   1     BT        CL.2244,cr0,0x4/eq,taken=40%(40,60)                                                                             0| 0065C8 lwz        80010058   1     L4A        gr0=#stack(gr1,88)
   77|                                CL.1377:                                                                                                                      0| 0065CC lwz        83E1004C   1     L4A        gr31=#stack(gr1,76)
   78| 006520 lwz        839C001C   1     L4A       gr28=(*)_typeobject._typeobject.tp_vectorcall_offset(gr28,28)                                                   0| 0065D0 lwz        83C10048   1     L4A        gr30=#stack(gr1,72)
    0| 006524 or.        7F80E379   2     LR_R      gr0,cr0=gr28                                                                                                    0| 0065D4 lwz        83A10044   1     L4A        gr29=#stack(gr1,68)
   79| 006528 bc         408101D0   1     BF        CL.2245,cr0,0x2/gt,taken=40%(40,60)                                                                          1792| 0065D8 addi       38210050   1     AI         gr1=gr1,80
   79|                                CL.1379:                                                                                                                      0| 0065DC mtspr      7C0803A6   1     LLR        lr=gr0
  118| 00652C ori        63C30000   1     LR        gr3=gr30                                                                                                     1792| 0065E0 bclr       4E800020   3     BA         lr
   81| 006530 lwzx       7CFEE02E   1     L4A       gr7=(*)_object*()*(gr30,gr28,0)                                                                                  |               Tag Table
  118| 006534 addi       388100BC   1     AI        gr4=gr1,188                                                                                                      | 0065E4        00000000 00002041 80030300 00000000 000000C4 00216173
  118| 006538 addi       38BD0001   1     AI        gr5=gr29,1                                                                                                       | 0065FC        796E635F 67656E5F 61746872 6F775F74 72617665 72736540







Wed Apr 15 07:30:04 CDT 2020  Page 179


  118| 00653C addi       38C00000   1     LI        gr6=0                                                                                                            | 006614        41463132 345F35
    0| 006540 or.        7CE03B79   1     LR_R      gr0,cr0=gr7                                                                                                      |               Instruction count           49
  114| 006544 bc         41820168   1     BT        CL.1776,cr0,0x4/eq,taken=30%(30,70)                                                                              |               Straight-line exec time     53
  118| 006548 lwz        80070000   2     L4A       gr0=#fnc_adr(gr7,0)                                                                                          GPR's set/used:   ssus ssss ssss s---  ---- ---- ---- ----
  118| 00654C lwz        81670008   1     L4A       gr11=#new_env(gr7,8)                                                                                         FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----
  118| 006550 mtspr      7C0903A6   1     LCTR      ctr=gr0                                                                                                      CCR's set/used:   ss-- -sss
  118| 006554 lwz        80470004   1     CALL      gr3=gr7,4,(*)_object",gr3,(*)_object*C",gr4,gr5,(*)_object",gr6,#ProcAlias",(*)_object",fcr",(*)_object*()"      | 000000                             PDEF       async_gen_wrapped_val_traverse at AF125_7
  118| 006558 bcctrl     4E800421   0                                                                                                                            1697|                                    PROC       o,visit,arg,gr3-gr5
  118| 00655C lwz        80410014   1                                                                                                                               0| 006620 mfspr      7C0802A6   1     LFLR       gr0=lr
  118| 006560 ori        60650000   1     LR        gr5=gr3                                                                                                      1700| 006624 lwz        80630008   1     L4A        gr3=(*)aggr#C.agw_val(gr3,8)
  119| 006564 ori        63630000   1     LR        gr3=gr27                                                                                                        0| 006628 stwu       9421FFB0   1     ST4U       gr1,#stack(gr1,-80)=gr1
  119| 006568 addi       38C00000   1     LI        gr6=0                                                                                                           0| 00662C ori        60860000   1     LR         gr6=gr4
  119| 00656C ori        63C40000   1     LR        gr4=gr30                                                                                                     1700| 006630 ori        60A40000   1     LR         gr4=gr5
  119| 006570 bl         4BFF9A91   0     CALL      gr3=_Py_CheckFunctionResult,4,(*)_ts",gr3,(*)_object",gr4,(*)_object",gr5,(*)Cuchar",gr6,#ProcAlias",_Py_Ch     0| 006634 stw        90010058   1     ST4A       #stack(gr1,88)=gr0
  119| 006574 ori        60000000   1                                                                                                                            1700| 006638 stw        90410014   1     ST4A       #cur_toc(gr1,20)=gr2
 1267| 006578 ori        607C0000   1     LR        gr28=gr3                                                                                                     1700| 00663C lwz        81660008   1     L4A        gr11=#new_env(gr6,8)
  417| 00657C lwz        807E0000   1     L4A       gr3=(*)_object._object.ob_refcnt(gr30,0)                                                                     1700| 006640 lwz        80060000   1     L4A        gr0=#fnc_adr(gr6,0)
  415| 006580 lwz        809F0000   1     L4A       gr4=<s117:d0:l4>(gr31,0)                                                                                     1700| 006644 mtspr      7C0903A6   2     LCTR       ctr=gr0
    0| 006584 lwz        80A20018   1     L4A       gr5=.+CONSTANT_AREA(gr2,0)                                                                                   1700| 006648 lwz        80460004   1     CALL       gr3=gr6,2,(*)_object",gr3,(*)void",gr4,#ProcAlias",fcr",(*)int()",gr1,cr[01567]",gr0",gr4"-gr12",fp0"-fp13
  417| 006588 addi       3803FFFF   1     AI        gr0=gr3,-1                                                                                                   1700| 00664C bcctrl     4E800421   0
  417| 00658C stw        901E0000   1     ST4A      (*)_object._object.ob_refcnt(gr30,0)=gr0                                                                     1700| 006650 lwz        80410014   1
  415| 006590 addi       3864FFFF   1     AI        gr3=gr4,-1                                                                                                   1700| 006654 cmpwi      2C030000   1     C4         cr0=gr3,0
  415| 006594 stw        907F0000   1     ST4A      <s117:d0:l4>(gr31,0)=gr3                                                                                     1700| 006658 bc         40820018   1     BF         CL.2337,cr0,0x4/eq,taken=50%(0,0)
  408| 006598 addi       3BA51110   1     AI        gr29=gr5,4368                                                                                                1701| 00665C addi       38600000   2     LI         gr3=0
  417| 00659C cmpwi      2C000000   1     C4        cr0=gr0,0                                                                                                       0| 006660 lwz        80010058   1     L4A        gr0=#stack(gr1,88)
  417| 0065A0 bc         418200F4   1     BT        CL.2236,cr0,0x4/eq,taken=40%(40,60)                                                                          1702| 006664 addi       38210050   1     AI         gr1=gr1,80
    0|                                CL.2249:                                                                                                                      0| 006668 mtspr      7C0803A6   1     LLR        lr=gr0
    0| 0065A4 lwz        836100CC   1     L4A       gr27=#stack(gr1,204)                                                                                         1702| 00666C bclr       4E800020   3     BA         lr
  419| 0065A8 bc         418000D0   0     BT        CL.2235,cr0,0x1/lt,taken=40%(40,60)                                                                             0|                                CL.2337:
    0| 0065AC lwz        83C100D8   2     L4A       gr30=#stack(gr1,216)                                                                                            0| 006670 lwz        80010058   1     L4A        gr0=#stack(gr1,88)
  421|                                CL.1388:                                                                                                                   1702| 006674 addi       38210050   1     AI         gr1=gr1,80
 1269| 0065B0 cmpwi      2C1C0000   1     C4        cr0=gr28,0                                                                                                      0| 006678 mtspr      7C0803A6   1     LLR        lr=gr0
 1269| 0065B4 bc         418200A4   1     BT        CL.2247,cr0,0x4/eq,taken=30%(30,70)                                                                          1702| 00667C bclr       4E800020   3     BA         lr
  415| 0065B8 lwz        809F0000   2     L4A       gr4=<s117:d0:l4>(gr31,0)                                                                                         |               Tag Table
  417| 0065BC lwz        807C0000   1     L4A       gr3=(*)_object._object.ob_refcnt(gr28,0)                                                                         | 006680        00000000 00002041 80000300 00000000 00000060 00266173
  417| 0065C0 addi       3803FFFF   2     AI        gr0=gr3,-1                                                                                                       | 006698        796E635F 67656E5F 77726170 7065645F 76616C5F 74726176
  417| 0065C4 stw        901C0000   1     ST4A      (*)_object._object.ob_refcnt(gr28,0)=gr0                                                                         | 0066B0        65727365 40414631 32355F37
  415| 0065C8 addi       3864FFFF   1     AI        gr3=gr4,-1                                                                                                       |               Instruction count           24
  415| 0065CC stw        907F0000   1     ST4A      <s117:d0:l4>(gr31,0)=gr3                                                                                         |               Straight-line exec time     29
  417| 0065D0 cmpwi      2C000000   1     C4        cr0=gr0,0                                                                                                    GPR's set/used:   ssus ssss ssss s---  ---- ---- ---- ----
  417| 0065D4 bc         41820058   1     BT        CL.1391,cr0,0x4/eq,taken=40%(40,60)                                                                          FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----
    0| 0065D8 lwz        83E100DC   1     L4A       gr31=#stack(gr1,220)                                                                                         CCR's set/used:   ss-- -sss
  419| 0065DC bc         41800020   0     BT        CL.2248,cr0,0x1/lt,taken=40%(40,60)                                                                              | 000000                             PDEF       async_gen_asend_traverse at AF126_13
 1275| 0065E0 addi       38600000   2     LI        gr3=0                                                                                                        1509|                                    PROC       o,visit,arg,gr3-gr5
    0| 0065E4 lwz        83A100D4   1     L4A       gr29=#stack(gr1,212)                                                                                            0| 0066C0 mfspr      7C0802A6   1     LFLR       gr0=lr
    0| 0065E8 lwz        838100D0   1     L4A       gr28=#stack(gr1,208)                                                                                         1512| 0066C4 lwz        8063000C   1     L4A        gr3=(*)aggr#D.ags_sendval(gr3,12)
 1276| 0065EC addi       382100E0   1     AI        gr1=gr1,224                                                                                                     0| 0066C8 stwu       9421FFB0   1     ST4U       gr1,#stack(gr1,-80)=gr1
    0| 0065F0 lwz        80010008   1     L4A       gr0=#stack(gr1,8)                                                                                               0| 0066CC ori        60860000   1     LR         gr6=gr4
    0| 0065F4 mtspr      7C0803A6   2     LLR       lr=gr0                                                                                                       1512| 0066D0 ori        60A40000   1     LR         gr4=gr5
 1276| 0065F8 bclr       4E800020   3     BA        lr                                                                                                              0| 0066D4 stw        90010058   1     ST4A       #stack(gr1,88)=gr0
    0|                                CL.2248:                                                                                                                   1512| 0066D8 stw        90410014   1     ST4A       #cur_toc(gr1,20)=gr2
  420| 0065FC ori        63A30000   1     LR        gr3=gr29                                                                                                     1512| 0066DC lwz        81660008   1     L4A        gr11=#new_env(gr6,8)
  420| 006600 addi       388004F8   1     LI        gr4=1272                                                                                                     1512| 0066E0 lwz        80060000   1     L4A        gr0=#fnc_adr(gr6,0)
  420| 006604 ori        63850000   1     LR        gr5=gr28                                                                                                     1512| 0066E4 mtspr      7C0903A6   2     LCTR       ctr=gr0
  420| 006608 bl         4BFF99F9   0     CALL      _Py_NegativeRefcount,3,(*)Cuchar",gr3,gr4,(*)_object",gr5,#ProcAlias",_Py_NegativeRefcount",fcr",gr1,cr[015  1512| 0066E8 lwz        80460004   1     CALL       gr3=gr6,2,(*)_object",gr3,(*)void",gr4,#ProcAlias",fcr",(*)int()",gr1,cr[01567]",gr0",gr4"-gr12",fp0"-fp13
  420| 00660C ori        60000000   1                                                                                                                            1512| 0066EC bcctrl     4E800421   0







Wed Apr 15 07:30:04 CDT 2020  Page 180


 1275| 006610 addi       38600000   1     LI        gr3=0                                                                                                        1512| 0066F0 lwz        80410014   1
    0| 006614 lwz        838100D0   1     L4A       gr28=#stack(gr1,208)                                                                                         1512| 0066F4 cmpwi      2C030000   1     C4         cr0=gr3,0
    0| 006618 lwz        83A100D4   1     L4A       gr29=#stack(gr1,212)                                                                                         1512| 0066F8 bc         40820018   1     BF         CL.2319,cr0,0x4/eq,taken=50%(0,0)
 1276| 00661C addi       382100E0   1     AI        gr1=gr1,224                                                                                                  1513| 0066FC addi       38600000   2     LI         gr3=0
    0| 006620 lwz        80010008   1     L4A       gr0=#stack(gr1,8)                                                                                               0| 006700 lwz        80010058   1     L4A        gr0=#stack(gr1,88)
    0| 006624 mtspr      7C0803A6   2     LLR       lr=gr0                                                                                                       1514| 006704 addi       38210050   1     AI         gr1=gr1,80
 1276| 006628 bclr       4E800020   3     BA        lr                                                                                                              0| 006708 mtspr      7C0803A6   1     LLR        lr=gr0
  423|                                CL.1391:                                                                                                                   1514| 00670C bclr       4E800020   3     BA         lr
  425| 00662C ori        63830000   1     LR        gr3=gr28                                                                                                        0|                                CL.2319:
    0| 006630 lwz        83E100DC   1     L4A       gr31=#stack(gr1,220)                                                                                            0| 006710 lwz        80010058   1     L4A        gr0=#stack(gr1,88)
    0| 006634 lwz        83A100D4   1     L4A       gr29=#stack(gr1,212)                                                                                         1514| 006714 addi       38210050   1     AI         gr1=gr1,80
  425| 006638 bl         4BFF99C9   0     CALL      _Py_Dealloc,1,(*)_object",gr3,#ProcAlias",_Py_Dealloc",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",l     0| 006718 mtspr      7C0803A6   1     LLR        lr=gr0
  425| 00663C ori        60000000   1                                                                                                                            1514| 00671C bclr       4E800020   3     BA         lr
 1275| 006640 addi       38600000   1     LI        gr3=0                                                                                                            |               Tag Table
    0| 006644 lwz        838100D0   1     L4A       gr28=#stack(gr1,208)                                                                                             | 006720        00000000 00002041 80000300 00000000 00000060 00216173
 1276| 006648 addi       382100E0   1     AI        gr1=gr1,224                                                                                                      | 006738        796E635F 67656E5F 6173656E 645F7472 61766572 73654041
    0| 00664C lwz        80010008   1     L4A       gr0=#stack(gr1,8)                                                                                                | 006750        46313236 5F3133
    0| 006650 mtspr      7C0803A6   2     LLR       lr=gr0                                                                                                           |               Instruction count           24
 1276| 006654 bclr       4E800020   3     BA        lr                                                                                                               |               Straight-line exec time     29
    0|                                CL.2247:                                                                                                                   GPR's set/used:   ssus ssss ssss s---  ---- ---- ---- -sss
 1270| 006658 addi       38600001   1     LI        gr3=1                                                                                                        FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----
    0| 00665C lwz        83E100DC   1     L4A       gr31=#stack(gr1,220)                                                                                         CCR's set/used:   ss-- -sss
    0| 006660 lwz        83A100D4   1     L4A       gr29=#stack(gr1,212)                                                                                             | 000000                             PDEF       async_gen_asend_traverse at AF127_13
    0| 006664 lwz        838100D0   1     L4A       gr28=#stack(gr1,208)                                                                                         1509|                                    PROC       o_126_13,visit_126_13,arg_126_13,gr3-gr5
 1276| 006668 addi       382100E0   1     AI        gr1=gr1,224                                                                                                     0| 006760 mfspr      7C0802A6   1     LFLR       gr0=lr
    0| 00666C lwz        80010008   1     L4A       gr0=#stack(gr1,8)                                                                                               0| 006764 stwu       9421FFB0   1     ST4U       gr1,#stack(gr1,-80)=gr1
    0| 006670 mtspr      7C0803A6   2     LLR       lr=gr0                                                                                                          0| 006768 stw        90010058   1     ST4A       #stack(gr1,88)=gr0
 1276| 006674 bclr       4E800020   3     BA        lr                                                                                                              0| 00676C stw        93E1004C   1     ST4A       #stack(gr1,76)=gr31
    0|                                CL.2235:                                                                                                                      0| 006770 ori        607F0000   1     LR         gr31=gr3
  420| 006678 ori        63A30000   1     LR        gr3=gr29                                                                                                        0| 006774 stw        93C10048   1     ST4A       #stack(gr1,72)=gr30
  420| 00667C addi       388004F4   1     LI        gr4=1268                                                                                                        0| 006778 stw        93A10044   1     ST4A       #stack(gr1,68)=gr29
  420| 006680 ori        63C50000   1     LR        gr5=gr30                                                                                                        0| 00677C ori        609E0000   1     LR         gr30=gr4
  420| 006684 bl         4BFF997D   0     CALL      _Py_NegativeRefcount,3,(*)Cuchar",gr3,gr4,(*)_object",gr5,#ProcAlias",_Py_NegativeRefcount",fcr",gr1,cr[015     0| 006780 ori        60BD0000   1     LR         gr29=gr5
  420| 006688 ori        60000000   1                                                                                                                            1511| 006784 stw        90410014   1     ST4A       #cur_toc(gr1,20)=gr2
    0| 00668C lwz        83C100D8   1     L4A       gr30=#stack(gr1,216)                                                                                         1511| 006788 ori        60A40000   1     LR         gr4=gr5
  423| 006690 b          4BFFFF20   0     B         CL.1388,-1                                                                                                   1511| 00678C lwz        80630008   1     L4A        gr3=(*)aggr#D.ags_gen(gr3,8)
    0|                                CL.2236:                                                                                                                   1511| 006790 lwz        801E0000   1     L4A        gr0=#fnc_adr(gr30,0)
  425| 006694 ori        63C30000   1     LR        gr3=gr30                                                                                                     1511| 006794 lwz        817E0008   1     L4A        gr11=#new_env(gr30,8)
    0| 006698 lwz        836100CC   1     L4A       gr27=#stack(gr1,204)                                                                                         1511| 006798 mtspr      7C0903A6   1     LCTR       ctr=gr0
  425| 00669C bl         4BFF9965   0     CALL      _Py_Dealloc,1,(*)_object",gr3,#ProcAlias",_Py_Dealloc",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",l  1511| 00679C lwz        805E0004   1     CALL       gr3=gr30,2,(*)_object",gr3,(*)void",gr4,#ProcAlias",fcr",(*)int()",gr1,cr[01567]",gr0",gr4"-gr12",fp0"-fp1
  425| 0066A0 ori        60000000   1                                                                                                                            1511| 0067A0 bcctrl     4E800421   0
    0| 0066A4 lwz        83C100D8   1     L4A       gr30=#stack(gr1,216)                                                                                         1511| 0067A4 lwz        80410014   1
    0| 0066A8 b          4BFFFF08   0     B         CL.1388,-1                                                                                                   1511| 0067A8 cmpwi      2C030000   1     C4         cr0=gr3,0
    0|                                CL.1776:                                                                                                                   1511| 0067AC bc         4082005C   1     BF         CL.2321,cr0,0x4/eq,taken=30%(30,70)
  116| 0066AC ori        63630000   1     LR        gr3=gr27                                                                                                     1513| 0067B0 addi       38600000   2     LI         gr3=0
  116| 0066B0 ori        63C40000   1     LR        gr4=gr30                                                                                                        0| 0067B4 lwz        80010058   1     L4A        gr0=#stack(gr1,88)
  116| 0066B4 addi       38A100BC   1     AI        gr5=gr1,188                                                                                                     0| 0067B8 mtspr      7C0803A6   2     LLR        lr=gr0
  116| 0066B8 addi       38C00001   1     LI        gr6=1                                                                                                        1512| 0067BC lwz        801F000C   1     L4A        gr0=(*)aggr#D.ags_sendval(gr31,12)
  116| 0066BC addi       38E00000   1     LI        gr7=0                                                                                                        1512| 0067C0 cmpwi      2C000000   2     C4         cr0=gr0,0
  116| 0066C0 bl         4BFF9941   0     CALL      gr3=_PyObject_MakeTpCall,5,(*)_ts",gr3,(*)_object",gr4,(*)_object*C",gr5,gr6,(*)_object",gr7,#ProcAlias",(*  1512| 0067C4 bc         40820018   1     BF         CL.2322,cr0,0x4/eq,taken=40%(40,60)
  116| 0066C4 ori        60000000   1                                                                                                                               0| 0067C8 lwz        83E1004C   1     L4A        gr31=#stack(gr1,76)
 1267| 0066C8 ori        607C0000   1     LR        gr28=gr3                                                                                                        0| 0067CC lwz        83C10048   1     L4A        gr30=#stack(gr1,72)
  417| 0066CC lwz        807E0000   1     L4A       gr3=(*)_object._object.ob_refcnt(gr30,0)                                                                        0| 0067D0 lwz        83A10044   1     L4A        gr29=#stack(gr1,68)
  415| 0066D0 lwz        809F0000   1     L4A       gr4=<s117:d0:l4>(gr31,0)                                                                                     1514| 0067D4 addi       38210050   1     AI         gr1=gr1,80
    0| 0066D4 lwz        80A20018   1     L4A       gr5=.+CONSTANT_AREA(gr2,0)                                                                                   1514| 0067D8 bclr       4E800020   0     BA         lr
  417| 0066D8 addi       3803FFFF   1     AI        gr0=gr3,-1                                                                                                      0|                                CL.2322:







Wed Apr 15 07:30:04 CDT 2020  Page 181


  417| 0066DC stw        901E0000   1     ST4A      (*)_object._object.ob_refcnt(gr30,0)=gr0                                                                        0| 0067DC ori        63E30000   1     LR         gr3=gr31
  415| 0066E0 addi       3864FFFF   1     AI        gr3=gr4,-1                                                                                                      0| 0067E0 ori        63C40000   1     LR         gr4=gr30
  415| 0066E4 stw        907F0000   1     ST4A      <s117:d0:l4>(gr31,0)=gr3                                                                                        0| 0067E4 ori        63A50000   1     LR         gr5=gr29
  408| 0066E8 addi       3BA51110   1     AI        gr29=gr5,4368                                                                                                   0| 0067E8 bl         4BFFFED9   0     CALL       gr3=async_gen_asend_traverse at AF126_13,3,gr3-gr5,fcr",async_gen_asend_traverse at AF126_13",gr1,cr[01567]",gr0
  417| 0066EC cmpwi      2C000000   1     C4        cr0=gr0,0                                                                                                       0| 0067EC lwz        83A10044   1     L4A        gr29=#stack(gr1,68)
  417| 0066F0 bc         4182FFA4   1     BT        CL.2236,cr0,0x4/eq,taken=40%(40,60)                                                                             0| 0067F0 lwz        80010058   1     L4A        gr0=#stack(gr1,88)
    0| 0066F4 b          4BFFFEB0   1     B         CL.2249,-1                                                                                                      0| 0067F4 lwz        83C10048   1     L4A        gr30=#stack(gr1,72)
    0|                                CL.2245:                                                                                                                      0| 0067F8 lwz        83E1004C   1     L4A        gr31=#stack(gr1,76)
   79| 0066F8 addi       38A0004F   1     LI        gr5=79                                                                                                       1514| 0067FC addi       38210050   1     AI         gr1=gr1,80
   79| 0066FC lwz        80620018   1     L4A       gr3=.+CONSTANT_AREA(gr2,0)                                                                                      0| 006800 mtspr      7C0803A6   1     LLR        lr=gr0
   79| 006700 addi       38831174   2     AI        gr4=gr3,4468                                                                                                 1514| 006804 bclr       4E800020   3     BA         lr
   79| 006704 addi       386311C4   1     AI        gr3=gr3,4548                                                                                                    0|                                CL.2321:
   79| 006708 bl         4BFF98F9   0     CALL      __assert,3,gr3-gr5,#ProcAlias",__assert",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",lr",fcr",xer",f     0| 006808 lwz        80010058   1     L4A        gr0=#stack(gr1,88)
   79| 00670C ori        60000000   1                                                                                                                               0| 00680C lwz        83E1004C   1     L4A        gr31=#stack(gr1,76)
    0| 006710 b          4BFFFE1C   0     B         CL.1379,-1                                                                                                      0| 006810 lwz        83C10048   1     L4A        gr30=#stack(gr1,72)
    0|                                CL.2244:                                                                                                                      0| 006814 lwz        83A10044   1     L4A        gr29=#stack(gr1,68)
   77| 006714 addi       38A0004D   1     LI        gr5=77                                                                                                       1514| 006818 addi       38210050   1     AI         gr1=gr1,80
   77| 006718 lwz        80620018   1     L4A       gr3=.+CONSTANT_AREA(gr2,0)                                                                                      0| 00681C mtspr      7C0803A6   1     LLR        lr=gr0
   77| 00671C addi       38831174   2     AI        gr4=gr3,4468                                                                                                 1514| 006820 bclr       4E800020   3     BA         lr
   77| 006720 addi       386311A8   1     AI        gr3=gr3,4520                                                                                                     |               Tag Table
   77| 006724 bl         4BFF98DD   0     CALL      __assert,3,gr3-gr5,#ProcAlias",__assert",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",lr",fcr",xer",f      | 006824        00000000 00002041 80030300 00000000 000000C4 00216173
   77| 006728 ori        60000000   1                                                                                                                                | 00683C        796E635F 67656E5F 6173656E 645F7472 61766572 73654041
    0| 00672C b          4BFFFDF4   0     B         CL.1377,-1                                                                                                       | 006854        46313237 5F3133
    0|                                CL.2243:                                                                                                                       |               Instruction count           49
   72| 006730 addi       38A00048   1     LI        gr5=72                                                                                                           |               Straight-line exec time     53
   72| 006734 lwz        80620018   1     L4A       gr3=.+CONSTANT_AREA(gr2,0)                                                                                   GPR's set/used:   ssus ssss ssss s---  ---- ---- --ss ssss
   72| 006738 addi       38831174   2     AI        gr4=gr3,4468                                                                                                 FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----
   72| 00673C addi       38631194   1     AI        gr3=gr3,4500                                                                                                 CCR's set/used:   ss-- -sss
   72| 006740 bl         4BFF98C1   0     CALL      __assert,3,gr3-gr5,#ProcAlias",__assert",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",lr",fcr",xer",f      | 000000                             PDEF       async_gen_init_hooks at AF128_21
   72| 006744 ori        60000000   1                                                                                                                            1242|                                    PROC       o,gr3
    0| 006748 b          4BFFFDAC   0     B         CL.1370,-1                                                                                                     67| 006860 lwz        808200A4   1     L4A        gr4=._PyRuntime(gr2,0)
    0|                                CL.2242:                                                                                                                      0| 006864 mfspr      7C0802A6   1     LFLR       gr0=lr
  183| 00674C addi       38A000B7   1     LI        gr5=183                                                                                                         0| 006868 stwu       9421FF50   1     ST4U       gr1,#stack(gr1,-176)=gr1
  183| 006750 lwz        80620018   1     L4A       gr3=.+CONSTANT_AREA(gr2,0)                                                                                     54| 00686C lwz        808401A0   1     L4A        gr4=(*)pyruntimestate._Py_atomic_address._value(gr4,416)
  183| 006754 addi       38831174   2     AI        gr4=gr3,4468                                                                                                    0| 006870 stw        900100B8   1     ST4A       #stack(gr1,184)=gr0
  183| 006758 addi       38631168   1     AI        gr3=gr3,4456                                                                                                    0| 006874 stw        93E100AC   1     ST4A       #stack(gr1,172)=gr31
  183| 00675C bl         4BFF98A5   0     CALL      __assert,3,gr3-gr5,#ProcAlias",__assert",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",lr",fcr",xer",f  1252| 006878 addi       38000001   1     LI         gr0=1
  183| 006760 ori        60000000   1                                                                                                                               0| 00687C stw        93C100A8   1     ST4A       #stack(gr1,168)=gr30
    0| 006764 b          4BFFFD74   0     B         CL.1358,-1                                                                                                      0| 006880 stw        93A100A4   1     ST4A       #stack(gr1,164)=gr29
    0|                                CL.2239:                                                                                                                      0| 006884 or.        7C7E1B79   1     LR_R       gr30,cr0=gr3
 1275| 006768 addi       38600000   1     LI        gr3=0                                                                                                           0| 006888 stw        938100A0   1     ST4A       #stack(gr1,160)=gr28
    0| 00676C lwz        83E100DC   1     L4A       gr31=#stack(gr1,220)                                                                                            0| 00688C stw        9361009C   1     ST4A       #stack(gr1,156)=gr27
    0| 006770 lwz        83C100D8   1     L4A       gr30=#stack(gr1,216)                                                                                            0| 006890 stw        93410098   1     ST4A       #stack(gr1,152)=gr26
    0| 006774 lwz        83A100D4   1     L4A       gr29=#stack(gr1,212)                                                                                          401| 006894 lwz        80620004   1     L4A        gr3=._Py_RefTotal(gr2,0)
 1276| 006778 addi       382100E0   1     AI        gr1=gr1,224                                                                                                   118| 006898 stw        90410014   1     ST4A       #cur_toc(gr1,20)=gr2
    0| 00677C lwz        80010008   1     L4A       gr0=#stack(gr1,8)                                                                                            1252| 00689C stw        901E0034   1     ST4A       (*)aggr#4.ag_hooks_inited(gr30,52)=gr0
    0| 006780 mtspr      7C0803A6   2     LLR       lr=gr0                                                                                                       1262| 0068A0 lwz        83440078   1     L4A        gr26=(*)_ts._ts.async_gen_firstiter(gr4,120)
 1276| 006784 bclr       4E800020   3     BA        lr                                                                                                            401| 0068A4 ori        607F0000   1     LR         gr31=gr3
     |               Tag Table                                                                                                                                   1256| 0068A8 lwz        8084007C   1     L4A        gr4=(*)_ts._ts.async_gen_finalizer(gr4,124)
     | 006788        00000000 00002041 80050100 00000000 00000348 001D6173                                                                                        401| 0068AC lwz        80A30000   1     L4A        gr5=_Py_RefTotal(gr3,0)
     | 0067A0        796E635F 67656E5F 696E6974 5F686F6F 6B734041 46313233                                                                                          0| 0068B0 ori        63460000   1     LR         gr6=gr26
     | 0067B8        5F3231                                                                                                                                      1263| 0068B4 cmpwi      2C860000   1     C4         cr1=gr6,0
     |               Instruction count          210                                                                                                               401| 0068B8 addi       38050001   1     AI         gr0=gr5,1
     |               Straight-line exec time    214                                                                                                                 0| 0068BC ori        60850000   1     LR         gr5=gr4
 GPR's set/used:   ssus ssss ssss s---  ---- ---- ---- ----                                                                                                      1257| 0068C0 cmpwi      2F050000   1     C4         cr6=gr5,0
 FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----                                                                                                      1257| 0068C4 bc         419A0018   1     BT         CL.141,cr6,0x4/eq,taken=30%(30,70)







Wed Apr 15 07:30:04 CDT 2020  Page 182


 CCR's set/used:   ss-- -sss                                                                                                                                      401| 0068C8 stw        90030000   2     ST4A       _Py_RefTotal(gr3,0)=gr0
     | 000000                             PDEF     coro_wrapper_traverse at AF124_25                                                                                1259| 0068CC stw        909E0030   1     ST4A       (*)aggr#4.ag_finalizer(gr30,48)=gr4
 1048|                                    PROC      cw,visit,arg,gr3-gr5                                                                                          403| 0068D0 lwz        80640000   1     L4A        gr3=(*)_object._object.ob_refcnt(gr4,0)
    0| 0067C0 mfspr      7C0802A6   1     LFLR      gr0=lr                                                                                                        403| 0068D4 addi       38030001   2     AI         gr0=gr3,1
 1050| 0067C4 lwz        80630008   1     L4A       gr3=(*)aggr#A.cw_coroutine(gr3,8)                                                                             403| 0068D8 stw        90040000   1     ST4A       (*)_object._object.ob_refcnt(gr4,0)=gr0
    0| 0067C8 ori        60860000   1     LR        gr6=gr4                                                                                                      1260|                                CL.141:
 1050| 0067CC ori        60A40000   1     LR        gr4=gr5                                                                                                       401| 0068DC lwz        807F0000   1     L4A        gr3=_Py_RefTotal(gr31,0)
    0| 0067D0 stw        90010008   1     ST4A      #stack(gr1,8)=gr0                                                                                             403| 0068E0 lwz        80DA0000   1     L4A        gr6=(*)_object._object.ob_refcnt(gr26,0)
 1050| 0067D4 lwz        81660008   1     L4A       gr11=#new_env(gr6,8)                                                                                         1263| 0068E4 bc         418603CC   0     BT         CL.2275,cr1,0x4/eq,taken=30%(30,70)
 1050| 0067D8 lwz        80060000   1     L4A       gr0=#fnc_adr(gr6,0)                                                                                           183| 0068E8 addi       38A000B7   2     LI         gr5=183
    0| 0067DC stwu       9421FFB0   1     ST4U      gr1,#stack(gr1,-80)=gr1                                                                                       183| 0068EC lwz        80820018   1     L4A        gr4=.+CONSTANT_AREA(gr2,0)
 1050| 0067E0 mtspr      7C0903A6   1     LCTR      ctr=gr0                                                                                                       401| 0068F0 addi       38030001   1     AI         gr0=gr3,1
 1050| 0067E4 stw        90410014   1     ST4A      #cur_toc(gr1,20)=gr2                                                                                          401| 0068F4 stw        901F0000   1     ST4A       _Py_RefTotal(gr31,0)=gr0
 1050| 0067E8 lwz        80460004   1     CALL      gr3=gr6,2,(*)_object",gr3,(*)void",gr4,#ProcAlias",fcr",(*)int()",gr1,cr[01567]",gr0",gr4"-gr12",fp0"-fp13"   403| 0068F8 addi       38C60001   1     AI         gr6=gr6,1
 1050| 0067EC bcctrl     4E800421   0                                                                                                                             403| 0068FC stw        90DA0000   1     ST4A       (*)_object._object.ob_refcnt(gr26,0)=gr6
 1050| 0067F0 lwz        80410014   1                                                                                                                             183| 006900 bc         40820374   0     BF         CL.1852,cr0,0x4/eq,taken=50%(0,0)
 1050| 0067F4 cmpwi      2C030000   1     C4        cr0=gr3,0                                                                                                     183| 006904 addi       38641168   2     AI         gr3=gr4,4456
 1050| 0067F8 bc         40820018   1     BF        CL.2223,cr0,0x4/eq,taken=50%(0,0)                                                                             183| 006908 addi       38841174   1     AI         gr4=gr4,4468
 1051| 0067FC addi       38600000   2     LI        gr3=0                                                                                                         183| 00690C bl         4BFF96F5   0     CALL       __assert,3,gr3-gr5,#ProcAlias",__assert",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",lr",fcr",xer",
    0| 006800 lwz        80010058   1     L4A       gr0=#stack(gr1,88)                                                                                            183| 006910 ori        60000000   1
 1052| 006804 addi       38210050   1     AI        gr1=gr1,80                                                                                                    185| 006914 stw        93C1008C   1     ST4A       _args(gr1,140)=gr30
    0| 006808 mtspr      7C0803A6   1     LLR       lr=gr0                                                                                                        186| 006918 bl         4BFF96E9   0     CALL       gr3=PyThreadState_Get,0,#ProcAlias",PyThreadState_Get",fcr",gr1,cr[01567]",gr0",gr4"-gr12",fp0"-fp13",mq",
 1052| 00680C bclr       4E800020   3     BA        lr                                                                                                            186| 00691C ori        60000000   1
    0|                                CL.2223:                                                                                                                    187| 006920 addis      3C808000   1     LIU        gr4=32768
    0| 006810 lwz        80010058   1     L4A       gr0=#stack(gr1,88)                                                                                             72| 006924 cmpwi      2C1A0000   1     C4         cr0=gr26,0
 1052| 006814 addi       38210050   1     AI        gr1=gr1,80                                                                                                    188| 006928 ori        607E0000   1     LR         gr30=gr3
    0| 006818 mtspr      7C0803A6   1     LLR       lr=gr0                                                                                                        187| 00692C addi       3BA40001   1     AI         gr29=gr4,1
 1052| 00681C bclr       4E800020   3     BA        lr                                                                                                             72| 006930 bc         40820328   0     BF         CL.1855,cr0,0x4/eq,taken=50%(0,0)
     |               Tag Table                                                                                                                                      0|                                CL.1853:
     | 006820        00000000 00002041 80000300 00000000 00000060 001E636F                                                                                         72| 006934 addi       38A00048   1     LI         gr5=72
     | 006838        726F5F77 72617070 65725F74 72617665 72736540 41463132                                                                                         72| 006938 lwz        80620018   1     L4A        gr3=.+CONSTANT_AREA(gr2,0)
     | 006850        345F3235                                                                                                                                      72| 00693C addi       38831174   2     AI         gr4=gr3,4468
     |               Instruction count           24                                                                                                                72| 006940 addi       38631194   1     AI         gr3=gr3,4500
     |               Straight-line exec time     28                                                                                                                72| 006944 bl         4BFF96BD   0     CALL       __assert,3,gr3-gr5,#ProcAlias",__assert",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",lr",fcr",xer",
 GPR's set/used:   ssus ssss ssss s---  ---- ---- ---- ssss                                                                                                        72| 006948 ori        60000000   1
 FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----                                                                                                        73| 00694C lwz        839A0004   1     L4A        gr28=(*)_object._object.ob_type(gr26,4)
 CCR's set/used:   ss-- -sss                                                                                                                                      617| 006950 ori        63830000   2     LR         gr3=gr28
     | 000000                             PDEF     _PyGen_Finalize at AF125_92                                                                                       617| 006954 bl         4BFF96AD   0     CALL       gr3=PyType_GetFlags,1,(*)_typeobject",gr3,#ProcAlias",PyType_GetFlags",fcr",gr1,cr[01567]",gr0",gr4"-gr12"
   43|                                    PROC      self,gen,res,gr3-gr5                                                                                          617| 006958 ori        60000000   1
    0| 006860 mfspr      7C0802A6   1     LFLR      gr0=lr                                                                                                         74| 00695C andi.      70600800   1     RN4_R      gr0,cr0=gr3,0,0x800
    0| 006864 ori        60860000   1     LR        gr6=gr4                                                                                                        74| 006960 bc         40820178   1     BF         CL.1373,cr0,0x4/eq,taken=50%(0,0)
    0| 006868 stw        90010008   1     ST4A      #stack(gr1,8)=gr0                                                                                               0|                                CL.2291:
    0| 00686C stw        93E1FFFC   1     ST4A      #stack(gr1,-4)=gr31                                                                                           116| 006964 ori        63C30000   1     LR         gr3=gr30
    0| 006870 ori        607F0000   1     LR        gr31=gr3                                                                                                      116| 006968 ori        63440000   1     LR         gr4=gr26
    0| 006874 stw        93C1FFF8   1     ST4A      #stack(gr1,-8)=gr30                                                                                           116| 00696C addi       38A1008C   1     AI         gr5=gr1,140
    0| 006878 stw        93A1FFF4   1     ST4A      #stack(gr1,-12)=gr29                                                                                            0| 006970 lwz        838100A0   1     L4A        gr28=#stack(gr1,160)
    0| 00687C stw        9381FFF0   1     ST4A      #stack(gr1,-16)=gr28                                                                                          116| 006974 addi       38C00001   1     LI         gr6=1
   54| 006880 lwz        800200E0   1     L4A       gr0=.PyAsyncGen_Type(gr2,0)                                                                                   116| 006978 addi       38E00000   1     LI         gr7=0
    0| 006884 stwu       9421FF20   1     ST4U      gr1,#stack(gr1,-224)=gr1                                                                                      116| 00697C bl         4BFF9685   0     CALL       gr3=_PyObject_MakeTpCall,5,(*)_ts",gr3,(*)_object",gr4,(*)_object*C",gr5,gr6,(*)_object",gr7,#ProcAlias",(
  128| 006888 lwz        80FF0004   1     L4A       gr7=(*)C_object._object.ob_type(gr31,4)                                                                       116| 006980 ori        60000000   1
   75| 00688C addi       38A10050   1     AI        gr5=gr1,80                                                                                                    116| 006984 ori        607D0000   1     LR         gr29=gr3
   75| 006890 addi       38810054   1     AI        gr4=gr1,84                                                                                                    417| 006988 lwz        807A0000   1     L4A        gr3=(*)_object._object.ob_refcnt(gr26,0)
   75| 006894 addi       38610058   1     AI        gr3=gr1,88                                                                                                    415| 00698C lwz        809F0000   1     L4A        gr4=_Py_RefTotal(gr31,0)
  128| 006898 cmplw      7C070040   1     CL4       cr0=gr7,gr0                                                                                                     0| 006990 lwz        80A20018   1     L4A        gr5=.+CONSTANT_AREA(gr2,0)
  118| 00689C stw        90410014   1     ST4A      #cur_toc(gr1,20)=gr2                                                                                          417| 006994 addi       3803FFFF   1     AI         gr0=gr3,-1
   54| 0068A0 bc         40820250   0     BF        CL.540,cr0,0x4/eq,taken=40%(40,60)                                                                            417| 006998 stw        901A0000   1     ST4A       (*)_object._object.ob_refcnt(gr26,0)=gr0







Wed Apr 15 07:30:04 CDT 2020  Page 183


   56| 0068A4 lwz        83DF0030   2     L4A       gr30=(*)aggr#4.ag_finalizer(gr31,48)                                                                          415| 00699C addi       3864FFFF   1     AI         gr3=gr4,-1
   57| 0068A8 cmpwi      2C1E0000   2     C4        cr0=gr30,0                                                                                                    415| 0069A0 stw        907F0000   1     ST4A       _Py_RefTotal(gr31,0)=gr3
   57| 0068AC bc         41820240   1     BT        CL.2063,cr0,0x4/eq,taken=40%(40,60)                                                                           408| 0069A4 addi       3BC51110   1     AI         gr30=gr5,4368
   57| 0068B0 lwz        801F0038   1     L4A       gr0=(*)aggr#4.ag_closed(gr31,56)                                                                              417| 0069A8 cmpwi      2C000000   1     C4         cr0=gr0,0
   57| 0068B4 cmpwi      2C000000   2     C4        cr0=gr0,0                                                                                                     417| 0069AC bc         41820118   1     BT         CL.1387,cr0,0x4/eq,taken=40%(40,60)
   57| 0068B8 bc         40820234   1     BF        CL.2063,cr0,0x4/eq,taken=50%(0,0)                                                                             419| 0069B0 bc         408000E8   1     BF         CL.2277,cr0,0x1/lt,taken=50%(0,0)
   59| 0068BC bl         4BFF9745   1     CALL      PyErr_Fetch,3,(*)_object*",gr3,(*)_object*",gr4,(*)_object*",gr5,#ProcAlias",(*)_object",(*)_object",(*)_ob     0|                                CL.1863:
   59| 0068C0 ori        60000000   1                                                                                                                             420| 0069B4 ori        63C30000   1     LR         gr3=gr30
  183| 0068C4 cmpwi      2C1F0000   1     C4        cr0=gr31,0                                                                                                    420| 0069B8 addi       388004F4   1     LI         gr4=1268
  183| 0068C8 bc         41820208   1     BT        CL.2066,cr0,0x4/eq,taken=40%(40,60)                                                                           420| 0069BC ori        63450000   1     LR         gr5=gr26
  183|                                CL.1044:                                                                                                                    420| 0069C0 bl         4BFF9641   0     CALL       _Py_NegativeRefcount,3,(*)Cuchar",gr3,gr4,(*)_object",gr5,#ProcAlias",_Py_NegativeRefcount",fcr",gr1,cr[01
  185| 0068CC stw        93E100BC   1     ST4A      _args(gr1,188)=gr31                                                                                           420| 0069C4 ori        60000000   1
  186| 0068D0 bl         4BFF9731   0     CALL      gr3=PyThreadState_Get,0,#ProcAlias",PyThreadState_Get",fcr",gr1,cr[01567]",gr0",gr4"-gr12",fp0"-fp13",mq",l  1269| 0069C8 cmpwi      2C1D0000   1     C4         cr0=gr29,0
  186| 0068D4 ori        60000000   1                                                                                                                            1269| 0069CC bc         418200A8   1     BT         CL.2286,cr0,0x4/eq,taken=30%(30,70)
  186| 0068D8 ori        607C0000   1     LR        gr28=gr3                                                                                                        0| 0069D0 lwz        83410098   2     L4A        gr26=#stack(gr1,152)
   73| 0068DC lwz        83BE0004   1     L4A       gr29=(*)_object._object.ob_type(gr30,4)                                                                      1271|                                CL.143:
  617| 0068E0 ori        63A30000   2     LR        gr3=gr29                                                                                                      417| 0069D4 lwz        807D0000   1     L4A        gr3=(*)_object._object.ob_refcnt(gr29,0)
  617| 0068E4 bl         4BFF971D   0     CALL      gr3=PyType_GetFlags,1,(*)_typeobject",gr3,#ProcAlias",PyType_GetFlags",fcr",gr1,cr[01567]",gr0",gr4"-gr12",   415| 0069D8 lwz        809F0000   1     L4A        gr4=_Py_RefTotal(gr31,0)
  617| 0068E8 ori        60000000   1                                                                                                                             417| 0069DC addi       3803FFFF   1     AI         gr0=gr3,-1
   74| 0068EC andi.      70600800   1     RN4_R     gr0,cr0=gr3,0,0x800                                                                                           417| 0069E0 stw        901D0000   1     ST4A       (*)_object._object.ob_refcnt(gr29,0)=gr0
   77| 0068F0 ori        63C30000   1     LR        gr3=gr30                                                                                                      415| 0069E4 addi       3864FFFF   1     AI         gr3=gr4,-1
   74| 0068F4 bc         41820178   0     BT        CL.2062,cr0,0x4/eq,taken=50%(0,0)                                                                             415| 0069E8 stw        907F0000   1     ST4A       _Py_RefTotal(gr31,0)=gr3
   77| 0068F8 bl         4BFF9709   1     CALL      gr3=PyCallable_Check,1,(*)_object",gr3,#ProcAlias",PyCallable_Check",fcr",gr1,cr[01567]",gr0",gr4"-gr12",fp   417| 0069EC cmpwi      2C000000   1     C4         cr0=gr0,0
   77| 0068FC ori        60000000   1                                                                                                                             417| 0069F0 bc         41820058   1     BT         CL.1391,cr0,0x4/eq,taken=40%(40,60)
   77| 006900 cmpwi      2C030000   1     C4        cr0=gr3,0                                                                                                       0| 0069F4 lwz        83E100AC   2     L4A        gr31=#stack(gr1,172)
   77| 006904 bc         418201B0   1     BT        CL.2067,cr0,0x4/eq,taken=40%(40,60)                                                                           419| 0069F8 bc         41800020   0     BT         CL.2287,cr0,0x1/lt,taken=40%(40,60)
   77|                                CL.1063:                                                                                                                   1275| 0069FC addi       38600000   2     LI         gr3=0
   78| 006908 lwz        83BD001C   1     L4A       gr29=(*)_typeobject._typeobject.tp_vectorcall_offset(gr29,28)                                                   0| 006A00 lwz        83C100A8   1     L4A        gr30=#stack(gr1,168)
    0| 00690C or.        7FA0EB79   2     LR_R      gr0,cr0=gr29                                                                                                    0| 006A04 lwz        83A100A4   1     L4A        gr29=#stack(gr1,164)
   79| 006910 bc         40810188   1     BF        CL.2068,cr0,0x2/gt,taken=40%(40,60)                                                                             0| 006A08 lwz        800100B8   1     L4A        gr0=#stack(gr1,184)
   79|                                CL.1065:                                                                                                                   1276| 006A0C addi       382100B0   1     AI         gr1=gr1,176
  118| 006914 ori        63C30000   1     LR        gr3=gr30                                                                                                        0| 006A10 mtspr      7C0803A6   1     LLR        lr=gr0
   81| 006918 lwzx       7CFEE82E   1     L4A       gr7=(*)_object*()*(gr30,gr29,0)                                                                              1276| 006A14 bclr       4E800020   3     BA         lr
  118| 00691C addis      3CC08000   1     LIU       gr6=32768                                                                                                       0|                                CL.2287:
  118| 006920 addi       388100BC   1     AI        gr4=gr1,188                                                                                                   420| 006A18 ori        63C30000   1     LR         gr3=gr30
  118| 006924 addi       38A60001   1     AI        gr5=gr6,1                                                                                                     420| 006A1C addi       388004F8   1     LI         gr4=1272
    0| 006928 or.        7CE03B79   1     LR_R      gr0,cr0=gr7                                                                                                   420| 006A20 ori        63A50000   1     LR         gr5=gr29
  118| 00692C addi       38C00000   1     LI        gr6=0                                                                                                         420| 006A24 bl         4BFF95DD   0     CALL       _Py_NegativeRefcount,3,(*)Cuchar",gr3,gr4,(*)_object",gr5,#ProcAlias",_Py_NegativeRefcount",fcr",gr1,cr[01
  114| 006930 bc         4182013C   0     BT        CL.2062,cr0,0x4/eq,taken=30%(30,70)                                                                           420| 006A28 ori        60000000   1
    0| 006934 lwz        83A100D4   2     L4A       gr29=#stack(gr1,212)                                                                                         1275| 006A2C addi       38600000   1     LI         gr3=0
  118| 006938 lwz        80070000   1     L4A       gr0=#fnc_adr(gr7,0)                                                                                             0| 006A30 lwz        83C100A8   1     L4A        gr30=#stack(gr1,168)
  118| 00693C lwz        81670008   1     L4A       gr11=#new_env(gr7,8)                                                                                            0| 006A34 lwz        83A100A4   1     L4A        gr29=#stack(gr1,164)
  118| 006940 mtspr      7C0903A6   1     LCTR      ctr=gr0                                                                                                         0| 006A38 lwz        800100B8   1     L4A        gr0=#stack(gr1,184)
  118| 006944 lwz        80470004   1     CALL      gr3=gr7,4,(*)_object",gr3,(*)_object*C",gr4,gr5,(*)_object",gr6,#ProcAlias",(*)_object",fcr",(*)_object*()"  1276| 006A3C addi       382100B0   1     AI         gr1=gr1,176
  118| 006948 bcctrl     4E800421   0                                                                                                                               0| 006A40 mtspr      7C0803A6   1     LLR        lr=gr0
  118| 00694C lwz        80410014   1                                                                                                                            1276| 006A44 bclr       4E800020   3     BA         lr
  118| 006950 ori        60650000   1     LR        gr5=gr3                                                                                                       423|                                CL.1391:
  119| 006954 ori        63830000   1     LR        gr3=gr28                                                                                                      425| 006A48 ori        63A30000   1     LR         gr3=gr29
  119| 006958 addi       38C00000   1     LI        gr6=0                                                                                                           0| 006A4C lwz        83E100AC   1     L4A        gr31=#stack(gr1,172)
  119| 00695C ori        63C40000   1     LR        gr4=gr30                                                                                                        0| 006A50 lwz        83C100A8   1     L4A        gr30=#stack(gr1,168)
  119| 006960 bl         4BFF96A1   0     CALL      gr3=_Py_CheckFunctionResult,4,(*)_ts",gr3,(*)_object",gr4,(*)_object",gr5,(*)Cuchar",gr6,#ProcAlias",_Py_Ch   425| 006A54 bl         4BFF95AD   0     CALL       _Py_Dealloc,1,(*)_object",gr3,#ProcAlias",_Py_Dealloc",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",
  119| 006964 ori        60000000   1                                                                                                                             425| 006A58 ori        60000000   1
    0| 006968 lwz        838100D0   1     L4A       gr28=#stack(gr1,208)                                                                                         1275| 006A5C addi       38600000   1     LI         gr3=0
    0| 00696C lwz        83C100D8   1     L4A       gr30=#stack(gr1,216)                                                                                            0| 006A60 lwz        83A100A4   1     L4A        gr29=#stack(gr1,164)
  188|                                CL.1069:                                                                                                                      0| 006A64 lwz        800100B8   1     L4A        gr0=#stack(gr1,184)
   63| 006970 cmpwi      2C030000   1     C4        cr0=gr3,0                                                                                                    1276| 006A68 addi       382100B0   1     AI         gr1=gr1,176







Wed Apr 15 07:30:04 CDT 2020  Page 184


    0| 006974 lwz        80E20018   1     L4A       gr7=.+CONSTANT_AREA(gr2,0)                                                                                      0| 006A6C mtspr      7C0803A6   1     LLR        lr=gr0
  415| 006978 lwz        80C20004   1     L4A       gr6=._Py_RefTotal(gr2,0)                                                                                     1276| 006A70 bclr       4E800020   3     BA         lr
   61| 00697C ori        60650000   1     LR        gr5=gr3                                                                                                         0|                                CL.2286:
   63| 006980 bc         418200B8   0     BT        CL.1973,cr0,0x4/eq,taken=40%(40,60)                                                                          1270| 006A74 addi       38600001   1     LI         gr3=1
  408| 006984 addi       38800042   2     LI        gr4=66                                                                                                          0| 006A78 lwz        83E100AC   1     L4A        gr31=#stack(gr1,172)
  408| 006988 addi       38071110   1     AI        gr0=gr7,4368                                                                                                    0| 006A7C lwz        83C100A8   1     L4A        gr30=#stack(gr1,168)
    0| 00698C lwz        83E100DC   1     L4A       gr31=#stack(gr1,220)                                                                                            0| 006A80 lwz        83410098   1     L4A        gr26=#stack(gr1,152)
  417| 006990 lwz        80E30000   1     L4A       gr7=(*)_object._object.ob_refcnt(gr3,0)                                                                         0| 006A84 lwz        83A100A4   1     L4A        gr29=#stack(gr1,164)
  415| 006994 lwz        81060000   1     L4A       gr8=<s117:d0:l4>(gr6,0)                                                                                         0| 006A88 lwz        800100B8   1     L4A        gr0=#stack(gr1,184)
  417| 006998 addi       38E7FFFF   1     AI        gr7=gr7,-1                                                                                                   1276| 006A8C addi       382100B0   1     AI         gr1=gr1,176
  417| 00699C stw        90E30000   1     ST4A      (*)_object._object.ob_refcnt(gr3,0)=gr7                                                                         0| 006A90 mtspr      7C0803A6   1     LLR        lr=gr0
  415| 0069A0 addi       3908FFFF   1     AI        gr8=gr8,-1                                                                                                   1276| 006A94 bclr       4E800020   3     BA         lr
  415| 0069A4 stw        91060000   1     ST4A      <s117:d0:l4>(gr6,0)=gr8                                                                                         0|                                CL.2277:
  417| 0069A8 cmpwi      2C070000   1     C4        cr0=gr7,0                                                                                                       0| 006A98 lwz        83410098   1     L4A        gr26=#stack(gr1,152)
  417| 0069AC bc         4182005C   1     BT        CL.1073,cr0,0x4/eq,taken=40%(40,60)                                                                             0|                                CL.1864:
    0| 0069B0 bc         41800028   1     BT        CL.2061,cr0,0x1/lt,taken=40%(40,60)                                                                          1269| 006A9C cmpwi      2C1D0000   1     C4         cr0=gr29,0
   99| 0069B4 lwz        80610058   3     L4A       gr3=error_type(gr1,88)                                                                                       1269| 006AA0 bc         4082FF34   1     BF         CL.143,cr0,0x4/eq,taken=70%(70,30)
   99| 0069B8 lwz        80810054   1     L4A       gr4=error_value(gr1,84)                                                                                      1270| 006AA4 addi       38600001   2     LI         gr3=1
   99| 0069BC lwz        80A10050   1     L4A       gr5=error_traceback(gr1,80)                                                                                     0| 006AA8 lwz        83E100AC   1     L4A        gr31=#stack(gr1,172)
   99| 0069C0 bl         4BFF9641   0     CALL      PyErr_Restore,3,(*)_object",gr3,(*)_object",gr4,(*)_object",gr5,#ProcAlias",PyErr_Restore",fcr",gr1,cr[0156     0| 006AAC lwz        83C100A8   1     L4A        gr30=#stack(gr1,168)
   99| 0069C4 ori        60000000   1                                                                                                                               0| 006AB0 lwz        83A100A4   1     L4A        gr29=#stack(gr1,164)
    0| 0069C8 lwz        800100E8   1     L4A       gr0=#stack(gr1,232)                                                                                             0| 006AB4 lwz        800100B8   1     L4A        gr0=#stack(gr1,184)
  100| 0069CC addi       382100E0   1     AI        gr1=gr1,224                                                                                                  1276| 006AB8 addi       382100B0   1     AI         gr1=gr1,176
    0| 0069D0 mtspr      7C0803A6   1     LLR       lr=gr0                                                                                                          0| 006ABC mtspr      7C0803A6   1     LLR        lr=gr0
  100| 0069D4 bclr       4E800020   3     BA        lr                                                                                                           1276| 006AC0 bclr       4E800020   3     BA         lr
  419|                                CL.2061:                                                                                                                    423|                                CL.1387:
  420| 0069D8 ori        60030000   1     LR        gr3=gr0                                                                                                       425| 006AC4 ori        63430000   1     LR         gr3=gr26
  420| 0069DC bl         4BFF9625   0     CALL      _Py_NegativeRefcount,3,(*)Cuchar",gr3,gr4,(*)_object",gr5,#ProcAlias",_Py_NegativeRefcount",fcr",gr1,cr[015   425| 006AC8 bl         4BFF9539   0     CALL       _Py_Dealloc,1,(*)_object",gr3,#ProcAlias",_Py_Dealloc",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",
  420| 0069E0 ori        60000000   1                                                                                                                             425| 006ACC ori        60000000   1
   99| 0069E4 lwz        80610058   1     L4A       gr3=error_type(gr1,88)                                                                                          0| 006AD0 lwz        83410098   1     L4A        gr26=#stack(gr1,152)
   99| 0069E8 lwz        80810054   1     L4A       gr4=error_value(gr1,84)                                                                                         0| 006AD4 b          4BFFFFC8   0     B          CL.1864,-1
   99| 0069EC lwz        80A10050   1     L4A       gr5=error_traceback(gr1,80)                                                                                    76|                                CL.1373:
   99| 0069F0 bl         4BFF9611   0     CALL      PyErr_Restore,3,(*)_object",gr3,(*)_object",gr4,(*)_object",gr5,#ProcAlias",PyErr_Restore",fcr",gr1,cr[0156    77| 006AD8 ori        63430000   1     LR         gr3=gr26
   99| 0069F4 ori        60000000   1                                                                                                                              77| 006ADC bl         4BFF9525   0     CALL       gr3=PyCallable_Check,1,(*)_object",gr3,#ProcAlias",PyCallable_Check",fcr",gr1,cr[01567]",gr0",gr4"-gr12",f
    0| 0069F8 lwz        800100E8   1     L4A       gr0=#stack(gr1,232)                                                                                            77| 006AE0 ori        60000000   1
  100| 0069FC addi       382100E0   1     AI        gr1=gr1,224                                                                                                    77| 006AE4 cmpwi      2C030000   1     C4         cr0=gr3,0
    0| 006A00 mtspr      7C0803A6   1     LLR       lr=gr0                                                                                                         78| 006AE8 lwz        837C001C   1     L4A        gr27=(*)_typeobject._typeobject.tp_vectorcall_offset(gr28,28)
  100| 006A04 bclr       4E800020   3     BA        lr                                                                                                              0| 006AEC ori        63600000   2     LR         gr0=gr27
  423|                                CL.1073:                                                                                                                     77| 006AF0 bc         41820110   0     BT         CL.1869,cr0,0x4/eq,taken=40%(40,60)
  425| 006A08 ori        60A30000   1     LR        gr3=gr5                                                                                                        79| 006AF4 cmpwi      2C000000   1     C4         cr0=gr0,0
  425| 006A0C bl         4BFF95F5   0     CALL      _Py_Dealloc,1,(*)_object",gr3,#ProcAlias",_Py_Dealloc",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",l     0| 006AF8 lwz        838100A0   1     L4A        gr28=#stack(gr1,160)
  425| 006A10 ori        60000000   1                                                                                                                              79| 006AFC bc         408100DC   0     BF         CL.1860,cr0,0x2/gt,taken=40%(40,60)
   99| 006A14 lwz        80610058   1     L4A       gr3=error_type(gr1,88)                                                                                          0|                                CL.1861:
   99| 006A18 lwz        80810054   1     L4A       gr4=error_value(gr1,84)                                                                                        81| 006B00 lwzx       7CFAD82E   1     L4A        gr7=(*)_object*()*(gr26,gr27,0)
   99| 006A1C lwz        80A10050   1     L4A       gr5=error_traceback(gr1,80)                                                                                     0| 006B04 or.        7CE03B79   2     LR_R       gr0,cr0=gr7
   99| 006A20 bl         4BFF95E1   0     CALL      PyErr_Restore,3,(*)_object",gr3,(*)_object",gr4,(*)_object",gr5,#ProcAlias",PyErr_Restore",fcr",gr1,cr[0156   114| 006B08 bc         4182007C   1     BT         CL.2285,cr0,0x4/eq,taken=30%(30,70)
   99| 006A24 ori        60000000   1                                                                                                                               0|                                CL.2290:
    0| 006A28 lwz        800100E8   1     L4A       gr0=#stack(gr1,232)                                                                                           118| 006B0C ori        63430000   1     LR         gr3=gr26
  100| 006A2C addi       382100E0   1     AI        gr1=gr1,224                                                                                                   118| 006B10 lwz        80070000   1     L4A        gr0=#fnc_adr(gr7,0)
    0| 006A30 mtspr      7C0803A6   1     LLR       lr=gr0                                                                                                        118| 006B14 lwz        81670008   1     L4A        gr11=#new_env(gr7,8)
  100| 006A34 bclr       4E800020   3     BA        lr                                                                                                            118| 006B18 ori        63A50000   1     LR         gr5=gr29
   91|                                CL.1973:                                                                                                                      0| 006B1C lwz        8361009C   1     L4A        gr27=#stack(gr1,156)
   64| 006A38 ori        63E30000   1     LR        gr3=gr31                                                                                                      118| 006B20 addi       3881008C   1     AI         gr4=gr1,140
   64| 006A3C bl         4BFF95C5   0     CALL      PyErr_WriteUnraisable,1,(*)_object",gr3,#ProcAlias",PyErr_WriteUnraisable",fcr",gr1,cr[01567]",gr0",gr3"-gr   118| 006B24 addi       38C00000   1     LI         gr6=0
   64| 006A40 ori        60000000   1                                                                                                                             118| 006B28 mtspr      7C0903A6   1     LCTR       ctr=gr0
   99| 006A44 lwz        80610058   1     L4A       gr3=error_type(gr1,88)                                                                                        118| 006B2C lwz        80470004   1     CALL       gr3=gr7,4,(*)_object",gr3,(*)_object*C",gr4,gr5,(*)_object",gr6,#ProcAlias",(*)_object",fcr",(*)_object*()







Wed Apr 15 07:30:04 CDT 2020  Page 185


   99| 006A48 lwz        80810054   1     L4A       gr4=error_value(gr1,84)                                                                                       118| 006B30 bcctrl     4E800421   0
    0| 006A4C lwz        83E100DC   1     L4A       gr31=#stack(gr1,220)                                                                                          118| 006B34 lwz        80410014   1
   99| 006A50 lwz        80A10050   1     L4A       gr5=error_traceback(gr1,80)                                                                                   118| 006B38 ori        60650000   1     LR         gr5=gr3
   99| 006A54 bl         4BFF95AD   0     CALL      PyErr_Restore,3,(*)_object",gr3,(*)_object",gr4,(*)_object",gr5,#ProcAlias",PyErr_Restore",fcr",gr1,cr[0156   119| 006B3C ori        63C30000   1     LR         gr3=gr30
   99| 006A58 ori        60000000   1                                                                                                                             119| 006B40 addi       38C00000   1     LI         gr6=0
    0| 006A5C lwz        800100E8   1     L4A       gr0=#stack(gr1,232)                                                                                           119| 006B44 ori        63440000   1     LR         gr4=gr26
  100| 006A60 addi       382100E0   1     AI        gr1=gr1,224                                                                                                   119| 006B48 bl         4BFF94B9   0     CALL       gr3=_Py_CheckFunctionResult,4,(*)_ts",gr3,(*)_object",gr4,(*)_object",gr5,(*)Cuchar",gr6,#ProcAlias",_Py_C
    0| 006A64 mtspr      7C0803A6   1     LLR       lr=gr0                                                                                                        119| 006B4C ori        60000000   1
  100| 006A68 bclr       4E800020   3     BA        lr                                                                                                            119| 006B50 ori        607D0000   1     LR         gr29=gr3
    0|                                CL.2062:                                                                                                                    417| 006B54 lwz        807A0000   1     L4A        gr3=(*)_object._object.ob_refcnt(gr26,0)
  116| 006A6C ori        63830000   1     LR        gr3=gr28                                                                                                      415| 006B58 lwz        809F0000   1     L4A        gr4=_Py_RefTotal(gr31,0)
  116| 006A70 ori        63C40000   1     LR        gr4=gr30                                                                                                        0| 006B5C lwz        80A20018   1     L4A        gr5=.+CONSTANT_AREA(gr2,0)
  116| 006A74 addi       38A100BC   1     AI        gr5=gr1,188                                                                                                   417| 006B60 addi       3803FFFF   1     AI         gr0=gr3,-1
    0| 006A78 lwz        83A100D4   1     L4A       gr29=#stack(gr1,212)                                                                                          417| 006B64 stw        901A0000   1     ST4A       (*)_object._object.ob_refcnt(gr26,0)=gr0
  116| 006A7C addi       38C00001   1     LI        gr6=1                                                                                                         415| 006B68 addi       3864FFFF   1     AI         gr3=gr4,-1
  116| 006A80 addi       38E00000   1     LI        gr7=0                                                                                                         415| 006B6C stw        907F0000   1     ST4A       _Py_RefTotal(gr31,0)=gr3
  116| 006A84 bl         4BFF957D   0     CALL      gr3=_PyObject_MakeTpCall,5,(*)_ts",gr3,(*)_object",gr4,(*)_object*C",gr5,gr6,(*)_object",gr7,#ProcAlias",(*   408| 006B70 addi       3BC51110   1     AI         gr30=gr5,4368
  116| 006A88 ori        60000000   1                                                                                                                             417| 006B74 cmpwi      2C000000   1     C4         cr0=gr0,0
    0| 006A8C lwz        838100D0   1     L4A       gr28=#stack(gr1,208)                                                                                          417| 006B78 bc         4182FF4C   1     BT         CL.1387,cr0,0x4/eq,taken=40%(40,60)
    0| 006A90 lwz        83C100D8   1     L4A       gr30=#stack(gr1,216)                                                                                          419| 006B7C bc         4180FE38   1     BT         CL.1863,cr0,0x1/lt,taken=40%(40,60)
  116| 006A94 b          4BFFFEDC   0     B         CL.1069,-1                                                                                                      0| 006B80 b          4BFFFF18   2     B          CL.2277,-1
    0|                                CL.2068:                                                                                                                      0|                                CL.2285:
   79| 006A98 addi       38A0004F   1     LI        gr5=79                                                                                                        116| 006B84 ori        63C30000   1     LR         gr3=gr30
   79| 006A9C lwz        80620018   1     L4A       gr3=.+CONSTANT_AREA(gr2,0)                                                                                    116| 006B88 ori        63440000   1     LR         gr4=gr26
   79| 006AA0 addi       38831174   2     AI        gr4=gr3,4468                                                                                                  116| 006B8C addi       38A1008C   1     AI         gr5=gr1,140
   79| 006AA4 addi       386311C4   1     AI        gr3=gr3,4548                                                                                                    0| 006B90 lwz        8361009C   1     L4A        gr27=#stack(gr1,156)
   79| 006AA8 bl         4BFF9559   0     CALL      __assert,3,gr3-gr5,#ProcAlias",__assert",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",lr",fcr",xer",f   116| 006B94 addi       38C00001   1     LI         gr6=1
   79| 006AAC ori        60000000   1                                                                                                                             116| 006B98 addi       38E00000   1     LI         gr7=0
    0| 006AB0 b          4BFFFE64   0     B         CL.1065,-1                                                                                                    116| 006B9C bl         4BFF9465   0     CALL       gr3=_PyObject_MakeTpCall,5,(*)_ts",gr3,(*)_object",gr4,(*)_object*C",gr5,gr6,(*)_object",gr7,#ProcAlias",(
    0|                                CL.2067:                                                                                                                    116| 006BA0 ori        60000000   1
   77| 006AB4 addi       38A0004D   1     LI        gr5=77                                                                                                        116| 006BA4 ori        607D0000   1     LR         gr29=gr3
   77| 006AB8 lwz        80620018   1     L4A       gr3=.+CONSTANT_AREA(gr2,0)                                                                                    417| 006BA8 lwz        807A0000   1     L4A        gr3=(*)_object._object.ob_refcnt(gr26,0)
   77| 006ABC addi       38831174   2     AI        gr4=gr3,4468                                                                                                  415| 006BAC lwz        809F0000   1     L4A        gr4=_Py_RefTotal(gr31,0)
   77| 006AC0 addi       386311A8   1     AI        gr3=gr3,4520                                                                                                    0| 006BB0 lwz        80A20018   1     L4A        gr5=.+CONSTANT_AREA(gr2,0)
   77| 006AC4 bl         4BFF953D   0     CALL      __assert,3,gr3-gr5,#ProcAlias",__assert",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",lr",fcr",xer",f   417| 006BB4 addi       3803FFFF   1     AI         gr0=gr3,-1
   77| 006AC8 ori        60000000   1                                                                                                                             417| 006BB8 stw        901A0000   1     ST4A       (*)_object._object.ob_refcnt(gr26,0)=gr0
    0| 006ACC b          4BFFFE3C   0     B         CL.1063,-1                                                                                                    415| 006BBC addi       3864FFFF   1     AI         gr3=gr4,-1
    0|                                CL.2066:                                                                                                                    415| 006BC0 stw        907F0000   1     ST4A       _Py_RefTotal(gr31,0)=gr3
  183| 006AD0 addi       38A000B7   1     LI        gr5=183                                                                                                       408| 006BC4 addi       3BC51110   1     AI         gr30=gr5,4368
  183| 006AD4 lwz        80620018   1     L4A       gr3=.+CONSTANT_AREA(gr2,0)                                                                                    417| 006BC8 cmpwi      2C000000   1     C4         cr0=gr0,0
  183| 006AD8 addi       38831174   2     AI        gr4=gr3,4468                                                                                                  417| 006BCC bc         4182FEF8   1     BT         CL.1387,cr0,0x4/eq,taken=40%(40,60)
  183| 006ADC addi       38631168   1     AI        gr3=gr3,4456                                                                                                    0| 006BD0 bc         4080FEC8   1     BF         CL.2277,cr0,0x1/lt,taken=50%(0,0)
  183| 006AE0 bl         4BFF9521   0     CALL      __assert,3,gr3-gr5,#ProcAlias",__assert",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",lr",fcr",xer",f     0| 006BD4 b          4BFFFDE0   2     B          CL.1863,-1
  183| 006AE4 ori        60000000   1                                                                                                                               0|                                CL.1860:
    0| 006AE8 b          4BFFFDE4   0     B         CL.1044,-1                                                                                                     79| 006BD8 addi       38A0004F   1     LI         gr5=79
    0|                                CL.2063:                                                                                                                     79| 006BDC lwz        80620018   1     L4A        gr3=.+CONSTANT_AREA(gr2,0)
    0| 006AEC lwz        83C100D8   1     L4A       gr30=#stack(gr1,216)                                                                                           79| 006BE0 addi       38831174   2     AI         gr4=gr3,4468
   72|                                CL.540:                                                                                                                      79| 006BE4 addi       386311C4   1     AI         gr3=gr3,4548
   72| 006AF0 stw        90C100C4   1     ST4A      #parameter_store0(gr1,196)=gr6                                                                                 79| 006BE8 bl         4BFF9419   0     CALL       __assert,3,gr3-gr5,#ProcAlias",__assert",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",lr",fcr",xer",
   75| 006AF4 bl         4BFF950D   0     CALL      PyErr_Fetch,3,(*)_object*",gr3,(*)_object*",gr4,(*)_object*",gr5,#ProcAlias",(*)_object",(*)_object",(*)_ob    79| 006BEC ori        60000000   1
   75| 006AF8 ori        60000000   1                                                                                                                              81| 006BF0 lwzx       7CFAD82E   1     L4A        gr7=(*)_object*()*(gr26,gr27,0)
   86| 006AFC addi       38800000   1     LI        gr4=0                                                                                                           0| 006BF4 or.        7CE03B79   2     LR_R       gr0,cr0=gr7
   75| 006B00 lwz        80C100C4   1     L4A       gr6=#parameter_store0(gr1,196)                                                                                114| 006BF8 bc         4182FF8C   1     BT         CL.2285,cr0,0x4/eq,taken=30%(30,70)
   86| 006B04 ori        60C30000   2     LR        gr3=gr6                                                                                                         0| 006BFC b          4BFFFF10   1     B          CL.2290,-1
   79| 006B08 lwz        80A60010   1     L4A       gr5=(*)aggr#3.gi_code(gr6,16)                                                                                   0|                                CL.1869:
    0| 006B0C or.        7CA02B79   2     LR_R      gr0,cr0=gr5                                                                                                    77| 006C00 addi       38A0004D   1     LI         gr5=77







Wed Apr 15 07:30:04 CDT 2020  Page 186


   79| 006B10 bc         41820020   1     BT        CL.544,cr0,0x4/eq,taken=30%(30,70)                                                                             77| 006C04 lwz        80620018   1     L4A        gr3=.+CONSTANT_AREA(gr2,0)
   80| 006B14 lwz        8005001C   1     L4A       gr0=(*)aggr#5.co_flags(gr5,28)                                                                                 77| 006C08 addi       38831174   2     AI         gr4=gr3,4468
   80| 006B18 andi.      70000080   2     RN4_R     gr0,cr0=gr0,0,0x80                                                                                             77| 006C0C addi       386311A8   1     AI         gr3=gr3,4520
   80| 006B1C bc         41820014   1     BT        CL.544,cr0,0x4/eq,taken=40%(40,60)                                                                             77| 006C10 bl         4BFF93F1   0     CALL       __assert,3,gr3-gr5,#ProcAlias",__assert",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",lr",fcr",xer",
   81| 006B20 lwz        80A60008   1     L4A       gr5=(*)aggr#3.gi_frame(gr6,8)                                                                                  77| 006C14 ori        60000000   1
   81| 006B24 lwz        80050034   2     L4A       gr0=(*)_frame._frame.f_lasti(gr5,52)                                                                           78| 006C18 lwz        837C001C   1     L4A        gr27=(*)_typeobject._typeobject.tp_vectorcall_offset(gr28,28)
   81| 006B28 cmpwi      2C00FFFF   2     C4        cr0=gr0,-1                                                                                                      0| 006C1C or.        7F60DB79   2     LR_R       gr0,cr0=gr27
   81| 006B2C bc         418200A8   1     BT        CL.2071,cr0,0x4/eq,taken=40%(40,60)                                                                            79| 006C20 bc         4081000C   1     BF         CL.2284,cr0,0x2/gt,taken=40%(40,60)
   84|                                CL.544:                                                                                                                       0| 006C24 lwz        838100A0   1     L4A        gr28=#stack(gr1,160)
   86| 006B30 bl         4BFFE211   0     CALL      gr3=gen_close,2,(*)aggr#3",gr3,(*)_object",gr4,#ProcAlias",gen_close",fcr",gr1,cr[01567]",gr0",gr4"-gr12",f     0| 006C28 b          4BFFFED8   0     B          CL.1861,-1
   89| 006B34 cmpwi      2C030000   1     C4        cr0=gr3,0                                                                                                       0|                                CL.2284:
  415| 006B38 lwz        80C20004   1     L4A       gr6=._Py_RefTotal(gr2,0)                                                                                       79| 006C2C addi       38A0004F   1     LI         gr5=79
    0| 006B3C lwz        80820018   1     L4A       gr4=.+CONSTANT_AREA(gr2,0)                                                                                     79| 006C30 lwz        80620018   1     L4A        gr3=.+CONSTANT_AREA(gr2,0)
   86| 006B40 ori        60650000   1     LR        gr5=gr3                                                                                                         0| 006C34 lwz        838100A0   1     L4A        gr28=#stack(gr1,160)
   89| 006B44 bc         41820058   0     BT        CL.1974,cr0,0x4/eq,taken=40%(40,60)                                                                            79| 006C38 addi       38831174   1     AI         gr4=gr3,4468
  417| 006B48 lwz        80E30000   2     L4A       gr7=(*)_object._object.ob_refcnt(gr3,0)                                                                        79| 006C3C addi       386311C4   1     AI         gr3=gr3,4548
    0| 006B4C lwz        83E100DC   1     L4A       gr31=#stack(gr1,220)                                                                                           79| 006C40 bl         4BFF93C1   0     CALL       __assert,3,gr3-gr5,#ProcAlias",__assert",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",lr",fcr",xer",
  408| 006B50 addi       38041110   1     AI        gr0=gr4,4368                                                                                                   79| 006C44 ori        60000000   1
  408| 006B54 addi       3880005F   1     LI        gr4=95                                                                                                         81| 006C48 lwzx       7CFAD82E   1     L4A        gr7=(*)_object*()*(gr26,gr27,0)
  417| 006B58 addi       38E7FFFF   1     AI        gr7=gr7,-1                                                                                                      0| 006C4C or.        7CE03B79   2     LR_R       gr0,cr0=gr7
  415| 006B5C lwz        81060000   1     L4A       gr8=<s117:d0:l4>(gr6,0)                                                                                       114| 006C50 bc         4182FF34   1     BT         CL.2285,cr0,0x4/eq,taken=30%(30,70)
  417| 006B60 stw        90E50000   1     ST4A      (*)_object._object.ob_refcnt(gr5,0)=gr7                                                                         0| 006C54 b          4BFFFEB8   1     B          CL.2290,-1
  415| 006B64 addi       3908FFFF   1     AI        gr8=gr8,-1                                                                                                      0|                                CL.1855:
  415| 006B68 stw        91060000   1     ST4A      <s117:d0:l4>(gr6,0)=gr8                                                                                        73| 006C58 lwz        839A0004   1     L4A        gr28=(*)_object._object.ob_type(gr26,4)
  417| 006B6C cmpwi      2C070000   1     C4        cr0=gr7,0                                                                                                     617| 006C5C ori        63830000   2     LR         gr3=gr28
  417| 006B70 bc         4182FE98   1     BT        CL.1073,cr0,0x4/eq,taken=40%(40,60)                                                                           617| 006C60 bl         4BFF93A1   0     CALL       gr3=PyType_GetFlags,1,(*)_typeobject",gr3,#ProcAlias",PyType_GetFlags",fcr",gr1,cr[01567]",gr0",gr4"-gr12"
  419| 006B74 bc         4180FE64   1     BT        CL.2061,cr0,0x1/lt,taken=40%(40,60)                                                                           617| 006C64 ori        60000000   1
   99| 006B78 lwz        80610058   3     L4A       gr3=error_type(gr1,88)                                                                                         74| 006C68 andi.      70600800   1     RN4_R      gr0,cr0=gr3,0,0x800
   99| 006B7C lwz        80810054   1     L4A       gr4=error_value(gr1,84)                                                                                        74| 006C6C bc         4082FE6C   1     BF         CL.1373,cr0,0x4/eq,taken=40%(40,60)
   99| 006B80 lwz        80A10050   1     L4A       gr5=error_traceback(gr1,80)                                                                                     0| 006C70 b          4BFFFCF4   1     B          CL.2291,-1
   99| 006B84 bl         4BFF947D   0     CALL      PyErr_Restore,3,(*)_object",gr3,(*)_object",gr4,(*)_object",gr5,#ProcAlias",PyErr_Restore",fcr",gr1,cr[0156     0|                                CL.1852:
   99| 006B88 ori        60000000   1                                                                                                                             185| 006C74 stw        93C1008C   1     ST4A       _args(gr1,140)=gr30
    0| 006B8C lwz        800100E8   1     L4A       gr0=#stack(gr1,232)                                                                                           186| 006C78 bl         4BFF9389   0     CALL       gr3=PyThreadState_Get,0,#ProcAlias",PyThreadState_Get",fcr",gr1,cr[01567]",gr0",gr4"-gr12",fp0"-fp13",mq",
  100| 006B90 addi       382100E0   1     AI        gr1=gr1,224                                                                                                   186| 006C7C ori        60000000   1
    0| 006B94 mtspr      7C0803A6   1     LLR       lr=gr0                                                                                                        187| 006C80 addis      3C808000   1     LIU        gr4=32768
  100| 006B98 bclr       4E800020   3     BA        lr                                                                                                             72| 006C84 cmpwi      2C1A0000   1     C4         cr0=gr26,0
    0|                                CL.1974:                                                                                                                    188| 006C88 ori        607E0000   1     LR         gr30=gr3
   90| 006B9C bl         4BFF9465   0     CALL      gr3=PyErr_Occurred,0,#ProcAlias",PyErr_Occurred",fcr",gr1,cr[01567]",gr0",gr4"-gr12",fp0"-fp13",mq",lr",fcr   187| 006C8C addi       3BA40001   1     AI         gr29=gr4,1
   90| 006BA0 ori        60000000   1                                                                                                                              72| 006C90 bc         4182FCA4   0     BT         CL.1853,cr0,0x4/eq,taken=50%(0,0)
   90| 006BA4 cmpwi      2C030000   1     C4        cr0=gr3,0                                                                                                      73| 006C94 lwz        839A0004   2     L4A        gr28=(*)_object._object.ob_type(gr26,4)
   90| 006BA8 bc         4082FE90   1     BF        CL.1973,cr0,0x4/eq,taken=40%(40,60)                                                                           617| 006C98 ori        63830000   2     LR         gr3=gr28
   99| 006BAC lwz        80610058   2     L4A       gr3=error_type(gr1,88)                                                                                        617| 006C9C bl         4BFF9365   0     CALL       gr3=PyType_GetFlags,1,(*)_typeobject",gr3,#ProcAlias",PyType_GetFlags",fcr",gr1,cr[01567]",gr0",gr4"-gr12"
   99| 006BB0 lwz        80810054   1     L4A       gr4=error_value(gr1,84)                                                                                       617| 006CA0 ori        60000000   1
    0| 006BB4 lwz        83E100DC   1     L4A       gr31=#stack(gr1,220)                                                                                           74| 006CA4 andi.      70600800   1     RN4_R      gr0,cr0=gr3,0,0x800
   99| 006BB8 lwz        80A10050   1     L4A       gr5=error_traceback(gr1,80)                                                                                    74| 006CA8 bc         4082FE30   1     BF         CL.1373,cr0,0x4/eq,taken=40%(40,60)
   99| 006BBC bl         4BFF9445   0     CALL      PyErr_Restore,3,(*)_object",gr3,(*)_object",gr4,(*)_object",gr5,#ProcAlias",PyErr_Restore",fcr",gr1,cr[0156     0| 006CAC b          4BFFFCB8   1     B          CL.2291,-1
   99| 006BC0 ori        60000000   1                                                                                                                               0|                                CL.2275:
    0| 006BC4 lwz        800100E8   1     L4A       gr0=#stack(gr1,232)                                                                                          1275| 006CB0 addi       38600000   1     LI         gr3=0
  100| 006BC8 addi       382100E0   1     AI        gr1=gr1,224                                                                                                     0| 006CB4 lwz        83E100AC   1     L4A        gr31=#stack(gr1,172)
    0| 006BCC mtspr      7C0803A6   1     LLR       lr=gr0                                                                                                          0| 006CB8 lwz        83C100A8   1     L4A        gr30=#stack(gr1,168)
  100| 006BD0 bclr       4E800020   3     BA        lr                                                                                                              0| 006CBC lwz        83410098   1     L4A        gr26=#stack(gr1,152)
    0|                                CL.2071:                                                                                                                      0| 006CC0 lwz        83A100A4   1     L4A        gr29=#stack(gr1,164)
   83| 006BD4 bl         4BFF942D   0     CALL      _PyErr_WarnUnawaitedCoroutine,1,(*)_object",gr3,#ProcAlias",_PyErr_WarnUnawaitedCoroutine",fcr",gr1,cr[0156     0| 006CC4 lwz        800100B8   1     L4A        gr0=#stack(gr1,184)
   83| 006BD8 ori        60000000   1                                                                                                                            1276| 006CC8 addi       382100B0   1     AI         gr1=gr1,176
   89| 006BDC b          4BFFFFC0   0     B         CL.1974,-1                                                                                                      0| 006CCC mtspr      7C0803A6   1     LLR        lr=gr0
     |               Tag Table                                                                                                                                   1276| 006CD0 bclr       4E800020   3     BA         lr







Wed Apr 15 07:30:04 CDT 2020  Page 187


     | 006BE0        00000000 00002041 80040300 00000000 00000380 00185F50                                                                                           |               Tag Table
     | 006BF8        7947656E 5F46696E 616C697A 65404146 3132355F 3932                                                                                               | 006CD4        00000000 00002041 80060100 00000000 00000474 001D6173
     |               Instruction count          224                                                                                                                  | 006CEC        796E635F 67656E5F 696E6974 5F686F6F 6B734041 46313238
     |               Straight-line exec time    226                                                                                                                  | 006D04        5F3231
     |               Constant Area                                                                                                                                   |               Instruction count          285
     | 000000        7F800000 7FC00000 6D6F6466 6C000000 77637374 6F6B0000                                                                                           |               Straight-line exec time    291
     | 000018        6C646578 706C0000 66726578 706C0000 73656C65 63740000                                                                                       GPR's set/used:   ssus ssss ssss s---  ---- ---- ---- ----
     | 000030        73747274 6F6C6400 67656E5F 72657072 00000000 77637366                                                                                       FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----
     | 000048        74696D65 00000000 636F726F 5F726570 72000000 67656E5F                                                                                       CCR's set/used:   ss-- -sss
     | 000060        7468726F 77000000 67656E5F 636C6F73 65000000 5F507947                                                                                           | 000000                             PDEF       coro_wrapper_traverse at AF129_25
     | 000078        656E5F79 66000000 50794765 6E5F4E65 77000000 73747274                                                                                       1048|                                    PROC       cw,visit,arg,gr3-gr5
     | 000090        6F696D61 78000000 636F726F 5F617761 69740000 5F67656E                                                                                          0| 006D20 mfspr      7C0802A6   1     LFLR       gr0=lr
     | 0000A8        5F746872 6F770000 5079436F 726F5F4E 65770000 5F50795F                                                                                       1050| 006D24 lwz        80630008   1     L4A        gr3=(*)aggr#A.cw_coroutine(gr3,8)
     | 0000C0        44454352 45460000 5F50795F 494E4352 45460000 67656E5F                                                                                          0| 006D28 stwu       9421FFB0   1     ST4U       gr1,#stack(gr1,-80)=gr1
     | 0000D8        73656E64 5F657800 67656E5F 6465616C 6C6F6300 5F507947                                                                                          0| 006D2C ori        60860000   1     LR         gr6=gr4
     | 0000F0        656E5F53 656E6400 5F50795F 58444543 52454600 5F50795F                                                                                       1050| 006D30 ori        60A40000   1     LR         gr4=gr5
     | 000108        58494E43 52454600 5F50795F 49535F54 59504500 67656E5F                                                                                          0| 006D34 stw        90010058   1     ST4A       #stack(gr1,88)=gr0
     | 000120        7365745F 6E616D65 00000000 67656E5F 6765745F 6E616D65                                                                                       1050| 006D38 stw        90410014   1     ST4A       #cur_toc(gr1,20)=gr2
     | 000138        00000000 67656E5F 69746572 6E657874 00000000 67656E5F                                                                                       1050| 006D3C lwz        81660008   1     L4A        gr11=#new_env(gr6,8)
     | 000150        74726176 65727365 00000000 5F50795F 5345545F 53495A45                                                                                       1050| 006D40 lwz        80060000   1     L4A        gr0=#fnc_adr(gr6,0)
     | 000168        00000000 5F50795F 5345545F 54595045 00000000 5F507954                                                                                       1050| 006D44 mtspr      7C0903A6   2     LCTR       ctr=gr0
     | 000180        7970655F 43686563 6B000000 67657464 7461626C 6573697A                                                                                       1050| 006D48 lwz        80460004   1     CALL       gr3=gr6,2,(*)_object",gr3,(*)void",gr4,#ProcAlias",fcr",(*)int()",gr1,cr[01567]",gr0",gr4"-gr12",fp0"-fp13
     | 000198        65000000 6173796E 635F6765 6E5F7265 70720000 67656E5F                                                                                       1050| 006D4C bcctrl     4E800421   0
     | 0001B0        636C6F73 655F6974 65720000 50794173 796E6347 656E5F4E                                                                                       1050| 006D50 lwz        80410014   1
     | 0001C8        65770000 5F50794F 626A6563 745F494E 49540000 5F50795F                                                                                       1050| 006D54 cmpwi      2C030000   1     C4         cr0=gr3,0
     | 0001E0        5345545F 52454643 4E540000 6173796E 635F6765 6E5F6173                                                                                       1050| 006D58 bc         40820018   1     BF         CL.2263,cr0,0x4/eq,taken=50%(0,0)
     | 0001F8        656E6400 6173796E 635F6765 6E5F616E 65787400 6578635F                                                                                       1051| 006D5C addi       38600000   2     LI         gr3=0
     | 000210        73746174 655F636C 65617200 5F507947 656E5F46 696E616C                                                                                          0| 006D60 lwz        80010058   1     L4A        gr0=#stack(gr1,88)
     | 000228        697A6500 5F507941 73796E63 47656E5F 46696E69 00000000                                                                                       1052| 006D64 addi       38210050   1     AI         gr1=gr1,80
     | 000240        6173796E 635F6765 6E5F6174 68726F77 00000000 6173796E                                                                                          0| 006D68 mtspr      7C0803A6   1     LLR        lr=gr0
     | 000258        635F6765 6E5F6163 6C6F7365 00000000 67656E5F 69735F63                                                                                       1052| 006D6C bclr       4E800020   3     BA         lr
     | 000270        6F726F75 74696E65 00000000 67656E5F 67657479 69656C64                                                                                          0|                                CL.2263:
     | 000288        66726F6D 00000000 67656E5F 7365745F 7175616C 6E616D65                                                                                          0| 006D70 lwz        80010058   1     L4A        gr0=#stack(gr1,88)
     | 0002A0        00000000 67656E5F 6765745F 7175616C 6E616D65 00000000                                                                                       1052| 006D74 addi       38210050   1     AI         gr1=gr1,80
     | 0002B8        5F50795F 4D616B65 52656343 6865636B 00000000 5F50795F                                                                                          0| 006D78 mtspr      7C0803A6   1     LLR        lr=gr0
     | 0002D0        49734D61 696E5468 72656164 00000000 636F6D70 7574655F                                                                                       1052| 006D7C bclr       4E800020   3     BA         lr
     | 0002E8        63725F6F 72696769 6E000000 636F726F 5F777261 70706572                                                                                           |               Tag Table
     | 000300        5F73656E 64000000 636F726F 5F676574 5F63725F 61776169                                                                                           | 006D80        00000000 00002041 80000300 00000000 00000060 001E636F
     | 000318        74000000 5F507945 76616C5F 4576616C 4672616D 65000000                                                                                           | 006D98        726F5F77 72617070 65725F74 72617665 72736540 41463132
     | 000330        5F50794D 656D5F49 73507472 46726565 64000000 50795479                                                                                           | 006DB0        395F3235
     | 000348        70655F48 61734665 61747572 65000000 6173796E 635F6765                                                                                           |               Instruction count           24
     | 000360        6E5F7472 61766572 73650000 636F726F 5F777261 70706572                                                                                           |               Straight-line exec time     29
     | 000378        5F636C6F 73650000 636F726F 5F777261 70706572 5F746872                                                                                       GPR's set/used:   ssus ssss ssss s---  ---- ---- --ss ssss
     | 000390        6F770000 6578635F 73746174 655F7472 61766572 73650000                                                                                       FPR's set/used:   ssss ssss ssss ss--  ---- ---- ---- ----
     | 0003A8        5F507954 7970655F 48617346 65617475 72650000 5F507954                                                                                       CCR's set/used:   ss-- -sss
     | 0003C0        68726561 64537461 74655F47 45540000 5F50794F 626A6563                                                                                           | 000000                             PDEF       _PyGen_Finalize at AF130_92
     | 0003D8        745F4661 73744361 6C6C0000 50795665 63746F72 63616C6C                                                                                         43|                                    PROC       self,res,gen,gr3-gr5
     | 0003F0        5F4E4152 47530000 5F50794F 626A6563 745F494E 49545F56                                                                                          0| 006DC0 mfspr      7C0802A6   1     LFLR       gr0=lr
     | 000408        41520000 5F507954 7970655F 43686563 6B457861 63740000                                                                                          0| 006DC4 stwu       9421FF50   1     ST4U       gr1,#stack(gr1,-176)=gr1
     | 000420        6173796E 635F6765 6E5F6173 656E645F 6E657700 50794F62                                                                                         75| 006DC8 addi       38810054   1     AI         gr4=gr1,84
     | 000438        6A656374 5F43616C 6C4F6E65 41726700 5F50794F 626A6563                                                                                          0| 006DCC stw        900100B8   1     ST4A       #stack(gr1,184)=gr0
     | 000450        745F4361 6C6C4E6F 41726700 50794F62 6A656374 5F566563                                                                                          0| 006DD0 stw        93E100AC   1     ST4A       #stack(gr1,172)=gr31
     | 000468        746F7263 616C6C00 6173796E 635F6765 6E5F6173 656E645F                                                                                          0| 006DD4 ori        607F0000   1     LR         gr31=gr3
     | 000480        73656E64 00000000 6173796E 635F6765 6E5F696E 69745F68                                                                                         75| 006DD8 addi       38610058   1     AI         gr3=gr1,88
     | 000498        6F6F6B73 00000000 636F726F 5F777261 70706572 5F646561                                                                                          0| 006DDC stw        93C100A8   1     ST4A       #stack(gr1,168)=gr30
     | 0004B0        6C6C6F63 00000000 6173796E 635F6765 6E5F6174 68726F77                                                                                          0| 006DE0 stw        93A100A4   1     ST4A       #stack(gr1,164)=gr29







Wed Apr 15 07:30:04 CDT 2020  Page 188


     | 0004C8        5F6E6577 00000000 6173796E 635F6765 6E5F6174 68726F77                                                                                          0| 006DE4 ori        60BE0000   1     LR         gr30=gr5
     | 0004E0        5F73656E 64000000 6173796E 635F6765 6E5F6173 656E645F                                                                                         75| 006DE8 addi       38A10050   1     AI         gr5=gr1,80
     | 0004F8        636C6F73 65000000 6173796E 635F6765 6E5F6173 656E645F                                                                                          0| 006DEC stw        938100A0   1     ST4A       #stack(gr1,160)=gr28
     | 000510        7468726F 77000000 636F726F 5F777261 70706572 5F747261                                                                                          0| 006DF0 stw        9361009C   1     ST4A       #stack(gr1,156)=gr27
     | 000528        76657273 65000000 636F726F 5F777261 70706572 5F697465                                                                                          0| 006DF4 stw        93410098   1     ST4A       #stack(gr1,152)=gr26
     | 000540        726E6578 74000000 67656E5F 6E65775F 77697468 5F717561                                                                                        118| 006DF8 stw        90410014   1     ST4A       #cur_toc(gr1,20)=gr2
     | 000558        6C6E616D 65000000 5F50795F 49734D61 696E496E 74657270                                                                                         54| 006DFC lwz        800200E0   1     L4A        gr0=.PyAsyncGen_Type(gr2,0)
     | 000570        72657465 72000000 50795665 63746F72 63616C6C 5F46756E                                                                                        128| 006E00 lwz        80DF0004   1     L4A        gr6=(*)C_object._object.ob_type(gr31,4)
     | 000588        6374696F 6E000000 50794765 6E5F4E65 77576974 68517561                                                                                        128| 006E04 cmplw      7C060040   2     CL4        cr0=gr6,gr0
     | 0005A0        6C4E616D 65000000 6173796E 635F6765 6E5F6174 68726F77                                                                                         54| 006E08 bc         40820370   1     BF         CL.2014,cr0,0x4/eq,taken=40%(40,60)
     | 0005B8        5F636C6F 73650000 6173796E 635F6765 6E5F6174 68726F77                                                                                         56| 006E0C lwz        835F0030   1     L4A        gr26=(*)aggr#4.ag_finalizer(gr31,48)
     | 0005D0        5F746872 6F770000 6173796E 635F6765 6E5F756E 77726170                                                                                         57| 006E10 cmpwi      2C1A0000   2     C4         cr0=gr26,0
     | 0005E8        5F76616C 75650000 5F50795F 4C656176 65526563 75727369                                                                                         57| 006E14 bc         41820360   1     BT         CL.2110,cr0,0x4/eq,taken=40%(40,60)
     | 000600        76654361 6C6C0000 5F50795F 456E7465 72526563 75727369                                                                                         57| 006E18 lwz        801F0038   1     L4A        gr0=(*)aggr#4.ag_closed(gr31,56)
     | 000618        76654361 6C6C0000 6173796E 635F6765 6E5F6173 656E645F                                                                                         57| 006E1C cmpwi      2C000000   2     C4         cr0=gr0,0
     | 000630        6465616C 6C6F6300 5F50794F 626A6563 745F4743 5F545241                                                                                         57| 006E20 bc         4182013C   1     BT         CL.2030,cr0,0x4/eq,taken=50%(0,0)
     | 000648        434B5F69 6D706C00 6173796E 635F6765 6E5F6174 68726F77                                                                                          0| 006E24 lwz        83410098   1     L4A        gr26=#stack(gr1,152)
     | 000660        5F646561 6C6C6F63 00000000 6173796E 635F6765 6E5F6173                                                                                         75| 006E28 bl         4BFF91D9   0     CALL       PyErr_Fetch,3,(*)_object*",gr3,(*)_object*",gr4,(*)_object*",gr5,#ProcAlias",(*)_object",(*)_object",(*)_o
     | 000678        656E645F 69746572 6E657874 00000000 6173796E 635F6765                                                                                         75| 006E2C ori        60000000   1
     | 000690        6E5F6173 656E645F 74726176 65727365 00000000 5F50794F                                                                                         79| 006E30 lwz        807E0010   1     L4A        gr3=(*)aggr#3.gi_code(gr30,16)
     | 0006A8        626A6563 745F4661 73744361 6C6C5473 74617465 00000000                                                                                          0| 006E34 or.        7C601B79   2     LR_R       gr0,cr0=gr3
     | 0006C0        5F507943 6F726F5F 47657441 77616974 61626C65 49746572                                                                                         79| 006E38 bc         41820020   1     BT         CL.544,cr0,0x4/eq,taken=40%(40,60)
     | 0006D8        00000000 6173796E 635F6765 6E5F6174 68726F77 5F697465                                                                                          0|                                CL.2015:
     | 0006F0        726E6578 74000000 6173796E 635F6765 6E5F6174 68726F77                                                                                         80| 006E3C lwz        8003001C   1     L4A        gr0=(*)aggr#5.co_flags(gr3,28)
     | 000708        5F747261 76657273 65000000 5F50794F 626A6563 745F4743                                                                                         80| 006E40 andi.      70000080   2     RN4_R      gr0,cr0=gr0,0,0x80
     | 000720        5F554E54 5241434B 5F696D70 6C000000 50794F62 6A656374                                                                                         80| 006E44 bc         41820014   1     BT         CL.544,cr0,0x4/eq,taken=40%(40,60)
     | 000738        5F43616C 6C4D6574 686F644F 6E654172 67000000 50794F62                                                                                         81| 006E48 lwz        807E0008   1     L4A        gr3=(*)aggr#3.gi_frame(gr30,8)
     | 000750        6A656374 5F43616C 6C4D6574 686F644E 6F417267 73000000                                                                                         81| 006E4C lwz        80030034   2     L4A        gr0=(*)_frame._frame.f_lasti(gr3,52)
     | 000768        50794173 796E6347 656E5F43 6C656172 46726565 4C697374                                                                                         81| 006E50 cmpwi      2C00FFFF   2     C4         cr0=gr0,-1
     | 000780        73000000 5F50795F 54687265 61644361 6E48616E 646C6553                                                                                         81| 006E54 bc         418200E4   1     BT         CL.2117,cr0,0x4/eq,taken=40%(40,60)
     | 000798        69676E61 6C730000 5F50794F 626A6563 745F5665 63746F72                                                                                         84|                                CL.544:
     | 0007B0        63616C6C 54737461 74650000 5F507941 73796E63 47656E56                                                                                         86| 006E58 ori        63C30000   1     LR         gr3=gr30
     | 0007C8        616C7565 57726170 7065724E 65770000 5F50794F 626A6563                                                                                         86| 006E5C addi       38800000   1     LI         gr4=0
     | 0007E0        745F4361 6C6C4D65 74686F64 49644F6E 65417267 00000000                                                                                         86| 006E60 bl         4BFFDD01   0     CALL       gr3=gen_close,2,(*)aggr#3",gr3,(*)_object",gr4,#ProcAlias",gen_close",fcr",gr1,cr[01567]",gr0",gr4"-gr12",
     | 0007F8        5F50794F 626A6563 745F4361 6C6C4D65 74686F64 49644E6F                                                                                         89| 006E64 cmpwi      2C030000   1     C4         cr0=gr3,0
     | 000810        41726773 00000000 5F50794F 626A6563 745F5665 63746F72                                                                                        415| 006E68 lwz        80E20004   1     L4A        gr7=._Py_RefTotal(gr2,0)
     | 000828        63616C6C 4D657468 6F644964 00000000 5F507947 656E5F53                                                                                          0| 006E6C lwz        80C20018   1     L4A        gr6=.+CONSTANT_AREA(gr2,0)
     | 000840        65745374 6F704974 65726174 696F6E56 616C7565 00000000                                                                                         86| 006E70 ori        60650000   1     LR         gr5=gr3
     | 000858        6173796E 635F6765 6E5F7772 61707065 645F7661 6C5F6465                                                                                         89| 006E74 bc         41820074   0     BT         CL.2028,cr0,0x4/eq,taken=40%(40,60)
     | 000870        616C6C6F 63000000 5F50795F 4C656176 65526563 75727369                                                                                        408| 006E78 addi       3880005F   2     LI         gr4=95
     | 000888        76654361 6C6C5F69 6E6C696E 65000000 5F50795F 456E7465                                                                                        408| 006E7C addi       38661110   1     AI         gr3=gr6,4368
     | 0008A0        72526563 75727369 76654361 6C6C5F69 6E6C696E 65000000                                                                                          0| 006E80 lwz        83E100AC   1     L4A        gr31=#stack(gr1,172)
     | 0008B8        5F507952 756E7469 6D655374 6174655F 53657446 696E616C                                                                                        417| 006E84 lwz        80C50000   1     L4A        gr6=(*)_object._object.ob_refcnt(gr5,0)
     | 0008D0        697A696E 67000000 5F507952 756E7469 6D655374 6174655F                                                                                        415| 006E88 lwz        81070000   1     L4A        gr8=_Py_RefTotal(gr7,0)
     | 0008E8        47657446 696E616C 697A696E 67000000 6173796E 635F6765                                                                                        417| 006E8C addi       3806FFFF   1     AI         gr0=gr6,-1
     | 000900        6E5F7772 61707065 645F7661 6C5F7472 61766572 73650000                                                                                        417| 006E90 stw        90050000   1     ST4A       (*)_object._object.ob_refcnt(gr5,0)=gr0
     | 000918        5F50794F 626A6563 745F4745 545F5745 414B5245 46535F4C                                                                                        415| 006E94 addi       38C8FFFF   1     AI         gr6=gr8,-1
     | 000930        49535450 54520000 5F507949 6E746572 70726574 65725374                                                                                        415| 006E98 stw        90C70000   1     ST4A       _Py_RefTotal(gr7,0)=gr6
     | 000948        6174655F 4745545F 554E5341 46450000 5F507952 756E7469                                                                                        417| 006E9C cmpwi      2C000000   1     C4         cr0=gr0,0
     | 000960        6D655374 6174655F 47657454 68726561 64537461 74650000                                                                                        417| 006EA0 bc         40820038   1     BF         CL.2013,cr0,0x4/eq,taken=50%(0,0)
     | 000978        5F507947 656E5F46 65746368 53746F70 49746572 6174696F                                                                                        423|                                CL.1073:
     | 000990        6E56616C 75650000 5F50795F 54687265 61644361 6E48616E                                                                                        425| 006EA4 ori        60A30000   1     LR         gr3=gr5
     | 0009A8        646C6550 656E6469 6E674361 6C6C7300 6173656E 64287629                                                                                        425| 006EA8 bl         4BFF9159   0     CALL       _Py_Dealloc,1,(*)_object",gr3,#ProcAlias",_Py_Dealloc",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",
     | 0009C0        202D3E20 73656E64 20277627 20696E20 67656E65 7261746F                                                                                        425| 006EAC ori        60000000   1
     | 0009D8        722E0000 636C6F73 65282920 2D3E2072 61697365 2047656E                                                                                          0|                                CL.2029:
     | 0009F0        65726174 6F724578 69742069 6E736964 65206765 6E657261                                                                                         99| 006EB0 lwz        80610058   1     L4A        gr3=error_type(gr1,88)







Wed Apr 15 07:30:04 CDT 2020  Page 189


     | 000A08        746F722E 00000000 636C6F73 65282920 2D3E2072 61697365                                                                                         99| 006EB4 lwz        80810054   1     L4A        gr4=error_value(gr1,84)
     | 000A20        2047656E 65726174 6F724578 69742069 6E736964 6520636F                                                                                         99| 006EB8 lwz        80A10050   1     L4A        gr5=error_traceback(gr1,80)
     | 000A38        726F7574 696E652E 00000000 61636C6F 73652829 202D3E20                                                                                         99| 006EBC bl         4BFF9145   0     CALL       PyErr_Restore,3,(*)_object",gr3,(*)_object",gr4,(*)_object",gr5,#ProcAlias",PyErr_Restore",fcr",gr1,cr[015
     | 000A50        72616973 65204765 6E657261 746F7245 78697420 696E7369                                                                                         99| 006EC0 ori        60000000   1
     | 000A68        64652067 656E6572 61746F72 2E000000 61746872 6F772874                                                                                          0| 006EC4 lwz        83C100A8   1     L4A        gr30=#stack(gr1,168)
     | 000A80        79705B2C 76616C5B 2C74625D 5D29202D 3E207261 69736520                                                                                          0| 006EC8 lwz        800100B8   1     L4A        gr0=#stack(gr1,184)
     | 000A98        65786365 7074696F 6E20696E 2067656E 65726174 6F722E00                                                                                        100| 006ECC addi       382100B0   1     AI         gr1=gr1,176
     | 000AB0        73656E64 28617267 29202D3E 2073656E 64202761 72672720                                                                                          0| 006ED0 mtspr      7C0803A6   1     LLR        lr=gr0
     | 000AC8        696E746F 2067656E 65726174 6F722C0A 72657475 726E206E                                                                                        100| 006ED4 bclr       4E800020   3     BA         lr
     | 000AE0        65787420 7969656C 64656420 76616C75 65206F72 20726169                                                                                          0|                                CL.2013:
     | 000AF8        73652053 746F7049 74657261 74696F6E 2E000000 73656E64                                                                                        419| 006ED8 bc         4080FFD8   0     BF         CL.2029,cr0,0x1/lt,taken=60%(60,40)
     | 000B10        28617267 29202D3E 2073656E 64202761 72672720 696E746F                                                                                        420| 006EDC bl         4BFF9125   1     CALL       _Py_NegativeRefcount,3,(*)Cuchar",gr3,gr4,(*)_object",gr5,#ProcAlias",_Py_NegativeRefcount",fcr",gr1,cr[01
     | 000B28        20636F72 6F757469 6E652C0A 72657475 726E206E 65787420                                                                                        420| 006EE0 ori        60000000   1
     | 000B40        69746572 61746564 2076616C 7565206F 72207261 69736520                                                                                          0| 006EE4 b          4BFFFFCC   0     B          CL.2029,-1
     | 000B58        53746F70 49746572 6174696F 6E2E0000 7468726F 77287479                                                                                          0|                                CL.2028:
     | 000B70        705B2C76 616C5B2C 74625D5D 29202D3E 20726169 73652065                                                                                         90| 006EE8 bl         4BFF9119   0     CALL       gr3=PyErr_Occurred,0,#ProcAlias",PyErr_Occurred",fcr",gr1,cr[01567]",gr0",gr4"-gr12",fp0"-fp13",mq",lr",fc
     | 000B88        78636570 74696F6E 20696E20 67656E65 7261746F 722C0A72                                                                                         90| 006EEC ori        60000000   1
     | 000BA0        65747572 6E206E65 78742079 69656C64 65642076 616C7565                                                                                         90| 006EF0 cmpwi      2C030000   1     C4         cr0=gr3,0
     | 000BB8        206F7220 72616973 65205374 6F704974 65726174 696F6E2E                                                                                         90| 006EF4 bc         4082000C   1     BF         CL.1685,cr0,0x4/eq,taken=50%(0,0)
     | 000BD0        00000000 7468726F 77287479 705B2C76 616C5B2C 74625D5D                                                                                          0| 006EF8 lwz        83E100AC   2     L4A        gr31=#stack(gr1,172)
     | 000BE8        29202D3E 20726169 73652065 78636570 74696F6E 20696E20                                                                                          0| 006EFC b          4BFFFFB4   0     B          CL.2029,-1
     | 000C00        636F726F 7574696E 652C0A72 65747572 6E206E65 78742069                                                                                         91|                                CL.1685:
     | 000C18        74657261 74656420 76616C75 65206F72 20726169 73652053                                                                                         64| 006F00 ori        63E30000   1     LR         gr3=gr31
     | 000C30        746F7049 74657261 74696F6E 2E000000 63616E27 74207365                                                                                         64| 006F04 bl         4BFF90FD   0     CALL       PyErr_WriteUnraisable,1,(*)_object",gr3,#ProcAlias",PyErr_WriteUnraisable",fcr",gr1,cr[01567]",gr0",gr3"-g
     | 000C48        6E64206E 6F6E2D4E 6F6E6520 76616C75 6520746F 2061206A                                                                                         64| 006F08 ori        60000000   1
     | 000C60        7573742D 73746172 74656420 636F726F 7574696E 65000000                                                                                         99| 006F0C lwz        80610058   1     L4A        gr3=error_type(gr1,88)
     | 000C78        6173796E 63206765 6E657261 746F7220 69676E6F 72656420                                                                                         99| 006F10 lwz        80810054   1     L4A        gr4=error_value(gr1,84)
     | 000C90        47656E65 7261746F 72457869 74000000 67656E65 7261746F                                                                                         99| 006F14 lwz        80A10050   1     L4A        gr5=error_traceback(gr1,80)
     | 000CA8        7220616C 72656164 79206578 65637574 696E6700 636F726F                                                                                         99| 006F18 bl         4BFF90E9   0     CALL       PyErr_Restore,3,(*)_object",gr3,(*)_object",gr4,(*)_object",gr5,#ProcAlias",PyErr_Restore",fcr",gr1,cr[015
     | 000CC0        7574696E 6520616C 72656164 79206578 65637574 696E6700                                                                                         99| 006F1C ori        60000000   1
     | 000CD8        6173796E 63206765 6E657261 746F7220 616C7265 61647920                                                                                          0| 006F20 lwz        83E100AC   1     L4A        gr31=#stack(gr1,172)
     | 000CF0        65786563 7574696E 67000000 63616E27 74207365 6E64206E                                                                                          0| 006F24 lwz        83C100A8   1     L4A        gr30=#stack(gr1,168)
     | 000D08        6F6E2D4E 6F6E6520 76616C75 6520746F 2061206A 7573742D                                                                                          0| 006F28 lwz        800100B8   1     L4A        gr0=#stack(gr1,184)
     | 000D20        73746172 74656420 67656E65 7261746F 72000000 63616E27                                                                                        100| 006F2C addi       382100B0   1     AI         gr1=gr1,176
     | 000D38        74207365 6E64206E 6F6E2D4E 6F6E6520 76616C75 6520746F                                                                                          0| 006F30 mtspr      7C0803A6   1     LLR        lr=gr0
     | 000D50        2061206A 7573742D 73746172 74656420 6173796E 63206765                                                                                        100| 006F34 bclr       4E800020   3     BA         lr
     | 000D68        6E657261 746F7200 67656E65 7261746F 72207261 69736564                                                                                          0|                                CL.2117:
     | 000D80        2053746F 70497465 72617469 6F6E0000 636F726F 7574696E                                                                                         83| 006F38 ori        63C30000   1     LR         gr3=gr30
     | 000D98        65207261 69736564 2053746F 70497465 72617469 6F6E0000                                                                                         83| 006F3C bl         4BFF90C5   0     CALL       _PyErr_WarnUnawaitedCoroutine,1,(*)_object",gr3,#ProcAlias",_PyErr_WarnUnawaitedCoroutine",fcr",gr1,cr[015
     | 000DB0        6173796E 63206765 6E657261 746F7220 72616973 65642053                                                                                         83| 006F40 ori        60000000   1
     | 000DC8        746F7049 74657261 74696F6E 00000000 6173796E 63206765                                                                                         90| 006F44 bl         4BFF90BD   0     CALL       gr3=PyErr_Occurred,0,#ProcAlias",PyErr_Occurred",fcr",gr1,cr[01567]",gr0",gr4"-gr12",fp0"-fp13",mq",lr",fc
     | 000DE0        6E657261 746F7220 72616973 65642053 746F7041 73796E63                                                                                         90| 006F48 ori        60000000   1
     | 000DF8        49746572 6174696F 6E000000 636C6F73 65000000 67656E65                                                                                         90| 006F4C cmpwi      2C030000   1     C4         cr0=gr3,0
     | 000E10        7261746F 72206967 6E6F7265 64204765 6E657261 746F7245                                                                                         90| 006F50 bc         4082FFB0   1     BF         CL.1685,cr0,0x4/eq,taken=70%(70,30)
     | 000E28        78697400 636F726F 7574696E 65206967 6E6F7265 64204765                                                                                          0| 006F54 lwz        83E100AC   2     L4A        gr31=#stack(gr1,172)
     | 000E40        6E657261 746F7245 78697400 7468726F 77000000 5F5F6E61                                                                                          0| 006F58 b          4BFFFF58   0     B          CL.2029,-1
     | 000E58        6D655F5F 00000000 6E616D65 206F6620 74686520 67656E65                                                                                          0|                                CL.2030:
     | 000E70        7261746F 72000000 5F5F7175 616C6E61 6D655F5F 00000000                                                                                         59| 006F5C bl         4BFF90A5   0     CALL       PyErr_Fetch,3,(*)_object*",gr3,(*)_object*",gr4,(*)_object*",gr5,#ProcAlias",(*)_object",(*)_object",(*)_o
     | 000E88        7175616C 69666965 64206E61 6D65206F 66207468 65206765                                                                                         59| 006F60 ori        60000000   1
     | 000EA0        6E657261 746F7200 67695F79 69656C64 66726F6D 00000000                                                                                        183| 006F64 addi       38A000B7   1     LI         gr5=183
     | 000EB8        6F626A65 63742062 65696E67 20697465 72617465 64206279                                                                                        183| 006F68 lwz        80820018   1     L4A        gr4=.+CONSTANT_AREA(gr2,0)
     | 000ED0        20796965 6C642066 726F6D2C 206F7220 4E6F6E65 00000000                                                                                        183| 006F6C cmpwi      2C1F0000   1     C4         cr0=gr31,0
     | 000EE8        67695F66 72616D65 00000000 67695F72 756E6E69 6E670000                                                                                        183| 006F70 bc         418201D8   1     BT         CL.2031,cr0,0x4/eq,taken=50%(0,0)
     | 000F00        67695F63 6F646500 73656E64 00000000 67656E65 7261746F                                                                                        185| 006F74 stw        93E1008C   2     ST4A       _args(gr1,140)=gr31
     | 000F18        72000000 6E616D65 206F6620 74686520 636F726F 7574696E                                                                                        186| 006F78 bl         4BFF9089   0     CALL       gr3=PyThreadState_Get,0,#ProcAlias",PyThreadState_Get",fcr",gr1,cr[01567]",gr0",gr4"-gr12",fp0"-fp13",mq",
     | 000F30        65000000 7175616C 69666965 64206E61 6D65206F 66207468                                                                                        186| 006F7C ori        60000000   1







Wed Apr 15 07:30:04 CDT 2020  Page 190


     | 000F48        6520636F 726F7574 696E6500 63725F61 77616974 00000000                                                                                        187| 006F80 addis      3C808000   1     LIU        gr4=32768
     | 000F60        6F626A65 63742062 65696E67 20617761 69746564 206F6E2C                                                                                        188| 006F84 ori        607E0000   1     LR         gr30=gr3
     | 000F78        206F7220 4E6F6E65 00000000 63725F66 72616D65 00000000                                                                                        187| 006F88 addi       3BA40001   1     AI         gr29=gr4,1
     | 000F90        63725F72 756E6E69 6E670000 63725F63 6F646500 63725F6F                                                                                          0|                                CL.2020:
     | 000FA8        72696769 6E000000 636F726F 7574696E 65000000 636F726F                                                                                         73| 006F8C lwz        839A0004   1     L4A        gr28=(*)_object._object.ob_type(gr26,4)
     | 000FC0        7574696E 655F7772 61707065 72000000 41207772 61707065                                                                                        617| 006F90 ori        63830000   2     LR         gr3=gr28
     | 000FD8        72206F62 6A656374 20696D70 6C656D65 6E74696E 67205F5F                                                                                        617| 006F94 bl         4BFF906D   0     CALL       gr3=PyType_GetFlags,1,(*)_typeobject",gr3,#ProcAlias",PyType_GetFlags",fcr",gr1,cr[01567]",gr0",gr4"-gr12"
     | 000FF0        61776169 745F5F20 666F7220 636F726F 7574696E 65732E00                                                                                        617| 006F98 ori        60000000   1
     | 001008        6E616D65 206F6620 74686520 6173796E 63206765 6E657261                                                                                         74| 006F9C andi.      70600800   1     RN4_R      gr0,cr0=gr3,0,0x800
     | 001020        746F7200 7175616C 69666965 64206E61 6D65206F 66207468                                                                                         74| 006FA0 bc         40820078   1     BF         CL.1059,cr0,0x4/eq,taken=40%(40,60)
     | 001038        65206173 796E6320 67656E65 7261746F 72000000 61675F61                                                                                        116| 006FA4 ori        63C30000   2     LR         gr3=gr30
     | 001050        77616974 00000000 61675F66 72616D65 00000000 61675F72                                                                                        116| 006FA8 ori        63440000   1     LR         gr4=gr26
     | 001068        756E6E69 6E670000 61675F63 6F646500 6173656E 64000000                                                                                        116| 006FAC addi       38A1008C   1     AI         gr5=gr1,140
     | 001080        61746872 6F770000 61636C6F 73650000 5F5F636C 6173735F                                                                                          0| 006FB0 lwz        83A100A4   1     L4A        gr29=#stack(gr1,164)
     | 001098        67657469 74656D5F 5F000000 53656520 50455020 35383500                                                                                          0| 006FB4 lwz        838100A0   1     L4A        gr28=#stack(gr1,160)
     | 0010B0        6173796E 635F6765 6E657261 746F7200 6173796E 635F6765                                                                                        116| 006FB8 addi       38C00001   1     LI         gr6=1
     | 0010C8        6E657261 746F725F 6173656E 64000000 6173796E 635F6765                                                                                        116| 006FBC addi       38E00000   1     LI         gr7=0
     | 0010E0        6E657261 746F725F 77726170 7065645F 76616C75 65000000                                                                                        116| 006FC0 bl         4BFF9041   0     CALL       gr3=_PyObject_MakeTpCall,5,(*)_ts",gr3,(*)_object",gr4,(*)_object*C",gr5,gr6,(*)_object",gr7,#ProcAlias",(
     | 0010F8        6173796E 635F6765 6E657261 746F725F 61746872 6F770049                                                                                        116| 006FC4 ori        60000000   1
     | 001110        4F626A65 6374732F 67656E6F 626A6563 742E6300 2E2F496E                                                                                          0| 006FC8 lwz        83410098   1     L4A        gr26=#stack(gr1,152)
     | 001128        636C7564 652F6F62 6A656374 2E680049 50794279 7465735F                                                                                        188|                                CL.1069:
     | 001140        43686563 6B286279 7465636F 64652900 636F6465 5B305D20                                                                                         63| 006FCC or.        7C651B79   1     LR_R       gr5,cr0=gr3
     | 001158        213D2059 49454C44 5F46524F 4D004942 61726720 213D204E                                                                                          0| 006FD0 lwz        80620018   1     L4A        gr3=.+CONSTANT_AREA(gr2,0)
     | 001170        554C4C00 2E2F496E 636C7564 652F6370 7974686F 6E2F6162                                                                                        408| 006FD4 addi       38800042   1     LI         gr4=66
     | 001188        73747261 63742E68 0049424D 63616C6C 61626C65 20213D20                                                                                        415| 006FD8 lwz        80C20004   1     L4A        gr6=._Py_RefTotal(gr2,0)
     | 0011A0        4E554C4C 0049424D 50794361 6C6C6162 6C655F43 6865636B                                                                                         63| 006FDC bc         4182FF24   0     BT         CL.1685,cr0,0x4/eq,taken=30%(30,70)
     | 0011B8        2863616C 6C61626C 65290049 6F666673 6574203E 20300049                                                                                        417| 006FE0 lwz        80E50000   2     L4A        gr7=(*)_object._object.ob_refcnt(gr5,0)
     | 0011D0        63616E6E 6F742072 65757365 20616C72 65616479 20617761                                                                                          0| 006FE4 lwz        83E100AC   1     L4A        gr31=#stack(gr1,172)
     | 0011E8        69746564 20636F72 6F757469 6E650049 662D3E66 5F626163                                                                                        408| 006FE8 addi       38631110   1     AI         gr3=gr3,4368
     | 001200        6B203D3D 204E554C 4C004942 662D3E66 5F626163 6B203D3D                                                                                        417| 006FEC addi       3807FFFF   1     AI         gr0=gr7,-1
     | 001218        20747374 6174652D 3E667261 6D650049 21507941 73796E63                                                                                        417| 006FF0 stw        90050000   1     ST4A       (*)_object._object.ob_refcnt(gr5,0)=gr0
     | 001230        47656E5F 43686563 6B457861 63742867 656E2900 25730049                                                                                        415| 006FF4 lwz        80E60000   1     L4A        gr7=_Py_RefTotal(gr6,0)
     | 001248        72657420 3D3D2079 66004942 67656E2D 3E67695F 6672616D                                                                                        415| 006FF8 addi       38E7FFFF   2     AI         gr7=gr7,-1
     | 001260        652D3E66 5F6C6173 7469203E 3D203000 7468726F 77282920                                                                                        415| 006FFC stw        90E60000   1     ST4A       _Py_RefTotal(gr6,0)=gr7
     | 001278        74686972 64206172 67756D65 6E74206D 75737420 62652061                                                                                        417| 007000 cmpwi      2C000000   1     C4         cr0=gr0,0
     | 001290        20747261 63656261 636B206F 626A6563 74004942 696E7374                                                                                        417| 007004 bc         4182FEA0   1     BT         CL.1073,cr0,0x4/eq,taken=40%(40,60)
     | 0012A8        616E6365 20657863 65707469 6F6E206D 6179206E 6F742068                                                                                        419| 007008 bc         4080FEA8   1     BF         CL.2029,cr0,0x1/lt,taken=50%(0,0)
     | 0012C0        61766520 61207365 70617261 74652076 616C7565 0049424D                                                                                        420| 00700C bl         4BFF8FF5   1     CALL       _Py_NegativeRefcount,3,(*)Cuchar",gr3,gr4,(*)_object",gr5,#ProcAlias",_Py_NegativeRefcount",fcr",gr1,cr[01
     | 0012D8        65786365 7074696F 6E73206D 75737420 62652063 6C617373                                                                                        420| 007010 ori        60000000   1
     | 0012F0        6573206F 7220696E 7374616E 63657320 64657269 76696E67                                                                                          0| 007014 b          4BFFFE9C   0     B          CL.2029,-1
     | 001308        2066726F 6D204261 73654578 63657074 696F6E2C 206E6F74                                                                                         76|                                CL.1059:
     | 001320        20257300 63616E6E 6F742072 65757365 20616C72 65616479                                                                                         77| 007018 ori        63430000   1     LR         gr3=gr26
     | 001338        20617761 69746564 2061636C 6F736528 292F6174 68726F77                                                                                         77| 00701C bl         4BFF8FE5   0     CALL       gr3=PyCallable_Check,1,(*)_object",gr3,#ProcAlias",PyCallable_Check",fcr",gr1,cr[01567]",gr0",gr4"-gr12",f
     | 001350        28290049 61636C6F 73652829 3A206173 796E6368 726F6E6F                                                                                         77| 007020 ori        60000000   1
     | 001368        75732067 656E6572 61746F72 20697320 616C7265 61647920                                                                                         77| 007024 cmpwi      2C030000   1     C4         cr0=gr3,0
     | 001380        72756E6E 696E6700 61746872 6F772829 3A206173 796E6368                                                                                         78| 007028 lwz        837C001C   1     L4A        gr27=(*)_typeobject._typeobject.tp_vectorcall_offset(gr28,28)
     | 001398        726F6E6F 75732067 656E6572 61746F72 20697320 616C7265                                                                                          0| 00702C ori        63600000   2     LR         gr0=gr27
     | 0013B0        61647920 72756E6E 696E6700 6F2D3E61 67745F73 74617465                                                                                         77| 007030 bc         418200C0   0     BT         CL.2032,cr0,0x4/eq,taken=40%(40,60)
     | 0013C8        203D3D20 41574149 5441424C 455F5354 4154455F 49544552                                                                                         79| 007034 cmpwi      2C000000   1     C4         cr0=gr0,0
     | 0013E0        0049424D 28282850 7947435F 48656164 202A2928 6F70292D                                                                                          0| 007038 lwz        838100A0   1     L4A        gr28=#stack(gr1,160)
     | 0013F8        31292D3E 5F67635F 6E657874 20213D20 30290049 6F626A65                                                                                         79| 00703C bc         4081008C   0     BF         CL.2024,cr0,0x2/gt,taken=40%(40,60)
     | 001410        6374206E 6F742074 7261636B 65642062 79207468 65206761                                                                                          0|                                CL.2025:
     | 001428        72626167 6520636F 6C6C6563 746F7200 5F50794F 626A6563                                                                                         81| 007040 lwzx       7CFAD82E   1     L4A        gr7=(*)_object*()*(gr26,gr27,0)
     | 001440        745F4743 5F554E54 5241434B 0049424D 5F507941 73796E63                                                                                          0| 007044 or.        7CE03B79   2     LR_R       gr0,cr0=gr7
     | 001458        47656E57 72617070 65645661 6C75655F 43686563 6B457861                                                                                        114| 007048 bc         41820054   1     BT         CL.2111,cr0,0x4/eq,taken=30%(30,70)
     | 001470        6374286F 29004942 63616E6E 6F742072 65757365 20616C72                                                                                          0|                                CL.2121:







Wed Apr 15 07:30:04 CDT 2020  Page 191


     | 001488        65616479 20617761 69746564 205F5F61 6E657874 5F5F2829                                                                                        118| 00704C ori        63430000   1     LR         gr3=gr26
     | 0014A0        2F617365 6E642829 0049424D 616E6578 7428293A 20617379                                                                                        118| 007050 lwz        80070000   1     L4A        gr0=#fnc_adr(gr7,0)
     | 0014B8        6E636872 6F6E6F75 73206765 6E657261 746F7220 69732061                                                                                        118| 007054 addi       3881008C   1     AI         gr4=gr1,140
     | 0014D0        6C726561 64792072 756E6E69 6E670049 50794173 796E6347                                                                                        118| 007058 lwz        81670008   1     L4A        gr11=#new_env(gr7,8)
     | 0014E8        656E4153 656E645F 43686563 6B457861 6374286F 29004942                                                                                          0| 00705C lwz        8361009C   1     L4A        gr27=#stack(gr1,156)
     | 001500        50795F49 535F5459 5045286F 2C20265F 50794173 796E6347                                                                                        118| 007060 ori        63A50000   1     LR         gr5=gr29
     | 001518        656E4153 656E645F 54797065 29004942 21282828 50794743                                                                                        118| 007064 addi       38C00000   1     LI         gr6=0
     | 001530        5F486561 64202A29 286F7029 2D31292D 3E5F6763 5F6E6578                                                                                        118| 007068 mtspr      7C0903A6   1     LCTR       ctr=gr0
     | 001548        7420213D 20302900 6F626A65 63742061 6C726561 64792074                                                                                        118| 00706C lwz        80470004   1     CALL       gr3=gr7,4,(*)_object",gr3,(*)_object*C",gr4,gr5,(*)_object",gr6,#ProcAlias",(*)_object",fcr",(*)_object*()
     | 001560        7261636B 65642062 79207468 65206761 72626167 6520636F                                                                                        118| 007070 bcctrl     4E800421   0
     | 001578        6C6C6563 746F7200 5F50794F 626A6563 745F4743 5F545241                                                                                        118| 007074 lwz        80410014   1
     | 001590        434B0049 2867632D 3E5F6763 5F707265 76202620 28322929                                                                                        118| 007078 ori        60650000   1     LR         gr5=gr3
     | 0015A8        203D3D20 30004942 6F626A65 63742069 7320696E 2067656E                                                                                        119| 00707C ori        63C30000   1     LR         gr3=gr30
     | 0015C0        65726174 696F6E20 77686963 68206973 20676172 62616765                                                                                        119| 007080 addi       38C00000   1     LI         gr6=0
     | 0015D8        20636F6C 6C656374 65640049 28287569 6E747074 725F7429                                                                                        119| 007084 ori        63440000   1     LR         gr4=gr26
     | 0015F0        6C617374 2026207E 5F507947 435F5052 45565F4D 41534B29                                                                                        119| 007088 bl         4BFF8F79   0     CALL       gr3=_Py_CheckFunctionResult,4,(*)_ts",gr3,(*)_object",gr4,(*)_object",gr5,(*)Cuchar",gr6,#ProcAlias",_Py_C
     | 001608        203D3D20 30004942 2E2F496E 636C7564 652F696E 7465726E                                                                                        119| 00708C ori        60000000   1
     | 001620        616C2F70 79636F72 655F6F62 6A656374 2E680049 3C617379                                                                                          0| 007090 lwz        83410098   1     L4A        gr26=#stack(gr1,152)
     | 001638        6E635F67 656E6572 61746F72 206F626A 65637420 25532061                                                                                          0| 007094 lwz        83A100A4   1     L4A        gr29=#stack(gr1,164)
     | 001650        74202570 3E004942 3C636F72 6F757469 6E65206F 626A6563                                                                                          0| 007098 b          4BFFFF34   0     B          CL.1069,-1
     | 001668        74202553 20617420 25703E00 5F5F7175 616C6E61 6D655F5F                                                                                          0|                                CL.2111:
     | 001680        206D7573 74206265 20736574 20746F20 61207374 72696E67                                                                                        116| 00709C ori        63C30000   1     LR         gr3=gr30
     | 001698        206F626A 65637400 5F5F6E61 6D655F5F 206D7573 74206265                                                                                        116| 0070A0 ori        63440000   1     LR         gr4=gr26
     | 0016B0        20736574 20746F20 61207374 72696E67 206F626A 65637400                                                                                        116| 0070A4 addi       38A1008C   1     AI         gr5=gr1,140
     | 0016C8        3C67656E 65726174 6F72206F 626A6563 74202553 20617420                                                                                          0| 0070A8 lwz        83A100A4   1     L4A        gr29=#stack(gr1,164)
     | 0016E0        25703E00 76616C00 4F694F00 50795475 706C655F 43686563                                                                                          0| 0070AC lwz        8361009C   1     L4A        gr27=#stack(gr1,156)
     | 0016F8        6B286372 5F6F7269 67696E29 0049424D 5F5F6177 6169745F                                                                                        116| 0070B0 addi       38C00001   1     LI         gr6=1
     | 001710        5F282920 72657475 726E6564 20612063 6F726F75 74696E65                                                                                        116| 0070B4 addi       38E00000   1     LI         gr7=0
     | 001728        0049424D 5F5F6177 6169745F 5F282920 72657475 726E6564                                                                                        116| 0070B8 bl         4BFF8F49   0     CALL       gr3=_PyObject_MakeTpCall,5,(*)_ts",gr3,(*)_object",gr4,(*)_object*C",gr5,gr6,(*)_object",gr7,#ProcAlias",(
     | 001740        206E6F6E 2D697465 7261746F 72206F66 20747970 65202725                                                                                        116| 0070BC ori        60000000   1
     | 001758        2E313030 73270049 6F626A65 63742025 2E313030 73206361                                                                                          0| 0070C0 lwz        83410098   1     L4A        gr26=#stack(gr1,152)
     | 001770        6E277420 62652075 73656420 696E2027 61776169 74272065                                                                                        116| 0070C4 b          4BFFFF08   0     B          CL.1069,-1
     | 001788        78707265 7373696F 6E00                                                                                                                         0|                                CL.2024:
                                                                                                                                                                   79| 0070C8 addi       38A0004F   1     LI         gr5=79
                                                                                                                                                                   79| 0070CC lwz        80620018   1     L4A        gr3=.+CONSTANT_AREA(gr2,0)
                                                                                                                                                                   79| 0070D0 addi       38831174   2     AI         gr4=gr3,4468
                                                                                                                                                                   79| 0070D4 addi       386311C4   1     AI         gr3=gr3,4548
                                                                                                                                                                   79| 0070D8 bl         4BFF8F29   0     CALL       __assert,3,gr3-gr5,#ProcAlias",__assert",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",lr",fcr",xer",
                                                                                                                                                                   79| 0070DC ori        60000000   1
                                                                                                                                                                   81| 0070E0 lwzx       7CFAD82E   1     L4A        gr7=(*)_object*()*(gr26,gr27,0)
                                                                                                                                                                    0| 0070E4 or.        7CE03B79   2     LR_R       gr0,cr0=gr7
                                                                                                                                                                  114| 0070E8 bc         4182FFB4   1     BT         CL.2111,cr0,0x4/eq,taken=30%(30,70)
                                                                                                                                                                    0| 0070EC b          4BFFFF60   1     B          CL.2121,-1
                                                                                                                                                                    0|                                CL.2032:
                                                                                                                                                                   77| 0070F0 addi       38A0004D   1     LI         gr5=77
                                                                                                                                                                   77| 0070F4 lwz        80620018   1     L4A        gr3=.+CONSTANT_AREA(gr2,0)
                                                                                                                                                                   77| 0070F8 addi       38831174   2     AI         gr4=gr3,4468
                                                                                                                                                                   77| 0070FC addi       386311A8   1     AI         gr3=gr3,4520
                                                                                                                                                                   77| 007100 bl         4BFF8F01   0     CALL       __assert,3,gr3-gr5,#ProcAlias",__assert",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",lr",fcr",xer",
                                                                                                                                                                   77| 007104 ori        60000000   1
                                                                                                                                                                   78| 007108 lwz        837C001C   1     L4A        gr27=(*)_typeobject._typeobject.tp_vectorcall_offset(gr28,28)
                                                                                                                                                                    0| 00710C or.        7F60DB79   2     LR_R       gr0,cr0=gr27
                                                                                                                                                                   79| 007110 bc         4081000C   1     BF         CL.2116,cr0,0x2/gt,taken=40%(40,60)
                                                                                                                                                                    0| 007114 lwz        838100A0   1     L4A        gr28=#stack(gr1,160)
                                                                                                                                                                    0| 007118 b          4BFFFF28   0     B          CL.2025,-1
                                                                                                                                                                    0|                                CL.2116:







Wed Apr 15 07:30:04 CDT 2020  Page 192


                                                                                                                                                                   79| 00711C addi       38A0004F   1     LI         gr5=79
                                                                                                                                                                   79| 007120 lwz        80620018   1     L4A        gr3=.+CONSTANT_AREA(gr2,0)
                                                                                                                                                                    0| 007124 lwz        838100A0   1     L4A        gr28=#stack(gr1,160)
                                                                                                                                                                   79| 007128 addi       38831174   1     AI         gr4=gr3,4468
                                                                                                                                                                   79| 00712C addi       386311C4   1     AI         gr3=gr3,4548
                                                                                                                                                                   79| 007130 bl         4BFF8ED1   0     CALL       __assert,3,gr3-gr5,#ProcAlias",__assert",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",lr",fcr",xer",
                                                                                                                                                                   79| 007134 ori        60000000   1
                                                                                                                                                                   81| 007138 lwzx       7CFAD82E   1     L4A        gr7=(*)_object*()*(gr26,gr27,0)
                                                                                                                                                                    0| 00713C or.        7CE03B79   2     LR_R       gr0,cr0=gr7
                                                                                                                                                                  114| 007140 bc         4182FF5C   1     BT         CL.2111,cr0,0x4/eq,taken=30%(30,70)
                                                                                                                                                                    0| 007144 b          4BFFFF08   1     B          CL.2121,-1
                                                                                                                                                                    0|                                CL.2031:
                                                                                                                                                                  183| 007148 addi       38641168   1     AI         gr3=gr4,4456
                                                                                                                                                                  183| 00714C addi       38841174   1     AI         gr4=gr4,4468
                                                                                                                                                                  183| 007150 bl         4BFF8EB1   0     CALL       __assert,3,gr3-gr5,#ProcAlias",__assert",fcr",gr1,cr[01567]",gr0",gr3"-gr12",fp0"-fp13",mq",lr",fcr",xer",
                                                                                                                                                                  183| 007154 ori        60000000   1
                                                                                                                                                                  185| 007158 stw        93E1008C   1     ST4A       _args(gr1,140)=gr31
                                                                                                                                                                  186| 00715C bl         4BFF8EA5   0     CALL       gr3=PyThreadState_Get,0,#ProcAlias",PyThreadState_Get",fcr",gr1,cr[01567]",gr0",gr4"-gr12",fp0"-fp13",mq",
                                                                                                                                                                  186| 007160 ori        60000000   1
                                                                                                                                                                  187| 007164 addis      3C808000   1     LIU        gr4=32768
                                                                                                                                                                  188| 007168 ori        607E0000   1     LR         gr30=gr3
                                                                                                                                                                  187| 00716C addi       3BA40001   1     AI         gr29=gr4,1
                                                                                                                                                                   72| 007170 b          4BFFFE1C   0     B          CL.2020,-1
                                                                                                                                                                    0|                                CL.2110:
                                                                                                                                                                    0| 007174 lwz        83410098   1     L4A        gr26=#stack(gr1,152)
                                                                                                                                                                    0|                                CL.2014:
                                                                                                                                                                   75| 007178 bl         4BFF8E89   0     CALL       PyErr_Fetch,3,(*)_object*",gr3,(*)_object*",gr4,(*)_object*",gr5,#ProcAlias",(*)_object",(*)_object",(*)_o
                                                                                                                                                                   75| 00717C ori        60000000   1
                                                                                                                                                                   79| 007180 lwz        807E0010   1     L4A        gr3=(*)aggr#3.gi_code(gr30,16)
                                                                                                                                                                    0| 007184 or.        7C601B79   2     LR_R       gr0,cr0=gr3
                                                                                                                                                                   79| 007188 bc         4182FCD0   1     BT         CL.544,cr0,0x4/eq,taken=40%(40,60)
                                                                                                                                                                    0| 00718C b          4BFFFCB0   1     B          CL.2015,-1
                                                                                                                                                                     |               Tag Table
                                                                                                                                                                     | 007190        00000000 00002041 80060300 00000000 000003D0 00185F50
                                                                                                                                                                     | 0071A8        7947656E 5F46696E 616C697A 65404146 3133305F 3932
                                                                                                                                                                     |               Instruction count          244
                                                                                                                                                                     |               Straight-line exec time    235
                                                                                                                                                                     |               Constant Area
                                                                                                                                                                     | 000000        7F800000 7FC00000 6D6F6466 6C000000 77637374 6F6B0000
                                                                                                                                                                     | 000018        6C646578 706C0000 66726578 706C0000 73656C65 63740000
                                                                                                                                                                     | 000030        73747274 6F6C6400 67656E5F 72657072 00000000 77637366
                                                                                                                                                                     | 000048        74696D65 00000000 636F726F 5F726570 72000000 67656E5F
                                                                                                                                                                     | 000060        7468726F 77000000 67656E5F 636C6F73 65000000 5F507947
                                                                                                                                                                     | 000078        656E5F79 66000000 50794765 6E5F4E65 77000000 73747274
                                                                                                                                                                     | 000090        6F696D61 78000000 636F726F 5F617761 69740000 5F67656E
                                                                                                                                                                     | 0000A8        5F746872 6F770000 5079436F 726F5F4E 65770000 5F50795F
                                                                                                                                                                     | 0000C0        44454352 45460000 5F50795F 494E4352 45460000 67656E5F
                                                                                                                                                                     | 0000D8        73656E64 5F657800 67656E5F 6465616C 6C6F6300 5F507947
                                                                                                                                                                     | 0000F0        656E5F53 656E6400 5F50795F 58444543 52454600 5F50795F
                                                                                                                                                                     | 000108        58494E43 52454600 5F50795F 49535F54 59504500 67656E5F
                                                                                                                                                                     | 000120        7365745F 6E616D65 00000000 67656E5F 6765745F 6E616D65
                                                                                                                                                                     | 000138        00000000 67656E5F 69746572 6E657874 00000000 67656E5F
                                                                                                                                                                     | 000150        74726176 65727365 00000000 5F50795F 5345545F 53495A45
                                                                                                                                                                     | 000168        00000000 5F50795F 5345545F 54595045 00000000 5F507954
                                                                                                                                                                     | 000180        7970655F 43686563 6B000000 67657464 7461626C 6573697A
                                                                                                                                                                     | 000198        65000000 6173796E 635F6765 6E5F7265 70720000 67656E5F







Wed Apr 15 07:30:04 CDT 2020  Page 193


                                                                                                                                                                     | 0001B0        636C6F73 655F6974 65720000 50794173 796E6347 656E5F4E
                                                                                                                                                                     | 0001C8        65770000 5F50794F 626A6563 745F494E 49540000 5F50795F
                                                                                                                                                                     | 0001E0        5345545F 52454643 4E540000 6173796E 635F6765 6E5F6173
                                                                                                                                                                     | 0001F8        656E6400 6173796E 635F6765 6E5F616E 65787400 6578635F
                                                                                                                                                                     | 000210        73746174 655F636C 65617200 5F507947 656E5F46 696E616C
                                                                                                                                                                     | 000228        697A6500 5F507941 73796E63 47656E5F 46696E69 00000000
                                                                                                                                                                     | 000240        6173796E 635F6765 6E5F6174 68726F77 00000000 6173796E
                                                                                                                                                                     | 000258        635F6765 6E5F6163 6C6F7365 00000000 67656E5F 69735F63
                                                                                                                                                                     | 000270        6F726F75 74696E65 00000000 67656E5F 67657479 69656C64
                                                                                                                                                                     | 000288        66726F6D 00000000 67656E5F 7365745F 7175616C 6E616D65
                                                                                                                                                                     | 0002A0        00000000 67656E5F 6765745F 7175616C 6E616D65 00000000
                                                                                                                                                                     | 0002B8        5F50795F 4D616B65 52656343 6865636B 00000000 5F50795F
                                                                                                                                                                     | 0002D0        49734D61 696E5468 72656164 00000000 636F6D70 7574655F
                                                                                                                                                                     | 0002E8        63725F6F 72696769 6E000000 636F726F 5F777261 70706572
                                                                                                                                                                     | 000300        5F73656E 64000000 636F726F 5F676574 5F63725F 61776169
                                                                                                                                                                     | 000318        74000000 5F507945 76616C5F 4576616C 4672616D 65000000
                                                                                                                                                                     | 000330        5F50794D 656D5F49 73507472 46726565 64000000 50795479
                                                                                                                                                                     | 000348        70655F48 61734665 61747572 65000000 6173796E 635F6765
                                                                                                                                                                     | 000360        6E5F7472 61766572 73650000 636F726F 5F777261 70706572
                                                                                                                                                                     | 000378        5F636C6F 73650000 636F726F 5F777261 70706572 5F746872
                                                                                                                                                                     | 000390        6F770000 6578635F 73746174 655F7472 61766572 73650000
                                                                                                                                                                     | 0003A8        5F507954 7970655F 48617346 65617475 72650000 5F507954
                                                                                                                                                                     | 0003C0        68726561 64537461 74655F47 45540000 5F50794F 626A6563
                                                                                                                                                                     | 0003D8        745F4661 73744361 6C6C0000 50795665 63746F72 63616C6C
                                                                                                                                                                     | 0003F0        5F4E4152 47530000 5F50794F 626A6563 745F494E 49545F56
                                                                                                                                                                     | 000408        41520000 5F507954 7970655F 43686563 6B457861 63740000
                                                                                                                                                                     | 000420        6173796E 635F6765 6E5F6173 656E645F 6E657700 50794F62
                                                                                                                                                                     | 000438        6A656374 5F43616C 6C4F6E65 41726700 5F50794F 626A6563
                                                                                                                                                                     | 000450        745F4361 6C6C4E6F 41726700 50794F62 6A656374 5F566563
                                                                                                                                                                     | 000468        746F7263 616C6C00 6173796E 635F6765 6E5F6173 656E645F
                                                                                                                                                                     | 000480        73656E64 00000000 6173796E 635F6765 6E5F696E 69745F68
                                                                                                                                                                     | 000498        6F6F6B73 00000000 636F726F 5F777261 70706572 5F646561
                                                                                                                                                                     | 0004B0        6C6C6F63 00000000 6173796E 635F6765 6E5F6174 68726F77
                                                                                                                                                                     | 0004C8        5F6E6577 00000000 6173796E 635F6765 6E5F6174 68726F77
                                                                                                                                                                     | 0004E0        5F73656E 64000000 6173796E 635F6765 6E5F6173 656E645F
                                                                                                                                                                     | 0004F8        636C6F73 65000000 6173796E 635F6765 6E5F6173 656E645F
                                                                                                                                                                     | 000510        7468726F 77000000 636F726F 5F777261 70706572 5F747261
                                                                                                                                                                     | 000528        76657273 65000000 636F726F 5F777261 70706572 5F697465
                                                                                                                                                                     | 000540        726E6578 74000000 67656E5F 6E65775F 77697468 5F717561
                                                                                                                                                                     | 000558        6C6E616D 65000000 5F50795F 49734D61 696E496E 74657270
                                                                                                                                                                     | 000570        72657465 72000000 50795665 63746F72 63616C6C 5F46756E
                                                                                                                                                                     | 000588        6374696F 6E000000 50794765 6E5F4E65 77576974 68517561
                                                                                                                                                                     | 0005A0        6C4E616D 65000000 6173796E 635F6765 6E5F6174 68726F77
                                                                                                                                                                     | 0005B8        5F636C6F 73650000 6173796E 635F6765 6E5F6174 68726F77
                                                                                                                                                                     | 0005D0        5F746872 6F770000 6173796E 635F6765 6E5F756E 77726170
                                                                                                                                                                     | 0005E8        5F76616C 75650000 5F50795F 4C656176 65526563 75727369
                                                                                                                                                                     | 000600        76654361 6C6C0000 5F50795F 456E7465 72526563 75727369
                                                                                                                                                                     | 000618        76654361 6C6C0000 6173796E 635F6765 6E5F6173 656E645F
                                                                                                                                                                     | 000630        6465616C 6C6F6300 5F50794F 626A6563 745F4743 5F545241
                                                                                                                                                                     | 000648        434B5F69 6D706C00 6173796E 635F6765 6E5F6174 68726F77
                                                                                                                                                                     | 000660        5F646561 6C6C6F63 00000000 6173796E 635F6765 6E5F6173
                                                                                                                                                                     | 000678        656E645F 69746572 6E657874 00000000 6173796E 635F6765
                                                                                                                                                                     | 000690        6E5F6173 656E645F 74726176 65727365 00000000 5F50794F
                                                                                                                                                                     | 0006A8        626A6563 745F4661 73744361 6C6C5473 74617465 00000000
                                                                                                                                                                     | 0006C0        5F507943 6F726F5F 47657441 77616974 61626C65 49746572
                                                                                                                                                                     | 0006D8        00000000 6173796E 635F6765 6E5F6174 68726F77 5F697465







Wed Apr 15 07:30:04 CDT 2020  Page 194


                                                                                                                                                                     | 0006F0        726E6578 74000000 6173796E 635F6765 6E5F6174 68726F77
                                                                                                                                                                     | 000708        5F747261 76657273 65000000 5F50794F 626A6563 745F4743
                                                                                                                                                                     | 000720        5F554E54 5241434B 5F696D70 6C000000 50794F62 6A656374
                                                                                                                                                                     | 000738        5F43616C 6C4D6574 686F644F 6E654172 67000000 50794F62
                                                                                                                                                                     | 000750        6A656374 5F43616C 6C4D6574 686F644E 6F417267 73000000
                                                                                                                                                                     | 000768        50794173 796E6347 656E5F43 6C656172 46726565 4C697374
                                                                                                                                                                     | 000780        73000000 5F50795F 54687265 61644361 6E48616E 646C6553
                                                                                                                                                                     | 000798        69676E61 6C730000 5F50794F 626A6563 745F5665 63746F72
                                                                                                                                                                     | 0007B0        63616C6C 54737461 74650000 5F507941 73796E63 47656E56
                                                                                                                                                                     | 0007C8        616C7565 57726170 7065724E 65770000 5F50794F 626A6563
                                                                                                                                                                     | 0007E0        745F4361 6C6C4D65 74686F64 49644F6E 65417267 00000000
                                                                                                                                                                     | 0007F8        5F50794F 626A6563 745F4361 6C6C4D65 74686F64 49644E6F
                                                                                                                                                                     | 000810        41726773 00000000 5F50794F 626A6563 745F5665 63746F72
                                                                                                                                                                     | 000828        63616C6C 4D657468 6F644964 00000000 5F507947 656E5F53
                                                                                                                                                                     | 000840        65745374 6F704974 65726174 696F6E56 616C7565 00000000
                                                                                                                                                                     | 000858        6173796E 635F6765 6E5F7772 61707065 645F7661 6C5F6465
                                                                                                                                                                     | 000870        616C6C6F 63000000 5F50795F 4C656176 65526563 75727369
                                                                                                                                                                     | 000888        76654361 6C6C5F69 6E6C696E 65000000 5F50795F 456E7465
                                                                                                                                                                     | 0008A0        72526563 75727369 76654361 6C6C5F69 6E6C696E 65000000
                                                                                                                                                                     | 0008B8        5F507952 756E7469 6D655374 6174655F 53657446 696E616C
                                                                                                                                                                     | 0008D0        697A696E 67000000 5F507952 756E7469 6D655374 6174655F
                                                                                                                                                                     | 0008E8        47657446 696E616C 697A696E 67000000 6173796E 635F6765
                                                                                                                                                                     | 000900        6E5F7772 61707065 645F7661 6C5F7472 61766572 73650000
                                                                                                                                                                     | 000918        5F50794F 626A6563 745F4745 545F5745 414B5245 46535F4C
                                                                                                                                                                     | 000930        49535450 54520000 5F507949 6E746572 70726574 65725374
                                                                                                                                                                     | 000948        6174655F 4745545F 554E5341 46450000 5F507952 756E7469
                                                                                                                                                                     | 000960        6D655374 6174655F 47657454 68726561 64537461 74650000
                                                                                                                                                                     | 000978        5F507947 656E5F46 65746368 53746F70 49746572 6174696F
                                                                                                                                                                     | 000990        6E56616C 75650000 5F50795F 54687265 61644361 6E48616E
                                                                                                                                                                     | 0009A8        646C6550 656E6469 6E674361 6C6C7300 6173656E 64287629
                                                                                                                                                                     | 0009C0        202D3E20 73656E64 20277627 20696E20 67656E65 7261746F
                                                                                                                                                                     | 0009D8        722E0000 636C6F73 65282920 2D3E2072 61697365 2047656E
                                                                                                                                                                     | 0009F0        65726174 6F724578 69742069 6E736964 65206765 6E657261
                                                                                                                                                                     | 000A08        746F722E 00000000 636C6F73 65282920 2D3E2072 61697365
                                                                                                                                                                     | 000A20        2047656E 65726174 6F724578 69742069 6E736964 6520636F
                                                                                                                                                                     | 000A38        726F7574 696E652E 00000000 61636C6F 73652829 202D3E20
                                                                                                                                                                     | 000A50        72616973 65204765 6E657261 746F7245 78697420 696E7369
                                                                                                                                                                     | 000A68        64652067 656E6572 61746F72 2E000000 61746872 6F772874
                                                                                                                                                                     | 000A80        79705B2C 76616C5B 2C74625D 5D29202D 3E207261 69736520
                                                                                                                                                                     | 000A98        65786365 7074696F 6E20696E 2067656E 65726174 6F722E00
                                                                                                                                                                     | 000AB0        73656E64 28617267 29202D3E 2073656E 64202761 72672720
                                                                                                                                                                     | 000AC8        696E746F 2067656E 65726174 6F722C0A 72657475 726E206E
                                                                                                                                                                     | 000AE0        65787420 7969656C 64656420 76616C75 65206F72 20726169
                                                                                                                                                                     | 000AF8        73652053 746F7049 74657261 74696F6E 2E000000 73656E64
                                                                                                                                                                     | 000B10        28617267 29202D3E 2073656E 64202761 72672720 696E746F
                                                                                                                                                                     | 000B28        20636F72 6F757469 6E652C0A 72657475 726E206E 65787420
                                                                                                                                                                     | 000B40        69746572 61746564 2076616C 7565206F 72207261 69736520
                                                                                                                                                                     | 000B58        53746F70 49746572 6174696F 6E2E0000 7468726F 77287479
                                                                                                                                                                     | 000B70        705B2C76 616C5B2C 74625D5D 29202D3E 20726169 73652065
                                                                                                                                                                     | 000B88        78636570 74696F6E 20696E20 67656E65 7261746F 722C0A72
                                                                                                                                                                     | 000BA0        65747572 6E206E65 78742079 69656C64 65642076 616C7565
                                                                                                                                                                     | 000BB8        206F7220 72616973 65205374 6F704974 65726174 696F6E2E
                                                                                                                                                                     | 000BD0        00000000 7468726F 77287479 705B2C76 616C5B2C 74625D5D
                                                                                                                                                                     | 000BE8        29202D3E 20726169 73652065 78636570 74696F6E 20696E20
                                                                                                                                                                     | 000C00        636F726F 7574696E 652C0A72 65747572 6E206E65 78742069
                                                                                                                                                                     | 000C18        74657261 74656420 76616C75 65206F72 20726169 73652053







Wed Apr 15 07:30:04 CDT 2020  Page 195


                                                                                                                                                                     | 000C30        746F7049 74657261 74696F6E 2E000000 63616E27 74207365
                                                                                                                                                                     | 000C48        6E64206E 6F6E2D4E 6F6E6520 76616C75 6520746F 2061206A
                                                                                                                                                                     | 000C60        7573742D 73746172 74656420 636F726F 7574696E 65000000
                                                                                                                                                                     | 000C78        6173796E 63206765 6E657261 746F7220 69676E6F 72656420
                                                                                                                                                                     | 000C90        47656E65 7261746F 72457869 74000000 67656E65 7261746F
                                                                                                                                                                     | 000CA8        7220616C 72656164 79206578 65637574 696E6700 636F726F
                                                                                                                                                                     | 000CC0        7574696E 6520616C 72656164 79206578 65637574 696E6700
                                                                                                                                                                     | 000CD8        6173796E 63206765 6E657261 746F7220 616C7265 61647920
                                                                                                                                                                     | 000CF0        65786563 7574696E 67000000 63616E27 74207365 6E64206E
                                                                                                                                                                     | 000D08        6F6E2D4E 6F6E6520 76616C75 6520746F 2061206A 7573742D
                                                                                                                                                                     | 000D20        73746172 74656420 67656E65 7261746F 72000000 63616E27
                                                                                                                                                                     | 000D38        74207365 6E64206E 6F6E2D4E 6F6E6520 76616C75 6520746F
                                                                                                                                                                     | 000D50        2061206A 7573742D 73746172 74656420 6173796E 63206765
                                                                                                                                                                     | 000D68        6E657261 746F7200 67656E65 7261746F 72207261 69736564
                                                                                                                                                                     | 000D80        2053746F 70497465 72617469 6F6E0000 636F726F 7574696E
                                                                                                                                                                     | 000D98        65207261 69736564 2053746F 70497465 72617469 6F6E0000
                                                                                                                                                                     | 000DB0        6173796E 63206765 6E657261 746F7220 72616973 65642053
                                                                                                                                                                     | 000DC8        746F7049 74657261 74696F6E 00000000 6173796E 63206765
                                                                                                                                                                     | 000DE0        6E657261 746F7220 72616973 65642053 746F7041 73796E63
                                                                                                                                                                     | 000DF8        49746572 6174696F 6E000000 636C6F73 65000000 67656E65
                                                                                                                                                                     | 000E10        7261746F 72206967 6E6F7265 64204765 6E657261 746F7245
                                                                                                                                                                     | 000E28        78697400 636F726F 7574696E 65206967 6E6F7265 64204765
                                                                                                                                                                     | 000E40        6E657261 746F7245 78697400 7468726F 77000000 5F5F6E61
                                                                                                                                                                     | 000E58        6D655F5F 00000000 6E616D65 206F6620 74686520 67656E65
                                                                                                                                                                     | 000E70        7261746F 72000000 5F5F7175 616C6E61 6D655F5F 00000000
                                                                                                                                                                     | 000E88        7175616C 69666965 64206E61 6D65206F 66207468 65206765
                                                                                                                                                                     | 000EA0        6E657261 746F7200 67695F79 69656C64 66726F6D 00000000
                                                                                                                                                                     | 000EB8        6F626A65 63742062 65696E67 20697465 72617465 64206279
                                                                                                                                                                     | 000ED0        20796965 6C642066 726F6D2C 206F7220 4E6F6E65 00000000
                                                                                                                                                                     | 000EE8        67695F66 72616D65 00000000 67695F72 756E6E69 6E670000
                                                                                                                                                                     | 000F00        67695F63 6F646500 73656E64 00000000 67656E65 7261746F
                                                                                                                                                                     | 000F18        72000000 6E616D65 206F6620 74686520 636F726F 7574696E
                                                                                                                                                                     | 000F30        65000000 7175616C 69666965 64206E61 6D65206F 66207468
                                                                                                                                                                     | 000F48        6520636F 726F7574 696E6500 63725F61 77616974 00000000
                                                                                                                                                                     | 000F60        6F626A65 63742062 65696E67 20617761 69746564 206F6E2C
                                                                                                                                                                     | 000F78        206F7220 4E6F6E65 00000000 63725F66 72616D65 00000000
                                                                                                                                                                     | 000F90        63725F72 756E6E69 6E670000 63725F63 6F646500 63725F6F
                                                                                                                                                                     | 000FA8        72696769 6E000000 636F726F 7574696E 65000000 636F726F
                                                                                                                                                                     | 000FC0        7574696E 655F7772 61707065 72000000 41207772 61707065
                                                                                                                                                                     | 000FD8        72206F62 6A656374 20696D70 6C656D65 6E74696E 67205F5F
                                                                                                                                                                     | 000FF0        61776169 745F5F20 666F7220 636F726F 7574696E 65732E00
                                                                                                                                                                     | 001008        6E616D65 206F6620 74686520 6173796E 63206765 6E657261
                                                                                                                                                                     | 001020        746F7200 7175616C 69666965 64206E61 6D65206F 66207468
                                                                                                                                                                     | 001038        65206173 796E6320 67656E65 7261746F 72000000 61675F61
                                                                                                                                                                     | 001050        77616974 00000000 61675F66 72616D65 00000000 61675F72
                                                                                                                                                                     | 001068        756E6E69 6E670000 61675F63 6F646500 6173656E 64000000
                                                                                                                                                                     | 001080        61746872 6F770000 61636C6F 73650000 5F5F636C 6173735F
                                                                                                                                                                     | 001098        67657469 74656D5F 5F000000 53656520 50455020 35383500
                                                                                                                                                                     | 0010B0        6173796E 635F6765 6E657261 746F7200 6173796E 635F6765
                                                                                                                                                                     | 0010C8        6E657261 746F725F 6173656E 64000000 6173796E 635F6765
                                                                                                                                                                     | 0010E0        6E657261 746F725F 77726170 7065645F 76616C75 65000000
                                                                                                                                                                     | 0010F8        6173796E 635F6765 6E657261 746F725F 61746872 6F770049
                                                                                                                                                                     | 001110        4F626A65 6374732F 67656E6F 626A6563 742E6300 2E2F496E
                                                                                                                                                                     | 001128        636C7564 652F6F62 6A656374 2E680049 50794279 7465735F
                                                                                                                                                                     | 001140        43686563 6B286279 7465636F 64652900 636F6465 5B305D20
                                                                                                                                                                     | 001158        213D2059 49454C44 5F46524F 4D004942 61726720 213D204E







Wed Apr 15 07:30:04 CDT 2020  Page 196


                                                                                                                                                                     | 001170        554C4C00 2E2F496E 636C7564 652F6370 7974686F 6E2F6162
                                                                                                                                                                     | 001188        73747261 63742E68 0049424D 63616C6C 61626C65 20213D20
                                                                                                                                                                     | 0011A0        4E554C4C 0049424D 50794361 6C6C6162 6C655F43 6865636B
                                                                                                                                                                     | 0011B8        2863616C 6C61626C 65290049 6F666673 6574203E 20300049
                                                                                                                                                                     | 0011D0        63616E6E 6F742072 65757365 20616C72 65616479 20617761
                                                                                                                                                                     | 0011E8        69746564 20636F72 6F757469 6E650049 662D3E66 5F626163
                                                                                                                                                                     | 001200        6B203D3D 204E554C 4C004942 662D3E66 5F626163 6B203D3D
                                                                                                                                                                     | 001218        20747374 6174652D 3E667261 6D650049 21507941 73796E63
                                                                                                                                                                     | 001230        47656E5F 43686563 6B457861 63742867 656E2900 25730049
                                                                                                                                                                     | 001248        72657420 3D3D2079 66004942 67656E2D 3E67695F 6672616D
                                                                                                                                                                     | 001260        652D3E66 5F6C6173 7469203E 3D203000 7468726F 77282920
                                                                                                                                                                     | 001278        74686972 64206172 67756D65 6E74206D 75737420 62652061
                                                                                                                                                                     | 001290        20747261 63656261 636B206F 626A6563 74004942 696E7374
                                                                                                                                                                     | 0012A8        616E6365 20657863 65707469 6F6E206D 6179206E 6F742068
                                                                                                                                                                     | 0012C0        61766520 61207365 70617261 74652076 616C7565 0049424D
                                                                                                                                                                     | 0012D8        65786365 7074696F 6E73206D 75737420 62652063 6C617373
                                                                                                                                                                     | 0012F0        6573206F 7220696E 7374616E 63657320 64657269 76696E67
                                                                                                                                                                     | 001308        2066726F 6D204261 73654578 63657074 696F6E2C 206E6F74
                                                                                                                                                                     | 001320        20257300 63616E6E 6F742072 65757365 20616C72 65616479
                                                                                                                                                                     | 001338        20617761 69746564 2061636C 6F736528 292F6174 68726F77
                                                                                                                                                                     | 001350        28290049 61636C6F 73652829 3A206173 796E6368 726F6E6F
                                                                                                                                                                     | 001368        75732067 656E6572 61746F72 20697320 616C7265 61647920
                                                                                                                                                                     | 001380        72756E6E 696E6700 61746872 6F772829 3A206173 796E6368
                                                                                                                                                                     | 001398        726F6E6F 75732067 656E6572 61746F72 20697320 616C7265
                                                                                                                                                                     | 0013B0        61647920 72756E6E 696E6700 6F2D3E61 67745F73 74617465
                                                                                                                                                                     | 0013C8        203D3D20 41574149 5441424C 455F5354 4154455F 49544552
                                                                                                                                                                     | 0013E0        0049424D 28282850 7947435F 48656164 202A2928 6F70292D
                                                                                                                                                                     | 0013F8        31292D3E 5F67635F 6E657874 20213D20 30290049 6F626A65
                                                                                                                                                                     | 001410        6374206E 6F742074 7261636B 65642062 79207468 65206761
                                                                                                                                                                     | 001428        72626167 6520636F 6C6C6563 746F7200 5F50794F 626A6563
                                                                                                                                                                     | 001440        745F4743 5F554E54 5241434B 0049424D 5F507941 73796E63
                                                                                                                                                                     | 001458        47656E57 72617070 65645661 6C75655F 43686563 6B457861
                                                                                                                                                                     | 001470        6374286F 29004942 63616E6E 6F742072 65757365 20616C72
                                                                                                                                                                     | 001488        65616479 20617761 69746564 205F5F61 6E657874 5F5F2829
                                                                                                                                                                     | 0014A0        2F617365 6E642829 0049424D 616E6578 7428293A 20617379
                                                                                                                                                                     | 0014B8        6E636872 6F6E6F75 73206765 6E657261 746F7220 69732061
                                                                                                                                                                     | 0014D0        6C726561 64792072 756E6E69 6E670049 50794173 796E6347
                                                                                                                                                                     | 0014E8        656E4153 656E645F 43686563 6B457861 6374286F 29004942
                                                                                                                                                                     | 001500        50795F49 535F5459 5045286F 2C20265F 50794173 796E6347
                                                                                                                                                                     | 001518        656E4153 656E645F 54797065 29004942 21282828 50794743
                                                                                                                                                                     | 001530        5F486561 64202A29 286F7029 2D31292D 3E5F6763 5F6E6578
                                                                                                                                                                     | 001548        7420213D 20302900 6F626A65 63742061 6C726561 64792074
                                                                                                                                                                     | 001560        7261636B 65642062 79207468 65206761 72626167 6520636F
                                                                                                                                                                     | 001578        6C6C6563 746F7200 5F50794F 626A6563 745F4743 5F545241
                                                                                                                                                                     | 001590        434B0049 2867632D 3E5F6763 5F707265 76202620 28322929
                                                                                                                                                                     | 0015A8        203D3D20 30004942 6F626A65 63742069 7320696E 2067656E
                                                                                                                                                                     | 0015C0        65726174 696F6E20 77686963 68206973 20676172 62616765
                                                                                                                                                                     | 0015D8        20636F6C 6C656374 65640049 28287569 6E747074 725F7429
                                                                                                                                                                     | 0015F0        6C617374 2026207E 5F507947 435F5052 45565F4D 41534B29
                                                                                                                                                                     | 001608        203D3D20 30004942 2E2F496E 636C7564 652F696E 7465726E
                                                                                                                                                                     | 001620        616C2F70 79636F72 655F6F62 6A656374 2E680049 3C617379
                                                                                                                                                                     | 001638        6E635F67 656E6572 61746F72 206F626A 65637420 25532061
                                                                                                                                                                     | 001650        74202570 3E004942 3C636F72 6F757469 6E65206F 626A6563
                                                                                                                                                                     | 001668        74202553 20617420 25703E00 5F5F7175 616C6E61 6D655F5F
                                                                                                                                                                     | 001680        206D7573 74206265 20736574 20746F20 61207374 72696E67
                                                                                                                                                                     | 001698        206F626A 65637400 5F5F6E61 6D655F5F 206D7573 74206265







Wed Apr 15 07:30:04 CDT 2020  Page 197


                                                                                                                                                                     | 0016B0        20736574 20746F20 61207374 72696E67 206F626A 65637400
                                                                                                                                                                     | 0016C8        3C67656E 65726174 6F72206F 626A6563 74202553 20617420
                                                                                                                                                                     | 0016E0        25703E00 76616C00 4F694F00 50795475 706C655F 43686563
                                                                                                                                                                     | 0016F8        6B286372 5F6F7269 67696E29 0049424D 5F5F6177 6169745F
                                                                                                                                                                     | 001710        5F282920 72657475 726E6564 20612063 6F726F75 74696E65
                                                                                                                                                                     | 001728        0049424D 5F5F6177 6169745F 5F282920 72657475 726E6564
                                                                                                                                                                     | 001740        206E6F6E 2D697465 7261746F 72206F66 20747970 65202725
                                                                                                                                                                     | 001758        2E313030 73270049 6F626A65 63742025 2E313030 73206361
                                                                                                                                                                     | 001770        6E277420 62652075 73656420 696E2027 61776169 74272065
                                                                                                                                                                     | 001788        78707265 7373696F 6E00




















































From report at bugs.python.org  Wed Apr 15 12:23:03 2020
From: report at bugs.python.org (hai shi)
Date: Wed, 15 Apr 2020 16:23:03 +0000
Subject: [issue40170] [C API] Make PyTypeObject structure an opaque structure
 in the public C API
In-Reply-To: <1585915023.07.0.846808236133.issue40170@roundup.psfhosted.org>
Message-ID: <1586967783.81.0.814993549859.issue40170@roundup.psfhosted.org>


hai shi <shihai1991 at 126.com> added the comment:

> It never prevented anyone to use a function of the C API :-)
Got it. If possible someone uses it, I will try to add a function to repalce it(MAYBE udpate this docs too;) )

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40170>
_______________________________________

From report at bugs.python.org  Wed Apr 15 13:08:34 2020
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 15 Apr 2020 17:08:34 +0000
Subject: [issue40249] __import__ doesn't honour globals
In-Reply-To: <1586558028.61.0.331520667517.issue40249@roundup.psfhosted.org>
Message-ID: <1586970514.61.0.0851280565542.issue40249@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

Algorithm is documented as part of the language reference: https://docs.python.org/3/reference/import.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40249>
_______________________________________

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: [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 13:45:38 2020
From: report at bugs.python.org (Jeffrey Quesnelle)
Date: Wed, 15 Apr 2020 17:45:38 +0000
Subject: [issue40294] Use-after-free crash if multiple interpreters import
 asyncio module
In-Reply-To: <1586971925.67.0.678462551955.issue40294@roundup.psfhosted.org>
Message-ID: <1586972738.0.0.0550888595575.issue40294@roundup.psfhosted.org>


Change by Jeffrey Quesnelle <jquesnelle at gmail.com>:


----------
keywords: +patch
pull_requests: +18890
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19542

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40294>
_______________________________________

From report at bugs.python.org  Wed Apr 15 13:51:06 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 15 Apr 2020 17:51:06 +0000
Subject: [issue40294] Use-after-free crash if multiple interpreters import
 asyncio module
In-Reply-To: <1586971925.67.0.678462551955.issue40294@roundup.psfhosted.org>
Message-ID: <1586973066.46.0.491660075322.issue40294@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

_asyncio should be ported to multiphase initialization (PEP 489) and its types converted to PyType_FromSpec() rather than using statically allocated types. See bpo-1635741.

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40294>
_______________________________________

From report at bugs.python.org  Wed Apr 15 13:52:15 2020
From: report at bugs.python.org (Russell Davis)
Date: Wed, 15 Apr 2020 17:52:15 +0000
Subject: [issue25680] Selector.select() hangs when there is nothing to select
In-Reply-To: <1448029102.96.0.470819036773.issue25680@psf.upfronthosting.co.za>
Message-ID: <1586973135.61.0.525039979209.issue25680@roundup.psfhosted.org>


Russell Davis <russell.davis at gmail.com> added the comment:

@gvanrossum PR is ready for review: https://github.com/python/cpython/pull/19508

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25680>
_______________________________________

From report at bugs.python.org  Wed Apr 15 14:13:01 2020
From: report at bugs.python.org (Steve Dower)
Date: Wed, 15 Apr 2020 18:13:01 +0000
Subject: [issue40293] Tag libffi build and sources in cpython-source-deps for
 3.9.0b1
In-Reply-To: <1586962962.85.0.815414541497.issue40293@roundup.psfhosted.org>
Message-ID: <1586974381.0.0.277271189526.issue40293@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

When we make a beta release, you can have a release artifact. Until then, if you're building against the master branch, you can use the dependency's "master" branch.

I've renamed the issue so it can serve as a reminder to tag whatever version we use for beta 1.

----------
title: cpython-source-deps project missing release for libffi commits -> Tag libffi build and sources in cpython-source-deps for 3.9.0b1
versions: +Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40293>
_______________________________________

From report at bugs.python.org  Wed Apr 15 14:22:17 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 15 Apr 2020 18:22:17 +0000
Subject: [issue40267] Error message differs when an expression is in an fstring
In-Reply-To: <1586728764.59.0.587923723315.issue40267@roundup.psfhosted.org>
Message-ID: <1586974937.81.0.421342540981.issue40267@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:


New changeset 9a4b38f66b3e674db94e07980e1cacb39e388c73 by Lysandros Nikolaou in branch 'master':
bpo-40267: Fix message when last input character produces a SyntaxError (GH-19521)
https://github.com/python/cpython/commit/9a4b38f66b3e674db94e07980e1cacb39e388c73


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40267>
_______________________________________

From report at bugs.python.org  Wed Apr 15 14:24:17 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 15 Apr 2020 18:24:17 +0000
Subject: [issue40267] Error message differs when an expression is in an fstring
In-Reply-To: <1586728764.59.0.587923723315.issue40267@roundup.psfhosted.org>
Message-ID: <1586975057.59.0.015370818135.issue40267@roundup.psfhosted.org>


Change by Guido van Rossum <guido at python.org>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40267>
_______________________________________

From report at bugs.python.org  Wed Apr 15 14:24:24 2020
From: report at bugs.python.org (Neil Schemenauer)
Date: Wed, 15 Apr 2020 18:24:24 +0000
Subject: [issue40255] Fixing Copy on Writes from reference counting
In-Reply-To: <1586619621.82.0.553262088399.issue40255@roundup.psfhosted.org>
Message-ID: <1586975064.62.0.506363193586.issue40255@roundup.psfhosted.org>


Neil Schemenauer <nas-python at arctrix.com> added the comment:

Eddie mentions in the PR about using memory arenas to contain immortal objects.  I think it could be worth investigating further.  With the current PR, the immortal status is dependent on the value of the refcnt field of the object.  Using immortal arenas might be faster because you can check if an object is immortal just based on its address (no data dependency on refcnt value).  

The fastest would be to create an immortal block as part of the BSS (uninitialized data).  Then, within incref/decref you use the location and size of the immortal arena (compile time constants) to test if the object is immortal.  Maybe could just check if the high bits of an object address match a constant mask (if immortal region is aligned and is power of 2 in size).  Slightly slower but more flexible would be to make the immortal arena size and location global variables.  That way, you can set the size of the region on startup.  Also would be more flexible in terms of ABI compatibility.  That would introduce one or two global loads within incref/decref but those values would almost certainly be in L1 cache.

Even more flexible would be to use a memory map to mark which arenas are immortal.  See my radix tree implementation for obmalloc:

https://bugs.python.org/issue37448

I would guess the radix tree lookups are too expensive to put in incref/decref.  Should probably test that though.

I had started doing an experiment with the arena approach before I noticed Eddie's comment about it.  I would like to see his version.  Here is a sketch of mine (not working yet):

- change new_arena() to initially allocate from an "immortal memory" region.  There are multiple ways to allocate that (BSS/uninitialized data, aligned_alloc(), etc).

- add a _PyMem_enable_immortal() call to switch obmalloc from using immortal arenas to regular ones.  Need to mess with some obmalloc data structures to switch arenas (usedpools, usable_arenas, unused_arena_objects).

- change incref/decref to check if immortal status has been enabled and if object address falls within immortal region.  If so, incref/decref don't do anything.

By default, the immortal arenas could be enabled on Python startup.  Call _PyMem_enable_immortal after startup but before running user code.  There could be a command-line option to disable the automatic call to _PyMem_enable_immortal() so that users like Instagram can do their pre-fork initialization before calling it.

Next step down the rabbit-hole could be to use something like Jeethu Rao's frozen module serializer and dump out all of the startup objects and put them into the BSS:

 https://bugs.python.org/issue34690

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40255>
_______________________________________

From report at bugs.python.org  Wed Apr 15 14:32:10 2020
From: report at bugs.python.org (Jason R. Coombs)
Date: Wed, 15 Apr 2020 18:32:10 +0000
Subject: [issue35967] Better platform.processor support
In-Reply-To: <1549895363.53.0.252912531241.issue35967@roundup.psfhosted.org>
Message-ID: <1586975530.63.0.00310181696329.issue35967@roundup.psfhosted.org>


Jason R. Coombs <jaraco at jaraco.com> added the comment:


New changeset 4b4e90a51848578dc06341777a929a0be4f4757f by Jason R. Coombs in branch 'master':
bpo-35967: Baseline values for uname -p (GH-12824)
https://github.com/python/cpython/commit/4b4e90a51848578dc06341777a929a0be4f4757f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35967>
_______________________________________

From report at bugs.python.org  Wed Apr 15 14:45:31 2020
From: report at bugs.python.org (Jason R. Coombs)
Date: Wed, 15 Apr 2020 18:45:31 +0000
Subject: [issue39667] Update zipfile.Path with zipp 3.0
In-Reply-To: <1581978881.84.0.42755558271.issue39667@roundup.psfhosted.org>
Message-ID: <1586976331.75.0.692241039101.issue39667@roundup.psfhosted.org>


Jason R. Coombs <jaraco at jaraco.com> added the comment:


New changeset 3e72de9e08b03a15875f5b226c5f096e567dab42 by Miss Islington (bot) in branch '3.8':
[3.8] bpo-39667: Sync zipp 3.0 (GH-18540) (GH-18701)
https://github.com/python/cpython/commit/3e72de9e08b03a15875f5b226c5f096e567dab42


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39667>
_______________________________________

From report at bugs.python.org  Wed Apr 15 14:46:11 2020
From: report at bugs.python.org (Jason R. Coombs)
Date: Wed, 15 Apr 2020 18:46:11 +0000
Subject: [issue39667] Update zipfile.Path with zipp 3.0
In-Reply-To: <1581978881.84.0.42755558271.issue39667@roundup.psfhosted.org>
Message-ID: <1586976371.8.0.820645858229.issue39667@roundup.psfhosted.org>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

In the 3.8 backport, I retained API compatibility and backported only the performance improvement code.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39667>
_______________________________________

From report at bugs.python.org  Wed Apr 15 14:47:56 2020
From: report at bugs.python.org (Jason R. Coombs)
Date: Wed, 15 Apr 2020 18:47:56 +0000
Subject: [issue35967] Better platform.processor support
In-Reply-To: <1549895363.53.0.252912531241.issue35967@roundup.psfhosted.org>
Message-ID: <1586976476.63.0.776736511398.issue35967@roundup.psfhosted.org>


Change by Jason R. Coombs <jaraco at jaraco.com>:


----------
versions: +Python 3.9 -Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35967>
_______________________________________

From report at bugs.python.org  Wed Apr 15 14:57:13 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 15 Apr 2020 18:57:13 +0000
Subject: [issue29255] selects.KqueueSelector behaves incorrectly when no fds
 are registered
In-Reply-To: <1484264107.13.0.0489042381572.issue29255@psf.upfronthosting.co.za>
Message-ID: <1586977033.0.0.709804279911.issue29255@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:


New changeset ba1bcffe5cafc1bb0ac6fdf9ecef51e75e342707 by Russell Davis in branch 'master':
bpo-29255: Wait in KqueueSelector.select when no fds are registered (GH-19508)
https://github.com/python/cpython/commit/ba1bcffe5cafc1bb0ac6fdf9ecef51e75e342707


----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29255>
_______________________________________

From report at bugs.python.org  Wed Apr 15 14:57:13 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 15 Apr 2020 18:57:13 +0000
Subject: [issue25680] Selector.select() hangs when there is nothing to select
In-Reply-To: <1448029102.96.0.470819036773.issue25680@psf.upfronthosting.co.za>
Message-ID: <1586977033.09.0.71097554341.issue25680@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:


New changeset ba1bcffe5cafc1bb0ac6fdf9ecef51e75e342707 by Russell Davis in branch 'master':
bpo-29255: Wait in KqueueSelector.select when no fds are registered (GH-19508)
https://github.com/python/cpython/commit/ba1bcffe5cafc1bb0ac6fdf9ecef51e75e342707


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25680>
_______________________________________

From report at bugs.python.org  Wed Apr 15 14:57:42 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 15 Apr 2020 18:57:42 +0000
Subject: [issue29255] selects.KqueueSelector behaves incorrectly when no fds
 are registered
In-Reply-To: <1484264107.13.0.0489042381572.issue29255@psf.upfronthosting.co.za>
Message-ID: <1586977062.08.0.932426787988.issue29255@roundup.psfhosted.org>


Change by Guido van Rossum <guido at python.org>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29255>
_______________________________________

From report at bugs.python.org  Wed Apr 15 15:05:49 2020
From: report at bugs.python.org (Jason R. Coombs)
Date: Wed, 15 Apr 2020 19:05:49 +0000
Subject: [issue35967] Better platform.processor support
In-Reply-To: <1549895363.53.0.252912531241.issue35967@roundup.psfhosted.org>
Message-ID: <1586977549.02.0.00804595167134.issue35967@roundup.psfhosted.org>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

The aformentioned test broke tests in buildbots: https://buildbot.python.org/all/#builders/105/builds/779

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35967>
_______________________________________

From report at bugs.python.org  Wed Apr 15 15:07:25 2020
From: report at bugs.python.org (Jason R. Coombs)
Date: Wed, 15 Apr 2020 19:07:25 +0000
Subject: [issue35967] Better platform.processor support
In-Reply-To: <1549895363.53.0.252912531241.issue35967@roundup.psfhosted.org>
Message-ID: <1586977645.76.0.701711292147.issue35967@roundup.psfhosted.org>


Change by Jason R. Coombs <jaraco at jaraco.com>:


----------
pull_requests: +18891
pull_request: https://github.com/python/cpython/pull/19544

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35967>
_______________________________________

From report at bugs.python.org  Wed Apr 15 15:28:50 2020
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 15 Apr 2020 19:28:50 +0000
Subject: [issue35967] Better platform.processor support
In-Reply-To: <1549895363.53.0.252912531241.issue35967@roundup.psfhosted.org>
Message-ID: <1586978930.19.0.89289871202.issue35967@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:

raspbian failure https://buildbot.python.org/all/#/builders/645/builds/31

----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35967>
_______________________________________

From report at bugs.python.org  Wed Apr 15 15:47:04 2020
From: report at bugs.python.org (Anthony Sottile)
Date: Wed, 15 Apr 2020 19:47:04 +0000
Subject: [issue40260] modulefinder traceback regression starting on Windows
In-Reply-To: <1586680620.99.0.514402715757.issue40260@roundup.psfhosted.org>
Message-ID: <1586980024.01.0.0156691300932.issue40260@roundup.psfhosted.org>


Anthony Sottile <asottile at umich.edu> added the comment:

This patch has broken debian's builds due to use of modulefinder -- notably the type of `file_info` changed as a side-effect of this patch and is now causing:

../debian/pymindeps.py:29: DeprecationWarning: the imp module is deprecated in favour of importlib; see the module's documentation for alternative uses
  import imp
Traceback (most recent call last):
  File "../debian/pymindeps.py", line 185, in <module>
    main(sys.argv[1:])
  File "../debian/pymindeps.py", line 178, in main
    mf.run_script(arg)
  File "/tmp/code/Lib/modulefinder.py", line 163, in run_script
    self.load_module('__main__', fp, pathname, stuff)
  File "../debian/pymindeps.py", line 91, in load_module
    suffix, mode, type = file_info
ValueError: not enough values to unpack (expected 3, got 2)


This is breaking python3.8 and python3.9 (should I open a separate issue or is it ok to continue discussion here?)

----------
nosy: +Anthony Sottile

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40260>
_______________________________________

From report at bugs.python.org  Wed Apr 15 15:54:01 2020
From: report at bugs.python.org (Russell Davis)
Date: Wed, 15 Apr 2020 19:54:01 +0000
Subject: [issue25680] Selector.select() hangs when there is nothing to select
In-Reply-To: <1448029102.96.0.470819036773.issue25680@psf.upfronthosting.co.za>
Message-ID: <1586980441.39.0.329721214224.issue25680@roundup.psfhosted.org>


Russell Davis <russell.davis at gmail.com> added the comment:

I think this got auto-closed due to a link in the PR. Note that, per https://github.com/python/cpython/pull/19508#issuecomment-613317021, the behavior is still inconsistent on windows.

I think the solution there will have to be a call to sleep() when the list of fds is empty.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25680>
_______________________________________

From report at bugs.python.org  Wed Apr 15 16:00:22 2020
From: report at bugs.python.org (Juan Arrivillaga)
Date: Wed, 15 Apr 2020 20:00:22 +0000
Subject: [issue39247] dataclass defaults and property don't work together
In-Reply-To: <1578418537.56.0.0565923550129.issue39247@roundup.psfhosted.org>
Message-ID: <1586980822.64.0.92954315773.issue39247@roundup.psfhosted.org>


Juan Arrivillaga <juanpa.arrivillaga at gmail.com> added the comment:

But when would you want to have a descriptor as an instance attribute? Descriptors must be in the class dictionary to work:

https://docs.python.org/3/reference/datamodel.html#implementing-descriptors

I suppose, you could want some container class of descriptor objects, but that seems like an extremely narrow use-case, compared to the normal and common use-case of descriptors acting like descriptors. I think special-casing descriptors make sense because they act in a special way.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39247>
_______________________________________

From report at bugs.python.org  Wed Apr 15 16:00:23 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 15 Apr 2020 20:00:23 +0000
Subject: [issue40257] Improve the use of __doc__ in pydoc
In-Reply-To: <1586638478.83.0.463728061154.issue40257@roundup.psfhosted.org>
Message-ID: <1586980823.83.0.482557837393.issue40257@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset fbf2786c4c89430e2067016603078cf3500cfe94 by Serhiy Storchaka in branch 'master':
bpo-40257: Output object's own docstring in pydoc (GH-19479)
https://github.com/python/cpython/commit/fbf2786c4c89430e2067016603078cf3500cfe94


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40257>
_______________________________________

From report at bugs.python.org  Wed Apr 15 16:06:54 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 15 Apr 2020 20:06:54 +0000
Subject: [issue25680] Selector.select() hangs when there is nothing to select
In-Reply-To: <1448029102.96.0.470819036773.issue25680@psf.upfronthosting.co.za>
Message-ID: <1586981214.84.0.559783330468.issue25680@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

How ironic, the other issue had to be closed manually. :-)

Reopening this one.

----------
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25680>
_______________________________________

From report at bugs.python.org  Wed Apr 15 16:27:22 2020
From: report at bugs.python.org (Steve Dower)
Date: Wed, 15 Apr 2020 20:27:22 +0000
Subject: [issue40260] modulefinder traceback regression starting on Windows
In-Reply-To: <1586680620.99.0.514402715757.issue40260@roundup.psfhosted.org>
Message-ID: <1586982442.73.0.352738501395.issue40260@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Go ahead and fix it against this one.

----------
resolution: fixed -> 
stage: resolved -> needs patch
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40260>
_______________________________________

From report at bugs.python.org  Wed Apr 15 16:27:44 2020
From: report at bugs.python.org (Steve Dower)
Date: Wed, 15 Apr 2020 20:27:44 +0000
Subject: [issue40260] modulefinder traceback regression starting on Windows
In-Reply-To: <1586680620.99.0.514402715757.issue40260@roundup.psfhosted.org>
Message-ID: <1586982464.66.0.645504425361.issue40260@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Would be ideal to add a test that hits this case as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40260>
_______________________________________

From report at bugs.python.org  Wed Apr 15 16:28:31 2020
From: report at bugs.python.org (Jason R. Coombs)
Date: Wed, 15 Apr 2020 20:28:31 +0000
Subject: [issue35967] Better platform.processor support
In-Reply-To: <1549895363.53.0.252912531241.issue35967@roundup.psfhosted.org>
Message-ID: <1586982511.66.0.360431118492.issue35967@roundup.psfhosted.org>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

I'm hoping that PR 19544 fixes the issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35967>
_______________________________________

From report at bugs.python.org  Wed Apr 15 16:34:50 2020
From: report at bugs.python.org (Barry Alan Scott)
Date: Wed, 15 Apr 2020 20:34:50 +0000
Subject: [issue40260] modulefinder traceback regression starting on Windows
In-Reply-To: <1586680620.99.0.514402715757.issue40260@roundup.psfhosted.org>
Message-ID: <1586982890.7.0.28398619959.issue40260@roundup.psfhosted.org>


Barry Alan Scott <barry-scott at users.sourceforge.net> added the comment:

I need to see the code of pymindeps to understand what you are doing and how to fix this. Can you post a URL to the source please?

Are you aware that load_module() changed in other ways that are required to fix the bug?

You may have to change yout pymindeps code anyway even with the mode restored to the tuple.

Steve: Do I need a new PR or just commit a fix to the same branch?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40260>
_______________________________________

From report at bugs.python.org  Wed Apr 15 16:36:10 2020
From: report at bugs.python.org (Michael Felt)
Date: Wed, 15 Apr 2020 20:36:10 +0000
Subject: [issue39953] Let's update ssl error codes
In-Reply-To: <1586966012.06.0.705872450565.issue39953@roundup.psfhosted.org>
Message-ID: <043F1C52-9AD6-4087-9ACE-74197BF5096F@felt.demon.nl>


Michael Felt <aixtools at felt.demon.nl> added the comment:

I did update, and saw that there was one more patch applied. 

I think that fixed the define issues, but there may be a new concern. Ran out of time to document it today. 

Will post tomorrow. 

Sent from my iPhone

> On 15 Apr 2020, at 17:53, SilentGhost <report at bugs.python.org> wrote:
> 
> ?
> SilentGhost <ghost.adh at runbox.com> added the comment:
> 
> Michael, could you try with the latest fix in 584a3cfda4?
> 
> ----------
> nosy: +SilentGhost
> 
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue39953>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39953>
_______________________________________

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: [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:40:03 2020
From: report at bugs.python.org (Barry Alan Scott)
Date: Wed, 15 Apr 2020 20:40:03 +0000
Subject: [issue40260] modulefinder traceback regression starting on Windows
In-Reply-To: <1586680620.99.0.514402715757.issue40260@roundup.psfhosted.org>
Message-ID: <1586983203.83.0.652872809855.issue40260@roundup.psfhosted.org>


Barry Alan Scott <barry-scott at users.sourceforge.net> added the comment:

Regarding test case. I will need to know what pymindeps is doing to be able to design a suitable test case.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40260>
_______________________________________

From report at bugs.python.org  Wed Apr 15 16:45:00 2020
From: report at bugs.python.org (Anthony Sottile)
Date: Wed, 15 Apr 2020 20:45:00 +0000
Subject: [issue40260] modulefinder traceback regression starting on Windows
In-Reply-To: <1586680620.99.0.514402715757.issue40260@roundup.psfhosted.org>
Message-ID: <1586983500.8.0.405619250707.issue40260@roundup.psfhosted.org>


Anthony Sottile <asottile at umich.edu> added the comment:

I'm admittedly a little unfamiliar with what it does as well -- I'm mostly repackaging debian sources for deadsnakes.  If I'm correct in my assumption, it is attempting to find a minimal set of modules to package into `python3-minimal` and ensure that that set is correct

here's my current version of the source: https://github.com/deadsnakes/python3.9-nightly/blob/3eb45671e2f1910a6f117580f1733e431cce8a6e/debian/pymindeps.py

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40260>
_______________________________________

From report at bugs.python.org  Wed Apr 15 16:45:50 2020
From: report at bugs.python.org (Anthony Sottile)
Date: Wed, 15 Apr 2020 20:45:50 +0000
Subject: [issue40260] modulefinder traceback regression starting on Windows
In-Reply-To: <1586680620.99.0.514402715757.issue40260@roundup.psfhosted.org>
Message-ID: <1586983550.04.0.205061760256.issue40260@roundup.psfhosted.org>


Anthony Sottile <asottile at umich.edu> added the comment:

(additionally, I'm not sure this should be backported to python3.8, especially with changed behaviour)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40260>
_______________________________________

From report at bugs.python.org  Wed Apr 15 16:47:57 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 15 Apr 2020 20:47:57 +0000
Subject: [issue40257] Improve the use of __doc__ in pydoc
In-Reply-To: <1586638478.83.0.463728061154.issue40257@roundup.psfhosted.org>
Message-ID: <1586983677.48.0.707427540485.issue40257@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +18892
pull_request: https://github.com/python/cpython/pull/19546

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40257>
_______________________________________

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: [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 17:19:30 2020
From: report at bugs.python.org (Zachary Ware)
Date: Wed, 15 Apr 2020 21:19:30 +0000
Subject: [issue40270] activate (or include) json1 extension in sqlite
In-Reply-To: <1586770672.18.0.207799300786.issue40270@roundup.psfhosted.org>
Message-ID: <1586985570.15.0.979587827473.issue40270@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:


New changeset 58d6f2ee3aeb699156d4784acccd2910d27982e7 by Ammar Askar in branch 'master':
bpo-40270: Enable json extension in Windows sqlite extension (GH-19528)
https://github.com/python/cpython/commit/58d6f2ee3aeb699156d4784acccd2910d27982e7


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40270>
_______________________________________

From report at bugs.python.org  Wed Apr 15 17:39:27 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 15 Apr 2020 21:39:27 +0000
Subject: [issue40295] doctest handling of multiline strings is broken
In-Reply-To: <1586983033.33.0.799206208911.issue40295@roundup.psfhosted.org>
Message-ID: <1586986767.37.0.598847434642.issue40295@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Did you try to run the tested function in the interactive Python interpreter? Did you get what you expected?

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40295>
_______________________________________

From report at bugs.python.org  Wed Apr 15 17:50:53 2020
From: report at bugs.python.org (Carl Meyer)
Date: Wed, 15 Apr 2020 21:50:53 +0000
Subject: [issue40255] Fixing Copy on Writes from reference counting
In-Reply-To: <1586619621.82.0.553262088399.issue40255@roundup.psfhosted.org>
Message-ID: <1586987453.24.0.187620498143.issue40255@roundup.psfhosted.org>


Carl Meyer <carl at oddbird.net> added the comment:

> I would be interested to hear the answer to Antoine's question which is basically: why not using the multiprocessing fork server?

Concretely, because for a long time we have used the uWSGI application server and it manages forking worker processes (among other things), and AFAIK nobody has yet proposed trying to replace that with something built around the multiprocessing module. I'm actually not aware of any popular Python WSGI application server built on top of the multiprocessing module (but some may exist).

What problem do you have in mind that the fork server would solve? How is it related to this issue? I looked at the docs and don't see that it does anything to help sharing Python objects' memory between forked processes without CoW.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40255>
_______________________________________

From report at bugs.python.org  Wed Apr 15 17:55:12 2020
From: report at bugs.python.org (Zachary Ware)
Date: Wed, 15 Apr 2020 21:55:12 +0000
Subject: [issue40270] activate (or include) json1 extension in sqlite
In-Reply-To: <1586770672.18.0.207799300786.issue40270@roundup.psfhosted.org>
Message-ID: <1586987712.14.0.484306252427.issue40270@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

This has been done in the macOS installer since 9625bf520e08828e36bc3b1d043af679eb5f993d, so this is now done.  I won't backport it due to the inevitable confusion over which patch version of which branch started including it on Windows; it's much easier to just say "3.9" :)

Thanks to Ammar for the patch!

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40270>
_______________________________________

From report at bugs.python.org  Wed Apr 15 17:58:17 2020
From: report at bugs.python.org (Steve Dower)
Date: Wed, 15 Apr 2020 21:58:17 +0000
Subject: [issue40260] modulefinder traceback regression starting on Windows
In-Reply-To: <1586680620.99.0.514402715757.issue40260@roundup.psfhosted.org>
Message-ID: <1586987897.44.0.488123333244.issue40260@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

The 3.8 behaviour is clearly broken, so backporting is fine. Also, io.open_code() is a security feature.

The core of the issue is that apparently load_module() is a public API, and the file_info parameter used to be a 3-tuple and is now a 2-tuple.

AFAICT, the fix should restore the 3-tuple everywhere and just ignore the mode parameter. The test should pass in a 3-tuple and make sure that it doesn't crash like this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40260>
_______________________________________

From report at bugs.python.org  Wed Apr 15 18:02:13 2020
From: report at bugs.python.org (Steve Dower)
Date: Wed, 15 Apr 2020 22:02:13 +0000
Subject: [issue40260] modulefinder traceback regression starting on Windows
In-Reply-To: <1586680620.99.0.514402715757.issue40260@roundup.psfhosted.org>
Message-ID: <1586988133.27.0.338993312483.issue40260@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Sorry, misready. They're monkeypatching the API. It isn't documented, but it's also not clearly internal.

We don't have a strong need to change the meaning of that argument though, so best to leave it as it was and not break anyone.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40260>
_______________________________________

From report at bugs.python.org  Wed Apr 15 18:09:33 2020
From: report at bugs.python.org (Steve Dower)
Date: Wed, 15 Apr 2020 22:09:33 +0000
Subject: [issue40255] Fixing Copy on Writes from reference counting
In-Reply-To: <1586619621.82.0.553262088399.issue40255@roundup.psfhosted.org>
Message-ID: <1586988573.5.0.623229954189.issue40255@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

> What problem do you have in mind that the fork server would solve?

My understanding is that the fork server solves the *general* problem of running arbitrary code before fork by making sure that only CPython/multiprocessing gets to run code before fork.

In this specific case where you're carefully running only forkable code at startup, it presumably won't help.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40255>
_______________________________________

From report at bugs.python.org  Wed Apr 15 18:14:23 2020
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 15 Apr 2020 22:14:23 +0000
Subject: [issue40255] Fixing Copy on Writes from reference counting
In-Reply-To: <1586619621.82.0.553262088399.issue40255@roundup.psfhosted.org>
Message-ID: <1586988863.25.0.933577553043.issue40255@roundup.psfhosted.org>


Antoine Pitrou <solipsis at pitrou.net> added the comment:

Steve is right.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40255>
_______________________________________

From report at bugs.python.org  Wed Apr 15 18:52:50 2020
From: report at bugs.python.org (=?utf-8?q?Filip_Rembia=C5=82kowski?=)
Date: Wed, 15 Apr 2020 22:52:50 +0000
Subject: [issue40295] doctest handling of multiline strings is broken
In-Reply-To: <1586983033.33.0.799206208911.issue40295@roundup.psfhosted.org>
Message-ID: <1586991170.56.0.417051882317.issue40295@roundup.psfhosted.org>


Filip Rembia?kowski <filip.rembialkowski at gmail.com> added the comment:

@Serhiy, Thank you for feedback. 

Yes the "testme" function (indeed trivial) works as expected - both in interactive Python interpreter and in script file. 

If you go to Lib/doctest.py, search for "string-identical" and debug my example there, you will see the problem is real.

I don't see an easy fix for the problem, I only suspect it's related to io.StringIO getvalue() method.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40295>
_______________________________________

From report at bugs.python.org  Wed Apr 15 19:13:58 2020
From: report at bugs.python.org (Sadhana Srinivasan)
Date: Wed, 15 Apr 2020 23:13:58 +0000
Subject: [issue23082] pathlib relative_to() can give confusing error message
In-Reply-To: <1418909839.25.0.648032443428.issue23082@psf.upfronthosting.co.za>
Message-ID: <1586992438.35.0.74876596002.issue23082@roundup.psfhosted.org>


Sadhana Srinivasan <sadhanasrinivasan at pm.me> added the comment:

I'll work on this. 

I tried to come up with a single error message but having two different error messages seems like a better idea to me. One for when the path isn't a subpath and one for when absolute and relative paths are mixed. Basically to explain this:

>>> Path("/Users/rotuna/Documents/cpython/Libs").relative_to(Path("./Libs"))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/rotuna/Documents/cpython/Lib/pathlib.py", line 907, in relative_to
    raise ValueError("{!r} is not a subpath of{!r}. NOTE: If this is not true, use absolute paths"
ValueError: '/Users/rotuna/Documents/cpython/Libs' does not start with 'Libs'

----------
nosy: +rotuna

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23082>
_______________________________________

From report at bugs.python.org  Wed Apr 15 19:15:57 2020
From: report at bugs.python.org (=?utf-8?q?Filip_Rembia=C5=82kowski?=)
Date: Wed, 15 Apr 2020 23:15:57 +0000
Subject: [issue40295] doctest handling of multiline strings is broken
In-Reply-To: <1586983033.33.0.799206208911.issue40295@roundup.psfhosted.org>
Message-ID: <1586992557.12.0.547775280361.issue40295@roundup.psfhosted.org>


Filip Rembia?kowski <filip.rembialkowski at gmail.com> added the comment:

Actually, the behavior does not depend on leading spaces, and test case can be isolated even further. Sample is attached [doctest-bugs-2.py].

----------
Added file: https://bugs.python.org/file49066/doctest-bugs-2.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40295>
_______________________________________

From report at bugs.python.org  Wed Apr 15 19:39:24 2020
From: report at bugs.python.org (Graham Dumpleton)
Date: Wed, 15 Apr 2020 23:39:24 +0000
Subject: [issue22213] Make pyvenv style virtual environments easier to
 configure when embedding Python
In-Reply-To: <1408275761.36.0.915361061447.issue22213@psf.upfronthosting.co.za>
Message-ID: <1586993964.21.0.733408086604.issue22213@roundup.psfhosted.org>


Graham Dumpleton <Graham.Dumpleton at gmail.com> added the comment:

For the record. Since virtualenv 20.0.0 (or there about) switched to the python -m venv style virtual environment structure, the C API for embedding when using a virtual environment is now completely broken on Windows. The same workaround used on UNIX doesn't work on Windows.

The only known workaround is in the initial Python code you load, to add:

import site
site.addsitedir('C:/some/path/to/pythonX.Y/Lib/site-packages')

to at least force it to use the site-packages directory from the virtual environment.

As to mod_wsgi, means that on Windows the WSGIPythonHome directive no longer works anymore and have to suggest that workaround instead.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22213>
_______________________________________

From report at bugs.python.org  Wed Apr 15 19:46:44 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 15 Apr 2020 23:46:44 +0000
Subject: [issue40290] Add z_score to statistics.NormalDist
In-Reply-To: <1586920449.06.0.712419472387.issue40290@roundup.psfhosted.org>
Message-ID: <1586994404.83.0.055976324458.issue40290@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
keywords: +patch
pull_requests: +18893
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19547

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40290>
_______________________________________

From report at bugs.python.org  Wed Apr 15 19:49:07 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 15 Apr 2020 23:49:07 +0000
Subject: [issue40290] Add zscore to statistics.NormalDist
In-Reply-To: <1586920449.06.0.712419472387.issue40290@roundup.psfhosted.org>
Message-ID: <1586994547.06.0.613757978744.issue40290@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Trying out various names in code examples, zscore() was a clear winner over z_score().  Also, the name matches what is used in R and numpy.

----------
title: Add z_score to statistics.NormalDist -> Add zscore to statistics.NormalDist

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40290>
_______________________________________

From report at bugs.python.org  Wed Apr 15 19:55:39 2020
From: report at bugs.python.org (Jason R. Coombs)
Date: Wed, 15 Apr 2020 23:55:39 +0000
Subject: [issue35967] Better platform.processor support
In-Reply-To: <1549895363.53.0.252912531241.issue35967@roundup.psfhosted.org>
Message-ID: <1586994939.78.0.782327676819.issue35967@roundup.psfhosted.org>


Jason R. Coombs <jaraco at jaraco.com> added the comment:


New changeset e72cbcb346cfcc1ed7741ed6baf1929764e1ee74 by Jason R. Coombs in branch 'master':
bpo-35967: Make test_platform.test_uname_processor more lenient to satisfy build bots. (GH-19544)
https://github.com/python/cpython/commit/e72cbcb346cfcc1ed7741ed6baf1929764e1ee74


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35967>
_______________________________________

From report at bugs.python.org  Wed Apr 15 21:30:06 2020
From: report at bugs.python.org (Carl Meyer)
Date: Thu, 16 Apr 2020 01:30:06 +0000
Subject: [issue40255] Fixing Copy on Writes from reference counting
In-Reply-To: <1586619621.82.0.553262088399.issue40255@roundup.psfhosted.org>
Message-ID: <1587000606.7.0.728513210102.issue40255@roundup.psfhosted.org>


Carl Meyer <carl at oddbird.net> added the comment:

Makes sense. Yes, caution is required about what code runs before fork, but forkserver?s solution for that would be a non-starter for us, since it would ensure that we can share no basically no memory at all between worker processes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40255>
_______________________________________

From report at bugs.python.org  Wed Apr 15 22:30:42 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Thu, 16 Apr 2020 02:30:42 +0000
Subject: [issue40295] doctest handling of multiline strings is broken
In-Reply-To: <1586983033.33.0.799206208911.issue40295@roundup.psfhosted.org>
Message-ID: <1587004242.35.0.960808010223.issue40295@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

Have you tried calling multiline_output() in the REPL?

It does *not* show your expected output:

    # expected
    First line
    Second line


but the string repr():

    # actual
    'First line\nSecond line\n'



Change your doctest to either:


    >>> multiline_output()
    'First line\\nSecond line\\n'

(note that you must escape the backslashes) or:

    >>> print(multiline_output())
    First line
    Second line
    <BLANKLINE>


Note that the "<BLANKLINE>" needs to be written literally, as described here:

https://docs.python.org/3/library/doctest.html#doctest.DONT_ACCEPT_BLANKLINE

----------
nosy: +steven.daprano
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40295>
_______________________________________

From report at bugs.python.org  Wed Apr 15 22:46:10 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Thu, 16 Apr 2020 02:46:10 +0000
Subject: [issue40295] doctest handling of multiline strings is broken
In-Reply-To: <1586983033.33.0.799206208911.issue40295@roundup.psfhosted.org>
Message-ID: <1587005170.33.0.115571076833.issue40295@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

By the way Filip, you were told on the Stackoverflow page that the output was correct and that you were not using doctest correctly. Serhiy also hinted to you that you should check the output in the REPL and you falsely claimed that it gave the expected output, but it doesn't:

    py> multiline_output()
    'First line\nSecond line\n'

which is nothing like the output you put in your doctest.

This is not a bug in doctest. The very first line of the doctest documentation says:

    The doctest module searches for pieces of text that look like
    interactive Python sessions

so this is expected and documented behaviour, not a bug.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40295>
_______________________________________

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: [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  Wed Apr 15 23:27:00 2020
From: report at bugs.python.org (Karl Ding)
Date: Thu, 16 Apr 2020 03:27:00 +0000
Subject: [issue40297] test_socket.CANTest is broken at HEAD on master
In-Reply-To: <1587007502.68.0.180919322143.issue40297@roundup.psfhosted.org>
Message-ID: <1587007620.3.0.640769455531.issue40297@roundup.psfhosted.org>


Change by Karl Ding <karl.jw.ding at gmail.com>:


----------
keywords: +patch
pull_requests: +18894
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19548

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40297>
_______________________________________

From report at bugs.python.org  Thu Apr 16 00:14:39 2020
From: report at bugs.python.org (Eddie Elizondo)
Date: Thu, 16 Apr 2020 04:14:39 +0000
Subject: [issue40255] Fixing Copy on Writes from reference counting
In-Reply-To: <1586619621.82.0.553262088399.issue40255@roundup.psfhosted.org>
Message-ID: <1587010479.1.0.413781911579.issue40255@roundup.psfhosted.org>


Eddie Elizondo <eduardo.elizondorueda at gmail.com> added the comment:

I was able to get an equal (maybe slightly better) performance by following the advice from Steve and Neil and skipping reference counting of instances that we know are immortal.

It seems that by getting performance parity, we should be able to ease most of the concerns raised so far.

I've updated the PR to now immortalize:
* All static types (i.e: PyType_Type, etc.)
* All small ints (-5 to 256)
* The following Singletons: PyTrue, PyFalse, PyNone
* And the heap after the runtime is initialized (in pymain_main)

A quick caveat, immortalizing the runtime heap caused ~6 or so tests to fail since they depend on shutdown behavior which this now changes. In the PR I commented out the call to `_PyGC_ImmortalizeHeap` in `pymain_main` to pass the CI. Ignoring these failing tests for now, these are the benchmarks numbers that I got from pyperformance:


Baseline (master branch):
unpack_sequence: Mean +- std dev: 76.0 ns +- 4.9 ns
richards: Mean +- std dev: 116 ms +- 8 ms
fannkuch: Mean +- std dev: 764 ms +- 24 ms
pidigits: Mean +- std dev: 261 ms +- 7 ms

Immortalizing known immortals objects (Latest PR)
unpack_sequence: Mean +- std dev: 74.7 ns +- 5.1 ns
richards: Mean +- std dev: 112 ms +- 5 ms
fannkuch: Mean +- std dev: 774 ms +- 24 ms
pidigits: Mean +- std dev: 262 ms +- 11 ms

Only adding immortal branch (The commit that Pablo benchmarked)
unpack_sequence: Mean +- std dev: 93.1 ns +- 5.7 ns
richards: Mean +- std dev: 124 ms +- 4 ms
fannkuch: Mean +- std dev: 861 ms +- 26 ms
pidigits: Mean +- std dev: 269 ms +- 7 ms


The performance of Immortal Objects by default seems to now be within error of the master branch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40255>
_______________________________________

From report at bugs.python.org  Thu Apr 16 00:27:55 2020
From: report at bugs.python.org (Eddie Elizondo)
Date: Thu, 16 Apr 2020 04:27:55 +0000
Subject: [issue40255] Fixing Copy on Writes from reference counting
In-Reply-To: <1586619621.82.0.553262088399.issue40255@roundup.psfhosted.org>
Message-ID: <1587011275.48.0.347155047905.issue40255@roundup.psfhosted.org>


Eddie Elizondo <eduardo.elizondorueda at gmail.com> added the comment:

Neil:
> The fastest would be to create an immortal block as part of the BSS (uninitialized data).

That's an interesting idea, definitely worth exploring and we can probably get some perf win out of it. And yes, using the frozen modules is definitely a step forward and we can leverage that to move these instances into the rodata section of the binary.
 
> I had started doing an experiment with the arena approach before I noticed Eddie's comment about it.  I would like to see his version.

What I had written up is slightly different from what you mentioned. I was mostly concerned about having a small object that we did not reach through the GC roots. If this small object would get a reference count bump, the whole arena would Copy on Write.

I added a commit to the PR with this Arena Immortalization so that you could take a look at the implementation: https://github.com/python/cpython/pull/19474/commits/b29c8ffd3faf99fc5c9885d2a4c6c3c6d5768c8c

The idea is to walk all the arena's pools to mark them as immortal by using a new word added to pool_header. This word would help us identify if the pool is immortal on every pyalloc and pydealloc.

I still get some tests breaking with this, I haven't tried to debug it though

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40255>
_______________________________________

From report at bugs.python.org  Thu Apr 16 00:42:53 2020
From: report at bugs.python.org (Eddie Elizondo)
Date: Thu, 16 Apr 2020 04:42:53 +0000
Subject: [issue40255] Fixing Copy on Writes from reference counting
In-Reply-To: <1586619621.82.0.553262088399.issue40255@roundup.psfhosted.org>
Message-ID: <1587012173.18.0.840304478339.issue40255@roundup.psfhosted.org>


Eddie Elizondo <eduardo.elizondorueda at gmail.com> added the comment:

After the added optimizations and assuming that running this more rigorously (i.e PGO + LTO + full cpu isolation + speed.python.org machine) also shows the PR as perf neutral, what are people's thoughts so far?

Would this be enough to consider adding this change by default?

Are there still any concerns regarding correctness? It seems like most of the questions raised so far have already been addressed

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40255>
_______________________________________

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: [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:07:38 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 16 Apr 2020 08:07:38 +0000
Subject: [issue40298] Type annotation objects (Tuple, List,
 etc.) register as callable()
In-Reply-To: <1587022037.69.0.998051306567.issue40298@roundup.psfhosted.org>
Message-ID: <1587024458.59.0.788052283668.issue40298@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +gvanrossum, levkivskyi

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40298>
_______________________________________

From report at bugs.python.org  Thu Apr 16 04:14:40 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 16 Apr 2020 08:14:40 +0000
Subject: [issue40296] help(list[int]) fails
In-Reply-To: <1586983817.03.0.686824683966.issue40296@roundup.psfhosted.org>
Message-ID: <1587024880.76.0.23757492688.issue40296@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

The problem is that isinstance(list[int], type) returns True, but list[int] is not actually an instance of type.

>>> isinstance(list[int], type)
True
>>> issubclass(type(list[int]), type)
False
>>> type.__subclasses__(list[int])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: descriptor '__subclasses__' for 'type' objects doesn't apply to a 'types.GenericAlias' object

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40296>
_______________________________________

From report at bugs.python.org  Thu Apr 16 04:29:21 2020
From: report at bugs.python.org (fireattack)
Date: Thu, 16 Apr 2020 08:29:21 +0000
Subject: [issue40093] ThreadPoolExecutor with wait=True shuts down too early
In-Reply-To: <1585351302.94.0.0578585326748.issue40093@roundup.psfhosted.org>
Message-ID: <1587025761.2.0.468241465565.issue40093@roundup.psfhosted.org>


fireattack <human.peng at gmail.com> added the comment:

>Yes, you are right. This is a feature of the ThreadPoolExecutor.

So is there any way to make the Executor actually wait and accept new job(s) after a while? I tried as_completed(), wait(), none seem to work.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40093>
_______________________________________

From report at bugs.python.org  Thu Apr 16 04:30:21 2020
From: report at bugs.python.org (Barry Alan Scott)
Date: Thu, 16 Apr 2020 08:30:21 +0000
Subject: [issue40260] modulefinder traceback regression starting on Windows
In-Reply-To: <1586680620.99.0.514402715757.issue40260@roundup.psfhosted.org>
Message-ID: <1587025821.72.0.96727137412.issue40260@roundup.psfhosted.org>


Change by Barry Alan Scott <barry-scott at users.sourceforge.net>:


----------
pull_requests: +18895
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/19549

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40260>
_______________________________________

From report at bugs.python.org  Thu Apr 16 04:47:10 2020
From: report at bugs.python.org (Barry Alan Scott)
Date: Thu, 16 Apr 2020 08:47:10 +0000
Subject: [issue40260] modulefinder traceback regression starting on Windows
In-Reply-To: <1586680620.99.0.514402715757.issue40260@roundup.psfhosted.org>
Message-ID: <1587026830.54.0.253591704986.issue40260@roundup.psfhosted.org>


Barry Alan Scott <barry-scott at users.sourceforge.net> added the comment:

I have the fix coded and tested.

I run out of git knowledge to update the PR branch so that I can push the fix.

I'll work on it more later in the day.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40260>
_______________________________________

From report at bugs.python.org  Thu Apr 16 04:49:32 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 16 Apr 2020 08:49:32 +0000
Subject: [issue40298] Type annotation objects (Tuple, List,
 etc.) register as callable()
In-Reply-To: <1587022037.69.0.998051306567.issue40298@roundup.psfhosted.org>
Message-ID: <1587026972.9.0.149949531833.issue40298@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

It is not a bug. Tuple is a callable, but calling it raises a TypeError with the informative error message.

It does not differ from e.g.

>>> def foo():
...     raise TypeError("don't call foo()")
... 
>>> callable(foo)
True
>>> foo()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 2, in foo
TypeError: don't call foo()

----------
nosy: +serhiy.storchaka
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40298>
_______________________________________

From report at bugs.python.org  Thu Apr 16 04:54:44 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 16 Apr 2020 08:54:44 +0000
Subject: [issue40133] Provide additional matchers for unittest.mock
In-Reply-To: <1585735205.76.0.306632606173.issue40133@roundup.psfhosted.org>
Message-ID: <1587027284.93.0.290749284795.issue40133@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Thanks for the idea. But given the size of the patch and benefit it provides for the code I feel it could be a better idea to have it in PyPI and then add it to stdlib later once it gathers more feedback and adoption. Adding others for more feedback.

----------
nosy: +cjw296, lisroach, mariocj89, michael.foord

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40133>
_______________________________________

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: [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 05:11:42 2020
From: report at bugs.python.org (Chris Withers)
Date: Thu, 16 Apr 2020 09:11:42 +0000
Subject: [issue40133] Provide additional matchers for unittest.mock
In-Reply-To: <1585735205.76.0.306632606173.issue40133@roundup.psfhosted.org>
Message-ID: <1587028302.87.0.752216563112.issue40133@roundup.psfhosted.org>


Chris Withers <chris at withers.org> added the comment:

Agreed, this would be better placed in a third party library.

There's examples out there already, for example, I maintain a library [0] that has tools for asserting about complex data structures, including flexible type matching [1] and regex string matching [2].

[0] https://testfixtures.readthedocs.io/en/latest/comparing.html#the-compare-function
[1] https://testfixtures.readthedocs.io/en/latest/comparing.html#comparison-objects
[2] https://testfixtures.readthedocs.io/en/latest/comparing.html#string-comparison-objects

Diego, would you be okay if we closed this issue and the accompanying pull request?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40133>
_______________________________________

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: [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 06:11:58 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 16 Apr 2020 10:11:58 +0000
Subject: [issue40209] read_pyfile function refactor in Lib/test/test_unparse.py
In-Reply-To: <1586197846.97.0.19099018734.issue40209@roundup.psfhosted.org>
Message-ID: <1587031918.87.0.884567672971.issue40209@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset 6a5bf15c71a1c101c28774ae714b58e8a65b130c by Hakan ?elik in branch 'master':
bpo-40209: Use tokenize.open in test_unparse (GH-19399)
https://github.com/python/cpython/commit/6a5bf15c71a1c101c28774ae714b58e8a65b130c


----------
nosy: +pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40209>
_______________________________________

From report at bugs.python.org  Thu Apr 16 06:13:40 2020
From: report at bugs.python.org (Martin Panter)
Date: Thu, 16 Apr 2020 10:13:40 +0000
Subject: [issue40299] os.dup seems broken with execvp (LINUX)
In-Reply-To: <1587027489.14.0.0429159118409.issue40299@roundup.psfhosted.org>
Message-ID: <1587032020.19.0.854740932248.issue40299@roundup.psfhosted.org>


Martin Panter <vadmium+py at gmail.com> added the comment:

The file descriptor created by "os.dup" is not inherited by child processes by default since Python 3.4.
https://docs.python.org/3/library/os.html#os.dup

Does it work if you use "os.set_inheritable" or "os.dup2" (which apparently sets it inhertiable by default)?

----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40299>
_______________________________________

From report at bugs.python.org  Thu Apr 16 06:26:35 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 16 Apr 2020 10:26:35 +0000
Subject: [issue40209] read_pyfile function refactor in Lib/test/test_unparse.py
In-Reply-To: <1586197846.97.0.19099018734.issue40209@roundup.psfhosted.org>
Message-ID: <1587032795.61.0.507984515125.issue40209@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40209>
_______________________________________

From report at bugs.python.org  Thu Apr 16 06:33:25 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 16 Apr 2020 10:33:25 +0000
Subject: [issue40300] logging.Formatter crashes when default_msec_format is
 None.
In-Reply-To: <1587031786.91.0.398301028125.issue40300@roundup.psfhosted.org>
Message-ID: <1587033205.62.0.439671705813.issue40300@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +vinay.sajip

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40300>
_______________________________________

From report at bugs.python.org  Thu Apr 16 06:51:52 2020
From: report at bugs.python.org (Mariusz Felisiak)
Date: Thu, 16 Apr 2020 10:51:52 +0000
Subject: [issue40300] logging.Formatter crashes when default_msec_format is
 None.
In-Reply-To: <1587031786.91.0.398301028125.issue40300@roundup.psfhosted.org>
Message-ID: <1587034312.95.0.161113430513.issue40300@roundup.psfhosted.org>


Change by Mariusz Felisiak <felisiak.mariusz at gmail.com>:


----------
keywords: +patch
pull_requests: +18897
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19551

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40300>
_______________________________________

From report at bugs.python.org  Thu Apr 16 06:52:01 2020
From: report at bugs.python.org (Dmitry Tsirkov)
Date: Thu, 16 Apr 2020 10:52:01 +0000
Subject: [issue30483] urllib.parse.parse_qsl does not handle unicode data
 properly
In-Reply-To: <1495792186.98.0.218510408103.issue30483@psf.upfronthosting.co.za>
Message-ID: <1587034321.36.0.194603584327.issue30483@roundup.psfhosted.org>


Dmitry Tsirkov <cyrkov.d at gmail.com> added the comment:

I have recently stumbled upon this bug, and I can present the example and a solution I've used.
The issue happens when we try to parse x-www-form-urlencoded of type bytes:
```
>>> from urllib.parse import urlencode, parse_qs
>>> urlencode([('v', '?')])
'v=%C3%B6'
>>> parse_qs('v=%C3%B6')
{'v': ['?']}
>>> parse_qs(b'v=%C3%B6')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib64/python3.6/urllib/parse.py", line 669, in parse_qs
    encoding=encoding, errors=errors)
  File "/usr/lib64/python3.6/urllib/parse.py", line 722, in parse_qsl
    value = _coerce_result(value)
  File "/usr/lib64/python3.6/urllib/parse.py", line 103, in _encode_result
    return obj.encode(encoding, errors)
UnicodeEncodeError: 'ascii' codec can't encode character '\xf6' in position 0: ordinal not in range(128)
```
This happens in the parse_qsl function because _coerce_result is a synonym of _encode_result and is called with default parameter encoding='ascii'. As far as I understand, it should be called with the encoding parameter of the parse_qsl function:
```
742c742
<             name = _coerce_result(name)
---
>             name = _coerce_result(name, encoding=encoding, errors=errors)
745c745
<             value = _coerce_result(value)
---
>             value = _coerce_result(value, encoding=encoding, errors=errors)
```
I am not sure whether I should commit this to the repo and create a pull request, as described in the devguide.

----------
nosy: +cyrkov

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30483>
_______________________________________

From report at bugs.python.org  Thu Apr 16 08:15:11 2020
From: report at bugs.python.org (Mark Shannon)
Date: Thu, 16 Apr 2020 12:15:11 +0000
Subject: [issue40255] Fixing Copy on Writes from reference counting
In-Reply-To: <1586619621.82.0.553262088399.issue40255@roundup.psfhosted.org>
Message-ID: <1587039311.36.0.0615666056862.issue40255@roundup.psfhosted.org>


Mark Shannon <mark at hotpy.org> added the comment:

A big -1 to this.

You are asking the whole world to take a hit on both performance and memory use, in order to save Instagram memory.

The PR uses the term "immortal" everywhere. There is only one reference to copy-on-write in a comment. Yet this issue about making object headers immutable.
Immortality and object header immutability are not the same.

If object header immutability is to be a requirement, that needs a PEP.

If it is not requirement, but immortality is, then make the obvious improvement of changing the branchy code

if (!(obj->refcnt & IMMORTAL_BIT)) {
   obj->refcnt++;
}

to the branchless

obj->refcnt += ((obj->refcnt &IMMORTAL_BIT) != 0)

Immortality has advantages because it allows saturating reference counting and thus smaller object headers, but it is not the same as making the object header immutable.

----------
nosy: +Mark.Shannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40255>
_______________________________________

From report at bugs.python.org  Thu Apr 16 08:28:16 2020
From: report at bugs.python.org (Jason R. Coombs)
Date: Thu, 16 Apr 2020 12:28:16 +0000
Subject: [issue35967] Better platform.processor support
In-Reply-To: <1549895363.53.0.252912531241.issue35967@roundup.psfhosted.org>
Message-ID: <1587040096.48.0.921744122242.issue35967@roundup.psfhosted.org>


Jason R. Coombs <jaraco at jaraco.com> added the comment:


New changeset 518835f3354d6672e61c9f52348c1e4a2533ea00 by Jason R. Coombs in branch 'master':
bpo-35967 resolve platform.processor late (GH-12239)
https://github.com/python/cpython/commit/518835f3354d6672e61c9f52348c1e4a2533ea00


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35967>
_______________________________________

From report at bugs.python.org  Thu Apr 16 08:29:40 2020
From: report at bugs.python.org (Jason R. Coombs)
Date: Thu, 16 Apr 2020 12:29:40 +0000
Subject: [issue35967] Better platform.processor support
In-Reply-To: <1549895363.53.0.252912531241.issue35967@roundup.psfhosted.org>
Message-ID: <1587040180.48.0.931724227897.issue35967@roundup.psfhosted.org>


Change by Jason R. Coombs <jaraco at jaraco.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35967>
_______________________________________

From report at bugs.python.org  Thu Apr 16 08:57:37 2020
From: report at bugs.python.org (Mark Borgerding)
Date: Thu, 16 Apr 2020 12:57:37 +0000
Subject: [issue32308] Replace empty matches adjacent to a previous non-empty
 match in re.sub()
In-Reply-To: <1513189718.03.0.213398074469.issue32308@psf.upfronthosting.co.za>
Message-ID: <1587041857.42.0.245799948439.issue32308@roundup.psfhosted.org>


Mark Borgerding <mborgerd at gmail.com> added the comment:

So third-party code was knowingly broken to satisfy an aesthetic notion that substitution should be more like iteration.

Would not a FutureWarning have been a kinder way to stage this implementation?

A foolish consistency, indeed.

----------
nosy: +Mark Borgerding

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32308>
_______________________________________

From report at bugs.python.org  Thu Apr 16 09:35:40 2020
From: report at bugs.python.org (Michael Felt)
Date: Thu, 16 Apr 2020 13:35:40 +0000
Subject: [issue39953] Let's update ssl error codes
In-Reply-To: <1586966012.06.0.705872450565.issue39953@roundup.psfhosted.org>
Message-ID: <9035924e-da34-9f62-41b6-706286277809@felt.demon.nl>


Michael Felt <aixtools at felt.demon.nl> added the comment:

Checked with latest version - and working as expected. Sorry for the noise.

On 15/04/2020 17:53, SilentGhost wrote:
> SilentGhost <ghost.adh at runbox.com> added the comment:
>
> Michael, could you try with the latest fix in 584a3cfda4?
>
> ----------
> nosy: +SilentGhost
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue39953>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39953>
_______________________________________

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: [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:08:41 2020
From: report at bugs.python.org (Jeffrey Quesnelle)
Date: Thu, 16 Apr 2020 14:08:41 +0000
Subject: [issue40294] Use-after-free crash if multiple interpreters import
 asyncio module
In-Reply-To: <1586971925.67.0.678462551955.issue40294@roundup.psfhosted.org>
Message-ID: <1587046121.54.0.13600134496.issue40294@roundup.psfhosted.org>


Jeffrey Quesnelle <jquesnelle at gmail.com> added the comment:

Would the simple fix (clearing the flag in `module_free`) be a candidate for a backport to 3.8? This seems to be a regression from the previous stable version that also limits the usability of subinterpreters -- `asyncio` is loaded by a wide variety of libraries and so in general it's not easy to know that a particular subinterpreter hasn't loaded `asyncio`.   However, I concede that subinterpreters with variable lifetimes isn't a common use case.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40294>
_______________________________________

From report at bugs.python.org  Thu Apr 16 10:11:22 2020
From: report at bugs.python.org (hai shi)
Date: Thu, 16 Apr 2020 14:11:22 +0000
Subject: [issue40294] Use-after-free crash if multiple interpreters import
 asyncio module
In-Reply-To: <1586971925.67.0.678462551955.issue40294@roundup.psfhosted.org>
Message-ID: <1587046282.24.0.157724927148.issue40294@roundup.psfhosted.org>


Change by hai shi <shihai1991 at 126.com>:


----------
nosy: +shihai1991

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40294>
_______________________________________

From report at bugs.python.org  Thu Apr 16 10:15:13 2020
From: report at bugs.python.org (Massimo Sala)
Date: Thu, 16 Apr 2020 14:15:13 +0000
Subject: [issue40301] zipfile module: new feature (two lines of code),
 useful for test, security and forensics
In-Reply-To: <1587045567.04.0.739688211881.issue40301@roundup.psfhosted.org>
Message-ID: <1587046513.15.0.755348973439.issue40301@roundup.psfhosted.org>


Change by Massimo Sala <massimo.sala.71 at gmail.com>:


----------
title: zipfile module: new feature (two lines of code) -> zipfile module: new feature (two lines of code), useful for test, security and forensics

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40301>
_______________________________________

From report at bugs.python.org  Thu Apr 16 10:21:10 2020
From: report at bugs.python.org (Massimo Sala)
Date: Thu, 16 Apr 2020 14:21:10 +0000
Subject: [issue40271] Allow shell like paths in
In-Reply-To: <1586774030.36.0.315208521295.issue40271@roundup.psfhosted.org>
Message-ID: <1587046870.65.0.667885173648.issue40271@roundup.psfhosted.org>


Massimo Sala <massimo.sala.71 at gmail.com> added the comment:

Gavin, zipfile works on all the operating systems where python runs.
Your request is OS dependent... BSD? linux?

The tilde isn't into the ZIP file specifications.
I have to agree with Serhiy: the correct solution is
    os.path.expanduser("~/stuff")

----------
nosy: +massimosala

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40271>
_______________________________________

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: [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 10:23:28 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 16 Apr 2020 14:23:28 +0000
Subject: [issue40302] Add _Py_bswap32() function to pyport.h
In-Reply-To: <1587046975.76.0.701994468055.issue40302@roundup.psfhosted.org>
Message-ID: <1587047008.42.0.97118429594.issue40302@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
keywords: +patch
pull_requests: +18899
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19552

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40302>
_______________________________________

From report at bugs.python.org  Thu Apr 16 10:23:53 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 16 Apr 2020 14:23:53 +0000
Subject: [issue40302] Add _Py_bswap32() function to pyport.h
In-Reply-To: <1587046975.76.0.701994468055.issue40302@roundup.psfhosted.org>
Message-ID: <1587047033.18.0.815651993832.issue40302@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40302>
_______________________________________

From report at bugs.python.org  Thu Apr 16 10:43:14 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Thu, 16 Apr 2020 14:43:14 +0000
Subject: [issue40301] zipfile module: new feature (two lines of code),
 useful for test, security and forensics
In-Reply-To: <1587045567.04.0.739688211881.issue40301@roundup.psfhosted.org>
Message-ID: <1587048194.21.0.732722493421.issue40301@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

This is a new feature and cannot be added to older versions which are in feature-freeze.

Adding the feature to (say) Python 2.7.18 would be inconsistent, because it wouldn't exist in 2.7.0 through .17. Likewise for all the other versions before 3.9.

Personally, this sounds like a nice feature to have, and your use-case sounds convincing to me.

----------
nosy: +steven.daprano
versions:  -Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40301>
_______________________________________

From report at bugs.python.org  Thu Apr 16 10:46:18 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 16 Apr 2020 14:46:18 +0000
Subject: [issue32308] Replace empty matches adjacent to a previous non-empty
 match in re.sub()
In-Reply-To: <1513189718.03.0.213398074469.issue32308@psf.upfronthosting.co.za>
Message-ID: <1587048378.52.0.590265612571.issue32308@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

The former implementation was wrong. See issue25054 which contains more obvious examples of that bug:

>>> re.sub(r"\b|:+", "-", "a::bc")
'-a-:-bc-'

Not all colons were replaced despite the fact that the pattern matches all colons.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32308>
_______________________________________

From report at bugs.python.org  Thu Apr 16 10:48:25 2020
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 16 Apr 2020 14:48:25 +0000
Subject: [issue40302] Add _Py_bswap32() function to pyport.h
In-Reply-To: <1587046975.76.0.701994468055.issue40302@roundup.psfhosted.org>
Message-ID: <1587048505.57.0.469490601645.issue40302@roundup.psfhosted.org>


Antoine Pitrou <solipsis at pitrou.net> added the comment:

Isn't pyport.h a public header?  IMHO you should put in a private header and make it an inline function there.

Here is for example what we do in Arrow:
https://github.com/apache/arrow/blob/master/cpp/src/arrow/util/bit_util.h#L48

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40302>
_______________________________________

From report at bugs.python.org  Thu Apr 16 10:59:31 2020
From: report at bugs.python.org (Mark Borgerding)
Date: Thu, 16 Apr 2020 14:59:31 +0000
Subject: [issue32308] Replace empty matches adjacent to a previous non-empty
 match in re.sub()
In-Reply-To: <1513189718.03.0.213398074469.issue32308@psf.upfronthosting.co.za>
Message-ID: <1587049171.35.0.319628533584.issue32308@roundup.psfhosted.org>


Mark Borgerding <mborgerd at gmail.com> added the comment:

@serhiy.storchaka  Thanks for the link to issue25054 to clarify this change was not done solely for aesthetics.
Hopefully that will mollify others like me who find their way to this discussion as they try to figure out why their code broke with a new version of python.


I wish it had been done in a more staged and overt way, but that is just spitting in the wind at this point.


Thanks for all your work, my gripe du jour notwithstanding.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32308>
_______________________________________

From report at bugs.python.org  Thu Apr 16 11:01:20 2020
From: report at bugs.python.org (Cheryl Sabella)
Date: Thu, 16 Apr 2020 15:01:20 +0000
Subject: [issue40243] Unicode 3.2 numeric uses decimal_changed instead of
 numeric_changed
Message-ID: <1587049280.59.0.527784613619.issue40243@roundup.psfhosted.org>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


----------
versions:  -Python 2.7, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40243>
_______________________________________

From report at bugs.python.org  Thu Apr 16 11:10:46 2020
From: report at bugs.python.org (Eddie Elizondo)
Date: Thu, 16 Apr 2020 15:10:46 +0000
Subject: [issue40255] Fixing Copy on Writes from reference counting
In-Reply-To: <1586619621.82.0.553262088399.issue40255@roundup.psfhosted.org>
Message-ID: <1587049846.82.0.244000356464.issue40255@roundup.psfhosted.org>


Eddie Elizondo <eduardo.elizondorueda at gmail.com> added the comment:

Mark:
> You are asking the whole world to take a hit on both performance and memory use.

That's an explicit non-goal. That's why the code was guarded to add as an optional compilation mode

This should be added by default if and only if this is a neutral or an improvement on performance. Which by the way, the latest perf numbers suggest that we are now at perf parity / within error (pending official confirmation from running this on speed.python.org machines).

Also, can you expand on how is this a performance hit on memory?


> There is only one reference to copy-on-write in a comment. Yet this issue about making object headers immutable.

The PR summary expands on Copy on Writes. If you think this belongs in-code, let me know and I can update the PR.


> then make the obvious improvement of changing the branchy code

That is strictly slower. The current version makes Py_INCREF and Py_DECREF cheaper for known immortal instances (i.e the heap after runtime init). This skips increasing and decreasing the refcount as well as the refcount check for deallocation. Using the proposed branch-less version makes all Py_INCREFs and Py_DECREFs more expensive.

I ran a couple of benchmarks with the branch-less version to highlight this:

Branch-less version:
unpack_sequence: Mean +- std dev: 98.2 ns +- 4.9 ns
richards: Mean +- std dev: 130 ms +- 5 ms
fannkuch: Mean +- std dev: 894 ms +- 18 ms


Branch version:
unpack_sequence: Mean +- std dev: 82.7 ns +- 3.9 ns
richards: Mean +- std dev: 123 ms +- 4 ms
fannkuch: Mean +- std dev: 838 ms +- 25 ms


> Immortality has advantages because it allows saturating reference counting and thus smaller object headers, but it is not the same as making the object header immutable.

In its current form, this change is not trying to do a strict immutability of the header. We can't guarantee that third-party extensions won't mutate the instance. Instead, this change tries to maintain an instance's immutability as long as it can.

If the issue is with naming, I can easily rename this to something else :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40255>
_______________________________________

From report at bugs.python.org  Thu Apr 16 12:02:57 2020
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 16 Apr 2020 16:02:57 +0000
Subject: [issue40301] zipfile module: new feature (two lines of code),
 useful for test, security and forensics
In-Reply-To: <1587045567.04.0.739688211881.issue40301@roundup.psfhosted.org>
Message-ID: <1587052977.18.0.73714413619.issue40301@roundup.psfhosted.org>


Change by Zachary Ware <zachary.ware at gmail.com>:


----------
nosy: +alanmcintyre, serhiy.storchaka, twouters

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40301>
_______________________________________

From report at bugs.python.org  Thu Apr 16 12:28:26 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 16 Apr 2020 16:28:26 +0000
Subject: [issue32308] Replace empty matches adjacent to a previous non-empty
 match in re.sub()
In-Reply-To: <1513189718.03.0.213398074469.issue32308@psf.upfronthosting.co.za>
Message-ID: <1587054506.18.0.507113672719.issue32308@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

If the behavior is obviously wrong (like in issue25054), we can fix it without warnings, and even backport the fix to older versions, because we do not expect that anybody depends on such weird behavior. If we are going to change the behavior, but expect that users can depend on the current behavior, we emit a FutureWarning first (and we did it for other changes in re). But this issue is the hard one. Before 3.7 we did not know that it is related to issue25054. We were not going to change this behavior (at least not in near future). But when a fix for issue25054 was written we did see that it is the same issue. We did not want to keep a bug in issue25054 few versions more, so we changed the behavior in this issue without warnings. It was an exceptional case.

This change was documented, in the module documentation, and in "What's New in Python 3.7" (section "Porting to Python 3.7"). If this is not enough we will be happy to get help to make it better.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32308>
_______________________________________

From report at bugs.python.org  Thu Apr 16 12:38:47 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 16 Apr 2020 16:38:47 +0000
Subject: [issue40271] Allow shell like paths in
In-Reply-To: <1586774030.36.0.315208521295.issue40271@roundup.psfhosted.org>
Message-ID: <1587055127.53.0.862332410783.issue40271@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

If add such option to zipfile.is_zipfile(), why not add it to other functions? There are many tens or hundreds of functions and methods in the stdlib which accept a file path. Adding such option to all of them is not practical. And zipfile.is_zipfile() does not look special.

Also, there are other options which you may want to add to zipfile.is_zipfile(). What about expandvars()? Or support URIs with the file:/// scheme? Or maybe someone want to replace ~ with the project directory instead of the home directory.

It is better to provide functions for every tiny feature and combine them as you want than add an infinite number of options to all functions.

----------
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40271>
_______________________________________

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: [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:11:19 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 16 Apr 2020 17:11:19 +0000
Subject: [issue40296] help(list[int]) fails
In-Reply-To: <1586983817.03.0.686824683966.issue40296@roundup.psfhosted.org>
Message-ID: <1587057079.76.0.696067318369.issue40296@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

Yeah, I think help() or pydoc needs to special-case this. (Didn't your other PR attempt to fix this?)

Note that issubclass(list[int].__class__, type) returns True -- the __class__ attribute in this case is taken from __origin__, while type() returns the "true" class.

I don't know what to do about __subclasses__ -- I expect we should just let it be this way.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40296>
_______________________________________

From report at bugs.python.org  Thu Apr 16 13:17:39 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 16 Apr 2020 17:17:39 +0000
Subject: [issue40302] Add _Py_bswap32() function to pyport.h
In-Reply-To: <1587046975.76.0.701994468055.issue40302@roundup.psfhosted.org>
Message-ID: <1587057459.97.0.961927159731.issue40302@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

We have another function which may be grouped somehow in the same category: _Py_bit_length().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40302>
_______________________________________

From report at bugs.python.org  Thu Apr 16 13:25:24 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 16 Apr 2020 17:25:24 +0000
Subject: [issue40290] Add zscore to statistics.NormalDist
In-Reply-To: <1586920449.06.0.712419472387.issue40290@roundup.psfhosted.org>
Message-ID: <1587057924.15.0.898158914266.issue40290@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:


New changeset 70f027dd22d6522b777d10c250f951e5e416b93a by Raymond Hettinger in branch 'master':
bpo-40290: Add zscore() to statistics.NormalDist. (GH-19547)
https://github.com/python/cpython/commit/70f027dd22d6522b777d10c250f951e5e416b93a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40290>
_______________________________________

From report at bugs.python.org  Thu Apr 16 13:25:41 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 16 Apr 2020 17:25:41 +0000
Subject: [issue40290] Add zscore to statistics.NormalDist
In-Reply-To: <1586920449.06.0.712419472387.issue40290@roundup.psfhosted.org>
Message-ID: <1587057941.23.0.106456487752.issue40290@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40290>
_______________________________________

From report at bugs.python.org  Thu Apr 16 13:29:18 2020
From: report at bugs.python.org (A.M. Kuchling)
Date: Thu, 16 Apr 2020 17:29:18 +0000
Subject: [issue39793] make_msgid fail on FreeBSD 12.1-RELEASE-p1 with
 different domains
In-Reply-To: <1582970177.09.0.683840972158.issue39793@roundup.psfhosted.org>
Message-ID: <1587058158.93.0.758917312552.issue39793@roundup.psfhosted.org>


A.M. Kuchling <amk at amk.ca> added the comment:


New changeset 5565c30f0b25996a0e73477fc0e1e1aced52b926 by Batuhan Ta?kaya in branch 'master':
bpo-39793: use the same domain on make_msgid tests (#18698)
https://github.com/python/cpython/commit/5565c30f0b25996a0e73477fc0e1e1aced52b926


----------
nosy: +akuchling

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39793>
_______________________________________

From report at bugs.python.org  Thu Apr 16 13:29:41 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 16 Apr 2020 17:29:41 +0000
Subject: [issue39793] make_msgid fail on FreeBSD 12.1-RELEASE-p1 with
 different domains
In-Reply-To: <1582970177.09.0.683840972158.issue39793@roundup.psfhosted.org>
Message-ID: <1587058181.54.0.206948162472.issue39793@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +18901
pull_request: https://github.com/python/cpython/pull/19555

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39793>
_______________________________________

From report at bugs.python.org  Thu Apr 16 13:29:34 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 16 Apr 2020 17:29:34 +0000
Subject: [issue39793] make_msgid fail on FreeBSD 12.1-RELEASE-p1 with
 different domains
In-Reply-To: <1582970177.09.0.683840972158.issue39793@roundup.psfhosted.org>
Message-ID: <1587058174.69.0.346819371365.issue39793@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
nosy: +miss-islington
nosy_count: 4.0 -> 5.0
pull_requests: +18900
pull_request: https://github.com/python/cpython/pull/19554

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39793>
_______________________________________

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: [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 13:57:34 2020
From: report at bugs.python.org (krsna)
Date: Thu, 16 Apr 2020 17:57:34 +0000
Subject: [issue40299] os.dup seems broken with execvp (LINUX)
In-Reply-To: <1587032020.19.0.854740932248.issue40299@roundup.psfhosted.org>
Message-ID: <1828690721.1681327.1587059847031@mail.yahoo.com>


krsna <bhrt_k at yahoo.com> added the comment:

I should read the updated documentation changes to modules more often. Adding the inheritable works and yes I tested with `os.dup2` which seemed consistent with C's dups2. I still think it is quite odd that the low level `dup` function has a different behavior than one would expect.

Thank you for you helpful and quick reply Martin.

This may be closed as it is a documented, imo, misbehavior.

On Thursday, April 16, 2020, 12:13:58 AM HST, Martin Panter <report at bugs.python.org> wrote: 

Martin Panter <vadmium+py at gmail.com> added the comment:

The file descriptor created by "os.dup" is not inherited by child processes by default since Python 3.4.
https://docs.python.org/3/library/os.html#os.dup

Does it work if you use "os.set_inheritable" or "os.dup2" (which apparently sets it inhertiable by default)?

----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40299>
_______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40299>
_______________________________________

From report at bugs.python.org  Thu Apr 16 14:05:07 2020
From: report at bugs.python.org (krsna)
Date: Thu, 16 Apr 2020 18:05:07 +0000
Subject: [issue40299] os.dup seems broken with execvp (LINUX)
In-Reply-To: <1587027489.14.0.0429159118409.issue40299@roundup.psfhosted.org>
Message-ID: <1587060307.9.0.308746977613.issue40299@roundup.psfhosted.org>


krsna <keshto at gmail.com> added the comment:

Closing has behavior is documented "The file descriptor created by "os.dup" is not inherited by child processes by default since Python 3.4.
https://docs.python.org/3/library/os.html#os.dup"

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40299>
_______________________________________

From report at bugs.python.org  Thu Apr 16 14:05:30 2020
From: report at bugs.python.org (Zackery Spytz)
Date: Thu, 16 Apr 2020 18:05:30 +0000
Subject: [issue15904] file,close() can fail assert on Windows in 2.7
In-Reply-To: <1347286598.53.0.580767825859.issue15904@psf.upfronthosting.co.za>
Message-ID: <1587060330.4.0.44452482361.issue15904@roundup.psfhosted.org>


Zackery Spytz <zspytz at gmail.com> added the comment:

Python 2 is EOL.

----------
nosy: +ZackerySpytz

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue15904>
_______________________________________

From report at bugs.python.org  Thu Apr 16 14:08:03 2020
From: report at bugs.python.org (A.M. Kuchling)
Date: Thu, 16 Apr 2020 18:08:03 +0000
Subject: [issue39793] make_msgid fail on FreeBSD 12.1-RELEASE-p1 with
 different domains
In-Reply-To: <1582970177.09.0.683840972158.issue39793@roundup.psfhosted.org>
Message-ID: <1587060483.74.0.645597869066.issue39793@roundup.psfhosted.org>


A.M. Kuchling <amk at amk.ca> added the comment:


New changeset ccf30e96d4bdcf04396e00899a0319041144509f by Miss Islington (bot) in branch '3.8':
bpo-39793: use the same domain on make_msgid tests (GH-18698) (GH-19554)
https://github.com/python/cpython/commit/ccf30e96d4bdcf04396e00899a0319041144509f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39793>
_______________________________________

From report at bugs.python.org  Thu Apr 16 14:09:03 2020
From: report at bugs.python.org (A.M. Kuchling)
Date: Thu, 16 Apr 2020 18:09:03 +0000
Subject: [issue39793] make_msgid fail on FreeBSD 12.1-RELEASE-p1 with
 different domains
In-Reply-To: <1582970177.09.0.683840972158.issue39793@roundup.psfhosted.org>
Message-ID: <1587060543.23.0.350439172744.issue39793@roundup.psfhosted.org>


A.M. Kuchling <amk at amk.ca> added the comment:


New changeset cd09d7e55d160edc454763d3fb6a48180988741a by Miss Islington (bot) in branch '3.7':
bpo-39793: use the same domain on make_msgid tests (GH-18698) (GH-19555)
https://github.com/python/cpython/commit/cd09d7e55d160edc454763d3fb6a48180988741a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39793>
_______________________________________

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: [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:24:18 2020
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 16 Apr 2020 18:24:18 +0000
Subject: [issue40305] Fix server_close() method for ThreadingHTTPServer and
 TCPServer class
In-Reply-To: <1587060788.93.0.613571029656.issue40305@roundup.psfhosted.org>
Message-ID: <1587061458.84.0.58961552572.issue40305@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch
nosy: +python-dev
nosy_count: 1.0 -> 2.0
pull_requests: +18903
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19556

_______________________________________
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: [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 14:37:30 2020
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 16 Apr 2020 18:37:30 +0000
Subject: [issue40306] Enhancement request for SSLContext - flag to handle
 trailing dot in hostname
In-Reply-To: <1587061615.86.0.473018087621.issue40306@roundup.psfhosted.org>
Message-ID: <1587062250.88.0.715594274101.issue40306@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

I prefer not to interfere with hostname matching. Could you please open a feature request with OpenSSL and request a verification flag to ignore trailing dot? I'm happy to expose the feature if OpenSSL implements it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40306>
_______________________________________

From report at bugs.python.org  Thu Apr 16 14:38:35 2020
From: report at bugs.python.org (bli2020)
Date: Thu, 16 Apr 2020 18:38:35 +0000
Subject: [issue40306] Enhancement request for SSLContext - flag to handle
 trailing dot in hostname
In-Reply-To: <1587061615.86.0.473018087621.issue40306@roundup.psfhosted.org>
Message-ID: <1587062315.52.0.0207722861707.issue40306@roundup.psfhosted.org>


bli2020 <brysonli at gmail.com> added the comment:

sure, that sounds reasonable. I will open up a feature request with OpenSSL

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40306>
_______________________________________

From report at bugs.python.org  Thu Apr 16 14:41:10 2020
From: report at bugs.python.org (Mark Shannon)
Date: Thu, 16 Apr 2020 18:41:10 +0000
Subject: [issue40255] Fixing Copy on Writes from reference counting
In-Reply-To: <1586619621.82.0.553262088399.issue40255@roundup.psfhosted.org>
Message-ID: <1587062470.13.0.23341654956.issue40255@roundup.psfhosted.org>


Mark Shannon <mark at hotpy.org> added the comment:

Do you have more details on your comparison?
I'm somewhat puzzled how a version that does no more work and has no jumps is slower.

The memory hit is not immediate, but making the object header immutable prevents changes like https://github.com/markshannon/cpython/commit/c73407e7b5d1a0fc794d55c6bcc91cfdc958f6c4
which would potentially save the two word per object overhead that the cyclic GC currently imposes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40255>
_______________________________________

From report at bugs.python.org  Thu Apr 16 15:10:59 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 16 Apr 2020 19:10:59 +0000
Subject: [issue40303] argparse parse_args args parameter bug or intended
In-Reply-To: <1587055634.08.0.65599497467.issue40303@roundup.psfhosted.org>
Message-ID: <1587064259.78.0.461247913788.issue40303@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +paul.j3, rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40303>
_______________________________________

From report at bugs.python.org  Thu Apr 16 15:13:30 2020
From: report at bugs.python.org (Eddie Elizondo)
Date: Thu, 16 Apr 2020 19:13:30 +0000
Subject: [issue40255] Fixing Copy on Writes from reference counting
In-Reply-To: <1586619621.82.0.553262088399.issue40255@roundup.psfhosted.org>
Message-ID: <1587064410.66.0.896008338397.issue40255@roundup.psfhosted.org>


Eddie Elizondo <eduardo.elizondorueda at gmail.com> added the comment:

> I'm somewhat puzzled how a version that does no more work and has no jumps is slower.

Oh I think I know why there's some confusion. I've updated the PR from the initial version (which is probably the one that you saw). The branching does 
less work in Py_INCREF and Py_DECREF for all instances marked with the immortal bit by exiting early.

In the latest change, I added the immortal bit to a bunch of "known" immortal objects by. For instance:
* All static types (i.e: PyType_Type, etc.)
* All small ints (-5 to 256)
* The following Singletons: PyTrue, PyFalse, PyNone
* And the heap after the runtime is initialized (in pymain_main)

Example 1)
```
PyObject _Py_NoneStruct = {
  _PyObject_EXTRA_INIT
  1, &_PyNone_Type
#ifdef Py_IMMORTAL_OBJECTS
  _Py_IMMORTAL_BIT,
#else
  1,
#endif  /* Py_IMMORTAL_OBJECTS */
  &_PyNone_Type
};
```

Example 2)
```
static int
pymain_main(_PyArgv *args)
{
    PyStatus status = pymain_init(args);
    if (_PyStatus_IS_EXIT(status)) {
        pymain_free();
        return status.exitcode;
    }
    if (_PyStatus_EXCEPTION(status)) {
        pymain_exit_error(status);
    }

#ifdef Py_IMMORTAL_OBJECTS
    /* Most of the objects alive at this point will stay alive throughout the
     * lifecycle of the runtime. Immortalize to avoid the GC and refcnt costs */
    _PyGC_ImmortalizeHeap();
#endif  /* Py_IMMORTAL_OBJECTS */
    return Py_RunMain();
```


Therefore, you are now making Py_INCREF and Py_DECREF cheaper for things like  `Py_RETURN_NONE` and a bunch of other instances.

Let me know if that explains it! I could also send you patch of the branch-less version so you can compare them.



> but making the object header immutable prevents changes like

Why would it prevent it? These changes are not mutually exclusive, you can still have an immortal bit by:
1) Using a bit from `gc_bits`. Currently you only need 2 bits for the GC. Even with a `short` you'll have space for the immortal bit.
2) Using a bit from the ob_refcnt. Separately, using this allows us to experiment with a branch-less and test-less code by using saturated adds. For example:

```
/* Branch-less incref with saturated add */
#define PY_REFCNT_MAX ((int)(((int)-1)>>1))
#define _Py_INCREF(op) ({
    __asm__ (
        "addl $0x1, %[refcnt]"
        "cmovol  %[refcnt_max], %[refcnt]"
        : [refcnt] "+r" (((PyObject *)op)->ob_refcnt)
        : [refcnt_max] "r" (PY_REFCNT_MAX)
    );})
```

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40255>
_______________________________________

From report at bugs.python.org  Thu Apr 16 15:26:37 2020
From: report at bugs.python.org (Eddie Elizondo)
Date: Thu, 16 Apr 2020 19:26:37 +0000
Subject: [issue40255] Fixing Copy on Writes from reference counting
In-Reply-To: <1586619621.82.0.553262088399.issue40255@roundup.psfhosted.org>
Message-ID: <1587065197.95.0.830493418364.issue40255@roundup.psfhosted.org>


Eddie Elizondo <eduardo.elizondorueda at gmail.com> added the comment:

> which would potentially save the two word per object overhead

Btw, I misread. I thought `gc_bits` referred to the bits used by the GC in the reference count. In any case, you can still use a bit in the reference count :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40255>
_______________________________________

From report at bugs.python.org  Thu Apr 16 15:39:54 2020
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Thu, 16 Apr 2020 19:39:54 +0000
Subject: [issue40303] argparse parse_args args parameter bug or intended
In-Reply-To: <1587055634.08.0.65599497467.issue40303@roundup.psfhosted.org>
Message-ID: <1587065994.78.0.448752407942.issue40303@roundup.psfhosted.org>


R?mi Lapeyre <remi.lapeyre at henki.fr> added the comment:

Hi Gharg, this is expected, both because your program would not actually receive `--boolean=''` but `--boolean=`:

?  ~ cat test.py
import sys

print(sys.argv)
?  ~ python test.py --boolean=''
['test.py', '--boolean=']

and the way the type argument works. 

You can do what you are looking for by using:

?  ~ cat test.py
import argparse

parser = argparse.ArgumentParser()
parser.add_argument('--boolean', action='store_const', const=True, default=False)

print(parser.parse_args())
?  ~ python test.py --boolean
Namespace(boolean=True)
?  ~ python test.py
Namespace(boolean=False)

----------
nosy: +remi.lapeyre

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40303>
_______________________________________

From report at bugs.python.org  Thu Apr 16 16:23:27 2020
From: report at bugs.python.org (paul j3)
Date: Thu, 16 Apr 2020 20:23:27 +0000
Subject: [issue40303] argparse parse_args args parameter bug or intended
In-Reply-To: <1587055634.08.0.65599497467.issue40303@roundup.psfhosted.org>
Message-ID: <1587068607.83.0.669170309799.issue40303@roundup.psfhosted.org>


paul j3 <ajipanca at gmail.com> added the comment:

'type=bool' doesn't get any special treatment.  'bool' is a builtin Python function.

test with 

    def mybool(astr):
        print("mybool:", astr, len(astr), bool(astr))
        return bool(astr)

The trick to getting a False value is to pass a genuinely empty string.

As can be seen in several previous bug/issues, 'bool' is allowed as a type function, but since the only string that returns False is the empty one, it isn't very useful.  And we've resisted attempts give it some special treatment.

Users can write their own 'type' function that accepts language specific 'true/false' words.  Otherwise we encourage the use of 'store_true', 'store_false' action values.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40303>
_______________________________________

From report at bugs.python.org  Thu Apr 16 16:29:14 2020
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 16 Apr 2020 20:29:14 +0000
Subject: [issue15904] file,close() can fail assert on Windows in 2.7
In-Reply-To: <1347286598.53.0.580767825859.issue15904@psf.upfronthosting.co.za>
Message-ID: <1587068954.02.0.16313302349.issue15904@roundup.psfhosted.org>


Change by Benjamin Peterson <benjamin at python.org>:


----------
resolution:  -> wont fix
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue15904>
_______________________________________

From report at bugs.python.org  Thu Apr 16 16:51:57 2020
From: report at bugs.python.org (Neil Schemenauer)
Date: Thu, 16 Apr 2020 20:51:57 +0000
Subject: [issue40255] Fixing Copy on Writes from reference counting
In-Reply-To: <1586619621.82.0.553262088399.issue40255@roundup.psfhosted.org>
Message-ID: <1587070317.69.0.479521600329.issue40255@roundup.psfhosted.org>


Neil Schemenauer <nas-python at arctrix.com> added the comment:

A few thoughts

First, the PR is well done.  The changes are pretty minimal and are well localized.  Thanks Eddie for writing clean code and responding to review requests.

My feeling is that, in current state, this still should not get merged or at least not get enabled by default.  The main consideration is what is the cost of this new feature vs what is the benefit.

If the immortalize heap function is not called by default, all Python users pay a performance hit for this feature.  Even after recent PR improvements, if you don't immortalize the heap, Python is slower. 

Only a small fraction of Python users will benefit from this feature.  I think the "pre-fork, CoW exploiting" application architecture is more common than some people would realize (it is a successful way to achieve multi-processing with CPython, making good use of multiple CPU cores).  However, I'm pretty sure it is used by a very tiny fraction of all Python programs.

If we do immortalize by default (e.g. on Python startup), the semantics of the refcnt field are subtly changed.  I suspect some programs will be broken as a result of this change.  A clue about what might go wrong comes from the unicode object code.  E.g. the resize_inplace() function in unicodeobject.c.  It is possible that a non-trivial amount of other 3rd party code will make assumptions about refcnt that will be broken by this change.  That code could be fixed but it is a matter of cost vs benefit.

If it is disabled by default with a build flag we have an ABI compatibility problem.  I.e. incref/decref are inlined functions/macros.  Also, as mentioned above, these kinds of build options tend to make maintenance and testing harder.

The frozen GC generation did not have these kinds of issues.  If people don't use it, there is basically no cost.  I think it was a good idea to merge the frozen generation feature.  There is a small amount of ongoing maintenance cost but that's acceptable.

Regarding Mark's comment about immutability vs immutable object headers, I would frame the goal of the PR differently.  Like the GC frozen generation, this immutable instance change is about providing a way to opt-out of Python's default garbage collection mechanism.  The frozen generation was to opt-out of the mark-and-sweep style cyclic collection.  This PR is about opting-out of the default Python reference counting.  

Put that way, could we consider this PR as an incremental step in a process of making it possible to have a non-reference count based GC for CPython?  E.g. perhaps we could eventually have a mixture of mark-and-sweep and reference counted GC, in order to support the handle (HPy) API.  If we want to move towards that, we want CPython code to stop making assumptions about the refcnt field, like the unicodeobject.c file currently does.

I think pitching the PR in that way makes it more compelling.  Merge it not because it helps a tiny class of Python applications.  Instead, merge it because it helps find unwarranted assumptions about how the Python GC works.  Once we get bad assumptions cleaned up in 3rd party code, we have more of chance of pursuing an alternative GC strategy for CPython.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40255>
_______________________________________

From report at bugs.python.org  Thu Apr 16 16:56:51 2020
From: report at bugs.python.org (Neil Schemenauer)
Date: Thu, 16 Apr 2020 20:56:51 +0000
Subject: [issue40255] Fixing Copy on Writes from reference counting
In-Reply-To: <1586619621.82.0.553262088399.issue40255@roundup.psfhosted.org>
Message-ID: <1587070611.94.0.511148499353.issue40255@roundup.psfhosted.org>


Neil Schemenauer <nas-python at arctrix.com> added the comment:

> immutability vs immutable object headers

Sorry, I meant to write "immortal vs immutable".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40255>
_______________________________________

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: [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:41 2020
From: report at bugs.python.org (Dennis Sweeney)
Date: Thu, 16 Apr 2020 21:40:41 +0000
Subject: [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  Thu Apr 16 17:50:28 2020
From: report at bugs.python.org (Alessandro Molina)
Date: Thu, 16 Apr 2020 21:50:28 +0000
Subject: [issue40307] multiprocessing.BaseManager does not retain Client type.
In-Reply-To: <1587072930.89.0.0694830896032.issue40307@roundup.psfhosted.org>
Message-ID: <1587073828.29.0.096171892818.issue40307@roundup.psfhosted.org>


Alessandro Molina <amol at turbogears.org> added the comment:

The issue seems fairly easy to fix, it's just a matter in consistency in usage of self._Client attribute in the manager. I'm working on a PR that I'm willing to propose for review once I have finished it and wrote tests.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40307>
_______________________________________

From report at bugs.python.org  Thu Apr 16 17:51:17 2020
From: report at bugs.python.org (Tal Einat)
Date: Thu, 16 Apr 2020 21:51:17 +0000
Subject: [issue38580] select()'s documentation claims only sequences are
 accepted, but it allows all iterables
In-Reply-To: <1571915326.93.0.150606644361.issue38580@roundup.psfhosted.org>
Message-ID: <1587073877.63.0.595773353199.issue38580@roundup.psfhosted.org>


Tal Einat <taleinat+python at gmail.com> added the comment:

It seems that select() does indeed support arbitrary iterables through the use of PySequence_Fast().

The commit where this was introduced, by Brett Cannon from 2003 (62dba4c2775adfb5a5a97ca012a3ab00c4e28597), doesn't seems to have intended this though: "select.select() now accepts a sequence (as defined by PySequence_Fast()) for its first three arguments."

However, regardless of whether this is intentional, it appears that this has been this way for a very long time. So it seems to me that we should document this behavior, as suggested here, since any change to this would be an unacceptable backwards-incompatibility.

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python, taleinat

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38580>
_______________________________________

From report at bugs.python.org  Thu Apr 16 19:09:35 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Thu, 16 Apr 2020 23:09:35 +0000
Subject: [issue39793] make_msgid fail on FreeBSD 12.1-RELEASE-p1 with
 different domains
In-Reply-To: <1582970177.09.0.683840972158.issue39793@roundup.psfhosted.org>
Message-ID: <1587078575.98.0.601741960255.issue39793@roundup.psfhosted.org>


Change by Batuhan Taskaya <batuhanosmantaskaya at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39793>
_______________________________________

From report at bugs.python.org  Thu Apr 16 20:05:01 2020
From: report at bugs.python.org (Furkan Onder)
Date: Fri, 17 Apr 2020 00:05:01 +0000
Subject: [issue40223] Add -fwrapv for new icc versions
In-Reply-To: <1586342429.44.0.914021178636.issue40223@roundup.psfhosted.org>
Message-ID: <1587081901.68.0.260652027998.issue40223@roundup.psfhosted.org>


Change by Furkan Onder <furkanonder at protonmail.com>:


----------
keywords: +patch
nosy: +furkanonder
nosy_count: 1.0 -> 2.0
pull_requests: +18905
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/19561

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40223>
_______________________________________

From report at bugs.python.org  Thu Apr 16 20:46:45 2020
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 17 Apr 2020 00:46:45 +0000
Subject: [issue38605] [typing] PEP 563: Postponed evaluation of annotations:
 enable it by default before Python 4.0
In-Reply-To: <1572192430.43.0.755831692199.issue38605@roundup.psfhosted.org>
Message-ID: <1587084405.4.0.692790514345.issue38605@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

I personally like 3.10 as the target as that means users had at least 3 years to move to move over. Plus we can put a warning in the What's New for 3.9 about our plans for 3.10.

----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38605>
_______________________________________

From report at bugs.python.org  Thu Apr 16 20:50:37 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 17 Apr 2020 00:50:37 +0000
Subject: [issue38605] [typing] PEP 563: Postponed evaluation of annotations:
 enable it by default before Python 4.0
In-Reply-To: <1572192430.43.0.755831692199.issue38605@roundup.psfhosted.org>
Message-ID: <1587084637.2.0.831243153998.issue38605@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

This issue has been discussed during the Language Summit. A quick poll showed that the majority is in favor of changing the default in Python 3.9.

Lukasz proposed a PEP update to propose to switch the default in Python 3.9:
https://github.com/python/peps/pull/1371/

For me, the unclear part is which projects would be impacted if the default changes?

Someone mentioned attrs, but it seems like attrs is fine:
https://github.com/python-attrs/attrs/issues/288#issuecomment-587265961

In term of workflow, I would _prefer_ to get such incompatible in the very beginning of a devcycle, rather than just before the feature freeze. But I don't think that it's a blocker issue. Technically, changes are allowed until 3.9.0 beta1. Moreover, Lukasz is the 3.9 release manager, the author of the PEP 563 and he is in favor of changing the default in 3.9 :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38605>
_______________________________________

From report at bugs.python.org  Thu Apr 16 21:10:24 2020
From: report at bugs.python.org (Paul Ganssle)
Date: Fri, 17 Apr 2020 01:10:24 +0000
Subject: [issue40236] datetime.datetime.strptime get day error
In-Reply-To: <1586426131.65.0.158262640104.issue40236@roundup.psfhosted.org>
Message-ID: <1587085824.82.0.717111386576.issue40236@roundup.psfhosted.org>


Change by Paul Ganssle <p.ganssle at gmail.com>:


----------
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40236>
_______________________________________

From report at bugs.python.org  Thu Apr 16 21:14:13 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Fri, 17 Apr 2020 01:14:13 +0000
Subject: [issue40288] atexit module should not be loaded more than once per
 interpreter
In-Reply-To: <1586917009.7.0.806642420762.issue40288@roundup.psfhosted.org>
Message-ID: <1587086053.41.0.566171122794.issue40288@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
keywords: +patch
pull_requests: +18906
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19562

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40288>
_______________________________________

From report at bugs.python.org  Thu Apr 16 22:10:05 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 17 Apr 2020 02:10:05 +0000
Subject: [issue40294] Use-after-free crash if multiple interpreters import
 asyncio module
In-Reply-To: <1586971925.67.0.678462551955.issue40294@roundup.psfhosted.org>
Message-ID: <1587089405.62.0.761039380116.issue40294@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
nosy: +miss-islington
nosy_count: 3.0 -> 4.0
pull_requests: +18907
pull_request: https://github.com/python/cpython/pull/19565

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40294>
_______________________________________

From report at bugs.python.org  Thu Apr 16 22:09:49 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 17 Apr 2020 02:09:49 +0000
Subject: [issue40294] Use-after-free crash if multiple interpreters import
 asyncio module
In-Reply-To: <1586971925.67.0.678462551955.issue40294@roundup.psfhosted.org>
Message-ID: <1587089389.53.0.349641025625.issue40294@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset a75e730075cd25be1143e6183006f3b1d61bb80f by Jeffrey Quesnelle in branch 'master':
bpo-40294: Fix _asyncio when module is loaded/unloaded multiple times (GH-19542)
https://github.com/python/cpython/commit/a75e730075cd25be1143e6183006f3b1d61bb80f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40294>
_______________________________________

From report at bugs.python.org  Thu Apr 16 22:12:08 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 17 Apr 2020 02:12:08 +0000
Subject: [issue40294] Use-after-free crash if multiple interpreters import
 asyncio module
In-Reply-To: <1586971925.67.0.678462551955.issue40294@roundup.psfhosted.org>
Message-ID: <1587089528.03.0.581924441186.issue40294@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> Would the simple fix (clearing the flag in `module_free`) be a candidate for a backport to 3.8?

Sure.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40294>
_______________________________________

From report at bugs.python.org  Thu Apr 16 22:30:00 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 17 Apr 2020 02:30:00 +0000
Subject: [issue40294] Use-after-free crash if multiple interpreters import
 asyncio module
In-Reply-To: <1586971925.67.0.678462551955.issue40294@roundup.psfhosted.org>
Message-ID: <1587090600.31.0.990689536916.issue40294@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 6b0ca0aeab04d7b7b54086248ca9d5e70f770f2f by Miss Islington (bot) in branch '3.8':
bpo-40294: Fix _asyncio when module is loaded/unloaded multiple times (GH-19542)
https://github.com/python/cpython/commit/6b0ca0aeab04d7b7b54086248ca9d5e70f770f2f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40294>
_______________________________________

From report at bugs.python.org  Thu Apr 16 22:32:42 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 17 Apr 2020 02:32:42 +0000
Subject: [issue40294] Use-after-free crash if multiple interpreters import
 asyncio module
In-Reply-To: <1586971925.67.0.678462551955.issue40294@roundup.psfhosted.org>
Message-ID: <1587090762.76.0.049526802673.issue40294@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Is Python 3.7 affected as well?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40294>
_______________________________________

From report at bugs.python.org  Thu Apr 16 22:37:33 2020
From: report at bugs.python.org (Jeffrey Quesnelle)
Date: Fri, 17 Apr 2020 02:37:33 +0000
Subject: [issue40294] Use-after-free crash if multiple interpreters import
 asyncio module
In-Reply-To: <1586971925.67.0.678462551955.issue40294@roundup.psfhosted.org>
Message-ID: <1587091053.32.0.575652535283.issue40294@roundup.psfhosted.org>


Jeffrey Quesnelle <jquesnelle at gmail.com> added the comment:

> Is Python 3.7 affected as well?

Nope, this was introduced in 3.8

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40294>
_______________________________________

From report at bugs.python.org  Thu Apr 16 22:42:48 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 17 Apr 2020 02:42:48 +0000
Subject: [issue40294] Use-after-free crash if multiple interpreters import
 asyncio module
In-Reply-To: <1586971925.67.0.678462551955.issue40294@roundup.psfhosted.org>
Message-ID: <1587091368.85.0.966660312131.issue40294@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Ok, the issue is now fixed: thanks Jeffrey Quesnelle!

> Nope, this was introduced in 3.8

I tested: attached main.c doesn't crash in 3.7. I guess that _asyncio leaks a few references, but it's not a big deal.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40294>
_______________________________________

From report at bugs.python.org  Thu Apr 16 23:26:16 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 17 Apr 2020 03:26:16 +0000
Subject: [issue40281] Add pathlib.PurePath.as_uri()
In-Reply-To: <1586869981.39.0.314985055066.issue40281@roundup.psfhosted.org>
Message-ID: <1587093976.31.0.304936865503.issue40281@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
nosy: +pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40281>
_______________________________________

From report at bugs.python.org  Thu Apr 16 23:49:54 2020
From: report at bugs.python.org (Andy Lester)
Date: Fri, 17 Apr 2020 03:49:54 +0000
Subject: [issue39943] Meta: Clean up various issues in C internals
In-Reply-To: <1583983387.49.0.277830283994.issue39943@roundup.psfhosted.org>
Message-ID: <1587095394.92.0.560566225369.issue39943@roundup.psfhosted.org>


Andy Lester <andy at petdance.com> added the comment:

I'm assuming that you're getting this sre_lib.h error when compiling Modules/_sre.c.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39943>
_______________________________________

From report at bugs.python.org  Fri Apr 17 02:49:29 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Fri, 17 Apr 2020 06:49:29 +0000
Subject: [issue38605] [typing] PEP 563: Postponed evaluation of annotations:
 enable it by default before Python 4.0
In-Reply-To: <1572192430.43.0.755831692199.issue38605@roundup.psfhosted.org>
Message-ID: <1587106169.74.0.961606873594.issue38605@roundup.psfhosted.org>


Change by Batuhan Taskaya <batuhanosmantaskaya at gmail.com>:


----------
nosy: +BTaskaya

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38605>
_______________________________________

From report at bugs.python.org  Fri Apr 17 02:56:56 2020
From: report at bugs.python.org (Inada Naoki)
Date: Fri, 17 Apr 2020 06:56:56 +0000
Subject: [issue40287] SpooledTemporaryFile.seek returns None
In-Reply-To: <1586914911.28.0.271091942099.issue40287@roundup.psfhosted.org>
Message-ID: <1587106616.9.0.681181060499.issue40287@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:


New changeset 485e715cb1ff92bc9882cd51ec32589f9cb30503 by Inada Naoki in branch 'master':
bpo-40287: Fix SpooledTemporaryFile.seek() return value (GH-19540)
https://github.com/python/cpython/commit/485e715cb1ff92bc9882cd51ec32589f9cb30503


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40287>
_______________________________________

From report at bugs.python.org  Fri Apr 17 02:56:55 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 17 Apr 2020 06:56:55 +0000
Subject: [issue40287] SpooledTemporaryFile.seek returns None
In-Reply-To: <1586914911.28.0.271091942099.issue40287@roundup.psfhosted.org>
Message-ID: <1587106615.85.0.38770150285.issue40287@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
nosy: +miss-islington
nosy_count: 2.0 -> 3.0
pull_requests: +18908
pull_request: https://github.com/python/cpython/pull/19566

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40287>
_______________________________________

From report at bugs.python.org  Fri Apr 17 02:57:02 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 17 Apr 2020 06:57:02 +0000
Subject: [issue40287] SpooledTemporaryFile.seek returns None
In-Reply-To: <1586914911.28.0.271091942099.issue40287@roundup.psfhosted.org>
Message-ID: <1587106622.48.0.216198621909.issue40287@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +18909
pull_request: https://github.com/python/cpython/pull/19567

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40287>
_______________________________________

From report at bugs.python.org  Fri Apr 17 03:13:38 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 17 Apr 2020 07:13:38 +0000
Subject: [issue40287] SpooledTemporaryFile.seek returns None
In-Reply-To: <1586914911.28.0.271091942099.issue40287@roundup.psfhosted.org>
Message-ID: <1587107618.27.0.0309955453916.issue40287@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 11ae7d075293fe855c8af26b577656d1026cd9bb by Miss Islington (bot) in branch '3.7':
bpo-40287: Fix SpooledTemporaryFile.seek() return value (GH-19540)
https://github.com/python/cpython/commit/11ae7d075293fe855c8af26b577656d1026cd9bb


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40287>
_______________________________________

From report at bugs.python.org  Fri Apr 17 03:14:59 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 17 Apr 2020 07:14:59 +0000
Subject: [issue40287] SpooledTemporaryFile.seek returns None
In-Reply-To: <1586914911.28.0.271091942099.issue40287@roundup.psfhosted.org>
Message-ID: <1587107699.32.0.60666251267.issue40287@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 9796fe88da7415925b3e8f7e0a5e55301548734f by Miss Islington (bot) in branch '3.8':
bpo-40287: Fix SpooledTemporaryFile.seek() return value (GH-19540)
https://github.com/python/cpython/commit/9796fe88da7415925b3e8f7e0a5e55301548734f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40287>
_______________________________________

From report at bugs.python.org  Fri Apr 17 03:15:52 2020
From: report at bugs.python.org (Inada Naoki)
Date: Fri, 17 Apr 2020 07:15:52 +0000
Subject: [issue40287] SpooledTemporaryFile.seek returns None
In-Reply-To: <1586914911.28.0.271091942099.issue40287@roundup.psfhosted.org>
Message-ID: <1587107752.48.0.229875671646.issue40287@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.7, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40287>
_______________________________________

From report at bugs.python.org  Fri Apr 17 04:31:15 2020
From: report at bugs.python.org (Gharg)
Date: Fri, 17 Apr 2020 08:31:15 +0000
Subject: [issue40303] argparse parse_args args parameter bug or intended
In-Reply-To: <1587055634.08.0.65599497467.issue40303@roundup.psfhosted.org>
Message-ID: <1587112275.53.0.0842449709379.issue40303@roundup.psfhosted.org>


Gharg <ghaarg at gmail.com> added the comment:

Hi R?mi and Paul,

thanks for your quick response.
It is as i expected and i will use 'store_true'/'store_false' to resolve my problem.

I see this issue as resolved and close it.

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40303>
_______________________________________

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: =?utf-8?q?=5Bissue40309=5D_=E2=80=9Cunmatched_paren=E2=80=9D_for_space_be?=
 =?utf-8?q?fore_parenthesis_in_Py=5FBuildValue?=
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 05:17:05 2020
From: report at bugs.python.org (Pikamander2)
Date: Fri, 17 Apr 2020 09:17:05 +0000
Subject: [issue34480] _markupbase.py fails with UnboundLocalError on invalid
 keyword in marked section
In-Reply-To: <1535045437.7.0.56676864532.issue34480@psf.upfronthosting.co.za>
Message-ID: <1587115025.14.0.00422729718814.issue34480@roundup.psfhosted.org>


Pikamander2 <Pikamander2 at gmail.com> added the comment:

Here's a simplified real world example that I found if it helps anyone:

import bs4

html = '''<html><head><!fill in here--> <![end--><!-- start: SSI y-xtra-topspace.shtml --><!-- --></head><body></body></html>'''

soup = bs4.BeautifulSoup(html, 'html.parser')

----------
nosy: +Pikamander2
Added file: https://bugs.python.org/file49070/weird-bug-3.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34480>
_______________________________________

From report at bugs.python.org  Fri Apr 17 05:21:19 2020
From: report at bugs.python.org (Pikamander2)
Date: Fri, 17 Apr 2020 09:21:19 +0000
Subject: [issue34480] _markupbase.py fails with UnboundLocalError on invalid
 keyword in marked section
In-Reply-To: <1535045437.7.0.56676864532.issue34480@psf.upfronthosting.co.za>
Message-ID: <1587115279.62.0.917318718086.issue34480@roundup.psfhosted.org>


Pikamander2 <Pikamander2 at gmail.com> added the comment:

For reference, my Python version is 3.8.2 and my bs4 version is 4.8.1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34480>
_______________________________________

From report at bugs.python.org  Fri Apr 17 05:35:20 2020
From: report at bugs.python.org (Pikamander2)
Date: Fri, 17 Apr 2020 09:35:20 +0000
Subject: [issue34480] _markupbase.py fails with UnboundLocalError on invalid
 keyword in marked section
In-Reply-To: <1535045437.7.0.56676864532.issue34480@psf.upfronthosting.co.za>
Message-ID: <1587116120.26.0.200890904105.issue34480@roundup.psfhosted.org>


Pikamander2 <Pikamander2 at gmail.com> added the comment:

I updated to bs4 version 4.9.0 and the same issue occurs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34480>
_______________________________________

From report at bugs.python.org  Fri Apr 17 05:56:23 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 17 Apr 2020 09:56:23 +0000
Subject: [issue40281] Add pathlib.PurePath.as_uri()
In-Reply-To: <1586869981.39.0.314985055066.issue40281@roundup.psfhosted.org>
Message-ID: <1587117383.43.0.473767417588.issue40281@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Is this different from https://docs.python.org/3/library/pathlib.html#pathlib.PurePath.as_uri

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40281>
_______________________________________

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: [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 06:45:52 2020
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 17 Apr 2020 10:45:52 +0000
Subject: [issue40281] Add pathlib.PurePath.as_uri()
In-Reply-To: <1586869981.39.0.314985055066.issue40281@roundup.psfhosted.org>
Message-ID: <1587120352.0.0.693412370735.issue40281@roundup.psfhosted.org>


Antoine Pitrou <solipsis at pitrou.net> added the comment:

Hmm, it looks like I lost my head from 10 years ago :-S

Sorry for the noise, everyone.

----------
resolution:  -> works for me
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40281>
_______________________________________

From report at bugs.python.org  Fri Apr 17 06:59:25 2020
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Fri, 17 Apr 2020 10:59:25 +0000
Subject: [issue40310] If use element from for in while loop it will have bad
 iterate.
In-Reply-To: <1587118643.2.0.902687286984.issue40310@roundup.psfhosted.org>
Message-ID: <1587121165.34.0.143936923209.issue40310@roundup.psfhosted.org>


R?mi Lapeyre <remi.lapeyre at henki.fr> added the comment:

Hi Maks, when you report a bug please write a minimal example that show the bug so we don't have to read the whole application (https://stackoverflow.com/help/minimal-reproducible-example).

I think in this case that the issue is that you overrride model on line 65 `model = car[1]` hence the error on the next iteration, model has been replaced.

This bug tracker is for bugs in the Python interpreter, for help in using Python please use the python-help mailing list or a forum like StackOverflow.

----------
nosy: +remi.lapeyre

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40310>
_______________________________________

From report at bugs.python.org  Fri Apr 17 07:03:13 2020
From: report at bugs.python.org (Maks Bleo)
Date: Fri, 17 Apr 2020 11:03:13 +0000
Subject: [issue40310] If use element from for in while loop it will have bad
 iterate.
In-Reply-To: <1587121165.34.0.143936923209.issue40310@roundup.psfhosted.org>
Message-ID: <CAGb653KtuZZuDkcpAP-J4iz_43+aBnfiv8rRWTvxq4_J=pVmRw@mail.gmail.com>


Maks Bleo <bleomaks at gmail.com> added the comment:

I don't think that it will overwrite element from for loop. In my mind it
was a bug.

Thank you.

On Fri, Apr 17, 2020, 1:59 PM R?mi Lapeyre <report at bugs.python.org> wrote:

>
> R?mi Lapeyre <remi.lapeyre at henki.fr> added the comment:
>
> Hi Maks, when you report a bug please write a minimal example that show
> the bug so we don't have to read the whole application (
> https://stackoverflow.com/help/minimal-reproducible-example).
>
> I think in this case that the issue is that you overrride model on line 65
> `model = car[1]` hence the error on the next iteration, model has been
> replaced.
>
> This bug tracker is for bugs in the Python interpreter, for help in using
> Python please use the python-help mailing list or a forum like
> StackOverflow.
>
> ----------
> nosy: +remi.lapeyre
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue40310>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40310>
_______________________________________

From report at bugs.python.org  Fri Apr 17 07:06:33 2020
From: report at bugs.python.org (Maks Bleo)
Date: Fri, 17 Apr 2020 11:06:33 +0000
Subject: [issue40310] If use element from for in while loop it will have bad
 iterate.
In-Reply-To: <1587118643.2.0.902687286984.issue40310@roundup.psfhosted.org>
Message-ID: <1587121593.33.0.836392522128.issue40310@roundup.psfhosted.org>


Change by Maks Bleo <bleomaks at gmail.com>:


----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40310>
_______________________________________

From report at bugs.python.org  Fri Apr 17 10:30:12 2020
From: report at bugs.python.org (Zackery Spytz)
Date: Fri, 17 Apr 2020 14:30:12 +0000
Subject: [issue32494] interface to gdbm_count
In-Reply-To: <1515102093.85.0.467229070634.issue32494@psf.upfronthosting.co.za>
Message-ID: <1587133812.02.0.865467568929.issue32494@roundup.psfhosted.org>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
keywords: +patch
nosy: +ZackerySpytz
nosy_count: 1.0 -> 2.0
pull_requests: +18910
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19569

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32494>
_______________________________________

From report at bugs.python.org  Fri Apr 17 10:30:54 2020
From: report at bugs.python.org (Zackery Spytz)
Date: Fri, 17 Apr 2020 14:30:54 +0000
Subject: [issue32494] interface to gdbm_count
In-Reply-To: <1515102093.85.0.467229070634.issue32494@psf.upfronthosting.co.za>
Message-ID: <1587133854.6.0.19444242552.issue32494@roundup.psfhosted.org>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
versions: +Python 3.9 -Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32494>
_______________________________________

From report at bugs.python.org  Fri Apr 17 10:47:39 2020
From: report at bugs.python.org (Fernando)
Date: Fri, 17 Apr 2020 14:47:39 +0000
Subject: [issue40154] embedded null byte when connecting to sqlite database
 using a bytes object
In-Reply-To: <1585830183.65.0.52883821516.issue40154@roundup.psfhosted.org>
Message-ID: <1587134859.55.0.496819054849.issue40154@roundup.psfhosted.org>


Fernando <ferferga.fer at gmail.com> added the comment:

Hello SilentGhost,

Okay, now I understand the difference and had my code working! Thank you very much for your answer and to all of you who help in making Python better.

(Wish I had more knowledge of it to help)

Have a nice day!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40154>
_______________________________________

From report at bugs.python.org  Fri Apr 17 10:48:34 2020
From: report at bugs.python.org (Martin Laus)
Date: Fri, 17 Apr 2020 14:48:34 +0000
Subject: [issue38884] __import__ is not thread-safe on Python 3
In-Reply-To: <1574363514.58.0.324753075286.issue38884@roundup.psfhosted.org>
Message-ID: <1587134914.14.0.742099508512.issue38884@roundup.psfhosted.org>


Change by Martin Laus <laus.martin at gmail.com>:


----------
nosy: +Martin Laus

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38884>
_______________________________________

From report at bugs.python.org  Fri Apr 17 10:51:47 2020
From: report at bugs.python.org (Big Stone)
Date: Fri, 17 Apr 2020 14:51:47 +0000
Subject: [issue40270] activate (or include) json1 extension in sqlite
In-Reply-To: <1586770672.18.0.207799300786.issue40270@roundup.psfhosted.org>
Message-ID: <1587135107.17.0.805286919689.issue40270@roundup.psfhosted.org>


Big Stone <stonebig34 at gmail.com> added the comment:

You may also consider having it on Mac Python-3.8 and not on Windows Python-3.8 is a total abnormality. For example, in the context of a Classroom.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40270>
_______________________________________

From report at bugs.python.org  Fri Apr 17 11:29:51 2020
From: report at bugs.python.org (Philip Lee)
Date: Fri, 17 Apr 2020 15:29:51 +0000
Subject: [issue19081] zipimport behaves badly when the zip file changes while
 the process is running
In-Reply-To: <1379995203.41.0.89812771706.issue19081@psf.upfronthosting.co.za>
Message-ID: <1587137391.39.0.164444851856.issue19081@roundup.psfhosted.org>


Philip Lee <redstone-cold at 163.com> added the comment:

The issue still remains in Python 3.8.

----------
nosy: +iMath
versions: +Python 3.8 -Python 2.7, Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19081>
_______________________________________

From report at bugs.python.org  Fri Apr 17 11:47:27 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 17 Apr 2020 15:47:27 +0000
Subject: [issue40302] Add _Py_bswap32() function to pyport.h
In-Reply-To: <1587046975.76.0.701994468055.issue40302@roundup.psfhosted.org>
Message-ID: <1587138447.63.0.179127558118.issue40302@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 1ae035b7e847064d09df01ca62b8a761e9b5aae3 by Victor Stinner in branch 'master':
bpo-40302: Add pycore_byteswap.h header file (GH-19552)
https://github.com/python/cpython/commit/1ae035b7e847064d09df01ca62b8a761e9b5aae3


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40302>
_______________________________________

From report at bugs.python.org  Fri Apr 17 12:03:00 2020
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 17 Apr 2020 16:03:00 +0000
Subject: [issue40300] logging.Formatter crashes when default_msec_format is
 None.
In-Reply-To: <1587031786.91.0.398301028125.issue40300@roundup.psfhosted.org>
Message-ID: <1587139380.41.0.919936439029.issue40300@roundup.psfhosted.org>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:


New changeset 06a35542aad15666cace307d841a95e33f3cbee6 by Mariusz Felisiak in branch 'master':
bpo-40300: Allow empty logging.Formatter.default_msec_format. (GH-19551)
https://github.com/python/cpython/commit/06a35542aad15666cace307d841a95e33f3cbee6


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40300>
_______________________________________

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: [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 12:24:51 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 17 Apr 2020 16:24:51 +0000
Subject: [issue40302] Add _Py_bswap32() function to pyport.h
In-Reply-To: <1587046975.76.0.701994468055.issue40302@roundup.psfhosted.org>
Message-ID: <1587140691.98.0.12113901345.issue40302@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +18912
pull_request: https://github.com/python/cpython/pull/19572

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40302>
_______________________________________

From report at bugs.python.org  Fri Apr 17 12:25:07 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 17 Apr 2020 16:25:07 +0000
Subject: [issue40302] Add _Py_bswap32() function to pyport.h
In-Reply-To: <1587046975.76.0.701994468055.issue40302@roundup.psfhosted.org>
Message-ID: <1587140707.68.0.104482419072.issue40302@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +18913
pull_request: https://github.com/python/cpython/pull/19573

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40302>
_______________________________________

From report at bugs.python.org  Fri Apr 17 12:28:35 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 17 Apr 2020 16:28:35 +0000
Subject: [issue40311] docs.python.org banner - release blocker for 2.7.18
In-Reply-To: <1587139977.42.0.984358391759.issue40311@roundup.psfhosted.org>
Message-ID: <1587140915.79.0.684119885124.issue40311@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

I'm marking it as a release blocker, as I believe that's the correct priority if it must be done before the 2.7.18 release.

----------
nosy: +eric.smith
priority: normal -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40311>
_______________________________________

From report at bugs.python.org  Fri Apr 17 12:40:06 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 17 Apr 2020 16:40:06 +0000
Subject: [issue40302] Add pycore_byteswap.h header file with _Py_bswap32()
 function
In-Reply-To: <1587046975.76.0.701994468055.issue40302@roundup.psfhosted.org>
Message-ID: <1587141606.85.0.752496219884.issue40302@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
title: Add _Py_bswap32() function to pyport.h -> Add pycore_byteswap.h header file with _Py_bswap32() function

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40302>
_______________________________________

From report at bugs.python.org  Fri Apr 17 12:40:12 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 17 Apr 2020 16:40:12 +0000
Subject: [issue40302] Add pycore_byteswap.h internal header file with
 _Py_bswap32() function
In-Reply-To: <1587046975.76.0.701994468055.issue40302@roundup.psfhosted.org>
Message-ID: <1587141612.29.0.453873954734.issue40302@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
title: Add pycore_byteswap.h header file with _Py_bswap32() function -> Add pycore_byteswap.h internal header file with _Py_bswap32() function

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40302>
_______________________________________

From report at bugs.python.org  Fri Apr 17 12:41:13 2020
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 17 Apr 2020 16:41:13 +0000
Subject: [issue39901] `pathlib.Path.owner()` and `group()` use `pwd` and `grp`
 modules directly
In-Reply-To: <1583659618.45.0.720570374465.issue39901@roundup.psfhosted.org>
Message-ID: <1587141673.94.0.499319852446.issue39901@roundup.psfhosted.org>


Antoine Pitrou <solipsis at pitrou.net> added the comment:


New changeset 22386bb4ef740ee92d34c87b8cb90d681423a853 by Barney Gale in branch 'master':
bpo-39901: Move `pathlib.Path.owner()` and `group()` implementations into the path accessor. (GH-18844)
https://github.com/python/cpython/commit/22386bb4ef740ee92d34c87b8cb90d681423a853


----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39901>
_______________________________________

From report at bugs.python.org  Fri Apr 17 12:41:29 2020
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 17 Apr 2020 16:41:29 +0000
Subject: [issue39901] `pathlib.Path.owner()` and `group()` use `pwd` and `grp`
 modules directly
In-Reply-To: <1583659618.45.0.720570374465.issue39901@roundup.psfhosted.org>
Message-ID: <1587141689.5.0.566765753963.issue39901@roundup.psfhosted.org>


Change by Antoine Pitrou <solipsis at pitrou.net>:


----------
nosy:  -pitrou
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39901>
_______________________________________

From report at bugs.python.org  Fri Apr 17 12:44:16 2020
From: report at bugs.python.org (Steve Dower)
Date: Fri, 17 Apr 2020 16:44:16 +0000
Subject: [issue40308] Intermittent failure of
 test_os.TestScandir.test_attributes on Windows
In-Reply-To: <1587073240.99.0.668032471383.issue40308@roundup.psfhosted.org>
Message-ID: <1587141856.19.0.0898964152578.issue40308@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Presumably you have something else on your system accessing the file.

Can you try disabling any file sync, anti-malware or indexing tools and see if that helps?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40308>
_______________________________________

From report at bugs.python.org  Fri Apr 17 13:03:17 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 17 Apr 2020 17:03:17 +0000
Subject: [issue40286] Add randbytes() method to random.Random
In-Reply-To: <1586903418.02.0.530735802731.issue40286@roundup.psfhosted.org>
Message-ID: <1587142997.1.0.61164420414.issue40286@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I wrote a quick benchmark:
---
import pyperf
import random

gen = random.Random()
# gen = random.SystemRandom()
gen.seed(850779834)

if 1: #hasattr(gen, 'randbytes'):
    func = type(gen).randbytes
elif 0:
    def py_randbytes(gen, n):
        data = bytearray(n)
        i = 0
        while i < n:
            chunk = 4
            word = gen.getrandbits(32)
            word = word.to_bytes(4, 'big')
            chunk = min(n, 4)
            data[i:i+chunk] = word[:chunk]
            i += chunk
        return bytes(data)

    func = py_randbytes
else:
    def getrandbits_to_bytes(gen, n):
        return gen.getrandbits(n * 8).to_bytes(n, 'little')

    func = getrandbits_to_bytes

runner = pyperf.Runner()
for nbytes in (1, 4, 16, 1024, 1024 * 1024):
    runner.bench_func(f'randbytes({nbytes})', func, gen, nbytes)
---

Results on Linux using gcc -O3 (without LTO or PGO) using the C randbytes() implementation as the reference:

+--------------------+-------------+----------------------------------+-------------------------------+
| Benchmark          | c_randbytes | py_randbytes                     | getrandbits_to_bytes          |
+====================+=============+==================================+===============================+
| randbytes(1)       | 71.4 ns     | 1.04 us: 14.51x slower (+1351%)  | 244 ns: 3.42x slower (+242%)  |
+--------------------+-------------+----------------------------------+-------------------------------+
| randbytes(4)       | 71.4 ns     | 1.03 us: 14.48x slower (+1348%)  | 261 ns: 3.66x slower (+266%)  |
+--------------------+-------------+----------------------------------+-------------------------------+
| randbytes(16)      | 81.9 ns     | 3.07 us: 37.51x slower (+3651%)  | 321 ns: 3.92x slower (+292%)  |
+--------------------+-------------+----------------------------------+-------------------------------+
| randbytes(1024)    | 1.05 us     | 173 us: 165.41x slower (+16441%) | 3.66 us: 3.49x slower (+249%) |
+--------------------+-------------+----------------------------------+-------------------------------+
| randbytes(1048576) | 955 us      | 187 ms: 196.30x slower (+19530%) | 4.37 ms: 4.58x slower (+358%) |
+--------------------+-------------+----------------------------------+-------------------------------+

* c_randbytes: PR 19527, randbytes() methods implemented in C
* py_randbytes: bytearray, getrandbits(), .to_bytes()
* getrandbits_to_bytes: Serhiy's implementation: gen.getrandbits(n * 8).to_bytes(n, 'little')

So well, the C randbytes() implementation is always the fastest.


random.SystemRandom().randbytes() (os.urandom(n)) performance using random.Random().randbytes() (Mersenne Twister) as a reference:

+--------------------+-------------+---------------------------------+
| Benchmark          | c_randbytes | systemrandom                    |
+====================+=============+=================================+
| randbytes(1)       | 71.4 ns     | 994 ns: 13.93x slower (+1293%)  |
+--------------------+-------------+---------------------------------+
| randbytes(4)       | 71.4 ns     | 1.04 us: 14.60x slower (+1360%) |
+--------------------+-------------+---------------------------------+
| randbytes(16)      | 81.9 ns     | 1.02 us: 12.49x slower (+1149%) |
+--------------------+-------------+---------------------------------+
| randbytes(1024)    | 1.05 us     | 6.22 us: 5.93x slower (+493%)   |
+--------------------+-------------+---------------------------------+
| randbytes(1048576) | 955 us      | 5.64 ms: 5.91x slower (+491%)   |
+--------------------+-------------+---------------------------------+

os.urandom() is way slower than Mersenne Twister.

Well, that's not surprising: os.urandom() requires at least one syscall (getrandom() syscall on my Linux machine).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40286>
_______________________________________

From report at bugs.python.org  Fri Apr 17 13:05:50 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 17 Apr 2020 17:05:50 +0000
Subject: [issue40286] Add randbytes() method to random.Random
In-Reply-To: <1586903418.02.0.530735802731.issue40286@roundup.psfhosted.org>
Message-ID: <1587143150.68.0.00148565738784.issue40286@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 9f5fe7910f4a1bf5a425837d4915e332b945eb7b by Victor Stinner in branch 'master':
bpo-40286: Add randbytes() method to random.Random (GH-19527)
https://github.com/python/cpython/commit/9f5fe7910f4a1bf5a425837d4915e332b945eb7b


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40286>
_______________________________________

From report at bugs.python.org  Fri Apr 17 13:06:22 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 17 Apr 2020 17:06:22 +0000
Subject: [issue40286] Add randbytes() method to random.Random
In-Reply-To: <1586903418.02.0.530735802731.issue40286@roundup.psfhosted.org>
Message-ID: <1587143182.53.0.977914891886.issue40286@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40286>
_______________________________________

From report at bugs.python.org  Fri Apr 17 13:13:10 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 17 Apr 2020 17:13:10 +0000
Subject: [issue40302] Add pycore_byteswap.h internal header file with
 _Py_bswap32() function
In-Reply-To: <1587046975.76.0.701994468055.issue40302@roundup.psfhosted.org>
Message-ID: <1587143590.16.0.523818739035.issue40302@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 1a1bd2e23871619adc1405e1cdc7c1e61252fd2c by Victor Stinner in branch 'master':
bpo-40302: Replace PY_INT64_T with int64_t (GH-19573)
https://github.com/python/cpython/commit/1a1bd2e23871619adc1405e1cdc7c1e61252fd2c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40302>
_______________________________________

From report at bugs.python.org  Fri Apr 17 13:13:22 2020
From: report at bugs.python.org (hai shi)
Date: Fri, 17 Apr 2020 17:13:22 +0000
Subject: [issue40092] Crash in _PyThreadState_DeleteExcept() at fork in the
 process child
In-Reply-To: <1585329415.65.0.534969367772.issue40092@roundup.psfhosted.org>
Message-ID: <1587143602.91.0.980062629395.issue40092@roundup.psfhosted.org>


Change by hai shi <shihai1991 at 126.com>:


----------
nosy: +shihai1991

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40092>
_______________________________________

From report at bugs.python.org  Fri Apr 17 13:13:38 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 17 Apr 2020 17:13:38 +0000
Subject: [issue40302] Add pycore_byteswap.h internal header file with
 _Py_bswap32() function
In-Reply-To: <1587046975.76.0.701994468055.issue40302@roundup.psfhosted.org>
Message-ID: <1587143618.03.0.125055253338.issue40302@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset d7c657d4b121164caa439253da5266b2e29a1bed by Victor Stinner in branch 'master':
bpo-40302: UTF-32 encoder SWAB4() macro use a|b rather than a+b (GH-19572)
https://github.com/python/cpython/commit/d7c657d4b121164caa439253da5266b2e29a1bed


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40302>
_______________________________________

From report at bugs.python.org  Fri Apr 17 13:15:00 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 17 Apr 2020 17:15:00 +0000
Subject: [issue40302] Add pycore_byteswap.h internal header file with
 _Py_bswap32() function
In-Reply-To: <1587046975.76.0.701994468055.issue40302@roundup.psfhosted.org>
Message-ID: <1587143700.26.0.276817656321.issue40302@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

FYI this issue was motivated by the implementation of random.Random().randbytes(): bpo-40286.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40302>
_______________________________________

From report at bugs.python.org  Fri Apr 17 13:32:20 2020
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 17 Apr 2020 17:32:20 +0000
Subject: [issue40282] random.getrandbits(0) should succeed
In-Reply-To: <1586878355.33.0.583777817655.issue40282@roundup.psfhosted.org>
Message-ID: <1587144740.8.0.463070404596.issue40282@roundup.psfhosted.org>


Antoine Pitrou <solipsis at pitrou.net> added the comment:


New changeset 75a3378810bab03949ad9f653f78d933bdf3879c by Antoine Pitrou in branch 'master':
bpo-40282: Allow random.getrandbits(0) (GH-19539)
https://github.com/python/cpython/commit/75a3378810bab03949ad9f653f78d933bdf3879c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40282>
_______________________________________

From report at bugs.python.org  Fri Apr 17 13:32:30 2020
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 17 Apr 2020 17:32:30 +0000
Subject: [issue40282] random.getrandbits(0) should succeed
In-Reply-To: <1586878355.33.0.583777817655.issue40282@roundup.psfhosted.org>
Message-ID: <1587144750.37.0.651818767005.issue40282@roundup.psfhosted.org>


Change by Antoine Pitrou <solipsis at pitrou.net>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40282>
_______________________________________

From report at bugs.python.org  Fri Apr 17 13:42:13 2020
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 17 Apr 2020 17:42:13 +0000
Subject: [issue39897] `pathlib.Path.is_mount()` calls `Path(self.parent)` and
 therefore misbehaves in `Path` subclasses
In-Reply-To: <1583640668.8.0.328631342101.issue39897@roundup.psfhosted.org>
Message-ID: <1587145333.06.0.875505428658.issue39897@roundup.psfhosted.org>


Antoine Pitrou <solipsis at pitrou.net> added the comment:


New changeset c746c4f353510a17683a49ed7f90ffaae664ff7b by Barney Gale in branch 'master':
bpo-39897: Remove needless `Path(self.parent)` call, which makes `is_mount()` misbehave in `Path` subclasses. (GH-18839)
https://github.com/python/cpython/commit/c746c4f353510a17683a49ed7f90ffaae664ff7b


----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39897>
_______________________________________

From report at bugs.python.org  Fri Apr 17 13:46:21 2020
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 17 Apr 2020 17:46:21 +0000
Subject: [issue39897] `pathlib.Path.is_mount()` calls `Path(self.parent)` and
 therefore misbehaves in `Path` subclasses
In-Reply-To: <1583640668.8.0.328631342101.issue39897@roundup.psfhosted.org>
Message-ID: <1587145581.23.0.00859345612174.issue39897@roundup.psfhosted.org>


Change by Antoine Pitrou <solipsis at pitrou.net>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39897>
_______________________________________

From report at bugs.python.org  Fri Apr 17 13:47:42 2020
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 17 Apr 2020 17:47:42 +0000
Subject: [issue39894] `pathlib.Path.samefile()` calls `os.stat()` without
 using accessor
In-Reply-To: <1583639089.94.0.893422780833.issue39894@roundup.psfhosted.org>
Message-ID: <1587145662.95.0.984237881429.issue39894@roundup.psfhosted.org>


Change by Antoine Pitrou <solipsis at pitrou.net>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39894>
_______________________________________

From report at bugs.python.org  Fri Apr 17 13:47:31 2020
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 17 Apr 2020 17:47:31 +0000
Subject: [issue39894] `pathlib.Path.samefile()` calls `os.stat()` without
 using accessor
In-Reply-To: <1583639089.94.0.893422780833.issue39894@roundup.psfhosted.org>
Message-ID: <1587145651.75.0.496930367629.issue39894@roundup.psfhosted.org>


Antoine Pitrou <solipsis at pitrou.net> added the comment:


New changeset 5b1d9184bb0e34391637c06bc7651fb6de8a6240 by Barney Gale in branch 'master':
bpo-39894: Route calls from pathlib.Path.samefile() to os.stat() via the path accessor (GH-18836)
https://github.com/python/cpython/commit/5b1d9184bb0e34391637c06bc7651fb6de8a6240


----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39894>
_______________________________________

From report at bugs.python.org  Fri Apr 17 13:59:50 2020
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 17 Apr 2020 17:59:50 +0000
Subject: [issue33898] pathlib issues with Windows device paths
In-Reply-To: <1529361630.0.0.56676864532.issue33898@psf.upfronthosting.co.za>
Message-ID: <1587146390.78.0.0772238282131.issue33898@roundup.psfhosted.org>


Change by Antoine Pitrou <solipsis at pitrou.net>:


----------
versions: +Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33898>
_______________________________________

From report at bugs.python.org  Fri Apr 17 14:04:13 2020
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 17 Apr 2020 18:04:13 +0000
Subject: [issue35306] OSError [WinError 123] when testing if pathlib.Path('*')
 (asterisks) exists
In-Reply-To: <1543038959.25.0.788709270274.issue35306@psf.upfronthosting.co.za>
Message-ID: <1587146653.78.0.787678589571.issue35306@roundup.psfhosted.org>


Change by Antoine Pitrou <solipsis at pitrou.net>:


----------
versions: +Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35306>
_______________________________________

From report at bugs.python.org  Fri Apr 17 14:10:14 2020
From: report at bugs.python.org (Furkan Onder)
Date: Fri, 17 Apr 2020 18:10:14 +0000
Subject: [issue40223] Add -fwrapv for new icc versions
In-Reply-To: <1586342429.44.0.914021178636.issue40223@roundup.psfhosted.org>
Message-ID: <1587147014.96.0.792569856082.issue40223@roundup.psfhosted.org>


Furkan Onder <furkanonder at protonmail.com> added the comment:

Pr has been sent.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40223>
_______________________________________

From report at bugs.python.org  Fri Apr 17 14:31:11 2020
From: report at bugs.python.org (Ned Deily)
Date: Fri, 17 Apr 2020 18:31:11 +0000
Subject: [issue40247] Logged out of user when running Tkinter
In-Reply-To: <1586551795.67.0.408476098567.issue40247@roundup.psfhosted.org>
Message-ID: <1587148271.39.0.752744425165.issue40247@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40247>
_______________________________________

From report at bugs.python.org  Fri Apr 17 15:04:34 2020
From: report at bugs.python.org (Furkan Onder)
Date: Fri, 17 Apr 2020 19:04:34 +0000
Subject: [issue19113] duplicate test names in Lib/ctypes/test/test_functions.py
In-Reply-To: <1380385419.52.0.767012097586.issue19113@psf.upfronthosting.co.za>
Message-ID: <1587150274.08.0.477869650951.issue19113@roundup.psfhosted.org>


Furkan Onder <furkanonder at protonmail.com> added the comment:

There are two tests with same name in the same test class  (ctypes.test.test_functions test_errors)
After merging both and re-run I encounter with this error
which looks like it was always there but overwritten by other test (with same name)

....F...........s.s...
======================================================================
FAIL: test_errors (__main__.FunctionTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/furkan/cpython/Lib/ctypes/test/test_functions.py", line 219, in test_errors
    self.assertRaises(TypeError, f, X()) #cannot convert parameter
AssertionError: TypeError not raised by _testfunc_p_p

----------------------------------------------------------------------
Ran 22 tests in 0.003s

----------
nosy: +furkanonder

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19113>
_______________________________________

From report at bugs.python.org  Fri Apr 17 15:14:19 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 17 Apr 2020 19:14:19 +0000
Subject: [issue40286] Add randbytes() method to random.Random
In-Reply-To: <1586903418.02.0.530735802731.issue40286@roundup.psfhosted.org>
Message-ID: <1587150859.51.0.825744939709.issue40286@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +18914
pull_request: https://github.com/python/cpython/pull/19574

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40286>
_______________________________________

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: [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:12:00 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 17 Apr 2020 20:12:00 +0000
Subject: [issue40286] Add randbytes() method to random.Random
In-Reply-To: <1586903418.02.0.530735802731.issue40286@roundup.psfhosted.org>
Message-ID: <1587154320.16.0.966432879065.issue40286@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +18915
pull_request: https://github.com/python/cpython/pull/19575

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40286>
_______________________________________

From report at bugs.python.org  Fri Apr 17 16:51:35 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 17 Apr 2020 20:51:35 +0000
Subject: [issue40286] Add randbytes() method to random.Random
In-Reply-To: <1586903418.02.0.530735802731.issue40286@roundup.psfhosted.org>
Message-ID: <1587156695.55.0.827730767148.issue40286@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 223221b290db00ca1042c77103efcbc072f29c90 by Serhiy Storchaka in branch 'master':
bpo-40286: Makes simpler the relation between randbytes() and getrandbits() (GH-19574)
https://github.com/python/cpython/commit/223221b290db00ca1042c77103efcbc072f29c90


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40286>
_______________________________________

From report at bugs.python.org  Fri Apr 17 16:54:41 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 17 Apr 2020 20:54:41 +0000
Subject: [issue40286] Add randbytes() method to random.Random
In-Reply-To: <1586903418.02.0.530735802731.issue40286@roundup.psfhosted.org>
Message-ID: <1587156881.85.0.734656831135.issue40286@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 87502ddd710eb1f030b8ff5a60b05becea3f474f by Victor Stinner in branch 'master':
bpo-40286: Use random.randbytes() in tests (GH-19575)
https://github.com/python/cpython/commit/87502ddd710eb1f030b8ff5a60b05becea3f474f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40286>
_______________________________________

From report at bugs.python.org  Fri Apr 17 16:58:30 2020
From: report at bugs.python.org (Antony Lee)
Date: Fri, 17 Apr 2020 20:58:30 +0000
Subject: [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 17:12:34 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 17 Apr 2020 21:12:34 +0000
Subject: [issue40237] Test code coverage (C) job of Travis CI fails on
 test_distutils which creates _configtest.gcno file
In-Reply-To: <1586436730.26.0.786791148526.issue40237@roundup.psfhosted.org>
Message-ID: <1587157954.53.0.985853307976.issue40237@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I understand that with PR 19460, code coverage is not longer run on C extension modules of the stdlib. I'm not using C code coverage, so I don't know how it's supposed to be used or analyzed.

Hai: if you want to move on this issue, you have to find who uses this CI and how it should behave.

The other option is to only fix test_distutils.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40237>
_______________________________________

From report at bugs.python.org  Fri Apr 17 18:30:21 2020
From: report at bugs.python.org (deekay)
Date: Fri, 17 Apr 2020 22:30:21 +0000
Subject: [issue40312] Weakref callbacks running before finalizers in GC
 collection
In-Reply-To: <1587153160.93.0.26793085181.issue40312@roundup.psfhosted.org>
Message-ID: <1587162621.81.0.544541712326.issue40312@roundup.psfhosted.org>


deekay <dee2thekay42 at gmail.com> added the comment:

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}")

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?

----------
nosy: +deekay

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40312>
_______________________________________

From report at bugs.python.org  Fri Apr 17 18:32:42 2020
From: report at bugs.python.org (deekay)
Date: Fri, 17 Apr 2020 22:32:42 +0000
Subject: [issue40312] Weakref callbacks running before finalizers in GC
 collection
In-Reply-To: <1587153160.93.0.26793085181.issue40312@roundup.psfhosted.org>
Message-ID: <1587162762.9.0.0364632728653.issue40312@roundup.psfhosted.org>


deekay <dee2thekay42 at gmail.com> added the comment:

Wrong thread, wrong thread, abort!
Sorry, I meant to submit this as a separate issue.
I don't see a delete option.
Maybe a mod can remove this please?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40312>
_______________________________________

From report at bugs.python.org  Fri Apr 17 18:34:21 2020
From: report at bugs.python.org (Ned Deily)
Date: Fri, 17 Apr 2020 22:34:21 +0000
Subject: [issue40312] Weakref callbacks running before finalizers in GC
 collection
In-Reply-To: <1587153160.93.0.26793085181.issue40312@roundup.psfhosted.org>
Message-ID: <1587162861.68.0.69052942816.issue40312@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

Going going gone

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40312>
_______________________________________

From report at bugs.python.org  Fri Apr 17 18:34:45 2020
From: report at bugs.python.org (Ned Deily)
Date: Fri, 17 Apr 2020 22:34:45 +0000
Subject: [issue40312] Weakref callbacks running before finalizers in GC
 collection
In-Reply-To: <1587153160.93.0.26793085181.issue40312@roundup.psfhosted.org>
Message-ID: <1587162885.16.0.797411899267.issue40312@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


----------
Removed message: https://bugs.python.org/msg366680

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40312>
_______________________________________

From report at bugs.python.org  Fri Apr 17 18:34:59 2020
From: report at bugs.python.org (Ned Deily)
Date: Fri, 17 Apr 2020 22:34:59 +0000
Subject: [issue40312] Weakref callbacks running before finalizers in GC
 collection
In-Reply-To: <1587153160.93.0.26793085181.issue40312@roundup.psfhosted.org>
Message-ID: <1587162899.86.0.225608462811.issue40312@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


----------
Removed message: https://bugs.python.org/msg366682

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40312>
_______________________________________

From report at bugs.python.org  Fri Apr 17 18:34:52 2020
From: report at bugs.python.org (Ned Deily)
Date: Fri, 17 Apr 2020 22:34:52 +0000
Subject: [issue40312] Weakref callbacks running before finalizers in GC
 collection
In-Reply-To: <1587153160.93.0.26793085181.issue40312@roundup.psfhosted.org>
Message-ID: <1587162892.55.0.966594460552.issue40312@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


----------
Removed message: https://bugs.python.org/msg366681

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40312>
_______________________________________

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: [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 18:35:43 2020
From: report at bugs.python.org (Ned Deily)
Date: Fri, 17 Apr 2020 22:35:43 +0000
Subject: [issue40312] Weakref callbacks running before finalizers in GC
 collection
In-Reply-To: <1587153160.93.0.26793085181.issue40312@roundup.psfhosted.org>
Message-ID: <1587162943.14.0.886762760121.issue40312@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


----------
nosy:  -ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40312>
_______________________________________

From report at bugs.python.org  Fri Apr 17 18:37:38 2020
From: report at bugs.python.org (Ned Deily)
Date: Fri, 17 Apr 2020 22:37:38 +0000
Subject: [issue40247] Logged out of user when running Tkinter
In-Reply-To: <1586551795.67.0.408476098567.issue40247@roundup.psfhosted.org>
Message-ID: <1587163058.92.0.576502480601.issue40247@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

Can you give the exact sequence of steps to reproduce the problem you see, please?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40247>
_______________________________________

From report at bugs.python.org  Fri Apr 17 19:09:55 2020
From: report at bugs.python.org (Massimo Sala)
Date: Fri, 17 Apr 2020 23:09:55 +0000
Subject: [issue40301] zipfile module: new feature (two lines of code),
 useful for test, security and forensics
In-Reply-To: <1587048194.21.0.732722493421.issue40301@roundup.psfhosted.org>
Message-ID: <CAKv20-Vcs0aL0ktiv4Zx3=B2ft5HFXVsvswLpWYpN7mPfMQG=Q@mail.gmail.com>


Massimo Sala <massimo.sala.71 at gmail.com> added the comment:

Hi Steven

Every software "ecosystem" has its guidelines and I am a newbie about
python development.

Mmh I see your concerns. I agree about your deletions of all py 3 versions
before the latest 3.9.

About Py 2, I remark these facts:
- there are a lot of forensics tools still written for py 2;
- python 2.7.18 will be forever the last python 2 and I think is it fine to
end-users to have zipfile with this feature both in py 2.7 and py 3.9;
- in the code there isn't any new routine to test: the change is just to
expose one internal variable.

I agree my request is an exception but I think you have to agree this
situation is exceptional.
IMHO rules must exist to help us and I think this request doesn't carry any
burden.

I ask you please
- to reconsider my request
- anyway, to put me in contact with zipfile mainteners, I don't know how to
reach them but I want to hear them about this.

Many thanks, Massimo

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40301>
_______________________________________

From report at bugs.python.org  Fri Apr 17 19:13:51 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 17 Apr 2020 23:13:51 +0000
Subject: [issue38492] Microsoft Store app IDLE (Python 3.8) needs msvcp140.dll
In-Reply-To: <1571191392.22.0.935623826778.issue38492@roundup.psfhosted.org>
Message-ID: <1587165231.88.0.025792268776.issue38492@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +18916
pull_request: https://github.com/python/cpython/pull/19576

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38492>
_______________________________________

From report at bugs.python.org  Fri Apr 17 19:31:35 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 17 Apr 2020 23:31:35 +0000
Subject: [issue38492] Microsoft Store app IDLE (Python 3.8) needs msvcp140.dll
In-Reply-To: <1571191392.22.0.935623826778.issue38492@roundup.psfhosted.org>
Message-ID: <1587166295.61.0.75178263322.issue38492@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset c46dc6f72b4b23a33e66f196f174602d520716df by Miss Islington (bot) in branch '3.7':
bpo-38492: Remove pythonw.exe dependency on the Microsoft C++ runtime (GH-16824)
https://github.com/python/cpython/commit/c46dc6f72b4b23a33e66f196f174602d520716df


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38492>
_______________________________________

From report at bugs.python.org  Fri Apr 17 19:49:38 2020
From: report at bugs.python.org (Diogo Flores)
Date: Fri, 17 Apr 2020 23:49:38 +0000
Subject: [issue39959] Bug on multiprocessing.shared_memory
In-Reply-To: <1584128583.89.0.486447704556.issue39959@roundup.psfhosted.org>
Message-ID: <1587167378.31.0.602126845246.issue39959@roundup.psfhosted.org>


Diogo Flores <dxflores at outlook.com> added the comment:

Any update on this issue?

----------
title: (Possible) bug on multiprocessing.shared_memory -> Bug on multiprocessing.shared_memory

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39959>
_______________________________________

From report at bugs.python.org  Fri Apr 17 20:45:22 2020
From: report at bugs.python.org (Philip Lee)
Date: Sat, 18 Apr 2020 00:45:22 +0000
Subject: [issue19081] zipimport behaves badly when the zip file changes while
 the process is running
In-Reply-To: <1379995203.41.0.89812771706.issue19081@psf.upfronthosting.co.za>
Message-ID: <1587170722.77.0.531366934679.issue19081@roundup.psfhosted.org>


Philip Lee <redstone-cold at 163.com> added the comment:

and I got ZipImportError: bad local file header

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19081>
_______________________________________

From report at bugs.python.org  Fri Apr 17 21:18:30 2020
From: report at bugs.python.org (Chih-Hsuan Yen)
Date: Sat, 18 Apr 2020 01:18:30 +0000
Subject: [issue35967] Better platform.processor support
In-Reply-To: <1549895363.53.0.252912531241.issue35967@roundup.psfhosted.org>
Message-ID: <1587172710.75.0.204943581823.issue35967@roundup.psfhosted.org>


Change by Chih-Hsuan Yen <yan12125 at gmail.com>:


----------
nosy: +yan12125
nosy_count: 4.0 -> 5.0
pull_requests: +18917
pull_request: https://github.com/python/cpython/pull/19577

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35967>
_______________________________________

From report at bugs.python.org  Fri Apr 17 21:26:18 2020
From: report at bugs.python.org (Daniel Hillier)
Date: Sat, 18 Apr 2020 01:26:18 +0000
Subject: [issue40301] zipfile module: new feature (two lines of code),
 useful for test, security and forensics
In-Reply-To: <1587045567.04.0.739688211881.issue40301@roundup.psfhosted.org>
Message-ID: <1587173178.71.0.0798763891005.issue40301@roundup.psfhosted.org>


Daniel Hillier <daniel.hillier at gmail.com> added the comment:

Could something similar be achieved by looking for the earliest file header offset?

def find_earliest_header_offset(zf):
    earliest_offset = None
    for zinfo in zf.infolist():
        if earliest_offset is None:
            earliest_offset = zinfo.header_offset
        else:
            earliest_offset = min(zinfo.header_offset, earliest_offset)
    return earliest_offset


You could also adapt this using

    zinfo.compress_size + len(zinfo.FileHeader())

to see if there were any sections inside the archive which were not referenced from the central directory. Not sure if zip files with arbitrary bytes inside the archive would be valid everywhere, but I think they are using zipfile.

You can also have zipped content inside an archive which has a valid fileheader but no reference from the central directory. Those entries are discoverable by implementations which process content serially from the start of the file but not implementations which rely on the central directory.

----------
nosy: +dhillier

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40301>
_______________________________________

From report at bugs.python.org  Fri Apr 17 21:37:16 2020
From: report at bugs.python.org (Andy Lester)
Date: Sat, 18 Apr 2020 01:37:16 +0000
Subject: [issue40314] python code order of magnitude faster than equivalent
 CPython code for simple import statement
In-Reply-To: <1587162924.52.0.924325577944.issue40314@roundup.psfhosted.org>
Message-ID: <1587173836.28.0.479325551851.issue40314@roundup.psfhosted.org>


Change by Andy Lester <andy at petdance.com>:


----------
nosy: +petdance

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40314>
_______________________________________

From report at bugs.python.org  Fri Apr 17 22:36:53 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Sat, 18 Apr 2020 02:36:53 +0000
Subject: [issue40301] zipfile module: new feature (two lines of code),
 useful for test, security and forensics
In-Reply-To: <CAKv20-Vcs0aL0ktiv4Zx3=B2ft5HFXVsvswLpWYpN7mPfMQG=Q@mail.gmail.com>
Message-ID: <20200418023328.GF26709@ando.pearwood.info>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

Sorry Massimo, there are no new features being added to 2.7, not even 
critical security fixes. That's not my decision.

https://www.python.org/doc/sunset-python-2/

Python 2 is effectively now a dead project from the point of view of us 
here at CPython. The very final bug fix release, 2.7.18, is due out any 
time soon, but it only includes fixes up to 1st of January.

You could try submitting your feature request to third-party bundlers of 
2.7, such as Red Hat, but I expect they will say no to new features.

For what it is worth, I don't agree that this situation is exceptional. 
Even if 2.7 wasn't obsolete, this is still a new feature. If we made an 
exception for you, then people using Python 2.7 still couldn't use this 
feature: `myzipfile.offset` would fail on code using Python 2.7, 2.7.1, 
2.7.2, 2.7.3, ... 2.7.17 and only work with 2.7.18. Nobody could use it 
unless their application required 2.7.18.

If you want this in 2.7 for your own personal use, wait for the 2.7.18 
final release, then add it into your personal copy. It is open source 
and you are completely permitted!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40301>
_______________________________________

From report at bugs.python.org  Fri Apr 17 23:25:02 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 18 Apr 2020 03:25:02 +0000
Subject: [issue1490384] PC new-logo-based icon set
Message-ID: <1587180302.51.0.322338324376.issue1490384@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
resolution: accepted -> fixed
stage:  -> resolved
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1490384>
_______________________________________

From report at bugs.python.org  Fri Apr 17 23:34:11 2020
From: report at bugs.python.org (Dennis Sweeney)
Date: Sat, 18 Apr 2020 03:34:11 +0000
Subject: [issue40308] Intermittent failure of
 test_os.TestScandir.test_attributes on Windows
In-Reply-To: <1587073240.99.0.668032471383.issue40308@roundup.psfhosted.org>
Message-ID: <1587180851.06.0.489849795445.issue40308@roundup.psfhosted.org>


Dennis Sweeney <sweeney.dennis650 at gmail.com> added the comment:

I disabled indexing and antivirus and I didn't see anything else obvious that would access the files, but I'm probably missing something -- I get the same intermittent failure when I build from the source at the 3.8.2 release, but not on a copy of 3.8.2 from python.org, so it's probably some setting that I don't know about for the repo folder. I think perhaps this isn't a real issue but rather me just not knowing the goings-on of my OS. :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40308>
_______________________________________

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: [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 01:24:34 2020
From: report at bugs.python.org (hai shi)
Date: Sat, 18 Apr 2020 05:24:34 +0000
Subject: [issue40237] Test code coverage (C) job of Travis CI fails on
 test_distutils which creates _configtest.gcno file
In-Reply-To: <1586436730.26.0.786791148526.issue40237@roundup.psfhosted.org>
Message-ID: <1587187474.41.0.555127683058.issue40237@roundup.psfhosted.org>


hai shi <shihai1991 at 126.com> added the comment:

> Hai: if you want to move on this issue, you have to find who uses this CI and how it should behave.

Copy that. I found PR7773 updated the travis' coverage ci and a discussion issue in https://github.com/python/core-workflow/issues/2, so I add brett and ammar to the noisy list, MAYBE they know the historical background.

----------
nosy: +ammar2, brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40237>
_______________________________________

From report at bugs.python.org  Sat Apr 18 02:27:30 2020
From: report at bugs.python.org (SilentGhost)
Date: Sat, 18 Apr 2020 06:27:30 +0000
Subject: [issue1490384] PC new-logo-based icon set
Message-ID: <1587191250.7.0.194446416657.issue1490384@roundup.psfhosted.org>


Change by SilentGhost <ghost.adh at runbox.com>:


----------
pull_requests:  -16955

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1490384>
_______________________________________

From report at bugs.python.org  Sat Apr 18 03:21:28 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 18 Apr 2020 07:21:28 +0000
Subject: [issue40315] Incorrect stacksize in code object
In-Reply-To: <1587181021.08.0.62849723006.issue40315@roundup.psfhosted.org>
Message-ID: <1587194488.19.0.654301618997.issue40315@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

The stack size is correct. The unreachable code is left because some code (in particularly the lineno setter of the frame object) depends on instructions which may be in the unreachable code to determines the boundaries of programming blocks. It is safer to keep some unreachable code.

You can just ignore the code which uses the stack past co_stacksize.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40315>
_______________________________________

From report at bugs.python.org  Sat Apr 18 03:36:23 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 18 Apr 2020 07:36:23 +0000
Subject: [issue40301] zipfile module: new feature (two lines of code),
 useful for test, security and forensics
In-Reply-To: <1587045567.04.0.739688211881.issue40301@roundup.psfhosted.org>
Message-ID: <1587195383.54.0.536725993433.issue40301@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I am not sure it would help you. There are legitimate files which contain a payload followed by the ZIP archive (self-extracting archives, programs with embedded ZIP archives). And the malware can make the offset of the ZIP archive be zero.

If you want to check whether the file looks like an executable, analyze first few bytes of the file. All executable files should start by one of well recognized signatures, otherwise the OS would not know how to execute them and they would not be malware.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40301>
_______________________________________

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: [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 05:37:50 2020
From: report at bugs.python.org (Or Toledano)
Date: Sat, 18 Apr 2020 09:37:50 +0000
Subject: [issue40316] Add zero function to time, datetime,
 which acts as the use case of replace to limit resolution
In-Reply-To: <1587202635.96.0.0810977655343.issue40316@roundup.psfhosted.org>
Message-ID: <1587202670.55.0.872636132423.issue40316@roundup.psfhosted.org>


Change by Or Toledano <ortoledano at protonmail.com>:


----------
keywords: +patch
pull_requests: +18918
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19580

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40316>
_______________________________________

From report at bugs.python.org  Sat Apr 18 05:38:52 2020
From: report at bugs.python.org (Or Toledano)
Date: Sat, 18 Apr 2020 09:38:52 +0000
Subject: [issue40316] Add zero function to time, datetime,
 which acts as the use case of replace to limit resolution
In-Reply-To: <1587202635.96.0.0810977655343.issue40316@roundup.psfhosted.org>
Message-ID: <1587202732.35.0.951275487699.issue40316@roundup.psfhosted.org>


Or Toledano <ortoledano at protonmail.com> added the comment:

https://github.com/python/cpython/pull/19580

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40316>
_______________________________________

From report at bugs.python.org  Sat Apr 18 06:28:31 2020
From: report at bugs.python.org (Ross Rhodes)
Date: Sat, 18 Apr 2020 10:28:31 +0000
Subject: [issue40028] Math module method to find prime factors for
 non-negative int n
In-Reply-To: <1584733974.83.0.0417466712916.issue40028@roundup.psfhosted.org>
Message-ID: <1587205711.84.0.814001346662.issue40028@roundup.psfhosted.org>


Ross Rhodes <ross.rhodes at hotmail.co.uk> added the comment:

Unable to dedicate time to this issue under the change of circumstances. Happy for someone else to re-open this if they take an interest in picking up this work.

----------
resolution:  -> postponed
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40028>
_______________________________________

From report at bugs.python.org  Sat Apr 18 07:18:34 2020
From: report at bugs.python.org (SilentGhost)
Date: Sat, 18 Apr 2020 11:18:34 +0000
Subject: [issue40316] Add zero function to time, datetime,
 which acts as the use case of replace to limit resolution
In-Reply-To: <1587202635.96.0.0810977655343.issue40316@roundup.psfhosted.org>
Message-ID: <1587208714.91.0.846111554834.issue40316@roundup.psfhosted.org>


SilentGhost <ghost.adh at runbox.com> added the comment:

What is the use-case for this new method?

----------
nosy: +SilentGhost

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40316>
_______________________________________

From report at bugs.python.org  Sat Apr 18 07:30:07 2020
From: report at bugs.python.org (Or Toledano)
Date: Sat, 18 Apr 2020 11:30:07 +0000
Subject: [issue40316] Add zero function to time, datetime,
 which acts as the use case of replace to limit resolution
In-Reply-To: <1587202635.96.0.0810977655343.issue40316@roundup.psfhosted.org>
Message-ID: <1587209407.24.0.22299396628.issue40316@roundup.psfhosted.org>


Or Toledano <ortoledano at protonmail.com> added the comment:

The use-case for this method is to "limit" the resolution of a time object.
I encountered the need for it when I needed to reduce the resolution of some timestamps, to compare them with timestamps of lesser resolution.
I found the following SOF post: https://stackoverflow.com/questions/13838394/can-i-easily-get-datetime-with-less-resolution-in-python
which made me think that a zero function can be nice for that use case of datetime.replace

----------

_______________________________________
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: [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: [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:56:18 2020
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Sat, 18 Apr 2020 11:56:18 +0000
Subject: [issue40318] Migrate to SQLite3 trace v2 API
In-Reply-To: <1587210970.59.0.35117859461.issue40318@roundup.psfhosted.org>
Message-ID: <1587210978.53.0.0927637050948.issue40318@roundup.psfhosted.org>


Change by Erlend Egeberg Aasland <erlend.aasland at innova.no>:


----------
type:  -> enhancement

_______________________________________
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: [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 08:00:26 2020
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Sat, 18 Apr 2020 12:00:26 +0000
Subject: [issue40318] Migrate to SQLite3 trace v2 API
In-Reply-To: <1587210970.59.0.35117859461.issue40318@roundup.psfhosted.org>
Message-ID: <1587211226.99.0.287292477977.issue40318@roundup.psfhosted.org>


Change by Erlend Egeberg Aasland <erlend.aasland at innova.no>:


----------
nosy: +ghaering

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40318>
_______________________________________

From report at bugs.python.org  Sat Apr 18 08:21:59 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 18 Apr 2020 12:21:59 +0000
Subject: [issue40319] dict.update() return the updated dict instead of None
In-Reply-To: <1587211075.61.0.291186837344.issue40319@roundup.psfhosted.org>
Message-ID: <1587212519.75.0.362631849349.issue40319@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40319>
_______________________________________

From report at bugs.python.org  Sat Apr 18 08:22:47 2020
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Sat, 18 Apr 2020 12:22:47 +0000
Subject: [issue40318] Migrate to SQLite3 trace v2 API
In-Reply-To: <1587210970.59.0.35117859461.issue40318@roundup.psfhosted.org>
Message-ID: <1587212567.22.0.794300798707.issue40318@roundup.psfhosted.org>


Change by Erlend Egeberg Aasland <erlend.aasland at innova.no>:


----------
pull_requests: +18919
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19581

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40318>
_______________________________________

From report at bugs.python.org  Sat Apr 18 08:25:29 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 18 Apr 2020 12:25:29 +0000
Subject: [issue40319] dict.update() return the updated dict instead of None
In-Reply-To: <1587211075.61.0.291186837344.issue40319@roundup.psfhosted.org>
Message-ID: <1587212729.53.0.54546640421.issue40319@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Can you please print the output of python -v? Using python 3.8.0 on Linux returns None for update method.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40319>
_______________________________________

From report at bugs.python.org  Sat Apr 18 08:40:54 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Sat, 18 Apr 2020 12:40:54 +0000
Subject: [issue40319] dict.update() return the updated dict instead of None
In-Reply-To: <1587211075.61.0.291186837344.issue40319@roundup.psfhosted.org>
Message-ID: <1587213654.72.0.67418255479.issue40319@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

Python 3.9.0a5+ (heads/master:c606624af8, Apr 18 2020, 18:42:51)
[Clang 11.0.3 (clang-1103.0.32.29)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> a = {"test": 1}
>>> b = {"type": 2}
>>> c = a.update(b)
>>> print(c)
None

on macOS master branch, the issue is not reproducible.

----------
nosy: +corona10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40319>
_______________________________________

From report at bugs.python.org  Sat Apr 18 08:44:39 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Sat, 18 Apr 2020 12:44:39 +0000
Subject: [issue40319] dict.update() return the updated dict instead of None
In-Reply-To: <1587211075.61.0.291186837344.issue40319@roundup.psfhosted.org>
Message-ID: <1587213879.73.0.22704025294.issue40319@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

Python 3.8.2+ (heads/3.8:c496e29c2b, Apr 18 2020, 21:42:41)
[Clang 11.0.3 (clang-1103.0.32.29)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> a = {"test": 1}
>>> b = {"type": 2}
>>> c = a.update(b)
>>> print(c)
None

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40319>
_______________________________________

From report at bugs.python.org  Sat Apr 18 08:47:24 2020
From: report at bugs.python.org (Skip Montanaro)
Date: Sat, 18 Apr 2020 12:47:24 +0000
Subject: [issue40315] Incorrect stacksize in code object
In-Reply-To: <1587181021.08.0.62849723006.issue40315@roundup.psfhosted.org>
Message-ID: <1587214044.54.0.137489121853.issue40315@roundup.psfhosted.org>


Skip Montanaro <skip.montanaro at gmail.com> added the comment:

Thanks, Serhiy.

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40315>
_______________________________________

From report at bugs.python.org  Sat Apr 18 08:51:37 2020
From: report at bugs.python.org (J)
Date: Sat, 18 Apr 2020 12:51:37 +0000
Subject: [issue40247] Logged out of user when running Tkinter
In-Reply-To: <1586551795.67.0.408476098567.issue40247@roundup.psfhosted.org>
Message-ID: <1587214297.46.0.393184723828.issue40247@roundup.psfhosted.org>


J <googoohashbrown at gmail.com> added the comment:

Thanks for reaching out. I solved the issue following @tcarroll2's solution from: https://github.com/pyenv/pyenv/issues/1375
The issue doesn't occur when using pyenv. It seems that the issue may have been caused by python sticking to the mac provided tkinter (version 8.5) instead of using a compatible version. With pyenv, I get python 3.7.4 and tkinter version 8.6.10 and it works flawlessly :)

Steps to reproduce crash: 
- Downloading Python version 3.8+ from python.org
- Typing python3 in terminal, importing tkinter as tk and starting a window with tk.Tk()
I am immediately logged out of my user. TkVersion is 8.6

Steps to reproduce weird window in window (my guess due to python using mac provided tkinter version 8.5):
- Downloading Python version 3.7.7 or older from python.org or homebrew
- Typing python3 in terminal, importing tkinter as tk and starting a window with tk.Tk()
- Voila! window in window created.

No logging out here, but the window created is unusable and glitchy. I tried running a tkinter GUI that works fine on other setups and the output was missing some widgets etc.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40247>
_______________________________________

From report at bugs.python.org  Sat Apr 18 08:58:58 2020
From: report at bugs.python.org (Massimo Sala)
Date: Sat, 18 Apr 2020 12:58:58 +0000
Subject: [issue40301] zipfile module: new feature (two lines of code),
 useful for test, security and forensics
In-Reply-To: <20200418023328.GF26709@ando.pearwood.info>
Message-ID: <CAKv20-VMfntoZt8LRqc8o1ggDnDA+4USRxaOTuQK4L32_iUDAg@mail.gmail.com>


Massimo Sala <massimo.sala.71 at gmail.com> added the comment:

On Sat, 18 Apr 2020 at 04:37, Steven D'Aprano <report at bugs.python.org>
wrote:
    If we made an exception for you, then people using Python 2.7 still
couldn't use this feature:
    `myzipfile.offset` would fail on code using Python 2.7, 2.7.1, 2.7.2,
2.7.3, ... 2.7.17 and only work with 2.7.18.
    Nobody could use it unless their application required 2.7.18.

Yes, it seems to me obvious it will work only with Python 2.7.18, and I see
no problem.
If you need new features, you have always to update (to a new MINOR version
or, like you said, MAJOR version).

I am used to other softwares where some features are backported to older
versions and IMHO it is very useful.
Sometimes you just need a specific feature and it isn't possible to update
to a MAJOR version.
You have to consider there are many legacy softwares, also in business, and
a version leap means a lot of work and tests.

Speaking in general, not only python: if the maintainers backport that
specific feature, bingo! you have only to update to the same MAJOR new
MINOR version. And this is good for the user base, there isn't "one size
fits all".
I shot my bullet but I cannot change python.org way of life.

Steven many thanks for your answers and patience to explain.
BTW yes I will patch python 2.7 sources and compile it... also on legacy,
intranet, centos 5 servers we cannot update :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40301>
_______________________________________

From report at bugs.python.org  Sat Apr 18 09:26:55 2020
From: report at bugs.python.org (SilentGhost)
Date: Sat, 18 Apr 2020 13:26:55 +0000
Subject: [issue40319] dict.update() return the updated dict instead of None
In-Reply-To: <1587211075.61.0.291186837344.issue40319@roundup.psfhosted.org>
Message-ID: <1587216415.64.0.884792453431.issue40319@roundup.psfhosted.org>


SilentGhost <ghost.adh at runbox.com> added the comment:

This looks like a proposed "enhancement" rather than a bug report. Unfortunately, this is not possible for a myriad of reasons, from backward compatibility to overall use of mutating methods in Python.

----------
nosy: +SilentGhost
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40319>
_______________________________________

From report at bugs.python.org  Sat Apr 18 09:31:36 2020
From: report at bugs.python.org (Massimo Sala)
Date: Sat, 18 Apr 2020 13:31:36 +0000
Subject: [issue40301] zipfile module: new feature (two lines of code),
 useful for test, security and forensics
In-Reply-To: <1587195383.54.0.536725993433.issue40301@roundup.psfhosted.org>
Message-ID: <CAKv20-Vf43PS74g2zRDMid9myCY-8KkZo_19Zs0bjx-nz_PA2Q@mail.gmail.com>


Massimo Sala <massimo.sala.71 at gmail.com> added the comment:

Hi Serhiy

Thanks for the suggestion but I don't need to analyse different
self-extraction payloads (and I think it is always unreliable, there are
too many self-extractors in the wild).

I spend two words about my work.

I analyze ZIP archives because they are the "incarnation" also of microsoft
OOXML and openoffice OASIS ODF documents.

I always find these kind of files with not zero offset aren't strictly
compliant documents (by their respective file formats specifications).
Sometimes there is a self-extrator, sometimes there are pieces of malware
blobs (outside the ZIP structure or inside it, into the compressed files),
sometimes other errors.

For us checking the offset is very effective: we discard "bad" documents at
maximum speed before any other checks and it is more reliable than
antivirus (checking against specific blobs signatures, everytime changing).
With just a single test we have a 100% go/nogo result. Every colleague
grasp this check, there aren't hard to read and maintain routines.

Massimo

On Sat, 18 Apr 2020 at 09:36, Serhiy Storchaka <report at bugs.python.org>
wrote:

>
> Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:
>
> I am not sure it would help you. There are legitimate files which contain
> a payload followed by the ZIP archive (self-extracting archives, programs
> with embedded ZIP archives). And the malware can make the offset of the ZIP
> archive be zero.
>
> If you want to check whether the file looks like an executable, analyze
> first few bytes of the file. All executable files should start by one of
> well recognized signatures, otherwise the OS would not know how to execute
> them and they would not be malware.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue40301>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40301>
_______________________________________

From report at bugs.python.org  Sat Apr 18 09:36:10 2020
From: report at bugs.python.org (Massimo Sala)
Date: Sat, 18 Apr 2020 13:36:10 +0000
Subject: [issue40301] zipfile module: new feature (two lines of code),
 useful for test, security and forensics
In-Reply-To: <1587173178.71.0.0798763891005.issue40301@roundup.psfhosted.org>
Message-ID: <CAKv20-UtDLBeBCtwvpFyoSDBAxd_-xNQHczLBqERc8RseZkMpw@mail.gmail.com>


Massimo Sala <massimo.sala.71 at gmail.com> added the comment:

Hi Daniel

Could you please elaborate the advantages of your loop versus my two lines
of code?
I don't grasp...

Thanks, Massimo

On Sat, 18 Apr 2020 at 03:26, Daniel Hillier <report at bugs.python.org> wrote:

>
> Daniel Hillier <daniel.hillier at gmail.com> added the comment:
>
> Could something similar be achieved by looking for the earliest file
> header offset?
>
> def find_earliest_header_offset(zf):
>     earliest_offset = None
>     for zinfo in zf.infolist():
>         if earliest_offset is None:
>             earliest_offset = zinfo.header_offset
>         else:
>             earliest_offset = min(zinfo.header_offset, earliest_offset)
>     return earliest_offset
>
>
> You could also adapt this using
>
>     zinfo.compress_size + len(zinfo.FileHeader())
>
> to see if there were any sections inside the archive which were not
> referenced from the central directory. Not sure if zip files with arbitrary
> bytes inside the archive would be valid everywhere, but I think they are
> using zipfile.
>
> You can also have zipped content inside an archive which has a valid
> fileheader but no reference from the central directory. Those entries are
> discoverable by implementations which process content serially from the
> start of the file but not implementations which rely on the central
> directory.
>
> ----------
> nosy: +dhillier
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue40301>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40301>
_______________________________________

From report at bugs.python.org  Sat Apr 18 09:45:40 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 18 Apr 2020 13:45:40 +0000
Subject: [issue40301] zipfile module: new feature (two lines of code),
 useful for test, security and forensics
In-Reply-To: <1587045567.04.0.739688211881.issue40301@roundup.psfhosted.org>
Message-ID: <1587217540.06.0.154857738049.issue40301@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Just check the first 4 bytes of the file. In "normal" ZIP archive they are b'PK\3\4' (or b'PK\5\6' if it is empty). It is so reliable as checking the offset, and more efficient. It is even more reliable, because a malware can have zero ZIP archive offset, but it cannot start with b'PK\3\4'.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40301>
_______________________________________

From report at bugs.python.org  Sat Apr 18 09:45:35 2020
From: report at bugs.python.org (Daniel Hillier)
Date: Sat, 18 Apr 2020 13:45:35 +0000
Subject: [issue40301] zipfile module: new feature (two lines of code),
 useful for test, security and forensics
In-Reply-To: <CAKv20-UtDLBeBCtwvpFyoSDBAxd_-xNQHczLBqERc8RseZkMpw@mail.gmail.com>
Message-ID: <CA+bP7jkDY=X1CmaJqv-C9D_6uCPe1p2WEji_ueS4SSLALsn2pw@mail.gmail.com>


Daniel Hillier <daniel.hillier at gmail.com> added the comment:

Hi Massimo,

Unless I'm missing something about your requirements, the advantage is that
it already works in python 2.7 so there is no need to patch Python. Just
bundle the above function with your analysis tool and you're good to go.

Cheers,
Dan

On Sat, Apr 18, 2020 at 11:36 PM Massimo Sala <report at bugs.python.org>
wrote:

>
> Massimo Sala <massimo.sala.71 at gmail.com> added the comment:
>
> Hi Daniel
>
> Could you please elaborate the advantages of your loop versus my two lines
> of code?
> I don't grasp...
>
> Thanks, Massimo
>
> On Sat, 18 Apr 2020 at 03:26, Daniel Hillier <report at bugs.python.org>
> wrote:
>
> >
> > Daniel Hillier <daniel.hillier at gmail.com> added the comment:
> >
> > Could something similar be achieved by looking for the earliest file
> > header offset?
> >
> > def find_earliest_header_offset(zf):
> >     earliest_offset = None
> >     for zinfo in zf.infolist():
> >         if earliest_offset is None:
> >             earliest_offset = zinfo.header_offset
> >         else:
> >             earliest_offset = min(zinfo.header_offset, earliest_offset)
> >     return earliest_offset
> >
> >
> > You could also adapt this using
> >
> >     zinfo.compress_size + len(zinfo.FileHeader())
> >
> > to see if there were any sections inside the archive which were not
> > referenced from the central directory. Not sure if zip files with
> arbitrary
> > bytes inside the archive would be valid everywhere, but I think they are
> > using zipfile.
> >
> > You can also have zipped content inside an archive which has a valid
> > fileheader but no reference from the central directory. Those entries are
> > discoverable by implementations which process content serially from the
> > start of the file but not implementations which rely on the central
> > directory.
> >
> > ----------
> > nosy: +dhillier
> >
> > _______________________________________
> > Python tracker <report at bugs.python.org>
> > <https://bugs.python.org/issue40301>
> > _______________________________________
> >
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue40301>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40301>
_______________________________________

From report at bugs.python.org  Sat Apr 18 10:13:25 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 18 Apr 2020 14:13:25 +0000
Subject: [issue40257] Improve the use of __doc__ in pydoc
In-Reply-To: <1586638478.83.0.463728061154.issue40257@roundup.psfhosted.org>
Message-ID: <1587219205.01.0.0748466735884.issue40257@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 7e64414f57b70dc5bc0ab19a3162a0735f9bfabf by Serhiy Storchaka in branch 'master':
bpo-40257: Improve help for the typing module (GH-19546)
https://github.com/python/cpython/commit/7e64414f57b70dc5bc0ab19a3162a0735f9bfabf


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40257>
_______________________________________

From report at bugs.python.org  Sat Apr 18 10:16:43 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 18 Apr 2020 14:16:43 +0000
Subject: [issue40257] Improve the use of __doc__ in pydoc
In-Reply-To: <1586638478.83.0.463728061154.issue40257@roundup.psfhosted.org>
Message-ID: <1587219403.61.0.843392686435.issue40257@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Some work is still needed for HTML output. But this code is so different from the code for plain text output and so complicated that I was afraid to break something. I'll rewrite it in separate issue.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40257>
_______________________________________

From report at bugs.python.org  Sat Apr 18 10:16:52 2020
From: report at bugs.python.org (Massimo Sala)
Date: Sat, 18 Apr 2020 14:16:52 +0000
Subject: [issue40301] zipfile module: new feature (two lines of code),
 useful for test, security and forensics
In-Reply-To: <1587217540.06.0.154857738049.issue40301@roundup.psfhosted.org>
Message-ID: <CAKv20-UK4qRDkxZZ=rAbcFbQx5XWv9wY1RRTXok_hu+2EZVtvg@mail.gmail.com>


Massimo Sala <massimo.sala.71 at gmail.com> added the comment:

Sorry I forgot to mention one specific case.
We have valid archives with a starting "blob": digitally signed zip files,
their filename extension is ".zip.p7m".

I agree your tip can be useful to other readers.
Best regards, Sala

On Sat, 18 Apr 2020 at 15:45, Serhiy Storchaka <report at bugs.python.org>
wrote:

>
> Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:
>
> Just check the first 4 bytes of the file. In "normal" ZIP archive they are
> b'PK\3\4' (or b'PK\5\6' if it is empty). It is so reliable as checking the
> offset, and more efficient. It is even more reliable, because a malware can
> have zero ZIP archive offset, but it cannot start with b'PK\3\4'.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue40301>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40301>
_______________________________________

From report at bugs.python.org  Sat Apr 18 10:20:57 2020
From: report at bugs.python.org (miss-islington)
Date: Sat, 18 Apr 2020 14:20:57 +0000
Subject: [issue35967] Better platform.processor support
In-Reply-To: <1549895363.53.0.252912531241.issue35967@roundup.psfhosted.org>
Message-ID: <1587219657.48.0.324889984929.issue35967@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset fb940408cea1fb34fed1418832f240f886dadf57 by Chih-Hsuan Yen in branch 'master':
bpo-35967: Skip test with `uname -p` on Android (GH-19577)
https://github.com/python/cpython/commit/fb940408cea1fb34fed1418832f240f886dadf57


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35967>
_______________________________________

From report at bugs.python.org  Sat Apr 18 10:30:24 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 18 Apr 2020 14:30:24 +0000
Subject: [issue40317] inspect.getsource() examines incorrect target
In-Reply-To: <1587210637.54.0.0432450975105.issue40317@roundup.psfhosted.org>
Message-ID: <1587220224.02.0.573502488439.issue40317@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

This will be resolved hopefully resolved using https://github.com/python/cpython/pull/10307 . Using my patch on the reproducer in the report.

./python bpo40317.py
123
    class Number:
        payload = 123

321
    class Number:
        payload = 321

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40317>
_______________________________________

From report at bugs.python.org  Sat Apr 18 10:35:44 2020
From: report at bugs.python.org (Massimo Sala)
Date: Sat, 18 Apr 2020 14:35:44 +0000
Subject: [issue40301] zipfile module: new feature (two lines of code),
 useful for test, security and forensics
In-Reply-To: <CA+bP7jkDY=X1CmaJqv-C9D_6uCPe1p2WEji_ueS4SSLALsn2pw@mail.gmail.com>
Message-ID: <CAKv20-Vjj2_YUw3--AgwbTxQJmt2859hRbczJxX8qGMLHGUQww@mail.gmail.com>


Massimo Sala <massimo.sala.71 at gmail.com> added the comment:

I choosed to use the internal variable *concat* because
- if I recollect correctly, it is calculated before successive routines;
- I didn't see your solution (!), there is a very nice computed variable in
front of my eyes.

Mmh
1) Reliability
Cannot be sure this always run with malformed files :
        for zinfo in zf.infolist():

We can try / except but we loose the computation.
If *concat* is already computed (unless completely damaged files), IMHO my
solution is better.

2) Performance
What are the performance for big files?
Are there file seeks due to traversing zf.infolist() ?

> Daniel wrote:
> the advantage is that it already works in python 2.7 so there is no need
to patch Python

Yes, indeed.

If I am right about the pros of my patch, I stand for it.

Many thanks for you attention.

On Sat, 18 Apr 2020 at 15:45, Daniel Hillier <report at bugs.python.org> wrote:

>
> Daniel Hillier <daniel.hillier at gmail.com> added the comment:
>
> Hi Massimo,
>
> Unless I'm missing something about your requirements, the advantage is that
> it already works in python 2.7 so there is no need to patch Python. Just
> bundle the above function with your analysis tool and you're good to go.
>
> Cheers,
> Dan
>
> On Sat, Apr 18, 2020 at 11:36 PM Massimo Sala <report at bugs.python.org>
> wrote:
>
> >
> > Massimo Sala <massimo.sala.71 at gmail.com> added the comment:
> >
> > Hi Daniel
> >
> > Could you please elaborate the advantages of your loop versus my two
> lines
> > of code?
> > I don't grasp...
> >
> > Thanks, Massimo
> >
> > On Sat, 18 Apr 2020 at 03:26, Daniel Hillier <report at bugs.python.org>
> > wrote:
> >
> > >
> > > Daniel Hillier <daniel.hillier at gmail.com> added the comment:
> > >
> > > Could something similar be achieved by looking for the earliest file
> > > header offset?
> > >
> > > def find_earliest_header_offset(zf):
> > >     earliest_offset = None
> > >     for zinfo in zf.infolist():
> > >         if earliest_offset is None:
> > >             earliest_offset = zinfo.header_offset
> > >         else:
> > >             earliest_offset = min(zinfo.header_offset, earliest_offset)
> > >     return earliest_offset
> > >
> > >
> > > You could also adapt this using
> > >
> > >     zinfo.compress_size + len(zinfo.FileHeader())
> > >
> > > to see if there were any sections inside the archive which were not
> > > referenced from the central directory. Not sure if zip files with
> > arbitrary
> > > bytes inside the archive would be valid everywhere, but I think they
> are
> > > using zipfile.
> > >
> > > You can also have zipped content inside an archive which has a valid
> > > fileheader but no reference from the central directory. Those entries
> are
> > > discoverable by implementations which process content serially from the
> > > start of the file but not implementations which rely on the central
> > > directory.
> > >
> > > ----------
> > > nosy: +dhillier
> > >
> > > _______________________________________
> > > Python tracker <report at bugs.python.org>
> > > <https://bugs.python.org/issue40301>
> > > _______________________________________
> > >
> >
> > ----------
> >
> > _______________________________________
> > Python tracker <report at bugs.python.org>
> > <https://bugs.python.org/issue40301>
> > _______________________________________
> >
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue40301>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40301>
_______________________________________

From report at bugs.python.org  Sat Apr 18 10:52:51 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 18 Apr 2020 14:52:51 +0000
Subject: [issue40179] Argument Clinic incorretly translates #elif
In-Reply-To: <1586017601.68.0.788293930127.issue40179@roundup.psfhosted.org>
Message-ID: <1587221571.77.0.768944951837.issue40179@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 12446e6a605f066d837d3a595d0a73e4f3b43b65 by Serhiy Storchaka in branch 'master':
bpo-40179: Fix translation of #elif in Argument Clinic (GH-19364)
https://github.com/python/cpython/commit/12446e6a605f066d837d3a595d0a73e4f3b43b65


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40179>
_______________________________________

From report at bugs.python.org  Sat Apr 18 10:58:19 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 18 Apr 2020 14:58:19 +0000
Subject: [issue40179] Argument Clinic incorretly translates #elif
In-Reply-To: <1586017601.68.0.788293930127.issue40179@roundup.psfhosted.org>
Message-ID: <1587221899.69.0.550393882728.issue40179@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +18920
pull_request: https://github.com/python/cpython/pull/19583

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40179>
_______________________________________

From report at bugs.python.org  Sat Apr 18 11:09:07 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 18 Apr 2020 15:09:07 +0000
Subject: [issue40179] Argument Clinic incorretly translates #elif
In-Reply-To: <1586017601.68.0.788293930127.issue40179@roundup.psfhosted.org>
Message-ID: <1587222547.02.0.0159289711024.issue40179@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +18921
pull_request: https://github.com/python/cpython/pull/19584

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40179>
_______________________________________

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: [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 12:11:52 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 18 Apr 2020 16:11:52 +0000
Subject: [issue40179] Argument Clinic incorretly translates #elif
In-Reply-To: <1586017601.68.0.788293930127.issue40179@roundup.psfhosted.org>
Message-ID: <1587226312.22.0.785306415101.issue40179@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset bfda4db0d2c05eef4e4ae90d899d0b67cb2e33e5 by Serhiy Storchaka in branch '3.8':
[3.8] bpo-40179: Fix translation of #elif in Argument Clinic (GH-19364) (GH-19583)
https://github.com/python/cpython/commit/bfda4db0d2c05eef4e4ae90d899d0b67cb2e33e5


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40179>
_______________________________________

From report at bugs.python.org  Sat Apr 18 12:12:18 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 18 Apr 2020 16:12:18 +0000
Subject: [issue40179] Argument Clinic incorretly translates #elif
In-Reply-To: <1586017601.68.0.788293930127.issue40179@roundup.psfhosted.org>
Message-ID: <1587226338.17.0.729298813774.issue40179@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 67ae454da749a7ca67115b43205d9fe98bea3213 by Serhiy Storchaka in branch '3.7':
[3.7] bpo-40179: Fix translation of #elif in Argument Clinic (GH-19364) (GH-19584)
https://github.com/python/cpython/commit/67ae454da749a7ca67115b43205d9fe98bea3213


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40179>
_______________________________________

From report at bugs.python.org  Sat Apr 18 12:13:03 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 18 Apr 2020 16:13:03 +0000
Subject: [issue40179] Argument Clinic incorretly translates #elif
In-Reply-To: <1586017601.68.0.788293930127.issue40179@roundup.psfhosted.org>
Message-ID: <1587226383.06.0.888238765026.issue40179@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40179>
_______________________________________

From report at bugs.python.org  Sat Apr 18 12:14:13 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 18 Apr 2020 16:14:13 +0000
Subject: [issue40178] Convert the remaining os funtions to Argument Clinic
In-Reply-To: <1586003108.43.0.643087706293.issue40178@roundup.psfhosted.org>
Message-ID: <1587226453.91.0.106825663981.issue40178@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 2b5603140c09766a7d4e8243a70d7144f684f6f9 by Serhiy Storchaka in branch 'master':
bpo-40178: Convert the remaining os functions to Argument Clinic. (GH-19360)
https://github.com/python/cpython/commit/2b5603140c09766a7d4e8243a70d7144f684f6f9


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40178>
_______________________________________

From report at bugs.python.org  Sat Apr 18 12:19:39 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 18 Apr 2020 16:19:39 +0000
Subject: [issue35113] inspect.getsource returns incorrect source for classes
 when class definition is part of multiline strings
In-Reply-To: <1540902777.26.0.788709270274.issue35113@psf.upfronthosting.co.za>
Message-ID: <1587226779.55.0.773102031744.issue35113@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:


New changeset 696136b993e11b37c4f34d729a0375e5ad544ade by Karthikeyan Singaravelan in branch 'master':
bpo-35113: Fix inspect.getsource to return correct source for inner classes (#10307)
https://github.com/python/cpython/commit/696136b993e11b37c4f34d729a0375e5ad544ade


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35113>
_______________________________________

From report at bugs.python.org  Sat Apr 18 12:19:39 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 18 Apr 2020 16:19:39 +0000
Subject: [issue15856] inspect.getsource(SomeClass) doesn't show @decorators
In-Reply-To: <1346685224.9.0.738134714561.issue15856@psf.upfronthosting.co.za>
Message-ID: <1587226779.47.0.610653698501.issue15856@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:


New changeset 696136b993e11b37c4f34d729a0375e5ad544ade by Karthikeyan Singaravelan in branch 'master':
bpo-35113: Fix inspect.getsource to return correct source for inner classes (#10307)
https://github.com/python/cpython/commit/696136b993e11b37c4f34d729a0375e5ad544ade


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue15856>
_______________________________________

From report at bugs.python.org  Sat Apr 18 12:34:05 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 18 Apr 2020 16:34:05 +0000
Subject: [issue40317] inspect.getsource() examines incorrect target
In-Reply-To: <1587210637.54.0.0432450975105.issue40317@roundup.psfhosted.org>
Message-ID: <1587227645.26.0.38122681165.issue40317@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Fixed in master now with https://github.com/python/cpython/commit/696136b993e11b37c4f34d729a0375e5ad544ade . This includes the change of show decorators for classes too to make it consistent with functions so it's not backported.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40317>
_______________________________________

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: [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:09:13 2020
From: report at bugs.python.org (miss-islington)
Date: Sat, 18 Apr 2020 18:09:13 +0000
Subject: [issue27635] pickle documentation says that unpickling may not call
 __new__
In-Reply-To: <1469639245.7.0.966654223743.issue27635@psf.upfronthosting.co.za>
Message-ID: <1587233353.66.0.666769954117.issue27635@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 482259d0dcf27714a84cf56b93977320bea7e093 by Furkan ?nder in branch 'master':
bpo-27635: Fix pickle documentation about `__new__` not being called. (GH-19269)
https://github.com/python/cpython/commit/482259d0dcf27714a84cf56b93977320bea7e093


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27635>
_______________________________________

From report at bugs.python.org  Sat Apr 18 14:09:24 2020
From: report at bugs.python.org (miss-islington)
Date: Sat, 18 Apr 2020 18:09:24 +0000
Subject: [issue27635] pickle documentation says that unpickling may not call
 __new__
In-Reply-To: <1469639245.7.0.966654223743.issue27635@psf.upfronthosting.co.za>
Message-ID: <1587233364.32.0.99715185051.issue27635@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +18922
pull_request: https://github.com/python/cpython/pull/19585

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27635>
_______________________________________

From report at bugs.python.org  Sat Apr 18 14:09:30 2020
From: report at bugs.python.org (miss-islington)
Date: Sat, 18 Apr 2020 18:09:30 +0000
Subject: [issue27635] pickle documentation says that unpickling may not call
 __new__
In-Reply-To: <1469639245.7.0.966654223743.issue27635@psf.upfronthosting.co.za>
Message-ID: <1587233370.61.0.240883651606.issue27635@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +18923
pull_request: https://github.com/python/cpython/pull/19586

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27635>
_______________________________________

From report at bugs.python.org  Sat Apr 18 14:14:44 2020
From: report at bugs.python.org (miss-islington)
Date: Sat, 18 Apr 2020 18:14:44 +0000
Subject: [issue27635] pickle documentation says that unpickling may not call
 __new__
In-Reply-To: <1469639245.7.0.966654223743.issue27635@psf.upfronthosting.co.za>
Message-ID: <1587233684.67.0.413342740177.issue27635@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 0abb548cc7b239fbe426ca9e00968130e53ffc98 by Miss Islington (bot) in branch '3.7':
bpo-27635: Fix pickle documentation about `__new__` not being called. (GH-19269)
https://github.com/python/cpython/commit/0abb548cc7b239fbe426ca9e00968130e53ffc98


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27635>
_______________________________________

From report at bugs.python.org  Sat Apr 18 14:14:58 2020
From: report at bugs.python.org (miss-islington)
Date: Sat, 18 Apr 2020 18:14:58 +0000
Subject: [issue27635] pickle documentation says that unpickling may not call
 __new__
In-Reply-To: <1469639245.7.0.966654223743.issue27635@psf.upfronthosting.co.za>
Message-ID: <1587233698.83.0.00875402137454.issue27635@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 020f2aaaea95aef6f54ab31488926ed76017e41a by Miss Islington (bot) in branch '3.8':
bpo-27635: Fix pickle documentation about `__new__` not being called. (GH-19269)
https://github.com/python/cpython/commit/020f2aaaea95aef6f54ab31488926ed76017e41a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27635>
_______________________________________

From report at bugs.python.org  Sat Apr 18 14:18:45 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 18 Apr 2020 18:18:45 +0000
Subject: [issue35113] inspect.getsource returns incorrect source for classes
 when class definition is part of multiline strings
In-Reply-To: <1540902777.26.0.788709270274.issue35113@psf.upfronthosting.co.za>
Message-ID: <1587233925.65.0.987484057575.issue35113@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +18924
pull_request: https://github.com/python/cpython/pull/19587

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35113>
_______________________________________

From report at bugs.python.org  Sat Apr 18 14:27:07 2020
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 18 Apr 2020 18:27:07 +0000
Subject: [issue40321] urllib.request does not support HTTP response status
 code 308
In-Reply-To: <1587232058.85.0.573866772263.issue40321@roundup.psfhosted.org>
Message-ID: <1587234427.17.0.810427081247.issue40321@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch
nosy: +python-dev
nosy_count: 1.0 -> 2.0
pull_requests: +18925
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19588

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40321>
_______________________________________

From report at bugs.python.org  Sat Apr 18 14:35:11 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 18 Apr 2020 18:35:11 +0000
Subject: [issue40269] Inconsistent complex behavior with (-1j)
In-Reply-To: <1586736208.71.0.129112794549.issue40269@roundup.psfhosted.org>
Message-ID: <1587234911.69.0.874256498539.issue40269@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Since integers don't have signed zeros, the use of integers in the complex repr is a little weird:

>>> (-0-1j)         # The unary minus in the repr has no effect.
-1j
>>> (0-1j)
-1j

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40269>
_______________________________________

From report at bugs.python.org  Sat Apr 18 14:39:27 2020
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 18 Apr 2020 18:39:27 +0000
Subject: [issue38891] ShareableList read and write access is O(N),
 should be O(1)
In-Reply-To: <1574389874.92.0.425732905902.issue38891@roundup.psfhosted.org>
Message-ID: <1587235167.54.0.979715656052.issue38891@roundup.psfhosted.org>


Change by Antoine Pitrou <solipsis at pitrou.net>:


----------
versions: +Python 3.9 -Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38891>
_______________________________________

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: [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 14:58:11 2020
From: report at bugs.python.org (Zackery Spytz)
Date: Sat, 18 Apr 2020 18:58:11 +0000
Subject: [issue23414] seek(count, whence) accepts bogus whence on windows,
 python2.7
In-Reply-To: <1423431538.2.0.390923477638.issue23414@psf.upfronthosting.co.za>
Message-ID: <1587236291.35.0.880117251388.issue23414@roundup.psfhosted.org>


Zackery Spytz <zspytz at gmail.com> added the comment:

Python 2 is EOL.

----------
nosy: +ZackerySpytz

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23414>
_______________________________________

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: [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:43:06 2020
From: report at bugs.python.org (Robert Bressan)
Date: Sat, 18 Apr 2020 19:43:06 +0000
Subject: [issue40322] struct.pack adding unexpected byte in 'B' format
In-Reply-To: <1587235779.35.0.377995541073.issue40322@roundup.psfhosted.org>
Message-ID: <1587238986.55.0.669977953449.issue40322@roundup.psfhosted.org>


Robert Bressan <robert.bressan at gmail.com> added the comment:

After placing a standard size instead of a native one, solved.

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40322>
_______________________________________

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: [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 16:39:05 2020
From: report at bugs.python.org (Ned Deily)
Date: Sat, 18 Apr 2020 20:39:05 +0000
Subject: [issue23414] seek(count, whence) accepts bogus whence on windows,
 python2.7
In-Reply-To: <1423431538.2.0.390923477638.issue23414@psf.upfronthosting.co.za>
Message-ID: <1587242345.91.0.15848891014.issue23414@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


----------
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23414>
_______________________________________

From report at bugs.python.org  Sat Apr 18 16:40:00 2020
From: report at bugs.python.org (Ned Deily)
Date: Sat, 18 Apr 2020 20:40:00 +0000
Subject: [issue40321] urllib.request does not support HTTP response status
 code 308
In-Reply-To: <1587232058.85.0.573866772263.issue40321@roundup.psfhosted.org>
Message-ID: <1587242400.05.0.0756848013626.issue40321@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40321>
_______________________________________

From report at bugs.python.org  Sat Apr 18 16:50:36 2020
From: report at bugs.python.org (SilentGhost)
Date: Sat, 18 Apr 2020 20:50:36 +0000
Subject: [issue40323] Printing of Single (') and Double (") code in one
 sentence using escape Code
In-Reply-To: <1587237663.06.0.425937353103.issue40323@roundup.psfhosted.org>
Message-ID: <1587243036.67.0.199269519891.issue40323@roundup.psfhosted.org>


SilentGhost <ghost.adh at runbox.com> added the comment:

The output in REPL is valid representation of an object that can be often be used to re-create the object, you could use print function to see how the string would look like when output on screen or written into a file.

----------
nosy: +SilentGhost
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40323>
_______________________________________

From report at bugs.python.org  Sat Apr 18 16:55:34 2020
From: report at bugs.python.org (Ned Deily)
Date: Sat, 18 Apr 2020 20:55:34 +0000
Subject: [issue40247] Logged out of user when running Tkinter
In-Reply-To: <1586551795.67.0.408476098567.issue40247@roundup.psfhosted.org>
Message-ID: <1587243334.52.0.0151806345399.issue40247@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

Thanks for the additional info but it still leaves open questions.  The current versions of python.org installers for macOS (3.8.2 and 3.7.7) and various others over the past couple of years all come with a built-in version of Tk 8.6 and that normally cannot be overriden. So if you are seeing indications that Tk 8.5.x is in use, you are somehow not really using those current versions of python.org installers or you are calling out within them directly to an older version of Tk (via a subprocess call, for example).  The Apple-provided Tk 8.5.x on macOS systems is woefully out-of-date and has known critical bugs, like crashing when typing in composite characters (like option-u then U to produce ? on an English keyboard).  Anyway, since you have solved the issue for you, I am going to close this issue.

----------
resolution:  -> works for me
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40247>
_______________________________________

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: [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  Sat Apr 18 17:48:09 2020
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Sat, 18 Apr 2020 21:48:09 +0000
Subject: [issue40325] Random.seed does not affect string hash randomization
 leading to non-intuitive results
In-Reply-To: <1587245119.63.0.0763742728572.issue40325@roundup.psfhosted.org>
Message-ID: <1587246489.15.0.7753552572.issue40325@roundup.psfhosted.org>


R?mi Lapeyre <remi.lapeyre at henki.fr> added the comment:

String hash randomization is a security feature so it may be better to not disable it unless explicitly asked for. Maybe a note in random's documentation could be added?

----------
nosy: +remi.lapeyre

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40325>
_______________________________________

From report at bugs.python.org  Sat Apr 18 19:13:37 2020
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 18 Apr 2020 23:13:37 +0000
Subject: [issue40311] docs.python.org banner - release blocker for 2.7.18
In-Reply-To: <1587139977.42.0.984358391759.issue40311@roundup.psfhosted.org>
Message-ID: <1587251617.36.0.847509676739.issue40311@roundup.psfhosted.org>


Benjamin Peterson <benjamin at python.org> added the comment:

0fc82e95878234291f23155a64408fced71892b2

----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40311>
_______________________________________

From report at bugs.python.org  Sat Apr 18 19:23:23 2020
From: report at bugs.python.org (Neil Schemenauer)
Date: Sat, 18 Apr 2020 23:23:23 +0000
Subject: [issue40255] Fixing Copy on Writes from reference counting
In-Reply-To: <1586619621.82.0.553262088399.issue40255@roundup.psfhosted.org>
Message-ID: <1587252203.82.0.0316472413816.issue40255@roundup.psfhosted.org>


Neil Schemenauer <nas-python at arctrix.com> added the comment:

I resurrected an old thread on Discourse that seems quite relevant to this PR:

https://discuss.python.org/t/switching-from-refcounting-to-libgc/1641/35?u=nas

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40255>
_______________________________________

From report at bugs.python.org  Sat Apr 18 20:38:04 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 19 Apr 2020 00:38:04 +0000
Subject: [issue40324] python 3.8.2 idle not opening
In-Reply-To: <1587239062.2.0.770603015348.issue40324@roundup.psfhosted.org>
Message-ID: <1587256684.42.0.949853024803.issue40324@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Please answer the questions in msg365164 of #40083.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40324>
_______________________________________

From report at bugs.python.org  Sat Apr 18 20:58:14 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 19 Apr 2020 00:58:14 +0000
Subject: [issue40325] Random.seed does not affect string hash randomization
 leading to non-intuitive results
In-Reply-To: <1587245119.63.0.0763742728572.issue40325@roundup.psfhosted.org>
Message-ID: <1587257894.86.0.935060223583.issue40325@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I'm going to deprecate the support for sets.  It was a design mistake at several levels.  Better to just remove it.

----------
assignee: docs at python -> rhettinger
nosy: +rhettinger
type:  -> behavior
versions: +Python 3.9 -Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40325>
_______________________________________

From report at bugs.python.org  Sat Apr 18 21:05:11 2020
From: report at bugs.python.org (Tim Peters)
Date: Sun, 19 Apr 2020 01:05:11 +0000
Subject: [issue40325] Random.seed does not affect string hash randomization
 leading to non-intuitive results
In-Reply-To: <1587245119.63.0.0763742728572.issue40325@roundup.psfhosted.org>
Message-ID: <1587258311.84.0.686356734383.issue40325@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

Raymond, I think that removing sample(set) support is a different issue.  This report will just change its final example line to

>>> print(random.sample(list(x), 1))

or

>>> print(random.sample(tuple(x), 1))

and have the same complaint.

----------
nosy: +tim.peters

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40325>
_______________________________________

From report at bugs.python.org  Sat Apr 18 22:12:31 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 19 Apr 2020 02:12:31 +0000
Subject: [issue40325] Random.seed does not affect string hash randomization
 leading to non-intuitive results
In-Reply-To: <1587245119.63.0.0763742728572.issue40325@roundup.psfhosted.org>
Message-ID: <1587262351.28.0.61532070644.issue40325@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I think the thing we can fix is the automatic set support which is intrinsically broken with respect to reproducibility and which was likely not a good idea to begin with (because it adds an implicit and possibly unexpected O(n) conversion step and because it doesn't make the API for choice()).

If someone converts a set to a list or tuple upstream from sample(), there isn't much we can do about it.   That wouldn't be much different from list(s)[0] giving different output from run to run.  That is a general FAQ and would apply to just about anything that takes a sequence or iterator to run.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40325>
_______________________________________

From report at bugs.python.org  Sat Apr 18 22:30:02 2020
From: report at bugs.python.org (Tim Peters)
Date: Sun, 19 Apr 2020 02:30:02 +0000
Subject: [issue40325] Random.seed does not affect string hash randomization
 leading to non-intuitive results
In-Reply-To: <1587245119.63.0.0763742728572.issue40325@roundup.psfhosted.org>
Message-ID: <1587263402.75.0.274155410075.issue40325@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

Yup, I agree sample(set) is a misfeature.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40325>
_______________________________________

From report at bugs.python.org  Sat Apr 18 22:31:43 2020
From: report at bugs.python.org (Tim Peters)
Date: Sun, 19 Apr 2020 02:31:43 +0000
Subject: [issue40312] Weakref callbacks running before finalizers in GC
 collection
In-Reply-To: <1587153160.93.0.26793085181.issue40312@roundup.psfhosted.org>
Message-ID: <1587263503.67.0.180687501389.issue40312@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

Offhand I'm surprised because of this:  if a weakref W refers to object O, and W and O are _both_ in cyclic trash, gc does not want to invoke W's callback (if any).  In fact, it works hard not to call it.  So I'm surprised that the callback is invoked at all, not by whether it's called before or after __del__ is called.

----------
nosy: +tim.peters

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40312>
_______________________________________

From report at bugs.python.org  Sat Apr 18 22:51:13 2020
From: report at bugs.python.org (Allan Feldman)
Date: Sun, 19 Apr 2020 02:51:13 +0000
Subject: [issue40312] Weakref callbacks running before finalizers in GC
 collection
In-Reply-To: <1587153160.93.0.26793085181.issue40312@roundup.psfhosted.org>
Message-ID: <1587264673.44.0.845842380343.issue40312@roundup.psfhosted.org>


Allan Feldman <allan.d.feldman at gmail.com> added the comment:

Thanks for the response!

> if a weakref W refers to object O, and W and O are _both_ in cyclic trash

I believe that in the examples W is not in cyclic trash, but remains referenced as a global in the frame. Only O is in cyclic trash (O references itself).

I would expect that W's callback would be invoked in this case, but only after O is guaranteed to be deleted. In some cases O can be resurrected in the finalizer.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40312>
_______________________________________

From report at bugs.python.org  Sat Apr 18 22:53:02 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 19 Apr 2020 02:53:02 +0000
Subject: [issue40325] Random.seed does not affect string hash randomization
 leading to non-intuitive results
In-Reply-To: <1587245119.63.0.0763742728572.issue40325@roundup.psfhosted.org>
Message-ID: <1587264782.92.0.010129518664.issue40325@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
keywords: +patch
pull_requests: +18926
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19591

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40325>
_______________________________________

From report at bugs.python.org  Sat Apr 18 23:14:10 2020
From: report at bugs.python.org (Carl Lewin)
Date: Sun, 19 Apr 2020 03:14:10 +0000
Subject: [issue40078] asyncio subprocesses allow pids to be reaped,
 different behavior than regular subprocesses
In-Reply-To: <1585242393.56.0.193315651182.issue40078@roundup.psfhosted.org>
Message-ID: <1587266050.18.0.575125030398.issue40078@roundup.psfhosted.org>


Carl Lewin <carl.maxwell.lewin at gmail.com> added the comment:

Very first time engaging in such a forum. Apologies is advance if I am doing it wrong!

Observation: ps -ef shows "Defunct" process until calling script terminates

Scenario: equivalent test scripts in BASH, Python 2.7 and 3.6 that:
1. Start a ping
2. SIGTERM (kill -15) the associated PID 
3. wait for a user input (hence stopping the script terminating)

I tried P.Open and threading but behaviour is same.

BASH script does not show any "defunct" process.

Is this "Child Reaping" the cause of this observed behaviour?

Problem comes when the Parent script is required to run constantly (server type scenario) as the "defunct" processes will presumably eventually consume all system resources?

----------
nosy: +c-lewin

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40078>
_______________________________________

From report at bugs.python.org  Sat Apr 18 23:26:52 2020
From: report at bugs.python.org (Dennis Sweeney)
Date: Sun, 19 Apr 2020 03:26:52 +0000
Subject: [issue40308] Intermittent failure of
 test_os.TestScandir.test_attributes on Windows
In-Reply-To: <1587073240.99.0.668032471383.issue40308@roundup.psfhosted.org>
Message-ID: <1587266812.34.0.373014267203.issue40308@roundup.psfhosted.org>


Change by Dennis Sweeney <sweeney.dennis650 at gmail.com>:


----------
resolution:  -> works for me
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40308>
_______________________________________

From report at bugs.python.org  Sat Apr 18 23:34:07 2020
From: report at bugs.python.org (Tim Peters)
Date: Sun, 19 Apr 2020 03:34:07 +0000
Subject: [issue40312] Weakref callbacks running before finalizers in GC
 collection
In-Reply-To: <1587153160.93.0.26793085181.issue40312@roundup.psfhosted.org>
Message-ID: <1587267247.78.0.365115977772.issue40312@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

Ah, I missed that `cache` is global.  So it will hold reachable strong refs to the weakrefs stored for the dict's values.  So gc will run the callbacks associated with weakrefs' trash referents.

I think you're out of luck.  Nothing is defined about the order in which the stuff in cyclic trash is destroyed.  gc has no knowledge of your intended semantics, and no way to be taught.  You happened to create code that assumed (albeit indirectly & subtly) a finalizer would run before a relevant callback, but someone else could create code assuming the reverse.

It so happens that gc forces all callbacks to run before it forces any finalizers to run, and I'm loathe to change that code - weakref callbacks in particular have been an historical segfault factory, so nobody will touch that code without extraordinarily strong reason to risk it.  But I'll add Pablo here just in case he's feeling adventurous ;-)

In any case, I'd say it's always _best_ practice to never delete a key from any kind of weak dict except under protection of a try/except block.  The point of a weak dict is that entries can vanish "by magic".  And in this particular case, by deeper magic than was anticipated ;-)

----------
nosy: +pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40312>
_______________________________________

From report at bugs.python.org  Sun Apr 19 00:38:57 2020
From: report at bugs.python.org (Allan Feldman)
Date: Sun, 19 Apr 2020 04:38:57 +0000
Subject: [issue40312] Weakref callbacks running before finalizers in GC
 collection
In-Reply-To: <1587153160.93.0.26793085181.issue40312@roundup.psfhosted.org>
Message-ID: <1587271137.51.0.234320975534.issue40312@roundup.psfhosted.org>


Allan Feldman <allan.d.feldman at gmail.com> added the comment:

Reading more carefully, I may have jumped to conclusions here :)

Looking at the weakref docs, I see the following description of the callback functionality:

> If callback is provided and not None, and the returned weakref object is still alive, the callback will be called when the object is about to be finalized; the weak reference object will be passed as the only parameter to the callback; the referent will no longer be available.

This description seems to imply that even if an object is resurrected, the callback will be run.

Using the `ForeverObject` example above, I see the weakref callback behavior is different when going through gc versus going through `_Py_Dealloc`.

The behavior being different seems to imply that a contract is broken somewhere.

In this case I think I assumed it was gc, but it looks like it might actually be that the contract (as currently defined) is broken by dealloc. Finalizers are always called before weakref callbacks on the reference counted path:
https://github.com/python/cpython/blob/482259d0dcf27714a84cf56b93977320bea7e093/Objects/typeobject.c#L1245

Here is the output from the `ForeverObject` example above:

------- Circular reference: True -------
callback running <weakref at 0x10fedea10; dead>
--------------
------- Circular reference: False -------
--------------

For my own understanding, why is the API documented as running the callback prior to finalizers running? The referent is unavailable when the callback runs, so isn't it safe to run the weakref callbacks consistently after the finalizers?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40312>
_______________________________________

From report at bugs.python.org  Sun Apr 19 01:39:01 2020
From: report at bugs.python.org (=?utf-8?q?Benedek_R=C3=A1cz?=)
Date: Sun, 19 Apr 2020 05:39:01 +0000
Subject: [issue38905] venv python reports wrong sys.executable in a subprocess
 on Windows
In-Reply-To: <1574583460.3.0.94905817038.issue38905@roundup.psfhosted.org>
Message-ID: <1587274741.35.0.938702276467.issue38905@roundup.psfhosted.org>


Benedek R?cz <betontalpfa at gmail.com> added the comment:

Is there any update/solution for this issue? This issue is the root cause of this SO post: https://stackoverflow.com/q/61290972/2506522

----------
nosy: +Benedek R?cz

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38905>
_______________________________________

From report at bugs.python.org  Sun Apr 19 02:20:53 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Sun, 19 Apr 2020 06:20:53 +0000
Subject: [issue40244] AIX: build: _PyObject_GC_TRACK Asstertion failure
In-Reply-To: <1586507316.69.0.786578254213.issue40244@roundup.psfhosted.org>
Message-ID: <1587277253.97.0.170354741842.issue40244@roundup.psfhosted.org>


Batuhan Taskaya <batuhanosmantaskaya at gmail.com> added the comment:

Moving assertion from _PyObject_GC_TRACK to gen_dealloc (just before the _PyObject_GC_TRACK call) results with success (????)

     if (gen->gi_weakreflist != NULL)
         PyObject_ClearWeakRefs(self);
-
+    _PyObject_ASSERT_FROM(self, !_PyObject_GC_IS_TRACKED(self),
+                          "object already tracked by they garbage collector",
+                          __FILE__, __LINE__, "_PyObject_GC_TRACK");
     _PyObject_GC_TRACK(self);
 
     if (PyObject_CallFinalizerFromDealloc(self))

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40244>
_______________________________________

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: [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 03:24:06 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 19 Apr 2020 07:24:06 +0000
Subject: [issue40326] A string contains an empty string?
In-Reply-To: <1587280457.85.0.869206136308.issue40326@roundup.psfhosted.org>
Message-ID: <1587281046.35.0.0677095721361.issue40326@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Yes, it is.

----------
nosy: +serhiy.storchaka
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40326>
_______________________________________

From report at bugs.python.org  Sun Apr 19 03:36:51 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 19 Apr 2020 07:36:51 +0000
Subject: [issue40325] Random.seed does not affect string hash randomization
 leading to non-intuitive results
In-Reply-To: <1587245119.63.0.0763742728572.issue40325@roundup.psfhosted.org>
Message-ID: <1587281811.17.0.0646719196814.issue40325@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:


New changeset 4fe002045fcf40823154b709fef0948b2bc5e934 by Raymond Hettinger in branch 'master':
bpo-40325: Deprecate set object support in random.sample() (GH-19591)
https://github.com/python/cpython/commit/4fe002045fcf40823154b709fef0948b2bc5e934


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40325>
_______________________________________

From report at bugs.python.org  Sun Apr 19 03:37:40 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 19 Apr 2020 07:37:40 +0000
Subject: [issue40325] Random.seed does not affect string hash randomization
 leading to non-intuitive results
In-Reply-To: <1587245119.63.0.0763742728572.issue40325@roundup.psfhosted.org>
Message-ID: <1587281860.31.0.200899796645.issue40325@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Yuval, thanks for the report.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40325>
_______________________________________

From report at bugs.python.org  Sun Apr 19 03:37:59 2020
From: report at bugs.python.org (Dennis Sweeney)
Date: Sun, 19 Apr 2020 07:37:59 +0000
Subject: [issue40313] bytes.hex(sep,
 bytes_per_sep) is many times slower than manually inserting the
 separators
In-Reply-To: <1587157109.99.0.0253750787201.issue40313@roundup.psfhosted.org>
Message-ID: <1587281879.89.0.903921208218.issue40313@roundup.psfhosted.org>


Dennis Sweeney <sweeney.dennis650 at gmail.com> added the comment:

I replicated this behavior. This looks like the relevant loop in pystrhex.c:

    for (i=j=0; i < arglen; ++i) {
        assert((j + 1) < resultlen);
        unsigned char c;
        c = (argbuf[i] >> 4) & 0x0f;
        retbuf[j++] = Py_hexdigits[c];
        c = argbuf[i] & 0x0f;
        retbuf[j++] = Py_hexdigits[c];
        if (bytes_per_sep_group && i < arglen - 1) {
            Py_ssize_t anchor;
            anchor = (bytes_per_sep_group > 0) ? (arglen - 1 - i) : (i + 1);
            if (anchor % abs_bytes_per_sep == 0) {
                retbuf[j++] = sep_char;
            }
        }
    }

It looks like this can be refactored a bit for a tighter inner loop with fewer if-tests. I can work on a PR.

----------
nosy: +Dennis Sweeney
versions: +Python 3.9 -Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40313>
_______________________________________

From report at bugs.python.org  Sun Apr 19 04:16:47 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 19 Apr 2020 08:16:47 +0000
Subject: [issue22548] Bogus parsing of negative zeros in complex literals
In-Reply-To: <1412357054.52.0.79002389879.issue22548@psf.upfronthosting.co.za>
Message-ID: <1587284207.02.0.865862820469.issue22548@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
nosy: +serhiy.storchaka
nosy_count: 3.0 -> 4.0
pull_requests: +18927
pull_request: https://github.com/python/cpython/pull/19593

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22548>
_______________________________________

From report at bugs.python.org  Sun Apr 19 04:18:40 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 19 Apr 2020 08:18:40 +0000
Subject: [issue40269] Inconsistent complex behavior with (-1j)
In-Reply-To: <1586736208.71.0.129112794549.issue40269@roundup.psfhosted.org>
Message-ID: <1587284320.64.0.416225793563.issue40269@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +18928
pull_request: https://github.com/python/cpython/pull/19593

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40269>
_______________________________________

From report at bugs.python.org  Sun Apr 19 04:21:49 2020
From: report at bugs.python.org (hai shi)
Date: Sun, 19 Apr 2020 08:21:49 +0000
Subject: [issue40275] test.support has way too many imports
In-Reply-To: <1586816691.28.0.874442798421.issue40275@roundup.psfhosted.org>
Message-ID: <1587284509.1.0.193538523832.issue40275@roundup.psfhosted.org>


Change by hai shi <shihai1991 at 126.com>:


----------
keywords: +patch
nosy: +shihai1991
nosy_count: 1.0 -> 2.0
pull_requests: +18929
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19592

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40275>
_______________________________________

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: [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 04:25:51 2020
From: report at bugs.python.org (Yuval S)
Date: Sun, 19 Apr 2020 08:25:51 +0000
Subject: [issue40325] Random.seed does not affect string hash randomization
 leading to non-intuitive results
In-Reply-To: <1587245119.63.0.0763742728572.issue40325@roundup.psfhosted.org>
Message-ID: <1587284751.52.0.616397471163.issue40325@roundup.psfhosted.org>


Yuval S <sadan.yuval at gmail.com> added the comment:

Thank you for the attention and the quick fix. However, the current documentation for "Notes on Reproducibility" should still address this issue of hash randomization. Not only `sample` is affected by this, but any code that combines strings (or bytes or datetime) with hash and random, e.g.

>>> import random
>>> random.seed(6)
>>> a = list(set(str(i) for i in range(500)))
>>> print(a[int(random.random() * 500)])

or, this

>>> import random
>>> import datetime
>>> random.seed(6)
>>> print(random.choice(range(hash(datetime.datetime(2000,1,1)) % 100)))

will still produce non-reproducible results even after the fix. Here is my suggestion for documentation:

> Hash randomization, which is enabled by default since version 3.3, is not affected by `random.seed()`. For this reason, code that relies on string hashes, such as code that relies on the ordering of `set` or `dict`, might be non-reproducible, unless string hash randomization is disabled or seeded (see: https://docs.python.org/3/using/cmdline.html#envvar-PYTHONHASHSEED).

My vote would be to keep hash randomization ties to `random.seed()`, and this would make all use cases more predictable, as well as allow `random.sample()` to support `set`.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40325>
_______________________________________

From report at bugs.python.org  Sun Apr 19 04:26:52 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 19 Apr 2020 08:26:52 +0000
Subject: [issue40269] Inconsistent complex behavior with (-1j)
In-Reply-To: <1586736208.71.0.129112794549.issue40269@roundup.psfhosted.org>
Message-ID: <1587284812.29.0.657528967365.issue40269@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I tried to make repr of floats producing a string which rounds up with eval() (see PR 19593).

>>> complex(0.0, 1.0)
1j
>>> complex(0.0, -1.0)
(0-1j)
>>> complex(-0.0, 1.0)
-(0-1j)
>>> complex(-0.0, -1.0)
(-0.0-1j)
>>> complex(1.0, 0.0)
(1+0j)
>>> complex(-1.0, 0.0)
(-1+0j)
>>> complex(1.0, -0.0)
-(-1+0j)
>>> complex(-1.0, -0.0)
-(1+0j)

The largest problem is with complex(-0.0, 0.0) and complex(-0.0, 0.0). The only forms which evaluate to these numbers are:

>>> complex(-0.0, 0.0)
(-0.0-0j)
>>> complex(0.0, -0.0)
-(-0.0-0j)

But it conflicts with the constructor:

>>> complex('(-0.0-0j)')
-(0+0j)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40269>
_______________________________________

From report at bugs.python.org  Sun Apr 19 04:30:31 2020
From: report at bugs.python.org (hai shi)
Date: Sun, 19 Apr 2020 08:30:31 +0000
Subject: [issue40275] test.support has way too many imports
In-Reply-To: <1586816691.28.0.874442798421.issue40275@roundup.psfhosted.org>
Message-ID: <1587285031.3.0.781984013158.issue40275@roundup.psfhosted.org>


hai shi <shihai1991 at 126.com> added the comment:

> "import test.support" imports not less than 171... That's quite "heavy".

If we split some "heavy" modules to xxxutils, what benefits  will we make in fact(more exact module importing behavior)?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40275>
_______________________________________

From report at bugs.python.org  Sun Apr 19 04:31:05 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 19 Apr 2020 08:31:05 +0000
Subject: [issue22548] Bogus parsing of negative zeros in complex literals
In-Reply-To: <1412357054.52.0.79002389879.issue22548@psf.upfronthosting.co.za>
Message-ID: <1587285065.26.0.534523289421.issue22548@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests:  -18927

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22548>
_______________________________________

From report at bugs.python.org  Sun Apr 19 04:40:07 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 19 Apr 2020 08:40:07 +0000
Subject: [issue40275] test.support has way too many imports
In-Reply-To: <1586816691.28.0.874442798421.issue40275@roundup.psfhosted.org>
Message-ID: <1587285607.72.0.0939802358614.issue40275@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

+1 for splitting test.support on several submodules!

Some imports can also be lazy.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40275>
_______________________________________

From report at bugs.python.org  Sun Apr 19 04:57:17 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 19 Apr 2020 08:57:17 +0000
Subject: [issue40275] test.support has way too many imports
In-Reply-To: <1586816691.28.0.874442798421.issue40275@roundup.psfhosted.org>
Message-ID: <1587286637.96.0.402489483113.issue40275@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

asyncio is now imported in unittest. Removing direct import from test.support does not help.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40275>
_______________________________________

From report at bugs.python.org  Sun Apr 19 05:02:48 2020
From: report at bugs.python.org (hai shi)
Date: Sun, 19 Apr 2020 09:02:48 +0000
Subject: [issue40284] Add mapping methods to types.SimpleNamespace
In-Reply-To: <1586898649.19.0.221456344176.issue40284@roundup.psfhosted.org>
Message-ID: <1587286967.99.0.169533667213.issue40284@roundup.psfhosted.org>


Change by hai shi <shihai1991 at 126.com>:


----------
nosy: +shihai1991

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40284>
_______________________________________

From report at bugs.python.org  Sun Apr 19 05:05:30 2020
From: report at bugs.python.org (Dennis Sweeney)
Date: Sun, 19 Apr 2020 09:05:30 +0000
Subject: [issue40313] bytes.hex(sep,
 bytes_per_sep) is many times slower than manually inserting the
 separators
In-Reply-To: <1587157109.99.0.0253750787201.issue40313@roundup.psfhosted.org>
Message-ID: <1587287130.81.0.860944903577.issue40313@roundup.psfhosted.org>


Change by Dennis Sweeney <sweeney.dennis650 at gmail.com>:


----------
keywords: +patch
pull_requests: +18930
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19594

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40313>
_______________________________________

From report at bugs.python.org  Sun Apr 19 05:10:07 2020
From: report at bugs.python.org (Barry Alan Scott)
Date: Sun, 19 Apr 2020 09:10:07 +0000
Subject: [issue40260] modulefinder traceback regression starting on Windows
In-Reply-To: <1586680620.99.0.514402715757.issue40260@roundup.psfhosted.org>
Message-ID: <1587287407.97.0.252883719405.issue40260@roundup.psfhosted.org>


Change by Barry Alan Scott <barry-scott at users.sourceforge.net>:


----------
pull_requests: +18931
pull_request: https://github.com/python/cpython/pull/19595

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40260>
_______________________________________

From report at bugs.python.org  Sun Apr 19 05:12:36 2020
From: report at bugs.python.org (hai shi)
Date: Sun, 19 Apr 2020 09:12:36 +0000
Subject: [issue40275] test.support has way too many imports
In-Reply-To: <1586816691.28.0.874442798421.issue40275@roundup.psfhosted.org>
Message-ID: <1587287556.62.0.596700818883.issue40275@roundup.psfhosted.org>


hai shi <shihai1991 at 126.com> added the comment:

> asyncio is now imported in unittest. Removing direct import from test.support does not help.

Oh, thanks, you are right. Looks like we need check which submodules should be splitted.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40275>
_______________________________________

From report at bugs.python.org  Sun Apr 19 05:17:52 2020
From: report at bugs.python.org (Barry Alan Scott)
Date: Sun, 19 Apr 2020 09:17:52 +0000
Subject: [issue40260] modulefinder traceback regression starting on Windows
In-Reply-To: <1586680620.99.0.514402715757.issue40260@roundup.psfhosted.org>
Message-ID: <1587287872.74.0.371698775368.issue40260@roundup.psfhosted.org>


Barry Alan Scott <barry-scott at users.sourceforge.net> added the comment:

I have pushed the fix onto https://github.com/python/cpython/pull/19595
with an API test case and the changes to keep the debain subclassing
working.

I'm new the the work flow. Let me know if I need to change anything.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40260>
_______________________________________

From report at bugs.python.org  Sun Apr 19 05:25:45 2020
From: report at bugs.python.org (Dennis Sweeney)
Date: Sun, 19 Apr 2020 09:25:45 +0000
Subject: [issue40313] bytes.hex(sep,
 bytes_per_sep) is many times slower than manually inserting the
 separators
In-Reply-To: <1587157109.99.0.0253750787201.issue40313@roundup.psfhosted.org>
Message-ID: <1587288345.43.0.352069548085.issue40313@roundup.psfhosted.org>


Dennis Sweeney <sweeney.dennis650 at gmail.com> added the comment:

========== Master ==========

.\python.bat -m pyperf timeit -s "import random, math; data=random.getrandbits(8*10_000_000).to_bytes(10_000_000, 'big')" "temp = data.hex(); '\n'.join(temp[n:n+128] for n in range(0, len(temp), 128))"

Mean +- std dev: 74.3 ms +- 1.1 ms

.\python.bat -m pyperf timeit -s "import random; data=random.getrandbits(8*10_000_000).to_bytes(10_000_000, 'big')" "data.hex('\n', -64)"

Mean +- std dev: 44.0 ms +- 0.3 ms

========== PR 19594 ==========

.\python.bat -m pyperf timeit -s "import random, math; data=random.getrandbits(8*10_000_000).to_bytes(10_000_000, 'big')" "temp = data.hex(); '\n'.join(temp[n:n+128] for n in range(0, len(temp), 128))"

Mean +- std dev: 65.2 ms +- 0.6 ms

.\python.bat -m pyperf timeit -s "import random; data=random.getrandbits(8*10_000_000).to_bytes(10_000_000, 'big')" "data.hex('\n', -64)"

Mean +- std dev: 18.1 ms +- 0.1 ms

----------
type:  -> performance

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40313>
_______________________________________

From report at bugs.python.org  Sun Apr 19 05:25:54 2020
From: report at bugs.python.org (Yuval S)
Date: Sun, 19 Apr 2020 09:25:54 +0000
Subject: [issue40325] Random.seed does not affect string hash randomization
 leading to non-intuitive results
In-Reply-To: <1587245119.63.0.0763742728572.issue40325@roundup.psfhosted.org>
Message-ID: <1587288354.87.0.363187442763.issue40325@roundup.psfhosted.org>


Change by Yuval S <sadan.yuval at gmail.com>:


----------
pull_requests: +18932
pull_request: https://github.com/python/cpython/pull/19596

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40325>
_______________________________________

From report at bugs.python.org  Sun Apr 19 05:26:26 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Sun, 19 Apr 2020 09:26:26 +0000
Subject: [issue40326] A string contains an empty string?
In-Reply-To: <1587280457.85.0.869206136308.issue40326@roundup.psfhosted.org>
Message-ID: <1587288386.71.0.263605413826.issue40326@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

https://docs.python.org/3/reference/expressions.html#membership-test-operations

----------
nosy: +steven.daprano

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40326>
_______________________________________

From report at bugs.python.org  Sun Apr 19 05:43:14 2020
From: report at bugs.python.org (miss-islington)
Date: Sun, 19 Apr 2020 09:43:14 +0000
Subject: [issue39285] PurePath.match indicates case-sensitive nature and
 presents a case-insensitive example
In-Reply-To: <1578650816.04.0.399157633818.issue39285@roundup.psfhosted.org>
Message-ID: <1587289394.63.0.0204648749382.issue39285@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset c12375aa0b838d34067efa3f1b9a1fbc632d0413 by Tim Lo in branch 'master':
bpo-39285: Clarify example for PurePath.match (GH-19458)
https://github.com/python/cpython/commit/c12375aa0b838d34067efa3f1b9a1fbc632d0413


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39285>
_______________________________________

From report at bugs.python.org  Sun Apr 19 05:43:36 2020
From: report at bugs.python.org (miss-islington)
Date: Sun, 19 Apr 2020 09:43:36 +0000
Subject: [issue39285] PurePath.match indicates case-sensitive nature and
 presents a case-insensitive example
In-Reply-To: <1578650816.04.0.399157633818.issue39285@roundup.psfhosted.org>
Message-ID: <1587289416.55.0.691489070819.issue39285@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +18933
pull_request: https://github.com/python/cpython/pull/19597

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39285>
_______________________________________

From report at bugs.python.org  Sun Apr 19 05:43:43 2020
From: report at bugs.python.org (miss-islington)
Date: Sun, 19 Apr 2020 09:43:43 +0000
Subject: [issue39285] PurePath.match indicates case-sensitive nature and
 presents a case-insensitive example
In-Reply-To: <1578650816.04.0.399157633818.issue39285@roundup.psfhosted.org>
Message-ID: <1587289423.93.0.325619135631.issue39285@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +18934
pull_request: https://github.com/python/cpython/pull/19598

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39285>
_______________________________________

From report at bugs.python.org  Sun Apr 19 05:55:39 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 19 Apr 2020 09:55:39 +0000
Subject: [issue40269] Inconsistent complex behavior with (-1j)
In-Reply-To: <1586736208.71.0.129112794549.issue40269@roundup.psfhosted.org>
Message-ID: <1587290139.54.0.221472239337.issue40269@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> I tried to make repr of floats producing a string which rounds up with eval()

We've looked at this before. There just isn't any sane and easy way to do this, except for changing the repr to be "complex(real, imag)", which is the solution that I favour.

And this seems like a non-starter to me:

    >>> complex(0.0, -0.0)
    -(-0.0-0j)

This is a case where the cure is worse than the disease.

We should also not change the repr lightly: the last time it was changed, it caused disruption at least for Cython, and probably for NumPy too. As a corollary, if we _do_ change it, we should make sure we get it right so that we're changing it to something we're not going to want to change again in 5 years' time. And I suspect that if we don't solve the underlying roundtrip problem, then this is going to come up again.

I'm +1 on changing the repr to "complex(..., ...)", +0 on modifying it to always include both real and imaginary parts _and_ format those parts as though they're floats; -1 on other changes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40269>
_______________________________________

From report at bugs.python.org  Sun Apr 19 06:03:39 2020
From: report at bugs.python.org (miss-islington)
Date: Sun, 19 Apr 2020 10:03:39 +0000
Subject: [issue39285] PurePath.match indicates case-sensitive nature and
 presents a case-insensitive example
In-Reply-To: <1578650816.04.0.399157633818.issue39285@roundup.psfhosted.org>
Message-ID: <1587290619.27.0.794204800962.issue39285@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 8c0734397603d84e3a2e753463b44cf904147cc4 by Miss Islington (bot) in branch '3.8':
bpo-39285: Clarify example for PurePath.match (GH-19458)
https://github.com/python/cpython/commit/8c0734397603d84e3a2e753463b44cf904147cc4


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39285>
_______________________________________

From report at bugs.python.org  Sun Apr 19 06:03:45 2020
From: report at bugs.python.org (miss-islington)
Date: Sun, 19 Apr 2020 10:03:45 +0000
Subject: [issue39285] PurePath.match indicates case-sensitive nature and
 presents a case-insensitive example
In-Reply-To: <1578650816.04.0.399157633818.issue39285@roundup.psfhosted.org>
Message-ID: <1587290625.91.0.558857244118.issue39285@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 143147d94f3e55a929327ddae1d0d3c260d71cef by Miss Islington (bot) in branch '3.7':
bpo-39285: Clarify example for PurePath.match (GH-19458)
https://github.com/python/cpython/commit/143147d94f3e55a929327ddae1d0d3c260d71cef


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39285>
_______________________________________

From report at bugs.python.org  Sun Apr 19 06:04:10 2020
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 19 Apr 2020 10:04:10 +0000
Subject: [issue39285] PurePath.match indicates case-sensitive nature and
 presents a case-insensitive example
In-Reply-To: <1578650816.04.0.399157633818.issue39285@roundup.psfhosted.org>
Message-ID: <1587290650.77.0.274058897558.issue39285@roundup.psfhosted.org>


Change by Antoine Pitrou <solipsis at pitrou.net>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39285>
_______________________________________

From report at bugs.python.org  Sun Apr 19 06:41:04 2020
From: report at bugs.python.org (hai shi)
Date: Sun, 19 Apr 2020 10:41:04 +0000
Subject: [issue40275] test.support has way too many imports
In-Reply-To: <1586816691.28.0.874442798421.issue40275@roundup.psfhosted.org>
Message-ID: <1587292864.49.0.524789826968.issue40275@roundup.psfhosted.org>


Change by hai shi <shihai1991 at 126.com>:


----------
pull_requests: +18935
pull_request: https://github.com/python/cpython/pull/19599

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40275>
_______________________________________

From report at bugs.python.org  Sun Apr 19 07:13:43 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 19 Apr 2020 11:13:43 +0000
Subject: [issue40275] test.support has way too many imports
In-Reply-To: <1586816691.28.0.874442798421.issue40275@roundup.psfhosted.org>
Message-ID: <1587294823.03.0.956883580891.issue40275@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

logging is also imported in unittest and indirectly in asyncio.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40275>
_______________________________________

From report at bugs.python.org  Sun Apr 19 07:20:36 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 19 Apr 2020 11:20:36 +0000
Subject: [issue40275] test.support has way too many imports
In-Reply-To: <1586816691.28.0.874442798421.issue40275@roundup.psfhosted.org>
Message-ID: <1587295236.65.0.619814322183.issue40275@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +18936
pull_request: https://github.com/python/cpython/pull/19600

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40275>
_______________________________________

From report at bugs.python.org  Sun Apr 19 07:23:34 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 19 Apr 2020 11:23:34 +0000
Subject: [issue40275] test.support has way too many imports
In-Reply-To: <1586816691.28.0.874442798421.issue40275@roundup.psfhosted.org>
Message-ID: <1587295414.67.0.536858082538.issue40275@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +18937
pull_request: https://github.com/python/cpython/pull/19601

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40275>
_______________________________________

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: [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 09:20:52 2020
From: report at bugs.python.org (szb512)
Date: Sun, 19 Apr 2020 13:20:52 +0000
Subject: [issue39107] Upgrade tcl/tk to 8.6.10 (Windows and maxOS)
In-Reply-To: <1576838540.23.0.689551930127.issue39107@roundup.psfhosted.org>
Message-ID: <1587302452.79.0.485164118414.issue39107@roundup.psfhosted.org>


szb512 <magicman730 at hotmail.com> added the comment:

That backfired horribly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39107>
_______________________________________

From report at bugs.python.org  Sun Apr 19 09:26:02 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Sun, 19 Apr 2020 13:26:02 +0000
Subject: [issue40328] Add tools for generating mappings_XX.h
In-Reply-To: <1587302039.42.0.928310034054.issue40328@roundup.psfhosted.org>
Message-ID: <1587302762.68.0.169259633432.issue40328@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
keywords: +patch
pull_requests: +18938
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19602

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40328>
_______________________________________

From report at bugs.python.org  Sun Apr 19 09:35:05 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 19 Apr 2020 13:35:05 +0000
Subject: [issue40275] test.support has way too many imports
In-Reply-To: <1586816691.28.0.874442798421.issue40275@roundup.psfhosted.org>
Message-ID: <1587303305.27.0.883486727277.issue40275@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +18939
pull_request: https://github.com/python/cpython/pull/19603

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40275>
_______________________________________

From report at bugs.python.org  Sun Apr 19 09:51:21 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 19 Apr 2020 13:51:21 +0000
Subject: [issue40313] bytes.hex(sep,
 bytes_per_sep) is many times slower than manually inserting the
 separators
In-Reply-To: <1587157109.99.0.0253750787201.issue40313@roundup.psfhosted.org>
Message-ID: <1587304281.48.0.0891675581268.issue40313@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40313>
_______________________________________

From report at bugs.python.org  Sun Apr 19 10:01:20 2020
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 19 Apr 2020 14:01:20 +0000
Subject: [issue39207] concurrent.futures.ProcessPoolExecutor does not properly
 reap jobs and spawns too many workers
In-Reply-To: <1578087844.56.0.81762061225.issue39207@roundup.psfhosted.org>
Message-ID: <1587304880.87.0.28870418308.issue39207@roundup.psfhosted.org>


Change by Antoine Pitrou <solipsis at pitrou.net>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39207>
_______________________________________

From report at bugs.python.org  Sun Apr 19 10:01:04 2020
From: report at bugs.python.org (miss-islington)
Date: Sun, 19 Apr 2020 14:01:04 +0000
Subject: [issue39207] concurrent.futures.ProcessPoolExecutor does not properly
 reap jobs and spawns too many workers
In-Reply-To: <1578087844.56.0.81762061225.issue39207@roundup.psfhosted.org>
Message-ID: <1587304864.2.0.96852927968.issue39207@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 1ac6e379297cc1cf8acf6c1b011fccc7b3da2cbe by Kyle Stanley in branch 'master':
bpo-39207: Spawn workers on demand in ProcessPoolExecutor (GH-19453)
https://github.com/python/cpython/commit/1ac6e379297cc1cf8acf6c1b011fccc7b3da2cbe


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39207>
_______________________________________

From report at bugs.python.org  Sun Apr 19 10:01:56 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 19 Apr 2020 14:01:56 +0000
Subject: [issue40275] test.support has way too many imports
In-Reply-To: <1586816691.28.0.874442798421.issue40275@roundup.psfhosted.org>
Message-ID: <1587304916.57.0.965718105623.issue40275@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

These three PRs combined reduce the number of imported modules from 179 to 105 (not including 24 modules imported by the bare interpreter) and reduce the hot import time from 160 ms to 80 ms.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40275>
_______________________________________

From report at bugs.python.org  Sun Apr 19 10:20:06 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 19 Apr 2020 14:20:06 +0000
Subject: [issue40328] Add tools for generating mappings_XX.h
In-Reply-To: <1587302039.42.0.928310034054.issue40328@roundup.psfhosted.org>
Message-ID: <1587306006.17.0.015966086901.issue40328@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
components: +Demos and Tools
nosy: +hyeshik.chang, serhiy.storchaka
versions: +Python 3.9

_______________________________________
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: [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: [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 10:47:30 2020
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 19 Apr 2020 14:47:30 +0000
Subject: [issue40330] ShareableList size guard incorrect for str data
Message-ID: <1587307650.58.0.0332306022836.issue40330@roundup.psfhosted.org>


New submission from Antoine Pitrou <solipsis at pitrou.net>:

The size check is done before encoding to utf-8...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40330>
_______________________________________

From report at bugs.python.org  Sun Apr 19 10:51:55 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 19 Apr 2020 14:51:55 +0000
Subject: [issue40329] Faulty dict arg gives ValueError but mostly TypeError
In-Reply-To: <1587307144.84.0.271412864136.issue40329@roundup.psfhosted.org>
Message-ID: <1587307915.95.0.677793805868.issue40329@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

It is all correct. Note that set is unordered, so "element #0" can be 1, and can be "one". If it is 1, you get a type error. If it is "one", which is a sequence with length 3, you get a value error.

----------
nosy: +serhiy.storchaka
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40329>
_______________________________________

From report at bugs.python.org  Sun Apr 19 11:19:28 2020
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 19 Apr 2020 15:19:28 +0000
Subject: [issue38891] ShareableList read and write access is O(N),
 should be O(1)
In-Reply-To: <1574389874.92.0.425732905902.issue38891@roundup.psfhosted.org>
Message-ID: <1587309568.18.0.453907564824.issue38891@roundup.psfhosted.org>


Antoine Pitrou <solipsis at pitrou.net> added the comment:


New changeset c8f1715283ec51822fb37a702bf253cbac1af276 by Thomas Krennwallner in branch 'master':
bpo-38891: avoid quadratic item access performance of ShareableList (GH-18996)
https://github.com/python/cpython/commit/c8f1715283ec51822fb37a702bf253cbac1af276


----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38891>
_______________________________________

From report at bugs.python.org  Sun Apr 19 11:19:42 2020
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 19 Apr 2020 15:19:42 +0000
Subject: [issue38891] ShareableList read and write access is O(N),
 should be O(1)
In-Reply-To: <1574389874.92.0.425732905902.issue38891@roundup.psfhosted.org>
Message-ID: <1587309582.19.0.0117442484906.issue38891@roundup.psfhosted.org>


Change by Antoine Pitrou <solipsis at pitrou.net>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38891>
_______________________________________

From report at bugs.python.org  Sun Apr 19 11:27:08 2020
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 19 Apr 2020 15:27:08 +0000
Subject: [issue40330] ShareableList size guard incorrect for str data
In-Reply-To: <1587307650.58.0.0332306022836.issue40330@roundup.psfhosted.org>
Message-ID: <1587310028.66.0.315856207834.issue40330@roundup.psfhosted.org>


Change by Antoine Pitrou <solipsis at pitrou.net>:


----------
keywords: +patch
pull_requests: +18940
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/19606

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40330>
_______________________________________

From report at bugs.python.org  Sun Apr 19 11:29:56 2020
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 19 Apr 2020 15:29:56 +0000
Subject: [issue40148] Add PurePath.with_stem()
In-Reply-To: <1585788024.89.0.165310869252.issue40148@roundup.psfhosted.org>
Message-ID: <1587310196.65.0.464807864977.issue40148@roundup.psfhosted.org>


Antoine Pitrou <solipsis at pitrou.net> added the comment:


New changeset 8aea4b3605059e243f1827d9328d6fc8d698c0a7 by Tim Hoffmann in branch 'master':
bpo-40148: Add PurePath.with_stem() (GH-19295)
https://github.com/python/cpython/commit/8aea4b3605059e243f1827d9328d6fc8d698c0a7


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40148>
_______________________________________

From report at bugs.python.org  Sun Apr 19 11:30:07 2020
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 19 Apr 2020 15:30:07 +0000
Subject: [issue40148] Add PurePath.with_stem()
In-Reply-To: <1585788024.89.0.165310869252.issue40148@roundup.psfhosted.org>
Message-ID: <1587310207.56.0.628172834451.issue40148@roundup.psfhosted.org>


Change by Antoine Pitrou <solipsis at pitrou.net>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40148>
_______________________________________

From report at bugs.python.org  Sun Apr 19 11:40:14 2020
From: report at bugs.python.org (hai shi)
Date: Sun, 19 Apr 2020 15:40:14 +0000
Subject: [issue40275] test.support has way too many imports
In-Reply-To: <1586816691.28.0.874442798421.issue40275@roundup.psfhosted.org>
Message-ID: <1587310814.9.0.349995091031.issue40275@roundup.psfhosted.org>


hai shi <shihai1991 at 126.com> added the comment:

> These three PRs combined reduce the number of imported modules from 179 to 105 (not including 24 modules imported by the bare interpreter) and reduce the hot import time from 160 ms to 80 ms.

Good job, serhiy. I tested your patches in my vm, the number of importing module have been reduced. Could you paste your performance benchmark test? I got a no siginificant change :( when I run: 
$ ./python -m pyperf timeit --compare-to python3.9 "from test import support" -p 100
python3.9: ..................................................................................................... 820 ns +- 206 ns

python: ..................................................................................................... 809 ns +- 201 ns

Mean +- std dev: [python3.9] 820 ns +- 206 ns -> [python] 809 ns +- 201 ns: 1.01x faster (-1%)
Not significant!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40275>
_______________________________________

From report at bugs.python.org  Sun Apr 19 11:49:55 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 19 Apr 2020 15:49:55 +0000
Subject: [issue40275] test.support has way too many imports
In-Reply-To: <1586816691.28.0.874442798421.issue40275@roundup.psfhosted.org>
Message-ID: <1587311395.48.0.695677139504.issue40275@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I used -X importtime.

Your benchmark measures the performance of look up in sys.modules.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40275>
_______________________________________

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: [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 12:25:28 2020
From: report at bugs.python.org (hai shi)
Date: Sun, 19 Apr 2020 16:25:28 +0000
Subject: [issue40275] test.support has way too many imports
In-Reply-To: <1586816691.28.0.874442798421.issue40275@roundup.psfhosted.org>
Message-ID: <1587313528.8.0.422013076175.issue40275@roundup.psfhosted.org>


hai shi <shihai1991 at 126.com> added the comment:

> I used -X importtime.
copy that, thanks.

In master branch:
import time:      5011 |     133562 | test.support

After apply serhiy's patches:
import time:      4863 |      66940 | test.support

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40275>
_______________________________________

From report at bugs.python.org  Sun Apr 19 12:36:25 2020
From: report at bugs.python.org (Tzanetos Balitsaris)
Date: Sun, 19 Apr 2020 16:36:25 +0000
Subject: [issue40331] Increase test coverage for the statistics module
In-Reply-To: <1587313488.32.0.170257726917.issue40331@roundup.psfhosted.org>
Message-ID: <1587314185.44.0.544787377359.issue40331@roundup.psfhosted.org>


Change by Tzanetos Balitsaris <tbalitsaris at gmail.com>:


----------
keywords: +patch
pull_requests: +18941
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19608

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40331>
_______________________________________

From report at bugs.python.org  Sun Apr 19 12:59:53 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 19 Apr 2020 16:59:53 +0000
Subject: [issue40331] Increase test coverage for the statistics module
In-Reply-To: <1587313488.32.0.170257726917.issue40331@roundup.psfhosted.org>
Message-ID: <1587315593.54.0.0443631003308.issue40331@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +steven.daprano

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40331>
_______________________________________

From report at bugs.python.org  Sun Apr 19 13:03:32 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 19 Apr 2020 17:03:32 +0000
Subject: [issue40083] No run option available in python idle in version 3.8.2
In-Reply-To: <1585292684.98.0.176532437082.issue40083@roundup.psfhosted.org>
Message-ID: <1587315812.58.0.101140230262.issue40083@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

3. You did not answer about the tcl/tk version.

4. When you start from the start menu, there is no Editor window, just the Shell window, which does not have the Run menu.  Again, how did you get an editor window?

5. Search the Web for an illustrated explanation or ask on python-list.

6. 'touch' was the wrong word.  I should have asked, "Have you changed any of the  files in Lib/idlelib?  If which ones, and how?"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40083>
_______________________________________

From report at bugs.python.org  Sun Apr 19 13:05:26 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 19 Apr 2020 17:05:26 +0000
Subject: [issue40324] python 3.8.2 idle not opening
In-Reply-To: <1587239062.2.0.770603015348.issue40324@roundup.psfhosted.org>
Message-ID: <1587315926.79.0.97364757521.issue40324@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

The relevant one.  Skip 3 and 4.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40324>
_______________________________________

From report at bugs.python.org  Sun Apr 19 13:13:40 2020
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Sun, 19 Apr 2020 17:13:40 +0000
Subject: [issue37373] Configuration of windows event loop for libraries
In-Reply-To: <1561228405.39.0.674272094682.issue37373@roundup.psfhosted.org>
Message-ID: <1587316420.96.0.697873552382.issue37373@roundup.psfhosted.org>


?ukasz Langa <lukasz at langa.pl> added the comment:

I'd be +1 to bringing uvloop into the stdlib, it would solve many things while introducing an acceptable dependency in the form of libuv.

However, uvloop itself is written in Cython which makes it impossible for us to directly merge it. So that option is pretty much off the table as rewriting the library is not something we have resources for right now.

Ben, Nathaniel is onto something though. Would it be acceptable for you to *require* use of uvloop when Tornado is used with AsyncIO? That indeed solves the Windows problems, and more. I use uvloop in all asyncio applications I maintain (*except for Black which is tested to work on Windows with the Proactor loop).

For Python 3.9, it is a bit late, but not *too late* yet, to make the Proactor loop support AFD_POLL. Maybe counter-intuitively I would feel better about *that* rather than have a background thread with a SelectorEventLoop.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37373>
_______________________________________

From report at bugs.python.org  Sun Apr 19 13:14:51 2020
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Sun, 19 Apr 2020 17:14:51 +0000
Subject: [issue39651] Exceptions raised by EventLoop.call_soon_threadsafe
In-Reply-To: <1581871318.96.0.350376923794.issue39651@roundup.psfhosted.org>
Message-ID: <1587316491.93.0.0977204103469.issue39651@roundup.psfhosted.org>


?ukasz Langa <lukasz at langa.pl> added the comment:

Good catch. We should fix this for Python 3.8.3.

----------
nosy: +lukasz.langa
priority: normal -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39651>
_______________________________________

From report at bugs.python.org  Sun Apr 19 13:21:35 2020
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Sun, 19 Apr 2020 17:21:35 +0000
Subject: [issue17986] Alternative async subprocesses (pep 3145)
In-Reply-To: <1368652199.21.0.577907802925.issue17986@psf.upfronthosting.co.za>
Message-ID: <1587316895.03.0.102904077076.issue17986@roundup.psfhosted.org>


?ukasz Langa <lukasz at langa.pl> added the comment:

Should this still be open given that PEP 3145 is withdrawn and asyncio subprocesses have been used in production for five Python releases now?

----------
nosy: +lukasz.langa

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17986>
_______________________________________

From report at bugs.python.org  Sun Apr 19 14:21:47 2020
From: report at bugs.python.org (Ben Darnell)
Date: Sun, 19 Apr 2020 18:21:47 +0000
Subject: [issue37373] Configuration of windows event loop for libraries
In-Reply-To: <1561228405.39.0.674272094682.issue37373@roundup.psfhosted.org>
Message-ID: <1587320507.7.0.0870457862873.issue37373@roundup.psfhosted.org>


Ben Darnell <ben.darnell at gmail.com> added the comment:

> Would it be acceptable for you to *require* use of uvloop when Tornado is used with AsyncIO?

How, exactly? Adding the dependency is no problem, but AFAIK I'd still be stuck with an import-time side effect to set the event loop policy (or a .pth file hack, I guess). Maybe an import-time side effect that chooses uvloop is better since it's a functional superset of the two default windows event loops, but setting the policy at import time still has its problems (What if another module has initialized the event loop before tornado is imported? What if someone also wants to set a custom policy to work around asyncio's strict "only on the main thread" defaults?)

That's why I started this thread not asking for a proactor+selector hybrid event loop, but a better way to *configure* the event loop because policies aren't really doing the job in this case. 

> I considered using the `selectors` module directly, but it's not as simple as it sounds.

FWIW, I've reconsidered this. Treating SelectorEventLoop as a black box means you don't have enough control over synchronization and it's hard to avoid spurious wakeups and busy loops on the selector thread. I have a (broken) prototype using SelectorEventLoop that I plan to rewrite to call select.select directly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37373>
_______________________________________

From report at bugs.python.org  Sun Apr 19 14:21:51 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Sun, 19 Apr 2020 18:21:51 +0000
Subject: [issue28002] ast.unparse can't roundtrip some f-strings
In-Reply-To: <1473268698.62.0.800338957351.issue28002@psf.upfronthosting.co.za>
Message-ID: <1587320511.54.0.105258799144.issue28002@roundup.psfhosted.org>


Batuhan Taskaya <batuhanosmantaskaya at gmail.com> added the comment:

> If that sounds good, I can submit a PR and inform the original author

I can't say anything before seeing the approach but fixing the problem definitely sounds good.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28002>
_______________________________________

From report at bugs.python.org  Sun Apr 19 14:49:11 2020
From: report at bugs.python.org (Tim Peters)
Date: Sun, 19 Apr 2020 18:49:11 +0000
Subject: [issue40312] Weakref callbacks running before finalizers in GC
 collection
In-Reply-To: <1587153160.93.0.26793085181.issue40312@roundup.psfhosted.org>
Message-ID: <1587322151.49.0.170347952577.issue40312@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

Things get complicated here because in older versions of Python an instance of ForeverObject(True) could "leak" forever:  if an object in a trash cycle had a __del__ method, that method would never be called, and the object would never be collected.

Starting in Python 3.4, that changed:  __del__ no longer inhibits collection of objects in cyclic trash.  However, __del__ is called no more than once starting in 3.4.  If an object is resurrected by __del__, it's marked with a "__del__ was already called" bit, and __del__ is never called again by magic if/when the object becomes trash again.

I don't think the weakref docs were changed, because nobody cares ;-)  

What it _intended_ to mean by "about to be finalized" is clear as mud.  What it actually means is akin to "about to have its memory destroyed and recycled".

In current CPython, for your ForeverObject(False), `del o` does not make the object trash "for real".  __del__ runs immediately (due to deterministic, synchronous reference counting) and resurrects it.  That cuts off the "about to have its memory destroyed and recycled" part, so the callback doesn't run.

But if you do

    del o

again, _then_ the callback runs.  __del__ isn't run again, so the object isn't resurrected again, so the "about to have its memory destroyed and recycled" part applies.

In cyclic gc, there is no deterministic order in which end-of-life actions occur.  There may well be thousands of objects in cyclic trash, or reachable only from cyclic trash.  The order picked is more-or-less arbitrary, just trying like hell to ensure that no end-of-life action ever "sees" an object whose memory has already been destroyed and recycled.

To make progress at all, it _assumes_ all the cyclic trash really will be reclaimed (memory destroyed and recycled).  That's why it runs all weakref callbacks to trash objects (provided the weakref isn't also trash).  It also runs all finalizers (except on objects with a __del__ that has already been called).  Only after _all_ that is done does it even start to destroy and recycle memory.

Although, along the way, memory _may_ be destroyed and recycled as a result of refcounts falling to 0 as end-of-life actions (callbacks and finalizers) are invoked.

And, yup, it's as delicate as it sounds ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40312>
_______________________________________

From report at bugs.python.org  Sun Apr 19 14:56:46 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 19 Apr 2020 18:56:46 +0000
Subject: [issue40327] list(sys.modules.items()) can throw RuntimeError:
 dictionary changed size during iteration
In-Reply-To: <1587284646.11.0.468516211586.issue40327@roundup.psfhosted.org>
Message-ID: <1587322606.35.0.0699415496542.issue40327@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Suggest making this change:

-    for module_name, module in list(sys.modules.items()):
+    for module_name, module in sys.modules.copy().items():

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40327>
_______________________________________

From report at bugs.python.org  Sun Apr 19 14:59:46 2020
From: report at bugs.python.org (Tomas Nordin)
Date: Sun, 19 Apr 2020 18:59:46 +0000
Subject: [issue40329] Faulty dict arg gives ValueError but mostly TypeError
In-Reply-To: <1587307915.95.0.677793805868.issue40329@roundup.psfhosted.org>
Message-ID: <875zdvnvxc.fsf@fliptop.i-did-not-set--mail-host-address--so-tickle-me>


Tomas Nordin <tomasn at posteo.net> added the comment:

Serhiy Storchaka <report at bugs.python.org> writes:

> Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:
>
> It is all correct. Note that set is unordered, so "element #0" can be 1, and can be "one". If it is 1, you get a type error. If it is "one", which is a sequence with length 3, you get a value error.

Yes! Thanks, sorry for the noise.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40329>
_______________________________________

From report at bugs.python.org  Sun Apr 19 15:13:44 2020
From: report at bugs.python.org (Simon Percivall)
Date: Sun, 19 Apr 2020 19:13:44 +0000
Subject: [issue28002] ast.unparse can't roundtrip some f-strings
In-Reply-To: <1473268698.62.0.800338957351.issue28002@psf.upfronthosting.co.za>
Message-ID: <1587323624.62.0.371579312699.issue28002@roundup.psfhosted.org>


Simon Percivall <percivall at gmail.com> added the comment:

Any and all code from astunparse is certainly available for inclusion. Go ahead.

----------
nosy: +simon.percivall

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28002>
_______________________________________

From report at bugs.python.org  Sun Apr 19 15:36:39 2020
From: report at bugs.python.org (Alessandro Molina)
Date: Sun, 19 Apr 2020 19:36:39 +0000
Subject: [issue40307] multiprocessing.BaseManager does not retain Client type.
In-Reply-To: <1587072930.89.0.0694830896032.issue40307@roundup.psfhosted.org>
Message-ID: <1587324999.98.0.531137707065.issue40307@roundup.psfhosted.org>


Change by Alessandro Molina <amol at turbogears.org>:


----------
keywords: +patch
pull_requests: +18942
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19609

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40307>
_______________________________________

From report at bugs.python.org  Sun Apr 19 15:43:21 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 19 Apr 2020 19:43:21 +0000
Subject: [issue40307] multiprocessing.BaseManager does not retain Client type.
In-Reply-To: <1587072930.89.0.0694830896032.issue40307@roundup.psfhosted.org>
Message-ID: <1587325401.51.0.773331625825.issue40307@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +davin, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40307>
_______________________________________

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: [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: [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:10:46 2020
From: report at bugs.python.org (Gregory Szorc)
Date: Sun, 19 Apr 2020 20:10:46 +0000
Subject: [issue40333] Request for multi-phase initialization API to run code
 after importlib init
In-Reply-To: <1587327033.84.0.66503294203.issue40333@roundup.psfhosted.org>
Message-ID: <1587327046.08.0.957195125394.issue40333@roundup.psfhosted.org>


Change by Gregory Szorc <gregory.szorc at gmail.com>:


----------
type:  -> enhancement

_______________________________________
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: [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 16:17:57 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Sun, 19 Apr 2020 20:17:57 +0000
Subject: [issue40334] PEP 617: new PEG-based parser
In-Reply-To: <1587327377.33.0.614039250584.issue40334@roundup.psfhosted.org>
Message-ID: <1587327477.29.0.384294981351.issue40334@roundup.psfhosted.org>


Change by Batuhan Taskaya <batuhanosmantaskaya at gmail.com>:


----------
nosy: +BTaskaya

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40334>
_______________________________________

From report at bugs.python.org  Sun Apr 19 16:21:23 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 19 Apr 2020 20:21:23 +0000
Subject: [issue40334] PEP 617: new PEG-based parser
In-Reply-To: <1587327377.33.0.614039250584.issue40334@roundup.psfhosted.org>
Message-ID: <1587327683.7.0.209323765091.issue40334@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
keywords: +patch
pull_requests: +18943
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19503

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40334>
_______________________________________

From report at bugs.python.org  Sun Apr 19 17:19:07 2020
From: report at bugs.python.org (Zackery Spytz)
Date: Sun, 19 Apr 2020 21:19:07 +0000
Subject: [issue23980] Documentation for format units starting with 'e' is
 inconsistent
In-Reply-To: <1429227526.01.0.733275706487.issue23980@psf.upfronthosting.co.za>
Message-ID: <1587331147.38.0.677840542401.issue23980@roundup.psfhosted.org>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
keywords: +patch
nosy: +ZackerySpytz
nosy_count: 7.0 -> 8.0
pull_requests: +18944
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/19610

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23980>
_______________________________________

From report at bugs.python.org  Sun Apr 19 17:22:26 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 19 Apr 2020 21:22:26 +0000
Subject: [issue40327] list(sys.modules.items()) can throw RuntimeError:
 dictionary changed size during iteration
In-Reply-To: <1587284646.11.0.468516211586.issue40327@roundup.psfhosted.org>
Message-ID: <1587331346.82.0.272010066217.issue40327@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

We should consider making this change just about everywhere in the standard library.  Besides avoiding a race condition, running a for loop over `d.copy().items()` is more memory efficient and possibly faster than a for loop over `list(d.items())`.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40327>
_______________________________________

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: [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  Sun Apr 19 17:45:48 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Sun, 19 Apr 2020 21:45:48 +0000
Subject: [issue40335] Regression in multiline SyntaxError offsets
In-Reply-To: <1587332455.2.0.964330224308.issue40335@roundup.psfhosted.org>
Message-ID: <1587332748.78.0.983146025981.issue40335@roundup.psfhosted.org>


Change by Batuhan Taskaya <batuhanosmantaskaya at gmail.com>:


----------
nosy: +BTaskaya

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40335>
_______________________________________

From report at bugs.python.org  Sun Apr 19 17:48:50 2020
From: report at bugs.python.org (Anthony Sottile)
Date: Sun, 19 Apr 2020 21:48:50 +0000
Subject: [issue40335] Regression in multiline SyntaxError offsets
In-Reply-To: <1587332455.2.0.964330224308.issue40335@roundup.psfhosted.org>
Message-ID: <1587332930.34.0.205636858148.issue40335@roundup.psfhosted.org>


Change by Anthony Sottile <asottile at umich.edu>:


----------
nosy: +pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40335>
_______________________________________

From report at bugs.python.org  Sun Apr 19 17:50:17 2020
From: report at bugs.python.org (Zackery Spytz)
Date: Sun, 19 Apr 2020 21:50:17 +0000
Subject: [issue23980] Documentation for format units starting with 'e' is
 inconsistent
In-Reply-To: <1429227526.01.0.733275706487.issue23980@psf.upfronthosting.co.za>
Message-ID: <1587333017.39.0.817772454888.issue23980@roundup.psfhosted.org>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
versions: +Python 3.7, Python 3.8, Python 3.9 -Python 2.7, Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23980>
_______________________________________

From report at bugs.python.org  Sun Apr 19 17:51:36 2020
From: report at bugs.python.org (Zackery Spytz)
Date: Sun, 19 Apr 2020 21:51:36 +0000
Subject: [issue9751] _PyInstance_Lookup() defeats its purpose
In-Reply-To: <1283506212.5.0.831864167364.issue9751@psf.upfronthosting.co.za>
Message-ID: <1587333096.38.0.437242678533.issue9751@roundup.psfhosted.org>


Zackery Spytz <zspytz at gmail.com> added the comment:

Python 2 is EOL.

----------
nosy: +ZackerySpytz

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue9751>
_______________________________________

From report at bugs.python.org  Sun Apr 19 17:58:52 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 19 Apr 2020 21:58:52 +0000
Subject: [issue40335] Regression in multiline SyntaxError offsets
In-Reply-To: <1587332455.2.0.964330224308.issue40335@roundup.psfhosted.org>
Message-ID: <1587333532.79.0.044184667459.issue40335@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40335>
_______________________________________

From report at bugs.python.org  Sun Apr 19 18:01:25 2020
From: report at bugs.python.org (gaborbernat)
Date: Sun, 19 Apr 2020 22:01:25 +0000
Subject: [issue40335] Regression in multiline SyntaxError offsets
In-Reply-To: <1587332455.2.0.964330224308.issue40335@roundup.psfhosted.org>
Message-ID: <1587333685.85.0.976930452495.issue40335@roundup.psfhosted.org>


Change by gaborbernat <gaborjbernat at gmail.com>:


----------
nosy: +gaborbernat

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40335>
_______________________________________

From report at bugs.python.org  Sun Apr 19 18:11:59 2020
From: report at bugs.python.org (Lysandros Nikolaou)
Date: Sun, 19 Apr 2020 22:11:59 +0000
Subject: [issue40334] PEP 617: new PEG-based parser
In-Reply-To: <1587327377.33.0.614039250584.issue40334@roundup.psfhosted.org>
Message-ID: <1587334319.53.0.599904274391.issue40334@roundup.psfhosted.org>


Change by Lysandros Nikolaou <lisandrosnik at gmail.com>:


----------
nosy: +lys.nikolaou

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40334>
_______________________________________

From report at bugs.python.org  Sun Apr 19 18:37:25 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 19 Apr 2020 22:37:25 +0000
Subject: [issue40335] Regression in multiline SyntaxError offsets
In-Reply-To: <1587332455.2.0.964330224308.issue40335@roundup.psfhosted.org>
Message-ID: <1587335845.83.0.740713120721.issue40335@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

The regression happened in:

commit 41d5b94af44e34ac05d4cd57460ed104ccf96628
Author: Lysandros Nikolaou <lisandrosnik at gmail.com>
Date:   Sun Apr 12 21:21:00 2020 +0300

    bpo-40246: Report a better error message for invalid string prefixes (GH-19476)

Will try to get a look at this shortly

----------
nosy: +lys.nikolaou

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40335>
_______________________________________

From report at bugs.python.org  Sun Apr 19 19:04:34 2020
From: report at bugs.python.org (Sadhana Srinivasan)
Date: Sun, 19 Apr 2020 23:04:34 +0000
Subject: [issue23082] pathlib relative_to() can give confusing error message
In-Reply-To: <1418909839.25.0.648032443428.issue23082@psf.upfronthosting.co.za>
Message-ID: <1587337474.21.0.577058017553.issue23082@roundup.psfhosted.org>


Change by Sadhana Srinivasan <sadhanasrinivasan at pm.me>:


----------
keywords: +patch
pull_requests: +18945
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19611

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23082>
_______________________________________

From report at bugs.python.org  Sun Apr 19 21:00:10 2020
From: report at bugs.python.org (jack1142)
Date: Mon, 20 Apr 2020 01:00:10 +0000
Subject: [issue37006] Add top level await statement support for doctest
In-Reply-To: <1558516850.14.0.4225480118.issue37006@roundup.psfhosted.org>
Message-ID: <1587344410.44.0.447240213433.issue37006@roundup.psfhosted.org>


Change by jack1142 <kuba.kuczys at gmail.com>:


----------
nosy: +jack1142

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37006>
_______________________________________

From report at bugs.python.org  Sun Apr 19 21:06:03 2020
From: report at bugs.python.org (Shantanu)
Date: Mon, 20 Apr 2020 01:06:03 +0000
Subject: [issue28002] ast.unparse can't roundtrip some f-strings
In-Reply-To: <1473268698.62.0.800338957351.issue28002@psf.upfronthosting.co.za>
Message-ID: <1587344763.67.0.697349820585.issue28002@roundup.psfhosted.org>


Change by Shantanu <hauntsaninja at gmail.com>:


----------
keywords: +patch
pull_requests: +18946
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19612

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28002>
_______________________________________

From report at bugs.python.org  Sun Apr 19 22:02:27 2020
From: report at bugs.python.org (Ned Deily)
Date: Mon, 20 Apr 2020 02:02:27 +0000
Subject: [issue40198] macOS Python builds from Python.org ignore
 DYLD_LIBRARY_PATH due to hardened runtime
In-Reply-To: <1586118049.02.0.786646499236.issue40198@roundup.psfhosted.org>
Message-ID: <1587348147.2.0.67662166553.issue40198@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

Thanks for the report. Yes, the choice of entitlements to request whith code hardening was somewhat arbitrary; we tried to keep them to a minimum.  I didn't anticipate that the DYLD_ env variables would be used much, sorry about that. Future python.org macOS installers will include that entitlement, starting with 2.7.18 (the final 2.7 release), 3.7.8, 3.8.3, and 3.9.0a6.

----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40198>
_______________________________________

From report at bugs.python.org  Mon Apr 20 01:19:45 2020
From: report at bugs.python.org (hai shi)
Date: Mon, 20 Apr 2020 05:19:45 +0000
Subject: =?utf-8?q?=5Bissue39849=5D_Compiler_warninig=3A_warning=3A_variable_?=
 =?utf-8?q?=E2=80=98res=E2=80=99_set_but_not_used_=5B-Wunused-but-set-vari?=
 =?utf-8?q?able=5D?=
In-Reply-To: <1583334504.92.0.978999288989.issue39849@roundup.psfhosted.org>
Message-ID: <1587359985.64.0.805159916596.issue39849@roundup.psfhosted.org>


Change by hai shi <shihai1991 at 126.com>:


----------
keywords: +patch
nosy: +shihai1991
nosy_count: 2.0 -> 3.0
pull_requests: +18947
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19615

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39849>
_______________________________________

From report at bugs.python.org  Mon Apr 20 01:23:58 2020
From: report at bugs.python.org (hai shi)
Date: Mon, 20 Apr 2020 05:23:58 +0000
Subject: =?utf-8?q?=5Bissue39849=5D_Compiler_warninig=3A_warning=3A_variable_?=
 =?utf-8?q?=E2=80=98res=E2=80=99_set_but_not_used_=5B-Wunused-but-set-vari?=
 =?utf-8?q?able=5D?=
In-Reply-To: <1583334504.92.0.978999288989.issue39849@roundup.psfhosted.org>
Message-ID: <1587360238.88.0.0468451082044.issue39849@roundup.psfhosted.org>


hai shi <shihai1991 at 126.com> added the comment:

I found this warning too(ps: my gcc is 9.3.0 ;)
Can we add a inner macro like `_unused(var) (void) var`? 
Hi, serhiy, can you give us some advice?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39849>
_______________________________________

From report at bugs.python.org  Mon Apr 20 01:44:23 2020
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 20 Apr 2020 05:44:23 +0000
Subject: [issue40275] test.support has way too many imports
In-Reply-To: <1586816691.28.0.874442798421.issue40275@roundup.psfhosted.org>
Message-ID: <1587361463.95.0.210760685909.issue40275@roundup.psfhosted.org>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

What is the practical impact on the time taken for test runs? How much does the total time for a test run reduce as a result of refactoring test.support to minimise imports?

----------
nosy: +vinay.sajip

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40275>
_______________________________________

From report at bugs.python.org  Mon Apr 20 01:47:26 2020
From: report at bugs.python.org (Tigran)
Date: Mon, 20 Apr 2020 05:47:26 +0000
Subject: [issue36054] On Linux,
 os.count() should read cgroup cpu.shares and cpu.cfs (CPU count
 inside docker container)
In-Reply-To: <1550681782.39.0.211832814896.issue36054@roundup.psfhosted.org>
Message-ID: <1587361646.71.0.852094226019.issue36054@roundup.psfhosted.org>


Tigran <nargitinthenight at gmail.com> added the comment:

Do we have any news about this?

----------
nosy: +nargit

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36054>
_______________________________________

From report at bugs.python.org  Mon Apr 20 03:45:56 2020
From: report at bugs.python.org (hongweipeng)
Date: Mon, 20 Apr 2020 07:45:56 +0000
Subject: [issue39942] Making instance of `TypeVar` fails because of missing
 `__name__`
In-Reply-To: <1583971911.89.0.874740392795.issue39942@roundup.psfhosted.org>
Message-ID: <1587368756.82.0.523836832496.issue39942@roundup.psfhosted.org>


Change by hongweipeng <hongweichen8888 at sina.com>:


----------
keywords: +patch
nosy: +hongweipeng
nosy_count: 1.0 -> 2.0
pull_requests: +18948
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19616

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39942>
_______________________________________

From report at bugs.python.org  Mon Apr 20 04:33:48 2020
From: report at bugs.python.org (Petr Viktorin)
Date: Mon, 20 Apr 2020 08:33:48 +0000
Subject: [issue34037] asyncio: BaseEventLoop.close() shutdowns the executor
 without waiting causing leak of dangling threads
In-Reply-To: <1530658646.63.0.56676864532.issue34037@psf.upfronthosting.co.za>
Message-ID: <1587371628.59.0.954120402999.issue34037@roundup.psfhosted.org>


Petr Viktorin <encukou at gmail.com> added the comment:

I got a report from a library that ties together asyncio and some other async libraries, getting errors like this:

tests/test_taskgroups.py:60: in test_run_natively
    module.run(testfunc())
/usr/lib64/python3.9/asyncio/runners.py:48: in run
    loop.run_until_complete(loop.shutdown_default_executor())
uvloop/loop.pyx:1451: in uvloop.loop.Loop.run_until_complete
    ???
/usr/lib64/python3.9/asyncio/events.py:254: in shutdown_default_executor
    raise NotImplementedError
E   NotImplementedError

(more at: https://bugzilla.redhat.com/show_bug.cgi?id=1817681#c1 )

I'm not all that familiar with asyncio, but it seems to me that all event loops inherited from BaseEventLoop must be updated to implement this new method to correctly work with run() in Python 3.9. Is that right? If it is, this needs at least a much more prominent What's New entry. Or the hard NotImplementedError should turn into a warning.

----------
nosy: +petr.viktorin

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34037>
_______________________________________

From report at bugs.python.org  Mon Apr 20 04:40:25 2020
From: report at bugs.python.org (Natanael Copa)
Date: Mon, 20 Apr 2020 08:40:25 +0000
Subject: [issue21622] ctypes.util incorrectly fails for libraries without
 DT_SONAME
In-Reply-To: <1401593302.24.0.994822187168.issue21622@psf.upfronthosting.co.za>
Message-ID: <1587372025.32.0.727035843937.issue21622@roundup.psfhosted.org>


Natanael Copa <ncopa at alpinelinux.org> added the comment:

I create a PR for this issue.

It would be nice to have it reviewed.
https://github.com/python/cpython/pull/18380

Thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21622>
_______________________________________

From report at bugs.python.org  Mon Apr 20 04:49:52 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 20 Apr 2020 08:49:52 +0000
Subject: [issue40332] RegEx for numbers in documentation (easy fix - solution
 provided)
In-Reply-To: <1587326483.24.0.84255521064.issue40332@roundup.psfhosted.org>
Message-ID: <1587372592.68.0.394994037238.issue40332@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

As you say, isn't this just a personal preference?

Is there an objective reason to prefer something that accepts ".5" and rejects "3." over something that rejects ".5" and accepts "3."?

The exact form of numbers accepted seems to be to be irrelevant to the point of the example; I'm not sure I see much value in changing it.

----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40332>
_______________________________________

From report at bugs.python.org  Mon Apr 20 05:24:00 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 20 Apr 2020 09:24:00 +0000
Subject: [issue40275] test.support has way too many imports
In-Reply-To: <1586816691.28.0.874442798421.issue40275@roundup.psfhosted.org>
Message-ID: <1587374640.49.0.544440359437.issue40275@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Reducing the import time is not a goal, it is just a measurable side effect. The goal is to reduce the number of imported modules unneeded for the particular test. Importing every module can have side effects which affects the tested behavior. It would be nice to minimize it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40275>
_______________________________________

From report at bugs.python.org  Mon Apr 20 05:59:36 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 20 Apr 2020 09:59:36 +0000
Subject: [issue40332] RegEx for numbers in documentation (easy fix - solution
 provided)
In-Reply-To: <1587326483.24.0.84255521064.issue40332@roundup.psfhosted.org>
Message-ID: <1587376776.04.0.911212290622.issue40332@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I concur with Mark. It is just an example. The regular expression which would support all possible forms of numbers (including exponent, underscores, non-decimal numbers) would be more complex and would distract from the main goal of the example.

----------
nosy: +serhiy.storchaka
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40332>
_______________________________________

From report at bugs.python.org  Mon Apr 20 06:27:51 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 20 Apr 2020 10:27:51 +0000
Subject: [issue40335] Regression in multiline SyntaxError offsets
In-Reply-To: <1587332455.2.0.964330224308.issue40335@roundup.psfhosted.org>
Message-ID: <1587378471.92.0.126302073898.issue40335@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
keywords: +patch
pull_requests: +18949
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19619

_______________________________________
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: [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 07:29:32 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 20 Apr 2020 11:29:32 +0000
Subject: [issue40336] Refactor typing._SpecialForm
In-Reply-To: <1587382077.76.0.465264579833.issue40336@roundup.psfhosted.org>
Message-ID: <1587382172.7.0.0440844304675.issue40336@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch
pull_requests: +18950
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19620

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40336>
_______________________________________

From report at bugs.python.org  Mon Apr 20 08:44:14 2020
From: report at bugs.python.org (Mark Shannon)
Date: Mon, 20 Apr 2020 12:44:14 +0000
Subject: [issue40255] Fixing Copy on Writes from reference counting
In-Reply-To: <1586619621.82.0.553262088399.issue40255@roundup.psfhosted.org>
Message-ID: <1587386654.65.0.119468905341.issue40255@roundup.psfhosted.org>


Mark Shannon <mark at hotpy.org> added the comment:

Eddie,
How did you compare the branching vs. non-branching implementations?  I have read the code in the PR. What is the non-branching version that you used to compare it against?

Why not use the sign bit as the immortal bit? It simplifies the test considerably, making it faster, and doesn't need any assembly code.

Are you suggesting that making a set of common objects immortal will make things faster? Have you tested it?
(I would expect that the negative impact on branch predictability would easily outweigh the cost of the memory write (A guaranteed L1 hit).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40255>
_______________________________________

From report at bugs.python.org  Mon Apr 20 08:50:06 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 20 Apr 2020 12:50:06 +0000
Subject: [issue39983] test.regrtest: test marked as failed (env changed),
 but no warning: test_multiprocessing_forkserver
In-Reply-To: <1584397271.26.0.591205335177.issue39983@roundup.psfhosted.org>
Message-ID: <1587387006.02.0.0882103936907.issue39983@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Another example: test_asyncio on AMD64 Fedora Stable Clang 3.x
https://buildbot.python.org/all/#/builders/226/builds/630

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39983>
_______________________________________

From report at bugs.python.org  Mon Apr 20 08:52:05 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 20 Apr 2020 12:52:05 +0000
Subject: [issue17986] Alternative async subprocesses (pep 3145)
In-Reply-To: <1368652199.21.0.577907802925.issue17986@psf.upfronthosting.co.za>
Message-ID: <1587387125.08.0.0212325838967.issue17986@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Well, this issue is basically inactive for 5 years. It doesn't sound like a common feature request. I close it.

----------
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17986>
_______________________________________

From report at bugs.python.org  Mon Apr 20 08:59:25 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 20 Apr 2020 12:59:25 +0000
Subject: [issue34037] asyncio: BaseEventLoop.close() shutdowns the executor
 without waiting causing leak of dangling threads
In-Reply-To: <1530658646.63.0.56676864532.issue34037@psf.upfronthosting.co.za>
Message-ID: <1587387565.25.0.00532941783611.issue34037@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I reopen the issue.

> /usr/lib64/python3.9/asyncio/events.py:254: in shutdown_default_executor
>     raise NotImplementedError

That means that the project (python-anyio) implements its own event loop which inherits from AbstractEventLoop, it doesn't use BaseEventLoop which implements shutdown_default_executor().

AbstractEventLoop documentation says:

https://docs.python.org/dev/library/asyncio-eventloop.html#asyncio.AbstractEventLoop

"The Event Loop Methods section lists all methods that an alternative implementation of AbstractEventLoop should have defined."

It points to the following documentation which lists shutdown_asyncgens():

It points to https://docs.python.org/dev/library/asyncio-eventloop.html#asyncio-event-loop


> I'm not all that familiar with asyncio, but it seems to me that all event loops inherited from BaseEventLoop must be updated to implement this new method to correctly work with run() in Python 3.9. Is that right?

Yes

> If it is, this needs at least a much more prominent What's New entry. Or the hard NotImplementedError should turn into a warning.

Raising NotImplementedError is a deliberate design choice.

Documentation the new requirement in the following section sounds like a good idea.

https://docs.python.org/dev/whatsnew/3.9.html#changes-in-the-python-api

Kyle: Can you please add a short sentence there to document the new requirement?

----------
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34037>
_______________________________________

From report at bugs.python.org  Mon Apr 20 09:02:37 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 20 Apr 2020 13:02:37 +0000
Subject: [issue40284] Add mapping methods to types.SimpleNamespace
In-Reply-To: <1586898649.19.0.221456344176.issue40284@roundup.psfhosted.org>
Message-ID: <1587387757.91.0.983542320133.issue40284@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Raymond started a thread on python-dev:
https://mail.python.org/archives/list/python-dev at python.org/message/JOMND56PJGRN7FQQLLCWONE5Z7R2EKXW/

It seems like most core developers are against modifying types.SimpleNamespace, the trend is more about adding a different class.

About a different class, so far, I see no consensus on an API. I suggest to close this issue (which is about types.SimpleNamespace) and continue the discussion on python-dev.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40284>
_______________________________________

From report at bugs.python.org  Mon Apr 20 09:06:16 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 20 Apr 2020 13:06:16 +0000
Subject: [issue40275] test.support has way too many imports
In-Reply-To: <1586816691.28.0.874442798421.issue40275@roundup.psfhosted.org>
Message-ID: <1587387976.3.0.416880534066.issue40275@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Vinay Sajip: "What is the practical impact on the time taken for test runs?"

My first concern is that our "unit tests" are not "unit" anymore. test_threading should be restricted to test the threading module: it should not test "indirectly" the logging module.

If someone wants to test how logging behaves on fork, test_logging should get a new test. (I didn't check if it already has such test.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40275>
_______________________________________

From report at bugs.python.org  Mon Apr 20 09:20:49 2020
From: report at bugs.python.org (Steve Dower)
Date: Mon, 20 Apr 2020 13:20:49 +0000
Subject: [issue38905] venv python reports wrong sys.executable in a subprocess
 on Windows
In-Reply-To: <1574583460.3.0.94905817038.issue38905@roundup.psfhosted.org>
Message-ID: <1587388849.85.0.340289459051.issue38905@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

I posted a workaround right above your post for when you want to resolve executables against PATH instead of using Windows's normal rules.

I'm not sure we reached any good approach for launching sys.executable in a venv and automatically bypassing the redirector.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38905>
_______________________________________

From report at bugs.python.org  Mon Apr 20 09:33:01 2020
From: report at bugs.python.org (Steve Dower)
Date: Mon, 20 Apr 2020 13:33:01 +0000
Subject: [issue40255] Fixing Copy on Writes from reference counting
In-Reply-To: <1586619621.82.0.553262088399.issue40255@roundup.psfhosted.org>
Message-ID: <1587389581.51.0.25436145899.issue40255@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

> I would expect that the negative impact on branch predictability would easily outweigh the cost of the memory write (A guaranteed L1 hit)

If that were true then Spectre and Meltdown wouldn't have been so interesting :)

Pipelining processors are going to speculatively execute both paths, and will skip the write much more quickly than by doing it, and meanwhile nobody should have tried to read the value so it hasn't had to block for that path. I'm not aware of any that detect no-op writes and skip synchronising across cores - the dirty bit of the cache line is just set unconditionally.

Benchmarking already showed that the branching version is faster. It's possible that "refcount += (refcount & IMMORTAL) ? 0 : 1" could generate different code (should be mov,test,lea,cmovz rather than mov,and,add,mov or mov,and,jz,add,mov), but it's totally reasonable for a branch to be faster than unconditionally modifying memory.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40255>
_______________________________________

From report at bugs.python.org  Mon Apr 20 09:35:02 2020
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 20 Apr 2020 13:35:02 +0000
Subject: [issue40255] Fixing Copy on Writes from reference counting
In-Reply-To: <1586619621.82.0.553262088399.issue40255@roundup.psfhosted.org>
Message-ID: <1587389702.67.0.808585417805.issue40255@roundup.psfhosted.org>


Antoine Pitrou <solipsis at pitrou.net> added the comment:

> Benchmarking already showed that the branching version is faster.

But micro-benchmarks may tell you things which are not true in the real-world (for example an easily-predicted branch).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40255>
_______________________________________

From report at bugs.python.org  Mon Apr 20 09:35:16 2020
From: report at bugs.python.org (Steve Dower)
Date: Mon, 20 Apr 2020 13:35:16 +0000
Subject: [issue40260] modulefinder traceback regression starting on Windows
In-Reply-To: <1586680620.99.0.514402715757.issue40260@roundup.psfhosted.org>
Message-ID: <1587389716.95.0.426139589438.issue40260@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Thanks! I deleted the NEWS file (we've already got one for this issue in this release) and skipped the check instead. Once CI passes, I'll merge it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40260>
_______________________________________

From report at bugs.python.org  Mon Apr 20 09:40:36 2020
From: report at bugs.python.org (Steve Dower)
Date: Mon, 20 Apr 2020 13:40:36 +0000
Subject: [issue40255] Fixing Copy on Writes from reference counting
In-Reply-To: <1586619621.82.0.553262088399.issue40255@roundup.psfhosted.org>
Message-ID: <1587390036.26.0.141955258043.issue40255@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

> But micro-benchmarks may tell you things which are not true in the real-world (for example an easily-predicted branch)

This is true, though this branch should be more easily predictable because INCREF/DECREF are inlined. If there were only one function doing the branch it'd be different.

Wouldn't even surprise me if PGO made different optimisations to this in certain functions. Anything that normally operates on a code object, for example, is almost always going to take the branch when everything is imported early and before immortalisation.

We also have the real world app that is Instagram. If they say that this has shown an improvement in their app, I'm inclined to believe that it's not reliant on a microbenchmark (other controlled circumstances, sure, but not a microbenchmark ;) ).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40255>
_______________________________________

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: [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:17:55 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 20 Apr 2020 14:17:55 +0000
Subject: [issue40337] builtins.RuntimeError: Caught RuntimeError in pin memory
 thread for device 0.
In-Reply-To: <1587391255.49.0.649010801229.issue40337@roundup.psfhosted.org>
Message-ID: <1587392275.18.0.898605007686.issue40337@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

This appears to be a problem in a third-party library: torch.

You didn't include any code example that triggers the problem. Without some way to duplicate this issue, there's not much we can do about it.

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40337>
_______________________________________

From report at bugs.python.org  Mon Apr 20 10:29:42 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 20 Apr 2020 14:29:42 +0000
Subject: [issue40333] Request for multi-phase initialization API to run code
 after importlib init
In-Reply-To: <1587327033.84.0.66503294203.issue40333@roundup.psfhosted.org>
Message-ID: <1587392982.5.0.503077885362.issue40333@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

The current workaround is to use PyConfig._init_main=0, call Py_InitializeFromConfig(), tune Python, and then call _Py_InitializeMain() to finish the "main" initialization:

https://docs.python.org/dev/c-api/init_config.html#multi-phase-initialization-private-provisional-api

You can execute code between init_importlib() and init_importlib_external().

I understand that it's not enough for you. As I wrote, it's a workaround.

--

Well, your use case is to fully control the "Python Path Configuration":
https://docs.python.org/dev/c-api/init_config.html#path-configuration

This part was completely put aside in PEP 587 on purpose (to be able to put the done part in Python 3.8), but it's part of PEP 432.

It was proposed to rewrite getpath.c and getpathc.c in pure Python to let embedders to fully override this code with their own Python implementation. But nobody is available to implement this feature.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40333>
_______________________________________

From report at bugs.python.org  Mon Apr 20 10:30:06 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 20 Apr 2020 14:30:06 +0000
Subject: [issue40333] Request for multi-phase initialization API to run code
 after importlib init
In-Reply-To: <1587327033.84.0.66503294203.issue40333@roundup.psfhosted.org>
Message-ID: <1587393006.76.0.538092394638.issue40333@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy: +eric.snow, ncoghlan, steve.dower

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40333>
_______________________________________

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: [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 10:46:13 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 20 Apr 2020 14:46:13 +0000
Subject: [issue40338] [Security] urllib and anti-slash (\) in the hostname
In-Reply-To: <1587393818.69.0.0669874545699.issue40338@roundup.psfhosted.org>
Message-ID: <1587393973.44.0.749605052245.issue40338@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

(The first message is basically David's email rephrased. Here is my reply ;-))

> This could present issues if server-side checks are used by applications to validate a URLs authority.

Which kind of application would be affected by this vulnerability?

It's unclear to me if urllib should be modified to explicitly reject \ in netloc, or if only third-party code should pay attention to this corner case (potential vulnerability).


The urllib module has _parse_proxy() and HTTPPasswordMgr.reduce_uri() code which use an "authority" variable.

Example:
---
from urllib.parse import urlsplit, _splitport, _splittype, _splituser,
_splitpasswd

def _parse_proxy(proxy):
    """Return (scheme, user, password, host/port) given a URL or an authority.

    If a URL is supplied, it must have an authority (host:port) component.
    According to RFC 3986, having an authority component means the URL must
    have two slashes after the scheme.
    """
    scheme, r_scheme = _splittype(proxy)
    if not r_scheme.startswith("/"):
        # authority
        scheme = None
        authority = proxy
    else:
        # URL
        if not r_scheme.startswith("//"):
            raise ValueError("proxy URL with no authority: %r" % proxy)
        # We have an authority, so for RFC 3986-compliant URLs (by ss 3.
        # and 3.3.), path is empty or starts with '/'
        end = r_scheme.find("/", 2)
        if end == -1:
            end = None
        authority = r_scheme[2:end]
    userinfo, hostport = _splituser(authority)
    if userinfo is not None:
        user, password = _splitpasswd(userinfo)
    else:
        user = password = None
    return scheme, user, password, hostport


def reduce_uri(uri, default_port=True):
    """Accept authority or URI and extract only the authority and path."""
    # note HTTP URLs do not have a userinfo component
    parts = urlsplit(uri)
    if parts[1]:
        # URI
        scheme = parts[0]
        authority = parts[1]
        path = parts[2] or '/'
    else:
        # host or host:port
        scheme = None
        authority = uri
        path = '/'
    host, port = _splitport(authority)
    if default_port and port is None and scheme is not None:
        dport = {"http": 80,
                 "https": 443,
                 }.get(scheme)
        if dport is not None:
            authority = "%s:%d" % (host, dport)
    return authority, path

def test(uri):
    print(f"{uri} => reduce_uri: {reduce_uri(uri)}")
    print(f"{uri} => _parse_proxy: {_parse_proxy(uri)}")

test(r"https://www.example.com")
test(r"https://user at www.example.com")
test(r"https://xdavidhu.me\test.corp.google.com")
test(r"https://user:password at xdavidhu.me\test.corp.google.com")
---

Output on Python 3.9:
---
https://www.example.com => reduce_uri: ('www.example.com:443', '/')
https://www.example.com => _parse_proxy: ('https', None, None,
'www.example.com')
https://user at www.example.com => reduce_uri: ('user at www.example.com:443', '/')
https://user at www.example.com => _parse_proxy: ('https', 'user', None,
'www.example.com')
https://xdavidhu.me\test.corp.google.com => reduce_uri:
('xdavidhu.me\\test.corp.google.com:443', '/')
https://xdavidhu.me\test.corp.google.com => _parse_proxy: ('https',
None, None, 'xdavidhu.me\\test.corp.google.com')
https://user:password at xdavidhu.me\test.corp.google.com => reduce_uri:
('user:password at xdavidhu.me\\test.corp.google.com:443', '/')
https://user:password at xdavidhu.me\test.corp.google.com =>
_parse_proxy: ('https', 'user', 'password',
'xdavidhu.me\\test.corp.google.com')
---

It seems to behave as expected, no?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40338>
_______________________________________

From report at bugs.python.org  Mon Apr 20 10:50:44 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Mon, 20 Apr 2020 14:50:44 +0000
Subject: [issue37006] Add top level await statement support for doctest
In-Reply-To: <1558516850.14.0.4225480118.issue37006@roundup.psfhosted.org>
Message-ID: <1587394244.96.0.121963524578.issue37006@roundup.psfhosted.org>


Change by Batuhan Taskaya <batuhanosmantaskaya at gmail.com>:


----------
nosy: +BTaskaya
versions: +Python 3.9 -Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37006>
_______________________________________

From report at bugs.python.org  Mon Apr 20 10:54:56 2020
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 20 Apr 2020 14:54:56 +0000
Subject: [issue40255] Fixing Copy on Writes from reference counting
In-Reply-To: <1586619621.82.0.553262088399.issue40255@roundup.psfhosted.org>
Message-ID: <1587394496.9.0.267171379027.issue40255@roundup.psfhosted.org>


Antoine Pitrou <solipsis at pitrou.net> added the comment:

> We also have the real world app that is Instagram.

I don't think Instagram is a single app. What is Python used for at Instagram?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40255>
_______________________________________

From report at bugs.python.org  Mon Apr 20 10:58:35 2020
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Mon, 20 Apr 2020 14:58:35 +0000
Subject: [issue40255] Fixing Copy on Writes from reference counting
In-Reply-To: <1586619621.82.0.553262088399.issue40255@roundup.psfhosted.org>
Message-ID: <1587394715.34.0.177076188955.issue40255@roundup.psfhosted.org>


R?mi Lapeyre <remi.lapeyre at henki.fr> added the comment:

>> We also have the real world app that is Instagram.

> I don't think Instagram is a single app. What is Python used for at Instagram?

According to their engineering blog (https://instagram-engineering.com/static-analysis-at-scale-an-instagram-story-8f498ab71a0c):

> Our server app is a monolith, one big codebase of several million lines and a few thousand Django endpoints [1], all loaded up and served together. A few services have been split out of the monolith, but we don?t have any plans to aggressively break it up.

----------
nosy: +remi.lapeyre

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40255>
_______________________________________

From report at bugs.python.org  Mon Apr 20 10:58:50 2020
From: report at bugs.python.org (Steve Dower)
Date: Mon, 20 Apr 2020 14:58:50 +0000
Subject: [issue40260] modulefinder traceback regression starting on Windows
In-Reply-To: <1586680620.99.0.514402715757.issue40260@roundup.psfhosted.org>
Message-ID: <1587394730.19.0.150448177823.issue40260@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:


New changeset 9b0b5d2baebd0b6a545317200c313a6a7408731e by Barry in branch 'master':
bpo-40260: Revert breaking changes made in modulefinder (GH-19595)
https://github.com/python/cpython/commit/9b0b5d2baebd0b6a545317200c313a6a7408731e


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40260>
_______________________________________

From report at bugs.python.org  Mon Apr 20 10:59:05 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 20 Apr 2020 14:59:05 +0000
Subject: [issue40260] modulefinder traceback regression starting on Windows
In-Reply-To: <1586680620.99.0.514402715757.issue40260@roundup.psfhosted.org>
Message-ID: <1587394745.04.0.808841613388.issue40260@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +18951
pull_request: https://github.com/python/cpython/pull/19621

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40260>
_______________________________________

From report at bugs.python.org  Mon Apr 20 10:59:24 2020
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 20 Apr 2020 14:59:24 +0000
Subject: [issue40255] Fixing Copy on Writes from reference counting
In-Reply-To: <1586619621.82.0.553262088399.issue40255@roundup.psfhosted.org>
Message-ID: <1587394764.36.0.659050959183.issue40255@roundup.psfhosted.org>


Antoine Pitrou <solipsis at pitrou.net> added the comment:

Wow.  I see, thank you.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40255>
_______________________________________

From report at bugs.python.org  Mon Apr 20 11:04:26 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 20 Apr 2020 15:04:26 +0000
Subject: [issue39562] Asynchronous comprehensions don't work in asyncio REPL
In-Reply-To: <1580923705.71.0.29233909242.issue39562@roundup.psfhosted.org>
Message-ID: <1587395066.56.0.00466012559486.issue39562@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Is there an update of this *release blocker* issue? Should we revert the commit 9052f7a41b90f2d34011c8da68f9a4facebc8a97?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39562>
_______________________________________

From report at bugs.python.org  Mon Apr 20 11:06:04 2020
From: report at bugs.python.org (Chris Meyer)
Date: Mon, 20 Apr 2020 15:06:04 +0000
Subject: [issue39651] Exceptions raised by EventLoop.call_soon_threadsafe
In-Reply-To: <1581871318.96.0.350376923794.issue39651@roundup.psfhosted.org>
Message-ID: <1587395164.32.0.940616927026.issue39651@roundup.psfhosted.org>


Chris Meyer <cmeyer1969 at gmail.com> added the comment:

Is this related to bpo-39010 too?

----------
nosy: +cmeyer

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39651>
_______________________________________

From report at bugs.python.org  Mon Apr 20 11:07:40 2020
From: report at bugs.python.org (Chris Meyer)
Date: Mon, 20 Apr 2020 15:07:40 +0000
Subject: [issue37373] Configuration of windows event loop for libraries
In-Reply-To: <1561228405.39.0.674272094682.issue37373@roundup.psfhosted.org>
Message-ID: <1587395260.32.0.758157790692.issue37373@roundup.psfhosted.org>


Change by Chris Meyer <cmeyer1969 at gmail.com>:


----------
nosy: +cmeyer

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37373>
_______________________________________

From report at bugs.python.org  Mon Apr 20 11:07:59 2020
From: report at bugs.python.org (Chris Meyer)
Date: Mon, 20 Apr 2020 15:07:59 +0000
Subject: [issue39010] ProactorEventLoop raises unhandled ConnectionResetError
In-Reply-To: <1575924458.67.0.403977169674.issue39010@roundup.psfhosted.org>
Message-ID: <1587395279.62.0.147883358058.issue39010@roundup.psfhosted.org>


Change by Chris Meyer <cmeyer1969 at gmail.com>:


----------
nosy: +cmeyer

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39010>
_______________________________________

From report at bugs.python.org  Mon Apr 20 11:10:12 2020
From: report at bugs.python.org (Ben Darnell)
Date: Mon, 20 Apr 2020 15:10:12 +0000
Subject: [issue39651] Exceptions raised by EventLoop.call_soon_threadsafe
In-Reply-To: <1581871318.96.0.350376923794.issue39651@roundup.psfhosted.org>
Message-ID: <1587395412.74.0.458143053959.issue39651@roundup.psfhosted.org>


Ben Darnell <ben.darnell at gmail.com> added the comment:

No, this is unrelated to bpo-39010.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39651>
_______________________________________

From report at bugs.python.org  Mon Apr 20 11:10:19 2020
From: report at bugs.python.org (Chris Meyer)
Date: Mon, 20 Apr 2020 15:10:19 +0000
Subject: [issue34037] asyncio: BaseEventLoop.close() shutdowns the executor
 without waiting causing leak of dangling threads
In-Reply-To: <1530658646.63.0.56676864532.issue34037@psf.upfronthosting.co.za>
Message-ID: <1587395419.32.0.464822632965.issue34037@roundup.psfhosted.org>


Change by Chris Meyer <cmeyer1969 at gmail.com>:


----------
nosy: +cmeyer

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34037>
_______________________________________

From report at bugs.python.org  Mon Apr 20 11:13:30 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Mon, 20 Apr 2020 15:13:30 +0000
Subject: [issue39562] Asynchronous comprehensions don't work in asyncio REPL
In-Reply-To: <1580923705.71.0.29233909242.issue39562@roundup.psfhosted.org>
Message-ID: <1587395610.42.0.798276650079.issue39562@roundup.psfhosted.org>


Batuhan Taskaya <batuhanosmantaskaya at gmail.com> added the comment:

> Is there an update of this *release blocker* issue? Should we revert the commit 9052f7a41b90f2d34011c8da68f9a4facebc8a97?

I dont think we can gain much by reverting 9052f7a41b90f2d34011c8da68f9a4facebc8a97 because it doesn't introduce a new issue, it just adds "another" path to notice it. 

Test:
>>> await __import__('asyncio').sleep(1)

Expected (and the behavior of 3.6):

(.venv) [  6:09PM ]  [ isidentical at threeheadedgiant:~ ]
 $ python3.6 z.py       
**********************************************************************
File "doctest.txt", line 4, in doctest.txt
Failed example:
    await __import__('asyncio').sleep(1)
Exception raised:
    Traceback (most recent call last):
      File "/usr/lib/python3.6/doctest.py", line 1330, in __run
        compileflags, 1), test.globs)
      File "<doctest doctest.txt[0]>", line 1
        await __import__('asyncio').sleep(1)
                       ^
    SyntaxError: invalid syntax
**********************************************************************
1 items had failures:
   1 of   1 in doctest.txt
***Test Failed*** 1 failures.
result: TestResults(failed=1, attempted=1

Current master (+ reverted GH 18968):
(.venv) [  6:09PM ]  [ isidentical at threeheadedgiant:~ ]
 $ ./cpython/python z.py
/home/isidentical/cpython/Lib/doctest.py:1336: RuntimeWarning: coroutine '<module>' was never awaited
  exec(compile(example.source, filename, "single",
RuntimeWarning: Enable tracemalloc to get the object allocation traceback
result: TestResults(failed=0, attempted=1)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39562>
_______________________________________

From report at bugs.python.org  Mon Apr 20 11:15:24 2020
From: report at bugs.python.org (hai shi)
Date: Mon, 20 Apr 2020 15:15:24 +0000
Subject: =?utf-8?q?=5Bissue39849=5D_Compiler_warninig=3A_warning=3A_variable_?=
 =?utf-8?q?=E2=80=98res=E2=80=99_set_but_not_used_=5B-Wunused-but-set-vari?=
 =?utf-8?q?able=5D?=
In-Reply-To: <1583334504.92.0.978999288989.issue39849@roundup.psfhosted.org>
Message-ID: <1587395724.4.0.445625185377.issue39849@roundup.psfhosted.org>


Change by hai shi <shihai1991 at 126.com>:


----------
pull_requests: +18952
pull_request: https://github.com/python/cpython/pull/19623

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39849>
_______________________________________

From report at bugs.python.org  Mon Apr 20 11:18:18 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 20 Apr 2020 15:18:18 +0000
Subject: [issue40260] modulefinder traceback regression starting on Windows
In-Reply-To: <1586680620.99.0.514402715757.issue40260@roundup.psfhosted.org>
Message-ID: <1587395898.78.0.497376312235.issue40260@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 81de3c225774179cdc82a1733a64e4a876ff02b5 by Miss Islington (bot) in branch '3.8':
bpo-40260: Revert breaking changes made in modulefinder (GH-19595)
https://github.com/python/cpython/commit/81de3c225774179cdc82a1733a64e4a876ff02b5


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40260>
_______________________________________

From report at bugs.python.org  Mon Apr 20 11:18:25 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Mon, 20 Apr 2020 15:18:25 +0000
Subject: [issue39562] Asynchronous comprehensions don't work in asyncio REPL
In-Reply-To: <1580923705.71.0.29233909242.issue39562@roundup.psfhosted.org>
Message-ID: <1587395905.65.0.777510839912.issue39562@roundup.psfhosted.org>


Batuhan Taskaya <batuhanosmantaskaya at gmail.com> added the comment:

GH 19230:
(.venv) [  6:17PM ]  [ isidentical at threeheadedgiant:~ ]
 $ ./cpython/python z.py
**********************************************************************
File "/home/isidentical/doctest.txt", line 4, in doctest.txt
Failed example:
    await __import__('asyncio').sleep(1)
Exception raised:
    Traceback (most recent call last):
      File "/home/isidentical/cpython/Lib/doctest.py", line 1336, in __run
        exec(compile(example.source, filename, "single",
      File "<doctest doctest.txt[0]>", line 1
    SyntaxError: 'await' outside function
**********************************************************************
1 items had failures:
   1 of   1 in doctest.txt
***Test Failed*** 1 failures.
result: TestResults(failed=1, attempted=1)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39562>
_______________________________________

From report at bugs.python.org  Mon Apr 20 11:21:37 2020
From: report at bugs.python.org (Allan Feldman)
Date: Mon, 20 Apr 2020 15:21:37 +0000
Subject: [issue40312] Weakref callbacks running before finalizers in GC
 collection
In-Reply-To: <1587153160.93.0.26793085181.issue40312@roundup.psfhosted.org>
Message-ID: <1587396097.98.0.0794398438186.issue40312@roundup.psfhosted.org>


Allan Feldman <allan.d.feldman at gmail.com> added the comment:

Thanks for the explanation! I agree that "about to be finalized" is unclear in the docs :)

I still believe that having different behavior for the ordering of finalizers versus weakref callbacks depending on whether the path is through gc versus reference counting is a bug.

The callback should be able to assume that when it's running, the referent is actually dead. The execution of a weakref callback in our case results in items being dropped from a WeakValueDictionary prematurely (the object is still referenced, accessible, and alive at the time the weakref callback runs).

I've attached a patch that would cause weakref callbacks to run consistently after finalizers. With the patch applied, all tests in cpython appear to pass, but the code examples above now work consistently.

----------
keywords: +patch
Added file: https://bugs.python.org/file49076/0001-Run-finalizers-before-invoking-weakref-callbacks.patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40312>
_______________________________________

From report at bugs.python.org  Mon Apr 20 11:29:51 2020
From: report at bugs.python.org (Allan Feldman)
Date: Mon, 20 Apr 2020 15:29:51 +0000
Subject: [issue40312] Weakref callbacks running before finalizers in GC
 collection
In-Reply-To: <1587153160.93.0.26793085181.issue40312@roundup.psfhosted.org>
Message-ID: <1587396591.62.0.770292568421.issue40312@roundup.psfhosted.org>


Allan Feldman <allan.d.feldman at gmail.com> added the comment:

Also I just noticed this statement:

> In current CPython, for your ForeverObject(False), `del o` does not make the object trash "for real".  __del__ runs immediately (due to deterministic, synchronous reference counting) and resurrects it.  That cuts off the "about to have its memory destroyed and recycled" part, so the callback doesn't run.

The problem is the callback _does_ run even though the object is resurrected! :)

(Only if going through gc)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40312>
_______________________________________

From report at bugs.python.org  Mon Apr 20 11:31:02 2020
From: report at bugs.python.org (hai shi)
Date: Mon, 20 Apr 2020 15:31:02 +0000
Subject: [issue40338] [Security] urllib and anti-slash (\) in the hostname
In-Reply-To: <1587393818.69.0.0669874545699.issue40338@roundup.psfhosted.org>
Message-ID: <1587396662.46.0.339032151602.issue40338@roundup.psfhosted.org>


Change by hai shi <shihai1991 at 126.com>:


----------
nosy: +shihai1991

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40338>
_______________________________________

From report at bugs.python.org  Mon Apr 20 11:46:39 2020
From: report at bugs.python.org (Ned Deily)
Date: Mon, 20 Apr 2020 15:46:39 +0000
Subject: [issue23117] Properly codesign Mac python 2.7.9.pkg so it can work
 thru OS X firewall
In-Reply-To: <1419634984.21.0.96201874002.issue23117@psf.upfronthosting.co.za>
Message-ID: <1587397599.5.0.178351200657.issue23117@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

Thanks to the additional requirements of Gatekeeper in macOS 10.15 Catalina, the binaries included in current python.org installers for macOS are now codesigned as of 3.8.2, 3.7.7, and 2.7.18.

----------
resolution:  -> fixed
stage: needs patch -> resolved
status: open -> closed
versions: +Python 3.7, Python 3.8, Python 3.9 -Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23117>
_______________________________________

From report at bugs.python.org  Mon Apr 20 11:57:54 2020
From: report at bugs.python.org (Ned Deily)
Date: Mon, 20 Apr 2020 15:57:54 +0000
Subject: [issue36890] python-3.7.3-macosx10.6.pkg verification error on macOS
 10.6 Snow Leopard
In-Reply-To: <1557598786.16.0.639636022435.issue36890@roundup.psfhosted.org>
Message-ID: <1587398274.95.0.407192049917.issue36890@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

Beginning in 2020, we have stopped providing the 10.6+ installer variant for macOS since all evidence that we have is that it was used very little and there are a grower number of problems with trying to use it on very old systems, as evidenced in this issue.  Since there has been no feedback yet about not providing the 10.6+ installer variant, I am closing this issue as not to be fixed. (We continue to provide the 10.9 64-bit-only installer variant.)  By the way, this does not mean we are intentionally removing or breaking support for building and running on 10.6 systems.  It's just that we are no longer providing pre-built binaries for them.

----------
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36890>
_______________________________________

From report at bugs.python.org  Mon Apr 20 11:59:33 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 20 Apr 2020 15:59:33 +0000
Subject: [issue40312] Weakref callbacks running before finalizers in GC
 collection
In-Reply-To: <1587153160.93.0.26793085181.issue40312@roundup.psfhosted.org>
Message-ID: <1587398373.16.0.74941403436.issue40312@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

I think this is a good summary of what you are referring to:

>>> import gc, weakref
>>> class Lazarus:
...    def __del__(self):
...       global x
...       x = self
...
>>> def callback(*args):
...     print("DEAD")
...

# No gc dead:

>>> x = None
>>> a = Lazarus()
>>> w = weakref.ref(a, callback)
>>> del a # Notice that the callback has not been executed
>>> del x
DEAD

# Gc code:

>>> a = Lazarus()
>>> x = None
>>> cycle = []
>>> cycle.append(cycle)
>>> cycle.append(a)
>>> w = weakref.ref(a, callback)
>>> del a,cycle
>>> gc.collect()
DEAD
>>> x. #The callback has executed but the variable is still alive
<__main__.Lazarus object at 0x1020e9910>


The "problem" is that when going through the gc, the callback is executed when the object is resurrected but going through normal refcount the callback is executed only when the object dies.

Notice that in both cases the fundamental property still holds: the callback is executed *once*. What you are discussing now is a matter of *when*. 

Not sure if we want to homogenize both code paths, but changing the one that goes through the GC is going to be challenging to say the least because as Tim mentioned, the weakrefs semantics are *very* delicate.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40312>
_______________________________________

From report at bugs.python.org  Mon Apr 20 12:05:44 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 20 Apr 2020 16:05:44 +0000
Subject: [issue39562] Asynchronous comprehensions don't work in asyncio REPL
In-Reply-To: <1580923705.71.0.29233909242.issue39562@roundup.psfhosted.org>
Message-ID: <1587398744.52.0.264840094664.issue39562@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Either the regression should be fixed, or the commits which introduced the regression should be reverted.

I'm talking about python-gmpy2 doctest which pass on Python 3.8: msg365311.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39562>
_______________________________________

From report at bugs.python.org  Mon Apr 20 12:06:02 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 20 Apr 2020 16:06:02 +0000
Subject: [issue40312] Weakref callbacks running before finalizers in GC
 collection
In-Reply-To: <1587153160.93.0.26793085181.issue40312@roundup.psfhosted.org>
Message-ID: <1587398762.52.0.711281838248.issue40312@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

One thing we could do is call the weakref callbacks *after* we call `finalize_garbage` and only on the "final_unreachable" set (the objects that do not resurrect). Notice that doing this still has one difference: the callback will be executed AFTER the finalizer while in the normal refcount path is executed BEFORE the finalizer.

I have not given enough thought to the correctness of doing this but my gut feeling tells me something can go wrong if we do that. What do you think about this path, Tim? 

Here is the diff I am refering to for clarity:

diff --git a/Modules/gcmodule.c b/Modules/gcmodule.c
index 5727820f09..498ff927ab 100644
--- a/Modules/gcmodule.c
+++ b/Modules/gcmodule.c
@@ -1252,9 +1252,6 @@ collect(PyThreadState *tstate, int generation,
         }
     }

-    /* Clear weakrefs and invoke callbacks as necessary. */
-    m += handle_weakrefs(&unreachable, old);
-
     validate_list(old, collecting_clear_unreachable_clear);
     validate_list(&unreachable, collecting_set_unreachable_clear);

@@ -1267,6 +1264,9 @@ collect(PyThreadState *tstate, int generation,
     PyGC_Head final_unreachable;
     handle_resurrected_objects(&unreachable, &final_unreachable, old);

+    /* Clear weakrefs and invoke callbacks as necessary. */
+    m += handle_weakrefs(&final_unreachable, old);
+
     /* Call tp_clear on objects in the final_unreachable set.  This will cause
     * the reference cycles to be broken.  It may also cause some objects
     * in finalizers to be freed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40312>
_______________________________________

From report at bugs.python.org  Mon Apr 20 12:08:50 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 20 Apr 2020 16:08:50 +0000
Subject: [issue39562] Asynchronous comprehensions don't work in asyncio REPL
In-Reply-To: <1580923705.71.0.29233909242.issue39562@roundup.psfhosted.org>
Message-ID: <1587398930.88.0.308223849708.issue39562@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

> Either the regression should be fixed, or the commits which introduced the regression should be reverted.

If you do that we will have now two problems:

* The asyncio repr will not work correctly.
* The flags in compile still have a clash.

The solution is to merge https://github.com/python/cpython/pull/19230 or some version of it, which should fix the issue in  python-gmpy2 doctest .

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39562>
_______________________________________

From report at bugs.python.org  Mon Apr 20 12:13:58 2020
From: report at bugs.python.org (Steve Dower)
Date: Mon, 20 Apr 2020 16:13:58 +0000
Subject: [issue40260] modulefinder traceback regression starting on Windows
In-Reply-To: <1586680620.99.0.514402715757.issue40260@roundup.psfhosted.org>
Message-ID: <1587399238.12.0.249287871922.issue40260@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40260>
_______________________________________

From report at bugs.python.org  Mon Apr 20 12:17:43 2020
From: report at bugs.python.org (Mark Shannon)
Date: Mon, 20 Apr 2020 16:17:43 +0000
Subject: [issue40255] Fixing Copy on Writes from reference counting
In-Reply-To: <1587389581.51.0.25436145899.issue40255@roundup.psfhosted.org>
Message-ID: <36574c4c-c682-50ae-6adc-e5838d328f84@hotpy.org>


Mark Shannon <mark at hotpy.org> added the comment:

On 20/04/2020 2:33 pm, Steve Dower wrote:
> 
> Steve Dower <steve.dower at python.org> added the comment:
> 
>> I would expect that the negative impact on branch predictability would easily outweigh the cost of the memory write (A guaranteed L1 hit)
> 
> If that were true then Spectre and Meltdown wouldn't have been so interesting :)

I really don't follow your logic here.

> 
> Pipelining processors are going to speculatively execute both paths, and will skip the write much more quickly than by doing it, and meanwhile nobody should have tried to read the value so it hasn't had to block for that path. I'm not aware of any that detect no-op writes and skip synchronising across cores - the dirty bit of the cache line is just set unconditionally.

Processors only execute the one path, speculatively or otherwise, that's 
why branch prediction is so important.
(And is important for the Spectre attack. If what you said were true, 
the Spectre attack wouldn't need to pre-bias the branch predictor.)
I'm assuming a modern Intel processor.

> 
> Benchmarking already showed that the branching version is faster. It's possible that "refcount += (refcount & IMMORTAL) ? 0 : 1" could generate different code (should be mov,test,lea,cmovz rather than mov,and,add,mov or mov,and,jz,add,mov), but it's totally reasonable for a branch to be faster than unconditionally modifying memory.

It hasn't been shown that it is faster. I'm not claiming that it isn't, 
just that I haven't seen the evidence.

> 
> ----------
> 
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue40255>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40255>
_______________________________________

From report at bugs.python.org  Mon Apr 20 12:32:36 2020
From: report at bugs.python.org (Tim Peters)
Date: Mon, 20 Apr 2020 16:32:36 +0000
Subject: [issue40312] Weakref callbacks running before finalizers in GC
 collection
In-Reply-To: <1587153160.93.0.26793085181.issue40312@roundup.psfhosted.org>
Message-ID: <1587400356.26.0.685373569009.issue40312@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

Allan, we don't (at least not knowingly) write tests that rely on order of end-of-life actions, because the _language_ defines nothing about the order.  So you can permute the order and it's unlikely any standard tests would fail.

The only reason your example "works" outside of cyclic gc is because, as already noted, CPython (the implementation you're using, not Python the language) primarily relies on reference counting.  That guarantees __del__ is called first, but that's not a language guarantee, it's a consequence of reference counting invoking __del__ IMMEDIATELY upon the refcount falling to 0.  The _language_ not only doesn't guarantee that, it doesn't even guarantee that __del__ will ever be called.

For CPython (this implementation), it's important that we don't introduce gratuitous breakage of programs that are "working" because of implementation details.  How do you know that no program currently relies on the implementation detail that cyclic gc happens to run callbacks before finalizers now?  CPython has done that for many years, and I personally wouldn't risk breaking "working" programs by flipping that order now, not without truly compelling reason (example: stopping a segfault would be compelling).

Pablo, as above, I'm inclined to leave things alone unless we can "prove" no current code could possibly be relying (even by accident) on that gc currently runs callbacks before finalizers.  Which may be the case!  I don't know ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40312>
_______________________________________

From report at bugs.python.org  Mon Apr 20 12:33:11 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 20 Apr 2020 16:33:11 +0000
Subject: [issue40327] list(sys.modules.items()) can throw RuntimeError:
 dictionary changed size during iteration
In-Reply-To: <1587284646.11.0.468516211586.issue40327@roundup.psfhosted.org>
Message-ID: <1587400391.11.0.982432007665.issue40327@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I afraid that this is a part of the larger issue (see also issue31165). Seems the cause is that the GIL can be released when allocate or reallocate the memory. Does your project use some memory managing hooks?

Using sys.modules.copy().items() can help a lot, because you allocate memory for new dict only once. In case of list(sys.modules.items()) you allocate memory for every key-value pair, and may allocate memory several times to resize a list.

This reduces the probability of occurring the problem in many times, but not to zero. There is still a chance that the size of the original dict increase when you allocate a memory for a new dict, so copying the data to a new dict can fail or even crash or spoil the memory.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40327>
_______________________________________

From report at bugs.python.org  Mon Apr 20 12:49:24 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Mon, 20 Apr 2020 16:49:24 +0000
Subject: =?utf-8?q?=5Bissue39849=5D_Compiler_warninig=3A_warning=3A_variable_?=
 =?utf-8?q?=E2=80=98res=E2=80=99_set_but_not_used_=5B-Wunused-but-set-vari?=
 =?utf-8?q?able=5D?=
In-Reply-To: <1583334504.92.0.978999288989.issue39849@roundup.psfhosted.org>
Message-ID: <1587401364.62.0.251197988779.issue39849@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:


New changeset 5dd21f5d1c9b5a9316deca4535932675f04efeee by Hai Shi in branch 'master':
bpo-39849: Enable assertions in _testcapimodule.c and _testinternalcapi.c (GH-19623)
https://github.com/python/cpython/commit/5dd21f5d1c9b5a9316deca4535932675f04efeee


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39849>
_______________________________________

From report at bugs.python.org  Mon Apr 20 12:50:16 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Mon, 20 Apr 2020 16:50:16 +0000
Subject: =?utf-8?q?=5Bissue39849=5D_Compiler_warninig=3A_warning=3A_variable_?=
 =?utf-8?q?=E2=80=98res=E2=80=99_set_but_not_used_=5B-Wunused-but-set-vari?=
 =?utf-8?q?able=5D?=
In-Reply-To: <1583334504.92.0.978999288989.issue39849@roundup.psfhosted.org>
Message-ID: <1587401416.3.0.041275447121.issue39849@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

Thanks hai shi, now the issue is fixed :)

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39849>
_______________________________________

From report at bugs.python.org  Mon Apr 20 13:03:35 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 20 Apr 2020 17:03:35 +0000
Subject: [issue40312] Weakref callbacks running before finalizers in GC
 collection
In-Reply-To: <1587153160.93.0.26793085181.issue40312@roundup.psfhosted.org>
Message-ID: <1587402215.24.0.607256715994.issue40312@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

> Pablo, as above, I'm inclined to leave things alone unless we can "prove" no current code could possibly be relying (even by accident) on that gc currently runs callbacks before finalizers.  Which may be the case!  I don't know ;-)

I very much agree with this. Also, (I think you already mentioned this) over-specifying the order of things in the gc may be a great way to shoot ourselves in the foot if we need to fix bugs or some odd behaviour during finalization/destruction (think for instance the latest bug regarding tp_clear and weakref callbacks).

I think we could at least improve somehow the docs, to say at least that the order is not specified so people that look at them do not rely on it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40312>
_______________________________________

From report at bugs.python.org  Mon Apr 20 13:28:24 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Mon, 20 Apr 2020 17:28:24 +0000
Subject: [issue40288] atexit module should not be loaded more than once per
 interpreter
In-Reply-To: <1586917009.7.0.806642420762.issue40288@roundup.psfhosted.org>
Message-ID: <1587403704.44.0.953087474266.issue40288@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
nosy: +eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40288>
_______________________________________

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: [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 13:55:13 2020
From: report at bugs.python.org (Allan Feldman)
Date: Mon, 20 Apr 2020 17:55:13 +0000
Subject: [issue40312] Weakref callbacks running before finalizers in GC
 collection
In-Reply-To: <1587153160.93.0.26793085181.issue40312@roundup.psfhosted.org>
Message-ID: <1587405313.81.0.911775883739.issue40312@roundup.psfhosted.org>


Allan Feldman <allan.d.feldman at gmail.com> added the comment:

I definitely understand the possibility that some code is relying on the current gc behavior of weakref callbacks being invoked after finalizers.

That being said, the behavior is currently inconsistent between gc and reference counted paths. The language doesn't have to define the explicit ordering but the internal inconsistency was definitely unexpected for us.

The result is that behavioral consistency becomes more difficult in application code when using language provided structures such as WeakValueDictionary.

cache = weakref.WeakValueDictionary()

class Bar:
    pass

class Foo:
    def __init__(self):
        self._self = self
        self.value = Bar()
        cache[id(self.value)] = self.value

    def __del__(self):
        # the cache may or may not have self.value at this point
        # even though self.value is strongly referenced!
        print(list(cache.items()))


>From the weakref docs:
> Entries in the dictionary will be discarded when no strong reference to the value exists any more.

But doesn't the code above imply that the entry is discarded even though there are strong references to the value?

In any case, I definitely appreciate all the eyes on this Tim + Pablo! At the very least, documentation updates do sound like a good idea if we're moving forward with leaving the behavior of weakrefs as currently specified. In particular, it would be worth pointing out that weakrefs callbacks can run even when the object is referenced.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40312>
_______________________________________

From report at bugs.python.org  Mon Apr 20 14:17:58 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 20 Apr 2020 18:17:58 +0000
Subject: [issue40286] Add randbytes() method to random.Random
In-Reply-To: <1586903418.02.0.530735802731.issue40286@roundup.psfhosted.org>
Message-ID: <1587406678.98.0.455403120595.issue40286@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

The randbytes() method needs to depend on genrandbits().  It is documented that custom generators can supply there own random() and genrandbits() methods and expect that the other downstream generators all follow.  See the attached example which demonstrates that randbytes() bypasses this framework pattern.

Also, I don't want randbytes() in the C extension.  We're tried to keep as much of the code as possible in pure Python and only have the MersenneTwister specific code in the C module.  The improves maintainability and makes the code more accessible to a broader audience.

Also, please don't change the name of the genrand_int32() function.  It was a goal to change as little as possible from the official, standard version of the C code at http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/MT2002/emt19937ar.html .  For the most part, we just want to wrap that code for Python bindings, but not modify it.

----------
status: closed -> open
Added file: https://bugs.python.org/file49078/run_random.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40286>
_______________________________________

From report at bugs.python.org  Mon Apr 20 14:20:31 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 20 Apr 2020 18:20:31 +0000
Subject: [issue40286] Add randbytes() method to random.Random
In-Reply-To: <1586903418.02.0.530735802731.issue40286@roundup.psfhosted.org>
Message-ID: <1587406831.14.0.475660432051.issue40286@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Direct link to MT code that I would like to leave mostly unmodified:  http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/MT2002/CODES/mt19937ar.c

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40286>
_______________________________________

From report at bugs.python.org  Mon Apr 20 14:24:09 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 20 Apr 2020 18:24:09 +0000
Subject: [issue40312] Weakref callbacks running before finalizers in GC
 collection
In-Reply-To: <1587153160.93.0.26793085181.issue40312@roundup.psfhosted.org>
Message-ID: <1587407049.67.0.60316512655.issue40312@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

> The result is that behavioral consistency becomes more difficult in application code when using language provided structures such as WeakValueDictionary.


Well, you are already in tricky territory using finalizers. Note this sentence from the docs (https://docs.python.org/3/reference/datamodel.html#object.__del__):

> It is not guaranteed that __del__() methods are called for objects that still exist when the interpreter exits.


So CPython does not even promise that __del__ will be called always!


> But doesn't the code above imply that the entry is discarded even though there are strong references to the value?

No, because if there would be strong references then the refcount won't be 0 and the object would not have been finalized. If the object is finalized is because nobody has more strong references. A WeakValueDictionary holds weak references in the values, that is why is called WeakValueDictionary ;) 

> In particular, it would be worth pointing out that weakrefs callbacks can run even when the object is referenced.

That can be true but with a big caveat. There are two cases:

- Normal refcount falls to 0: the callback is executed when the deallocator is going to run, so nobody has strong references.

- GC: The gc calls the callback *before* the finalizer but at that point (before the finalizer) is unreachable from the outside, so all the references are from internal objects. Is still referenced but from unreachable objects that (unless resurrected) they are going to be destroyed by the gc. Notice that at the point the callback runs, all those objects are unreachable, so they cannot be referenced by anything in your program except themselves.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40312>
_______________________________________

From report at bugs.python.org  Mon Apr 20 14:46:50 2020
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 20 Apr 2020 18:46:50 +0000
Subject: [issue40314] python code order of magnitude faster than equivalent
 CPython code for simple import statement
In-Reply-To: <1587162924.52.0.924325577944.issue40314@roundup.psfhosted.org>
Message-ID: <1587408410.42.0.0705411639357.issue40314@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

Are you quite sure you're converting your times correctly, particularly in the C code?  The units in the Python version should be seconds; does the C version actually take 23 seconds to execute?  What kind of timing do you get if you time both programs with the same external program?

----------
nosy: +zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40314>
_______________________________________

From report at bugs.python.org  Mon Apr 20 14:54:19 2020
From: report at bugs.python.org (Allan Feldman)
Date: Mon, 20 Apr 2020 18:54:19 +0000
Subject: [issue40312] Weakref callbacks running before finalizers in GC
 collection
In-Reply-To: <1587153160.93.0.26793085181.issue40312@roundup.psfhosted.org>
Message-ID: <1587408859.47.0.576042878481.issue40312@roundup.psfhosted.org>


Allan Feldman <allan.d.feldman at gmail.com> added the comment:

Yup agree with all the points above, just wanted to point out that I think self.value is strongly referenced (even though it's just internal references and will be collected by the gc) during Foo.__del__ execution (annotated code below), yet the WeakValueDictionary entry is cleared:

import gc
import sys
import weakref

cache = weakref.WeakValueDictionary()


class Bar:
    pass


class Foo:
    def __init__(self):
        self._self = self
        self.value = Bar()
        cache[id(self.value)] = self.value

    def __del__(self):
        print(sys.getrefcount(self.value))  # -> 2
        # the cache may or may not have self.value at this point
        # even though self.value is strongly referenced!
        print(list(cache.items()))  # -> []


o = Foo()
del o
gc.collect()

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40312>
_______________________________________

From report at bugs.python.org  Mon Apr 20 14:55:09 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 20 Apr 2020 18:55:09 +0000
Subject: [issue40330] ShareableList size guard incorrect for str data
In-Reply-To: <1587307650.58.0.0332306022836.issue40330@roundup.psfhosted.org>
Message-ID: <1587408909.41.0.273701808163.issue40330@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset eba9f6155df59c9beed97fb5764c9f01dd941af0 by Antoine Pitrou in branch 'master':
bpo-40330: Fix utf-8 size check in ShareableList (GH-19606)
https://github.com/python/cpython/commit/eba9f6155df59c9beed97fb5764c9f01dd941af0


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40330>
_______________________________________

From report at bugs.python.org  Mon Apr 20 14:58:56 2020
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 20 Apr 2020 18:58:56 +0000
Subject: [issue40330] ShareableList size guard incorrect for str data
In-Reply-To: <1587307650.58.0.0332306022836.issue40330@roundup.psfhosted.org>
Message-ID: <1587409136.74.0.666771237563.issue40330@roundup.psfhosted.org>


Change by Antoine Pitrou <solipsis at pitrou.net>:


----------
pull_requests: +18953
pull_request: https://github.com/python/cpython/pull/19625

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40330>
_______________________________________

From report at bugs.python.org  Mon Apr 20 15:05:24 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 20 Apr 2020 19:05:24 +0000
Subject: [issue40339] Instead of skipping,
 IPV6 test(s) fail on a non-IPV6 machine
In-Reply-To: <1587404929.24.0.675615215393.issue40339@roundup.psfhosted.org>
Message-ID: <1587409524.4.0.588017992124.issue40339@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

See also https://bugs.python.org/issue37199 for related work.

----------
nosy: +ZackerySpytz, asvetlov, xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40339>
_______________________________________

From report at bugs.python.org  Mon Apr 20 15:06:26 2020
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 20 Apr 2020 19:06:26 +0000
Subject: [issue40237] Test code coverage (C) job of Travis CI fails on
 test_distutils which creates _configtest.gcno file
In-Reply-To: <1586436730.26.0.786791148526.issue40237@roundup.psfhosted.org>
Message-ID: <1587409586.09.0.319393326142.issue40237@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

The historical background is code coverage of C code seemed like a good idea, so we set it up. :) Not much else to it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40237>
_______________________________________

From report at bugs.python.org  Mon Apr 20 15:22:53 2020
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 20 Apr 2020 19:22:53 +0000
Subject: [issue40330] ShareableList size guard incorrect for str data
In-Reply-To: <1587307650.58.0.0332306022836.issue40330@roundup.psfhosted.org>
Message-ID: <1587410573.84.0.0379101199465.issue40330@roundup.psfhosted.org>


Antoine Pitrou <solipsis at pitrou.net> added the comment:


New changeset 887ff8e37e238fbce18c647e588283904f38ab24 by Antoine Pitrou in branch '3.8':
[3.8] bpo-40330: Fix utf-8 size check in ShareableList (GH-19606) (GH-19625)
https://github.com/python/cpython/commit/887ff8e37e238fbce18c647e588283904f38ab24


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40330>
_______________________________________

From report at bugs.python.org  Mon Apr 20 15:23:06 2020
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 20 Apr 2020 19:23:06 +0000
Subject: [issue40330] ShareableList size guard incorrect for str data
In-Reply-To: <1587307650.58.0.0332306022836.issue40330@roundup.psfhosted.org>
Message-ID: <1587410586.78.0.38714362609.issue40330@roundup.psfhosted.org>


Change by Antoine Pitrou <solipsis at pitrou.net>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions:  -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40330>
_______________________________________

From report at bugs.python.org  Mon Apr 20 15:25:22 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 20 Apr 2020 19:25:22 +0000
Subject: [issue40286] Add randbytes() method to random.Random
In-Reply-To: <1586903418.02.0.530735802731.issue40286@roundup.psfhosted.org>
Message-ID: <1587410722.95.0.698043989045.issue40286@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

When a new method gets added to a module, it should happen in a way that is in harmony with the module's design.

----------
nosy: +tim.peters

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40286>
_______________________________________

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: [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:00:13 2020
From: report at bugs.python.org (Cajetan Rodrigues)
Date: Mon, 20 Apr 2020 20:00:13 +0000
Subject: [issue40340] Programming FAQ about "How do I convert a string to a
 number?" contains a typo
In-Reply-To: <1587411465.5.0.0585658579804.issue40340@roundup.psfhosted.org>
Message-ID: <1587412813.57.0.777494817162.issue40340@roundup.psfhosted.org>


Cajetan Rodrigues <caje731 at gmail.com> added the comment:

> these interpret the number as decimal

I'm no linguist, but I feel both expressions in the subordinate clause have their purposes, with respect to the the main clause:

* `int('0144') == 144` to show what works
* `int('0x144')` to show what does not work

I don't believe the octal notation was meant in the first example, as the equality wouldn't then hold, even if somehow the typecast worked (which it doesn't). The point was to positively reinforce the idea that the content of the string would be interpreted as a decimal. So something like `int('000000144') == 144` would still hold True. Negative reinforcement is provided in the second example.

But I agree that the sentence itself does not clearly separate the two examples, so I would suggest adding a comma after the first example, like so:

> By default, these interpret the number as decimal, so that `int('0144') == 144`, and `int('0x144')` raises ValueError.

----------
nosy: +cajetan.rodrigues

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40340>
_______________________________________

From report at bugs.python.org  Mon Apr 20 16:02:00 2020
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Mon, 20 Apr 2020 20:02:00 +0000
Subject: [issue39942] Making instance of `TypeVar` fails because of missing
 `__name__`
In-Reply-To: <1583971911.89.0.874740392795.issue39942@roundup.psfhosted.org>
Message-ID: <1587412920.39.0.81679684943.issue39942@roundup.psfhosted.org>


Ivan Levkivskyi <levkivskyi at gmail.com> added the comment:


New changeset a25a04fea5446b1712cde0cff556574be139285a by HongWeipeng in branch 'master':
bpo-39942:Fix failure in `TypeVar` when missing `__name__` (GH-19616)
https://github.com/python/cpython/commit/a25a04fea5446b1712cde0cff556574be139285a


----------
nosy: +levkivskyi

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39942>
_______________________________________

From report at bugs.python.org  Mon Apr 20 16:04:31 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 20 Apr 2020 20:04:31 +0000
Subject: [issue39942] Making instance of `TypeVar` fails because of missing
 `__name__`
In-Reply-To: <1583971911.89.0.874740392795.issue39942@roundup.psfhosted.org>
Message-ID: <1587413071.06.0.479392887457.issue39942@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
nosy: +miss-islington
nosy_count: 3.0 -> 4.0
pull_requests: +18954
pull_request: https://github.com/python/cpython/pull/19626

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39942>
_______________________________________

From report at bugs.python.org  Mon Apr 20 16:04:38 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 20 Apr 2020 20:04:38 +0000
Subject: [issue39942] Making instance of `TypeVar` fails because of missing
 `__name__`
In-Reply-To: <1583971911.89.0.874740392795.issue39942@roundup.psfhosted.org>
Message-ID: <1587413078.49.0.710639036769.issue39942@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +18955
pull_request: https://github.com/python/cpython/pull/19627

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39942>
_______________________________________

From report at bugs.python.org  Mon Apr 20 16:05:37 2020
From: report at bugs.python.org (Tim Peters)
Date: Mon, 20 Apr 2020 20:05:37 +0000
Subject: [issue40312] Weakref callbacks running before finalizers in GC
 collection
In-Reply-To: <1587153160.93.0.26793085181.issue40312@roundup.psfhosted.org>
Message-ID: <1587413137.74.0.274596844853.issue40312@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

Well, the refcounts on _everything_ cyclic gc sees are greater than 0.  Because if an object's refcount ever falls to 0 in CPython, reference counting deals with it immediately, and so it doesn't survive to participate in cyclic gc.

IOW, absolutely everything cyclic gc deals with is "strongly referenced" in the sense you're using:  absolutely everything cyclic gc deals with has a nonzero refcount.  Indeed, in a debug build, gc asserts early on that everything it sees has a refcount > 0.

It can be trash anyway.  Finding those "just internal references" is the _point_ of cyclic gc.  In your last example, the instant after you did `del o`, the instance of Foo, and the instance of Bar, _both_ became trash, period, despite that they both retained positive refcounts.

So you may as well object that the refcount of `self` is also greater than 0 inside __del__.  Indeed, add

            print(sys.getrefcount(self))

inside your __del__, and you'll see it prints 4.  So it's _twice_ as "strongly referenced" as self.value ;-)  It's being destroyed anyway.

Refcounts are simply irrelevant at this point, and so also is the concept of "strong reference" on its own.  All that matters is whether a strong reference exists from _outside_ the generation being collected.  `self` and `self.value` are in exactly the same boat in this regard:  there are no strong references to either from outside, but there are strong references to both from inside.  They're both trash.

There is _a_ principled way to proceed that would get you what you want in this example, but CPython never pursued it because it would add major complexity for almost no apparent practical gain:  build a graph of all the cyclic trash, compute the strongly connected components, build the induced DAG composed of the SCCs, then run end-of-life actions in order of a topological sort of that DAG.  Then __del__ would run first (self is in a self-cycle SCC with no predecessors in the DAG), and the weakref callback second (the Bar instance would be in its own SCC, with the `self` SCC as its predecessor in the DAG).

But I'm not sure any real gc system does that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40312>
_______________________________________

From report at bugs.python.org  Mon Apr 20 16:22:41 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 20 Apr 2020 20:22:41 +0000
Subject: [issue39942] Making instance of `TypeVar` fails because of missing
 `__name__`
In-Reply-To: <1583971911.89.0.874740392795.issue39942@roundup.psfhosted.org>
Message-ID: <1587414161.16.0.264759490667.issue39942@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 694a95ff437613e6295f531336b5bc7cab9e3713 by Miss Islington (bot) in branch '3.7':
bpo-39942:Fix failure in `TypeVar` when missing `__name__` (GH-19616)
https://github.com/python/cpython/commit/694a95ff437613e6295f531336b5bc7cab9e3713


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39942>
_______________________________________

From report at bugs.python.org  Mon Apr 20 16:24:13 2020
From: report at bugs.python.org (Dominik V.)
Date: Mon, 20 Apr 2020 20:24:13 +0000
Subject: [issue40340] Programming FAQ about "How do I convert a string to a
 number?" contains a typo
In-Reply-To: <1587411465.5.0.0585658579804.issue40340@roundup.psfhosted.org>
Message-ID: <1587414253.93.0.124668383846.issue40340@roundup.psfhosted.org>


Dominik V. <dominik.vilsmeier1123 at gmail.com> added the comment:

Indeed, thanks for clarifying. It seems I misunderstood the example, and perhaps that calls for a better separation. What about adding

> By default, these interpret the number as decimal, so that `int('0144') == 144` holds true and `int('0x144')` raises ValueError.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40340>
_______________________________________

From report at bugs.python.org  Mon Apr 20 16:24:42 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 20 Apr 2020 20:24:42 +0000
Subject: [issue39942] Making instance of `TypeVar` fails because of missing
 `__name__`
In-Reply-To: <1583971911.89.0.874740392795.issue39942@roundup.psfhosted.org>
Message-ID: <1587414282.36.0.375192730876.issue39942@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 41660cac63c1a216e43335007e329e213054100e by Miss Islington (bot) in branch '3.8':
bpo-39942:Fix failure in `TypeVar` when missing `__name__` (GH-19616)
https://github.com/python/cpython/commit/41660cac63c1a216e43335007e329e213054100e


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39942>
_______________________________________

From report at bugs.python.org  Mon Apr 20 16:25:04 2020
From: report at bugs.python.org (dgelessus)
Date: Mon, 20 Apr 2020 20:25:04 +0000
Subject: [issue40198] macOS Python builds from Python.org ignore
 DYLD_LIBRARY_PATH due to hardened runtime
In-Reply-To: <1586118049.02.0.786646499236.issue40198@roundup.psfhosted.org>
Message-ID: <1587414304.89.0.21994090879.issue40198@roundup.psfhosted.org>


dgelessus <dgelessus+bugs.python.org at me.com> added the comment:

I can confirm that the newly released Python 2.7.18 has the .allow-dyld-environment-variables entitlement:

$ ./python2.7 --version
Python 2.7.18
$ codesign --display --entitlements=:- python2.7
Executable=/Library/Frameworks/Python.framework/Versions/2.7/bin/python2.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.allow-dyld-environment-variables</key>
<true/>
<key>com.apple.security.cs.disable-library-validation</key>
<true/>
<key>com.apple.security.cs.disable-executable-page-protection</key>
<true/>
</dict>
</plist>

and accepts DYLD_LIBRARY_PATH again:

$ DYLD_LIBRARY_PATH=tests/objc ./python2.7 -c 'import os; print(os.environ.get("DYLD_LIBRARY_PATH"))'
tests/objc

Thank you for the fix!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40198>
_______________________________________

From report at bugs.python.org  Mon Apr 20 16:28:28 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 20 Apr 2020 20:28:28 +0000
Subject: [issue40327] list(sys.modules.items()) can throw RuntimeError:
 dictionary changed size during iteration
In-Reply-To: <1587284646.11.0.468516211586.issue40327@roundup.psfhosted.org>
Message-ID: <1587414508.89.0.0138502065538.issue40327@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
keywords: +patch
pull_requests: +18956
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19628

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40327>
_______________________________________

From report at bugs.python.org  Mon Apr 20 16:28:52 2020
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Mon, 20 Apr 2020 20:28:52 +0000
Subject: [issue39942] Making instance of `TypeVar` fails because of missing
 `__name__`
In-Reply-To: <1583971911.89.0.874740392795.issue39942@roundup.psfhosted.org>
Message-ID: <1587414532.87.0.431852027247.issue39942@roundup.psfhosted.org>


Change by Ivan Levkivskyi <levkivskyi at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39942>
_______________________________________

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: [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:02:00 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 20 Apr 2020 21:02:00 +0000
Subject: [issue39939] PEP 616: Add str methods to remove prefix or suffix
In-Reply-To: <1583953898.19.0.613718077904.issue39939@roundup.psfhosted.org>
Message-ID: <1587416520.22.0.861674666276.issue39939@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

The documentation should explain well the difference between removeprefix()/removesuffix() and lstrip()/strip()/rstrip(), since it is the rationale of the PEP ;-)

An example that can be used to explain the difference:

>>> "Monty Python".removesuffix(" Python")
'Monty'
>>> "Monty Python".strip(" Python")
'M'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39939>
_______________________________________

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: [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:10:57 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 20 Apr 2020 21:10:57 +0000
Subject: [issue40341] Programming FAQ includes actively discouraged solutions; 
 Should those be removed?
In-Reply-To: <1587416365.54.0.999974156982.issue40341@roundup.psfhosted.org>
Message-ID: <1587417057.98.0.43761493421.issue40341@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I rather like the discussion in [How do I write a function with output parameters].  Some variant of each of those solutions arise in code reviews over and over again.  Rarely do the occur in simplistic examples, but they do occur.  The simple examples given are the easiest way to learn about the anti-patterns.

In the section [How do I use strings to call functions/methods?], let's eliminate the eval() variant which isn't really helpful.  The locals() technique does occur in practice and is worth showing.

In the section [How can I sort one list by values from another list], I concur that we can completely eliminate "alternative" and its explanatory text.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40341>
_______________________________________

From report at bugs.python.org  Mon Apr 20 17:11:38 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 20 Apr 2020 21:11:38 +0000
Subject: [issue39939] PEP 616: Add str methods to remove prefix or suffix
In-Reply-To: <1583953898.19.0.613718077904.issue39939@roundup.psfhosted.org>
Message-ID: <1587417098.42.0.822417287835.issue39939@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

When, I even expect that some people use .strip() whereas their intent was to use .lstrip():

>>> "Python vs Monty Python".strip("Python")
' vs Monty '

Again, strip() is used with a string whereas the real intent was to use removesuffix() which didn't exist ;-)

A note should be added to lstrip(), strip() and rstrip() documentation to point to removeprefix() and/or removesuffix().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39939>
_______________________________________

From report at bugs.python.org  Mon Apr 20 17:13:05 2020
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 20 Apr 2020 21:13:05 +0000
Subject: [issue40120] Undefined C behavior going beyond end of struct via a
 [1] arrays.
In-Reply-To: <1585602263.71.0.279519604291.issue40120@roundup.psfhosted.org>
Message-ID: <1587417185.94.0.947363558961.issue40120@roundup.psfhosted.org>


Antoine Pitrou <solipsis at pitrou.net> added the comment:

Another possibility yet would be:

typedef struct {
    PyObject_VAR_HEAD
    Py_hash_t ob_shash;
    char ob_sval;
} PyBytesObject;

#define PyBytes_AS_STRING(op) (assert(PyBytes_Check(op)), \
                                &(((PyBytesObject *)(op))->ob_sval))

Not sure whether that would be UB...

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40120>
_______________________________________

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: [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:17:11 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 20 Apr 2020 21:17:11 +0000
Subject: [issue40342] Programming FAQ about "How do I apply a method to a
 sequence of objects?" should include the option of an explicit for-loop
In-Reply-To: <1587416798.17.0.310240358568.issue40342@roundup.psfhosted.org>
Message-ID: <1587417431.07.0.910025131597.issue40342@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

The current answer seems reasonable to me.  It addresses the question that most people want to have answered.  Also, it isn't common to loop over methods that don't return values, because those typically do in-place mutations.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40342>
_______________________________________

From report at bugs.python.org  Mon Apr 20 17:23:18 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 20 Apr 2020 21:23:18 +0000
Subject: [issue39939] PEP 616: Add str methods to remove prefix or suffix
In-Reply-To: <1583953898.19.0.613718077904.issue39939@roundup.psfhosted.org>
Message-ID: <1587417798.24.0.57268691125.issue39939@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Please add an underscore to the names:  remove_prefix(). and remove_suffix().

The latter method causes a mental hiccup when first reading as removes-uffix, forcing mental backtracking to get to remove-suffix.

We had a similar problem with addinfourl initially being read as add-in-four-l before mentally backtracking to add-info-url.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39939>
_______________________________________

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: [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:28:13 2020
From: report at bugs.python.org (Dominik V.)
Date: Mon, 20 Apr 2020 21:28:13 +0000
Subject: [issue40344] Programming FAQ about "What is the most efficient way to
 concatenate many strings together?" -- Improving the example
In-Reply-To: <1587418050.72.0.944089786988.issue40344@roundup.psfhosted.org>
Message-ID: <1587418093.96.0.238523563104.issue40344@roundup.psfhosted.org>


Dominik V. <dominik.vilsmeier1123 at gmail.com> added the comment:

Here's the link to the relevant section: https://docs.python.org/3/faq/programming.html#what-is-the-most-efficient-way-to-concatenate-many-strings-together

----------

_______________________________________
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: [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:39:52 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 20 Apr 2020 21:39:52 +0000
Subject: [issue39939] PEP 616: Add str methods to remove prefix or suffix
In-Reply-To: <1583953898.19.0.613718077904.issue39939@roundup.psfhosted.org>
Message-ID: <1587418792.55.0.0777564022878.issue39939@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> Please add an underscore to the names:  remove_prefix(). and remove_suffix().

The PEP 616 was approved with removeprefix() and removesuffix() names. The rationale for the names can be even found in the PEP:
https://www.python.org/dev/peps/pep-0616/#alternative-method-names

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39939>
_______________________________________

From report at bugs.python.org  Mon Apr 20 17:49:31 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 20 Apr 2020 21:49:31 +0000
Subject: [issue40344] Programming FAQ about "What is the most efficient way to
 concatenate many strings together?" -- Improving the example
In-Reply-To: <1587418050.72.0.944089786988.issue40344@roundup.psfhosted.org>
Message-ID: <1587419371.26.0.529540406584.issue40344@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Dominik, can you please limit your tracker issues to a handful on entries that you really care about?  This is turning into a stream of consciousness dump onto our tracker.  You really don't need to rewrite every entry you see, especially when we haven't had user complaints about the existing entries.

Also, it seems to me that you're missing the point of the simplified examples in the docs.  Yes, of course, the for-loop in chunks is superfluous; however, that for-loop is very common pattern, but it typically does other work in the loop.  For example:
    
    blocks = []
    while True:
        block = s.recv(4096)
        if not block:
            break
        blocks.append(block)
    page = b''.join(blocks)

The problem with that example is that it shifts focus to tcp clients rather than the core topic to how to join strings.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40344>
_______________________________________

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: [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:17 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 20 Apr 2020 21:53:17 +0000
Subject: [issue40346] Redesign random.Random class inheritance
In-Reply-To: <1587419589.68.0.186666450831.issue40346@roundup.psfhosted.org>
Message-ID: <1587419597.2.0.526376005477.issue40346@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
title: Redesign random class inheritance -> Redesign random.Random class inheritance

_______________________________________
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: [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:53:59 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 20 Apr 2020 21:53:59 +0000
Subject: [issue40286] Add randbytes() method to random.Random
In-Reply-To: <1586903418.02.0.530735802731.issue40286@roundup.psfhosted.org>
Message-ID: <1587419639.2.0.400336184287.issue40286@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I created bpo-40346: "Redesign random.Random class inheritance".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40286>
_______________________________________

From report at bugs.python.org  Mon Apr 20 17:54:21 2020
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 20 Apr 2020 21:54:21 +0000
Subject: [issue40346] Redesign random.Random class inheritance
In-Reply-To: <1587419589.68.0.186666450831.issue40346@roundup.psfhosted.org>
Message-ID: <1587419661.59.0.596743603027.issue40346@roundup.psfhosted.org>


Change by Antoine Pitrou <solipsis at pitrou.net>:


----------
keywords: +patch
nosy: +pitrou
nosy_count: 1.0 -> 2.0
pull_requests: +18957
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19539

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40346>
_______________________________________

From report at bugs.python.org  Mon Apr 20 17:54:30 2020
From: report at bugs.python.org (Tim Peters)
Date: Mon, 20 Apr 2020 21:54:30 +0000
Subject: [issue40312] Weakref callbacks running before finalizers in GC
 collection
In-Reply-To: <1587153160.93.0.26793085181.issue40312@roundup.psfhosted.org>
Message-ID: <1587419670.27.0.592549926567.issue40312@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

A simple (finalizer-only) example of what an SCC-based DAG topsort ordering would accomplish:

    import gc

    class C:
        def __init__(self, val):
            self.val = val
        def __del__(self):
            print("finalizing", self.val)

    c, b, a = map(C, "cba")
    a.next = b
    b.next = c

    #a.loop = a
    del c, b, a
    gc.collect()

That finalizes in the order a, b, c.  Refcount semantics force that.  But, uncomment the "a.loop = a" line, and the order changes to c, b, a.  They all look exactly the same to gc, so it runs finalizers in the order they happen to appear in the list gc is crawling over.  A DAG topsort ordering would force a, b, c order again.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40312>
_______________________________________

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: [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 17:58:26 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 20 Apr 2020 21:58:26 +0000
Subject: [issue39939] PEP 616: Add str methods to remove prefix or suffix
In-Reply-To: <1583953898.19.0.613718077904.issue39939@roundup.psfhosted.org>
Message-ID: <1587419906.27.0.953216159029.issue39939@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I disagree with the rationale given in the PEP.  The reason that "startswith" and "endswith" don't have underscores is that the aren't needed to disambiguate the text.  Our rules are to add underscores when it improves readability, which in this case it does.   Like casing conventions, these rules became prevent after the early modules were created (i.e. the older the module, the more likely that it doesn't follow modern conventions).

We only have one chance to get this right.  Take it from someone with experience with this particular problem.  I created imap() but later regretted the naming pattern when if came to ifilter() and islice() which sometimes cause mental hiccups initially being read as if-ilter and is-lice.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39939>
_______________________________________

From report at bugs.python.org  Mon Apr 20 18:10:25 2020
From: report at bugs.python.org (Dominik V.)
Date: Mon, 20 Apr 2020 22:10:25 +0000
Subject: [issue40344] Programming FAQ about "What is the most efficient way to
 concatenate many strings together?" -- Improving the example
In-Reply-To: <1587418050.72.0.944089786988.issue40344@roundup.psfhosted.org>
Message-ID: <1587420625.52.0.0477608048705.issue40344@roundup.psfhosted.org>


Dominik V. <dominik.vilsmeier1123 at gmail.com> added the comment:

It was not my intention to disturb the traffic on the bug tracker. My apologies if that caused any trouble. I also thought only people subscribed to the indicated topic (e.g. "Documentation") would receive a notification.

The docs pages mention that for enhancement proposals one should submit a bug report on the tracker:

> If you find a bug in this documentation or would like to propose an improvement, please submit a bug report on the tracker (https://docs.python.org/3/bugs.html).

I do care about the quality of Python's documentation and I think it could be improved in these cases. Often it is newcomers who consult these pages and they might be irritated by the mentioned parts.

I see how it would be distracting to include a more complex real world example, but using an example which performs apparently superfluous steps without any additional comment might seem strange. More experienced users probably won't need such an example at all. In addition it might make people falsely belief that `str.join` expects a list of strings rather than any iterable, and hence the explicit construction of the list.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40344>
_______________________________________

From report at bugs.python.org  Mon Apr 20 18:19:10 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 20 Apr 2020 22:19:10 +0000
Subject: [issue40346] Redesign random.Random class inheritance
In-Reply-To: <1587419589.68.0.186666450831.issue40346@roundup.psfhosted.org>
Message-ID: <1587421150.32.0.811998134849.issue40346@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests:  -18957

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40346>
_______________________________________

From report at bugs.python.org  Mon Apr 20 18:35:36 2020
From: report at bugs.python.org (Andy Lester)
Date: Mon, 20 Apr 2020 22:35:36 +0000
Subject: [issue40344] Programming FAQ about "What is the most efficient way to
 concatenate many strings together?" -- Improving the example
In-Reply-To: <1587418050.72.0.944089786988.issue40344@roundup.psfhosted.org>
Message-ID: <1587422136.19.0.890748654323.issue40344@roundup.psfhosted.org>


Change by Andy Lester <andy at petdance.com>:


----------
nosy: +petdance

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40344>
_______________________________________

From report at bugs.python.org  Mon Apr 20 18:55:49 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 20 Apr 2020 22:55:49 +0000
Subject: [issue40344] Programming FAQ about "What is the most efficient way to
 concatenate many strings together?" -- Improving the example
In-Reply-To: <1587418050.72.0.944089786988.issue40344@roundup.psfhosted.org>
Message-ID: <1587423349.27.0.976160639508.issue40344@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Your contributions are welcome.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40344>
_______________________________________

From report at bugs.python.org  Mon Apr 20 19:00:16 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 20 Apr 2020 23:00:16 +0000
Subject: [issue40346] Redesign random.Random class inheritance
In-Reply-To: <1587419589.68.0.186666450831.issue40346@roundup.psfhosted.org>
Message-ID: <1587423616.68.0.850229580817.issue40346@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

The randbytes() method could have been added effortlessly as a one line pure python method.  It only became complicated as a result of premature optimization into C code and as a result of ignoring the API promises.

You really don't have to redesign the whole module.  We have no user complaints.  There is no problem to be fixed.  IMO, this would be unnecessary churn.

----------
nosy: +mark.dickinson, rhettinger, tim.peters

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40346>
_______________________________________

From report at bugs.python.org  Mon Apr 20 19:10:58 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 20 Apr 2020 23:10:58 +0000
Subject: [issue40346] Redesign random.Random class inheritance
In-Reply-To: <1587419589.68.0.186666450831.issue40346@roundup.psfhosted.org>
Message-ID: <1587424258.76.0.30813375256.issue40346@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +18958
pull_request: https://github.com/python/cpython/pull/19631

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40346>
_______________________________________

From report at bugs.python.org  Mon Apr 20 19:18:37 2020
From: report at bugs.python.org (=?utf-8?b?VmVkcmFuIMSMYcSNacSH?=)
Date: Mon, 20 Apr 2020 23:18:37 +0000
Subject: [issue40342] Programming FAQ about "How do I apply a method to a
 sequence of objects?" should include the option of an explicit for-loop
In-Reply-To: <1587416798.17.0.310240358568.issue40342@roundup.psfhosted.org>
Message-ID: <1587424717.44.0.404027510381.issue40342@roundup.psfhosted.org>


Vedran ?a?i? <vedgar at gmail.com> added the comment:

I must say I agree with Dominik here. Too many times my students write list comprehensions when they mean a for loop. It's not just a "has result vs updates inplace" dichotomy: often it produces some output like a drawing or just a print() call [one of rare things that was better when print was a command is that it was impossible to do this:]. Yes, I know print call is not a method, but e.g. .plot() on DataFrame is. I'd sleep easier if I knew the Programming FAQ didn't encourage this style.

It would be enough to add a sentence of a sort
"If you don't care about the return value of the method, use a for loop.
for obj in mylist: obj.method()
"

----------
nosy: +veky

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40342>
_______________________________________

From report at bugs.python.org  Mon Apr 20 19:31:23 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 20 Apr 2020 23:31:23 +0000
Subject: [issue40346] Redesign random.Random class inheritance
In-Reply-To: <1587419589.68.0.186666450831.issue40346@roundup.psfhosted.org>
Message-ID: <1587425483.98.0.860084867155.issue40346@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Attached PR 19631 adds random.BaseRandom. random.SystemRandom now inherits from BaseRandom and so no longer inherits from _random.Random: an instance now only takes 48 bytes of memory, rather than 2568 bytes (on x86-64).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40346>
_______________________________________

From report at bugs.python.org  Mon Apr 20 19:53:07 2020
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 20 Apr 2020 23:53:07 +0000
Subject: [issue40313] bytes.hex(sep,
 bytes_per_sep) is many times slower than manually inserting the
 separators
In-Reply-To: <1587157109.99.0.0253750787201.issue40313@roundup.psfhosted.org>
Message-ID: <1587426787.04.0.556196169051.issue40313@roundup.psfhosted.org>


Change by Gregory P. Smith <greg at krypto.org>:


----------
assignee:  -> gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40313>
_______________________________________

From report at bugs.python.org  Mon Apr 20 20:17:59 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 21 Apr 2020 00:17:59 +0000
Subject: [issue40313] bytes.hex(sep,
 bytes_per_sep) is many times slower than manually inserting the
 separators
In-Reply-To: <1587157109.99.0.0253750787201.issue40313@roundup.psfhosted.org>
Message-ID: <1587428279.28.0.122260686073.issue40313@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 6a9e80a93148b13e4d3bceaab5ea1804ab0e64d5 by sweeneyde in branch 'master':
bpo-40313: speed up bytes.hex() (GH-19594)
https://github.com/python/cpython/commit/6a9e80a93148b13e4d3bceaab5ea1804ab0e64d5


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40313>
_______________________________________

From report at bugs.python.org  Mon Apr 20 20:32:21 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 21 Apr 2020 00:32:21 +0000
Subject: [issue40313] bytes.hex(sep,
 bytes_per_sep) is many times slower than manually inserting the
 separators
In-Reply-To: <1587157109.99.0.0253750787201.issue40313@roundup.psfhosted.org>
Message-ID: <1587429141.53.0.47444365837.issue40313@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Thanks Dennis for the optimization!

FYI I also pushed another optimization recently:

commit 455df9779873b8335b20292b8d0c43d66338a4db
Author: Victor Stinner <vstinner at python.org>
Date:   Wed Apr 15 14:05:24 2020 +0200

    Optimize _Py_strhex_impl() (GH-19535)
    
    Avoid a temporary buffer to create a bytes string: use
    PyBytes_FromStringAndSize() to directly allocate a bytes object.

----------
nosy: +vstinner
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40313>
_______________________________________

From report at bugs.python.org  Mon Apr 20 20:53:11 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 21 Apr 2020 00:53:11 +0000
Subject: [issue40335] Regression in multiline SyntaxError offsets
In-Reply-To: <1587332455.2.0.964330224308.issue40335@roundup.psfhosted.org>
Message-ID: <1587430391.24.0.306326575365.issue40335@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset 11a7f158ef51b0edcde3c3d9215172354e385877 by Pablo Galindo in branch 'master':
bpo-40335: Correctly handle multi-line strings in tokenize error scenarios (GH-19619)
https://github.com/python/cpython/commit/11a7f158ef51b0edcde3c3d9215172354e385877


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40335>
_______________________________________

From report at bugs.python.org  Mon Apr 20 20:53:24 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 21 Apr 2020 00:53:24 +0000
Subject: [issue40335] Regression in multiline SyntaxError offsets
In-Reply-To: <1587332455.2.0.964330224308.issue40335@roundup.psfhosted.org>
Message-ID: <1587430404.45.0.172593448831.issue40335@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40335>
_______________________________________

From report at bugs.python.org  Mon Apr 20 21:07:34 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 21 Apr 2020 01:07:34 +0000
Subject: [issue40089] Add _at_fork_reinit() method to locks
In-Reply-To: <1585324297.97.0.65509955463.issue40089@roundup.psfhosted.org>
Message-ID: <1587431254.44.0.533668383238.issue40089@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40089>
_______________________________________

From report at bugs.python.org  Mon Apr 20 21:08:54 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 21 Apr 2020 01:08:54 +0000
Subject: [issue39954] test_subprocess: test_specific_shell() fails on AMD64
 FreeBSD Shared 3.x
In-Reply-To: <1584102265.92.0.572809355016.issue39954@roundup.psfhosted.org>
Message-ID: <1587431334.87.0.182968627091.issue39954@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

AMD64 FreeBSD Shared 3.x is green again, I close the issue.

----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39954>
_______________________________________

From report at bugs.python.org  Mon Apr 20 21:09:18 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 21 Apr 2020 01:09:18 +0000
Subject: [issue39933] test_gdb fails on AMD64 FreeBSD Shared 3.x: ptrace:
 Operation not permitted
In-Reply-To: <1583927803.55.0.643222253401.issue39933@roundup.psfhosted.org>
Message-ID: <1587431358.33.0.426669357242.issue39933@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

AMD64 FreeBSD Shared 3.x is green again, I close the issue.

----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39933>
_______________________________________

From report at bugs.python.org  Mon Apr 20 21:12:10 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 21 Apr 2020 01:12:10 +0000
Subject: [issue40346] Redesign random.Random class inheritance
In-Reply-To: <1587419589.68.0.186666450831.issue40346@roundup.psfhosted.org>
Message-ID: <1587431530.45.0.206644098803.issue40346@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Having SystemRandom() use less memory is nice.  The seed() logic is reusable (not MT specific) and should be kept.  Historically, subclassers were supposed to supply random(), and the getrandbits() method was optional and just added greater range to randrange.  Am not sure I'm comfortable with you defining random() in pure python dividing by BPF -- that seems like a C level decision. Perhaps some factoring may be useful, but I worry that you're changing the user contracts in subtle ways and that we aren't really gaining anything out of this.  I'll just wait to see what everyone else has to say.  For me, I really wish you wouldn't do this and would have instead just added randbytes() in a way that was in harmony with the rest of the module.  I am getting afraid to submit bug reports because instead of fixing them, it triggers broad redesign and churn.  This all started because Antoine and Mark wanted getrandbits(0) to return 0; that was such a minor thing, and now the code is experiencing instability and is in some places measurably slower.

> The base class should implement randbytes() using getrandbits()

That is a reimagining of the API at odds with the 20+ year history of the module.  If we were starting out from scratch, that might have been a reasonable path, but with long standing, stable code, it doesn't make as much sense.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40346>
_______________________________________

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: [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 00:05:13 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 21 Apr 2020 04:05:13 +0000
Subject: [issue40349] Python3.9 changes col_offset for some ast nodes
In-Reply-To: <1587441488.8.0.801232249249.issue40349@roundup.psfhosted.org>
Message-ID: <1587441913.6.0.972718514138.issue40349@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +BTaskaya, pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40349>
_______________________________________

From report at bugs.python.org  Tue Apr 21 02:43:12 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 21 Apr 2020 06:43:12 +0000
Subject: [issue40349] Python3.9 changes col_offset for some ast nodes
In-Reply-To: <1587441488.8.0.801232249249.issue40349@roundup.psfhosted.org>
Message-ID: <1587451392.78.0.769542207051.issue40349@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

col_offset = 0 is the correct value. There was a bug which is fixed now (see issue39474).

----------
nosy: +serhiy.storchaka
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40349>
_______________________________________

From report at bugs.python.org  Tue Apr 21 02:51:24 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 21 Apr 2020 06:51:24 +0000
Subject: [issue40286] Add randbytes() method to random.Random
In-Reply-To: <1586903418.02.0.530735802731.issue40286@roundup.psfhosted.org>
Message-ID: <1587451884.73.0.115126773867.issue40286@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

$ ./python -m timeit -s 'import random' 'random.randbytes(10**6)'
200 loops, best of 5: 1.36 msec per loop

$ ./python -m timeit -s 'import random' 'random.getrandbits(10**6*8).to_bytes(10**6, "little")'
50 loops, best of 5: 6.31 msec per loop

The Python implementation is only 5 times slower than the C implementation. I am fine with implementing randbytes() in Python. This would automatically make it depending on the getrandbits() implementation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40286>
_______________________________________

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: [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 03:38:51 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 21 Apr 2020 07:38:51 +0000
Subject: [issue40337] builtins.RuntimeError: Caught RuntimeError in pin memory
 thread for device 0.
In-Reply-To: <1587391255.49.0.649010801229.issue40337@roundup.psfhosted.org>
Message-ID: <1587454731.35.0.843222713245.issue40337@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

Unless the original poster can provide more information (and preferably a way to reproduce this), I'm going to close this.

----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40337>
_______________________________________

From report at bugs.python.org  Tue Apr 21 05:51:40 2020
From: report at bugs.python.org (Yurii Karabas)
Date: Tue, 21 Apr 2020 09:51:40 +0000
Subject: [issue29847] Path takes and ignores **kwargs
In-Reply-To: <1489850567.46.0.646194395205.issue29847@psf.upfronthosting.co.za>
Message-ID: <1587462700.63.0.797709119943.issue29847@roundup.psfhosted.org>


Change by Yurii Karabas <1998uriyyo at gmail.com>:


----------
nosy: +uriyyo
nosy_count: 6.0 -> 7.0
pull_requests: +18959
pull_request: https://github.com/python/cpython/pull/19632

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29847>
_______________________________________

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: [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 06:12:01 2020
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Tue, 21 Apr 2020 10:12:01 +0000
Subject: [issue40351] How to edit "python --help"?
In-Reply-To: <1587463291.28.0.618151648812.issue40351@roundup.psfhosted.org>
Message-ID: <1587463921.97.0.781199437648.issue40351@roundup.psfhosted.org>


R?mi Lapeyre <remi.lapeyre at henki.fr> added the comment:

Hi Nino, the text for `python --help` is here : https://github.com/python/cpython/blob/master/Python/initconfig.c#L28-L130

----------
nosy: +remi.lapeyre

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40351>
_______________________________________

From report at bugs.python.org  Tue Apr 21 06:15:00 2020
From: report at bugs.python.org (raina)
Date: Tue, 21 Apr 2020 10:15:00 +0000
Subject: [issue38977] python3.8 and namedlist1.7 is Incompatible
In-Reply-To: <1575540930.03.0.27673784229.issue38977@roundup.psfhosted.org>
Message-ID: <1587464100.07.0.0912868524838.issue38977@roundup.psfhosted.org>


raina <raina121 at 126.com> added the comment:

Traceback (most recent call last):
  File "c:\users\raina\appdata\local\programs\python\python38\lib\runpy.py", line 193, in _run_module_as_main
    return _run_code(code, main_globals, None,
......  
code = compile(module_node, '<string>', 'exec')
TypeError: required field "posonlyargs" missing from arguments

----------
nosy: +raina

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38977>
_______________________________________

From report at bugs.python.org  Tue Apr 21 07:39:34 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 21 Apr 2020 11:39:34 +0000
Subject: [issue40351] How to edit "python --help"?
In-Reply-To: <1587463291.28.0.618151648812.issue40351@roundup.psfhosted.org>
Message-ID: <1587469174.04.0.872690277956.issue40351@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

Thanks, R?mi.

Nino: Please don't ask help questions on the bug tracker, only report bugs here. For general questions you can try the python-list mailing list or Stack Overflow.

----------
nosy: +eric.smith
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40351>
_______________________________________

From report at bugs.python.org  Tue Apr 21 08:22:18 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 21 Apr 2020 12:22:18 +0000
Subject: [issue40346] Redesign random.Random class inheritance
In-Reply-To: <1587419589.68.0.186666450831.issue40346@roundup.psfhosted.org>
Message-ID: <1587471738.84.0.74477210463.issue40346@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Example with Python 3.8:
---
import random

class MyRandom(random.Random):
    def getrandbits(self, n):
        return 0

my = MyRandom()
print([my.randint(1, 6) for _ in range(3)])
print([my.random() for _ in range(3)])
---

Output:
---
[1, 1, 1]
[0.5654641798814677, 0.610057019404943, 0.7526620665660224]
---

[1, 1, 1] is what I expect, but what are these random [0.5654641798814677, 0.610057019404943, 0.7526620665660224] numbers?

This behavior is surprising me. I would expect the base class to be "empty", not to inherit Mersenne Twister. If I don't implement all required abstract methods: I would either expect an error when the class is created, or at least when the method is called.


Raymond:
> Am not sure I'm comfortable with you defining random() in pure python dividing by BPF -- that seems like a C level decision.

My PR 19631 doesn't change random.Random.random() (still implemented in C) nor random.SystemRandom.random() (same Python implementation): they should produce exactly the same random floating point numbers.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40346>
_______________________________________

From report at bugs.python.org  Tue Apr 21 08:49:42 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 21 Apr 2020 12:49:42 +0000
Subject: [issue40286] Add randbytes() method to random.Random
In-Reply-To: <1586903418.02.0.530735802731.issue40286@roundup.psfhosted.org>
Message-ID: <1587473382.16.0.228487949326.issue40286@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Raymond:
> Also, I don't want randbytes() in the C extension.  We're tried to keep as much of the code as possible in pure Python and only have the MersenneTwister specific code in the C module.  The improves maintainability and makes the code more accessible to a broader audience.

I don't see how 30 lines makes Python so harder to maintain. These lines make the function 4x to 5x faster. We are not talking about 5% or 10% faster. I think that such optimization is worth it. When did we decide to stop optimizing Python?


Raymond:
> The randbytes() method needs to depend on genrandbits().

I created bpo-40346: "Redesign random.Random class inheritance" for a more generic fix, not just randbytes().


Raymond:
> Also, please don't change the name of the genrand_int32() function.  It was a goal to change as little as possible from the official, standard version of the C code at http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/MT2002/emt19937ar.html .

This code was already modified to replace "unsigned long" with "uint32_t" for example. I don't think that renaming genrand_int32() to genrand_uint32() makes the code impossible to maintain. Moreover, it seems like http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/MT2002/emt19937ar.html was not updated for 13 years.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40286>
_______________________________________

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: [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 11:19:11 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 21 Apr 2020 15:19:11 +0000
Subject: [issue40352] SocketHandler silently drops log messages on re-connect
In-Reply-To: <1587474127.52.0.907489557829.issue40352@roundup.psfhosted.org>
Message-ID: <1587482351.52.0.0305407348297.issue40352@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
nosy: +vinay.sajip

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40352>
_______________________________________

From report at bugs.python.org  Tue Apr 21 11:23:18 2020
From: report at bugs.python.org (hai shi)
Date: Tue, 21 Apr 2020 15:23:18 +0000
Subject: [issue40237] Test code coverage (C) job of Travis CI fails on
 test_distutils which creates _configtest.gcno file
In-Reply-To: <1586436730.26.0.786791148526.issue40237@roundup.psfhosted.org>
Message-ID: <1587482598.53.0.850523032014.issue40237@roundup.psfhosted.org>


hai shi <shihai1991 at 126.com> added the comment:

> The historical background is code coverage of C code seemed like a good idea, so we set it up. :) Not much else to it.

Hm, code coverage of C code including two parts:
1) coverage of inner c code;
2) extension modules built by distutils;

If I understand correct, we force on 1) is good enough, no?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40237>
_______________________________________

From report at bugs.python.org  Tue Apr 21 11:31:28 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 21 Apr 2020 15:31:28 +0000
Subject: [issue40346] Redesign random.Random class inheritance
In-Reply-To: <1587419589.68.0.186666450831.issue40346@roundup.psfhosted.org>
Message-ID: <1587483088.1.0.379988317318.issue40346@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

It may be time to start emitting a warning if a Random subclass overrides random() but not getrandbits() or vice versa.

If you only override random(), methods which rely on generating random integers will use worse algorithm (slightly less uniform). If you only override getrandbits(), -- it is even worse, methods which rely on generating random floating point number will be not affected.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40346>
_______________________________________

From report at bugs.python.org  Tue Apr 21 11:40:31 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 21 Apr 2020 15:40:31 +0000
Subject: [issue40346] Redesign random.Random class inheritance
In-Reply-To: <1587419589.68.0.186666450831.issue40346@roundup.psfhosted.org>
Message-ID: <1587483631.7.0.924983920129.issue40346@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> It may be time to start emitting a warning if a Random subclass overrides random() but not getrandbits() or vice versa.

Does someone know if there are users outside the stdlib of random subclass which only implements random()? I guess that a deprecation warning should help us to know :-)

There is also an implementation detail: technically, it's also sems to possible to only implement _randbelow(): see __init_subclass__(). But I'm not sure what happens in Python 3.8 if you implement _randbelow() but not random() not getrandbits().

In my experience, all RNG either generates random bits or random bytes, but not directly random floats. Usually, floats are computed from the other operations: that's what I'm proposing in BaseRandom. random() is now computed from getrandbits(). But it remains possible to override random(), as done in random.Random.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40346>
_______________________________________

From report at bugs.python.org  Tue Apr 21 11:41:57 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 21 Apr 2020 15:41:57 +0000
Subject: [issue40237] Test code coverage (C) job of Travis CI fails on
 test_distutils which creates _configtest.gcno file
In-Reply-To: <1586436730.26.0.786791148526.issue40237@roundup.psfhosted.org>
Message-ID: <1587483717.63.0.0489036849416.issue40237@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Brett:
> The historical background is code coverage of C code seemed like a good idea, so we set it up. :) Not much else to it.

If there is no user of code coverage *on pull requests*, maybe the simplest fix is to remove this job.

There is also Codecov service running somehow on Python branches through GitHub integration.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40237>
_______________________________________

From report at bugs.python.org  Tue Apr 21 12:12:16 2020
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Tue, 21 Apr 2020 16:12:16 +0000
Subject: [issue40352] SocketHandler silently drops log messages on re-connect
In-Reply-To: <1587474127.52.0.907489557829.issue40352@roundup.psfhosted.org>
Message-ID: <1587485536.95.0.00505560962378.issue40352@roundup.psfhosted.org>


R?mi Lapeyre <remi.lapeyre at henki.fr> added the comment:

On one hand it's bad messages get lost, one the other retrying to send the message would take a lot of time and make `SocketHandler` very slow.

Maybe we could had the record to a very short queue so we can retry to send it with the next message?

----------
nosy: +remi.lapeyre

_______________________________________
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: [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 12:35:22 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 21 Apr 2020 16:35:22 +0000
Subject: [issue40353] Add an optional "strict" check to zip
In-Reply-To: <1587486778.34.0.294525065748.issue40353@roundup.psfhosted.org>
Message-ID: <1587486922.89.0.957526698071.issue40353@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

It would be better to implement it as a separate function.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40353>
_______________________________________

From report at bugs.python.org  Tue Apr 21 12:36:40 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 21 Apr 2020 16:36:40 +0000
Subject: [issue40353] Add an optional "strict" check to zip
In-Reply-To: <1587486778.34.0.294525065748.issue40353@roundup.psfhosted.org>
Message-ID: <1587487000.22.0.294661840401.issue40353@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Also you can just get a ready implementation from more-tertools.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40353>
_______________________________________

From report at bugs.python.org  Tue Apr 21 12:39:58 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 21 Apr 2020 16:39:58 +0000
Subject: [issue40353] Add an optional "strict" check to zip
In-Reply-To: <1587486778.34.0.294525065748.issue40353@roundup.psfhosted.org>
Message-ID: <1587487198.11.0.810507366255.issue40353@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40353>
_______________________________________

From report at bugs.python.org  Tue Apr 21 12:41:20 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 21 Apr 2020 16:41:20 +0000
Subject: [issue40352] SocketHandler silently drops log messages on re-connect
In-Reply-To: <1587474127.52.0.907489557829.issue40352@roundup.psfhosted.org>
Message-ID: <1587487280.55.0.453687605856.issue40352@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

If sending log messages is not guaranteed, we could use UDP. But when we use TCP it is expected that log messages will not be lost.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40352>
_______________________________________

From report at bugs.python.org  Tue Apr 21 12:44:54 2020
From: report at bugs.python.org (Ram Rachum)
Date: Tue, 21 Apr 2020 16:44:54 +0000
Subject: [issue40353] Add an optional "strict" check to zip
In-Reply-To: <1587486778.34.0.294525065748.issue40353@roundup.psfhosted.org>
Message-ID: <1587487494.14.0.913862091691.issue40353@roundup.psfhosted.org>


Ram Rachum <ram at rachum.com> added the comment:

Here are the tests I made: https://github.com/cool-RR/cpython/commit/766409748a107f290997b0cfab5aa19d0c2888e5

----------

_______________________________________
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: [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 13:34:05 2020
From: report at bugs.python.org (Ned Deily)
Date: Tue, 21 Apr 2020 17:34:05 +0000
Subject: [issue40164] Upgrade Windows and macOS installer builds to OpenSSL
 1.1.1g
In-Reply-To: <1585875388.92.0.251240838882.issue40164@roundup.psfhosted.org>
Message-ID: <1587490445.28.0.0852930108092.issue40164@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

And today (2020-04-21) 1.1.1g is released with a high severity fix.

----------
title: Upgrade Windows and macOS installer builds to OpenSSL 1.1.1f -> Upgrade Windows and macOS installer builds to OpenSSL 1.1.1g

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40164>
_______________________________________

From report at bugs.python.org  Tue Apr 21 13:58:22 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 21 Apr 2020 17:58:22 +0000
Subject: [issue40354] problem when using yield
In-Reply-To: <1587488716.21.0.425548141738.issue40354@roundup.psfhosted.org>
Message-ID: <1587491902.84.0.422260134352.issue40354@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Which part of the behaviour do you think is a bug?

In version1, you want to think of the yield expression as though it were bracketed like this:

    result = yield (a+100 if b>100 else (yield a))

With the particular values of a and b that you have, that statement is equivalent to this:

    result = yield (yield 0)

This yields two values to the consumer: a `0` from the inner yield, followed by a None (or whatever was "sent" into the generator, if applicable) for the out yield.

In version 2, the corresponding line simplifies to just

    result = yield 0

So no, I don't think these two versions of the code should behave the same, and I don't think there's any bug here.

----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40354>
_______________________________________

From report at bugs.python.org  Tue Apr 21 14:08:00 2020
From: report at bugs.python.org (Kjell Braden)
Date: Tue, 21 Apr 2020 18:08:00 +0000
Subject: [issue39148] DatagramProtocol + IPv6 does not work with
 ProactorEventLoop
In-Reply-To: <1577530511.62.0.532247879973.issue39148@roundup.psfhosted.org>
Message-ID: <1587492480.97.0.611563969053.issue39148@roundup.psfhosted.org>


Kjell Braden <k.python at brdn.eu> added the comment:

Please let me know if there is anything else I can do to get this going.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39148>
_______________________________________

From report at bugs.python.org  Tue Apr 21 15:14:11 2020
From: report at bugs.python.org (Timothy Geiser)
Date: Tue, 21 Apr 2020 19:14:11 +0000
Subject: [issue33065] IDLE debugger: failure stepping through module loading
In-Reply-To: <1520917336.65.0.467229070634.issue33065@psf.upfronthosting.co.za>
Message-ID: <1587496451.54.0.1819289458.issue33065@roundup.psfhosted.org>


Timothy Geiser <slimshady007 at inbox.lv> added the comment:

I wish I could be more helpful than to just pipe up with a "this bug affects me, too," note, but wanted to poke this bug report since it's been dormant for 14 months.
With Python 3.8.2 I tried using the pgpdump module (version 1.5, installed from pip) on Windows 10 and wanted to step through how it worked. As soon as I enabled the debugger in IDLE it stopped working, throwing a very similar stack trace. Here's the MWE:

>>> import pgpdump
>>> <turn on debugger, Locals is checked by default>
[DEBUG ON]
>>> pgpdump.BinaryData(b'')
<focus auto-switches to debug window>
<click Step button>
Traceback (most recent call last):
  File "<pyshell#1>", line 1, in <module>
    pgpdump.BinaryData(b'')
  File "C:\Python38\lib\site-packages\pgpdump\data.py", line 13, in __init__
    if not data:
  File "C:\Python38\lib\site-packages\pgpdump\data.py", line 13, in __init__
    if not data:
  File "C:\Python38\lib\bdb.py", line 88, in trace_dispatch
    return self.dispatch_line(frame)
  File "C:\Python38\lib\bdb.py", line 112, in dispatch_line
    self.user_line(frame)
  File "C:\Python38\lib\idlelib\debugger.py", line 24, in user_line
    self.gui.interaction(message, frame)
AttributeError: 'BinaryData' object has no attribute 'length'

This error only occurs when the Locals checkbox in the debugging window is checked - it runs as expected as long as Locals is unchecked (this minimum [not]working example throws a "pgpdump.utils.PgpdumpException: no data to parse" error, as it should). A longer example with actual data will run for several steps while Locals is unchecked, but fails with the first Step once Locals is checked. A side note is that the specific error here is that the class BinaryData is being asked about it's 'length', rather than the OP's error of _ModuleLock not having a 'name'
Is there anything else I can do to help fix this, given that I'm not familiar with programming bdb or the IDLE debugger GUI?

----------
nosy: +geitda

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33065>
_______________________________________

From report at bugs.python.org  Tue Apr 21 15:19:59 2020
From: report at bugs.python.org (Kyle Stanley)
Date: Tue, 21 Apr 2020 19:19:59 +0000
Subject: [issue34037] asyncio: BaseEventLoop.close() shutdowns the executor
 without waiting causing leak of dangling threads
In-Reply-To: <1530658646.63.0.56676864532.issue34037@psf.upfronthosting.co.za>
Message-ID: <1587496799.81.0.563911677618.issue34037@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:

> Kyle: Can you please add a short sentence there to document the new requirement?

Yep, I'll open a PR soon. I'm glad this is coming up now rather than post-release, thanks for bringing attention to it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34037>
_______________________________________

From report at bugs.python.org  Tue Apr 21 15:47:06 2020
From: report at bugs.python.org (Daniel Holth)
Date: Tue, 21 Apr 2020 19:47:06 +0000
Subject: [issue40235] confusing documentation for IOBase.__exit__
In-Reply-To: <1586404042.0.0.215231917986.issue40235@roundup.psfhosted.org>
Message-ID: <1587498426.5.0.684203821656.issue40235@roundup.psfhosted.org>


Daniel Holth <dholth at fastmail.fm> added the comment:

Possibly the best io module example I've found https://github.com/python/cpython/blob/master/Lib/_compression.py

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40235>
_______________________________________

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: [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 16:03:31 2020
From: report at bugs.python.org (Kyle Stanley)
Date: Tue, 21 Apr 2020 20:03:31 +0000
Subject: [issue34037] asyncio: BaseEventLoop.close() shutdowns the executor
 without waiting causing leak of dangling threads
In-Reply-To: <1530658646.63.0.56676864532.issue34037@psf.upfronthosting.co.za>
Message-ID: <1587499411.01.0.480964923711.issue34037@roundup.psfhosted.org>


Change by Kyle Stanley <aeros167 at gmail.com>:


----------
pull_requests: +18960
stage: resolved -> patch review
pull_request: https://github.com/python/cpython/pull/19634

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34037>
_______________________________________

From report at bugs.python.org  Tue Apr 21 16:33:45 2020
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Tue, 21 Apr 2020 20:33:45 +0000
Subject: [issue40355] The ast module fails to reject certain malformed nodes
In-Reply-To: <1587499162.97.0.267428394248.issue40355@roundup.psfhosted.org>
Message-ID: <1587501225.24.0.763971005522.issue40355@roundup.psfhosted.org>


Change by R?mi Lapeyre <remi.lapeyre at henki.fr>:


----------
nosy: +remi.lapeyre

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40355>
_______________________________________

From report at bugs.python.org  Tue Apr 21 16:50:55 2020
From: report at bugs.python.org (Kyle Stanley)
Date: Tue, 21 Apr 2020 20:50:55 +0000
Subject: [issue34037] asyncio: BaseEventLoop.close() shutdowns the executor
 without waiting causing leak of dangling threads
In-Reply-To: <1530658646.63.0.56676864532.issue34037@psf.upfronthosting.co.za>
Message-ID: <1587502255.38.0.702645792556.issue34037@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:


New changeset 9c82ea7868a1c5ecf88891c627b5c399357eb05e by Kyle Stanley in branch 'master':
bpo-34037: Add Python API whatsnew for loop.shutdown_default_executor() (#19634)
https://github.com/python/cpython/commit/9c82ea7868a1c5ecf88891c627b5c399357eb05e


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34037>
_______________________________________

From report at bugs.python.org  Tue Apr 21 17:02:35 2020
From: report at bugs.python.org (Steve Dower)
Date: Tue, 21 Apr 2020 21:02:35 +0000
Subject: [issue40164] Upgrade Windows and macOS installer builds to OpenSSL
 1.1.1g
In-Reply-To: <1585875388.92.0.251240838882.issue40164@roundup.psfhosted.org>
Message-ID: <1587502955.75.0.779043507349.issue40164@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

That'll teach me for being so quick on this...

Are we even impacted by the issue though? I don't see any calls to SSL_check_chain() in our code or the SSL sources.

Advisory: https://www.openssl.org/news/secadv/20200421.txt
Full diff: https://github.com/openssl/openssl/compare/OpenSSL_1_1_1f...OpenSSL_1_1_1g

----------
nosy: +christian.heimes

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40164>
_______________________________________

From report at bugs.python.org  Tue Apr 21 17:03:28 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Tue, 21 Apr 2020 21:03:28 +0000
Subject: [issue40355] The ast module fails to reject certain malformed nodes
In-Reply-To: <1587499162.97.0.267428394248.issue40355@roundup.psfhosted.org>
Message-ID: <1587503008.85.0.981382898888.issue40355@roundup.psfhosted.org>


Batuhan Taskaya <batuhanosmantaskaya at gmail.com> added the comment:

See https://bugs.python.org/msg360767 for ast.unparse's point of view regarding malformed nodes.

----------
nosy: +BTaskaya, pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40355>
_______________________________________

From report at bugs.python.org  Tue Apr 21 17:23:14 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 21 Apr 2020 21:23:14 +0000
Subject: [issue39943] Meta: Clean up various issues in C internals
In-Reply-To: <1583983387.49.0.277830283994.issue39943@roundup.psfhosted.org>
Message-ID: <1587504194.06.0.539175445902.issue39943@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> Yes, it is a consequence of PR 19345. But it looks like a compiler bug. It complains about implicit conversion from `const void **` to `void *` in memcpy() and PyMem_Del().

Is it possible to add an explicit cast to make the compiler warnings quiet?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39943>
_______________________________________

From report at bugs.python.org  Tue Apr 21 17:31:38 2020
From: report at bugs.python.org (Kyle Stanley)
Date: Tue, 21 Apr 2020 21:31:38 +0000
Subject: [issue34037] asyncio: BaseEventLoop.close() shutdowns the executor
 without waiting causing leak of dangling threads
In-Reply-To: <1530658646.63.0.56676864532.issue34037@psf.upfronthosting.co.za>
Message-ID: <1587504698.07.0.40644078744.issue34037@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:

PR-19634 should address the primary issue of documenting in the 3.9 whatsnew that alternative event loops should implement loop.shutdown_default_executor().

For reference, here's the implementation in BaseEventLoop: https://github.com/python/cpython/blob/9c82ea7868a1c5ecf88891c627b5c399357eb05e/Lib/asyncio/base_events.py#L556-L574. I believe it could be used in alternative event loops without too much modification.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34037>
_______________________________________

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: [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: [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 18:05:23 2020
From: report at bugs.python.org (Brandt Bucher)
Date: Tue, 21 Apr 2020 22:05:23 +0000
Subject: [issue40353] Add an optional "strict" check to zip
In-Reply-To: <1587486778.34.0.294525065748.issue40353@roundup.psfhosted.org>
Message-ID: <1587506723.54.0.775832289965.issue40353@roundup.psfhosted.org>


Brandt Bucher <brandtbucher at gmail.com> added the comment:

Slight edit: if the shortest iterator is "first", one additional item will have to be drawn from the next non-exhausted iterator. I missed that, initially.

> It would be better to implement it as a separate function.

I disagree. It's not intrusive here; I think the handful of new lines this needs to fit into the existing zip implementation (which already handles most of this logic) is more maintainable than a whole new object/function living somewhere else.

> Also you can just get a ready implementation from more-tertools.

I've found that there are several places where our own standard library could immediately benefit from this change.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40353>
_______________________________________

From report at bugs.python.org  Tue Apr 21 18:08:38 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 21 Apr 2020 22:08:38 +0000
Subject: [issue33065] IDLE debugger: failure stepping through module loading
In-Reply-To: <1520917336.65.0.467229070634.issue33065@psf.upfronthosting.co.za>
Message-ID: <1587506918.49.0.839348636.issue33065@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Timothy, this is already more helpful than a simple 'me too'.  Can you reduce pgdata.dump to a truly minimal file that exhibits the bug?  and then upload it?  Installing any package into my local copy of the master CPython repository is problemmatical.  What I need is a file that I can download elsewhere, load into IDLE, run from a branch for this issue, and edit and rerun.  From the traceback, it appears that it might be as simple as 

class BinaryData:
    def __init__(self, bd):
        <minimal body>

BinaryData(b'')

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33065>
_______________________________________

From report at bugs.python.org  Tue Apr 21 18:16:14 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Tue, 21 Apr 2020 22:16:14 +0000
Subject: [issue38870] Expose ast.unparse in the ast module
In-Reply-To: <1574289269.61.0.90605518345.issue38870@roundup.psfhosted.org>
Message-ID: <1587507374.27.0.165179650675.issue38870@roundup.psfhosted.org>


Change by Batuhan Taskaya <batuhanosmantaskaya at gmail.com>:


----------
pull_requests: +18961
pull_request: https://github.com/python/cpython/pull/19636

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38870>
_______________________________________

From report at bugs.python.org  Tue Apr 21 18:23:02 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 21 Apr 2020 22:23:02 +0000
Subject: [issue40138] Windows implementation of os.waitpid() truncates the
 exit status (status << 8)
In-Reply-To: <1585760727.67.0.797995887325.issue40138@roundup.psfhosted.org>
Message-ID: <1587507782.12.0.171575394805.issue40138@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
keywords: +patch
pull_requests: +18962
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19637

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40138>
_______________________________________

From report at bugs.python.org  Tue Apr 21 18:41:51 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 21 Apr 2020 22:41:51 +0000
Subject: [issue40357] asyncio: will shutdown_default_executor work in single
 step (stop, run_forever) mode?
In-Reply-To: <1587506447.82.0.117857372941.issue40357@roundup.psfhosted.org>
Message-ID: <1587508911.5.0.0176037394979.issue40357@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy: +aeros

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40357>
_______________________________________

From report at bugs.python.org  Tue Apr 21 18:41:58 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 21 Apr 2020 22:41:58 +0000
Subject: [issue40357] asyncio: will shutdown_default_executor work in single
 step (stop, run_forever) mode?
In-Reply-To: <1587506447.82.0.117857372941.issue40357@roundup.psfhosted.org>
Message-ID: <1587508918.22.0.742501059559.issue40357@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy:  -vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40357>
_______________________________________

From report at bugs.python.org  Tue Apr 21 18:55:41 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Tue, 21 Apr 2020 22:55:41 +0000
Subject: [issue40353] Add an optional "strict" check to zip
In-Reply-To: <1587486778.34.0.294525065748.issue40353@roundup.psfhosted.org>
Message-ID: <1587509741.46.0.183797371764.issue40353@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

I don't think this is needed in the builtin zip at all. I think that there is no consensus on Python-Ideas that this is needed or desirable.

I especially don't think the API should be a keyword flag on zip. Flag arguments which change the behaviour of functions are at best a code-smell and at worst an outright anti-pattern.

It is not always practical to avoid them, but in this case it certainly is: if we need this (I'm not sure we do) then a separate zip_strict() function in itertools next to zip_longest() is better than a flag on the builtin zip.

(That's not to say that the zip_strict iterator must be an independent class to the builtin zip and itertools.zip_longest, they can share a common backend. It is the public API I am referring to.)

I've already posted an implementation on the mailing list, it is about half a dozen or so lines of Python. Another independent implementation is available from the current development branch of more-itertools, more or less the same only with a less informative error message.

Personally, the fact that this has only just hit more-itertools counts as a point against this function to me: more-itertools is the "everything including the kitchen sink" grab-bag of iterator tools, and even they didn't think they needed "zip_equal" until version literally a few days ago. It's so new it isn't even documented yet:

https://pypi.org/project/more-itertools/

----------
nosy: +steven.daprano

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40353>
_______________________________________

From report at bugs.python.org  Tue Apr 21 18:56:29 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Tue, 21 Apr 2020 22:56:29 +0000
Subject: [issue40353] Add an optional "strict" check to zip
In-Reply-To: <1587486778.34.0.294525065748.issue40353@roundup.psfhosted.org>
Message-ID: <1587509789.69.0.261074509924.issue40353@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

> independent class

Oops, sorry I mean independent implementation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40353>
_______________________________________

From report at bugs.python.org  Tue Apr 21 19:12:57 2020
From: report at bugs.python.org (Furkan Onder)
Date: Tue, 21 Apr 2020 23:12:57 +0000
Subject: [issue27635] pickle documentation says that unpickling may not call
 __new__
In-Reply-To: <1469639245.7.0.966654223743.issue27635@psf.upfronthosting.co.za>
Message-ID: <1587510777.75.0.741379836809.issue27635@roundup.psfhosted.org>


Furkan Onder <furkanonder at protonmail.com> added the comment:

The problem is fixed, issue can be closed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27635>
_______________________________________

From report at bugs.python.org  Tue Apr 21 19:13:00 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 21 Apr 2020 23:13:00 +0000
Subject: [issue32912] Raise non-silent warning for invalid escape sequences
In-Reply-To: <1519324497.82.0.467229070634.issue32912@psf.upfronthosting.co.za>
Message-ID: <1587510780.1.0.756448321477.issue32912@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32912>
_______________________________________

From report at bugs.python.org  Tue Apr 21 19:19:10 2020
From: report at bugs.python.org (Furkan Onder)
Date: Tue, 21 Apr 2020 23:19:10 +0000
Subject: [issue38770] Pickle handle self references in classes
In-Reply-To: <1573506617.89.0.382822936013.issue38770@roundup.psfhosted.org>
Message-ID: <1587511150.66.0.505514806989.issue38770@roundup.psfhosted.org>


Furkan Onder <furkanonder at protonmail.com> added the comment:

I ran your script and didn't get RecursionError. The issue seems to be fixed.

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.
>>> from __future__ import print_function
>>> 
>>> import pickle, sys
>>> 
>>> class Foo:
...     __name__ = __qualname__ = "Foo.ref"
...     pass
... 
>>> Foo.ref = Foo
>>> 
>>> print(sys.version_info)
sys.version_info(major=3, minor=8, micro=2, releaselevel='final', serial=0)
>>> for proto in range(0, pickle.HIGHEST_PROTOCOL + 1):
...     print("{}:".format(proto), end=" ")
...     try:
...         pkl = pickle.dumps(Foo, proto)
...         print("Dump OK,", end=" ")
...         assert(pickle.loads(pkl) is Foo)
...         print("Load OK,")
...     except Exception as err:
...         print(repr(err))
... 
0: PicklingError("Can't pickle <class '__main__.Foo.ref'>: import of module '__main__' failed")
1: PicklingError("Can't pickle <class '__main__.Foo.ref'>: import of module '__main__' failed")
2: PicklingError("Can't pickle <class '__main__.Foo.ref'>: import of module '__main__' failed")
3: PicklingError("Can't pickle <class '__main__.Foo.ref'>: import of module '__main__' failed")
4: Dump OK, Load OK,
5: Dump OK, Load OK,
>>>

----------
nosy: +furkanonder

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38770>
_______________________________________

From report at bugs.python.org  Tue Apr 21 19:20:38 2020
From: report at bugs.python.org (Zackery Spytz)
Date: Tue, 21 Apr 2020 23:20:38 +0000
Subject: [issue34204] Bump the default pickle protocol in shelve
In-Reply-To: <1532423802.47.0.56676864532.issue34204@psf.upfronthosting.co.za>
Message-ID: <1587511238.83.0.408366633857.issue34204@roundup.psfhosted.org>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
keywords: +patch
nosy: +ZackerySpytz
nosy_count: 4.0 -> 5.0
pull_requests: +18963
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19639

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34204>
_______________________________________

From report at bugs.python.org  Tue Apr 21 19:20:55 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 21 Apr 2020 23:20:55 +0000
Subject: [issue40327] list(sys.modules.items()) can throw RuntimeError:
 dictionary changed size during iteration
In-Reply-To: <1587284646.11.0.468516211586.issue40327@roundup.psfhosted.org>
Message-ID: <1587511255.55.0.983687056681.issue40327@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:


New changeset 75bedbe2ed4119ff18a2ea86c544b3cf08a92e75 by Raymond Hettinger in branch 'master':
bpo-40327: Improve atomicity, speed, and memory efficiency of the items() loop (GH-19628)
https://github.com/python/cpython/commit/75bedbe2ed4119ff18a2ea86c544b3cf08a92e75


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40327>
_______________________________________

From report at bugs.python.org  Tue Apr 21 19:21:04 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 21 Apr 2020 23:21:04 +0000
Subject: [issue40327] list(sys.modules.items()) can throw RuntimeError:
 dictionary changed size during iteration
In-Reply-To: <1587284646.11.0.468516211586.issue40327@roundup.psfhosted.org>
Message-ID: <1587511264.49.0.459467717694.issue40327@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
nosy: +miss-islington
nosy_count: 3.0 -> 4.0
pull_requests: +18964
pull_request: https://github.com/python/cpython/pull/19640

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40327>
_______________________________________

From report at bugs.python.org  Tue Apr 21 19:23:55 2020
From: report at bugs.python.org (Furkan Onder)
Date: Tue, 21 Apr 2020 23:23:55 +0000
Subject: [issue39817] CRITICAL: TypeError: cannot pickle 'generator'
In-Reply-To: <1583093867.42.0.0359831443421.issue39817@roundup.psfhosted.org>
Message-ID: <1587511435.6.0.982133337233.issue39817@roundup.psfhosted.org>


Furkan Onder <furkanonder at protonmail.com> added the comment:

Can you send your code?

----------
nosy: +furkanonder

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39817>
_______________________________________

From report at bugs.python.org  Tue Apr 21 19:24:55 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 21 Apr 2020 23:24:55 +0000
Subject: [issue40356] OverflowError: mktime argument out of range
In-Reply-To: <1587505343.63.0.318003481208.issue40356@roundup.psfhosted.org>
Message-ID: <1587511495.67.0.791228902788.issue40356@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

FWIW, that time.struct_time value is:

>>> d
time.struct_time(tm_year=2020, tm_mon=4, tm_mday=16, tm_hour=19, tm_min=12, tm_sec=35, tm_wday=3, tm_yday=107, tm_isdst=1)


I don't get an error on 3.7.4 from Cygwin or 3.7.6 from stock Fedora.

----------
components: +Interpreter Core -C API
nosy: +eric.smith
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40356>
_______________________________________

From report at bugs.python.org  Tue Apr 21 19:43:26 2020
From: report at bugs.python.org (Ned Deily)
Date: Tue, 21 Apr 2020 23:43:26 +0000
Subject: [issue40164] Upgrade Windows and macOS installer builds to OpenSSL
 1.1.1g
In-Reply-To: <1585875388.92.0.251240838882.issue40164@roundup.psfhosted.org>
Message-ID: <1587512606.74.0.834716507286.issue40164@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

> Are we even impacted by the issue though?

Certainly we use a check_chain function at least indirectly but, whether that path is vulnerable, dunno.

But, in any case, we will no doubt be pinged about it so best to be ahead of the curve, I think.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40164>
_______________________________________

From report at bugs.python.org  Tue Apr 21 19:57:29 2020
From: report at bugs.python.org (Furkan Onder)
Date: Tue, 21 Apr 2020 23:57:29 +0000
Subject: [issue38770] Pickle handle self references in classes
In-Reply-To: <1573506617.89.0.382822936013.issue38770@roundup.psfhosted.org>
Message-ID: <1587513449.53.0.983813022761.issue38770@roundup.psfhosted.org>


Furkan Onder <furkanonder at protonmail.com> added the comment:

Ahh. I misunderstood the problem. Pickle behaves differently when it is a circular reference. If you have a solution, I am waiting with curiosity.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38770>
_______________________________________

From report at bugs.python.org  Tue Apr 21 20:02:28 2020
From: report at bugs.python.org (Furkan Onder)
Date: Wed, 22 Apr 2020 00:02:28 +0000
Subject: [issue39423] Process finished with exit code -1073741819 (0xC0000005)
 when trying to access data from a pickled file
In-Reply-To: <1579709155.26.0.28815846735.issue39423@roundup.psfhosted.org>
Message-ID: <1587513748.61.0.311804659292.issue39423@roundup.psfhosted.org>


Furkan Onder <furkanonder at protonmail.com> added the comment:

Hi,
Can you share the program codes to better understand the problem?

----------
nosy: +furkanonder

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39423>
_______________________________________

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: [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:10:28 2020
From: report at bugs.python.org (Timothy Geiser)
Date: Wed, 22 Apr 2020 00:10:28 +0000
Subject: [issue33065] IDLE debugger: failure stepping through module loading
In-Reply-To: <1520917336.65.0.467229070634.issue33065@psf.upfronthosting.co.za>
Message-ID: <1587514228.95.0.886486773556.issue33065@roundup.psfhosted.org>


Timothy Geiser <slimshady007 at inbox.lv> added the comment:

It looks like the IDLE debugger seems to call repr on objects to present in the Locals list, even before they've been properly initialized. If __repr__ needs to refer to variables that don't exist until __init__ is done (and I don't think it's unreasonable for __repr__ to assume that __init__ is indeed finished), the debugger either needs wait until __init__ has completed on any given instance before trying to repr it, or otherwise needs to catch a potentially very wide range of exceptions that might be raised from calling __repr__ so early. I prefer the latter solution, since any buggy code that (effectively) crashes on it's __repr__ (for whatever reason) will probably bring the debugger to it's knees.
I played around with pdb directly and can sort of get the same thing if I ask for __repr__ too early:

 1 Python 3.8.2 (tags/v3.8.2:7b3ab59, Feb 25 2020, 23:03:10) [MSC v.1916 64 bit (AMD64)] on win32
 2 Type "help", "copyright", "credits" or "license" for more information.
 3 >>> import data
 4 >>> import pdb
 5 >>> pdb.run("data.BinaryData(b'some data')")
 6 > <string>(1)<module>()
 7 (Pdb) step
 8 --Call--
 9 > c:\users\geitd\documents\python\data.py(4)__init__()
10 -> def __init__(self, data):
11 (Pdb) p self
12 (Pdb) p BinaryData.__repr__(self)
13 *** AttributeError: 'BinaryData' object has no attribute 'length'
14 (Pdb) step
15 > c:\users\geitd\documents\python\data.py(5)__init__()
16 -> if not data:
17 (Pdb) step
18 > c:\users\geitd\documents\python\data.py(7)__init__()
19 -> if len(data) <= 1:
20 (Pdb) step
21 > c:\users\geitd\documents\python\data.py(10)__init__()
22 -> self.data = data
23 (Pdb) step
24 > c:\users\geitd\documents\python\data.py(11)__init__()
25 -> self.length = len(data)
26 (Pdb) p self
27 (Pdb) p BinaryData.__repr__(self)
28 *** AttributeError: 'BinaryData' object has no attribute 'length'
29 (Pdb) step
30 --Return--
31 > c:\users\geitd\documents\python\data.py(11)__init__()->None
32 -> self.length = len(data)
33 (Pdb) p self
34 <BinaryData: length 9>
35 (Pdb) p BinaryData.__repr__(self)
36 '<BinaryData: length 9>'

Note that line 11 didn't return anything, but didn't have any bad results, whereas the way I phrased line 12 gave the exact same error the IDLE debugger threw.
Lines 26 and 27 towards the end of __init__ came out the same, but after the --Return-- on 30, either phrasing gives what you'd expect.
I suppose the TL;DR is to take the mechanism that gives the correct behavior of 'p self' in pdb and copy it over to the IDLE debugger (or whatever other mechanism is necessary).

Is this enough for you to work from?

----------
Added file: https://bugs.python.org/file49082/data.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33065>
_______________________________________

From report at bugs.python.org  Tue Apr 21 20:11:11 2020
From: report at bugs.python.org (Dennis Sweeney)
Date: Wed, 22 Apr 2020 00:11:11 +0000
Subject: [issue39939] PEP 616: Add str methods to remove prefix or suffix
In-Reply-To: <1583953898.19.0.613718077904.issue39939@roundup.psfhosted.org>
Message-ID: <1587514271.2.0.381352900031.issue39939@roundup.psfhosted.org>


Dennis Sweeney <sweeney.dennis650 at gmail.com> added the comment:

I'm personally -0 for underscores -- they might slightly improve readability of the function name in isolation but may also add confusion about which methods have underscores.  Only one out of the 45 non-dunder str methods has an underscore right now:

    >>> meths = [x for x in dir(str) if not x.startswith('__')]
    >>> [x for x in meths if '_' in x]
    ['format_map']
    >>> [x for x in meths if '_' not in x]
    ['capitalize', 'casefold', 'center', 'count', 'encode', 'endswith', 'expandtabs', 'find', 'format', 'index', 'isalnum', 'isalpha', 'isascii', 'isdecimal', 'isdigit', 'isidentifier', 'islower', 'isnumeric', 'isprintable', 'isspace', 'istitle', 'isupper', 'join', 'ljust', 'lower', 'lstrip', 'maketrans', 'partition', 'replace', 'rfind', 'rindex', 'rjust', 'rpartition', 'rsplit', 'rstrip', 'split', 'splitlines', 'startswith', 'strip', 'swapcase', 'title', 'translate', 'upper', 'zfill']

Maybe I'm wrong, but it seemed to me that most of the discussions to date had arrived at leaving out underscores.  Is there a process or appropriate channel to continue this discussion now that the PEP is accepted?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39939>
_______________________________________

From report at bugs.python.org  Tue Apr 21 20:14:52 2020
From: report at bugs.python.org (xie)
Date: Wed, 22 Apr 2020 00:14:52 +0000
Subject: [issue40354] problem when using yield
In-Reply-To: <1587488716.21.0.425548141738.issue40354@roundup.psfhosted.org>
Message-ID: <1587514492.33.0.444302627809.issue40354@roundup.psfhosted.org>


xie <xsmyqf at qq.com> added the comment:

Okay,I agree with you.I did not get the priority.

----------
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40354>
_______________________________________

From report at bugs.python.org  Tue Apr 21 20:15:18 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 22 Apr 2020 00:15:18 +0000
Subject: [issue40346] Redesign random.Random class inheritance
In-Reply-To: <1587419589.68.0.186666450831.issue40346@roundup.psfhosted.org>
Message-ID: <1587514518.56.0.834909769321.issue40346@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

-1   I am opposed to this redesign.  There is no problem being solved that warrants changing a long standing public API.  It is irresponsible to just guess at whether anyone is using the API.  To add randbytes() could have just been a simple two line addition.  None of what is being proposed is necessary -- there are no known user problems being solved.  At best, this is unnecessary code churn.  At worse, it will be a breaking change.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40346>
_______________________________________

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: [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  Tue Apr 21 21:14:10 2020
From: report at bugs.python.org (Dennis Sweeney)
Date: Wed, 22 Apr 2020 01:14:10 +0000
Subject: [issue39939] PEP 616: Add str methods to remove prefix or suffix
In-Reply-To: <1583953898.19.0.613718077904.issue39939@roundup.psfhosted.org>
Message-ID: <1587518050.2.0.449214630166.issue39939@roundup.psfhosted.org>


Dennis Sweeney <sweeney.dennis650 at gmail.com> added the comment:

Oops -- I now see the message on Python-Dev.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39939>
_______________________________________

From report at bugs.python.org  Tue Apr 21 21:20:05 2020
From: report at bugs.python.org (Matthew Davis)
Date: Wed, 22 Apr 2020 01:20:05 +0000
Subject: [issue40359] email.parse part.get_filename() fails to unwrap long
 attachment file names
In-Reply-To: <1587515187.44.0.744042033479.issue40359@roundup.psfhosted.org>
Message-ID: <1587518405.52.0.555971206148.issue40359@roundup.psfhosted.org>


Matthew Davis <ubuntu.one at mdavis.xyz> added the comment:

Ah woops, I mistyped the relevant ticket.

It's issue 36401

https://bugs.python.org/issue36041

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40359>
_______________________________________

From report at bugs.python.org  Tue Apr 21 21:20:37 2020
From: report at bugs.python.org (Matthew Davis)
Date: Wed, 22 Apr 2020 01:20:37 +0000
Subject: [issue40359] email.parse part.get_filename() fails to unwrap long
 attachment file names
In-Reply-To: <1587515187.44.0.744042033479.issue40359@roundup.psfhosted.org>
Message-ID: <1587518437.95.0.185455911502.issue40359@roundup.psfhosted.org>


Matthew Davis <ubuntu.one at mdavis.xyz> added the comment:

36041

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40359>
_______________________________________

From report at bugs.python.org  Tue Apr 21 21:43:54 2020
From: report at bugs.python.org (Anthony Sottile)
Date: Wed, 22 Apr 2020 01:43:54 +0000
Subject: [issue40260] modulefinder traceback regression starting on Windows
In-Reply-To: <1586680620.99.0.514402715757.issue40260@roundup.psfhosted.org>
Message-ID: <1587519834.39.0.139652964241.issue40260@roundup.psfhosted.org>


Anthony Sottile <asottile at umich.edu> added the comment:

This is still failing, but now in a different way:


Traceback (most recent call last):
  File "../debian/pymindeps.py", line 185, in <module>
    main(sys.argv[1:])
  File "../debian/pymindeps.py", line 178, in main
    mf.run_script(arg)
  File "/tmp/code/Lib/modulefinder.py", line 163, in run_script
    self.load_module('__main__', fp, pathname, stuff)
  File "../debian/pymindeps.py", line 92, in load_module
    m = modulefinder.ModuleFinder.load_module(self, fqname,
  File "/tmp/code/Lib/modulefinder.py", line 359, in load_module
    self.scan_code(co, m)
  File "/tmp/code/Lib/modulefinder.py", line 432, in scan_code
    self._safe_import_hook(name, m, fromlist, level=0)
  File "/tmp/code/Lib/modulefinder.py", line 377, in _safe_import_hook
    self.import_hook(name, caller, level=level)
  File "../debian/pymindeps.py", line 42, in import_hook
    return modulefinder.ModuleFinder.import_hook(self, name, caller,
  File "/tmp/code/Lib/modulefinder.py", line 175, in import_hook
    q, tail = self.find_head_package(parent, name)
  File "/tmp/code/Lib/modulefinder.py", line 231, in find_head_package
    q = self.import_module(head, qname, parent)
  File "../debian/pymindeps.py", line 48, in import_module
    m = modulefinder.ModuleFinder.import_module(self,
  File "/tmp/code/Lib/modulefinder.py", line 325, in import_module
    m = self.load_module(fqname, fp, pathname, stuff)
  File "../debian/pymindeps.py", line 92, in load_module
    m = modulefinder.ModuleFinder.load_module(self, fqname,
  File "/tmp/code/Lib/modulefinder.py", line 342, in load_module
    co = compile(fp.read()+b'\n', pathname, 'exec')
TypeError: can only concatenate str (not "bytes") to str

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40260>
_______________________________________

From report at bugs.python.org  Tue Apr 21 21:55:22 2020
From: report at bugs.python.org (Anthony Sottile)
Date: Wed, 22 Apr 2020 01:55:22 +0000
Subject: [issue40260] modulefinder traceback regression starting on Windows
In-Reply-To: <1586680620.99.0.514402715757.issue40260@roundup.psfhosted.org>
Message-ID: <1587520522.22.0.615860335178.issue40260@roundup.psfhosted.org>


Anthony Sottile <asottile at umich.edu> added the comment:

The failure above is `fp` is now a text file but before it was a binary file.  this causes `fp.read()` + `b'\n'` to fail

I can send a patch -- I don't think the `b'\n'` is necessary any more (as far as I can tell it used to be there for an old version of python where `compile(...)` errored if the file did not end in a newline, that's now handled in the parser internally though)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40260>
_______________________________________

From report at bugs.python.org  Tue Apr 21 22:04:45 2020
From: report at bugs.python.org (Anthony Sottile)
Date: Wed, 22 Apr 2020 02:04:45 +0000
Subject: [issue40260] modulefinder traceback regression starting on Windows
In-Reply-To: <1586680620.99.0.514402715757.issue40260@roundup.psfhosted.org>
Message-ID: <1587521085.58.0.71050532998.issue40260@roundup.psfhosted.org>


Change by Anthony Sottile <asottile at umich.edu>:


----------
pull_requests: +18965
pull_request: https://github.com/python/cpython/pull/19641

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40260>
_______________________________________

From report at bugs.python.org  Tue Apr 21 22:05:32 2020
From: report at bugs.python.org (Anthony Sottile)
Date: Wed, 22 Apr 2020 02:05:32 +0000
Subject: [issue40260] modulefinder traceback regression starting on Windows
In-Reply-To: <1586680620.99.0.514402715757.issue40260@roundup.psfhosted.org>
Message-ID: <1587521132.01.0.291779565087.issue40260@roundup.psfhosted.org>


Anthony Sottile <asottile at umich.edu> added the comment:

actually I said that backwards in the previous message -- it was a text file and now it's a binary file

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40260>
_______________________________________

From report at bugs.python.org  Tue Apr 21 22:14:17 2020
From: report at bugs.python.org (Ned Deily)
Date: Wed, 22 Apr 2020 02:14:17 +0000
Subject: [issue40164] Upgrade Windows and macOS installer builds to OpenSSL
 1.1.1g
In-Reply-To: <1585875388.92.0.251240838882.issue40164@roundup.psfhosted.org>
Message-ID: <1587521657.46.0.179374661566.issue40164@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


----------
pull_requests: +18966
pull_request: https://github.com/python/cpython/pull/19642

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40164>
_______________________________________

From report at bugs.python.org  Tue Apr 21 22:41:40 2020
From: report at bugs.python.org (Ned Deily)
Date: Wed, 22 Apr 2020 02:41:40 +0000
Subject: [issue40164] Upgrade Windows and macOS installer builds to OpenSSL
 1.1.1g
In-Reply-To: <1585875388.92.0.251240838882.issue40164@roundup.psfhosted.org>
Message-ID: <1587523300.05.0.188301064468.issue40164@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:


New changeset 783a673f23c5e9ffafe12fe172e119dc0fa2abda by Ned Deily in branch 'master':
bpo-40164: Update macOS installer builds to use OpenSSL 1.1.1g. (GH-19642)
https://github.com/python/cpython/commit/783a673f23c5e9ffafe12fe172e119dc0fa2abda


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40164>
_______________________________________

From report at bugs.python.org  Tue Apr 21 22:41:48 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 22 Apr 2020 02:41:48 +0000
Subject: [issue40164] Upgrade Windows and macOS installer builds to OpenSSL
 1.1.1g
In-Reply-To: <1585875388.92.0.251240838882.issue40164@roundup.psfhosted.org>
Message-ID: <1587523308.57.0.440063208565.issue40164@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
nosy: +miss-islington
nosy_count: 7.0 -> 8.0
pull_requests: +18967
pull_request: https://github.com/python/cpython/pull/19643

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40164>
_______________________________________

From report at bugs.python.org  Tue Apr 21 22:41:56 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 22 Apr 2020 02:41:56 +0000
Subject: [issue40164] Upgrade Windows and macOS installer builds to OpenSSL
 1.1.1g
In-Reply-To: <1585875388.92.0.251240838882.issue40164@roundup.psfhosted.org>
Message-ID: <1587523316.01.0.0526674617051.issue40164@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +18968
pull_request: https://github.com/python/cpython/pull/19644

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40164>
_______________________________________

From report at bugs.python.org  Tue Apr 21 22:47:14 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 22 Apr 2020 02:47:14 +0000
Subject: [issue40358] pathlib's relative_to should behave like os.path.relpath
In-Reply-To: <1587513783.17.0.6950267733.issue40358@roundup.psfhosted.org>
Message-ID: <1587523634.62.0.258911801378.issue40358@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40358>
_______________________________________

From report at bugs.python.org  Tue Apr 21 23:00:34 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 22 Apr 2020 03:00:34 +0000
Subject: [issue40164] Upgrade Windows and macOS installer builds to OpenSSL
 1.1.1g
In-Reply-To: <1585875388.92.0.251240838882.issue40164@roundup.psfhosted.org>
Message-ID: <1587524434.9.0.562470285139.issue40164@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 9e51aab37e9af6fa0fe406fd56184a0aded28e11 by Miss Islington (bot) in branch '3.8':
bpo-40164: Update macOS installer builds to use OpenSSL 1.1.1g. (GH-19642)
https://github.com/python/cpython/commit/9e51aab37e9af6fa0fe406fd56184a0aded28e11


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40164>
_______________________________________

From report at bugs.python.org  Tue Apr 21 23:04:19 2020
From: report at bugs.python.org (Ned Deily)
Date: Wed, 22 Apr 2020 03:04:19 +0000
Subject: [issue40164] Upgrade Windows and macOS installer builds to OpenSSL
 1.1.1g
In-Reply-To: <1585875388.92.0.251240838882.issue40164@roundup.psfhosted.org>
Message-ID: <1587524659.31.0.0351073961346.issue40164@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:


New changeset 7ad3adda9bff8a9055eaf0b66489e8204f1e7cc6 by Miss Islington (bot) in branch '3.7':
bpo-40164: Update macOS installer builds to use OpenSSL 1.1.1g. (GH-19642) (GH-19644)
https://github.com/python/cpython/commit/7ad3adda9bff8a9055eaf0b66489e8204f1e7cc6


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40164>
_______________________________________

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: [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 00:41:28 2020
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 22 Apr 2020 04:41:28 +0000
Subject: [issue40360] Deprecate lib2to3 (and 2to3) for future removal
In-Reply-To: <1587530454.25.0.44181585934.issue40360@roundup.psfhosted.org>
Message-ID: <1587530488.62.0.889660721746.issue40360@roundup.psfhosted.org>


Change by Gregory P. Smith <greg at krypto.org>:


----------
components: +2to3 (2.x to 3.x conversion tool)
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40360>
_______________________________________

From report at bugs.python.org  Wed Apr 22 00:52:00 2020
From: report at bugs.python.org (deekay)
Date: Wed, 22 Apr 2020 04:52:00 +0000
Subject: [issue40314] python code order of magnitude faster than equivalent
 CPython code for simple import statement
In-Reply-To: <1587162924.52.0.924325577944.issue40314@roundup.psfhosted.org>
Message-ID: <1587531120.25.0.624277973398.issue40314@roundup.psfhosted.org>


deekay <dee2thekay42 at gmail.com> added the comment:

The times are correct. It's very noticeable even without using a stopwatch. The C version actually takes 23 seconds to execute.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40314>
_______________________________________

From report at bugs.python.org  Wed Apr 22 00:55:46 2020
From: report at bugs.python.org (Tim Peters)
Date: Wed, 22 Apr 2020 04:55:46 +0000
Subject: [issue40346] Redesign random.Random class inheritance
In-Reply-To: <1587419589.68.0.186666450831.issue40346@roundup.psfhosted.org>
Message-ID: <1587531346.32.0.918296506255.issue40346@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

This wasn't written with subclassing in mind to begin with.  A class was just an obvious way to allow advanced users to construct instances with their own states (e.g., so they could build pseudo-independent generators for parallel programming).

When SystemRandom got added, I believe that did about as little as possible just so that it "would work".

Making it easy to create subclasses was never a goal regardless.

I don't mind if that _becomes_ a goal, but with some disclaimers:

- If that makes any method currently in use slower, it's not worth it.

- Saving bytes in a SystemRandom instance is of no practical value.

So I think I'm agreeing with Raymond that reworking this doesn't solve any actual problem.  But I'm not opposed to making changes for aesthetic reasons, provided such changes don't impose costs beyond the always-present risk of breaking things with any change.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40346>
_______________________________________

From report at bugs.python.org  Wed Apr 22 00:59:47 2020
From: report at bugs.python.org (Shantanu)
Date: Wed, 22 Apr 2020 04:59:47 +0000
Subject: [issue40222] "Zero cost" exception handling
In-Reply-To: <1586338863.3.0.393749013734.issue40222@roundup.psfhosted.org>
Message-ID: <1587531587.34.0.76034269669.issue40222@roundup.psfhosted.org>


Change by Shantanu <hauntsaninja at gmail.com>:


----------
nosy: +hauntsaninja

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40222>
_______________________________________

From report at bugs.python.org  Wed Apr 22 01:01:15 2020
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 22 Apr 2020 05:01:15 +0000
Subject: [issue40360] Deprecate lib2to3 (and 2to3) for future removal
In-Reply-To: <1587530454.25.0.44181585934.issue40360@roundup.psfhosted.org>
Message-ID: <1587531675.09.0.0750223909555.issue40360@roundup.psfhosted.org>


Change by Gregory P. Smith <greg at krypto.org>:


----------
keywords: +patch
pull_requests: +18969
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/19645

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40360>
_______________________________________

From report at bugs.python.org  Wed Apr 22 01:10:18 2020
From: report at bugs.python.org (Bowie Chen)
Date: Wed, 22 Apr 2020 05:10:18 +0000
Subject: [issue40358] pathlib's relative_to should behave like os.path.relpath
In-Reply-To: <1587513783.17.0.6950267733.issue40358@roundup.psfhosted.org>
Message-ID: <1587532218.05.0.335186324294.issue40358@roundup.psfhosted.org>


Change by Bowie Chen <bowiechen.github at gmail.com>:


----------
nosy: +bowiechen

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40358>
_______________________________________

From report at bugs.python.org  Wed Apr 22 01:38:29 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 22 Apr 2020 05:38:29 +0000
Subject: [issue40222] "Zero cost" exception handling
In-Reply-To: <1586338863.3.0.393749013734.issue40222@roundup.psfhosted.org>
Message-ID: <1587533909.25.0.477943859787.issue40222@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

This is an exciting prospect.  Am looking forward to it :-)

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40222>
_______________________________________

From report at bugs.python.org  Wed Apr 22 01:51:52 2020
From: report at bugs.python.org (Jacob Melendrez)
Date: Wed, 22 Apr 2020 05:51:52 +0000
Subject: [issue32966] Python 3.7.2 - 0x80070643 - Fatal Error during
 installation
In-Reply-To: <1519767226.7.0.467229070634.issue32966@psf.upfronthosting.co.za>
Message-ID: <1587534712.81.0.667262490382.issue32966@roundup.psfhosted.org>


Jacob Melendrez <jacob.n.melendrez at gmail.com> added the comment:

I am trying to uninstall python 3.7.2 because I think it is preventing me from correctly using python 3.8.2. When I go to my program list on windows 10 and try to uninstall it, it gets approximately 10% in and then gives me the message that No python 3.7 installation was detected. I hit Ok and then it continues loading for another 1% and then I receive the error message "0x80070643 Fatal Error during installation " How do I resolve this?

----------
nosy: +Cybernetic
title: Python 3.6.4 - 0x80070643 - Fatal Error during installation -> Python 3.7.2 - 0x80070643 - Fatal Error during installation
versions: +Python 3.7 -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32966>
_______________________________________

From report at bugs.python.org  Wed Apr 22 02:30:23 2020
From: report at bugs.python.org (AndrewGYork)
Date: Wed, 22 Apr 2020 06:30:23 +0000
Subject: [issue38946] IDLE on macOS 10.15 Catalina does not open
 double-clicked files if app already launched
In-Reply-To: <1575141041.2.0.751349559914.issue38946@roundup.psfhosted.org>
Message-ID: <1587537023.31.0.146989807513.issue38946@roundup.psfhosted.org>


AndrewGYork <andrew.g.york at gmail.com> added the comment:

We have a 10.15.3 Mac with python 3.8.2, IDLE version 3.8.2, and we see similar behavior.

Summary:
The *second* 'bad' .py file you double-click won't open in IDLE. This seems unrelated to permissions, but a 'bad' file (saved by IDLE) can be converted to a 'good' file by emailing the file to myself.

Details:
Open IDLE, save a 5-byte file 'fails.py' (contents: pass) to an empty folder. Permissions are rw-r--r--.

Close IDLE. Double-click 'fails.py', which opens in the IDLE editor; a shell also opens. Double-click 'fails.py' again, or drag it onto the IDLE icon in the Dock, and it does not open in a second instance of the IDLE editor. Typing `idle3 fails.py` in the terminal does open in a second instance of the IDLE editor (same version as first instance).

Email 'fails.py' to myself, via Gmail. Download 'fails.py' from Gmail, and rename it to 'works.py'. Permissions are still rw-r--r--.

Close IDLE. Double-click 'works.py', which opens in the IDLE editor; a shell also opens. Double-click 'works.py' again, or drag it onto the IDLE icon in the Dock, and it *does* open in a second instance of the IDLE editor. Any number of instances can be simultaneously opened this way.

Close IDLE. Double-click 'works.py' several times to open it in several different instances of the IDLE editor. Double-click 'fails.py' once, which successfully opens in one more instance of the IDLE editor. Finally, double-click 'fails.py' a second time; it does *not* open a second instance of 'fails.py' in the IDLE editor.

IDLE's File->Open menu option does not open two instances of `fails.py` OR `works.py`; attempts to open the second instance simply raise focus of the first instance. However, if you open 'fails.py' via the menu, you can then open a second instance of 'fails.py' via double-clicking, but not a third.

----------
nosy: +AndrewGYork

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38946>
_______________________________________

From report at bugs.python.org  Wed Apr 22 02:51:40 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 22 Apr 2020 06:51:40 +0000
Subject: [issue40342] Programming FAQ about "How do I apply a method to a
 sequence of objects?" should include the option of an explicit for-loop
In-Reply-To: <1587416798.17.0.310240358568.issue40342@roundup.psfhosted.org>
Message-ID: <1587538300.96.0.738794297099.issue40342@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

This is an antipattern I've seen on multiple occasions in real code. A common offender is:

    [worker.join() for worker in workers]

Similarly, things like:

    [plugin.start() for plugin in plugins]

I do think it would be worth updating the FAQ text.

----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40342>
_______________________________________

From report at bugs.python.org  Wed Apr 22 02:54:42 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 22 Apr 2020 06:54:42 +0000
Subject: [issue40342] Programming FAQ about "How do I apply a method to a
 sequence of objects?" should include the option of an explicit for-loop
In-Reply-To: <1587416798.17.0.310240358568.issue40342@roundup.psfhosted.org>
Message-ID: <1587538482.56.0.198446545812.issue40342@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

However, the list comprehension pattern is not as bad as lines like this one [#1]:

    map(lambda plugin: self.start_plugin(plugin), self._plugins)

... which of course stopped working as soon as we transitioned to Python 3. :-(


[#1] https://github.com/enthought/envisage/blob/b7adb8793336dd3859623cb89bcc7bdfefe91b29/enthought/envisage/plugin_manager.py#L105

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40342>
_______________________________________

From report at bugs.python.org  Wed Apr 22 02:58:50 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 22 Apr 2020 06:58:50 +0000
Subject: [issue33065] IDLE debugger: failure stepping through module loading
In-Reply-To: <1520917336.65.0.467229070634.issue33065@psf.upfronthosting.co.za>
Message-ID: <1587538730.47.0.489449540549.issue33065@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I believe I found the bug.  For IDLE's original single process mode, still available with the -n startup option, debugger.py contains the entire debugger.  The values displayed for global and local names are obtained with reprlib.Repr.repr.  That in turn calls .repr1, and that calls .repr_xxx, where xxx is one of the 'common' builtin classes or 'instance'.

The latter is used for all user classes.  It calls __builtins__.repr, but guarded by 'try...except Exception' since user classes may cause exceptions.  The except clause returns an alternative type and id string, like object.__repr__.  (That alternative could also raise, but much less often.  Any of the examples above should run if IDLE were started from a command line with 'python -m idlelib -n'.

When user code is run in a separate process, the code that interacts with user object must also run in the separate process.  debugger.Idb is moved and the code in debugger_r is added, some in each process.  Of concern here is that the GUI code that displays global or local values is passed a dict proxy instead of an actual namespace dict.  The proxy __getitem__ for d[key] makes an rpc call to through the socket connection to code in the user process.  That returns not the object itself but a string representation.  It does so with an unguarded repr call.

IDLE intentionally removes traceback lines added by IDLE (and pdb, if used), so that tracebacks look mostly the same as in standard CPython.  But that is a handicap when there is a bug in IDLE.  A traceback ending with 
  File .../idlelib/debugger_r, line 173, in dict_item
    value = repr(value)
AttributeError: ...

would have been a big help here.  I am thinking about how to selectively disable traceback cleanup.

In any case, I believe the solution is to import reprlib in debugger_r also and add 'reprlib.Repr' before 'repr' in the line above.

----------
versions: +Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33065>
_______________________________________

From report at bugs.python.org  Wed Apr 22 03:11:11 2020
From: report at bugs.python.org (=?utf-8?b?VmVkcmFuIMSMYcSNacSH?=)
Date: Wed, 22 Apr 2020 07:11:11 +0000
Subject: [issue40342] Programming FAQ about "How do I apply a method to a
 sequence of objects?" should include the option of an explicit for-loop
In-Reply-To: <1587416798.17.0.310240358568.issue40342@roundup.psfhosted.org>
Message-ID: <1587539471.12.0.764817427237.issue40342@roundup.psfhosted.org>


Vedran ?a?i? <vedgar at gmail.com> added the comment:

Mapping lambdas is always inferior to comprehensions, in fact the main reason comprehensions were introduced was that mapping lambdas was cumbersome. (It didn't work so well for filtering by lambdas, but that's another story.)

As I said, Py3K was beneficial since raw maps weren't eager anymore, but it also gave us a print_function, enabling the new antipattern

    [print(obj) for obj in mylist]

which wasn't possible before.

It's too late for Python, but a lesson for some future programming language: procedures and functions are not the same. Function call is an expression having a value, procedure call is a statement having an effect. Both are useful, but conflating them is not.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40342>
_______________________________________

From report at bugs.python.org  Wed Apr 22 03:13:55 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 22 Apr 2020 07:13:55 +0000
Subject: [issue38946] IDLE on macOS 10.15 Catalina does not open
 double-clicked files if app already launched
In-Reply-To: <1575141041.2.0.751349559914.issue38946@roundup.psfhosted.org>
Message-ID: <1587539635.93.0.366310200309.issue38946@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

By design, IDLE should only allow one editor instance per file for a given python-IDLE process.  "$ python3 fails.py" opens a new python-IDLE process, independent of existing processes. It is possible that double-clicking good.py multiple times opens a new IDLE process each time, without a new Shell.  You could check the process list in Terminal. (I have forgotten the unix command and barely know bash.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38946>
_______________________________________

From report at bugs.python.org  Wed Apr 22 03:21:46 2020
From: report at bugs.python.org (=?utf-8?q?Miro_Hron=C4=8Dok?=)
Date: Wed, 22 Apr 2020 07:21:46 +0000
Subject: [issue1490384] PC new-logo-based icon set
Message-ID: <1587540106.85.0.0727776040608.issue1490384@roundup.psfhosted.org>


Change by Miro Hron?ok <miro at hroncok.cz>:


----------
nosy: +hroncok
nosy_count: 2.0 -> 3.0
pull_requests: +18970
pull_request: https://github.com/python/cpython/pull/17473

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1490384>
_______________________________________

From report at bugs.python.org  Wed Apr 22 03:21:50 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 22 Apr 2020 07:21:50 +0000
Subject: [issue1490384] PC new-logo-based icon set
Message-ID: <1587540110.94.0.993815231733.issue1490384@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:


New changeset 3a69f3caeeaea57048ed3bc3051e16854b9a4cd6 by Miro Hron?ok in branch 'master':
bpo-38439: Add 256px IDLE icon (GH-17473)
https://github.com/python/cpython/commit/3a69f3caeeaea57048ed3bc3051e16854b9a4cd6


----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1490384>
_______________________________________

From report at bugs.python.org  Wed Apr 22 03:21:51 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 22 Apr 2020 07:21:51 +0000
Subject: [issue38439] Python needs higher resolution app/menu icons
In-Reply-To: <1570749295.67.0.980962290264.issue38439@roundup.psfhosted.org>
Message-ID: <1587540111.0.0.0263300736909.issue38439@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:


New changeset 3a69f3caeeaea57048ed3bc3051e16854b9a4cd6 by Miro Hron?ok in branch 'master':
bpo-38439: Add 256px IDLE icon (GH-17473)
https://github.com/python/cpython/commit/3a69f3caeeaea57048ed3bc3051e16854b9a4cd6


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38439>
_______________________________________

From report at bugs.python.org  Wed Apr 22 03:22:09 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 22 Apr 2020 07:22:09 +0000
Subject: [issue38439] Python needs higher resolution app/menu icons
In-Reply-To: <1570749295.67.0.980962290264.issue38439@roundup.psfhosted.org>
Message-ID: <1587540129.03.0.697364523728.issue38439@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +18973
pull_request: https://github.com/python/cpython/pull/19647

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38439>
_______________________________________

From report at bugs.python.org  Wed Apr 22 03:22:01 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 22 Apr 2020 07:22:01 +0000
Subject: [issue38439] Python needs higher resolution app/menu icons
In-Reply-To: <1570749295.67.0.980962290264.issue38439@roundup.psfhosted.org>
Message-ID: <1587540121.34.0.983989179574.issue38439@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
nosy: +miss-islington
nosy_count: 5.0 -> 6.0
pull_requests: +18971
pull_request: https://github.com/python/cpython/pull/19646

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38439>
_______________________________________

From report at bugs.python.org  Wed Apr 22 03:22:09 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 22 Apr 2020 07:22:09 +0000
Subject: [issue1490384] PC new-logo-based icon set
Message-ID: <1587540129.13.0.290615187886.issue1490384@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +18974
pull_request: https://github.com/python/cpython/pull/19647

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1490384>
_______________________________________

From report at bugs.python.org  Wed Apr 22 03:22:01 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 22 Apr 2020 07:22:01 +0000
Subject: [issue1490384] PC new-logo-based icon set
Message-ID: <1587540121.44.0.817006617691.issue1490384@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
nosy: +miss-islington
nosy_count: 4.0 -> 5.0
pull_requests: +18972
pull_request: https://github.com/python/cpython/pull/19646

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1490384>
_______________________________________

From report at bugs.python.org  Wed Apr 22 03:38:46 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 22 Apr 2020 07:38:46 +0000
Subject: [issue1490384] PC new-logo-based icon set
Message-ID: <1587541126.14.0.684217401367.issue1490384@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset abdfb3b47156a6ca5696b6f4380d412a460b718a by Miss Islington (bot) in branch '3.7':
bpo-38439: Add 256px IDLE icon (GH-17473)
https://github.com/python/cpython/commit/abdfb3b47156a6ca5696b6f4380d412a460b718a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1490384>
_______________________________________

From report at bugs.python.org  Wed Apr 22 03:38:46 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 22 Apr 2020 07:38:46 +0000
Subject: [issue38439] Python needs higher resolution app/menu icons
In-Reply-To: <1570749295.67.0.980962290264.issue38439@roundup.psfhosted.org>
Message-ID: <1587541126.22.0.23417709922.issue38439@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset abdfb3b47156a6ca5696b6f4380d412a460b718a by Miss Islington (bot) in branch '3.7':
bpo-38439: Add 256px IDLE icon (GH-17473)
https://github.com/python/cpython/commit/abdfb3b47156a6ca5696b6f4380d412a460b718a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38439>
_______________________________________

From report at bugs.python.org  Wed Apr 22 03:38:52 2020
From: report at bugs.python.org (=?utf-8?q?Miro_Hron=C4=8Dok?=)
Date: Wed, 22 Apr 2020 07:38:52 +0000
Subject: [issue38439] Python needs higher resolution app/menu icons
In-Reply-To: <1570749295.67.0.980962290264.issue38439@roundup.psfhosted.org>
Message-ID: <1587541132.22.0.667690629518.issue38439@roundup.psfhosted.org>


Change by Miro Hron?ok <miro at hroncok.cz>:


----------
pull_requests: +18975
pull_request: https://github.com/python/cpython/pull/19648

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38439>
_______________________________________

From report at bugs.python.org  Wed Apr 22 03:40:05 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 22 Apr 2020 07:40:05 +0000
Subject: [issue1490384] PC new-logo-based icon set
Message-ID: <1587541205.93.0.400376461839.issue1490384@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 3a5545025685040842420c85a4a9aab5f044aeb8 by Miss Islington (bot) in branch '3.8':
bpo-38439: Add 256px IDLE icon (GH-17473)
https://github.com/python/cpython/commit/3a5545025685040842420c85a4a9aab5f044aeb8


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1490384>
_______________________________________

From report at bugs.python.org  Wed Apr 22 03:40:06 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 22 Apr 2020 07:40:06 +0000
Subject: [issue38439] Python needs higher resolution app/menu icons
In-Reply-To: <1570749295.67.0.980962290264.issue38439@roundup.psfhosted.org>
Message-ID: <1587541206.02.0.123749212279.issue38439@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 3a5545025685040842420c85a4a9aab5f044aeb8 by Miss Islington (bot) in branch '3.8':
bpo-38439: Add 256px IDLE icon (GH-17473)
https://github.com/python/cpython/commit/3a5545025685040842420c85a4a9aab5f044aeb8


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38439>
_______________________________________

From report at bugs.python.org  Wed Apr 22 03:44:20 2020
From: report at bugs.python.org (Ned Deily)
Date: Wed, 22 Apr 2020 07:44:20 +0000
Subject: [issue38360] single-argument form of -isysroot should be supported
In-Reply-To: <1570101654.53.0.395218631906.issue38360@roundup.psfhosted.org>
Message-ID: <1587541459.99.0.180170114752.issue38360@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:


New changeset b310700976524b4b99ee319c947ca40468716fc9 by Joshua Root in branch 'master':
bpo-38360: macOS: support alternate form of -isysroot flag (GH-16480)
https://github.com/python/cpython/commit/b310700976524b4b99ee319c947ca40468716fc9


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38360>
_______________________________________

From report at bugs.python.org  Wed Apr 22 03:53:20 2020
From: report at bugs.python.org (Ned Deily)
Date: Wed, 22 Apr 2020 07:53:20 +0000
Subject: [issue38360] single-argument form of -isysroot should be supported
In-Reply-To: <1570101654.53.0.395218631906.issue38360@roundup.psfhosted.org>
Message-ID: <1587542000.47.0.757496779969.issue38360@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

Thanks for the PR! This seems like a borderline feature rather than a bug so, unless there is a compelling reason to backport it to 3.8.x, I'm just going to push it to master for release in 3.9.0 (as of alpha 6).

----------
assignee:  -> ned.deily
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
versions:  -Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38360>
_______________________________________

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: [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 04:04:03 2020
From: report at bugs.python.org (mapf)
Date: Wed, 22 Apr 2020 08:04:03 +0000
Subject: [issue39423] Process finished with exit code -1073741819 (0xC0000005)
 when trying to access data from a pickled file
In-Reply-To: <1579709155.26.0.28815846735.issue39423@roundup.psfhosted.org>
Message-ID: <1587542643.96.0.260233578663.issue39423@roundup.psfhosted.org>


mapf <mapfus at gmx.de> added the comment:

Hi, thanks for your interest! Since this was quite some time ago now, I eventually found a workaround (I think I made dicts out of the 1d slices and saved them instead) and the project moved on. I don't have the code from back then anymore, I'm sorry. But I can try to recreate it. I'm not sure if I will succeed though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39423>
_______________________________________

From report at bugs.python.org  Wed Apr 22 04:05:54 2020
From: report at bugs.python.org (Ned Deily)
Date: Wed, 22 Apr 2020 08:05:54 +0000
Subject: [issue38329] macOS python.org installers only add or modify framework
 Versions/Current symlink for Python 2.x installs, not Python 3.x
In-Reply-To: <1569872224.76.0.739484042885.issue38329@roundup.psfhosted.org>
Message-ID: <1587542754.49.0.774830905343.issue38329@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


----------
keywords: +patch
pull_requests: +18976
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19650

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38329>
_______________________________________

From report at bugs.python.org  Wed Apr 22 04:12:28 2020
From: report at bugs.python.org (Jakub Stasiak)
Date: Wed, 22 Apr 2020 08:12:28 +0000
Subject: [issue37339] os.path.ismount returns true on nested btrfs subvolumes
In-Reply-To: <1560939042.69.0.683071795623.issue37339@roundup.psfhosted.org>
Message-ID: <1587543148.63.0.802850145797.issue37339@roundup.psfhosted.org>


Change by Jakub Stasiak <jakub+python.org at stasiak.at>:


----------
nosy: +jstasiak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37339>
_______________________________________

From report at bugs.python.org  Wed Apr 22 04:27:29 2020
From: report at bugs.python.org (Ned Deily)
Date: Wed, 22 Apr 2020 08:27:29 +0000
Subject: [issue38329] macOS python.org installers only add or modify framework
 Versions/Current symlink for Python 2.x installs, not Python 3.x
In-Reply-To: <1569872224.76.0.739484042885.issue38329@roundup.psfhosted.org>
Message-ID: <1587544049.92.0.350340243054.issue38329@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:


New changeset bcc136ba892e62078a67ad0ca0b34072ec9c88aa by Ned Deily in branch 'master':
bpo-38329: python.org macOS installers now update Current symlink (GH-19650)
https://github.com/python/cpython/commit/bcc136ba892e62078a67ad0ca0b34072ec9c88aa


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38329>
_______________________________________

From report at bugs.python.org  Wed Apr 22 04:33:10 2020
From: report at bugs.python.org (Ned Deily)
Date: Wed, 22 Apr 2020 08:33:10 +0000
Subject: [issue38329] macOS python.org installers only add or modify framework
 Versions/Current symlink for Python 2.x installs, not Python 3.x
In-Reply-To: <1569872224.76.0.739484042885.issue38329@roundup.psfhosted.org>
Message-ID: <1587544390.59.0.00494074614851.issue38329@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

With Python 2 now officially retired, it's time to change the installer behavior.  With the merged change, as of Python 3.9.0 (alpha 6) the python.org macOS installers will now update the Current version symmlink in the /Library/Frameworks Python being installed.  Since this would be a change in behavior that could affect current users of Python 3.8.x or 3.7.x, I think we should not backport this to those versions.  Thanks again for the report!

----------
components: +Installation
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions:  -Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38329>
_______________________________________

From report at bugs.python.org  Wed Apr 22 06:07:55 2020
From: report at bugs.python.org (Ammar Askar)
Date: Wed, 22 Apr 2020 10:07:55 +0000
Subject: [issue34990] year 2038 problem in compileall.py
In-Reply-To: <1539602536.3.0.788709270274.issue34990@psf.upfronthosting.co.za>
Message-ID: <1587550075.18.0.761737703913.issue34990@roundup.psfhosted.org>


Change by Ammar Askar <ammar at ammaraskar.com>:


----------
nosy: +ammar2
nosy_count: 4.0 -> 5.0
pull_requests: +18977
pull_request: https://github.com/python/cpython/pull/19651

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34990>
_______________________________________

From report at bugs.python.org  Wed Apr 22 06:43:38 2020
From: report at bugs.python.org (Steve Dower)
Date: Wed, 22 Apr 2020 10:43:38 +0000
Subject: [issue40214] test_ctypes.test_load_dll_with_flags Windows failure
In-Reply-To: <1586230066.46.0.791582618244.issue40214@roundup.psfhosted.org>
Message-ID: <1587552218.51.0.472335500686.issue40214@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
pull_requests: +18978
pull_request: https://github.com/python/cpython/pull/19652

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40214>
_______________________________________

From report at bugs.python.org  Wed Apr 22 06:53:23 2020
From: report at bugs.python.org (mapf)
Date: Wed, 22 Apr 2020 10:53:23 +0000
Subject: [issue39423] Process finished with exit code -1073741819 (0xC0000005)
 when trying to access data from a pickled file
In-Reply-To: <1579709155.26.0.28815846735.issue39423@roundup.psfhosted.org>
Message-ID: <1587552803.07.0.761085326986.issue39423@roundup.psfhosted.org>


mapf <mapfus at gmx.de> added the comment:

Ok, I created a little something. It's not very pretty, but it works for me, meaning it causes the process to finish with exit code -1073741819 (0xC0000005).

----------
Added file: https://bugs.python.org/file49084/temp.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39423>
_______________________________________

From report at bugs.python.org  Wed Apr 22 07:27:00 2020
From: report at bugs.python.org (Oscar)
Date: Wed, 22 Apr 2020 11:27:00 +0000
Subject: [issue39817] CRITICAL: TypeError: cannot pickle 'generator'
In-Reply-To: <1583093867.42.0.0359831443421.issue39817@roundup.psfhosted.org>
Message-ID: <1587554820.01.0.70949237968.issue39817@roundup.psfhosted.org>


Oscar <dotoscat at gmail.com> added the comment:

Hello there. Im sorry very much by not replying to the answers. The source code is not mine, not written by me.

I can pass a link from the project issue tracker
https://github.com/getpelican/pelican/issues/2674#issuecomment-569431530
telling that the code works with Python 3.6.8 and 3.7.3, but not with Python 3.8.

Thank you for your time.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39817>
_______________________________________

From report at bugs.python.org  Wed Apr 22 07:34:30 2020
From: report at bugs.python.org (Joshua Root)
Date: Wed, 22 Apr 2020 11:34:30 +0000
Subject: [issue38360] single-argument form of -isysroot should be supported
In-Reply-To: <1570101654.53.0.395218631906.issue38360@roundup.psfhosted.org>
Message-ID: <1587555270.56.0.154059918004.issue38360@roundup.psfhosted.org>


Joshua Root <josh+python at root.id.au> added the comment:

That ValueError I mentioned causes build failures for extension modules whenever the CFLAGS in sysconfig contains an -isysroot flag in the single arg form. We ran into it a lot in MacPorts on Mojave and Catalina. So I would consider it a bug, and would prefer to backport to all branches that are open for bug fixes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38360>
_______________________________________

From report at bugs.python.org  Wed Apr 22 07:45:08 2020
From: report at bugs.python.org (Michael Felt)
Date: Wed, 22 Apr 2020 11:45:08 +0000
Subject: [issue40244] AIX: build: _PyObject_GC_TRACK Asstertion failure
In-Reply-To: <1587277253.97.0.170354741842.issue40244@roundup.psfhosted.org>
Message-ID: <a1d1d3b7-4c92-7b48-4d01-8967961d9229@felt.demon.nl>


Michael Felt <aixtools at felt.demon.nl> added the comment:

When I have more time I hope to investigate specifically what is
different in the assembly code - with/without the __noreturn__ change.

On 19/04/2020 08:20, Batuhan Taskaya wrote:
> Batuhan Taskaya <batuhanosmantaskaya at gmail.com> added the comment:
>
> Moving assertion from _PyObject_GC_TRACK to gen_dealloc (just before the _PyObject_GC_TRACK call) results with success (????)
>
>      if (gen->gi_weakreflist != NULL)
>          PyObject_ClearWeakRefs(self);
> -
> +    _PyObject_ASSERT_FROM(self, !_PyObject_GC_IS_TRACKED(self),
> +                          "object already tracked by they garbage collector",
> +                          __FILE__, __LINE__, "_PyObject_GC_TRACK");
>      _PyObject_GC_TRACK(self);
>  
>      if (PyObject_CallFinalizerFromDealloc(self))
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue40244>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40244>
_______________________________________

From report at bugs.python.org  Wed Apr 22 08:54:30 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 22 Apr 2020 12:54:30 +0000
Subject: [issue39966] mock 3.9 bug: Wrapped objects without __bool__ raise
 exception
In-Reply-To: <1584254384.28.0.0187140133308.issue39966@roundup.psfhosted.org>
Message-ID: <1587560070.52.0.353841996171.issue39966@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

The patch assumed using the magic method attribute as the way to evaluate an object in a context which I got to know is wrong since evaluations in context like boolean are not only dependent on one magic method but has a precedence over several others. In the event of 3.9 alpha 6 being the next candidate I guess the change can be reverted to be revisited later about the desired behaviour with backwards compatibility. The docs could perhaps be clarified that calling magic method on a wrap gives default set of values. 

Thoughts on reversion or other possible approaches?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39966>
_______________________________________

From report at bugs.python.org  Wed Apr 22 08:56:42 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 22 Apr 2020 12:56:42 +0000
Subject: [issue40356] OverflowError: mktime argument out of range
In-Reply-To: <1587505343.63.0.318003481208.issue40356@roundup.psfhosted.org>
Message-ID: <1587560202.03.0.85331066738.issue40356@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +belopolsky, p-ganssle

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40356>
_______________________________________

From report at bugs.python.org  Wed Apr 22 09:14:06 2020
From: report at bugs.python.org (Inada Naoki)
Date: Wed, 22 Apr 2020 13:14:06 +0000
Subject: [issue36346] Prepare for removing the legacy Unicode C API
In-Reply-To: <1552918981.83.0.901300276481.issue36346@roundup.psfhosted.org>
Message-ID: <1587561246.51.0.705440760185.issue36346@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
pull_requests: +18979
pull_request: https://github.com/python/cpython/pull/19653

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36346>
_______________________________________

From report at bugs.python.org  Wed Apr 22 09:16:26 2020
From: report at bugs.python.org (Inada Naoki)
Date: Wed, 22 Apr 2020 13:16:26 +0000
Subject: [issue36299] array: Deprecate 'u' type in array module
In-Reply-To: <1552629002.67.0.658973531537.issue36299@roundup.psfhosted.org>
Message-ID: <1587561386.7.0.114631022747.issue36299@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

I closed GH-12497 (Py_UNICODE -> Py_UCS4).
I created GH-19653 (Py_UNICODE -> wchar_t) instead.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36299>
_______________________________________

From report at bugs.python.org  Wed Apr 22 09:18:25 2020
From: report at bugs.python.org (Barry Alan Scott)
Date: Wed, 22 Apr 2020 13:18:25 +0000
Subject: [issue40260] modulefinder traceback regression starting on Windows
In-Reply-To: <1586680620.99.0.514402715757.issue40260@roundup.psfhosted.org>
Message-ID: <1587561505.07.0.969422468217.issue40260@roundup.psfhosted.org>


Barry Alan Scott <barry-scott at users.sourceforge.net> added the comment:

Anthony,

Now that everything is opened using open_code that returns bytes its
not clear to me why this breaks for you.

Further the data must be bytes for the codings to be figured out.

Removing the b'\n' may be reasonable, but not for the reason given.
I kept it as the original code did this and assumed it was needed.
Maybe for Windows users that forget to put a trailing NL?

How can I reproduce your user case?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40260>
_______________________________________

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: [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 09:37:19 2020
From: report at bugs.python.org (Paul Stoner)
Date: Wed, 22 Apr 2020 13:37:19 +0000
Subject: [issue40362] AbstractBasicAuthHandler does not support the following
 scheme: 'Bearer'
In-Reply-To: <1587562144.16.0.694381500951.issue40362@roundup.psfhosted.org>
Message-ID: <1587562639.28.0.566962114248.issue40362@roundup.psfhosted.org>


Paul Stoner <pstoner6765 at gmail.com> added the comment:

--4/22/2020 09:36
I disconnected from my corporate vpn and ran the script over my private network with the same result

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40362>
_______________________________________

From report at bugs.python.org  Wed Apr 22 10:13:52 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 22 Apr 2020 14:13:52 +0000
Subject: [issue40346] Add random.BaseRandom to ease implementation of
 subclasses
In-Reply-To: <1587419589.68.0.186666450831.issue40346@roundup.psfhosted.org>
Message-ID: <1587564832.77.0.440444406297.issue40346@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> Making it easy to create subclasses was never a goal regardless.

It's clearly advertised at the beginning of the documentation:

"Class Random can also be subclassed if you want to use a different basic generator of your own devising: (...)"

Do you mean that the documentation is wrong and users must not subclass random.Random?


> If that makes any method currently in use slower, it's not worth it.

I don't think that my PR 19631 has any impact on random.Random and random.SystemRandom performances. Only new 3rd party classes which will be written to inherit from the *new* random.BaseRandom loose the gauss() optimization.

It would be possible to keep the optimization, but it would make class inheritance more complex: subclasses would have to call seed(), getstate() and setstate() methods of BaseRandom. Moreover, I dislike that the base class is not thread state. I prefer to keep it simple and correct.


> that reworking this doesn't solve any actual problem.

I changed the issue title to clarify my intent.

My intent is to ease the creation of subclasses. In Python 3.8, a subclass has to *override* 5 methods: getrandbits(), random(), seed(), getstate() and setstate().

With the proposed BaseRandom, a sublcass only has to *implement* *1* single method, getrandbits():

* random() and randbytes() are implemented with getrandbits() automatically
* seed(), getstate() and setstate() raise NotImplementedError, as done by SystemRandom currently. Obviously, you can override them if you want. But at least, you don't inherit the whole Mersenne Twister state by default.

The current problem is that Python 3.9 adds randbytes() which means that a class which inherit from random.Random now has to override not 5 but 6 methods: it now also has to override randbytes().

Raymond proposes to remove _random.Random.randbytes() C implementation and use instead a Python implementation which is 5x slower.

For me, it's surprising that if a subclass doesn't override all methods, it gets a Mersenne Twister implementation. See my msg366918 example. I would prefer a real base class with has no default implementation.

It doesn't prevent people to continue to inherit from random.Random: classes which inherit from random.Random continue to work.

Note: currently in my PR 19631, seed() has to be implemented since it's called by the constructor. I'm not sure if it's a good design or not.

----------
title: Redesign random.Random class inheritance -> Add random.BaseRandom to ease implementation of subclasses

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40346>
_______________________________________

From report at bugs.python.org  Wed Apr 22 10:26:04 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 22 Apr 2020 14:26:04 +0000
Subject: [issue40360] Deprecate lib2to3 (and 2to3) for future removal
In-Reply-To: <1587530454.25.0.44181585934.issue40360@roundup.psfhosted.org>
Message-ID: <1587565564.25.0.573668687161.issue40360@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

I am in favor of this. We could promote LibCST, which is based on Parso, which uses a forked version of pgen2 (the parser in lib2to3). I believe one of these could switch to a fork of pegen as its parser, so it will be able to handle new PEG based syntax in 3.10+.

Removal by 3.12 might be feasible.

----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40360>
_______________________________________

From report at bugs.python.org  Wed Apr 22 10:26:16 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 22 Apr 2020 14:26:16 +0000
Subject: [issue40346] Add random.BaseRandom to ease implementation of
 subclasses
In-Reply-To: <1587419589.68.0.186666450831.issue40346@roundup.psfhosted.org>
Message-ID: <1587565576.53.0.0654157072071.issue40346@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

In Python 3.8, random.Random docstring starts with "Random number generator base class".

I do understand that the random module design predates the abc module (added to Python 2.7). I'm now proposing to add a real base class to move it towards modern Python stdlib coding style.


That's the behavior that I would expect from a "base class":

>>> class MySequence(collections.abc.Sequence): pass
... 
>>> seq=MySequence()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: Can't instantiate abstract class MySequence with abstract methods __getitem__, __len__

Some examples of stdlib modules which implement base classes like this:

* collections.abc.Sequence
* numbers.Complex
* selectors.BaseSelector
* typing.SupportsInt

asyncio.AbstractEventLoop doesn't fail when an instance is created, but when an abstract method is created. Users can choose to inherit from asyncio.BaseEventLoop or asyncio.AbstractEventLoop depending if they wany to inherit partially of BaseEventLoop features, or really create an event loop from scratch (AbstractEventLoop). Other classes which are designed like that:

* email._policybase.Policy
* http.cookiejar.CookiePolicy
* importlib.abc.Loader
* wsgiref.handlers.BaseHandler

I don't think that it's worth it to bother with abc.ABC abstraction here, and so I only propose to provide methods which are implemented as "raise NotImplementedError".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40346>
_______________________________________

From report at bugs.python.org  Wed Apr 22 10:30:42 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 22 Apr 2020 14:30:42 +0000
Subject: [issue40138] Windows implementation of os.waitpid() truncates the
 exit status (status << 8)
In-Reply-To: <1585760727.67.0.797995887325.issue40138@roundup.psfhosted.org>
Message-ID: <1587565842.13.0.767828857623.issue40138@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 9bee32b34e4fb3e67a88bf14d38153851d4c4598 by Victor Stinner in branch 'master':
bpo-40138: Fix Windows os.waitpid() for large exit code (GH-19637)
https://github.com/python/cpython/commit/9bee32b34e4fb3e67a88bf14d38153851d4c4598


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40138>
_______________________________________

From report at bugs.python.org  Wed Apr 22 10:46:27 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 22 Apr 2020 14:46:27 +0000
Subject: [issue40138] Windows implementation of os.waitpid() truncates the
 exit status (status << 8)
In-Reply-To: <1585760727.67.0.797995887325.issue40138@roundup.psfhosted.org>
Message-ID: <1587566787.45.0.401745278598.issue40138@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +18980
pull_request: https://github.com/python/cpython/pull/19654

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40138>
_______________________________________

From report at bugs.python.org  Wed Apr 22 11:06:12 2020
From: report at bugs.python.org (hai shi)
Date: Wed, 22 Apr 2020 15:06:12 +0000
Subject: [issue40338] [Security] urllib and anti-slash (\) in the hostname
In-Reply-To: <1587393818.69.0.0669874545699.issue40338@roundup.psfhosted.org>
Message-ID: <1587567972.77.0.943664204547.issue40338@roundup.psfhosted.org>


hai shi <shihai1991 at 126.com> added the comment:

>It seems to behave as expected
+1. This is an interesting test;)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40338>
_______________________________________

From report at bugs.python.org  Wed Apr 22 11:16:53 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 22 Apr 2020 15:16:53 +0000
Subject: [issue40334] PEP 617: new PEG-based parser
In-Reply-To: <1587327377.33.0.614039250584.issue40334@roundup.psfhosted.org>
Message-ID: <1587568613.86.0.974744348815.issue40334@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Once PR 19503 will be merged, I would be interested to see if setjmp()/longjmp() can be avoided. I'm scared by these functions: they require that all functions in between setjmp() and longjmp() call stack have no state and don't need any cleanup at exit.

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40334>
_______________________________________

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: [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 11:39:56 2020
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Wed, 22 Apr 2020 15:39:56 +0000
Subject: [issue40363] shlex.quote applied to a glob pattern disables glob
 matching
In-Reply-To: <1587568891.1.0.0837751696044.issue40363@roundup.psfhosted.org>
Message-ID: <1587569996.3.0.321269498144.issue40363@roundup.psfhosted.org>


R?mi Lapeyre <remi.lapeyre at henki.fr> added the comment:

shlex.quote makes the string safe to pass a command, what if it's 

   rm 'var/log/syslog*'

instead?

You make sure that only the file given would be removed but then shlex.quote() shoot you in the foot.

This would also cause issues for files with '*' or another special characters in the name, you would not be able to pass their name anymore.

Also, not all shells have the same glob patterns and some of them are actually configurable to enable more patterns, so it would be impossible to know what to escape or not, shlex.quote() just quote everything unconditionnaly

If you want to allow '*' at the end or inside the pattern I think the best way is to look for it in your application, split (or take the prefix if you only want to allow it in the end), use shlex.quote() on the parts and concatenate with '*'.

----------
nosy: +remi.lapeyre

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40363>
_______________________________________

From report at bugs.python.org  Wed Apr 22 11:40:21 2020
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Wed, 22 Apr 2020 15:40:21 +0000
Subject: [issue40363] shlex.quote applied to a glob pattern disables glob
 matching
In-Reply-To: <1587568891.1.0.0837751696044.issue40363@roundup.psfhosted.org>
Message-ID: <1587570021.27.0.870101428955.issue40363@roundup.psfhosted.org>


Change by R?mi Lapeyre <remi.lapeyre at henki.fr>:


----------
type:  -> behavior
versions: +Python 3.9 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40363>
_______________________________________

From report at bugs.python.org  Wed Apr 22 11:58:07 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 22 Apr 2020 15:58:07 +0000
Subject: [issue40138] Windows implementation of os.waitpid() truncates the
 exit status (status << 8)
In-Reply-To: <1585760727.67.0.797995887325.issue40138@roundup.psfhosted.org>
Message-ID: <1587571087.63.0.348636177197.issue40138@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset b07350901cac9197aef41855d8a4d56533636b91 by Victor Stinner in branch '3.8':
bpo-40138: Fix Windows os.waitpid() for large exit code (GH-19654)
https://github.com/python/cpython/commit/b07350901cac9197aef41855d8a4d56533636b91


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40138>
_______________________________________

From report at bugs.python.org  Wed Apr 22 11:58:32 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 22 Apr 2020 15:58:32 +0000
Subject: [issue40138] Windows implementation of os.waitpid() truncates the
 exit status (status << 8)
In-Reply-To: <1585760727.67.0.797995887325.issue40138@roundup.psfhosted.org>
Message-ID: <1587571112.74.0.759744517942.issue40138@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
nosy: +miss-islington
nosy_count: 2.0 -> 3.0
pull_requests: +18981
pull_request: https://github.com/python/cpython/pull/19655

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40138>
_______________________________________

From report at bugs.python.org  Wed Apr 22 12:05:00 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 22 Apr 2020 16:05:00 +0000
Subject: [issue40214] test_ctypes.test_load_dll_with_flags Windows failure
In-Reply-To: <1586230066.46.0.791582618244.issue40214@roundup.psfhosted.org>
Message-ID: <1587571500.52.0.909049217164.issue40214@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +18982
pull_request: https://github.com/python/cpython/pull/19656

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40214>
_______________________________________

From report at bugs.python.org  Wed Apr 22 12:04:53 2020
From: report at bugs.python.org (Steve Dower)
Date: Wed, 22 Apr 2020 16:04:53 +0000
Subject: [issue40214] test_ctypes.test_load_dll_with_flags Windows failure
In-Reply-To: <1586230066.46.0.791582618244.issue40214@roundup.psfhosted.org>
Message-ID: <1587571493.71.0.432725557163.issue40214@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:


New changeset 9b498939009f49b8c772c89e8fc80efbfd8afcb5 by Steve Dower in branch 'master':
bpo-40214: Fix ctypes WinDLL test with insecure flags (GH-19652)
https://github.com/python/cpython/commit/9b498939009f49b8c772c89e8fc80efbfd8afcb5


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40214>
_______________________________________

From report at bugs.python.org  Wed Apr 22 12:05:54 2020
From: report at bugs.python.org (Steve Dower)
Date: Wed, 22 Apr 2020 16:05:54 +0000
Subject: [issue40214] test_ctypes.test_load_dll_with_flags Windows failure
In-Reply-To: <1586230066.46.0.791582618244.issue40214@roundup.psfhosted.org>
Message-ID: <1587571554.62.0.156391311638.issue40214@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Looks like that fix has done it. Thanks, Eryk!

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40214>
_______________________________________

From report at bugs.python.org  Wed Apr 22 12:08:32 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Wed, 22 Apr 2020 16:08:32 +0000
Subject: [issue36346] Prepare for removing the legacy Unicode C API
In-Reply-To: <1552918981.83.0.901300276481.issue36346@roundup.psfhosted.org>
Message-ID: <1587571712.03.0.0337256333674.issue36346@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
nosy: +corona10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36346>
_______________________________________

From report at bugs.python.org  Wed Apr 22 12:09:06 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 22 Apr 2020 16:09:06 +0000
Subject: [issue39562] Asynchronous comprehensions don't work in asyncio REPL
In-Reply-To: <1580923705.71.0.29233909242.issue39562@roundup.psfhosted.org>
Message-ID: <1587571746.92.0.105799585477.issue39562@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 4454057269b995341b04d13f0bf97f96080f27d0 by Batuhan Ta?kaya in branch 'master':
bpo-39562: Prevent collision of future and compiler flags (GH-19230)
https://github.com/python/cpython/commit/4454057269b995341b04d13f0bf97f96080f27d0


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39562>
_______________________________________

From report at bugs.python.org  Wed Apr 22 12:10:16 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 22 Apr 2020 16:10:16 +0000
Subject: [issue38360] single-argument form of -isysroot should be supported
In-Reply-To: <1570101654.53.0.395218631906.issue38360@roundup.psfhosted.org>
Message-ID: <1587571816.65.0.0470508046043.issue38360@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +18984
pull_request: https://github.com/python/cpython/pull/19658

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38360>
_______________________________________

From report at bugs.python.org  Wed Apr 22 12:10:08 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 22 Apr 2020 16:10:08 +0000
Subject: [issue38360] single-argument form of -isysroot should be supported
In-Reply-To: <1570101654.53.0.395218631906.issue38360@roundup.psfhosted.org>
Message-ID: <1587571808.69.0.577886315859.issue38360@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
nosy: +miss-islington
nosy_count: 5.0 -> 6.0
pull_requests: +18983
pull_request: https://github.com/python/cpython/pull/19657

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38360>
_______________________________________

From report at bugs.python.org  Wed Apr 22 12:15:30 2020
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 22 Apr 2020 16:15:30 +0000
Subject: [issue26826] Expose new copy_file_range() syscall in os module.
In-Reply-To: <1461325239.41.0.30054024313.issue26826@psf.upfronthosting.co.za>
Message-ID: <1587572130.9.0.970555124891.issue26826@roundup.psfhosted.org>


Change by Benjamin Peterson <benjamin at python.org>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26826>
_______________________________________

From report at bugs.python.org  Wed Apr 22 12:16:50 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 22 Apr 2020 16:16:50 +0000
Subject: [issue40138] Windows implementation of os.waitpid() truncates the
 exit status (status << 8)
In-Reply-To: <1585760727.67.0.797995887325.issue40138@roundup.psfhosted.org>
Message-ID: <1587572210.26.0.066646591908.issue40138@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset de5dcfa3bcabf52e43468a2b088ed71b5e5c4503 by Miss Islington (bot) in branch '3.7':
bpo-40138: Fix Windows os.waitpid() for large exit code (GH-19654)
https://github.com/python/cpython/commit/de5dcfa3bcabf52e43468a2b088ed71b5e5c4503


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40138>
_______________________________________

From report at bugs.python.org  Wed Apr 22 12:27:31 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 22 Apr 2020 16:27:31 +0000
Subject: [issue38360] single-argument form of -isysroot should be supported
In-Reply-To: <1570101654.53.0.395218631906.issue38360@roundup.psfhosted.org>
Message-ID: <1587572851.64.0.972934199827.issue38360@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset e7f8684ef77d280eb99b8533fd18455caa0fe194 by Miss Islington (bot) in branch '3.7':
bpo-38360: macOS: support alternate form of -isysroot flag (GH-16480)
https://github.com/python/cpython/commit/e7f8684ef77d280eb99b8533fd18455caa0fe194


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38360>
_______________________________________

From report at bugs.python.org  Wed Apr 22 12:34:52 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 22 Apr 2020 16:34:52 +0000
Subject: [issue39562] Asynchronous comprehensions don't work in asyncio REPL
In-Reply-To: <1580923705.71.0.29233909242.issue39562@roundup.psfhosted.org>
Message-ID: <1587573292.52.0.27054247231.issue39562@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> bpo-39562: Prevent collision of future and compiler flags (GH-19230)
> https://github.com/python/cpython/commit/4454057269b995341b04d13f0bf97f96080f27d0

I tested manually: this change fix my msg365311 reproducer. Thanks!

In Python 3.8, PyCF_ALLOW_TOP_LEVEL_AWAIT = CO_FUTURE_DIVISION = 0x2000. The commit 9052f7a41b90f2d34011c8da68f9a4facebc8a97 was backported to 3.8:

New changeset ec8a973f7cf080d9c0679f058b2371f0b7c7862c by Miss Islington (bot) in branch '3.8':
bpo-39562: Allow executing asynchronous comprehensions in the asyncio REPL (GH-18968)
https://github.com/python/cpython/commit/ec8a973f7cf080d9c0679f058b2371f0b7c7862c

And now 3.8 branch also has the bug: msg365311 reproducer fails as well in 3.8.

What should be done? Revert ec8a973f7cf080d9c0679f058b2371f0b7c7862c? Change constants value in Python 3.8.3? (backport 4454057269b995341b04d13f0bf97f96080f27d0 to 3.8)

IMHO reverting the commit ec8a973f7cf080d9c0679f058b2371f0b7c7862c (fix async comprehension in asyncio REPL) is the safest option.

First, I understood that the asyncio REPL was experimental in Python 3.8: https://bugs.python.org/issue37028

But it's not documented as provisional or experimental in What's New in Python 3.8:
https://docs.python.org/dev/whatsnew/3.8.html#asyncio

But I'm also fine with backporting the fix 4454057269b995341b04d13f0bf97f96080f27d0 (change constants) to 3.8.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39562>
_______________________________________

From report at bugs.python.org  Wed Apr 22 12:35:49 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 22 Apr 2020 16:35:49 +0000
Subject: [issue40138] Windows implementation of os.waitpid() truncates the
 exit status (status << 8)
In-Reply-To: <1585760727.67.0.797995887325.issue40138@roundup.psfhosted.org>
Message-ID: <1587573349.07.0.666867026654.issue40138@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Ok, os.waitpid() is now fixed in 3.7, 3.8 and master branches, and os.waitstatus_to_exitcode() is fixed in master.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40138>
_______________________________________

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: [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 12:51:03 2020
From: report at bugs.python.org (Anthony Sottile)
Date: Wed, 22 Apr 2020 16:51:03 +0000
Subject: [issue40260] modulefinder traceback regression starting on Windows
In-Reply-To: <1586680620.99.0.514402715757.issue40260@roundup.psfhosted.org>
Message-ID: <1587574263.68.0.0793552611072.issue40260@roundup.psfhosted.org>


Anthony Sottile <asottile at umich.edu> added the comment:

debian has its own implementation of find_modules which still returns a text file for PY_SOURCE

changing the type of that io object is the "breaking change" and maybe shouldn't be backported to python3.8 in a patch release

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40260>
_______________________________________

From report at bugs.python.org  Wed Apr 22 12:52:02 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 22 Apr 2020 16:52:02 +0000
Subject: [issue40094] Add os.waitstatus_to_exitcode() function
In-Reply-To: <1585351787.12.0.917977186474.issue40094@roundup.psfhosted.org>
Message-ID: <1587574322.4.0.275108952138.issue40094@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> TODO: Modify asyncio.unix_events._compute_returncode() to use waitstatus_to_exitcode(): need to update tests.

I created bpo-40364 for that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40094>
_______________________________________

From report at bugs.python.org  Wed Apr 22 12:54:03 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 22 Apr 2020 16:54:03 +0000
Subject: [issue40094] Add os.waitstatus_to_exitcode() function
In-Reply-To: <1585351787.12.0.917977186474.issue40094@roundup.psfhosted.org>
Message-ID: <1587574443.81.0.858515588592.issue40094@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

"""
TODO:
* Decide if subprocess should reject WIFSTOPPED() or not.
* Check if the pure Python implementation of os._spawnvef() handles WIFSTOPPED() properly.
"""

Well, let's keep the status quo: leave os and subprocess modules unchanged. It can be revisited later if needed. My intent when I created this issue wasn't to change the behavior of other modules, just to add a new function to remove duplicated code ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40094>
_______________________________________

From report at bugs.python.org  Wed Apr 22 12:55:12 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 22 Apr 2020 16:55:12 +0000
Subject: [issue40094] Add os.waitstatus_to_exitcode() function
In-Reply-To: <1585351787.12.0.917977186474.issue40094@roundup.psfhosted.org>
Message-ID: <1587574512.18.0.285680744338.issue40094@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

The initial issue has been implemented: I added os.waitstatus_to_exitcode() function to Python 3.9. It's now well documented, I close the issue.

See sub-issues like bpo-40364 (asyncio) for further cleanups.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40094>
_______________________________________

From report at bugs.python.org  Wed Apr 22 13:04:09 2020
From: report at bugs.python.org (Steve Dower)
Date: Wed, 22 Apr 2020 17:04:09 +0000
Subject: [issue32966] Python 3.7.2 - 0x80070643 - Fatal Error during
 installation
In-Reply-To: <1519767226.7.0.467229070634.issue32966@psf.upfronthosting.co.za>
Message-ID: <1587575049.25.0.236223368632.issue32966@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Your best bet is to repair the Python 3.7.2 install first (through Programs and Features, if possible), and then uninstall it.

Any idea why it's interfering with Python 3.8? That shouldn't be the case (unless it's PATH related, in which case yeah, that's more or less expected).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32966>
_______________________________________

From report at bugs.python.org  Wed Apr 22 13:12:15 2020
From: report at bugs.python.org (Steve Dower)
Date: Wed, 22 Apr 2020 17:12:15 +0000
Subject: [issue40260] modulefinder traceback regression starting on Windows
In-Reply-To: <1586680620.99.0.514402715757.issue40260@roundup.psfhosted.org>
Message-ID: <1587575535.26.0.756674646765.issue40260@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

If we want to be strictly correct here, the fix should check the "mode" variable to determine the type. And given the fragility of the code being used here, there's no doubt some reliance on a trailing newline somewhere too.

I haven't bumped the categorisation, but at some level this is a security fix. All executable code is expected to be loaded through io.open_code(), and the fact that this didn't was a breach of that guarantee. There's a limit to how much we will accommodate people using it outside of what's documented.

Anthony, since you can apparently validate this, could you run through all the fixes necessary to keep that working? I want to stop this game of chasing, either by fixing everything in one go or by apologising for the breakage (the io.open_code() fix is staying).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40260>
_______________________________________

From report at bugs.python.org  Wed Apr 22 13:13:53 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 22 Apr 2020 17:13:53 +0000
Subject: [issue38360] single-argument form of -isysroot should be supported
In-Reply-To: <1570101654.53.0.395218631906.issue38360@roundup.psfhosted.org>
Message-ID: <1587575633.96.0.730324248956.issue38360@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 4a6da0b63ba0fb811bfa3cacd69d22a9c0b24a4d by Miss Islington (bot) in branch '3.8':
bpo-38360: macOS: support alternate form of -isysroot flag (GH-16480)
https://github.com/python/cpython/commit/4a6da0b63ba0fb811bfa3cacd69d22a9c0b24a4d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38360>
_______________________________________

From report at bugs.python.org  Wed Apr 22 13:15:33 2020
From: report at bugs.python.org (Eryk Sun)
Date: Wed, 22 Apr 2020 17:15:33 +0000
Subject: [issue37339] os.path.ismount returns true on nested btrfs subvolumes
In-Reply-To: <1560939042.69.0.683071795623.issue37339@roundup.psfhosted.org>
Message-ID: <1587575733.66.0.800760446296.issue37339@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> What do you mean by "portable version of mountpoint"?

posixpath.ismount is based on a portable method to detect a mountpoint in Unix systems, since POSIX lacks a portable function for this. The implementation is simple. A symlink is never a mountpoint. Otherwise compare the lstat of the path and its parent directory. It's a mountpoint if the st_dev fields are different. If not, it's a mountpoint if the st_ino fields are the same (e.g. "/").

The portable method may fail in particular cases. For instance, a bind mount in the Linux kernel (not bindfs) doesn't create a new device. For example, given "/opt" is bound to "opt" in the current directory on the same filesystem, ismount returns a false negative:


    >>> posixpath.ismount('opt')
    False

But it's a mountpoint according to the "/proc/self/mountinfo" table:

    >>> os.system('mountpoint opt')
    opt is a mountpoint
    0

The above false negative is documented, so a precedent exists to simply document the false positive with a btrfs subvolume. Developers can make of it what they will. If it matters to not count this case as a mountpoint, a script will have to implement its own platform-specific solution (e.g. use subprocess to call `mountpoint`).

----------
nosy: +eryksun
versions: +Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37339>
_______________________________________

From report at bugs.python.org  Wed Apr 22 13:21:50 2020
From: report at bugs.python.org (Ned Deily)
Date: Wed, 22 Apr 2020 17:21:50 +0000
Subject: [issue38360] single-argument form of -isysroot should be supported
In-Reply-To: <1570101654.53.0.395218631906.issue38360@roundup.psfhosted.org>
Message-ID: <1587576110.18.0.745786291606.issue38360@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


----------
versions: +Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38360>
_______________________________________

From report at bugs.python.org  Wed Apr 22 13:23:36 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 22 Apr 2020 17:23:36 +0000
Subject: [issue35886] Move PyInterpreterState into
 Include/internal/pycore_pystate.h
In-Reply-To: <1549069628.87.0.454232469964.issue35886@roundup.psfhosted.org>
Message-ID: <1587576216.16.0.783295366106.issue35886@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> FWIW, I was hoping to the same for PyThreadState but it looks like 6 of its fields are exposed in "stable" header files via the following macros: (...)

I created bpo-39947: "[C API] Make the PyThreadState structure opaque (move it to the internal C API)".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35886>
_______________________________________

From report at bugs.python.org  Wed Apr 22 13:28:46 2020
From: report at bugs.python.org (Anthony Sottile)
Date: Wed, 22 Apr 2020 17:28:46 +0000
Subject: [issue40260] modulefinder traceback regression starting on Windows
In-Reply-To: <1586680620.99.0.514402715757.issue40260@roundup.psfhosted.org>
Message-ID: <1587576526.82.0.952397187209.issue40260@roundup.psfhosted.org>


Anthony Sottile <asottile at umich.edu> added the comment:

The trailing newline was added in 1.5.1 78fc3634cbfd65a6be8abfd1b7fc7cbd0ccbfb39 -- back then `compile(...)` could not take strings which did not end in newlines

now it can, so it is safe to remove -- I did the same triage on another PR here: https://github.com/python/cpython/pull/17817

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40260>
_______________________________________

From report at bugs.python.org  Wed Apr 22 13:31:39 2020
From: report at bugs.python.org (Carl Meyer)
Date: Wed, 22 Apr 2020 17:31:39 +0000
Subject: [issue40360] Deprecate lib2to3 (and 2to3) for future removal
In-Reply-To: <1587530454.25.0.44181585934.issue40360@roundup.psfhosted.org>
Message-ID: <1587576699.1.0.112344293173.issue40360@roundup.psfhosted.org>


Carl Meyer <carl at oddbird.net> added the comment:

I volunteered in the python-dev thread to write a patch to the docs clarifying future status of lib2to3; happy to include the PendingDeprecationWarning as well.

Re linking to alternatives, we want to make sure we link to alternatives that are committed to updating to support newer Python versions' syntax. This definitely includes LibCST; I can inquire with the parso maintainer about whether it also includes parso. In future it could also include a third-party-maintained copy of lib2to3, if someone picks that up.

----------
nosy: +carljm

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40360>
_______________________________________

From report at bugs.python.org  Wed Apr 22 13:40:06 2020
From: report at bugs.python.org (Sebastian Berg)
Date: Wed, 22 Apr 2020 17:40:06 +0000
Subject: [issue39471] Meaning and clarification of PyBuffer_Release()
In-Reply-To: <1580163259.11.0.807397733698.issue39471@roundup.psfhosted.org>
Message-ID: <1587577206.57.0.0358948561066.issue39471@roundup.psfhosted.org>


Sebastian Berg <sebastian at sipsolutions.net> added the comment:

Ok, I will just close it. It is painfully clear that e.g. `mmap` uses it this way to prohibit closing, and also `memoryview` has all the machinery necessary to do counting of how many exports, etc. exists.

I admit, this still rubs me the wrong way, and I think it means that we may need to check `bf_releasebuffer != NULL` also in NumPy.

We still have the issue of not being able to use `releasebuffer` easily in NumPy. But there is nothing to be done, unless we can consider limiting the `"#s"`, etc. type argparsing, which is likely not an option.

----------
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39471>
_______________________________________

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: [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 13:44:38 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 22 Apr 2020 17:44:38 +0000
Subject: [issue35886] [C API] Make PyInterpreterState opaque: move it into the
 internal C API (internal/pycore_pystate.h)
In-Reply-To: <1549069628.87.0.454232469964.issue35886@roundup.psfhosted.org>
Message-ID: <1587577478.45.0.274465451716.issue35886@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Python 3.8 was released in October 2019 with this change (PyInterpreterState structure is now opaque). Fedora 32 is going to be released soon with Python 3.8 as /usr/bin/python. The change only broke very few projets: cffi (which indirectly broke brotlipy and httpbin), Blender, FreeBSD. Fixes are trivial:

* Replace "interp->modules" with PyImport_GetModuleDict()
* Replace "interp->builtins" with PyEval_GetBuiltins()

I close the issue. Well done Eric!

----------
components: +C API
resolution:  -> fixed
status: open -> closed
title: Move PyInterpreterState into Include/internal/pycore_pystate.h -> [C API] Make PyInterpreterState opaque: move it into the internal C API (internal/pycore_pystate.h)

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35886>
_______________________________________

From report at bugs.python.org  Wed Apr 22 13:44:56 2020
From: report at bugs.python.org (Steve Dower)
Date: Wed, 22 Apr 2020 17:44:56 +0000
Subject: [issue40260] modulefinder traceback regression starting on Windows
In-Reply-To: <1587576526.82.0.952397187209.issue40260@roundup.psfhosted.org>
Message-ID: <245aeeb9-1db4-3e71-fcad-02725f6b1542@python.org>


Steve Dower <steve.dower at python.org> added the comment:

Okay, no problems then.

We'll have to close that other PR now. Too bad nobody noticed it (or 
knew where to send it - I doubt modulefinder has an obvious owner).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40260>
_______________________________________

From report at bugs.python.org  Wed Apr 22 13:52:40 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 22 Apr 2020 17:52:40 +0000
Subject: [issue39471] Meaning and clarification of PyBuffer_Release()
In-Reply-To: <1580163259.11.0.807397733698.issue39471@roundup.psfhosted.org>
Message-ID: <1587577960.24.0.324759928754.issue39471@roundup.psfhosted.org>


Change by Mark Dickinson <dickinsm at gmail.com>:


----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39471>
_______________________________________

From report at bugs.python.org  Wed Apr 22 13:56:20 2020
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 22 Apr 2020 17:56:20 +0000
Subject: [issue40361] Darwin systems using win settings for webbrowser.py
Message-ID: <1587578180.28.0.28235895563.issue40361@roundup.psfhosted.org>


New submission from ?ric Araujo <merwok at netwok.org>:

Hello!  You didn?t give any information about the problem you found :)

----------
components: +Library (Lib) -Distutils
nosy:  -dstufft
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40361>
_______________________________________

From report at bugs.python.org  Wed Apr 22 13:57:20 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Wed, 22 Apr 2020 17:57:20 +0000
Subject: [issue40360] Deprecate lib2to3 (and 2to3) for future removal
In-Reply-To: <1587530454.25.0.44181585934.issue40360@roundup.psfhosted.org>
Message-ID: <1587578240.21.0.100422246783.issue40360@roundup.psfhosted.org>


Change by Batuhan Taskaya <batuhanosmantaskaya at gmail.com>:


----------
nosy: +BTaskaya

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40360>
_______________________________________

From report at bugs.python.org  Wed Apr 22 14:10:08 2020
From: report at bugs.python.org (Eric Snow)
Date: Wed, 22 Apr 2020 18:10:08 +0000
Subject: [issue40360] Deprecate lib2to3 (and 2to3) for future removal
In-Reply-To: <1587530454.25.0.44181585934.issue40360@roundup.psfhosted.org>
Message-ID: <1587579008.16.0.251460024407.issue40360@roundup.psfhosted.org>


Change by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40360>
_______________________________________

From report at bugs.python.org  Wed Apr 22 14:18:16 2020
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 22 Apr 2020 18:18:16 +0000
Subject: [issue40358] pathlib's relative_to should behave like os.path.relpath
In-Reply-To: <1587513783.17.0.6950267733.issue40358@roundup.psfhosted.org>
Message-ID: <1587579496.98.0.573733631196.issue40358@roundup.psfhosted.org>


Antoine Pitrou <solipsis at pitrou.net> added the comment:

The current behaviour is by design.  I would not mind adding an option to control it, though.

If you are new to Python development and want to submit a patch or PR, I recommend reading the Developer's Guide:
https://devguide.python.org/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40358>
_______________________________________

From report at bugs.python.org  Wed Apr 22 14:22:06 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 22 Apr 2020 18:22:06 +0000
Subject: [issue40363] shlex.quote applied to a glob pattern disables glob
 matching
In-Reply-To: <1587568891.1.0.0837751696044.issue40363@roundup.psfhosted.org>
Message-ID: <1587579726.72.0.971468782589.issue40363@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

Agreed that shlex.quote is working as intended. It's goal is to pass something to the shell, preserving it just as you started with it. It exists exactly because you want to avoid shell globbing and parsing issues (consider filenames that contain spaces and *'s).

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40363>
_______________________________________

From report at bugs.python.org  Wed Apr 22 14:24:04 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 22 Apr 2020 18:24:04 +0000
Subject: [issue40363] shlex.quote applied to a glob pattern disables glob
 matching
In-Reply-To: <1587568891.1.0.0837751696044.issue40363@roundup.psfhosted.org>
Message-ID: <1587579844.74.0.505607830722.issue40363@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

I meant to add: it's possible that this isn't well documented.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40363>
_______________________________________

From report at bugs.python.org  Wed Apr 22 14:43:07 2020
From: report at bugs.python.org (Steve Dower)
Date: Wed, 22 Apr 2020 18:43:07 +0000
Subject: [issue40260] modulefinder traceback regression starting on Windows
In-Reply-To: <1586680620.99.0.514402715757.issue40260@roundup.psfhosted.org>
Message-ID: <1587580987.78.0.882753836592.issue40260@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:


New changeset 39652cd8bdf7c82b7c6055089a4ed90ee546a448 by Anthony Sottile in branch 'master':
bpo-40260: Remove unnecessary newline in compile() call (GH-19641)
https://github.com/python/cpython/commit/39652cd8bdf7c82b7c6055089a4ed90ee546a448


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40260>
_______________________________________

From report at bugs.python.org  Wed Apr 22 14:43:11 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 22 Apr 2020 18:43:11 +0000
Subject: [issue40260] modulefinder traceback regression starting on Windows
In-Reply-To: <1586680620.99.0.514402715757.issue40260@roundup.psfhosted.org>
Message-ID: <1587580991.7.0.28996244757.issue40260@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +18985
pull_request: https://github.com/python/cpython/pull/19659

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40260>
_______________________________________

From report at bugs.python.org  Wed Apr 22 14:49:00 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 22 Apr 2020 18:49:00 +0000
Subject: [issue40365] argparse: action "extend" with 1 parameter splits
 strings into characters
In-Reply-To: <1587577356.91.0.833148420465.issue40365@roundup.psfhosted.org>
Message-ID: <1587581340.45.0.429580728748.issue40365@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +paul.j3, rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40365>
_______________________________________

From report at bugs.python.org  Wed Apr 22 15:00:13 2020
From: report at bugs.python.org (Domenico Ragusa)
Date: Wed, 22 Apr 2020 19:00:13 +0000
Subject: [issue40358] pathlib's relative_to should behave like os.path.relpath
In-Reply-To: <1587579496.98.0.573733631196.issue40358@roundup.psfhosted.org>
Message-ID: <CAHsu_9WMOLqUQC3i9NXyXiTMRXvuiJ-beb4oMy1o5FC5xj1XCQ@mail.gmail.com>


Domenico Ragusa <domenicoragusa at gmail.com> added the comment:

Thanks for your answer. Yeah, I'm new, I'm reading the guide, sorry for any
faux pas :)

Ok, an option would be great as well, a simple True/False switch? Any
suggestion for the name?
I'll get back with a proper patch this time.

On Wed, Apr 22, 2020 at 8:18 PM Antoine Pitrou <report at bugs.python.org>
wrote:

>
> Antoine Pitrou <solipsis at pitrou.net> added the comment:
>
> The current behaviour is by design.  I would not mind adding an option to
> control it, though.
>
> If you are new to Python development and want to submit a patch or PR, I
> recommend reading the Developer's Guide:
> https://devguide.python.org/
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue40358>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40358>
_______________________________________

From report at bugs.python.org  Wed Apr 22 15:05:17 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 22 Apr 2020 19:05:17 +0000
Subject: [issue40260] modulefinder traceback regression starting on Windows
In-Reply-To: <1586680620.99.0.514402715757.issue40260@roundup.psfhosted.org>
Message-ID: <1587582317.17.0.814308912107.issue40260@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset fc45cb4400409572f05c8b54f2c6f06cbefb1b4e by Miss Islington (bot) in branch '3.8':
bpo-40260: Remove unnecessary newline in compile() call (GH-19641)
https://github.com/python/cpython/commit/fc45cb4400409572f05c8b54f2c6f06cbefb1b4e


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40260>
_______________________________________

From report at bugs.python.org  Wed Apr 22 15:08:55 2020
From: report at bugs.python.org (Kyle Stanley)
Date: Wed, 22 Apr 2020 19:08:55 +0000
Subject: [issue40364] asyncio: replace _compute_returncode() with
 os.waitstatus_to_exitcode()
In-Reply-To: <1587574271.75.0.606427962214.issue40364@roundup.psfhosted.org>
Message-ID: <1587582535.07.0.170368773447.issue40364@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:

Victor Stinner wrote:
> Is there someone interested to propose a PR for that?

I would be interested in looking into this, although I'm not entirely certain either as to how it should be tested at the moment. I'll have to look further into the existing ones.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40364>
_______________________________________

From report at bugs.python.org  Wed Apr 22 15:09:38 2020
From: report at bugs.python.org (Kyle Stanley)
Date: Wed, 22 Apr 2020 19:09:38 +0000
Subject: [issue40364] asyncio: replace _compute_returncode() with
 os.waitstatus_to_exitcode()
In-Reply-To: <1587574271.75.0.606427962214.issue40364@roundup.psfhosted.org>
Message-ID: <1587582578.8.0.385521668971.issue40364@roundup.psfhosted.org>


Change by Kyle Stanley <aeros167 at gmail.com>:


----------
assignee:  -> aeros

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40364>
_______________________________________

From report at bugs.python.org  Wed Apr 22 15:15:06 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 22 Apr 2020 19:15:06 +0000
Subject: [issue36299] array: Deprecate 'u' type in array module
In-Reply-To: <1552629002.67.0.658973531537.issue36299@roundup.psfhosted.org>
Message-ID: <1587582906.44.0.347504978241.issue36299@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Should this issue be closed, possibly as superseded by #36346, the issue for the new PR-19653?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36299>
_______________________________________

From report at bugs.python.org  Wed Apr 22 15:26:48 2020
From: report at bugs.python.org (paul j3)
Date: Wed, 22 Apr 2020 19:26:48 +0000
Subject: [issue40365] argparse: action "extend" with 1 parameter splits
 strings into characters
In-Reply-To: <1587577356.91.0.833148420465.issue40365@roundup.psfhosted.org>
Message-ID: <1587583608.2.0.638995294593.issue40365@roundup.psfhosted.org>


paul j3 <ajipanca at gmail.com> added the comment:

This is a consequence of Python's own definition of append vs extend

In [730]: alist = []                                                                                   
In [731]: alist.append('astring')                                                                      
In [732]: alist                                                                                        
Out[732]: ['astring']
In [733]: alist.extend('astring')                                                                      
In [734]: alist                                                                                        
Out[734]: ['astring', 'a', 's', 't', 'r', 'i', 'n', 'g']
In [735]: alist.extend(['astring'])                                                                    
In [736]: alist                                                                                        
Out[736]: ['astring', 'a', 's', 't', 'r', 'i', 'n', 'g', 'astring']

Normally 'add_argument' doesn't check for valid parameters, but some Action subclasses do their own checking, 

'extend' inherits the nargs==0 test from 'append'. (extend just modifies the __call__, not the __init__ method.

But I wonder, was this situation discussed in the original bug/issue?

----------

_______________________________________
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: [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 15:50:21 2020
From: report at bugs.python.org (Eryk Sun)
Date: Wed, 22 Apr 2020 19:50:21 +0000
Subject: [issue40358] pathlib's relative_to should behave like os.path.relpath
In-Reply-To: <1587513783.17.0.6950267733.issue40358@roundup.psfhosted.org>
Message-ID: <1587585021.43.0.391857493828.issue40358@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

Note that the implementation of relpath is pure and thus assumes it's working with existing, resolved paths (i.e. "the filesystem is not accessed to confirm the existence or nature of path or start"). For example:

    >>> os.path.relpath('/some/thing', '/symlink')
    '../some/thing'

If "symlink" targets "/spam/eggs/foo", then the resolved path would be "/spam/eggs/some/thing" instead of "/some/thing". Maybe the relative_to method should default to a `strict` mode that raises ValueError on ambiguous cases that depend on the "existence or nature" of the paths. I think the current implementation is strict.

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40358>
_______________________________________

From report at bugs.python.org  Wed Apr 22 15:51:38 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Wed, 22 Apr 2020 19:51:38 +0000
Subject: [issue40366] Start giving deprecation warnings for obsoleted flags in
 compile
In-Reply-To: <1587584663.02.0.972629021884.issue40366@roundup.psfhosted.org>
Message-ID: <1587585098.0.0.883372642987.issue40366@roundup.psfhosted.org>


Change by Batuhan Taskaya <batuhanosmantaskaya at gmail.com>:


----------
keywords: +patch
pull_requests: +18986
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19660

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40366>
_______________________________________

From report at bugs.python.org  Wed Apr 22 16:02:40 2020
From: report at bugs.python.org (desbma)
Date: Wed, 22 Apr 2020 20:02:40 +0000
Subject: [issue37157] shutil: add reflink=False to file copy functions to
 control clone/CoW copies (use copy_file_range)
In-Reply-To: <1559684200.61.0.18008315195.issue37157@roundup.psfhosted.org>
Message-ID: <1587585760.82.0.313745351544.issue37157@roundup.psfhosted.org>


Change by desbma <dutch109 at gmail.com>:


----------
nosy: +desbma

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37157>
_______________________________________

From report at bugs.python.org  Wed Apr 22 16:50:05 2020
From: report at bugs.python.org (Carl Meyer)
Date: Wed, 22 Apr 2020 20:50:05 +0000
Subject: [issue40360] Deprecate lib2to3 (and 2to3) for future removal
In-Reply-To: <1587530454.25.0.44181585934.issue40360@roundup.psfhosted.org>
Message-ID: <1587588605.79.0.893346078422.issue40360@roundup.psfhosted.org>


Change by Carl Meyer <carl at oddbird.net>:


----------
pull_requests: +18987
pull_request: https://github.com/python/cpython/pull/19663

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40360>
_______________________________________

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: [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:05:51 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 22 Apr 2020 21:05:51 +0000
Subject: [issue39939] PEP 616: Add str methods to remove prefix or suffix
In-Reply-To: <1583953898.19.0.613718077904.issue39939@roundup.psfhosted.org>
Message-ID: <1587589551.93.0.274188725368.issue39939@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset a81849b0315277bb3937271174aaaa5059c0b445 by sweeneyde in branch 'master':
bpo-39939: Add str.removeprefix and str.removesuffix (GH-18939)
https://github.com/python/cpython/commit/a81849b0315277bb3937271174aaaa5059c0b445


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39939>
_______________________________________

From report at bugs.python.org  Wed Apr 22 17:07:54 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 22 Apr 2020 21:07:54 +0000
Subject: [issue40334] PEP 617: new PEG-based parser
In-Reply-To: <1587327377.33.0.614039250584.issue40334@roundup.psfhosted.org>
Message-ID: <1587589674.92.0.55669170349.issue40334@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

VIctor, you were very right about longjmp. See https://github.com/we-like-parsers/cpython/pull/119

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40334>
_______________________________________

From report at bugs.python.org  Wed Apr 22 17:15:02 2020
From: report at bugs.python.org (Carl Meyer)
Date: Wed, 22 Apr 2020 21:15:02 +0000
Subject: [issue40360] Deprecate lib2to3 (and 2to3) for future removal
In-Reply-To: <1587530454.25.0.44181585934.issue40360@roundup.psfhosted.org>
Message-ID: <1587590102.69.0.453863524042.issue40360@roundup.psfhosted.org>


Carl Meyer <carl at oddbird.net> added the comment:

I opened a PR. It deprecates the lib2to3 library to discourage future use of it for Python3, but not the 2to3 tool. This of course means that the lib2to3 module will in practice stick around in the stdlib as long as 2to3 is still bundled with Python.

It seems like the idea in this issue is to deprecate and remove both. I'm not sure what we typically do to deprecate a command-line utility bundled with Python. Given warnings are silent by default, the deprecation warning for lib2to3 won't be visible to users of 2to3. Should I add something to its `--help` output? Or something more aggressive; an unconditionally-printed warning?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40360>
_______________________________________

From report at bugs.python.org  Wed Apr 22 17:16:57 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 22 Apr 2020 21:16:57 +0000
Subject: [issue39939] PEP 616: Add str.removeprefix and str.removesuffix
 methods
In-Reply-To: <1583953898.19.0.613718077904.issue39939@roundup.psfhosted.org>
Message-ID: <1587590217.03.0.996269019173.issue39939@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Well done Dennis Sweeney! You got a PEP approved and now the implementation is merged!

Maybe the documentation will need more reviews, but that can be done later. 

I prefer to get the implementation merged as soon as possible (it will likely be part of the next 3.9.0a6), so more users can play with it before 3.9.0 final release.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
title: PEP 616: Add str methods to remove prefix or suffix -> PEP 616: Add str.removeprefix and str.removesuffix methods

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39939>
_______________________________________

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: [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 18:00:35 2020
From: report at bugs.python.org (Eryk Sun)
Date: Wed, 22 Apr 2020 22:00:35 +0000
Subject: [issue40368] os.path.realpath uppercases Windows drive letter on
 Python 3.8
In-Reply-To: <1587590743.67.0.821024621015.issue40368@roundup.psfhosted.org>
Message-ID: <1587592835.92.0.407707188545.issue40368@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> This behavior is inconsistent with `os.path.abspath` where it always 
> returns lowercased drive letter, 

ntpath.abspath calls GetFullPathNameW, which generally preserves the input case of the device/drive component. But it doesn't always preserve drive-letter case. In particular, a drive-relative path gets resolved with the upper-case drive letter:

    >>> os.path.abspath('c:spam')
    'C:\\Temp\\spam'

That's a corner case that maybe needs to be addressed for ntpath.abspath. However, regarding ntpath.realpath, I see no reason for it to preserve the input case. To the contrary, it should always make a best effort to normalize the input path to use the real device and component names and replace 8.3 short names with long names.

> and also causes a failure in Gecko build script: 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1628726

IMO, the bug there is using a case-insensitive path as a key without first case folding the string.

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40368>
_______________________________________

From report at bugs.python.org  Wed Apr 22 18:14:45 2020
From: report at bugs.python.org (Dennis Sweeney)
Date: Wed, 22 Apr 2020 22:14:45 +0000
Subject: [issue39939] PEP 616: Add str.removeprefix and str.removesuffix
 methods
In-Reply-To: <1583953898.19.0.613718077904.issue39939@roundup.psfhosted.org>
Message-ID: <1587593685.45.0.473524054636.issue39939@roundup.psfhosted.org>


Dennis Sweeney <sweeney.dennis650 at gmail.com> added the comment:

There's a failure here:

    https://buildbot.python.org/all/#/builders/64/builds/656

    Failed subtests:
    test_killed_child - test.test_concurrent_futures.ProcessPoolSpawnProcessPoolExecutorTest

    Traceback (most recent call last):
    ...
    OSError: [Errno 9] Bad file descriptor

This should be unrelated to the patch, right?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39939>
_______________________________________

From report at bugs.python.org  Wed Apr 22 18:21:47 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 22 Apr 2020 22:21:47 +0000
Subject: [issue39939] PEP 616: Add str.removeprefix and str.removesuffix
 methods
In-Reply-To: <1583953898.19.0.613718077904.issue39939@roundup.psfhosted.org>
Message-ID: <1587594107.74.0.538642538648.issue39939@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> This should be unrelated to the patch, right?

It's unrelated. It smells like bpo-39995.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39939>
_______________________________________

From report at bugs.python.org  Wed Apr 22 18:29:49 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 22 Apr 2020 22:29:49 +0000
Subject: [issue40334] PEP 617: new PEG-based parser
In-Reply-To: <1587327377.33.0.614039250584.issue40334@roundup.psfhosted.org>
Message-ID: <1587594589.93.0.627322372136.issue40334@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset c5fc15685202cda73f7c3f5c6f299b0945f58508 by Pablo Galindo in branch 'master':
bpo-40334: PEP 617 implementation: New PEG parser for CPython (GH-19503)
https://github.com/python/cpython/commit/c5fc15685202cda73f7c3f5c6f299b0945f58508


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40334>
_______________________________________

From report at bugs.python.org  Wed Apr 22 18:34:23 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 22 Apr 2020 22:34:23 +0000
Subject: [issue40334] PEP 617: new PEG-based parser
In-Reply-To: <1587327377.33.0.614039250584.issue40334@roundup.psfhosted.org>
Message-ID: <1587594863.56.0.400250991282.issue40334@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
pull_requests: +18988
pull_request: https://github.com/python/cpython/pull/19664

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40334>
_______________________________________

From report at bugs.python.org  Wed Apr 22 18:53:31 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 22 Apr 2020 22:53:31 +0000
Subject: [issue40346] Add random.BaseRandom to ease implementation of
 subclasses
In-Reply-To: <1587419589.68.0.186666450831.issue40346@roundup.psfhosted.org>
Message-ID: <1587596011.17.0.134836008274.issue40346@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Ok, PR 19631 is now ready for a review. I completed the documentation to better explain the rationale.

Copy of the What's New in Python 3.9 documentation:

"Add a new random.BaseRandom class: random number generator base class. A random.BaseRandom subclass must only implement a single method: getrandbits(), whereas a random.Random subclass must override 6 methods (getrandbits(), random(), randbytes(), seed(), getstate() and setstate())."

Copy of the commit message:

"BaseRandom implements random() and randbytes() using getrandbits().
It has no state and its gauss() method is thread safe. It has no
VERSION attribute and its seed() method has no version parameter.

The implementation of random.Random, random.SystemRandom and
random.Random subclasses are not affected by this change."

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40346>
_______________________________________

From report at bugs.python.org  Wed Apr 22 18:54:01 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 22 Apr 2020 22:54:01 +0000
Subject: [issue40334] PEP 617: new PEG-based parser
In-Reply-To: <1587327377.33.0.614039250584.issue40334@roundup.psfhosted.org>
Message-ID: <1587596041.29.0.61566428674.issue40334@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
pull_requests: +18989
pull_request: https://github.com/python/cpython/pull/19666

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40334>
_______________________________________

From report at bugs.python.org  Wed Apr 22 19:13:52 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 22 Apr 2020 23:13:52 +0000
Subject: [issue40334] PEP 617: new PEG-based parser
In-Reply-To: <1587327377.33.0.614039250584.issue40334@roundup.psfhosted.org>
Message-ID: <1587597232.92.0.997971279465.issue40334@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset 458004bf7914f96b20bb76bc3584718cf83f652e by Pablo Galindo in branch 'master':
bpo-40334: Fix errors in parse_string.c with old compilers (GH-19666)
https://github.com/python/cpython/commit/458004bf7914f96b20bb76bc3584718cf83f652e


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40334>
_______________________________________

From report at bugs.python.org  Wed Apr 22 19:19:28 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 22 Apr 2020 23:19:28 +0000
Subject: [issue40334] PEP 617: new PEG-based parser
In-Reply-To: <1587327377.33.0.614039250584.issue40334@roundup.psfhosted.org>
Message-ID: <1587597568.65.0.454397218897.issue40334@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> bpo-40334: Fix errors in parse_string.c with old compilers (GH-19666)

Pablo told me in private that he plans to add a buildbot worker to test the old parser. So this change is fine.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40334>
_______________________________________

From report at bugs.python.org  Wed Apr 22 19:21:25 2020
From: report at bugs.python.org (Ned Deily)
Date: Wed, 22 Apr 2020 23:21:25 +0000
Subject: [issue40334] PEP 617: new PEG-based parser
In-Reply-To: <1587327377.33.0.614039250584.issue40334@roundup.psfhosted.org>
Message-ID: <1587597685.38.0.742835868867.issue40334@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

Looks like the build changes do not work with a build directory outside of the source directory:

mkdir build && cd build && ../configure && make

gcc -c -Wno-unused-result -Wsign-compare -Wunreachable-code -DNDEBUG -g -fwrapv -O3 -Wall    -std=c99 -Wextra -Wno-unused-result -Wno-unused-parameter -Wno-missing-field-initializers -Wstrict-prototypes -Werror=implicit-function-declaration -fvisibility=hidden  -I../Include/internal -IObjects -IInclude -IPython -I. -I../Include    -DPy_BUILD_CORE -o Parser/pegen/pegen.o ../Parser/pegen/pegen.c
error: unable to open output file 'Parser/pegen/pegen.o': 'No such file or directory'
1 error generated.
make: *** [Parser/pegen/pegen.o] Error 1

Lots of build processes depend on this, like for putting out a release.

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40334>
_______________________________________

From report at bugs.python.org  Wed Apr 22 19:31:59 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Wed, 22 Apr 2020 23:31:59 +0000
Subject: [issue40366] Start giving deprecation warnings for obsoleted flags in
 compile
In-Reply-To: <1587584663.02.0.972629021884.issue40366@roundup.psfhosted.org>
Message-ID: <1587598319.39.0.474984643253.issue40366@roundup.psfhosted.org>


Batuhan Taskaya <batuhanosmantaskaya at gmail.com> added the comment:

As suggestion of @vstinner, instead of deprecation we decided to remove support for these flags immediately.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40366>
_______________________________________

From report at bugs.python.org  Wed Apr 22 19:32:17 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Wed, 22 Apr 2020 23:32:17 +0000
Subject: [issue40366] Remove support for obsolete flags in compile function
In-Reply-To: <1587584663.02.0.972629021884.issue40366@roundup.psfhosted.org>
Message-ID: <1587598337.76.0.24610693376.issue40366@roundup.psfhosted.org>


Change by Batuhan Taskaya <batuhanosmantaskaya at gmail.com>:


----------
title: Start giving deprecation warnings for obsoleted flags in compile -> Remove support for obsolete flags in compile function

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40366>
_______________________________________

From report at bugs.python.org  Wed Apr 22 19:42:28 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 22 Apr 2020 23:42:28 +0000
Subject: [issue40334] PEP 617: new PEG-based parser
In-Reply-To: <1587327377.33.0.614039250584.issue40334@roundup.psfhosted.org>
Message-ID: <1587598948.64.0.955305050174.issue40334@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
pull_requests: +18990
pull_request: https://github.com/python/cpython/pull/19667

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40334>
_______________________________________

From report at bugs.python.org  Wed Apr 22 19:42:52 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 22 Apr 2020 23:42:52 +0000
Subject: [issue40334] PEP 617: new PEG-based parser
In-Reply-To: <1587327377.33.0.614039250584.issue40334@roundup.psfhosted.org>
Message-ID: <1587598972.77.0.539824079384.issue40334@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

> Looks like the build changes do not work with a build directory outside of the source directory:

Opened https://github.com/python/cpython/pull/19667. Ned, could you review?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40334>
_______________________________________

From report at bugs.python.org  Wed Apr 22 20:07:29 2020
From: report at bugs.python.org (Lysandros Nikolaou)
Date: Thu, 23 Apr 2020 00:07:29 +0000
Subject: [issue40334] PEP 617: new PEG-based parser
In-Reply-To: <1587327377.33.0.614039250584.issue40334@roundup.psfhosted.org>
Message-ID: <1587600449.94.0.922652711105.issue40334@roundup.psfhosted.org>


Change by Lysandros Nikolaou <lisandrosnik at gmail.com>:


----------
pull_requests: +18991
pull_request: https://github.com/python/cpython/pull/19669

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40334>
_______________________________________

From report at bugs.python.org  Wed Apr 22 20:07:49 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 23 Apr 2020 00:07:49 +0000
Subject: [issue40334] PEP 617: new PEG-based parser
In-Reply-To: <1587327377.33.0.614039250584.issue40334@roundup.psfhosted.org>
Message-ID: <1587600469.9.0.691026298385.issue40334@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +18992
pull_request: https://github.com/python/cpython/pull/19670

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40334>
_______________________________________

From report at bugs.python.org  Wed Apr 22 20:12:19 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 23 Apr 2020 00:12:19 +0000
Subject: [issue40334] PEP 617: new PEG-based parser
In-Reply-To: <1587327377.33.0.614039250584.issue40334@roundup.psfhosted.org>
Message-ID: <1587600739.21.0.609989414774.issue40334@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
pull_requests: +18993
pull_request: https://github.com/python/cpython/pull/19668

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40334>
_______________________________________

From report at bugs.python.org  Wed Apr 22 20:38:15 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 23 Apr 2020 00:38:15 +0000
Subject: [issue40334] PEP 617: new PEG-based parser
In-Reply-To: <1587327377.33.0.614039250584.issue40334@roundup.psfhosted.org>
Message-ID: <1587602295.49.0.276495842771.issue40334@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset a25f3c4c8f7d4878918ce1d3d67db40ae255ccc6 by Pablo Galindo in branch 'master':
bpo-40334: Fix builds outside the source directory and regenerate autoconf files (GH-19667)
https://github.com/python/cpython/commit/a25f3c4c8f7d4878918ce1d3d67db40ae255ccc6


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40334>
_______________________________________

From report at bugs.python.org  Wed Apr 22 20:47:43 2020
From: report at bugs.python.org (Inada Naoki)
Date: Thu, 23 Apr 2020 00:47:43 +0000
Subject: [issue36299] array: Deprecate 'u' type in array module
In-Reply-To: <1552629002.67.0.658973531537.issue36299@roundup.psfhosted.org>
Message-ID: <1587602863.74.0.314829915277.issue36299@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

While array('u') doesn't use deprecated API with GH-19653, I still don't like 'u' because:

* I don't have any reason to use platform dependant wchar_t. [1]
* It is not consistent with PEP-3118.

[1]: https://mail.python.org/pipermail/python-dev/2019-March/156807.html

How about this plan?

* Add 'w' for Py_UCS4.
* Deprecate 'u', and remove it in the future.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36299>
_______________________________________

From report at bugs.python.org  Wed Apr 22 21:03:27 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 23 Apr 2020 01:03:27 +0000
Subject: [issue40334] PEP 617: new PEG-based parser
In-Reply-To: <1587327377.33.0.614039250584.issue40334@roundup.psfhosted.org>
Message-ID: <1587603807.8.0.877669051793.issue40334@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 1def7754b7a41fe57efafaf5eff24cfa15353444 by Victor Stinner in branch 'master':
bpo-40334: Rename PyConfig.use_peg to _use_peg_parser (GH-19670)
https://github.com/python/cpython/commit/1def7754b7a41fe57efafaf5eff24cfa15353444


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40334>
_______________________________________

From report at bugs.python.org  Wed Apr 22 21:09:20 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 23 Apr 2020 01:09:20 +0000
Subject: [issue40334] PEP 617: new PEG-based parser
In-Reply-To: <1587327377.33.0.614039250584.issue40334@roundup.psfhosted.org>
Message-ID: <1587604160.52.0.235361164004.issue40334@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> bpo-40334: Rename PyConfig.use_peg to _use_peg_parser (GH-19670)

This change removes sys.flags.use_peg which was only used in tests. If someone sees a good reason, we may add it back. In the meanwhile, test.support.use_old_parser() can be used.

I didn't like the idea of having a new sys.flags.use_peg flag appears in 3.9 but disappears in 3.10.

FYI sys.flags still supports the tuple API! Example:

>>> sys.flags[9]
0

I have no idea what is this 10th member of sys.flags :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40334>
_______________________________________

From report at bugs.python.org  Wed Apr 22 21:15:55 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 23 Apr 2020 01:15:55 +0000
Subject: [issue40334] PEP 617: new PEG-based parser
In-Reply-To: <1587327377.33.0.614039250584.issue40334@roundup.psfhosted.org>
Message-ID: <1587604555.63.0.664069439198.issue40334@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

test_peg_generator emits compiler warnings:

https://buildbot.python.org/all/#/builders/612/builds/283

0:08:01 load avg: 1.40 [423/423/1] test_peg_generator passed (7 min 4 sec)
/tmp/tmp0vbqe8gp/parse.c: In function ?start_rule?:
/tmp/tmp0vbqe8gp/parse.c:32:35: warning: passing argument 2 of ?_PyPegen_lookahead? from incompatible pointer type [-Wincompatible-pointer-types]
   32 |             _PyPegen_lookahead(1, _PyPegen_name_token, p)
      |                                   ^~~~~~~~~~~~~~~~~~~
      |                                   |
      |                                   struct _expr * (*)(Parser *)
In file included from /tmp/tmp0vbqe8gp/parse.c:2:
/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-aarch64.lto-pgo/build/Parser/pegen/pegen.h:90:36: note: expected ?void * (*)(Parser *)? but argument is of type ?struct _expr * (*)(Parser *)?
   90 | int _PyPegen_lookahead(int, void *(func)(Parser *), Parser *);
      |                             ~~~~~~~^~~~~~~~~~~~~~~
/tmp/tmp54o68k3n/parse.c: In function ?start_rule?:
/tmp/tmp54o68k3n/parse.c:32:35: warning: passing argument 2 of ?_PyPegen_lookahead? from incompatible pointer type [-Wincompatible-pointer-types]
   32 |             _PyPegen_lookahead(0, _PyPegen_name_token, p)
      |                                   ^~~~~~~~~~~~~~~~~~~
      |                                   |
      |                                   struct _expr * (*)(Parser *)
In file included from /tmp/tmp54o68k3n/parse.c:2:
/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-aarch64.lto-pgo/build/Parser/pegen/pegen.h:90:36: note: expected ?void * (*)(Parser *)? but argument is of type ?struct _expr * (*)(Parser *)?
   90 | int _PyPegen_lookahead(int, void *(func)(Parser *), Parser *);
      |                             ~~~~~~~^~~~~~~~~~~~~~~

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40334>
_______________________________________

From report at bugs.python.org  Wed Apr 22 21:18:51 2020
From: report at bugs.python.org (Lysandros Nikolaou)
Date: Thu, 23 Apr 2020 01:18:51 +0000
Subject: [issue40334] PEP 617: new PEG-based parser
In-Reply-To: <1587327377.33.0.614039250584.issue40334@roundup.psfhosted.org>
Message-ID: <1587604731.92.0.495335547179.issue40334@roundup.psfhosted.org>


Lysandros Nikolaou <lisandrosnik at gmail.com> added the comment:

> test_peg_generator emits compiler warnings

These are expected. Is this a problem?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40334>
_______________________________________

From report at bugs.python.org  Wed Apr 22 21:33:17 2020
From: report at bugs.python.org (Wade Sanchez)
Date: Thu, 23 Apr 2020 01:33:17 +0000
Subject: [issue40334] PEP 617: new PEG-based parser
In-Reply-To: <1587327377.33.0.614039250584.issue40334@roundup.psfhosted.org>
Message-ID: <1587605597.14.0.0287074735543.issue40334@roundup.psfhosted.org>


Change by Wade Sanchez <rosindo077 at gmail.com>:


----------
type:  -> resource usage

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40334>
_______________________________________

From report at bugs.python.org  Wed Apr 22 21:34:56 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 23 Apr 2020 01:34:56 +0000
Subject: [issue40334] PEP 617: new PEG-based parser
In-Reply-To: <1587327377.33.0.614039250584.issue40334@roundup.psfhosted.org>
Message-ID: <1587605696.04.0.942780344575.issue40334@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
pull_requests: +18994
pull_request: https://github.com/python/cpython/pull/19671

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40334>
_______________________________________

From report at bugs.python.org  Wed Apr 22 21:53:04 2020
From: report at bugs.python.org (Viraat Das)
Date: Thu, 23 Apr 2020 01:53:04 +0000
Subject: [issue40361] Darwin systems using win settings for webbrowser.py
In-Reply-To: <1587578180.28.0.28235895563.issue40361@roundup.psfhosted.org>
Message-ID: <1587606784.75.0.504441806741.issue40361@roundup.psfhosted.org>


Viraat Das <viraat.laldas at gmail.com> added the comment:

When loading Jupyter Notebook, a NotADirectoryError: [Errno 20] Not a directory: 'xdg-settings' error was showing. This seems to be because Darwin systems were using Win settings. 

The pull request has addressed this by modifying the webbrowser.py code.

----------
keywords: +patch
message_count: 1.0 -> 2.0
pull_requests: +18995
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19649

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40361>
_______________________________________

From report at bugs.python.org  Wed Apr 22 21:55:43 2020
From: report at bugs.python.org (Ned Deily)
Date: Thu, 23 Apr 2020 01:55:43 +0000
Subject: [issue40334] PEP 617: new PEG-based parser
In-Reply-To: <1587327377.33.0.614039250584.issue40334@roundup.psfhosted.org>
Message-ID: <1587606943.37.0.371269083862.issue40334@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

> These are expected. Is this a problem?

People and bots running tests normally expect to not see any output from each test in the default case unless there are errors.  If these are supposed to be emitted, we should find a way to hide them (and check the results, if necessary) unless a verbose option is selected.  Personally, I wouldn't consider that a showstopper for a6 but as something to be fixed by b1.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40334>
_______________________________________

From report at bugs.python.org  Wed Apr 22 22:23:22 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 23 Apr 2020 02:23:22 +0000
Subject: [issue40334] PEP 617: new PEG-based parser
In-Reply-To: <1587327377.33.0.614039250584.issue40334@roundup.psfhosted.org>
Message-ID: <1587608602.61.0.0695379934929.issue40334@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
pull_requests: +18996
pull_request: https://github.com/python/cpython/pull/19672

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40334>
_______________________________________

From report at bugs.python.org  Wed Apr 22 22:29:58 2020
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 23 Apr 2020 02:29:58 +0000
Subject: [issue40361] Darwin systems using win settings for webbrowser.py
In-Reply-To: <1587578180.28.0.28235895563.issue40361@roundup.psfhosted.org>
Message-ID: <1587608998.97.0.887043168845.issue40361@roundup.psfhosted.org>


?ric Araujo <merwok at netwok.org> added the comment:

xdg-settings is a program used on linux systems, not windows.  Also it is an executable file, not a directory, so something weird is going on.

Could you diagnose more?  The proposed PR does not seem to make sense: platform can?t be both darwin and win32/nt.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40361>
_______________________________________

From report at bugs.python.org  Wed Apr 22 22:43:11 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 23 Apr 2020 02:43:11 +0000
Subject: [issue40334] PEP 617: new PEG-based parser
In-Reply-To: <1587327377.33.0.614039250584.issue40334@roundup.psfhosted.org>
Message-ID: <1587609791.55.0.242780565572.issue40334@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset ee40e4b8563e6e1bc2bfb267da5ffc9a2293318d by Pablo Galindo in branch 'master':
bpo-40334: Don't downcast from Py_ssize_t to int (GH-19671)
https://github.com/python/cpython/commit/ee40e4b8563e6e1bc2bfb267da5ffc9a2293318d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40334>
_______________________________________

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: [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  Wed Apr 22 22:51:15 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 23 Apr 2020 02:51:15 +0000
Subject: [issue40334] PEP 617: new PEG-based parser
In-Reply-To: <1587327377.33.0.614039250584.issue40334@roundup.psfhosted.org>
Message-ID: <1587610275.14.0.0162050543139.issue40334@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

> test_peg_generator emits compiler warnings:

This is fixed by https://github.com/python/cpython/pull/19672

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40334>
_______________________________________

From report at bugs.python.org  Wed Apr 22 22:52:25 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 23 Apr 2020 02:52:25 +0000
Subject: [issue40334] PEP 617: new PEG-based parser
In-Reply-To: <1587327377.33.0.614039250584.issue40334@roundup.psfhosted.org>
Message-ID: <1587610345.25.0.650815872467.issue40334@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Those warnings are legitimate: we cannot cast function pointers that have different return types from one to the other. This only happens in the test, but could happen in the grammar if we use lookahead with NAME (&NAME).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40334>
_______________________________________

From report at bugs.python.org  Wed Apr 22 22:52:53 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Thu, 23 Apr 2020 02:52:53 +0000
Subject: [issue40369] Use PEP 590 vectorcall to speed up GenericAlias.
In-Reply-To: <1587610134.42.0.272743433509.issue40369@roundup.psfhosted.org>
Message-ID: <1587610373.35.0.365106957434.issue40369@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
assignee:  -> corona10
type:  -> performance

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40369>
_______________________________________

From report at bugs.python.org  Thu Apr 23 00:58:54 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 23 Apr 2020 04:58:54 +0000
Subject: [issue40346] Add random.BaseRandom to ease implementation of
 subclasses
In-Reply-To: <1587419589.68.0.186666450831.issue40346@roundup.psfhosted.org>
Message-ID: <1587617934.36.0.777006251776.issue40346@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

This is a breaking change.  The published API says that random() is the base method and that getrandbits() is optional.

It is not okay to flat out ignore the opposing comments from the module maintainers.  Being on the steering committee isn't a license to do whatever you want, ignoring published APIs, breaking user code, and ignoring other contributors.  If you want to go forward with this, there should be a PEP (and you should be recused from adjudicating it).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40346>
_______________________________________

From report at bugs.python.org  Thu Apr 23 01:20:33 2020
From: report at bugs.python.org (Inada Naoki)
Date: Thu, 23 Apr 2020 05:20:33 +0000
Subject: [issue37465] Incorrect documentation for `s#` arguments in C API
 argument parsing
In-Reply-To: <1561969220.64.0.698927964651.issue37465@roundup.psfhosted.org>
Message-ID: <1587619233.37.0.12644021906.issue37465@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

Fixed via GH-18663.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37465>
_______________________________________

From report at bugs.python.org  Thu Apr 23 01:29:32 2020
From: report at bugs.python.org (Inada Naoki)
Date: Thu, 23 Apr 2020 05:29:32 +0000
Subject: [issue37846] declare that Text I/O use buffer inside
In-Reply-To: <1565750649.11.0.831019575323.issue37846@roundup.psfhosted.org>
Message-ID: <1587619772.86.0.900312267174.issue37846@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

I still think it's too detailed.
Reading C and Python code is much better way to understand such implementation detail.

----------
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37846>
_______________________________________

From report at bugs.python.org  Thu Apr 23 01:39:49 2020
From: report at bugs.python.org (Inada Naoki)
Date: Thu, 23 Apr 2020 05:39:49 +0000
Subject: [issue38784] ip_network does not clear/update the broadcast_address
 cache when network_address is changed.
In-Reply-To: <1573632523.63.0.350382995031.issue38784@roundup.psfhosted.org>
Message-ID: <1587620389.56.0.647042341241.issue38784@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

I close this issue as rejected.
If you have opinion about this issue, please post to python-dev mailing list
or discuss.python.org.

----------
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38784>
_______________________________________

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: [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 02:05:52 2020
From: report at bugs.python.org (Inada Naoki)
Date: Thu, 23 Apr 2020 06:05:52 +0000
Subject: =?utf-8?q?=5Bissue37626=5D_Documentation=EF=BC=9Aconflict_between_docs?=
In-Reply-To: <1563507822.25.0.227141722177.issue37626@roundup.psfhosted.org>
Message-ID: <1587621952.07.0.449118266124.issue37626@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

I don't think they are conflict.

"now required to have a valid name."
"were allowed to have name set to None [snip]  This is no longer permitted."

"None" is not "valid name".

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37626>
_______________________________________

From report at bugs.python.org  Thu Apr 23 02:43:20 2020
From: report at bugs.python.org (Ned Deily)
Date: Thu, 23 Apr 2020 06:43:20 +0000
Subject: [issue40370] AIX: ld_so_aix not found during test of
 test_peg_generator
In-Reply-To: <1587621380.1.0.901678392936.issue40370@roundup.psfhosted.org>
Message-ID: <1587624200.91.0.351862585588.issue40370@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


----------
nosy: +pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40370>
_______________________________________

From report at bugs.python.org  Thu Apr 23 02:50:33 2020
From: report at bugs.python.org (Ned Deily)
Date: Thu, 23 Apr 2020 06:50:33 +0000
Subject: [issue40370] AIX: ld_so_aix not found during test of
 test_peg_generator
In-Reply-To: <1587621380.1.0.901678392936.issue40370@roundup.psfhosted.org>
Message-ID: <1587624633.92.0.531276530501.issue40370@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

It looks like the newly added test_peg_gemerator tries to build C code at run time as part of executing the test.  So most likely the test is not invoking distutils with the same set of options and/or environment variable values that the main Python setup.py does when building standard library C extension modules at Python build time.  Pablo?

----------
nosy: +ned.deily
priority: normal -> high

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40370>
_______________________________________

From report at bugs.python.org  Thu Apr 23 02:52:42 2020
From: report at bugs.python.org (Ned Deily)
Date: Thu, 23 Apr 2020 06:52:42 +0000
Subject: [issue40334] PEP 617: new PEG-based parser
In-Reply-To: <1587327377.33.0.614039250584.issue40334@roundup.psfhosted.org>
Message-ID: <1587624762.84.0.634392287516.issue40334@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

Issue40370 documents test_peg_generator breakage on an AIX buildbot.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40334>
_______________________________________

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: [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: [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 04:19:53 2020
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 23 Apr 2020 08:19:53 +0000
Subject: [issue40372] doctest example programs should exit 1 if any test fails
In-Reply-To: <1587629772.69.0.383881965755.issue40372@roundup.psfhosted.org>
Message-ID: <1587629993.3.0.0519931544775.issue40372@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch
nosy: +python-dev
nosy_count: 2.0 -> 3.0
pull_requests: +18997
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19673

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40372>
_______________________________________

From report at bugs.python.org  Thu Apr 23 05:16:30 2020
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 23 Apr 2020 09:16:30 +0000
Subject: [issue40346] Add random.BaseRandom to ease implementation of
 subclasses
In-Reply-To: <1587419589.68.0.186666450831.issue40346@roundup.psfhosted.org>
Message-ID: <1587633390.42.0.533546942254.issue40346@roundup.psfhosted.org>


Antoine Pitrou <solipsis at pitrou.net> added the comment:

If I believe what Victor wrote about:
"""
The implementation of random.Random, random.SystemRandom and
random.Random subclasses are not affected by this change.
"""

then I don't understand how the API is changed.  IIUC, users subclassing random.Random won't see a difference.  However, users now can subclass BaseRandom which makes it easier to obtain a full-featured random generator class.

However, if we want to think about a new subclassing API, it may be worth looking at the recent Numpy changes. Numpy added a new random generator API recently, with a design based on composition rather than inheritance (and also they switched from Mersenne Twister to another underlying PRNG!):
https://numpy.org/doc/stable/reference/random/index.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40346>
_______________________________________

From report at bugs.python.org  Thu Apr 23 05:52:07 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 23 Apr 2020 09:52:07 +0000
Subject: [issue40370] AIX: ld_so_aix not found during test of
 test_peg_generator
In-Reply-To: <1587621380.1.0.901678392936.issue40370@roundup.psfhosted.org>
Message-ID: <1587635527.25.0.445646848732.issue40370@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Ned, the analysis seems correct. We need to fix test_peg_generator so it uses the same build options as the interpreter. I am slightly surprised as I was under the assumption that distutils propagates the compiler options that were used when the interpreter was built automatically

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40370>
_______________________________________

From report at bugs.python.org  Thu Apr 23 05:53:34 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 23 Apr 2020 09:53:34 +0000
Subject: [issue40370] AIX: ld_so_aix not found during test of
 test_peg_generator
In-Reply-To: <1587621380.1.0.901678392936.issue40370@roundup.psfhosted.org>
Message-ID: <1587635614.87.0.923314378483.issue40370@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
nosy: +lys.nikolaou

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40370>
_______________________________________

From report at bugs.python.org  Thu Apr 23 06:16:07 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 23 Apr 2020 10:16:07 +0000
Subject: [issue40370] AIX: ld_so_aix not found during test of
 test_peg_generator
In-Reply-To: <1587621380.1.0.901678392936.issue40370@roundup.psfhosted.org>
Message-ID: <1587636967.03.0.427956512676.issue40370@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
keywords: +patch
pull_requests: +18998
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19674

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40370>
_______________________________________

From report at bugs.python.org  Thu Apr 23 06:22:47 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 23 Apr 2020 10:22:47 +0000
Subject: [issue40370] AIX: ld_so_aix not found during test of
 test_peg_generator
In-Reply-To: <1587621380.1.0.901678392936.issue40370@roundup.psfhosted.org>
Message-ID: <1587637367.59.0.508661763855.issue40370@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Michael, could you check if PR 19674 fixes the issue? That PR ensures that we are using the same set of flags as to when building the interpreter, which independently of this issue, is the correct thing to do.

I suspect that given the path '/home/aixtools/buildarea/3.x.aixtools-aix-power6/build/target/lib/python3.9/config-3.9d/ld_so_aix', distutils is triying to use an installed 'ld_so_aix' instead of the one in Modules/ld_so_aix.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40370>
_______________________________________

From report at bugs.python.org  Thu Apr 23 07:09:02 2020
From: report at bugs.python.org (Michael Felt)
Date: Thu, 23 Apr 2020 11:09:02 +0000
Subject: [issue40370] AIX: ld_so_aix not found during test of
 test_peg_generator
In-Reply-To: <1587621380.1.0.901678392936.issue40370@roundup.psfhosted.org>
Message-ID: <1587640142.16.0.156758420804.issue40370@roundup.psfhosted.org>


Michael Felt <aixtools at felt.demon.nl> added the comment:

New issue with test during PR19764:

0:03:29 [416/423/1] test_peg_generator failed (2 min 34 sec) -- running: test_pathlib (3 min 19 sec), test_bufio (3 min 17 sec), test_concurrent_futures (3 min 10 sec), test_multiprocessing_fork (3 min), test_subprocess (2 min 49 sec), test_multiprocessing_forkserver (3 min 18 sec), test_multiprocessing_spawn (2 min 56 sec)
[]

\u2514\u2500\u2500Rule
   \u2514\u2500\u2500Rhs
      \u2514\u2500\u2500Alt
         \u251c\u2500\u2500NamedItem
         \u2502  \u2514\u2500\u2500StringLeaf("'a'")
         \u2514\u2500\u2500NamedItem
            \u2514\u2500\u2500Opt
               \u2514\u2500\u2500Rhs
                  \u2514\u2500\u2500Alt
                     \u251c\u2500\u2500NamedItem
                     \u2502  \u2514\u2500\u2500StringLeaf("'b'")
                     \u2514\u2500\u2500NamedItem
                        \u2514\u2500\u2500Opt
                           \u2514\u2500\u2500Rhs
                              \u2514\u2500\u2500Alt
                                 \u251c\u2500\u2500NamedItem
                                 \u2502  \u2514\u2500\u2500StringLeaf("'c'")
                                 \u2514\u2500\u2500NamedItem
                                    \u2514\u2500\u2500Opt
                                       \u2514\u2500\u2500Rhs
                                          \u2514\u2500\u2500Alt
                                             \u2514\u2500\u2500NamedItem
                                                \u2514\u2500\u2500StringLeaf("'d'")

start() ... (looking at 1.0: OP:'(')
  expect('(') ... (looking at 1.0: OP:'(')
  ... expect('(') -> TokenInfo(type=54 (OP), string='(', start=(1, 0), end=(1, 1), line='(1)')
  expr() ... (looking at 1.1: NUMBER:'1')
    number() ... (looking at 1.1: NUMBER:'1')
    ... number() -> TokenInfo(type=2 (NUMBER), string='1', start=(1, 1), end=(1, 2), line='(1)')
  ... expr() -> [TokenInfo(type=2 (NUMBER), string='1', start=(1, 1), end=(1, 2), line='(1)')]
  expect(')') ... (looking at 1.2: OP:')')
  ... expect(')') -> TokenInfo(type=54 (OP), string=')', start=(1, 2), end=(1, 3), line='(1)')
... start() -> [TokenInfo(type=54 (OP), string='(', start=(1, 0), end=(1, 1), line='(1)'), [TokenInfo(type=2 (NUMBER), string='1', start=(1, 1), end=(1, 2), line='(1)')], TokenInfo(type=54 (OP), string=')', start=(1
Rule('start', None, Rhs([Alt([NamedItem(None, Gather(StringLeaf("','"), NameLeaf('thing'))), NamedItem(None, NameLeaf('NEWLINE'))])]))
/tmp/tmp9nzhxvu1/parse.c: In function 'start_rule':
/tmp/tmp9nzhxvu1/parse.c:32:35: warning: passing argument 2 of '_PyPegen_lookahead' from incompatible pointer type [-Wincompatible-pointer-types]
             _PyPegen_lookahead(1, _PyPegen_name_token, p)
                                   ^~~~~~~~~~~~~~~~~~~
In file included from /tmp/tmp9nzhxvu1/parse.c:2:0:
/home/aixtools/python/cpython-master/Parser/pegen/pegen.h:90:5: note: expected 'void * (*)(Parser *) {aka void * (*)(struct <anonymous> *)}' but argument is of type 'struct _expr * (*)(Parser *) {aka struct _expr * (*)(struct <anonymous> *)}'
 int _PyPegen_lookahead(int, void *(func)(Parser *), Parser *);
     ^~~~~~~~~~~~~~~~~~
/tmp/tmp1qne6lpy/parse.c: In function 'start_rule':
/tmp/tmp1qne6lpy/parse.c:32:35: warning: passing argument 2 of '_PyPegen_lookahead' from incompatible pointer type [-Wincompatible-pointer-types]
             _PyPegen_lookahead(0, _PyPegen_name_token, p)
                                   ^~~~~~~~~~~~~~~~~~~
In file included from /tmp/tmp1qne6lpy/parse.c:2:0:
/home/aixtools/python/cpython-master/Parser/pegen/pegen.h:90:5: note: expected 'void * (*)(Parser *) {aka void * (*)(struct <anonymous> *)}' but argument is of type 'struct _expr * (*)(Parser *) {aka struct _expr * (*)(struct <anonymous> *)}'
 int _PyPegen_lookahead(int, void *(func)(Parser *), Parser *);
     ^~~~~~~~~~~~~~~~~~
test test_peg_generator failed -- multiple errors occurred; run in verbose mode for details
0:03:47 [417/423/1] test_pathlib passed (3 min 36 sec) -- running: test_bufio (3 min 35 sec), test_concurrent_futures (3 min 27 sec), test_multiprocessing_fork (3 min 18 sec), test_subprocess (3 min 6 sec), test_multiprocessing_forkserver (3 min 35 sec), test_multiprocessing_spawn (3 min 14 sec)
0:03:51 [418/423/1] test_multiprocessing_fork passed (3 min 21 sec) -- running: test_bufio (3 min 39 sec), test_concurrent_futures (3 min 32 sec), test_subprocess (3 min 11 sec), test_multiprocessing_forkserver (3 min 40 sec), test_multiprocessing_spawn (3 min 18 sec)
/home/aixtools/python/cpython-master/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 '
/home/aixtools/python/cpython-master/Lib/multiprocessing/resource_tracker.py:229: UserWarning: resource_tracker: '/psm_35e4dd20': [Errno 2] No such file or directory: '/psm_35e4dd20'
  warnings.warn('resource_tracker: %r: %s' % (name, e))
0:04:00 [419/423/1] test_bufio passed (3 min 47 sec) -- running: test_concurrent_futures (3 min 41 sec), test_subprocess (3 min 20 sec), test_multiprocessing_forkserver (3 min 49 sec), test_multiprocessing_spawn (3 min 27 sec)
0:04:03 [420/423/1] test_subprocess passed (3 min 21 sec) -- running: test_concurrent_futures (3 min 43 sec), test_multiprocessing_forkserver (3 min 51 sec), test_multiprocessing_spawn (3 min 29 sec)

This is with gcc as compiler. Shall repeat with xlc and only update if different.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40370>
_______________________________________

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: [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 07:27:54 2020
From: report at bugs.python.org (Michael Felt)
Date: Thu, 23 Apr 2020 11:27:54 +0000
Subject: [issue40370] AIX: ld_so_aix not found during test of
 test_peg_generator
In-Reply-To: <1587621380.1.0.901678392936.issue40370@roundup.psfhosted.org>
Message-ID: <1587641274.59.0.879062857233.issue40370@roundup.psfhosted.org>


Michael Felt <aixtools at felt.demon.nl> added the comment:

Currently build using xlc-v13 hangs during creation of _json.so. Trying xlc-v11.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40370>
_______________________________________

From report at bugs.python.org  Thu Apr 23 07:39:10 2020
From: report at bugs.python.org (Michael Felt)
Date: Thu, 23 Apr 2020 11:39:10 +0000
Subject: [issue40370] AIX: ld_so_aix not found during test of
 test_peg_generator
In-Reply-To: <1587621380.1.0.901678392936.issue40370@roundup.psfhosted.org>
Message-ID: <1587641950.73.0.78845409941.issue40370@roundup.psfhosted.org>


Michael Felt <aixtools at felt.demon.nl> added the comment:

with the xlc-v11 environment yet another issue:

Stop.
/usr/bin/make returned an error
root at x065:[/data/prj/python/python-3.9]make V=1
        xlc_r -c   -O -I/opt/include -O2 -qmaxmem=-1 -qarch=pwr5 -O    -I../git/python-3.9/Include/internal -IObjects -IInclude -IPython -I. -I../git/python-3.9/Include -I/opt/include   -DPy_BUILD_CORE -o Modules/_math.o ../git/python-3.9/Modules/_math.c
 CC='xlc_r' LDSHARED='Modules/ld_so_aix xlc_r -bI:Modules/python.exp    ' OPT='-O'  _TCLTK_INCLUDES='' _TCLTK_LIBS=''  ./python -E ../git/python-3.9/setup.py  build
make: 1254-059 The signal code from the last command is 11.

** All I can test using PR19674 ** Hope it helps.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40370>
_______________________________________

From report at bugs.python.org  Thu Apr 23 07:40:18 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 23 Apr 2020 11:40:18 +0000
Subject: [issue40370] AIX: ld_so_aix not found during test of
 test_peg_generator
In-Reply-To: <1587621380.1.0.901678392936.issue40370@roundup.psfhosted.org>
Message-ID: <1587642018.65.0.328962570791.issue40370@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

I think the problem here is that distutils in AIX needs the ld_so_aix file installed and is not able to use the one in Modules from the source directory. This happens because sysconfig has "config-3.9d/ld_so_aix", which does not exist until python is installed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40370>
_______________________________________

From report at bugs.python.org  Thu Apr 23 07:41:29 2020
From: report at bugs.python.org (=?utf-8?q?Alex_Gr=C3=B6nholm?=)
Date: Thu, 23 Apr 2020 11:41:29 +0000
Subject: [issue39148] DatagramProtocol + IPv6 does not work with
 ProactorEventLoop
In-Reply-To: <1577530511.62.0.532247879973.issue39148@roundup.psfhosted.org>
Message-ID: <1587642089.08.0.382078214279.issue39148@roundup.psfhosted.org>


Alex Gr?nholm <alex.gronholm at nextday.fi> added the comment:

Which PR is it?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39148>
_______________________________________

From report at bugs.python.org  Thu Apr 23 07:42:17 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 23 Apr 2020 11:42:17 +0000
Subject: [issue40334] PEP 617: new PEG-based parser
In-Reply-To: <1587327377.33.0.614039250584.issue40334@roundup.psfhosted.org>
Message-ID: <1587642137.18.0.00713478005035.issue40334@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset 1df5a9e88c8df1495a2e689d71b34bf0c7d008ea by Pablo Galindo in branch 'master':
bpo-40334: Fix build errors and warnings in test_peg_generator (GH-19672)
https://github.com/python/cpython/commit/1df5a9e88c8df1495a2e689d71b34bf0c7d008ea


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40334>
_______________________________________

From report at bugs.python.org  Thu Apr 23 07:45:21 2020
From: report at bugs.python.org (=?utf-8?q?Alex_Gr=C3=B6nholm?=)
Date: Thu, 23 Apr 2020 11:45:21 +0000
Subject: [issue39148] DatagramProtocol + IPv6 does not work with
 ProactorEventLoop
In-Reply-To: <1577530511.62.0.532247879973.issue39148@roundup.psfhosted.org>
Message-ID: <1587642321.68.0.795192334643.issue39148@roundup.psfhosted.org>


Alex Gr?nholm <alex.gronholm at nextday.fi> added the comment:

Oh, it's https://github.com/python/cpython/pull/19121. I think it would be prudent to add a test as well to make sure this doesn't happen again.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39148>
_______________________________________

From report at bugs.python.org  Thu Apr 23 07:46:04 2020
From: report at bugs.python.org (Lysandros Nikolaou)
Date: Thu, 23 Apr 2020 11:46:04 +0000
Subject: [issue40370] AIX: ld_so_aix not found during test of
 test_peg_generator
In-Reply-To: <1587621380.1.0.901678392936.issue40370@roundup.psfhosted.org>
Message-ID: <1587642364.71.0.0318444912053.issue40370@roundup.psfhosted.org>


Lysandros Nikolaou <lisandrosnik at gmail.com> added the comment:

I propose skipping test_peg_generator for now, so that we don't hold the alpha6 release. It actually only tests the generator and not the parser and since we don't plan on adding new operators in the very near future, we can skip it and fix it after the release.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40370>
_______________________________________

From report at bugs.python.org  Thu Apr 23 07:50:14 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 23 Apr 2020 11:50:14 +0000
Subject: [issue40370] AIX: ld_so_aix not found during test of
 test_peg_generator
In-Reply-To: <1587621380.1.0.901678392936.issue40370@roundup.psfhosted.org>
Message-ID: <1587642614.57.0.607928473019.issue40370@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Interestingly, test_distutils has the same problem, but basically skips the test:

test_build_ext (distutils.tests.test_build_ext.BuildExtTestCase) ... skipped "The '/usr/local/lib/python3.9/config-3.9d/ld_so_aix' command is not found"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40370>
_______________________________________

From report at bugs.python.org  Thu Apr 23 07:50:57 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 23 Apr 2020 11:50:57 +0000
Subject: [issue40370] AIX: ld_so_aix not found during test of
 test_peg_generator
In-Reply-To: <1587621380.1.0.901678392936.issue40370@roundup.psfhosted.org>
Message-ID: <1587642657.4.0.143269194676.issue40370@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

> so that we don't hold the alpha6 release.

AIX is not a STABLE buildbot so I cannot hold the release

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40370>
_______________________________________

From report at bugs.python.org  Thu Apr 23 07:52:22 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 23 Apr 2020 11:52:22 +0000
Subject: [issue40370] AIX: ld_so_aix not found during test of
 test_peg_generator
In-Reply-To: <1587621380.1.0.901678392936.issue40370@roundup.psfhosted.org>
Message-ID: <1587642742.68.0.674439677869.issue40370@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

We need to do the same thing as test_build_ext does:

https://github.com/python/cpython/blob/master/Lib/distutils/tests/test_build_ext.py#L56-L58

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40370>
_______________________________________

From report at bugs.python.org  Thu Apr 23 08:00:37 2020
From: report at bugs.python.org (Lysandros Nikolaou)
Date: Thu, 23 Apr 2020 12:00:37 +0000
Subject: [issue40334] PEP 617: new PEG-based parser
In-Reply-To: <1587327377.33.0.614039250584.issue40334@roundup.psfhosted.org>
Message-ID: <1587643237.2.0.666565324315.issue40334@roundup.psfhosted.org>


Change by Lysandros Nikolaou <lisandrosnik at gmail.com>:


----------
pull_requests: +18999
pull_request: https://github.com/python/cpython/pull/19675

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40334>
_______________________________________

From report at bugs.python.org  Thu Apr 23 08:12:27 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 23 Apr 2020 12:12:27 +0000
Subject: [issue40369] Use PEP 590 vectorcall to speed up GenericAlias.
In-Reply-To: <1587610134.42.0.272743433509.issue40369@roundup.psfhosted.org>
Message-ID: <1587643947.41.0.0263090210556.issue40369@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> if the suggestion is accepted, I 'd like to summit the patch :)

Can you propose a PR, so I can have a look at the implementation?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40369>
_______________________________________

From report at bugs.python.org  Thu Apr 23 08:19:48 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Thu, 23 Apr 2020 12:19:48 +0000
Subject: [issue40369] Use PEP 590 vectorcall to speed up GenericAlias.
In-Reply-To: <1587610134.42.0.272743433509.issue40369@roundup.psfhosted.org>
Message-ID: <1587644388.13.0.273661277301.issue40369@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

> Can you propose a PR, so I can have a look at the implementation?

Got it :), I will upload it soon.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40369>
_______________________________________

From report at bugs.python.org  Thu Apr 23 08:22:35 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 23 Apr 2020 12:22:35 +0000
Subject: [issue40334] PEP 617: new PEG-based parser
In-Reply-To: <1587327377.33.0.614039250584.issue40334@roundup.psfhosted.org>
Message-ID: <1587644555.55.0.423695252617.issue40334@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset 8d1cbfffea7a5dbf7a3c60b066a2c2120ef08cd0 by Lysandros Nikolaou in branch 'master':
bpo-40334: Suppress all output in test_peg_generator (GH-19675)
https://github.com/python/cpython/commit/8d1cbfffea7a5dbf7a3c60b066a2c2120ef08cd0


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40334>
_______________________________________

From report at bugs.python.org  Thu Apr 23 08:28:10 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 23 Apr 2020 12:28:10 +0000
Subject: [issue40369] Use PEP 590 vectorcall to speed up GenericAlias.
In-Reply-To: <1587610134.42.0.272743433509.issue40369@roundup.psfhosted.org>
Message-ID: <1587644890.76.0.0441342592863.issue40369@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I have doubts that GenericAlias instances are created in mass in tight loops. Do you have any realistic example which would benefit from speeding up creation of GenericAlias instances?

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40369>
_______________________________________

From report at bugs.python.org  Thu Apr 23 08:54:23 2020
From: report at bugs.python.org (Nathaniel Manista)
Date: Thu, 23 Apr 2020 12:54:23 +0000
Subject: [issue17519] unittest should not try to run abstract classes
In-Reply-To: <1363951466.19.0.505441528041.issue17519@psf.upfronthosting.co.za>
Message-ID: <1587646463.21.0.524045315607.issue17519@roundup.psfhosted.org>


Change by Nathaniel Manista <nathaniel at google.com>:


----------
nosy: +Nathaniel Manista

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17519>
_______________________________________

From report at bugs.python.org  Thu Apr 23 08:56:43 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Thu, 23 Apr 2020 12:56:43 +0000
Subject: [issue40369] Use PEP 590 vectorcall to speed up GenericAlias.
In-Reply-To: <1587610134.42.0.272743433509.issue40369@roundup.psfhosted.org>
Message-ID: <1587646603.77.0.196632544593.issue40369@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
keywords: +patch
pull_requests: +19000
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19677

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40369>
_______________________________________

From report at bugs.python.org  Thu Apr 23 09:01:40 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Thu, 23 Apr 2020 13:01:40 +0000
Subject: [issue40369] Use PEP 590 vectorcall to speed up GenericAlias.
In-Reply-To: <1587610134.42.0.272743433509.issue40369@roundup.psfhosted.org>
Message-ID: <1587646900.27.0.847071924511.issue40369@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

> Do you have any realistic example which would benefit from speeding up the creation of GenericAlias instances?

Hmm I did not find loop tightly calling case, but
for example, this kinds of usage are very often.

def create_q(l: list[int]) -> Queue[int]:
    q = Queue[int]()
    for e in l:
        q.put(e)
    return q

a = create_q([1,2,3,4,5])

In this code, GenericAlias is called 2 times for function declare and function call.

It's true that GenericAlias ??has a small portion in this scenario,
but wouldn't it be worth it if we could optimize itself to a few lines of code?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40369>
_______________________________________

From report at bugs.python.org  Thu Apr 23 09:14:57 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 23 Apr 2020 13:14:57 +0000
Subject: [issue40369] Use PEP 590 vectorcall to speed up GenericAlias.
In-Reply-To: <1587610134.42.0.272743433509.issue40369@roundup.psfhosted.org>
Message-ID: <1587647697.87.0.0551560440615.issue40369@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

And how much faster has your example become?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40369>
_______________________________________

From report at bugs.python.org  Thu Apr 23 09:31:35 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Thu, 23 Apr 2020 13:31:35 +0000
Subject: [issue40369] Use PEP 590 vectorcall to speed up GenericAlias.
In-Reply-To: <1587610134.42.0.272743433509.issue40369@roundup.psfhosted.org>
Message-ID: <1587648695.86.0.862309609154.issue40369@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

> And how much faster has your example become?

For function declaration, 5% enhancement,
the function call does not show difference because the GenericAlias is not big portion on calling.

+--------------------+------------------------+----------------------------+
| Benchmark          | master-generic-alias-1 | bpo-40369-generic-alias-1  |
+====================+========================+============================+
| bench GenericAlias | 420 ns                 | 399 ns: 1.05x faster (-5%) |
+--------------------+------------------------+----------------------------+

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40369>
_______________________________________

From report at bugs.python.org  Thu Apr 23 09:46:54 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 23 Apr 2020 13:46:54 +0000
Subject: [issue40370] AIX: ld_so_aix not found during test of
 test_peg_generator
In-Reply-To: <1587621380.1.0.901678392936.issue40370@roundup.psfhosted.org>
Message-ID: <1587649614.45.0.0240459086195.issue40370@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Michael, can you check if AIX is happy with the current master? :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40370>
_______________________________________

From report at bugs.python.org  Thu Apr 23 09:53:31 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 23 Apr 2020 13:53:31 +0000
Subject: [issue40370] AIX: ld_so_aix not found during test of
 test_peg_generator
In-Reply-To: <1587621380.1.0.901678392936.issue40370@roundup.psfhosted.org>
Message-ID: <1587650011.37.0.669349699741.issue40370@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset 9e6a1312c1cd04ab37cddd8f3bb9baa7e9a38bc0 by Pablo Galindo in branch 'master':
bpo-40370: Use the same compile and link args as the interpreter used in test_peg_generator (GH-19674)
https://github.com/python/cpython/commit/9e6a1312c1cd04ab37cddd8f3bb9baa7e9a38bc0


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40370>
_______________________________________

From report at bugs.python.org  Thu Apr 23 10:05:48 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 23 Apr 2020 14:05:48 +0000
Subject: [issue40334] PEP 617: new PEG-based parser
In-Reply-To: <1587327377.33.0.614039250584.issue40334@roundup.psfhosted.org>
Message-ID: <1587650748.2.0.521670341792.issue40334@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

GCC warning on aarch64 Fedora Rawhide LTO + PGO 3.x buildbot:
https://buildbot.python.org/all/#/builders/612/builds/286

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;
      |         ~~~~~~~~~~^~~

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40334>
_______________________________________

From report at bugs.python.org  Thu Apr 23 10:10:50 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 23 Apr 2020 14:10:50 +0000
Subject: [issue40334] PEP 617: new PEG-based parser
In-Reply-To: <1587327377.33.0.614039250584.issue40334@roundup.psfhosted.org>
Message-ID: <1587651050.11.0.343649682764.issue40334@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

> GCC warning on aarch64 Fedora Rawhide LTO + PGO 3.x buildbot:

Is this related to this issue? We didn't change that line

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40334>
_______________________________________

From report at bugs.python.org  Thu Apr 23 10:17:18 2020
From: report at bugs.python.org (Charalampos Stratakis)
Date: Thu, 23 Apr 2020 14:17:18 +0000
Subject: [issue40334] PEP 617: new PEG-based parser
In-Reply-To: <1587327377.33.0.614039250584.issue40334@roundup.psfhosted.org>
Message-ID: <1587651438.05.0.0648639341961.issue40334@roundup.psfhosted.org>


Charalampos Stratakis <cstratak at redhat.com> added the comment:

> Is this related to this issue? We didn't change that line

I can provide you access to the buildbot if you'd like to debug the issue.

----------
nosy: +cstratak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40334>
_______________________________________

From report at bugs.python.org  Thu Apr 23 10:28:55 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 23 Apr 2020 14:28:55 +0000
Subject: [issue40334] PEP 617: new PEG-based parser
In-Reply-To: <1587327377.33.0.614039250584.issue40334@roundup.psfhosted.org>
Message-ID: <1587652135.24.0.659073297862.issue40334@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> Is this related to this issue? We didn't change that line

I don't know. It's just that I spotted this compiler warnining while reviewing recent buildbot failures.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40334>
_______________________________________

From report at bugs.python.org  Thu Apr 23 10:30:46 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 23 Apr 2020 14:30:46 +0000
Subject: [issue40370] AIX: ld_so_aix not found during test of
 test_peg_generator
In-Reply-To: <1587621380.1.0.901678392936.issue40370@roundup.psfhosted.org>
Message-ID: <1587652246.66.0.023668150535.issue40370@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Tested on an AIX system:

[pablo at ibm_machine cpython (master)]$ uname -a
AIX ibm_machine 1 7 ******* powerpc ******** AIX
[pablo at ibm1 cpython (master)]$ ./python -m test test_peg_generator
0:00:00 Run tests sequentially
0:00:00 [1/1] test_peg_generator

== Tests result: SUCCESS ==

1 test OK.

Total duration: 5.0 sec
Tests result: SUCCESS

I will mark this issue as fixed as It was failing before on this machine and now the test suceeds. Feel free to reopen if is not fixes in your system :)

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40370>
_______________________________________

From report at bugs.python.org  Thu Apr 23 10:33:02 2020
From: report at bugs.python.org (R. David Murray)
Date: Thu, 23 Apr 2020 14:33:02 +0000
Subject: [issue40359] email.parse part.get_filename() fails to unwrap long
 attachment file names (legacy API)
In-Reply-To: <1587515187.44.0.744042033479.issue40359@roundup.psfhosted.org>
Message-ID: <1587652382.08.0.671940827619.issue40359@roundup.psfhosted.org>


R. David Murray <rdmurray at bitdance.com> added the comment:

Yeah, that looks like a bug in the old API.  If you try the new API, it does the right thing.  To do that, import email.policy and make your message_as_string call:

  email.message_from_string(raw, policy=email.policy.default)

Note, however, that you really ought to be using message_from_bytes.  Serialized email messages are bytes, not unicode, and using message_from_string will get you in to other trouble.

I don't know if it is worth fixing the old API.

----------
title: email.parse part.get_filename() fails to unwrap long attachment file names -> email.parse part.get_filename() fails to unwrap long attachment file names (legacy API)

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40359>
_______________________________________

From report at bugs.python.org  Thu Apr 23 10:37:56 2020
From: report at bugs.python.org (Kagami Sascha Rosylight)
Date: Thu, 23 Apr 2020 14:37:56 +0000
Subject: [issue40368] os.path.realpath uppercases Windows drive letter on
 Python 3.8
In-Reply-To: <1587590743.67.0.821024621015.issue40368@roundup.psfhosted.org>
Message-ID: <1587652676.64.0.325705256585.issue40368@roundup.psfhosted.org>


Kagami Sascha Rosylight <saschanaz at outlook.com> added the comment:

I mentioned `os.path.abspath` because `os.path.abspath(".")` on console returned `'c:\\Users\\Kagami\\Documents\\GitHub\\gecko-dev'`. It seems this incompatibility is partially because MSYS shell prefers lowercase letter for Windows path while Windows prefers otherwise.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40368>
_______________________________________

From report at bugs.python.org  Thu Apr 23 10:54:00 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 23 Apr 2020 14:54:00 +0000
Subject: [issue40217] The garbage collector doesn't take in account that
 objects of heap allocated types hold a strong reference to their type
In-Reply-To: <1586276621.78.0.843757244355.issue40217@roundup.psfhosted.org>
Message-ID: <1587653640.57.0.354977914257.issue40217@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I'm not comfortable with requesting authors of all C extensions to modify their tp_traverse function. As Pablo explained, the type is already visited on subtypes instances. I approved PR 19414.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40217>
_______________________________________

From report at bugs.python.org  Thu Apr 23 10:56:00 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 23 Apr 2020 14:56:00 +0000
Subject: [issue40217] The garbage collector doesn't take in account that
 objects of heap allocated types hold a strong reference to their type
In-Reply-To: <1586276621.78.0.843757244355.issue40217@roundup.psfhosted.org>
Message-ID: <1587653760.46.0.638568298529.issue40217@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Tests should be added, maybe based on msg365963 examples. But I would prefer to get this bug fixed in 3.9.0a6 (if possible), tests can be added later.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40217>
_______________________________________

From report at bugs.python.org  Thu Apr 23 11:17:09 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 23 Apr 2020 15:17:09 +0000
Subject: [issue40334] PEP 617: new PEG-based parser
In-Reply-To: <1587327377.33.0.614039250584.issue40334@roundup.psfhosted.org>
Message-ID: <1587655029.53.0.429004117003.issue40334@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

> I don't know. It's just that I spotted this compiler warnining while reviewing recent buildbot failures.

Given that is a compiler warning and we didn't change those lines, I would say is not related to this PR :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40334>
_______________________________________

From report at bugs.python.org  Thu Apr 23 11:18:03 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 23 Apr 2020 15:18:03 +0000
Subject: [issue40217] The garbage collector doesn't take in account that
 objects of heap allocated types hold a strong reference to their type
In-Reply-To: <1586276621.78.0.843757244355.issue40217@roundup.psfhosted.org>
Message-ID: <1587655083.64.0.692676356378.issue40217@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I do not think it is right. Please wait, I'll submit an alternate solution.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40217>
_______________________________________

From report at bugs.python.org  Thu Apr 23 11:19:45 2020
From: report at bugs.python.org (Kagami Sascha Rosylight)
Date: Thu, 23 Apr 2020 15:19:45 +0000
Subject: [issue40368] os.path.realpath uppercases Windows drive letter on
 Python 3.8
In-Reply-To: <1587590743.67.0.821024621015.issue40368@roundup.psfhosted.org>
Message-ID: <1587655185.57.0.125515363568.issue40368@roundup.psfhosted.org>


Kagami Sascha Rosylight <saschanaz at outlook.com> added the comment:

Should `ntpath.normpath` make the drive letter uppercase?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40368>
_______________________________________

From report at bugs.python.org  Thu Apr 23 11:33:56 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 23 Apr 2020 15:33:56 +0000
Subject: [issue40217] The garbage collector doesn't take in account that
 objects of heap allocated types hold a strong reference to their type
In-Reply-To: <1586276621.78.0.843757244355.issue40217@roundup.psfhosted.org>
Message-ID: <1587656036.28.0.696815408582.issue40217@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

There are limited options to fix this issue:

(A) Revert commit 364f0b0f19cc3f0d5e63f571ec9163cf41c62958

It would reintroduced bpo-35810 bug. Moreover, C extension modules which have been modified to call Py_DECREF(Py_TYPE(self)) in tp_dealloc which suddenly crash.

I don't think that anyone wants this option.


(B) Require all C extension modules authors to modify their tp_traverse function.

It requires to communicate well that all C extension modules which use PyType_FromSpec() need to modify their tp_traverse method to add code specific to Python 3.8 or newer.

Serhiy and me are against this option.


(C) Modify gcmodule.c to traverse the type.

This option is not trivial since *subtype* are already traversed. Moreover, Pablo and Tim are strongly against this option.


(D) Modify PyType_FromSpec() to hook into tp_traverse and transparently visit the type, as already done for subtypes.

Option chosen by PR 19414.

Honestly, I'm unhappy that we have to hook into tp_traverse, but this option sounds like the least bad option to me.

Developers don't have to modify their C extensions code, the bug is fixed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40217>
_______________________________________

From report at bugs.python.org  Thu Apr 23 11:35:15 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 23 Apr 2020 15:35:15 +0000
Subject: [issue40217] The garbage collector doesn't take in account that
 objects of heap allocated types hold a strong reference to their type
In-Reply-To: <1586276621.78.0.843757244355.issue40217@roundup.psfhosted.org>
Message-ID: <1587656115.91.0.841433806456.issue40217@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> I do not think it is right. Please wait, I'll submit an alternate solution.

What is your idea? How would it be different than PR 19414? Refleak buildbots are broken for almost one month (bpo-40149), it would be nice to get a fix soon. In Python 3.9.0a6 if possible.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40217>
_______________________________________

From report at bugs.python.org  Thu Apr 23 11:36:14 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 23 Apr 2020 15:36:14 +0000
Subject: [issue40334] PEP 617: new PEG-based parser
In-Reply-To: <1587327377.33.0.614039250584.issue40334@roundup.psfhosted.org>
Message-ID: <1587656174.75.0.425628897346.issue40334@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset ebebb6429c224c713e1c63a0b05d4840f52c7415 by Lysandros Nikolaou in branch 'master':
bpo-40334: Improve various PEG-Parser related stuff (GH-19669)
https://github.com/python/cpython/commit/ebebb6429c224c713e1c63a0b05d4840f52c7415


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40334>
_______________________________________

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: [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 12:04:12 2020
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 23 Apr 2020 16:04:12 +0000
Subject: [issue26317] Build Problem with GCC + Macintosh OS X 10.11 El Capitain
In-Reply-To: <1454992584.65.0.198275659625.issue26317@psf.upfronthosting.co.za>
Message-ID: <1587657852.75.0.254316961905.issue26317@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
nosy: +python-dev
nosy_count: 6.0 -> 7.0
pull_requests: +19002
pull_request: https://github.com/python/cpython/pull/19681

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26317>
_______________________________________

From report at bugs.python.org  Thu Apr 23 12:08:50 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Thu, 23 Apr 2020 16:08:50 +0000
Subject: [issue40369] Use PEP 590 vectorcall to speed up GenericAlias.
In-Reply-To: <1587610134.42.0.272743433509.issue40369@roundup.psfhosted.org>
Message-ID: <1587658130.97.0.264502104119.issue40369@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

Just for the record,

https://github.com/python/cpython/pull/19677#discussion_r413894982

guido left an opinion that the caching approach might be more proper.
So I 'd like to suggest open a new issue for caching. :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40369>
_______________________________________

From report at bugs.python.org  Thu Apr 23 12:10:34 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 23 Apr 2020 16:10:34 +0000
Subject: [issue39983] test.regrtest: test marked as failed (env changed),
 but no warning: test_multiprocessing_forkserver
In-Reply-To: <1584397271.26.0.591205335177.issue39983@roundup.psfhosted.org>
Message-ID: <1587658234.69.0.102151417247.issue39983@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
keywords: +patch
pull_requests: +19003
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19683

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39983>
_______________________________________

From report at bugs.python.org  Thu Apr 23 12:10:52 2020
From: report at bugs.python.org (=?utf-8?q?Fran=C3=A7ois_Freitag?=)
Date: Thu, 23 Apr 2020 16:10:52 +0000
Subject: [issue39385] Add an assertNoLogs context manager to unittest TestCase
In-Reply-To: <1579379123.37.0.908861475494.issue39385@roundup.psfhosted.org>
Message-ID: <1587658252.19.0.937003809956.issue39385@roundup.psfhosted.org>


Change by Fran?ois Freitag <mail+python at franek.fr>:


----------
nosy: +francois.freitag

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39385>
_______________________________________

From report at bugs.python.org  Thu Apr 23 12:27:29 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Thu, 23 Apr 2020 16:27:29 +0000
Subject: [issue40369] Use PEP 590 vectorcall to speed up GenericAlias.
In-Reply-To: <1587610134.42.0.272743433509.issue40369@roundup.psfhosted.org>
Message-ID: <1587659249.49.0.940734825405.issue40369@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
resolution:  -> rejected
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40369>
_______________________________________

From report at bugs.python.org  Thu Apr 23 07:11:36 2020
From: report at bugs.python.org (Michael Felt)
Date: Thu, 23 Apr 2020 11:11:36 +0000
Subject: [issue40370] AIX: ld_so_aix not found during test of
 test_peg_generator
In-Reply-To: <1587621380.1.0.901678392936.issue40370@roundup.psfhosted.org>
Message-ID: <1587640296.71.0.444419722953.issue40370@roundup.psfhosted.org>


Michael Felt <aixtools at felt.demon.nl> added the comment:

More `make test` output:

1 test failed:
    test_peg_generator

18 tests skipped:
    test_devpoll test_epoll test_gdb test_ioctl test_kqueue
    test_msilib test_ossaudiodev test_spwd test_startfile test_tix
    test_tk test_ttk_guionly test_unicode_file
    test_unicode_file_functions test_winconsoleio test_winreg
    test_winsound test_zipfile64
0:05:24
0:05:24 Re-running failed tests in verbose mode
0:05:24 Re-running test_peg_generator in verbose mode
test_advanced_left_recursive (test.test_peg_generator.test_c_parser.TestCParser) ... ERROR
test_c_parser (test.test_peg_generator.test_c_parser.TestCParser) ... ERROR
test_cut (test.test_peg_generator.test_c_parser.TestCParser) ... ERROR
test_error_in_rules (test.test_peg_generator.test_c_parser.TestCParser) ... ERROR
test_gather (test.test_peg_generator.test_c_parser.TestCParser) ... ERROR
test_gather_action_ast (test.test_peg_generator.test_c_parser.TestCParser) ... ERROR
test_headers_and_trailer (test.test_peg_generator.test_c_parser.TestCParser) ... ok
test_if_stmt_action (test.test_peg_generator.test_c_parser.TestCParser) ... ERROR
test_left_recursion (test.test_peg_generator.test_c_parser.TestCParser) ... ERROR
test_lookahead (test.test_peg_generator.test_c_parser.TestCParser) ... /tmp/tmpte0se473/parse.c: In function 'start_rule':
/tmp/tmpte0se473/parse.c:32:35: warning: passing argument 2 of '_PyPegen_lookahead' from incompatible pointer type [-Wincompatible-pointer-types]
             _PyPegen_lookahead(1, _PyPegen_name_token, p)
                                   ^~~~~~~~~~~~~~~~~~~
In file included from /tmp/tmpte0se473/parse.c:2:0:
/home/aixtools/python/cpython-master/Parser/pegen/pegen.h:90:5: note: expected 'void * (*)(Parser *) {aka void * (*)(struct <anonymous> *)}' but argument is of type 'struct _expr * (*)(Parser *) {aka struct _expr * (*)(struct <anonymous> *)}'
 int _PyPegen_lookahead(int, void *(func)(Parser *), Parser *);
     ^~~~~~~~~~~~~~~~~~
ERROR
test_mutually_left_recursive (test.test_peg_generator.test_c_parser.TestCParser) ... ERROR
test_nasty_mutually_left_recursive (test.test_peg_generator.test_c_parser.TestCParser) ... ERROR
test_negative_lookahead (test.test_peg_generator.test_c_parser.TestCParser) ... /tmp/tmpyyc57e2e/parse.c: In function 'start_rule':
/tmp/tmpyyc57e2e/parse.c:32:35: warning: passing argument 2 of '_PyPegen_lookahead' from incompatible pointer type [-Wincompatible-pointer-types]
             _PyPegen_lookahead(0, _PyPegen_name_token, p)
                                   ^~~~~~~~~~~~~~~~~~~
In file included from /tmp/tmpyyc57e2e/parse.c:2:0:
/home/aixtools/python/cpython-master/Parser/pegen/pegen.h:90:5: note: expected 'void * (*)(Parser *) {aka void * (*)(struct <anonymous> *)}' but argument is of type 'struct _expr * (*)(Parser *) {aka struct _expr * (*)(struct <anonymous> *)}'
 int _PyPegen_lookahead(int, void *(func)(Parser *), Parser *);
     ^~~~~~~~~~~~~~~~~~
ERROR
test_pass_stmt_action (test.test_peg_generator.test_c_parser.TestCParser) ... ERROR
test_return_stmt_noexpr_action (test.test_peg_generator.test_c_parser.TestCParser) ... ERROR
test_same_name_different_types (test.test_peg_generator.test_c_parser.TestCParser) ... ERROR
test_syntax_error_for_string (test.test_peg_generator.test_c_parser.TestCParser) ... []
ERROR
test_ternary_operator (test.test_peg_generator.test_c_parser.TestCParser) ... ERROR
test_with_stmt_with_paren (test.test_peg_generator.test_c_parser.TestCParser) ... ERROR
test_advance_left_recursion (test.test_peg_generator.test_first_sets.TestFirstSets) ... ok
test_alternatives (test.test_peg_generator.test_first_sets.TestFirstSets) ... ok
test_epsilon_production_in_start_rule (test.test_peg_generator.test_first_sets.TestFirstSets) ... ok
test_gather (test.test_peg_generator.test_first_sets.TestFirstSets) ... ok
test_left_recursion (test.test_peg_generator.test_first_sets.TestFirstSets) ... ok
test_multiple_nullable_rules (test.test_peg_generator.test_first_sets.TestFirstSets) ... ok
test_mutual_left_recursion (test.test_peg_generator.test_first_sets.TestFirstSets) ... ok
test_nasty_left_recursion (test.test_peg_generator.test_first_sets.TestFirstSets) ... ok
test_negative_lookahead (test.test_peg_generator.test_first_sets.TestFirstSets) ... ok
test_nullable_rule (test.test_peg_generator.test_first_sets.TestFirstSets) ... ok
test_optional_after (test.test_peg_generator.test_first_sets.TestFirstSets) ... ok
test_optional_before (test.test_peg_generator.test_first_sets.TestFirstSets) ... ok
test_optional_literal (test.test_peg_generator.test_first_sets.TestFirstSets) ... ok
test_optional_operator (test.test_peg_generator.test_first_sets.TestFirstSets) ... ok
test_optionals (test.test_peg_generator.test_first_sets.TestFirstSets) ... ok
test_positive_lookahead (test.test_peg_generator.test_first_sets.TestFirstSets) ... ok
test_repeat_0 (test.test_peg_generator.test_first_sets.TestFirstSets) ... ok
test_repeat_0_with_group (test.test_peg_generator.test_first_sets.TestFirstSets) ... ok
test_repeat_1 (test.test_peg_generator.test_first_sets.TestFirstSets) ... ok
test_repeat_1_with_group (test.test_peg_generator.test_first_sets.TestFirstSets) ... ok
test_repeat_with_separator (test.test_peg_generator.test_first_sets.TestFirstSets) ... ok
test_deep_nested_rule (test.test_peg_generator.test_pegen.TestGrammarVisualizer) ...
\u2514\u2500\u2500Rule
   \u2514\u2500\u2500Rhs
      \u2514\u2500\u2500Alt
         \u251c\u2500\u2500NamedItem
         \u2502  \u2514\u2500\u2500StringLeaf("'a'")
         \u2514\u2500\u2500NamedItem
            \u2514\u2500\u2500Opt
               \u2514\u2500\u2500Rhs
                  \u2514\u2500\u2500Alt
                     \u251c\u2500\u2500NamedItem
                     \u2502  \u2514\u2500\u2500StringLeaf("'b'")
                     \u2514\u2500\u2500NamedItem
                        \u2514\u2500\u2500Opt
                           \u2514\u2500\u2500Rhs
                              \u2514\u2500\u2500Alt
                                 \u251c\u2500\u2500NamedItem
                                 \u2502  \u2514\u2500\u2500StringLeaf("'c'")
                                 \u2514\u2500\u2500NamedItem
                                    \u2514\u2500\u2500Opt
                                       \u2514\u2500\u2500Rhs
                                          \u2514\u2500\u2500Alt
                                             \u2514\u2500\u2500NamedItem
                                                \u2514\u2500\u2500StringLeaf("'d'")

ok
test_multiple_rules (test.test_peg_generator.test_pegen.TestGrammarVisualizer) ... ok
test_simple_rule (test.test_peg_generator.test_pegen.TestGrammarVisualizer) ... ok
test_advanced_left_recursive (test.test_peg_generator.test_pegen.TestPegen) ... ok
test_alt_optional_operator (test.test_peg_generator.test_pegen.TestPegen) ... ok
test_bad_token_reference (test.test_peg_generator.test_pegen.TestPegen) ... ok
test_cut (test.test_peg_generator.test_pegen.TestPegen) ... start() ... (looking at 1.0: OP:'(')
  expect('(') ... (looking at 1.0: OP:'(')
  ... expect('(') -> TokenInfo(type=54 (OP), string='(', start=(1, 0), end=(1, 1), line='(1)')
  expr() ... (looking at 1.1: NUMBER:'1')
    number() ... (looking at 1.1: NUMBER:'1')
    ... number() -> TokenInfo(type=2 (NUMBER), string='1', start=(1, 1), end=(1, 2), line='(1)')
  ... expr() -> [TokenInfo(type=2 (NUMBER), string='1', start=(1, 1), end=(1, 2), line='(1)')]
  expect(')') ... (looking at 1.2: OP:')')
  ... expect(')') -> TokenInfo(type=54 (OP), string=')', start=(1, 2), end=(1, 3), line='(1)')
... start() -> [TokenInfo(type=54 (OP), string='(', start=(1, 0), end=(1, 1), line='(1)'), [TokenInfo(type=2 (NUMBER), string='1', start=(1, 1), end=(1, 2), line='(1)')], TokenInfo(type=54 (OP), string=')', start=(1
ok
test_dangling_reference (test.test_peg_generator.test_pegen.TestPegen) ... ok
test_expr_grammar (test.test_peg_generator.test_pegen.TestPegen) ... ok
test_left_recursion_too_complex (test.test_peg_generator.test_pegen.TestPegen) ... ok
test_left_recursive (test.test_peg_generator.test_pegen.TestPegen) ... ok
test_long_rule_str (test.test_peg_generator.test_pegen.TestPegen) ... ok
test_lookahead (test.test_peg_generator.test_pegen.TestPegen) ... ok
test_missing_start (test.test_peg_generator.test_pegen.TestPegen) ... ok
test_mutually_left_recursive (test.test_peg_generator.test_pegen.TestPegen) ... ok
test_named_lookahead_error (test.test_peg_generator.test_pegen.TestPegen) ... ok
test_nasty_mutually_left_recursive (test.test_peg_generator.test_pegen.TestPegen) ... ok
test_nullable (test.test_peg_generator.test_pegen.TestPegen) ... ok
test_optional_literal (test.test_peg_generator.test_pegen.TestPegen) ... ok
test_optional_operator (test.test_peg_generator.test_pegen.TestPegen) ... ok
test_parse_grammar (test.test_peg_generator.test_pegen.TestPegen) ... ok
test_python_expr (test.test_peg_generator.test_pegen.TestPegen) ... ok
test_repeat_0_complex (test.test_peg_generator.test_pegen.TestPegen) ... ok
test_repeat_0_simple (test.test_peg_generator.test_pegen.TestPegen) ... ok
test_repeat_1_complex (test.test_peg_generator.test_pegen.TestPegen) ... ok
test_repeat_1_simple (test.test_peg_generator.test_pegen.TestPegen) ... ok
test_repeat_with_sep_simple (test.test_peg_generator.test_pegen.TestPegen) ... ok
test_repeat_with_separator_rules (test.test_peg_generator.test_pegen.TestPegen) ... Rule('start', None, Rhs([Alt([NamedItem(None, Gather(StringLeaf("','"), NameLeaf('thing'))), NamedItem(None, NameLeaf('NEWLINE'))])]))
ok
test_start_leader (test.test_peg_generator.test_pegen.TestPegen) ... ok
test_typed_rules (test.test_peg_generator.test_pegen.TestPegen) ... ok

======================================================================
ERROR: test_advanced_left_recursive (test.test_peg_generator.test_c_parser.TestCParser)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/aixtools/python/cpython-master/Lib/test/test_peg_generator/test_c_parser.py", line 155, in test_advanced_left_recursive
    self.check_input_strings_for_grammar(grammar, self.tmp_path, valid_cases)
  File "/home/aixtools/python/cpython-master/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/python/cpython-master/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/python/cpython-master/Tools/peg_generator/pegen/build.py", line 84, in compile_c_extension
    cmd.run()
  File "/home/aixtools/python/cpython-master/Lib/distutils/command/build_ext.py", line 340, in run
    self.build_extensions()
  File "/home/aixtools/python/cpython-master/Lib/distutils/command/build_ext.py", line 449, in build_extensions
    self._build_extensions_serial()
  File "/home/aixtools/python/cpython-master/Lib/distutils/command/build_ext.py", line 474, in _build_extensions_serial
    self.build_extension(ext)
  File "/home/aixtools/python/cpython-master/Lib/distutils/command/build_ext.py", line 551, in build_extension
    self.compiler.link_shared_object(
  File "/home/aixtools/python/cpython-master/Lib/distutils/ccompiler.py", line 713, in link_shared_object
    self.link(CCompiler.SHARED_OBJECT, objects,
  File "/home/aixtools/python/cpython-master/Lib/distutils/unixccompiler.py", line 204, in link
    self.spawn(linker + ld_args)
  File "/home/aixtools/python/cpython-master/Lib/distutils/ccompiler.py", line 910, in spawn
    spawn(cmd, dry_run=self.dry_run)
  File "/home/aixtools/python/cpython-master/Lib/distutils/spawn.py", line 74, in spawn
    proc = subprocess.Popen(cmd, env=env)
  File "/home/aixtools/python/cpython-master/Lib/subprocess.py", line 947, in __init__
    self._execute_child(args, executable, preexec_fn, close_fds,
  File "/home/aixtools/python/cpython-master/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: '/usr/local/lib/python3.9/config-3.9d/ld_so_aix'

======================================================================
ERROR: test_c_parser (test.test_peg_generator.test_c_parser.TestCParser)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/aixtools/python/cpython-master/Lib/test/test_peg_generator/test_c_parser.py", line 81, in test_c_parser
    extension = generate_parser_c_extension(grammar, Path(self.tmp_path))
  File "/home/aixtools/python/cpython-master/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/python/cpython-master/Tools/peg_generator/pegen/build.py", line 84, in compile_c_extension
    cmd.run()
  File "/home/aixtools/python/cpython-master/Lib/distutils/command/build_ext.py", line 340, in run
    self.build_extensions()
  File "/home/aixtools/python/cpython-master/Lib/distutils/command/build_ext.py", line 449, in build_extensions
    self._build_extensions_serial()
  File "/home/aixtools/python/cpython-master/Lib/distutils/command/build_ext.py", line 474, in _build_extensions_serial
    self.build_extension(ext)
  File "/home/aixtools/python/cpython-master/Lib/distutils/command/build_ext.py", line 551, in build_extension
    self.compiler.link_shared_object(
  File "/home/aixtools/python/cpython-master/Lib/distutils/ccompiler.py", line 713, in link_shared_object
    self.link(CCompiler.SHARED_OBJECT, objects,
  File "/home/aixtools/python/cpython-master/Lib/distutils/unixccompiler.py", line 204, in link
    self.spawn(linker + ld_args)
  File "/home/aixtools/python/cpython-master/Lib/distutils/ccompiler.py", line 910, in spawn
    spawn(cmd, dry_run=self.dry_run)
  File "/home/aixtools/python/cpython-master/Lib/distutils/spawn.py", line 74, in spawn
    proc = subprocess.Popen(cmd, env=env)
  File "/home/aixtools/python/cpython-master/Lib/subprocess.py", line 947, in __init__
    self._execute_child(args, executable, preexec_fn, close_fds,
  File "/home/aixtools/python/cpython-master/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: '/usr/local/lib/python3.9/config-3.9d/ld_so_aix'

======================================================================
ERROR: test_cut (test.test_peg_generator.test_c_parser.TestCParser)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/aixtools/python/cpython-master/Lib/test/test_peg_generator/test_c_parser.py", line 129, in test_cut
    self.check_input_strings_for_grammar(grammar, self.tmp_path, valid_cases, invalid_cases)
  File "/home/aixtools/python/cpython-master/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/python/cpython-master/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/python/cpython-master/Tools/peg_generator/pegen/build.py", line 84, in compile_c_extension
    cmd.run()
  File "/home/aixtools/python/cpython-master/Lib/distutils/command/build_ext.py", line 340, in run
    self.build_extensions()
  File "/home/aixtools/python/cpython-master/Lib/distutils/command/build_ext.py", line 449, in build_extensions
    self._build_extensions_serial()
  File "/home/aixtools/python/cpython-master/Lib/distutils/command/build_ext.py", line 474, in _build_extensions_serial
    self.build_extension(ext)
  File "/home/aixtools/python/cpython-master/Lib/distutils/command/build_ext.py", line 551, in build_extension
    self.compiler.link_shared_object(
  File "/home/aixtools/python/cpython-master/Lib/distutils/ccompiler.py", line 713, in link_shared_object
    self.link(CCompiler.SHARED_OBJECT, objects,
  File "/home/aixtools/python/cpython-master/Lib/distutils/unixccompiler.py", line 204, in link
    self.spawn(linker + ld_args)
  File "/home/aixtools/python/cpython-master/Lib/distutils/ccompiler.py", line 910, in spawn
    spawn(cmd, dry_run=self.dry_run)
  File "/home/aixtools/python/cpython-master/Lib/distutils/spawn.py", line 74, in spawn
    proc = subprocess.Popen(cmd, env=env)
  File "/home/aixtools/python/cpython-master/Lib/subprocess.py", line 947, in __init__
    self._execute_child(args, executable, preexec_fn, close_fds,
  File "/home/aixtools/python/cpython-master/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: '/usr/local/lib/python3.9/config-3.9d/ld_so_aix'

======================================================================
ERROR: test_error_in_rules (test.test_peg_generator.test_c_parser.TestCParser)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/aixtools/python/cpython-master/Lib/test/test_peg_generator/test_c_parser.py", line 330, in test_error_in_rules
    extension = generate_parser_c_extension(grammar, Path(self.tmp_path))
  File "/home/aixtools/python/cpython-master/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/python/cpython-master/Tools/peg_generator/pegen/build.py", line 84, in compile_c_extension
    cmd.run()
  File "/home/aixtools/python/cpython-master/Lib/distutils/command/build_ext.py", line 340, in run
    self.build_extensions()
  File "/home/aixtools/python/cpython-master/Lib/distutils/command/build_ext.py", line 449, in build_extensions
    self._build_extensions_serial()
  File "/home/aixtools/python/cpython-master/Lib/distutils/command/build_ext.py", line 474, in _build_extensions_serial
    self.build_extension(ext)
  File "/home/aixtools/python/cpython-master/Lib/distutils/command/build_ext.py", line 551, in build_extension
    self.compiler.link_shared_object(
  File "/home/aixtools/python/cpython-master/Lib/distutils/ccompiler.py", line 713, in link_shared_object
    self.link(CCompiler.SHARED_OBJECT, objects,
  File "/home/aixtools/python/cpython-master/Lib/distutils/unixccompiler.py", line 204, in link
    self.spawn(linker + ld_args)
  File "/home/aixtools/python/cpython-master/Lib/distutils/ccompiler.py", line 910, in spawn
    spawn(cmd, dry_run=self.dry_run)
  File "/home/aixtools/python/cpython-master/Lib/distutils/spawn.py", line 74, in spawn
    proc = subprocess.Popen(cmd, env=env)
  File "/home/aixtools/python/cpython-master/Lib/subprocess.py", line 947, in __init__
    self._execute_child(args, executable, preexec_fn, close_fds,
  File "/home/aixtools/python/cpython-master/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: '/usr/local/lib/python3.9/config-3.9d/ld_so_aix'

======================================================================
ERROR: test_gather (test.test_peg_generator.test_c_parser.TestCParser)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/aixtools/python/cpython-master/Lib/test/test_peg_generator/test_c_parser.py", line 138, in test_gather
    self.check_input_strings_for_grammar(grammar, self.tmp_path, valid_cases, invalid_cases)
  File "/home/aixtools/python/cpython-master/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/python/cpython-master/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/python/cpython-master/Tools/peg_generator/pegen/build.py", line 84, in compile_c_extension
    cmd.run()
  File "/home/aixtools/python/cpython-master/Lib/distutils/command/build_ext.py", line 340, in run
    self.build_extensions()
  File "/home/aixtools/python/cpython-master/Lib/distutils/command/build_ext.py", line 449, in build_extensions
    self._build_extensions_serial()
  File "/home/aixtools/python/cpython-master/Lib/distutils/command/build_ext.py", line 474, in _build_extensions_serial
    self.build_extension(ext)
  File "/home/aixtools/python/cpython-master/Lib/distutils/command/build_ext.py", line 551, in build_extension
    self.compiler.link_shared_object(
  File "/home/aixtools/python/cpython-master/Lib/distutils/ccompiler.py", line 713, in link_shared_object
    self.link(CCompiler.SHARED_OBJECT, objects,
  File "/home/aixtools/python/cpython-master/Lib/distutils/unixccompiler.py", line 204, in link
    self.spawn(linker + ld_args)
  File "/home/aixtools/python/cpython-master/Lib/distutils/ccompiler.py", line 910, in spawn
    spawn(cmd, dry_run=self.dry_run)
  File "/home/aixtools/python/cpython-master/Lib/distutils/spawn.py", line 74, in spawn
    proc = subprocess.Popen(cmd, env=env)
  File "/home/aixtools/python/cpython-master/Lib/subprocess.py", line 947, in __init__
    self._execute_child(args, executable, preexec_fn, close_fds,
  File "/home/aixtools/python/cpython-master/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: '/usr/local/lib/python3.9/config-3.9d/ld_so_aix'

======================================================================
ERROR: test_gather_action_ast (test.test_peg_generator.test_c_parser.TestCParser)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/aixtools/python/cpython-master/Lib/test/test_peg_generator/test_c_parser.py", line 194, in test_gather_action_ast
    self.verify_ast_generation(grammar, stmt, self.tmp_path)
  File "/home/aixtools/python/cpython-master/Lib/test/test_peg_generator/test_c_parser.py", line 53, in verify_ast_generation
    extension = generate_parser_c_extension(grammar, Path(tmp_path))
  File "/home/aixtools/python/cpython-master/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/python/cpython-master/Tools/peg_generator/pegen/build.py", line 84, in compile_c_extension
    cmd.run()
  File "/home/aixtools/python/cpython-master/Lib/distutils/command/build_ext.py", line 340, in run
    self.build_extensions()
  File "/home/aixtools/python/cpython-master/Lib/distutils/command/build_ext.py", line 449, in build_extensions
    self._build_extensions_serial()
  File "/home/aixtools/python/cpython-master/Lib/distutils/command/build_ext.py", line 474, in _build_extensions_serial
    self.build_extension(ext)
  File "/home/aixtools/python/cpython-master/Lib/distutils/command/build_ext.py", line 551, in build_extension
    self.compiler.link_shared_object(
  File "/home/aixtools/python/cpython-master/Lib/distutils/ccompiler.py", line 713, in link_shared_object
    self.link(CCompiler.SHARED_OBJECT, objects,
  File "/home/aixtools/python/cpython-master/Lib/distutils/unixccompiler.py", line 204, in link
    self.spawn(linker + ld_args)
  File "/home/aixtools/python/cpython-master/Lib/distutils/ccompiler.py", line 910, in spawn
    spawn(cmd, dry_run=self.dry_run)
  File "/home/aixtools/python/cpython-master/Lib/distutils/spawn.py", line 74, in spawn
    proc = subprocess.Popen(cmd, env=env)
  File "/home/aixtools/python/cpython-master/Lib/subprocess.py", line 947, in __init__
    self._execute_child(args, executable, preexec_fn, close_fds,
  File "/home/aixtools/python/cpython-master/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: '/usr/local/lib/python3.9/config-3.9d/ld_so_aix'

======================================================================
ERROR: test_if_stmt_action (test.test_peg_generator.test_c_parser.TestCParser)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/aixtools/python/cpython-master/Lib/test/test_peg_generator/test_c_parser.py", line 230, in test_if_stmt_action
    self.verify_ast_generation(grammar, stmt, self.tmp_path)
  File "/home/aixtools/python/cpython-master/Lib/test/test_peg_generator/test_c_parser.py", line 53, in verify_ast_generation
    extension = generate_parser_c_extension(grammar, Path(tmp_path))
  File "/home/aixtools/python/cpython-master/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/python/cpython-master/Tools/peg_generator/pegen/build.py", line 84, in compile_c_extension
    cmd.run()
  File "/home/aixtools/python/cpython-master/Lib/distutils/command/build_ext.py", line 340, in run
    self.build_extensions()
  File "/home/aixtools/python/cpython-master/Lib/distutils/command/build_ext.py", line 449, in build_extensions
    self._build_extensions_serial()
  File "/home/aixtools/python/cpython-master/Lib/distutils/command/build_ext.py", line 474, in _build_extensions_serial
    self.build_extension(ext)
  File "/home/aixtools/python/cpython-master/Lib/distutils/command/build_ext.py", line 551, in build_extension
    self.compiler.link_shared_object(
  File "/home/aixtools/python/cpython-master/Lib/distutils/ccompiler.py", line 713, in link_shared_object
    self.link(CCompiler.SHARED_OBJECT, objects,
  File "/home/aixtools/python/cpython-master/Lib/distutils/unixccompiler.py", line 204, in link
    self.spawn(linker + ld_args)
  File "/home/aixtools/python/cpython-master/Lib/distutils/ccompiler.py", line 910, in spawn
    spawn(cmd, dry_run=self.dry_run)
  File "/home/aixtools/python/cpython-master/Lib/distutils/spawn.py", line 74, in spawn
    proc = subprocess.Popen(cmd, env=env)
  File "/home/aixtools/python/cpython-master/Lib/subprocess.py", line 947, in __init__
    self._execute_child(args, executable, preexec_fn, close_fds,
  File "/home/aixtools/python/cpython-master/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: '/usr/local/lib/python3.9/config-3.9d/ld_so_aix'

======================================================================
ERROR: test_left_recursion (test.test_peg_generator.test_c_parser.TestCParser)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/aixtools/python/cpython-master/Lib/test/test_peg_generator/test_c_parser.py", line 147, in test_left_recursion
    self.check_input_strings_for_grammar(grammar, self.tmp_path, valid_cases)
  File "/home/aixtools/python/cpython-master/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/python/cpython-master/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/python/cpython-master/Tools/peg_generator/pegen/build.py", line 84, in compile_c_extension
    cmd.run()
  File "/home/aixtools/python/cpython-master/Lib/distutils/command/build_ext.py", line 340, in run
    self.build_extensions()
  File "/home/aixtools/python/cpython-master/Lib/distutils/command/build_ext.py", line 449, in build_extensions
    self._build_extensions_serial()
  File "/home/aixtools/python/cpython-master/Lib/distutils/command/build_ext.py", line 474, in _build_extensions_serial
    self.build_extension(ext)
  File "/home/aixtools/python/cpython-master/Lib/distutils/command/build_ext.py", line 551, in build_extension
    self.compiler.link_shared_object(
  File "/home/aixtools/python/cpython-master/Lib/distutils/ccompiler.py", line 713, in link_shared_object
    self.link(CCompiler.SHARED_OBJECT, objects,
  File "/home/aixtools/python/cpython-master/Lib/distutils/unixccompiler.py", line 204, in link
    self.spawn(linker + ld_args)
  File "/home/aixtools/python/cpython-master/Lib/distutils/ccompiler.py", line 910, in spawn
    spawn(cmd, dry_run=self.dry_run)
  File "/home/aixtools/python/cpython-master/Lib/distutils/spawn.py", line 74, in spawn
    proc = subprocess.Popen(cmd, env=env)
  File "/home/aixtools/python/cpython-master/Lib/subprocess.py", line 947, in __init__
    self._execute_child(args, executable, preexec_fn, close_fds,
  File "/home/aixtools/python/cpython-master/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: '/usr/local/lib/python3.9/config-3.9d/ld_so_aix'

======================================================================
ERROR: test_lookahead (test.test_peg_generator.test_c_parser.TestCParser)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/aixtools/python/cpython-master/Lib/test/test_peg_generator/test_c_parser.py", line 107, in test_lookahead
    self.check_input_strings_for_grammar(grammar, self.tmp_path, valid_cases, invalid_cases)
  File "/home/aixtools/python/cpython-master/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/python/cpython-master/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/python/cpython-master/Tools/peg_generator/pegen/build.py", line 84, in compile_c_extension
    cmd.run()
  File "/home/aixtools/python/cpython-master/Lib/distutils/command/build_ext.py", line 340, in run
    self.build_extensions()
  File "/home/aixtools/python/cpython-master/Lib/distutils/command/build_ext.py", line 449, in build_extensions
    self._build_extensions_serial()
  File "/home/aixtools/python/cpython-master/Lib/distutils/command/build_ext.py", line 474, in _build_extensions_serial
    self.build_extension(ext)
  File "/home/aixtools/python/cpython-master/Lib/distutils/command/build_ext.py", line 551, in build_extension
    self.compiler.link_shared_object(
  File "/home/aixtools/python/cpython-master/Lib/distutils/ccompiler.py", line 713, in link_shared_object
    self.link(CCompiler.SHARED_OBJECT, objects,
  File "/home/aixtools/python/cpython-master/Lib/distutils/unixccompiler.py", line 204, in link
    self.spawn(linker + ld_args)
  File "/home/aixtools/python/cpython-master/Lib/distutils/ccompiler.py", line 910, in spawn
    spawn(cmd, dry_run=self.dry_run)
  File "/home/aixtools/python/cpython-master/Lib/distutils/spawn.py", line 74, in spawn
    proc = subprocess.Popen(cmd, env=env)
  File "/home/aixtools/python/cpython-master/Lib/subprocess.py", line 947, in __init__
    self._execute_child(args, executable, preexec_fn, close_fds,
  File "/home/aixtools/python/cpython-master/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: '/usr/local/lib/python3.9/config-3.9d/ld_so_aix'

======================================================================
ERROR: test_mutually_left_recursive (test.test_peg_generator.test_c_parser.TestCParser)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/aixtools/python/cpython-master/Lib/test/test_peg_generator/test_c_parser.py", line 164, in test_mutually_left_recursive
    self.check_input_strings_for_grammar(grammar, self.tmp_path, valid_cases)
  File "/home/aixtools/python/cpython-master/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/python/cpython-master/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/python/cpython-master/Tools/peg_generator/pegen/build.py", line 84, in compile_c_extension
    cmd.run()
  File "/home/aixtools/python/cpython-master/Lib/distutils/command/build_ext.py", line 340, in run
    self.build_extensions()
  File "/home/aixtools/python/cpython-master/Lib/distutils/command/build_ext.py", line 449, in build_extensions
    self._build_extensions_serial()
  File "/home/aixtools/python/cpython-master/Lib/distutils/command/build_ext.py", line 474, in _build_extensions_serial
    self.build_extension(ext)
  File "/home/aixtools/python/cpython-master/Lib/distutils/command/build_ext.py", line 551, in build_extension
    self.compiler.link_shared_object(
  File "/home/aixtools/python/cpython-master/Lib/distutils/ccompiler.py", line 713, in link_shared_object
    self.link(CCompiler.SHARED_OBJECT, objects,
  File "/home/aixtools/python/cpython-master/Lib/distutils/unixccompiler.py", line 204, in link
    self.spawn(linker + ld_args)
  File "/home/aixtools/python/cpython-master/Lib/distutils/ccompiler.py", line 910, in spawn
    spawn(cmd, dry_run=self.dry_run)
  File "/home/aixtools/python/cpython-master/Lib/distutils/spawn.py", line 74, in spawn
    proc = subprocess.Popen(cmd, env=env)
  File "/home/aixtools/python/cpython-master/Lib/subprocess.py", line 947, in __init__
    self._execute_child(args, executable, preexec_fn, close_fds,
  File "/home/aixtools/python/cpython-master/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: '/usr/local/lib/python3.9/config-3.9d/ld_so_aix'

======================================================================
ERROR: test_nasty_mutually_left_recursive (test.test_peg_generator.test_c_parser.TestCParser)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/aixtools/python/cpython-master/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/python/cpython-master/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/python/cpython-master/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/python/cpython-master/Tools/peg_generator/pegen/build.py", line 84, in compile_c_extension
    cmd.run()
  File "/home/aixtools/python/cpython-master/Lib/distutils/command/build_ext.py", line 340, in run
    self.build_extensions()
  File "/home/aixtools/python/cpython-master/Lib/distutils/command/build_ext.py", line 449, in build_extensions
    self._build_extensions_serial()
  File "/home/aixtools/python/cpython-master/Lib/distutils/command/build_ext.py", line 474, in _build_extensions_serial
    self.build_extension(ext)
  File "/home/aixtools/python/cpython-master/Lib/distutils/command/build_ext.py", line 551, in build_extension
    self.compiler.link_shared_object(
  File "/home/aixtools/python/cpython-master/Lib/distutils/ccompiler.py", line 713, in link_shared_object
    self.link(CCompiler.SHARED_OBJECT, objects,
  File "/home/aixtools/python/cpython-master/Lib/distutils/unixccompiler.py", line 204, in link
    self.spawn(linker + ld_args)
  File "/home/aixtools/python/cpython-master/Lib/distutils/ccompiler.py", line 910, in spawn
    spawn(cmd, dry_run=self.dry_run)
  File "/home/aixtools/python/cpython-master/Lib/distutils/spawn.py", line 74, in spawn
    proc = subprocess.Popen(cmd, env=env)
  File "/home/aixtools/python/cpython-master/Lib/subprocess.py", line 947, in __init__
    self._execute_child(args, executable, preexec_fn, close_fds,
  File "/home/aixtools/python/cpython-master/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: '/usr/local/lib/python3.9/config-3.9d/ld_so_aix'

======================================================================
ERROR: test_negative_lookahead (test.test_peg_generator.test_c_parser.TestCParser)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/aixtools/python/cpython-master/Lib/test/test_peg_generator/test_c_parser.py", line 116, in test_negative_lookahead
    self.check_input_strings_for_grammar(grammar, self.tmp_path, valid_cases, invalid_cases)
  File "/home/aixtools/python/cpython-master/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/python/cpython-master/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/python/cpython-master/Tools/peg_generator/pegen/build.py", line 84, in compile_c_extension
    cmd.run()
  File "/home/aixtools/python/cpython-master/Lib/distutils/command/build_ext.py", line 340, in run
    self.build_extensions()
  File "/home/aixtools/python/cpython-master/Lib/distutils/command/build_ext.py", line 449, in build_extensions
    self._build_extensions_serial()
  File "/home/aixtools/python/cpython-master/Lib/distutils/command/build_ext.py", line 474, in _build_extensions_serial
    self.build_extension(ext)
  File "/home/aixtools/python/cpython-master/Lib/distutils/command/build_ext.py", line 551, in build_extension
    self.compiler.link_shared_object(
  File "/home/aixtools/python/cpython-master/Lib/distutils/ccompiler.py", line 713, in link_shared_object
    self.link(CCompiler.SHARED_OBJECT, objects,
  File "/home/aixtools/python/cpython-master/Lib/distutils/unixccompiler.py", line 204, in link
    self.spawn(linker + ld_args)
  File "/home/aixtools/python/cpython-master/Lib/distutils/ccompiler.py", line 910, in spawn
    spawn(cmd, dry_run=self.dry_run)
  File "/home/aixtools/python/cpython-master/Lib/distutils/spawn.py", line 74, in spawn
    proc = subprocess.Popen(cmd, env=env)
  File "/home/aixtools/python/cpython-master/Lib/subprocess.py", line 947, in __init__
    self._execute_child(args, executable, preexec_fn, close_fds,
  File "/home/aixtools/python/cpython-master/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: '/usr/local/lib/python3.9/config-3.9d/ld_so_aix'

======================================================================
ERROR: test_pass_stmt_action (test.test_peg_generator.test_c_parser.TestCParser)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/aixtools/python/cpython-master/Lib/test/test_peg_generator/test_c_parser.py", line 206, in test_pass_stmt_action
    self.verify_ast_generation(grammar, stmt, self.tmp_path)
  File "/home/aixtools/python/cpython-master/Lib/test/test_peg_generator/test_c_parser.py", line 53, in verify_ast_generation
    extension = generate_parser_c_extension(grammar, Path(tmp_path))
  File "/home/aixtools/python/cpython-master/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/python/cpython-master/Tools/peg_generator/pegen/build.py", line 84, in compile_c_extension
    cmd.run()
  File "/home/aixtools/python/cpython-master/Lib/distutils/command/build_ext.py", line 340, in run
    self.build_extensions()
  File "/home/aixtools/python/cpython-master/Lib/distutils/command/build_ext.py", line 449, in build_extensions
    self._build_extensions_serial()
  File "/home/aixtools/python/cpython-master/Lib/distutils/command/build_ext.py", line 474, in _build_extensions_serial
    self.build_extension(ext)
  File "/home/aixtools/python/cpython-master/Lib/distutils/command/build_ext.py", line 551, in build_extension
    self.compiler.link_shared_object(
  File "/home/aixtools/python/cpython-master/Lib/distutils/ccompiler.py", line 713, in link_shared_object
    self.link(CCompiler.SHARED_OBJECT, objects,
  File "/home/aixtools/python/cpython-master/Lib/distutils/unixccompiler.py", line 204, in link
    self.spawn(linker + ld_args)
  File "/home/aixtools/python/cpython-master/Lib/distutils/ccompiler.py", line 910, in spawn
    spawn(cmd, dry_run=self.dry_run)
  File "/home/aixtools/python/cpython-master/Lib/distutils/spawn.py", line 74, in spawn
    proc = subprocess.Popen(cmd, env=env)
  File "/home/aixtools/python/cpython-master/Lib/subprocess.py", line 947, in __init__
    self._execute_child(args, executable, preexec_fn, close_fds,
  File "/home/aixtools/python/cpython-master/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: '/usr/local/lib/python3.9/config-3.9d/ld_so_aix'

======================================================================
ERROR: test_return_stmt_noexpr_action (test.test_peg_generator.test_c_parser.TestCParser)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/aixtools/python/cpython-master/Lib/test/test_peg_generator/test_c_parser.py", line 186, in test_return_stmt_noexpr_action
    self.verify_ast_generation(grammar, stmt, self.tmp_path)
  File "/home/aixtools/python/cpython-master/Lib/test/test_peg_generator/test_c_parser.py", line 53, in verify_ast_generation
    extension = generate_parser_c_extension(grammar, Path(tmp_path))
  File "/home/aixtools/python/cpython-master/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/python/cpython-master/Tools/peg_generator/pegen/build.py", line 84, in compile_c_extension
    cmd.run()
  File "/home/aixtools/python/cpython-master/Lib/distutils/command/build_ext.py", line 340, in run
    self.build_extensions()
  File "/home/aixtools/python/cpython-master/Lib/distutils/command/build_ext.py", line 449, in build_extensions
    self._build_extensions_serial()
  File "/home/aixtools/python/cpython-master/Lib/distutils/command/build_ext.py", line 474, in _build_extensions_serial
    self.build_extension(ext)
  File "/home/aixtools/python/cpython-master/Lib/distutils/command/build_ext.py", line 551, in build_extension
    self.compiler.link_shared_object(
  File "/home/aixtools/python/cpython-master/Lib/distutils/ccompiler.py", line 713, in link_shared_object
    self.link(CCompiler.SHARED_OBJECT, objects,
  File "/home/aixtools/python/cpython-master/Lib/distutils/unixccompiler.py", line 204, in link
    self.spawn(linker + ld_args)
  File "/home/aixtools/python/cpython-master/Lib/distutils/ccompiler.py", line 910, in spawn
    spawn(cmd, dry_run=self.dry_run)
  File "/home/aixtools/python/cpython-master/Lib/distutils/spawn.py", line 74, in spawn
    proc = subprocess.Popen(cmd, env=env)
  File "/home/aixtools/python/cpython-master/Lib/subprocess.py", line 947, in __init__
    self._execute_child(args, executable, preexec_fn, close_fds,
  File "/home/aixtools/python/cpython-master/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: '/usr/local/lib/python3.9/config-3.9d/ld_so_aix'

======================================================================
ERROR: test_same_name_different_types (test.test_peg_generator.test_c_parser.TestCParser)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/aixtools/python/cpython-master/Lib/test/test_peg_generator/test_c_parser.py", line 245, in test_same_name_different_types
    extension = generate_parser_c_extension(grammar, Path(self.tmp_path))
  File "/home/aixtools/python/cpython-master/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/python/cpython-master/Tools/peg_generator/pegen/build.py", line 84, in compile_c_extension
    cmd.run()
  File "/home/aixtools/python/cpython-master/Lib/distutils/command/build_ext.py", line 340, in run
    self.build_extensions()
  File "/home/aixtools/python/cpython-master/Lib/distutils/command/build_ext.py", line 449, in build_extensions
    self._build_extensions_serial()
  File "/home/aixtools/python/cpython-master/Lib/distutils/command/build_ext.py", line 474, in _build_extensions_serial
    self.build_extension(ext)
  File "/home/aixtools/python/cpython-master/Lib/distutils/command/build_ext.py", line 551, in build_extension
    self.compiler.link_shared_object(
  File "/home/aixtools/python/cpython-master/Lib/distutils/ccompiler.py", line 713, in link_shared_object
    self.link(CCompiler.SHARED_OBJECT, objects,
  File "/home/aixtools/python/cpython-master/Lib/distutils/unixccompiler.py", line 204, in link
    self.spawn(linker + ld_args)
  File "/home/aixtools/python/cpython-master/Lib/distutils/ccompiler.py", line 910, in spawn
    spawn(cmd, dry_run=self.dry_run)
  File "/home/aixtools/python/cpython-master/Lib/distutils/spawn.py", line 74, in spawn
    proc = subprocess.Popen(cmd, env=env)
  File "/home/aixtools/python/cpython-master/Lib/subprocess.py", line 947, in __init__
    self._execute_child(args, executable, preexec_fn, close_fds,
  File "/home/aixtools/python/cpython-master/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: '/usr/local/lib/python3.9/config-3.9d/ld_so_aix'

======================================================================
ERROR: test_syntax_error_for_string (test.test_peg_generator.test_c_parser.TestCParser)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/aixtools/python/cpython-master/Lib/test/test_peg_generator/test_c_parser.py", line 299, in test_syntax_error_for_string
    extension = generate_parser_c_extension(grammar, Path(self.tmp_path))
  File "/home/aixtools/python/cpython-master/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/python/cpython-master/Tools/peg_generator/pegen/build.py", line 84, in compile_c_extension
    cmd.run()
  File "/home/aixtools/python/cpython-master/Lib/distutils/command/build_ext.py", line 340, in run
    self.build_extensions()
  File "/home/aixtools/python/cpython-master/Lib/distutils/command/build_ext.py", line 449, in build_extensions
    self._build_extensions_serial()
  File "/home/aixtools/python/cpython-master/Lib/distutils/command/build_ext.py", line 474, in _build_extensions_serial
    self.build_extension(ext)
  File "/home/aixtools/python/cpython-master/Lib/distutils/command/build_ext.py", line 551, in build_extension
    self.compiler.link_shared_object(
  File "/home/aixtools/python/cpython-master/Lib/distutils/ccompiler.py", line 713, in link_shared_object
    self.link(CCompiler.SHARED_OBJECT, objects,
  File "/home/aixtools/python/cpython-master/Lib/distutils/unixccompiler.py", line 204, in link
    self.spawn(linker + ld_args)
  File "/home/aixtools/python/cpython-master/Lib/distutils/ccompiler.py", line 910, in spawn
    spawn(cmd, dry_run=self.dry_run)
  File "/home/aixtools/python/cpython-master/Lib/distutils/spawn.py", line 74, in spawn
    proc = subprocess.Popen(cmd, env=env)
  File "/home/aixtools/python/cpython-master/Lib/subprocess.py", line 947, in __init__
    self._execute_child(args, executable, preexec_fn, close_fds,
  File "/home/aixtools/python/cpython-master/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: '/usr/local/lib/python3.9/config-3.9d/ld_so_aix'

======================================================================
ERROR: test_ternary_operator (test.test_peg_generator.test_c_parser.TestCParser)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/aixtools/python/cpython-master/Lib/test/test_peg_generator/test_c_parser.py", line 290, in test_ternary_operator
    self.verify_ast_generation(grammar_source, stmt, self.tmp_path)
  File "/home/aixtools/python/cpython-master/Lib/test/test_peg_generator/test_c_parser.py", line 53, in verify_ast_generation
    extension = generate_parser_c_extension(grammar, Path(tmp_path))
  File "/home/aixtools/python/cpython-master/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/python/cpython-master/Tools/peg_generator/pegen/build.py", line 84, in compile_c_extension
    cmd.run()
  File "/home/aixtools/python/cpython-master/Lib/distutils/command/build_ext.py", line 340, in run
    self.build_extensions()
  File "/home/aixtools/python/cpython-master/Lib/distutils/command/build_ext.py", line 449, in build_extensions
    self._build_extensions_serial()
  File "/home/aixtools/python/cpython-master/Lib/distutils/command/build_ext.py", line 474, in _build_extensions_serial
    self.build_extension(ext)
  File "/home/aixtools/python/cpython-master/Lib/distutils/command/build_ext.py", line 551, in build_extension
    self.compiler.link_shared_object(
  File "/home/aixtools/python/cpython-master/Lib/distutils/ccompiler.py", line 713, in link_shared_object
    self.link(CCompiler.SHARED_OBJECT, objects,
  File "/home/aixtools/python/cpython-master/Lib/distutils/unixccompiler.py", line 204, in link
    self.spawn(linker + ld_args)
  File "/home/aixtools/python/cpython-master/Lib/distutils/ccompiler.py", line 910, in spawn
    spawn(cmd, dry_run=self.dry_run)
  File "/home/aixtools/python/cpython-master/Lib/distutils/spawn.py", line 74, in spawn
    proc = subprocess.Popen(cmd, env=env)
  File "/home/aixtools/python/cpython-master/Lib/subprocess.py", line 947, in __init__
    self._execute_child(args, executable, preexec_fn, close_fds,
  File "/home/aixtools/python/cpython-master/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: '/usr/local/lib/python3.9/config-3.9d/ld_so_aix'

======================================================================
ERROR: test_with_stmt_with_paren (test.test_peg_generator.test_c_parser.TestCParser)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/aixtools/python/cpython-master/Lib/test/test_peg_generator/test_c_parser.py", line 270, in test_with_stmt_with_paren
    extension = generate_parser_c_extension(grammar, Path(self.tmp_path))
  File "/home/aixtools/python/cpython-master/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/python/cpython-master/Tools/peg_generator/pegen/build.py", line 84, in compile_c_extension
    cmd.run()
  File "/home/aixtools/python/cpython-master/Lib/distutils/command/build_ext.py", line 340, in run
    self.build_extensions()
  File "/home/aixtools/python/cpython-master/Lib/distutils/command/build_ext.py", line 449, in build_extensions
    self._build_extensions_serial()
  File "/home/aixtools/python/cpython-master/Lib/distutils/command/build_ext.py", line 474, in _build_extensions_serial
    self.build_extension(ext)
  File "/home/aixtools/python/cpython-master/Lib/distutils/command/build_ext.py", line 551, in build_extension
    self.compiler.link_shared_object(
  File "/home/aixtools/python/cpython-master/Lib/distutils/ccompiler.py", line 713, in link_shared_object
    self.link(CCompiler.SHARED_OBJECT, objects,
  File "/home/aixtools/python/cpython-master/Lib/distutils/unixccompiler.py", line 204, in link
    self.spawn(linker + ld_args)
  File "/home/aixtools/python/cpython-master/Lib/distutils/ccompiler.py", line 910, in spawn
    spawn(cmd, dry_run=self.dry_run)
  File "/home/aixtools/python/cpython-master/Lib/distutils/spawn.py", line 74, in spawn
    proc = subprocess.Popen(cmd, env=env)
  File "/home/aixtools/python/cpython-master/Lib/subprocess.py", line 947, in __init__
    self._execute_child(args, executable, preexec_fn, close_fds,
  File "/home/aixtools/python/cpython-master/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: '/usr/local/lib/python3.9/config-3.9d/ld_so_aix'

----------------------------------------------------------------------

Ran 70 tests in 84.622s

FAILED (errors=18)
test test_peg_generator failed
1 test failed again:
    test_peg_generator

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40370>
_______________________________________

From report at bugs.python.org  Thu Apr 23 12:34:46 2020
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Thu, 23 Apr 2020 16:34:46 +0000
Subject: [issue39385] Add an assertNoLogs context manager to unittest TestCase
In-Reply-To: <1579379123.37.0.908861475494.issue39385@roundup.psfhosted.org>
Message-ID: <1587659686.87.0.518892671892.issue39385@roundup.psfhosted.org>


R?mi Lapeyre <remi.lapeyre at henki.fr> added the comment:

This makes sense, should assertNoWarns() be added too?

----------
nosy: +remi.lapeyre

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39385>
_______________________________________

From report at bugs.python.org  Thu Apr 23 13:03:59 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 23 Apr 2020 17:03:59 +0000
Subject: [issue39983] test.regrtest: test marked as failed (env changed),
 but no warning: test_multiprocessing_forkserver
In-Reply-To: <1584397271.26.0.591205335177.issue39983@roundup.psfhosted.org>
Message-ID: <1587661439.74.0.873377827199.issue39983@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset d663d34685e18588748569468c672763f4c73b3e by Victor Stinner in branch 'master':
bpo-39983: Add test.support.print_warning() (GH-19683)
https://github.com/python/cpython/commit/d663d34685e18588748569468c672763f4c73b3e


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39983>
_______________________________________

From report at bugs.python.org  Thu Apr 23 13:09:36 2020
From: report at bugs.python.org (=?utf-8?q?Marcin_Wi=C5=9Bniewsk?=)
Date: Thu, 23 Apr 2020 17:09:36 +0000
Subject: [issue39148] DatagramProtocol + IPv6 does not work with
 ProactorEventLoop
In-Reply-To: <1577530511.62.0.532247879973.issue39148@roundup.psfhosted.org>
Message-ID: <1587661776.94.0.692944831563.issue39148@roundup.psfhosted.org>


Marcin Wi?niewsk <martini.mwn at gmail.com> added the comment:

>``>#
#7?0.. ?
>?&^^}
>7&?_86>>
X.*
>{[??_`&&???
$?/>}<?#?>?="?

----------
nosy: +Marcin Wi?niewsk
versions: +Python 3.6
Added file: https://bugs.python.org/file49089/README.md20629842+superfon at users.noreply.github.com

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39148>
_______________________________________

From report at bugs.python.org  Thu Apr 23 13:16:36 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 23 Apr 2020 17:16:36 +0000
Subject: [issue39148] DatagramProtocol + IPv6 does not work with
 ProactorEventLoop
In-Reply-To: <1577530511.62.0.532247879973.issue39148@roundup.psfhosted.org>
Message-ID: <1587662196.23.0.402287949294.issue39148@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
Removed message: https://bugs.python.org/msg367131

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39148>
_______________________________________

From report at bugs.python.org  Thu Apr 23 13:17:05 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 23 Apr 2020 17:17:05 +0000
Subject: [issue39148] DatagramProtocol + IPv6 does not work with
 ProactorEventLoop
In-Reply-To: <1577530511.62.0.532247879973.issue39148@roundup.psfhosted.org>
Message-ID: <1587662225.92.0.884971966053.issue39148@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


Removed file: https://bugs.python.org/file49089/README.md20629842+superfon at users.noreply.github.com

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39148>
_______________________________________

From report at bugs.python.org  Thu Apr 23 13:25:14 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 23 Apr 2020 17:25:14 +0000
Subject: [issue39932] test_multiprocessing_fork leaked [0, 2,
 0] file descriptors on aarch64 RHEL8 Refleaks 3.7 buildbot
In-Reply-To: <1583927530.29.0.751848754039.issue39932@roundup.psfhosted.org>
Message-ID: <1587662714.0.0.798343382188.issue39932@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

On aarch64 RHEL8 Refleaks 3.7, I managed to reproduce the issue with a single test:

./python -m test test_multiprocessing_fork -R 3:3 -m test.test_multiprocessing_fork.WithProcessesTestHeap.test_heap -v

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39932>
_______________________________________

From report at bugs.python.org  Thu Apr 23 13:28:45 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 23 Apr 2020 17:28:45 +0000
Subject: [issue39932] test_multiprocessing_fork leaked [0, 2,
 0] file descriptors on aarch64 RHEL8 Refleaks 3.7 buildbot
In-Reply-To: <1583927530.29.0.751848754039.issue39932@roundup.psfhosted.org>
Message-ID: <1587662925.21.0.533140736162.issue39932@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

The following command fails randomly:

$ ./python -m test test_multiprocessing_fork -R 3:3 -m test.test_multiprocessing_fork.WithProcessesTestHeap.test_heap -v

Run 1:

test_multiprocessing_fork leaked [73, 52, 33] references, sum=158
test_multiprocessing_fork leaked [31, 23, 14] memory blocks, sum=68
test_multiprocessing_fork leaked [2, 0, 0] file descriptors, sum=2
test_multiprocessing_fork failed

Run 2:

1 test OK.

Run 6:

test_multiprocessing_fork leaked [0, 2, 0] file descriptors, sum=2
test_multiprocessing_fork failed

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39932>
_______________________________________

From report at bugs.python.org  Thu Apr 23 13:39:13 2020
From: report at bugs.python.org (Kit Yan Choi)
Date: Thu, 23 Apr 2020 17:39:13 +0000
Subject: [issue39385] Add an assertNoLogs context manager to unittest TestCase
In-Reply-To: <1579379123.37.0.908861475494.issue39385@roundup.psfhosted.org>
Message-ID: <1587663553.14.0.929335918795.issue39385@roundup.psfhosted.org>


Kit Yan Choi <kit at kychoi.org> added the comment:

Thank you for looking into this.
Yes, I agree it makes sense to have assertNoWarns for the same reason.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39385>
_______________________________________

From report at bugs.python.org  Thu Apr 23 14:06:49 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 23 Apr 2020 18:06:49 +0000
Subject: [issue40334] PEP 617: new PEG-based parser
In-Reply-To: <1587327377.33.0.614039250584.issue40334@roundup.psfhosted.org>
Message-ID: <1587665209.47.0.540911321755.issue40334@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

AMD64 Windows10 3.x:
https://buildbot.python.org/all/#builders/129/builds/825

Warning -- files was modified by test_peg_generator
  Before: []
  After:  ['parse_d.cp39-win_amd64.pdb', 'vc140.pdb']

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40334>
_______________________________________

From report at bugs.python.org  Thu Apr 23 14:12:04 2020
From: report at bugs.python.org (Lysandros Nikolaou)
Date: Thu, 23 Apr 2020 18:12:04 +0000
Subject: [issue40334] PEP 617: new PEG-based parser
In-Reply-To: <1587327377.33.0.614039250584.issue40334@roundup.psfhosted.org>
Message-ID: <1587665524.22.0.292107350028.issue40334@roundup.psfhosted.org>


Lysandros Nikolaou <lisandrosnik at gmail.com> added the comment:

> Warning -- files was modified by test_peg_generator
>   Before: []
>   After:  ['parse_d.cp39-win_amd64.pdb', 'vc140.pdb']

Currently working on this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40334>
_______________________________________

From report at bugs.python.org  Thu Apr 23 14:13:34 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 23 Apr 2020 18:13:34 +0000
Subject: [issue40334] PEP 617: new PEG-based parser
In-Reply-To: <1587327377.33.0.614039250584.issue40334@roundup.psfhosted.org>
Message-ID: <1587665614.9.0.155644661281.issue40334@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

$ make -s regen-all
./Include/opcode.h.new regenerated from ./Lib/opcode.py
Jump table written into ./Python/opcode_targets.h.new
Traceback (most recent call last):
  File "/usr/lib/python3.6/runpy.py", line 193, in _run_module_as_main
    "__main__", mod_spec)
  File "/usr/lib/python3.6/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/home/serhiy/py/cpython/Tools/peg_generator/pegen/__main__.py", line 14, in <module>
    from typing import Final
ImportError: cannot import name 'Final'
Makefile:837: recipe for target 'regen-pegen' failed
make: *** [regen-pegen] Error 1

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40334>
_______________________________________

From report at bugs.python.org  Thu Apr 23 14:26:54 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 23 Apr 2020 18:26:54 +0000
Subject: [issue40336] Refactor typing._SpecialForm
In-Reply-To: <1587382077.76.0.465264579833.issue40336@roundup.psfhosted.org>
Message-ID: <1587666414.54.0.977302974689.issue40336@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 40ded947f82683f0ed08144599a83d3a1ce719eb by Serhiy Storchaka in branch 'master':
bpo-40336: Refactor typing._SpecialForm (GH-19620)
https://github.com/python/cpython/commit/40ded947f82683f0ed08144599a83d3a1ce719eb


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40336>
_______________________________________

From report at bugs.python.org  Thu Apr 23 14:28:05 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 23 Apr 2020 18:28:05 +0000
Subject: [issue40336] Refactor typing._SpecialForm
In-Reply-To: <1587382077.76.0.465264579833.issue40336@roundup.psfhosted.org>
Message-ID: <1587666485.53.0.0729619600613.issue40336@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40336>
_______________________________________

From report at bugs.python.org  Thu Apr 23 14:38:08 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 23 Apr 2020 18:38:08 +0000
Subject: [issue40334] PEP 617: new PEG-based parser
In-Reply-To: <1587327377.33.0.614039250584.issue40334@roundup.psfhosted.org>
Message-ID: <1587667088.02.0.539971775674.issue40334@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

> ImportError: cannot import name 'Final'

Currently, you need Python3.8+ to do 'make regen-pegen'. We can try to modify the module to not use newer features like "Final" so you can use older Pythons.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40334>
_______________________________________

From report at bugs.python.org  Thu Apr 23 14:42:14 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 23 Apr 2020 18:42:14 +0000
Subject: [issue40334] PEP 617: new PEG-based parser
In-Reply-To: <1587327377.33.0.614039250584.issue40334@roundup.psfhosted.org>
Message-ID: <1587667334.66.0.479015940685.issue40334@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

It does not work with python3.8 either.

$ make -s regen-all PYTHON_FOR_REGEN=python3.8
./Include/opcode.h.new regenerated from ./Lib/opcode.py
Jump table written into ./Python/opcode_targets.h.new
Traceback (most recent call last):
  File "/usr/lib/python3.8/runpy.py", line 192, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "/usr/lib/python3.8/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/home/serhiy/py/cpython/Tools/peg_generator/pegen/__main__.py", line 16, in <module>
    from pegen.build import build_parser_and_generator
  File "/home/serhiy/py/cpython/Tools/peg_generator/pegen/build.py", line 13, in <module>
    from distutils.tests.support import fixup_build_ext
ModuleNotFoundError: No module named 'distutils.tests'
Error in sys.excepthook:
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/apport_python_hook.py", line 63, in apport_excepthook
    from apport.fileutils import likely_packaged, get_recent_crashes
  File "/usr/lib/python3/dist-packages/apport/__init__.py", line 5, in <module>
    from apport.report import Report
  File "/usr/lib/python3/dist-packages/apport/report.py", line 30, in <module>
    import apport.fileutils
  File "/usr/lib/python3/dist-packages/apport/fileutils.py", line 23, in <module>
    from apport.packaging_impl import impl as packaging
  File "/usr/lib/python3/dist-packages/apport/packaging_impl.py", line 24, in <module>
    import apt
  File "/usr/lib/python3/dist-packages/apt/__init__.py", line 23, in <module>
    import apt_pkg
ModuleNotFoundError: No module named 'apt_pkg'

Original exception was:
Traceback (most recent call last):
  File "/usr/lib/python3.8/runpy.py", line 192, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "/usr/lib/python3.8/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/home/serhiy/py/cpython/Tools/peg_generator/pegen/__main__.py", line 16, in <module>
    from pegen.build import build_parser_and_generator
  File "/home/serhiy/py/cpython/Tools/peg_generator/pegen/build.py", line 13, in <module>
    from distutils.tests.support import fixup_build_ext
ModuleNotFoundError: No module named 'distutils.tests'
Makefile:837: recipe for target 'regen-pegen' failed
make: *** [regen-pegen] Error 1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40334>
_______________________________________

From report at bugs.python.org  Thu Apr 23 14:48:31 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 23 Apr 2020 18:48:31 +0000
Subject: [issue40334] PEP 617: new PEG-based parser
In-Reply-To: <1587327377.33.0.614039250584.issue40334@roundup.psfhosted.org>
Message-ID: <1587667711.66.0.0352509956079.issue40334@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

> oduleNotFoundError: No module named 'distutils.tests'

Oh, are you using a python distribution that strips distutils? Is this Debian or Ubuntu?

I suppose we need to account for that. I will create a PR for trying to address both. That's for pointing that out, Serhiy!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40334>
_______________________________________

From report at bugs.python.org  Thu Apr 23 14:49:34 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 23 Apr 2020 18:49:34 +0000
Subject: [issue40334] PEP 617: new PEG-based parser
In-Reply-To: <1587327377.33.0.614039250584.issue40334@roundup.psfhosted.org>
Message-ID: <1587667774.96.0.162785880802.issue40334@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

"That's for pointing that out" -> "Thanks for pointing that out"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40334>
_______________________________________

From report at bugs.python.org  Thu Apr 23 15:06:44 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 23 Apr 2020 19:06:44 +0000
Subject: [issue40334] PEP 617: new PEG-based parser
In-Reply-To: <1587327377.33.0.614039250584.issue40334@roundup.psfhosted.org>
Message-ID: <1587668804.46.0.146095670637.issue40334@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
pull_requests: +19004
pull_request: https://github.com/python/cpython/pull/19684

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40334>
_______________________________________

From report at bugs.python.org  Thu Apr 23 16:10:43 2020
From: report at bugs.python.org (Eryk Sun)
Date: Thu, 23 Apr 2020 20:10:43 +0000
Subject: [issue40368] os.path.realpath uppercases Windows drive letter on
 Python 3.8
In-Reply-To: <1587590743.67.0.821024621015.issue40368@roundup.psfhosted.org>
Message-ID: <1587672643.77.0.719381619137.issue40368@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> `os.path.abspath(".")` returned 
> `'c:\\Users\\Kagami\\Documents\\GitHub\\gecko-dev'`. 
> Should `ntpath.normpaoh` make the drive letter uppercase?

ntpath.abspath and ntpath.normpath should preserve the input case for all components of a path because they don't query the system for the real path. On the other hand, ntpath.realpath in 3.8+ opens the path and queries the final path from the system. 

With drive-relative paths, ntpath.abspath does upper-case the drive letter. That's due to the underlying GutFullPathNameW call on Windows (an API function that normalizes a path as a string-only operation). We should just leave that up to Windows instead of trying to impose consistency. The behavior could be documented, however, along with other Windows behaviors such as per-drive working directories with drive-relative paths, DOS devices (e.g. "C:/Temp/con.txt" -> r"\\.\con") and stripping of trailing dots and spaces (e.g. "C:/Temp/spam. . ." -> r"C:\Temp\spam"). These cases make ntpath.abspath(path) more complicated than just the documented equivalent of ntpath.normpath(ntpath.join(os.getcwd(), path))` on "most platforms" (i.e. most POSIX platforms -- not Windows).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40368>
_______________________________________

From report at bugs.python.org  Thu Apr 23 16:22:46 2020
From: report at bugs.python.org (Cajetan Rodrigues)
Date: Thu, 23 Apr 2020 20:22:46 +0000
Subject: [issue40340] Programming FAQ about "How do I convert a string to a
 number?" contains a typo
In-Reply-To: <1587411465.5.0.0585658579804.issue40340@roundup.psfhosted.org>
Message-ID: <1587673366.21.0.508228782601.issue40340@roundup.psfhosted.org>


Cajetan Rodrigues <caje731 at gmail.com> added the comment:

Yes, I think that's acceptable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40340>
_______________________________________

From report at bugs.python.org  Thu Apr 23 16:54:10 2020
From: report at bugs.python.org (Tim Peters)
Date: Thu, 23 Apr 2020 20:54:10 +0000
Subject: [issue40346] Add random.BaseRandom to ease implementation of
 subclasses
In-Reply-To: <1587419589.68.0.186666450831.issue40346@roundup.psfhosted.org>
Message-ID: <1587675250.5.0.0813829860991.issue40346@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

>> Making it easy to create subclasses was never a goal regardless.

> It's clearly advertised at the beginning of the documentation:
>
> "Class Random can also be subclassed if you want to use a
> different basic generator of your own devising: (...)"
>
> Do you mean that the documentation is wrong and users must
> not subclass random.Random?

I don't know about the docs, but I do know what the goals were whenever I wrote the code ;-)  It _can_ be subclassed - but so can be any class whatsoever.  There was never an intent to make usefully subclass-ing Random easy:  which is precisely what you've discovered and are attempting to improve.

Already said that's fine by me, with caveats.  It's not worth much that I can see, beyond scratching an "elegance" itch that I don't happen to have in this case.  Who subclasses Random in the real world?  Who would want to?  Python wanted to in order to add SystemRandom, and did as little as necessary to do so usefully.  A long time ago, I believe we also supplied a subclass to give results identical to Python's ancient (& long gone) Wichmann-Hill generator.

Those two are the only cases I've heard of (outside of the test suite).

Provided reworking it doesn't break working code or slow things down, I'm +0.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40346>
_______________________________________

From report at bugs.python.org  Thu Apr 23 17:02:35 2020
From: report at bugs.python.org (Zackery Spytz)
Date: Thu, 23 Apr 2020 21:02:35 +0000
Subject: [issue40150] (minor) mismatched argument in
 overlapped_RegisterWaitWithQueue call to RegisterWaitForSingleObject
In-Reply-To: <1585797239.79.0.769290971181.issue40150@roundup.psfhosted.org>
Message-ID: <1587675755.76.0.104163500227.issue40150@roundup.psfhosted.org>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
keywords: +patch
nosy: +ZackerySpytz
nosy_count: 1.0 -> 2.0
pull_requests: +19005
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19686

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40150>
_______________________________________

From report at bugs.python.org  Thu Apr 23 17:06:21 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 23 Apr 2020 21:06:21 +0000
Subject: [issue39983] test.regrtest: test marked as failed (env changed),
 but no warning: test_multiprocessing_forkserver
In-Reply-To: <1584397271.26.0.591205335177.issue39983@roundup.psfhosted.org>
Message-ID: <1587675981.27.0.271932740044.issue39983@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +19006
pull_request: https://github.com/python/cpython/pull/19687

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39983>
_______________________________________

From report at bugs.python.org  Thu Apr 23 17:21:21 2020
From: report at bugs.python.org (Michael Felt)
Date: Thu, 23 Apr 2020 21:21:21 +0000
Subject: [issue40370] AIX: ld_so_aix not found during test of
 test_peg_generator
In-Reply-To: <1587652246.66.0.023668150535.issue40370@roundup.psfhosted.org>
Message-ID: <276199FB-9401-4E28-8ACE-F73D6740D73B@felt.demon.nl>


Michael Felt <aixtools at felt.demon.nl> added the comment:

Thanks for the quick work. I?ll test with xlc as well, as the builds behave differently this afternoon. 

Sent from my iPhone

> On 23 Apr 2020, at 16:31, Pablo Galindo Salgado <report at bugs.python.org> wrote:
> 
> ?
> Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:
> 
> Tested on an AIX system:
> 
> [pablo at ibm_machine cpython (master)]$ uname -a
> AIX ibm_machine 1 7 ******* powerpc ******** AIX
> [pablo at ibm1 cpython (master)]$ ./python -m test test_peg_generator
> 0:00:00 Run tests sequentially
> 0:00:00 [1/1] test_peg_generator
> 
> == Tests result: SUCCESS ==
> 
> 1 test OK.
> 
> Total duration: 5.0 sec
> Tests result: SUCCESS
> 
> I will mark this issue as fixed as It was failing before on this machine and now the test suceeds. Feel free to reopen if is not fixes in your system :)
> 
> ----------
> resolution:  -> fixed
> stage: patch review -> resolved
> status: open -> closed
> 
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue40370>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40370>
_______________________________________

From report at bugs.python.org  Thu Apr 23 17:24:33 2020
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 23 Apr 2020 21:24:33 +0000
Subject: [issue40340] Programming FAQ about "How do I convert a string to a
 number?" contains a typo
In-Reply-To: <1587411465.5.0.0585658579804.issue40340@roundup.psfhosted.org>
Message-ID: <1587677073.14.0.441094536343.issue40340@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch
nosy: +python-dev
nosy_count: 3.0 -> 4.0
pull_requests: +19007
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19688

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40340>
_______________________________________

From report at bugs.python.org  Thu Apr 23 17:27:58 2020
From: report at bugs.python.org (Dennis Sweeney)
Date: Thu, 23 Apr 2020 21:27:58 +0000
Subject: [issue40374] collections.abc docs table: Mapping missing __reversed__
In-Reply-To: <1587657761.26.0.243868623408.issue40374@roundup.psfhosted.org>
Message-ID: <1587677278.15.0.840790535156.issue40374@roundup.psfhosted.org>


Dennis Sweeney <sweeney.dennis650 at gmail.com> added the comment:

> `Mapping.__reversed__` exists

While ``'__reversed__' in dir(Mapping)`` is true, that unfortunately does not mean that it is a real callable method:


    from collections.abc import Mapping
    class Map(Mapping):
        def __getitem__(self, x):
            if x == 42:
                return 17
            raise KeyError
        def __len__(self, x):
            return 1
        def __iter__(self):
            yield 42
		
    >>> m = Map()
    >>> reversed(m)
    Traceback (most recent call last):
    ...
    TypeError: 'Map' object is not reversible

In the code for Mapping, ``__reversed__`` is explicitly defined as None [1] so that calling ``reversed(custom_mapping)`` doesn't accidentally fall back on the sequence protocol, which would mean starting at len(custom_mapping)-1 and calling __getitem__ on each index [2], which is certainly not desirable for arbitrary mappings.

I don't think there is a reasonable way, given arbitrary implementations of __len__, __iter__, and __getitem__, to have a mixin reversed iterator.  If someone wants their mapping to have a __reversed__ method, they should define it themselves.

[1] https://github.com/python/cpython/blob/master/Lib/_collections_abc.py#L707
[2] https://docs.python.org/3/reference/datamodel.html?highlight=__reversed__#object.__reversed__

----------
nosy: +Dennis Sweeney

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40374>
_______________________________________

From report at bugs.python.org  Thu Apr 23 17:31:22 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 23 Apr 2020 21:31:22 +0000
Subject: [issue33065] IDLE debugger: failure stepping through module loading
In-Reply-To: <1520917336.65.0.467229070634.issue33065@psf.upfronthosting.co.za>
Message-ID: <1587677482.59.0.0964333693496.issue33065@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Timothy, can you try editing idlelib.debugger_r, line 173, as suggested above and see if it solves the problem?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33065>
_______________________________________

From report at bugs.python.org  Thu Apr 23 17:35:26 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 23 Apr 2020 21:35:26 +0000
Subject: [issue38546] test_concurrent_futures: reap_children() warnings on
 RHEL7 and RHEL8 buildbots
In-Reply-To: <1571656800.65.0.31860297071.issue38546@roundup.psfhosted.org>
Message-ID: <1587677726.11.0.093486573267.issue38546@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +19009
pull_request: https://github.com/python/cpython/pull/19689

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38546>
_______________________________________

From report at bugs.python.org  Thu Apr 23 17:40:00 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 23 Apr 2020 21:40:00 +0000
Subject: [issue39932] test_multiprocessing_fork leaked [0, 2,
 0] file descriptors on aarch64 RHEL8 Refleaks 3.7 buildbot
In-Reply-To: <1583927530.29.0.751848754039.issue39932@roundup.psfhosted.org>
Message-ID: <1587678000.68.0.711955339592.issue39932@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
keywords: +patch
pull_requests: +19010
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19690

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39932>
_______________________________________

From report at bugs.python.org  Thu Apr 23 17:51:20 2020
From: report at bugs.python.org (ppperry)
Date: Thu, 23 Apr 2020 21:51:20 +0000
Subject: [issue33065] IDLE debugger: failure stepping through module loading
In-Reply-To: <1520917336.65.0.467229070634.issue33065@psf.upfronthosting.co.za>
Message-ID: <1587678680.55.0.451435096419.issue33065@roundup.psfhosted.org>


Change by ppperry <mapreader at olum.org>:


----------
nosy:  -ppperry

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33065>
_______________________________________

From report at bugs.python.org  Thu Apr 23 17:52:10 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 23 Apr 2020 21:52:10 +0000
Subject: [issue40048] _PyEval_EvalFrameDefault() doesn't reset tstate->frame
 if _PyCode_InitOpcache() fails
In-Reply-To: <1584974213.54.0.484285807208.issue40048@roundup.psfhosted.org>
Message-ID: <1587678730.84.0.765949773032.issue40048@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
keywords: +patch
pull_requests: +19011
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19691

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40048>
_______________________________________

From report at bugs.python.org  Thu Apr 23 17:53:05 2020
From: report at bugs.python.org (Tim Peters)
Date: Thu, 23 Apr 2020 21:53:05 +0000
Subject: [issue40217] The garbage collector doesn't take in account that
 objects of heap allocated types hold a strong reference to their type
In-Reply-To: <1586276621.78.0.843757244355.issue40217@roundup.psfhosted.org>
Message-ID: <1587678785.66.0.533142755998.issue40217@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

There is no possible world in which the best answer is "hack gcmodule.c" ;-)

I haven't tried to dig into the details here, but Pablo's approach looked spot-on to me:  put the solution near the source of the problem.  The problem is specific to a relatively tiny number of objects, and all gc asks is that they play by the rules.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40217>
_______________________________________

From report at bugs.python.org  Thu Apr 23 17:55:13 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 23 Apr 2020 21:55:13 +0000
Subject: [issue39983] test.regrtest: test marked as failed (env changed),
 but no warning: test_multiprocessing_forkserver
In-Reply-To: <1584397271.26.0.591205335177.issue39983@roundup.psfhosted.org>
Message-ID: <1587678913.98.0.368254673501.issue39983@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 3340b2a61b458e7087c8c5fea063b1b45e1a4a07 by Victor Stinner in branch '3.8':
bpo-39983: Add test.support.print_warning() (GH-19683) (GH-19687)
https://github.com/python/cpython/commit/3340b2a61b458e7087c8c5fea063b1b45e1a4a07


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39983>
_______________________________________

From report at bugs.python.org  Thu Apr 23 18:06:07 2020
From: report at bugs.python.org (Timothy Geiser)
Date: Thu, 23 Apr 2020 22:06:07 +0000
Subject: [issue33065] IDLE debugger: failure stepping through module loading
In-Reply-To: <1520917336.65.0.467229070634.issue33065@psf.upfronthosting.co.za>
Message-ID: <1587679567.42.0.917803814158.issue33065@roundup.psfhosted.org>


Timothy Geiser <slimshady007 at inbox.lv> added the comment:

Looks good when testing both the minimal example and the pgpdump original case.

I added the import at the top, and changed the original line 173 from

value = repr(value)

to

value = reprlib.repr(value)

This is based on lines 160 & 161 in reprlib (we need a Repr instance, but reprlib makes it's own for us to use).

I get a nice boring and not-crashy result in the debug window for Locals:

data   b''
self   <BinaryData instance at 0x2726a0ab880>

Thanks for the fix, Terry!
I shouldn't expect any strange side-effects from this, should I?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33065>
_______________________________________

From report at bugs.python.org  Thu Apr 23 18:20:04 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 23 Apr 2020 22:20:04 +0000
Subject: [issue39932] test_multiprocessing_fork leaked [0, 2,
 0] file descriptors on aarch64 RHEL8 Refleaks 3.7 buildbot
In-Reply-To: <1583927530.29.0.751848754039.issue39932@roundup.psfhosted.org>
Message-ID: <1587680404.93.0.676364676357.issue39932@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 857d573257ab150d6bea666354312a5fd284b171 by Victor Stinner in branch '3.7':
bpo-39932: Fix multiprocessing test_heap() (GH-19690)
https://github.com/python/cpython/commit/857d573257ab150d6bea666354312a5fd284b171


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39932>
_______________________________________

From report at bugs.python.org  Thu Apr 23 18:20:04 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 23 Apr 2020 22:20:04 +0000
Subject: [issue32759] multiprocessing.Array do not release shared memory
In-Reply-To: <1517692462.01.0.467229070634.issue32759@psf.upfronthosting.co.za>
Message-ID: <1587680404.63.0.461708394113.issue32759@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 857d573257ab150d6bea666354312a5fd284b171 by Victor Stinner in branch '3.7':
bpo-39932: Fix multiprocessing test_heap() (GH-19690)
https://github.com/python/cpython/commit/857d573257ab150d6bea666354312a5fd284b171


----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32759>
_______________________________________

From report at bugs.python.org  Thu Apr 23 18:20:36 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 23 Apr 2020 22:20:36 +0000
Subject: [issue39932] test_multiprocessing_fork leaked [0, 2,
 0] file descriptors on aarch64 RHEL8 Refleaks 3.7 buildbot
In-Reply-To: <1583927530.29.0.751848754039.issue39932@roundup.psfhosted.org>
Message-ID: <1587680436.53.0.485531850988.issue39932@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39932>
_______________________________________

From report at bugs.python.org  Thu Apr 23 18:21:14 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 23 Apr 2020 22:21:14 +0000
Subject: [issue40334] PEP 617: new PEG-based parser
In-Reply-To: <1587327377.33.0.614039250584.issue40334@roundup.psfhosted.org>
Message-ID: <1587680474.48.0.945811291471.issue40334@roundup.psfhosted.org>


Change by Guido van Rossum <guido at python.org>:


----------
pull_requests: +19012
pull_request: https://github.com/python/cpython/pull/19692

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40334>
_______________________________________

From report at bugs.python.org  Thu Apr 23 18:40:39 2020
From: report at bugs.python.org (Sadhana Srinivasan)
Date: Thu, 23 Apr 2020 22:40:39 +0000
Subject: [issue26543] [EASY] imaplib noop Debug: bytes vs Unicode bug in debug
 mode
In-Reply-To: <1457738623.54.0.0867122071018.issue26543@psf.upfronthosting.co.za>
Message-ID: <1587681639.57.0.44241924676.issue26543@roundup.psfhosted.org>


Change by Sadhana Srinivasan <sadhanasrinivasan at pm.me>:


----------
nosy: +rotuna
nosy_count: 9.0 -> 10.0
pull_requests: +19013
pull_request: https://github.com/python/cpython/pull/19693

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26543>
_______________________________________

From report at bugs.python.org  Thu Apr 23 18:43:02 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 23 Apr 2020 22:43:02 +0000
Subject: [issue40334] PEP 617: new PEG-based parser
In-Reply-To: <1587327377.33.0.614039250584.issue40334@roundup.psfhosted.org>
Message-ID: <1587681782.7.0.261156102524.issue40334@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:


New changeset bc28805570ae3e8835a5d502ae9ab15c52449f77 by Guido van Rossum in branch 'master':
bpo-40334: Use old compiler when compile mode is func_type (GH-19692)
https://github.com/python/cpython/commit/bc28805570ae3e8835a5d502ae9ab15c52449f77


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40334>
_______________________________________

From report at bugs.python.org  Thu Apr 23 18:44:12 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 23 Apr 2020 22:44:12 +0000
Subject: [issue38546] test_concurrent_futures: reap_children() warnings on
 RHEL7 and RHEL8 buildbots
In-Reply-To: <1571656800.65.0.31860297071.issue38546@roundup.psfhosted.org>
Message-ID: <1587681852.16.0.943703848084.issue38546@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset fd32a0e2ee445dd7156323d216627112e66b0a69 by Victor Stinner in branch '3.7':
[3.7] bpo-38546: Backport multiprocessing tests fixes from master (GH-19689)
https://github.com/python/cpython/commit/fd32a0e2ee445dd7156323d216627112e66b0a69


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38546>
_______________________________________

From report at bugs.python.org  Thu Apr 23 18:44:12 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 23 Apr 2020 22:44:12 +0000
Subject: [issue37421] Some tests leak temporary files
In-Reply-To: <1561588455.96.0.166877646344.issue37421@roundup.psfhosted.org>
Message-ID: <1587681852.22.0.976015652029.issue37421@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset fd32a0e2ee445dd7156323d216627112e66b0a69 by Victor Stinner in branch '3.7':
[3.7] bpo-38546: Backport multiprocessing tests fixes from master (GH-19689)
https://github.com/python/cpython/commit/fd32a0e2ee445dd7156323d216627112e66b0a69


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37421>
_______________________________________

From report at bugs.python.org  Thu Apr 23 18:57:52 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 23 Apr 2020 22:57:52 +0000
Subject: [issue40334] PEP 617: new PEG-based parser
In-Reply-To: <1587327377.33.0.614039250584.issue40334@roundup.psfhosted.org>
Message-ID: <1587682672.66.0.142549425482.issue40334@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I don't see any mention of the PEP 617 in What's New in Python 3.9:
https://docs.python.org/dev/whatsnew/3.9.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40334>
_______________________________________

From report at bugs.python.org  Thu Apr 23 19:04:03 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 23 Apr 2020 23:04:03 +0000
Subject: [issue39674] Keep deprecated features in Python 3.9 to ease migration
 from Python 2.7, but remove in Python 3.10
In-Reply-To: <1582025189.05.0.731615044433.issue39674@roundup.psfhosted.org>
Message-ID: <1587683043.25.0.78289497288.issue39674@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I close this issue.

So far, it seems like the number of incompatible changes in Python 3.9 is reasonable. If more incompatible changes should be reverted, I suggest to open new issues.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39674>
_______________________________________

From report at bugs.python.org  Thu Apr 23 19:05:04 2020
From: report at bugs.python.org (Lysandros Nikolaou)
Date: Thu, 23 Apr 2020 23:05:04 +0000
Subject: [issue40334] PEP 617: new PEG-based parser
In-Reply-To: <1587327377.33.0.614039250584.issue40334@roundup.psfhosted.org>
Message-ID: <1587683104.53.0.526189517587.issue40334@roundup.psfhosted.org>


Change by Lysandros Nikolaou <lisandrosnik at gmail.com>:


----------
pull_requests: +19014
pull_request: https://github.com/python/cpython/pull/19694

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40334>
_______________________________________

From report at bugs.python.org  Thu Apr 23 19:09:36 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 23 Apr 2020 23:09:36 +0000
Subject: [issue40334] PEP 617: new PEG-based parser
In-Reply-To: <1587327377.33.0.614039250584.issue40334@roundup.psfhosted.org>
Message-ID: <1587683376.2.0.466862661316.issue40334@roundup.psfhosted.org>


Change by Guido van Rossum <guido at python.org>:


----------
pull_requests: +19015
pull_request: https://github.com/python/cpython/pull/19695

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40334>
_______________________________________

From report at bugs.python.org  Thu Apr 23 19:27:51 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 23 Apr 2020 23:27:51 +0000
Subject: [issue38061] FreeBSD: Optimize subprocess.Popen(close_fds=True) using
 closefrom()
In-Reply-To: <1568013936.15.0.668992536534.issue38061@roundup.psfhosted.org>
Message-ID: <1587684471.97.0.498743009952.issue38061@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
keywords: +patch
pull_requests: +19016
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19696

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38061>
_______________________________________

From report at bugs.python.org  Thu Apr 23 19:53:36 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 23 Apr 2020 23:53:36 +0000
Subject: [issue40334] PEP 617: new PEG-based parser
In-Reply-To: <1587327377.33.0.614039250584.issue40334@roundup.psfhosted.org>
Message-ID: <1587686016.41.0.7007755496.issue40334@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset 50f28dea32c45e1a49b3bd07c874b4fa837a5e88 by Pablo Galindo in branch 'master':
bpo-40334: Allow to run make regen-pegen without distutils (GH-19684)
https://github.com/python/cpython/commit/50f28dea32c45e1a49b3bd07c874b4fa837a5e88


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40334>
_______________________________________

From report at bugs.python.org  Thu Apr 23 19:59:36 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 23 Apr 2020 23:59:36 +0000
Subject: [issue38061] FreeBSD: Optimize subprocess.Popen(close_fds=True) using
 closefrom()
In-Reply-To: <1568013936.15.0.668992536534.issue38061@roundup.psfhosted.org>
Message-ID: <1587686376.2.0.906678794403.issue38061@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +19017
pull_request: https://github.com/python/cpython/pull/19697

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38061>
_______________________________________

From report at bugs.python.org  Thu Apr 23 20:14:28 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 24 Apr 2020 00:14:28 +0000
Subject: [issue38061] FreeBSD: Optimize subprocess.Popen(close_fds=True) using
 closefrom()
In-Reply-To: <1568013936.15.0.668992536534.issue38061@roundup.psfhosted.org>
Message-ID: <1587687268.36.0.0915334562056.issue38061@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Links to the FreeBSD downstream patches:

* https://reviews.freebsd.org/rP518640
* https://svnweb.freebsd.org/ports?view=revision&revision=518640
* https://svnweb.freebsd.org/ports/head/lang/python38/files/
* https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242274
* "Patches based on emaste/cem contributions in PR 221700." wrote Kyle Evans in the bugzilla issue
* "cem" is Conrad Meyer: https://reviews.freebsd.org/p/cem/
* "emaste" is Ed Maste: https://reviews.freebsd.org/p/emaste/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38061>
_______________________________________

From report at bugs.python.org  Thu Apr 23 20:28:51 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 24 Apr 2020 00:28:51 +0000
Subject: [issue37790] subprocess.Popen() is extremely slow (with
 close_fds=True which is the default) on Illumos
In-Reply-To: <1565210160.36.0.538688157223.issue37790@roundup.psfhosted.org>
Message-ID: <1587688131.57.0.424546318874.issue37790@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> We've moved illumos-gate wsdiff python tool from Python 2 to Python 3.

I guess that you're talking about https://github.com/illumos/illumos-gate/blob/master/usr/src/tools/scripts/wsdiff.py

This project is part of illumos: "An open-source Unix operating system". It's a fork of Solaris.

Python does not officially support Solaris not Illumos. If someone provides a patch, we can review it. But I'm not aware of anyone working actively on supporting Illumos.

In the meanwhile, there are two workarounds:

* Use subprocess.Popen(close_fds=False): it should be safe since PEP 446 has been implemented in Python 3.4... except for C extension modules and C libraries which don't implement it.
* Reduce the maximum number of file descriptors.

On Linux and FreeBSD (if fdescfs kernel module is loaded and mounted), Python 3 iterates on /proc/self/fd/. On FreeBSD, the closefrom() syscall can be used: PR 19697. But I'm not aware of any more efficient solution for Illumos.

Since the latest comment of the original poster was last August, I close the issue.

----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed
title: subprocess.Popen() is extremely slow -> subprocess.Popen() is extremely slow (with close_fds=True which is the default) on Illumos

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37790>
_______________________________________

From report at bugs.python.org  Thu Apr 23 20:29:24 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 24 Apr 2020 00:29:24 +0000
Subject: [issue1663329] subprocess/popen close_fds perform poor if SC_OPEN_MAX
 is hi
Message-ID: <1587688164.16.0.428113009084.issue1663329@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
resolution: accepted -> fixed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1663329>
_______________________________________

From report at bugs.python.org  Thu Apr 23 20:34:00 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 24 Apr 2020 00:34:00 +0000
Subject: [issue38061] FreeBSD: Optimize subprocess.Popen(close_fds=True) using
 closefrom()
In-Reply-To: <1568013936.15.0.668992536534.issue38061@roundup.psfhosted.org>
Message-ID: <1587688440.94.0.85595855787.issue38061@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Copy of the very interesting https://svnweb.freebsd.org/ports?view=revision&revision=518640 commit message by koobs:


Log Message: 	

lang/python{27,35,36,37,38}: Add closefrom(2) support

A single close(fd) syscall is cheap, but when MAXFDS (maximum file
descriptor number) is high, the loop calling close(fd) on each file
descriptor can take several milliseconds.

The default value of subprocess.Popen "close_fds" parameter changed to True
in Python 3. Compared to Python 2, close_fds=True can make Popen 10x
slower: see bpo-37790 [1]

The present workaround on FreeBSD to improve performance is to load and
mount the fdescfs kernel module, but this is not enabled by default.

This change adds minimum viable (and upstreamable) closefrom(2) syscall
support to Python's subprocess and posix modules, improving performance
significantly for loads that involve working with many processes, such as
diffoscope, ansible, and many others.

For additional optimizations, upstream recently (3.8) landed posix_spawn(2)
support [3] and has stated that they will adopt close_range(2) after Linux
merges it [4]. Linux/FreeBSD developers are already collaborating on
ensuring compatible implementations, with FreeBSD's implementation pending
in D21627. [5]

Thank you emaste, cem, kevans for providing analysis, input,
clarifications, comms/upstream support and patches.

[1] https://bugs.python.org/issue37790
[2] https://bugs.python.org/issue38061
[3] https://bugs.python.org/issue35537
[4] https://lwn.net/Articles/789023/
[5] https://reviews.freebsd.org/D21627

Additional References:

https://bugs.python.org/issue8052
https://bugs.python.org/issue11284
https://bugs.python.org/issue13788
https://bugs.python.org/issue1663329
https://www.python.org/dev/peps/pep-0446/

PR:		242274, 221700
Submitted by:	kevans (emaste, cem)
Approved by:	koobs (python (maintainer), santa)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38061>
_______________________________________

From report at bugs.python.org  Thu Apr 23 20:43:22 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 24 Apr 2020 00:43:22 +0000
Subject: [issue40048] _PyEval_EvalFrameDefault() doesn't reset tstate->frame
 if _PyCode_InitOpcache() fails
In-Reply-To: <1584974213.54.0.484285807208.issue40048@roundup.psfhosted.org>
Message-ID: <1587689002.22.0.995575591252.issue40048@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 25104949a5a60ff86c10691e184ce2ecb500159b by Victor Stinner in branch 'master':
bpo-40048: Fix _PyCode_InitOpcache() error path (GH-19691)
https://github.com/python/cpython/commit/25104949a5a60ff86c10691e184ce2ecb500159b


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40048>
_______________________________________

From report at bugs.python.org  Thu Apr 23 20:44:33 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 24 Apr 2020 00:44:33 +0000
Subject: [issue40048] _PyEval_EvalFrameDefault() doesn't reset tstate->frame
 if _PyCode_InitOpcache() fails
In-Reply-To: <1584974213.54.0.484285807208.issue40048@roundup.psfhosted.org>
Message-ID: <1587689073.74.0.751515696002.issue40048@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +19018
pull_request: https://github.com/python/cpython/pull/19698

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40048>
_______________________________________

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: [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  Thu Apr 23 20:56:33 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 24 Apr 2020 00:56:33 +0000
Subject: [issue39983] test.regrtest: test marked as failed (env changed),
 but no warning: test_multiprocessing_forkserver
In-Reply-To: <1584397271.26.0.591205335177.issue39983@roundup.psfhosted.org>
Message-ID: <1587689793.7.0.330990449263.issue39983@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Oh nice, my fix worked as expected: "Warning -- Unraisable exception" was logged! But the unraisable exception itself was not logged.

https://buildbot.python.org/all/#/builders/612/builds/292

0:04:02 load avg: 8.11 [421/423/1] test_concurrent_futures failed (env changed) (3 min 39 sec) -- running: test_peg_generator (2 min 3 sec)
Warning -- Unraisable exception
test_cancel (test.test_concurrent_futures.FutureTests) ... ok
test_cancelled (test.test_concurrent_futures.FutureTests) ... ok
(...)
test_first_exception_some_already_complete (test.test_concurrent_futures.ThreadPoolWaitTests) ... ok
test_pending_calls_race (test.test_concurrent_futures.ThreadPoolWaitTests) ... ok
test_timeout (test.test_concurrent_futures.ThreadPoolWaitTests) ... ok

----------------------------------------------------------------------

Ran 193 tests in 219.248s

OK (skipped=6)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39983>
_______________________________________

From report at bugs.python.org  Thu Apr 23 21:07:27 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 24 Apr 2020 01:07:27 +0000
Subject: [issue40048] _PyEval_EvalFrameDefault() doesn't reset tstate->frame
 if _PyCode_InitOpcache() fails
In-Reply-To: <1584974213.54.0.484285807208.issue40048@roundup.psfhosted.org>
Message-ID: <1587690447.22.0.761180025222.issue40048@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset d9df63deab78f70061a5a24c1f92e6d389fc45f7 by Victor Stinner in branch '3.8':
bpo-40048: Fix _PyCode_InitOpcache() error path (GH-19691) (GH-19698)
https://github.com/python/cpython/commit/d9df63deab78f70061a5a24c1f92e6d389fc45f7


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40048>
_______________________________________

From report at bugs.python.org  Thu Apr 23 21:07:43 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 24 Apr 2020 01:07:43 +0000
Subject: [issue40048] _PyEval_EvalFrameDefault() doesn't reset tstate->frame
 if _PyCode_InitOpcache() fails
In-Reply-To: <1584974213.54.0.484285807208.issue40048@roundup.psfhosted.org>
Message-ID: <1587690463.68.0.664784181394.issue40048@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Thanks for the review Pablo ;-)

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40048>
_______________________________________

From report at bugs.python.org  Thu Apr 23 21:14:15 2020
From: report at bugs.python.org (Jack Wong)
Date: Fri, 24 Apr 2020 01:14:15 +0000
Subject: [issue39645] Expand concurrent.futures.Future's public API
In-Reply-To: <1581838685.03.0.542500965222.issue39645@roundup.psfhosted.org>
Message-ID: <1587690855.68.0.80352626499.issue39645@roundup.psfhosted.org>


Change by Jack Wong <ajackwong at gmail.com>:


----------
nosy: +iforapsy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39645>
_______________________________________

From report at bugs.python.org  Thu Apr 23 22:27:18 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 24 Apr 2020 02:27:18 +0000
Subject: [issue39983] test.regrtest: test marked as failed (env changed),
 but no warning: test_multiprocessing_forkserver
In-Reply-To: <1584397271.26.0.591205335177.issue39983@roundup.psfhosted.org>
Message-ID: <1587695238.69.0.192461058087.issue39983@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

test_concurrent_futures "unraisable exception" may be bpo-39995.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39983>
_______________________________________

From report at bugs.python.org  Thu Apr 23 22:33:26 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 24 Apr 2020 02:33:26 +0000
Subject: [issue40334] PEP 617: new PEG-based parser
In-Reply-To: <1587327377.33.0.614039250584.issue40334@roundup.psfhosted.org>
Message-ID: <1587695606.18.0.254031846518.issue40334@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

test_peg_generator leaks references.

Example with s390x RHEL8 Refleaks 3.x:
https://buildbot.python.org/all/#builders/536/builds/67

test_peg_generator leaked [24246, 24242, 24246] references, sum=72734
test_peg_generator leaked [10928, 10926, 10928] memory blocks, sum=32782


The following test is enough to trigger a leak:

$ ./python -m test -R 3:3 test_peg_generator -m test.test_peg_generator.test_c_parser.TestCParser.test_error_in_rules

0:00:00 load avg: 0.94 Run tests sequentially
0:00:00 load avg: 0.94 [1/1] test_peg_generator
beginning 6 repetitions
123456
......
test_peg_generator leaked [55, 55, 55] references, sum=165
test_peg_generator leaked [19, 19, 19] memory blocks, sum=57
test_peg_generator failed

== Tests result: FAILURE ==

1 test failed:
    test_peg_generator

Total duration: 10.8 sec
Tests result: FAILURE

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40334>
_______________________________________

From report at bugs.python.org  Thu Apr 23 23:56:20 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 24 Apr 2020 03:56:20 +0000
Subject: [issue40334] PEP 617: new PEG-based parser
In-Reply-To: <1587695606.18.0.254031846518.issue40334@roundup.psfhosted.org>
Message-ID: <CAP7+vJ+4sQosY1ykRrWzSHHeTGgO3cVroMah66rdSP2iNzE8ew@mail.gmail.com>


Guido van Rossum <guido at python.org> added the comment:

Yeah that's why we have a PR out to delete or skip this test. Pablo and
Lysandros will deal with it tomorrow.

On Thu, Apr 23, 2020 at 19:33 STINNER Victor <report at bugs.python.org> wrote:

>
> STINNER Victor <vstinner at python.org> added the comment:
>
> test_peg_generator leaks references.
>
> Example with s390x RHEL8 Refleaks 3.x:
> https://buildbot.python.org/all/#builders/536/builds/67
>
> test_peg_generator leaked [24246, 24242, 24246] references, sum=72734
> test_peg_generator leaked [10928, 10926, 10928] memory blocks, sum=32782
>
>
> The following test is enough to trigger a leak:
>
> $ ./python -m test -R 3:3 test_peg_generator -m
> test.test_peg_generator.test_c_parser.TestCParser.test_error_in_rules
>
> 0:00:00 load avg: 0.94 Run tests sequentially
> 0:00:00 load avg: 0.94 [1/1] test_peg_generator
> beginning 6 repetitions
> 123456
> ......
> test_peg_generator leaked [55, 55, 55] references, sum=165
> test_peg_generator leaked [19, 19, 19] memory blocks, sum=57
> test_peg_generator failed
>
> == Tests result: FAILURE ==
>
> 1 test failed:
>     test_peg_generator
>
> Total duration: 10.8 sec
> Tests result: FAILURE
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue40334>
> _______________________________________
>
-- 
--Guido (mobile)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40334>
_______________________________________

From report at bugs.python.org  Fri Apr 24 01:53:12 2020
From: report at bugs.python.org (Glyph Lefkowitz)
Date: Fri, 24 Apr 2020 05:53:12 +0000
Subject: [issue11654] errors in atexit hooks don't change process exit code
In-Reply-To: <1300912017.1.0.699282992507.issue11654@psf.upfronthosting.co.za>
Message-ID: <1587707592.46.0.578717740821.issue11654@roundup.psfhosted.org>


Glyph Lefkowitz <glyph at twistedmatrix.com> added the comment:

I hope nobody will mind if I close: It's a duplicate of issue1257 so future discussion, if any, should probably happen there.

----------
nosy: +glyph
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue11654>
_______________________________________

From report at bugs.python.org  Fri Apr 24 03:29:20 2020
From: report at bugs.python.org (Jim DeLaHunt)
Date: Fri, 24 Apr 2020 07:29:20 +0000
Subject: [issue36675] Doctest directives and comments missing from code samples
In-Reply-To: <1555757030.56.0.8094269644.issue36675@roundup.psfhosted.org>
Message-ID: <1587713360.28.0.642768891897.issue36675@roundup.psfhosted.org>


Jim DeLaHunt <from+python at jdlh.com> added the comment:

We discovered and fixed this same problem back in 2011-2012 with #12947 . 

That was apparently the source of the monkeypatch that was removed as "obselete code" on 2019-09-12. That old issue commentary has some suggestions about other workarounds. This includes adding explanatory text about the fact that doctest directives are missing from the examples which should be showing them. Maybe some of those workarounds would be effective for us now.

----------
nosy: +JDLH

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36675>
_______________________________________

From report at bugs.python.org  Fri Apr 24 04:08:10 2020
From: report at bugs.python.org (Kjell Braden)
Date: Fri, 24 Apr 2020 08:08:10 +0000
Subject: [issue39148] DatagramProtocol + IPv6 does not work with
 ProactorEventLoop
In-Reply-To: <1577530511.62.0.532247879973.issue39148@roundup.psfhosted.org>
Message-ID: <1587715690.4.0.694151757781.issue39148@roundup.psfhosted.org>


Kjell Braden <k.python at brdn.eu> added the comment:

Fair enough, PR updated.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39148>
_______________________________________

From report at bugs.python.org  Fri Apr 24 04:14:10 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 24 Apr 2020 08:14:10 +0000
Subject: [issue40346] Add random.BaseRandom to ease implementation of
 subclasses
In-Reply-To: <1587419589.68.0.186666450831.issue40346@roundup.psfhosted.org>
Message-ID: <1587716050.83.0.854540449939.issue40346@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

[Tim]

> Who subclasses Random in the real world?  Who would want to?

Um. Me?

Or at least, I *wanted* to, when I was playing around with PCG. (See https://github.com/mdickinson/pcgrandom.) But after running into the same inelegancies (please note that I'm not calling them *issues*) as Victor, I decided to avoid the subclassing. That led to other inelegancies, like have to reproduce the code for all the various distribution sampling methods (beta, gamma, ...).  But I'm okay with that; this was just a toy project.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40346>
_______________________________________

From report at bugs.python.org  Fri Apr 24 04:15:15 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 24 Apr 2020 08:15:15 +0000
Subject: [issue40346] Add random.BaseRandom to ease implementation of
 subclasses
In-Reply-To: <1587419589.68.0.186666450831.issue40346@roundup.psfhosted.org>
Message-ID: <1587716115.1.0.926503597084.issue40346@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Whoops. I thought the URL highlighter would be clever enough not to include the period. That URL is: https://github.com/mdickinson/pcgrandom

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40346>
_______________________________________

From report at bugs.python.org  Fri Apr 24 04:16:38 2020
From: report at bugs.python.org (=?utf-8?q?Alex_Gr=C3=B6nholm?=)
Date: Fri, 24 Apr 2020 08:16:38 +0000
Subject: [issue39148] DatagramProtocol + IPv6 does not work with
 ProactorEventLoop
In-Reply-To: <1577530511.62.0.532247879973.issue39148@roundup.psfhosted.org>
Message-ID: <1587716198.22.0.83510288998.issue39148@roundup.psfhosted.org>


Alex Gr?nholm <alex.gronholm at nextday.fi> added the comment:

Thanks, looks good to me now!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39148>
_______________________________________

From report at bugs.python.org  Fri Apr 24 04:21:29 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 24 Apr 2020 08:21:29 +0000
Subject: [issue40346] Add random.BaseRandom to ease implementation of
 subclasses
In-Reply-To: <1587419589.68.0.186666450831.issue40346@roundup.psfhosted.org>
Message-ID: <1587716489.66.0.524707071015.issue40346@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> it may be worth looking at the recent Numpy changes

Agreed: I do like the NumPy composition model (the random state object _has_ a bit generator, rather than _being_ an extended bit generator).

With the various competing options and the lack of agreement on what (if anything) should be done, this feels like PEP territory.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40346>
_______________________________________

From report at bugs.python.org  Fri Apr 24 05:25:27 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 24 Apr 2020 09:25:27 +0000
Subject: [issue40346] Add random.BaseRandom to ease implementation of
 subclasses
In-Reply-To: <1587419589.68.0.186666450831.issue40346@roundup.psfhosted.org>
Message-ID: <1587720327.4.0.90324384859.issue40346@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +19019
pull_request: https://github.com/python/cpython/pull/19700

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40346>
_______________________________________

From report at bugs.python.org  Fri Apr 24 05:29:32 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 24 Apr 2020 09:29:32 +0000
Subject: [issue40346] Add random.BaseRandom to ease implementation of
 subclasses
In-Reply-To: <1587419589.68.0.186666450831.issue40346@roundup.psfhosted.org>
Message-ID: <1587720572.49.0.544151218189.issue40346@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I created this issue to address Raymond's comment:
"The randbytes() method needs to depend on genrandbits()."
https://bugs.python.org/issue40286#msg366860

I wrote PR 19700 to address that and only that.

With PR 19700, Random subclasses get a randbytes() implementation which uses getrandbits().

*Maybe* we could do the same in Random subclasses for the random() method, so let's start with the simplest PR :-)

Let's fix the randbytes() issue first.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40346>
_______________________________________

From report at bugs.python.org  Fri Apr 24 05:32:37 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 24 Apr 2020 09:32:37 +0000
Subject: [issue40286] Add randbytes() method to random.Random
In-Reply-To: <1586903418.02.0.530735802731.issue40286@roundup.psfhosted.org>
Message-ID: <1587720757.82.0.468537028351.issue40286@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Raymond:
> The randbytes() method needs to depend on genrandbits().

I created PR 19700 which allows to keep the optimization (C implementation in _randommodule.c) and Random subclasses implement randbytes() with getrandbits().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40286>
_______________________________________

From report at bugs.python.org  Fri Apr 24 05:43:37 2020
From: report at bugs.python.org (John Levon)
Date: Fri, 24 Apr 2020 09:43:37 +0000
Subject: [issue37790] subprocess.Popen() is extremely slow (with
 close_fds=True which is the default) on Illumos
In-Reply-To: <1565210160.36.0.538688157223.issue37790@roundup.psfhosted.org>
Message-ID: <1587721417.27.0.0033109908357.issue37790@roundup.psfhosted.org>


John Levon <movement at users.sourceforge.net> added the comment:

closefrom() is on both Solaris and illumos too - and might even have originated there as an API -  so if that's the issue, it should be trivially fixable

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37790>
_______________________________________

From report at bugs.python.org  Fri Apr 24 05:53:28 2020
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 24 Apr 2020 09:53:28 +0000
Subject: [issue37790] subprocess.Popen() is extremely slow (with
 close_fds=True which is the default) on Illumos
In-Reply-To: <1565210160.36.0.538688157223.issue37790@roundup.psfhosted.org>
Message-ID: <1587722008.38.0.464865909019.issue37790@roundup.psfhosted.org>


Antoine Pitrou <solipsis at pitrou.net> added the comment:

I think we would accept a PR since it would probably be trivial, but someone has to submit it :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37790>
_______________________________________

From report at bugs.python.org  Fri Apr 24 06:00:55 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 24 Apr 2020 10:00:55 +0000
Subject: [issue38061] FreeBSD: Optimize subprocess.Popen(close_fds=True) using
 closefrom()
In-Reply-To: <1568013936.15.0.668992536534.issue38061@roundup.psfhosted.org>
Message-ID: <1587722455.35.0.37680906296.issue38061@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 162c567d164b5742c0d1f3f8bd8c8bab9c117cd0 by Victor Stinner in branch 'master':
bpo-38061: os.closerange() uses closefrom() on FreeBSD (GH-19696)
https://github.com/python/cpython/commit/162c567d164b5742c0d1f3f8bd8c8bab9c117cd0


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38061>
_______________________________________

From report at bugs.python.org  Fri Apr 24 06:07:02 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 24 Apr 2020 10:07:02 +0000
Subject: [issue38061] FreeBSD: Optimize subprocess.Popen(close_fds=True) using
 closefrom()
In-Reply-To: <1568013936.15.0.668992536534.issue38061@roundup.psfhosted.org>
Message-ID: <1587722822.32.0.773710015502.issue38061@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset e6f8abd500751a834b6fff4f107ecbd29f2184fe by Victor Stinner in branch 'master':
bpo-38061: subprocess uses closefrom() on FreeBSD (GH-19697)
https://github.com/python/cpython/commit/e6f8abd500751a834b6fff4f107ecbd29f2184fe


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38061>
_______________________________________

From report at bugs.python.org  Fri Apr 24 06:09:09 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 24 Apr 2020 10:09:09 +0000
Subject: [issue37790] subprocess.Popen() is extremely slow (with
 close_fds=True which is the default) on Illumos
In-Reply-To: <1565210160.36.0.538688157223.issue37790@roundup.psfhosted.org>
Message-ID: <1587722949.52.0.711230996579.issue37790@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I merged FreeBSD changes:

New changeset 162c567d164b5742c0d1f3f8bd8c8bab9c117cd0 by Victor Stinner in branch 'master':
bpo-38061: os.closerange() uses closefrom() on FreeBSD (GH-19696)
https://github.com/python/cpython/commit/162c567d164b5742c0d1f3f8bd8c8bab9c117cd0

New changeset e6f8abd500751a834b6fff4f107ecbd29f2184fe by Victor Stinner in branch 'master':
bpo-38061: subprocess uses closefrom() on FreeBSD (GH-19697)
https://github.com/python/cpython/commit/e6f8abd500751a834b6fff4f107ecbd29f2184fe

Free feel to propose a more generic way to detect when closefrom() function is available ;-) Or just a patch to add "|| defined(sun)".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37790>
_______________________________________

From report at bugs.python.org  Fri Apr 24 06:14:59 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 24 Apr 2020 10:14:59 +0000
Subject: [issue38061] FreeBSD: Optimize subprocess.Popen(close_fds=True) using
 closefrom()
In-Reply-To: <1568013936.15.0.668992536534.issue38061@roundup.psfhosted.org>
Message-ID: <1587723299.84.0.566094347273.issue38061@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Thanks Ed Maste, Conrad Meyer, Kyle Evans and Kubilay Kocak!

I ran a benchmark:

vstinner at freebsd$ env/bin/python -m pyperf command -v -- ./python -c 'import subprocess, sys; args=[sys.executable, "-sS", "-c", "pass"]; subprocess.run(args)'

The optimization made subprocess almost 4x faster on FreeBSD!

vstinner at freebsd$ env/bin/python -m pyperf compare_to ref.json closefrom.json 
Mean +- std dev: [ref] 176 ms +- 1 ms -> [closefrom] 46.6 ms +- 1.2 ms: 3.77x faster (-74%)

129 ms were wasted in calling 229 284 times close(fd)!

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38061>
_______________________________________

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: [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 08:00:32 2020
From: report at bugs.python.org (=?utf-8?q?Jens_Holzk=C3=A4mper?=)
Date: Fri, 24 Apr 2020 12:00:32 +0000
Subject: [issue40376] documentation for os.getgrouplist potentially misleading
In-Reply-To: <1587726234.05.0.711517383833.issue40376@roundup.psfhosted.org>
Message-ID: <1587729632.42.0.977956825083.issue40376@roundup.psfhosted.org>


Change by Jens Holzk?mper <jens at holzkaemper.berlin>:


----------
keywords: +patch
pull_requests: +19020
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19702

_______________________________________
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: [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 09:27:27 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 24 Apr 2020 13:27:27 +0000
Subject: [issue40377] APPDATA location in Microsoft Store version
In-Reply-To: <1587734754.85.0.727792315124.issue40377@roundup.psfhosted.org>
Message-ID: <1587734847.47.0.111798174951.issue40377@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +steve.dower

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40377>
_______________________________________

From report at bugs.python.org  Fri Apr 24 09:30:11 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 24 Apr 2020 13:30:11 +0000
Subject: [issue9216] FIPS support for hashlib
In-Reply-To: <1278721335.16.0.522410247151.issue9216@psf.upfronthosting.co.za>
Message-ID: <1587735011.05.0.0382765269443.issue9216@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +19021
pull_request: https://github.com/python/cpython/pull/19703

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue9216>
_______________________________________

From report at bugs.python.org  Fri Apr 24 09:41:14 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 24 Apr 2020 13:41:14 +0000
Subject: [issue9216] FIPS support for hashlib
In-Reply-To: <1278721335.16.0.522410247151.issue9216@psf.upfronthosting.co.za>
Message-ID: <1587735674.26.0.337618244468.issue9216@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> I'm fine with a used_for_security flag and functions to get/set FIPS state. Something like hashlib.get_fips_mode() is useful for testing.

I proposed PR 19703 to expose OpenSSL FIPS_mode() as hashlib.get_fips_mode().

FIPS support was introduced in version 0.9.7 of OpenSSL and so is available in the minimum OpenSSL required to build Python 3.9.

LibreSSL doesn't have FIPS_mode() on purpose. Ted Unangst wrote: "I figured I should mention our current libressl policy wrt FIPS mode.  It's gone and it's not coming back."
https://marc.info/?l=openbsd-misc&m=139819485423701&w=2

My plan is to use hashlib.get_fips_mode() to skip a few tests if the FIPS mode is enabled. Simple example: test_crypt.test_methods() checks that self.assertEqual(crypt.methods[-1], crypt.METHOD_CRYPT). Except that in FIPS mode, METHOD_CRYPT is not available since it's too weak (3DES if I recall correctly). I would like to skip this test in FIPS mode.

My colleague Chalampos also plans to add a FIPS enabled buildbot running RHEL8 to ensure that the Python test suite pass in FIPS mode, and detect regressions in FIPS mode.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue9216>
_______________________________________

From report at bugs.python.org  Fri Apr 24 09:51:15 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 24 Apr 2020 13:51:15 +0000
Subject: [issue40334] PEP 617: new PEG-based parser
In-Reply-To: <1587327377.33.0.614039250584.issue40334@roundup.psfhosted.org>
Message-ID: <1587736275.61.0.522920540952.issue40334@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset 24ffe705c30e36c82940d75fd1454256634d0b3c by Lysandros Nikolaou in branch 'master':
bpo-40334: Rewrite test_c_parser to avoid memory leaks (GH-19694)
https://github.com/python/cpython/commit/24ffe705c30e36c82940d75fd1454256634d0b3c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40334>
_______________________________________

From report at bugs.python.org  Fri Apr 24 09:53:46 2020
From: report at bugs.python.org (Lysandros Nikolaou)
Date: Fri, 24 Apr 2020 13:53:46 +0000
Subject: [issue40334] PEP 617: new PEG-based parser
In-Reply-To: <1587327377.33.0.614039250584.issue40334@roundup.psfhosted.org>
Message-ID: <1587736426.74.0.755609586007.issue40334@roundup.psfhosted.org>


Lysandros Nikolaou <lisandrosnik at gmail.com> added the comment:

> test_peg_generator leaks references.

This is now fixed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40334>
_______________________________________

From report at bugs.python.org  Fri Apr 24 10:06:05 2020
From: report at bugs.python.org (Michael Felt)
Date: Fri, 24 Apr 2020 14:06:05 +0000
Subject: [issue40370] AIX: ld_so_aix not found during test of
 test_peg_generator
In-Reply-To: <1587621380.1.0.901678392936.issue40370@roundup.psfhosted.org>
Message-ID: <1587737165.18.0.919067602897.issue40370@roundup.psfhosted.org>


Michael Felt <aixtools at felt.demon.nl> added the comment:

Thanks for the quick response. I see both bots are good.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40370>
_______________________________________

From report at bugs.python.org  Fri Apr 24 10:18:41 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 24 Apr 2020 14:18:41 +0000
Subject: [issue9216] FIPS support for hashlib
In-Reply-To: <1278721335.16.0.522410247151.issue9216@psf.upfronthosting.co.za>
Message-ID: <1587737921.32.0.960684931994.issue9216@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I'm trying to understand how "portable" is it to expose OpenSSL FIPS_mode() as hashlib.get_fips_mode() which would return a boolean (True or False).

It seems like FIPS is more complex than that. Other crypto libraries which implement FIPS have a different way to expose FIPS mode to the consumer of the API:

* NSS seems to have a different API for functions in FIPS mode: https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/Reference/NSS_cryptographic_module/FIPS_mode_of_operation
* GnuTLS provides gnutls_fips140_mode_enabled() which returns an unsigned integer: "return non-zero if true or zero if false"
* Gcrypt doesn't seem to expose a function to know if FIPS is enabled or not. It also has an "Enforced FIPS" mode:

  * https://www.gnupg.org/documentation/manuals/gcrypt/Enabling-FIPS-mode.html
  * https://www.gnupg.org/documentation/manuals/gcrypt/Enabling-FIPS-mode.html

* Bouncy Castle has a "FIPS provider": an object should be requested in FIPS mode

See also RHEL 8 Security Hardening documentation, "Chapter 3. Using system-wide cryptographic policies":
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/security_hardening/using-the-system-wide-cryptographic-policies_security-hardening

For my needs (skip tests which are not relevant in FIPS mode), it seems like keeping the function private in _hashlib.get_fips_mode() is enough.

My plan is to use it in as test.support.get_fips_mode() function which would return False if _hashlib.get_fips_mode() is missing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue9216>
_______________________________________

From report at bugs.python.org  Fri Apr 24 10:35:24 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 24 Apr 2020 14:35:24 +0000
Subject: [issue9216] FIPS support for hashlib
In-Reply-To: <1278721335.16.0.522410247151.issue9216@psf.upfronthosting.co.za>
Message-ID: <1587738924.14.0.857281379094.issue9216@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Petr Viktorin and Christian Heimes convinced me that it's a bad idea to expose OpenSSL FIPS_mode() as a public hashlib.get_fips_mode() function. It is too specific to OpenSSL. For example, FIPS_mode() result is a number which is specific to OpenSSL. Other crypto libraries are likely to use different values.

Moreover, as I wrote in my previous message, other crypto libraries expose the FIPS mode differently. It may not just be a global FIPS mode.

Finally, there are different FIPS modes. For example, Gcrypt has an "Enforced FIPS" mode.

So I modified PR 19703 to only expose FIPS_mode() as a private _hashlib.get_fips_mode() function. Well, as done in RHEL in fact ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue9216>
_______________________________________

From report at bugs.python.org  Fri Apr 24 10:47:47 2020
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 24 Apr 2020 14:47:47 +0000
Subject: [issue9216] FIPS support for hashlib
In-Reply-To: <1278721335.16.0.522410247151.issue9216@psf.upfronthosting.co.za>
Message-ID: <1587739667.54.0.153608789129.issue9216@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

I'm against exposing the function as hashlib.get_fips_mode() because it is an internal implementation detail. I don't want to confuse users or make users think that "if hashlib.get_fips_mode()" is sufficient for feature tests. For starters there are multiple levels and versions of the FIPS standard like FIPS-140-2 and FIPS-140-3.

Instead if doing a FIPS test, users and applications should perform a feature test and handle the error. The approach is future-proof and can also cover crypto policies restriction like minimum key sizes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue9216>
_______________________________________

From report at bugs.python.org  Fri Apr 24 10:56:57 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 24 Apr 2020 14:56:57 +0000
Subject: [issue40334] PEP 617: new PEG-based parser
In-Reply-To: <1587327377.33.0.614039250584.issue40334@roundup.psfhosted.org>
Message-ID: <1587740217.86.0.701382098909.issue40334@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Lysandros:
> This is now fixed.

Thanks, that was quick ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40334>
_______________________________________

From report at bugs.python.org  Fri Apr 24 10:57:57 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 24 Apr 2020 14:57:57 +0000
Subject: [issue9216] FIPS support for hashlib
In-Reply-To: <1278721335.16.0.522410247151.issue9216@psf.upfronthosting.co.za>
Message-ID: <1587740277.74.0.80603281987.issue9216@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Christian Heimes: "Instead if doing a FIPS test, users and applications should perform a feature test and handle the error. The approach is future-proof and can also cover crypto policies restriction like minimum key sizes."

Alright, I see. Thanks for your explanation ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue9216>
_______________________________________

From report at bugs.python.org  Fri Apr 24 11:50:50 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Fri, 24 Apr 2020 15:50:50 +0000
Subject: [issue40375] Add the UNSELECT command to imaplib
In-Reply-To: <1587689097.33.0.419593805597.issue40375@roundup.psfhosted.org>
Message-ID: <1587743450.05.0.313856257277.issue40375@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
nosy: +corona10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40375>
_______________________________________

From report at bugs.python.org  Fri Apr 24 12:19:36 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 24 Apr 2020 16:19:36 +0000
Subject: [issue40346] Add random.BaseRandom to ease implementation of
 subclasses
In-Reply-To: <1587419589.68.0.186666450831.issue40346@roundup.psfhosted.org>
Message-ID: <1587745176.1.0.613237396222.issue40346@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Antoine:
> However, if we want to think about a new subclassing API, it may be worth looking at the recent Numpy changes. Numpy added a new random generator API recently, with a design based on composition rather than inheritance (and also they switched from Mersenne Twister to another underlying PRNG!):
> https://numpy.org/doc/stable/reference/random/index.html

Yeah, sometimes composition is simpler. My BaseRandom base class (PR 19631) can be used with composition indirectly, since all you need is to implemented getrandbits(). Example:

---
from numpy.random import default_rng
import random

class NumpyRandom(random.BaseRandom):
    def __init__(self):
        self._rng = default_rng()

    def getrandbits(self, n):
        # FIXME: support n larger than 64 ;-)
        return int(self._rng.integers(2 ** n))

gen = NumpyRandom()
print(gen.randint(1, 6))
print(gen.random())
print(gen.randbytes(3))
---

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40346>
_______________________________________

From report at bugs.python.org  Fri Apr 24 12:29:47 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 24 Apr 2020 16:29:47 +0000
Subject: [issue40346] Add random.BaseRandom to ease implementation of
 subclasses
In-Reply-To: <1587419589.68.0.186666450831.issue40346@roundup.psfhosted.org>
Message-ID: <1587745787.63.0.38666223216.issue40346@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Mark:
> With the various competing options and the lack of agreement on what (if anything) should be done, this feels like PEP territory.

Honestly, if you consider that BaseRandom base class is not worth it, I will just abandon this idea. I'm not interested to write a whole PEP just for that. (Maybe someone else is more motivated than me ;-))

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40346>
_______________________________________

From report at bugs.python.org  Fri Apr 24 12:37:45 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 24 Apr 2020 16:37:45 +0000
Subject: [issue40346] Add random.BaseRandom to ease implementation of
 subclasses
In-Reply-To: <1587419589.68.0.186666450831.issue40346@roundup.psfhosted.org>
Message-ID: <1587746265.73.0.136896936528.issue40346@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Raymond Hettinger: "It is not okay to flat out ignore the opposing comments from the module maintainers.  Being on the steering committee isn't a license to do whatever you want, ignoring published APIs, breaking user code, and ignoring other contributors.  If you want to go forward with this, there should be a PEP (and you should be recused from adjudicating it)."

That's a personal attack, would you mind to stay at the technical level, please? Thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40346>
_______________________________________

From report at bugs.python.org  Fri Apr 24 13:08:58 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 24 Apr 2020 17:08:58 +0000
Subject: [issue40346] Add random.BaseRandom to ease implementation of
 subclasses
In-Reply-To: <1587419589.68.0.186666450831.issue40346@roundup.psfhosted.org>
Message-ID: <1587748138.02.0.0704011714355.issue40346@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

[Victor]

> Honestly, if you consider that BaseRandom base class is not worth it, I will just abandon this idea.

It's not that I think it's not worth it (I'm not currently convinced either way). It's more that if we're going to make a change, then it's not clear to me that the particular choice in the BaseRandom PR is necessarily the only or best way to do it. There are a good few technical choices to be made, and I think there's value in having a wider discussion.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40346>
_______________________________________

From report at bugs.python.org  Fri Apr 24 13:10:00 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 24 Apr 2020 17:10:00 +0000
Subject: [issue40346] Add random.BaseRandom to ease implementation of
 subclasses
In-Reply-To: <1587419589.68.0.186666450831.issue40346@roundup.psfhosted.org>
Message-ID: <1587748200.8.0.528066556836.issue40346@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I see 3 options to fix randbytes() in subclasses:

(A) Remove the randbytes() optimization (C implementation): always implement it with getrandbits().

(B) Add BaseRandom base class: PR 19631.

(C) Modify __init_subclass__() to implement randbytes() with getrandbits() in subclasses: PR 19700

--

Option (A) is the simplest, but it makes randbytes() 5x slower.

Option (B) is my favorite: it keeps all random.Random optimization, it reduces SystemRandom footprint by 2 KB, it eases writing new subclasses (a single method must be defined).

Option (C) seems to be complicated to implement. I'm not sure that it does satisfy Raymond's requirements.

--

Option (A) and (C) don't solve my initial concern of this issue: it's not easy to subclass random.Random, it is still required to *override* 5 methods.

The main drawback of option (B) is that Random subclasses now inherit Random.randbytes() and so should override it which is new requirement. But technically, if Random.randbytes() is inherited: it respects its contract, it generates random bytes... it's just that it may not be the behavior expected by the developer.

My PR 19631 solves this drawback by *documenting* the new requirement in the Porting guide of What's New in Python 3.9. I'm not sure if it should be qualified as backward incompatible, but if yes, I propose to make it on purpose (other options have other drawbacks).

--

Honestly, so far, I'm confused. It's now unclear to me if subclassing the random.Random class is a supported feature and/or if we want to support it. It's also unclear to me if the performance matters in the random module. On one side, gauss() has an optimization which makes it not thread-safe, on the other side option (A) would make randbytes() 5x slower.

It's also possible to combine some options like (B)+(C) which solves the main (B) drawback.

Obviously, the last choice is to revert the randbytes() features (decide that it's no longer possible to add such new method to the random.Random because of drawbacks described in this issue).

--

Well, I proposed various options. Now I let you to decide ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40346>
_______________________________________

From report at bugs.python.org  Fri Apr 24 13:13:24 2020
From: report at bugs.python.org (Tim Peters)
Date: Fri, 24 Apr 2020 17:13:24 +0000
Subject: [issue40346] Add random.BaseRandom to ease implementation of
 subclasses
In-Reply-To: <1587419589.68.0.186666450831.issue40346@roundup.psfhosted.org>
Message-ID: <1587748404.87.0.11112973286.issue40346@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

Mark, you don't count ;-)  Neither do I.  Of course I've subclassed Random too, to experiment with other base generators (including PCG variants).  But they're throwaways, and I don't care that it can require staring at the code to make as many changes as needed.  Developers _of_ Python don't need things to be trivial to make quick progress.

So I remain where I was:  +0, provided there are no notable runtime regressions.  Nice to have (hence "+"), but don't really care if it never happens (hence "0").

As to what numpy does, I'm always in favor of following their lead when possible and Pythonic.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40346>
_______________________________________

From report at bugs.python.org  Fri Apr 24 13:15:08 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 24 Apr 2020 17:15:08 +0000
Subject: [issue40346] Add random.BaseRandom to ease implementation of
 subclasses
In-Reply-To: <1587419589.68.0.186666450831.issue40346@roundup.psfhosted.org>
Message-ID: <1587748508.6.0.410916122156.issue40346@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

[Tim]

> Mark, you don't count ;-)

Yes, I was suspecting I'd fail the "real world" test. Fair enough. :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40346>
_______________________________________

From report at bugs.python.org  Fri Apr 24 13:24:22 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 24 Apr 2020 17:24:22 +0000
Subject: [issue40346] Add random.BaseRandom to ease implementation of
 subclasses
In-Reply-To: <1587419589.68.0.186666450831.issue40346@roundup.psfhosted.org>
Message-ID: <1587749062.25.0.173814600334.issue40346@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Fun fact. When I wrote my "class NumpyRandom(random.BaseRandom):" example, I found a quite serious bug in numpy:

"default_rng.integers(2**32) always return 0"
https://github.com/numpy/numpy/issues/16066

Even numpy is not perfect yet :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40346>
_______________________________________

From report at bugs.python.org  Fri Apr 24 13:34:13 2020
From: report at bugs.python.org (Thor Whalen)
Date: Fri, 24 Apr 2020 17:34:13 +0000
Subject: [issue40374] collections.abc docs table: Mapping missing __reversed__
In-Reply-To: <1587677278.15.0.840790535156.issue40374@roundup.psfhosted.org>
Message-ID: <CANryRXA1jJ0Obj7huKaAnKYD47uqQAnc1E5mFN-KDDvNpoOCug@mail.gmail.com>


Thor Whalen <thorwhalen at gmail.com> added the comment:

Dennis,

Thanks for the (very complete) explanation. I induced to err because of the
following confusing facts:
```
from collections.abc import Mapping, Sequence
import sys
if sys.version_info <= (2, 7):
    assert '__reversed__' not in dir(Mapping)
elif sys.version_info >= (3, 7):
    assert not isinstance(Mapping, Sequence)
    assert '__reversed__' in dir(Mapping)
    assert list(reversed(dict.fromkeys('abc'))) == ['c', 'b', 'a']
    # + no mention of Mapping.__reversed__ in the docs
```
Indeed, I didn't look at the code. Thanks for that.

On Thu, Apr 23, 2020 at 5:28 PM Dennis Sweeney <report at bugs.python.org>
wrote:

>
> Dennis Sweeney <sweeney.dennis650 at gmail.com> added the comment:
>
> > `Mapping.__reversed__` exists
>
> While ``'__reversed__' in dir(Mapping)`` is true, that unfortunately does
> not mean that it is a real callable method:
>
>
>     from collections.abc import Mapping
>     class Map(Mapping):
>         def __getitem__(self, x):
>             if x == 42:
>                 return 17
>             raise KeyError
>         def __len__(self, x):
>             return 1
>         def __iter__(self):
>             yield 42
>
>     >>> m = Map()
>     >>> reversed(m)
>     Traceback (most recent call last):
>     ...
>     TypeError: 'Map' object is not reversible
>
> In the code for Mapping, ``__reversed__`` is explicitly defined as None
> [1] so that calling ``reversed(custom_mapping)`` doesn't accidentally fall
> back on the sequence protocol, which would mean starting at
> len(custom_mapping)-1 and calling __getitem__ on each index [2], which is
> certainly not desirable for arbitrary mappings.
>
> I don't think there is a reasonable way, given arbitrary implementations
> of __len__, __iter__, and __getitem__, to have a mixin reversed iterator.
> If someone wants their mapping to have a __reversed__ method, they should
> define it themselves.
>
> [1]
> https://github.com/python/cpython/blob/master/Lib/_collections_abc.py#L707
> [2]
> https://docs.python.org/3/reference/datamodel.html?highlight=__reversed__#object.__reversed__
>
> ----------
> nosy: +Dennis Sweeney
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue40374>
> _______________________________________
>

----------
nosy: +Thor Whalen

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40374>
_______________________________________

From report at bugs.python.org  Fri Apr 24 13:58:39 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 24 Apr 2020 17:58:39 +0000
Subject: [issue40374] collections.abc docs table: Mapping missing __reversed__
In-Reply-To: <1587657761.26.0.243868623408.issue40374@roundup.psfhosted.org>
Message-ID: <1587751119.33.0.339049085424.issue40374@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40374>
_______________________________________

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: [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:19:54 2020
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 24 Apr 2020 18:19:54 +0000
Subject: [issue40360] Deprecate lib2to3 (and 2to3) for future removal
In-Reply-To: <1587530454.25.0.44181585934.issue40360@roundup.psfhosted.org>
Message-ID: <1587752394.62.0.527228608224.issue40360@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:


New changeset 503de7149d03bdcc671dcbbb5b64f761bb192b4d by Carl Meyer in branch 'master':
bpo-40360: Deprecate lib2to3 module in light of PEP 617 (GH-19663)
https://github.com/python/cpython/commit/503de7149d03bdcc671dcbbb5b64f761bb192b4d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40360>
_______________________________________

From report at bugs.python.org  Fri Apr 24 14:21:21 2020
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 24 Apr 2020 18:21:21 +0000
Subject: [issue40360] Deprecate lib2to3 (and 2to3) for future removal
In-Reply-To: <1587530454.25.0.44181585934.issue40360@roundup.psfhosted.org>
Message-ID: <1587752481.2.0.867656802737.issue40360@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:

Okay,the pending deprecation is in.  Keeping open as a reminder to turn that into a real DeprecationWarning in 3.10 after the 3.9 branch is cut.

We'll then want to track reminding us to remove it in 3.12.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40360>
_______________________________________

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: [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 14:26:50 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 24 Apr 2020 18:26:50 +0000
Subject: [issue40334] PEP 617: new PEG-based parser
In-Reply-To: <1587327377.33.0.614039250584.issue40334@roundup.psfhosted.org>
Message-ID: <1587752810.67.0.0628127660116.issue40334@roundup.psfhosted.org>


Change by Guido van Rossum <guido at python.org>:


----------
pull_requests: +19022
pull_request: https://github.com/python/cpython/pull/19704

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40334>
_______________________________________

From report at bugs.python.org  Fri Apr 24 14:31:05 2020
From: report at bugs.python.org (Itamar Turner-Trauring)
Date: Fri, 24 Apr 2020 18:31:05 +0000
Subject: [issue40379] multiprocessing's default start method of
 fork()-without-exec() is broken
In-Reply-To: <1587752543.41.0.119768714545.issue40379@roundup.psfhosted.org>
Message-ID: <1587753065.61.0.236143793503.issue40379@roundup.psfhosted.org>


Itamar Turner-Trauring <itamar at futurefoundries.com> added the comment:

Looks like as of 3.8 this only impacts Linux/non-macOS-POSIX, so I'll amend the above to say this will also make it consistent with macOS.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40379>
_______________________________________

From report at bugs.python.org  Fri Apr 24 14:32:00 2020
From: report at bugs.python.org (Tim Peters)
Date: Fri, 24 Apr 2020 18:32:00 +0000
Subject: [issue40346] Add random.BaseRandom to ease implementation of
 subclasses
In-Reply-To: <1587419589.68.0.186666450831.issue40346@roundup.psfhosted.org>
Message-ID: <1587753120.48.0.633162903784.issue40346@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

To be serious about numpy ;-) , people consuming a great many random outputs will eventually move to numpy out of necessity (speed).  So for that reason alone it's good to mimic what they do. But more fundamentally, they have more people with relevant deep knowledge contributing to the project than Python has. When, e.g., they were considering a Twister alternative, PCG's inventor contributed extensively to their discussion, and even created a new member of the PCG family to address concerns raised by numpy contributors' testing - sll _before_ it was released.

Apart from Mark chiming in, the Python project just doesn't get that level of help in these areas.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40346>
_______________________________________

From report at bugs.python.org  Fri Apr 24 15:29:41 2020
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 24 Apr 2020 19:29:41 +0000
Subject: [issue40348] Programming FAQ about "What is delegation?": Fix typos
In-Reply-To: <1587419868.54.0.356271490131.issue40348@roundup.psfhosted.org>
Message-ID: <1587756581.83.0.627996810291.issue40348@roundup.psfhosted.org>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks!  Would you like to make the changes yourself?

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40348>
_______________________________________

From report at bugs.python.org  Fri Apr 24 15:35:23 2020
From: report at bugs.python.org (Ammar Askar)
Date: Fri, 24 Apr 2020 19:35:23 +0000
Subject: [issue13645] import machinery vulnerable to timestamp collisions
In-Reply-To: <1324470738.36.0.917497036729.issue13645@psf.upfronthosting.co.za>
Message-ID: <1587756923.04.0.590078467304.issue13645@roundup.psfhosted.org>


Change by Ammar Askar <ammar at ammaraskar.com>:


----------
nosy: +ammar2
nosy_count: 8.0 -> 9.0
pull_requests: +19023
pull_request: https://github.com/python/cpython/pull/19651

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13645>
_______________________________________

From report at bugs.python.org  Fri Apr 24 15:37:51 2020
From: report at bugs.python.org (Jan Wilmans)
Date: Fri, 24 Apr 2020 19:37:51 +0000
Subject: [issue34028] Python 3.7.0 wont compile with SSL Support 1.1.0 >
 alledged missing X509_VERIFY_PARAM_set1_host() support
In-Reply-To: <1530609211.5.0.56676864532.issue34028@psf.upfronthosting.co.za>
Message-ID: <1587757071.51.0.958206332327.issue34028@roundup.psfhosted.org>


Jan Wilmans <janwilmans at gmail.com> added the comment:

I couldn't get this to work at all, python 3.7 compiled fine, but at the end it reports:

'''
*** WARNING: renaming "_ssl" since importing it failed: libssl.so.1.1: cannot open shared object file: No such file or directory
*** WARNING: renaming "_hashlib" since importing it failed: libssl.so.1.1: cannot open shared object file: No such file or directory

Python build finished successfully!

Following modules built successfully but were removed because they could not be imported:
_hashlib              _ssl                                     


Could not build the ssl module!
Python requires an OpenSSL 1.0.2 or 1.1 compatible libssl with X509_VERIFY_PARAM_set1_host().
LibreSSL 2.6.4 and earlier do not provide the necessary APIs, https://github.com/libressl-portable/portable/issues/381
'''

But in the end I got it to work like this:

----- install_python3.7.sh ---- 
#!/bin/bash
set -euo pipefail

mkdir /tmp/openssl
cd /tmp/openssl
wget https://www.openssl.org/source/openssl-1.1.1a.tar.gz
tar -xvf openssl-1.1.1a.tar.gz
cd openssl-1.1.1a
./config --prefix=/usr/local/openssl1.1.1 --openssldir=/usr/local/openssl1.1.1
make
make install
rm -rf /tmp/opensll

echo /usr/local/openssl1.1.1/lib > /etc/ld.so.conf.d/openssl1.1.1.conf
ldconfig 

mkdir /tmp/python37
wget https://www.python.org/ftp/python/3.7.3/Python-3.7.3.tgz
tar xfz Python-3.7.3.tgz
cd Python-3.7.3
./configure --with-ensurepip=yes --with-openssl=/usr/local/openssl1.1.1 CFLAGS="-I/usr/local/openssl1.1.1/include" LDFLAGS="-L/usr/local/openssl1.1.1/lib" CXX=/usr/bin/g++
make
make install
rm -rf /tmp/python37

ldconfig 
--------------------

This important pieces are:

echo /usr/local/openssl1.1.1/lib > /etc/ld.so.conf.d/openssl1.1.1.conf
ldconfig 

to make it find the .so to load it at runtime and 

./configure --with-ensurepip=yes --with-openssl=/usr/local/openssl1.1.1 CFLAGS="-I/usr/local/openssl1.1.1/include" LDFLAGS="-L/usr/local/openssl1.1.1/lib" CXX=/usr/bin/g++

specifying the non-standard openssl-version specifically.

----------
nosy: +Jan Wilmans

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34028>
_______________________________________

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: [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:51:10 2020
From: report at bugs.python.org (Steve Dower)
Date: Fri, 24 Apr 2020 19:51:10 +0000
Subject: [issue40377] APPDATA location in Microsoft Store version
In-Reply-To: <1587734754.85.0.727792315124.issue40377@roundup.psfhosted.org>
Message-ID: <1587757870.68.0.993035079863.issue40377@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

You're welcome! We're all involved - apart from a little bit of startup code, it's exactly the same as the regular install.

Right now, I'd say you have a case that needs the regular installer, in order to avoid the appdata redirection.

As for changing it, it seems that thing have been updated again in last year's 1903 update to make AppData redirection even more transparent (ref: https://docs.microsoft.com/en-us/windows/msix/desktop/desktop-to-uwp-behind-the-scenes#file-system ). So the intent is really clear that these file locations are not supposed to be shared (e.g. by printing out the directory backing the app-local modifications).

What's the best option here? Probably for Jupyter to move the files elsewhere, or provide a way to output the relevant contents of the file on the console rather than just printing the path. Either of those would work fine on Python 3.8 and earlier as well.

I'm not even sure that those UWP APIs are guaranteed to give a path to the redirected folder - that would break reading of unredirected files, as the docs are clear that User\Name\AppData is redirected, not the other way around. So I don't know that it's an option. I'm also not aware of any way to disable the redirection within the app, like there is for WOW64 redirections.

Having thought some more, I really do think the best option is for Jupyter to be able to print out the required information. That means its stored files can be safely backed up/restored (or transferred, if put in Roaming) and other applications can "python -m jupyter kernelspec <some new command>" to get all of the info they need. Even if we added a new API here, they'd still have to make a change, so making a change that works well for all runtime versions is probably preferable for them as well.

----------
components: +Windows
nosy: +paul.moore, tim.golden, zach.ware
type: behavior -> enhancement
versions: +Python 3.9 -Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40377>
_______________________________________

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: [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:02:37 2020
From: report at bugs.python.org (Clay Caviness)
Date: Fri, 24 Apr 2020 20:02:37 +0000
Subject: [issue40381] plistlib doesn't handle poorly-formatted plists
In-Reply-To: <1587757952.37.0.0995683897517.issue40381@roundup.psfhosted.org>
Message-ID: <1587758557.68.0.53718047847.issue40381@roundup.psfhosted.org>


Clay Caviness <clay at boobah.com> added the comment:

I expect the answer here to be "plistlib is correct, that's a poorly formatted plist", but since plistlib is "for reading and writing the ?property list? files used mainly by Mac OS X and supports both binary and XML plist files", and Apple's own tooling handles these poorly-formatted files without error it was worth raising the issue.

----------

_______________________________________
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: [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 16:37:34 2020
From: report at bugs.python.org (Anthony Sottile)
Date: Fri, 24 Apr 2020 20:37:34 +0000
Subject: [issue40335] Regression in multiline SyntaxError offsets
In-Reply-To: <1587332455.2.0.964330224308.issue40335@roundup.psfhosted.org>
Message-ID: <1587760654.0.0.497002515598.issue40335@roundup.psfhosted.org>


Anthony Sottile <asottile at umich.edu> added the comment:

This seems to have regressed again

$ ./python --version --version
Python 3.9.0a5+ (heads/master:503de7149d, Apr 24 2020, 13:34:49) 
[GCC 7.5.0]
$ ./python t.py
  File "/home/asottile/workspace/cpython/t.py", line 8
    
                                        ^
SyntaxError: invalid string prefix

----------
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40335>
_______________________________________

From report at bugs.python.org  Fri Apr 24 16:41:03 2020
From: report at bugs.python.org (Tal Einat)
Date: Fri, 24 Apr 2020 20:41:03 +0000
Subject: [issue40031] Python Configure IDLE 'Ok' and 'Apply' buttons do not
 seem to work.
In-Reply-To: <1584783754.51.0.582471420619.issue40031@roundup.psfhosted.org>
Message-ID: <1587760863.94.0.305602878579.issue40031@roundup.psfhosted.org>


Tal Einat <taleinat+python at gmail.com> added the comment:

Saaheer, could you please run IDLE by opening a command window (Run -> cmd.exe) or PowerShell, then running `python -m idlelib`? Then when this happens, please check the command / PowerShell window to see whether an error message and/or traceback has appeared there, and if so please copy it here. That would greatly help us to diagnose the issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40031>
_______________________________________

From report at bugs.python.org  Fri Apr 24 16:45:04 2020
From: report at bugs.python.org (Tal Einat)
Date: Fri, 24 Apr 2020 20:45:04 +0000
Subject: [issue39089] Update IDLE's credits
In-Reply-To: <1576691089.83.0.499008805758.issue39089@roundup.psfhosted.org>
Message-ID: <1587761104.91.0.219434388896.issue39089@roundup.psfhosted.org>


Tal Einat <taleinat+python at gmail.com> added the comment:

Looks pretty good to me. I've been working on IDLE since... 2003/2004, beginning with a private fork of IDLE-fork. I began actually contributing to the main CPython version of IDLE in 2005.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39089>
_______________________________________

From report at bugs.python.org  Fri Apr 24 16:54:54 2020
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 24 Apr 2020 20:54:54 +0000
Subject: [issue40367] ImportError: libffi.so.6
In-Reply-To: <1587589423.16.0.82755935318.issue40367@roundup.psfhosted.org>
Message-ID: <1587761694.92.0.83048663796.issue40367@roundup.psfhosted.org>


?ric Araujo <merwok at netwok.org> added the comment:

How did you get the Python installed in /opt/python/3.8.1?

Maybe it was compiled against libffi 6, then you updated the system to libffi 7, so that Python would need a rebuild.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40367>
_______________________________________

From report at bugs.python.org  Fri Apr 24 16:55:00 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 24 Apr 2020 20:55:00 +0000
Subject: [issue40335] Regression in multiline SyntaxError offsets
In-Reply-To: <1587332455.2.0.964330224308.issue40335@roundup.psfhosted.org>
Message-ID: <1587761700.41.0.385318289186.issue40335@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

This is likely due to the new parser (see PEP 617). Do you get the same problem running with -X oldparser ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40335>
_______________________________________

From report at bugs.python.org  Fri Apr 24 16:56:57 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 24 Apr 2020 20:56:57 +0000
Subject: [issue40335] Regression in multiline SyntaxError offsets
In-Reply-To: <1587332455.2.0.964330224308.issue40335@roundup.psfhosted.org>
Message-ID: <1587761817.36.0.0705238440282.issue40335@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Hummmm.....actually, no. This is something else...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40335>
_______________________________________

From report at bugs.python.org  Fri Apr 24 16:59:46 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 24 Apr 2020 20:59:46 +0000
Subject: [issue40335] Regression in multiline SyntaxError offsets
In-Reply-To: <1587332455.2.0.964330224308.issue40335@roundup.psfhosted.org>
Message-ID: <1587761986.06.0.412860434592.issue40335@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
Removed message: https://bugs.python.org/msg367225

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40335>
_______________________________________

From report at bugs.python.org  Fri Apr 24 17:00:07 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 24 Apr 2020 21:00:07 +0000
Subject: [issue40335] Regression in multiline SyntaxError offsets
In-Reply-To: <1587332455.2.0.964330224308.issue40335@roundup.psfhosted.org>
Message-ID: <1587762007.45.0.990473361399.issue40335@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Yeah, I can confirm after bisecting that the commit that introduced the regression is the new parser:

c5fc15685202cda73f7c3f5c6f299b0945f58508 is the first bad commit
commit c5fc15685202cda73f7c3f5c6f299b0945f58508
Author: Pablo Galindo <Pablogsal at gmail.com>
Date:   Wed Apr 22 23:29:27 2020 +0100

    bpo-40334: PEP 617 implementation: New PEG parser for CPython (GH-19503)

    Co-authored-by: Guido van Rossum <guido at python.org>
    Co-authored-by: Lysandros Nikolaou <lisandrosnik at gmail.com>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40335>
_______________________________________

From report at bugs.python.org  Fri Apr 24 17:02:53 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 24 Apr 2020 21:02:53 +0000
Subject: [issue40335] Regression in multiline SyntaxError offsets
In-Reply-To: <1587332455.2.0.964330224308.issue40335@roundup.psfhosted.org>
Message-ID: <1587762173.68.0.523935264656.issue40335@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

With the old parser it works:

~/github/python/master master*
? ./python -X oldparser t.py
3.9.0a5+ (heads/master:503de7149d, Apr 24 2020, 22:02:28)
[GCC 9.3.0]

SyntaxError:
- line: 8
- offset: 8
- text: "    '''\n\ndef bar():\n    pass\n\ndef baz():\n    '''quux'''\n"


~/github/python/master master*
? ./python  t.py
3.9.0a5+ (heads/master:503de7149d, Apr 24 2020, 22:02:28)
[GCC 9.3.0]

SyntaxError:
- line: 8
- offset: 52
- text: "    '''"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40335>
_______________________________________

From report at bugs.python.org  Fri Apr 24 17:04:26 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 24 Apr 2020 21:04:26 +0000
Subject: [issue40335] Regression in multiline SyntaxError offsets
In-Reply-To: <1587332455.2.0.964330224308.issue40335@roundup.psfhosted.org>
Message-ID: <1587762266.24.0.741697447229.issue40335@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

And the regression happens because we are ignoring that test currently due to the new parser not currently reporting the same offsets:

https://github.com/python/cpython/blob/master/Lib/test/test_exceptions.py#L181

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40335>
_______________________________________

From report at bugs.python.org  Fri Apr 24 17:15:50 2020
From: report at bugs.python.org (Carl Meyer)
Date: Fri, 24 Apr 2020 21:15:50 +0000
Subject: [issue40360] Deprecate lib2to3 (and 2to3) for future removal
In-Reply-To: <1587530454.25.0.44181585934.issue40360@roundup.psfhosted.org>
Message-ID: <1587762950.88.0.438581936472.issue40360@roundup.psfhosted.org>


Carl Meyer <carl at oddbird.net> added the comment:

@gregory.p.smith

What do you think about the question I raised above about how to make this deprecation visible to users of the 2to3 CLI tool, assuming the plan is to remove both?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40360>
_______________________________________

From report at bugs.python.org  Fri Apr 24 17:15:46 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Fri, 24 Apr 2020 21:15:46 +0000
Subject: [issue40378] ast.parse fails to trigger SyntaxWarning that normal
 execution does
In-Reply-To: <1587752284.4.0.62112080929.issue40378@roundup.psfhosted.org>
Message-ID: <1587762946.41.0.244850483623.issue40378@roundup.psfhosted.org>


Batuhan Taskaya <batuhanosmantaskaya at gmail.com> added the comment:

This is probably because that these warnings raised during code generation, rather then AST Validation / generation.

----------
nosy: +BTaskaya

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40378>
_______________________________________

From report at bugs.python.org  Fri Apr 24 17:16:09 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 24 Apr 2020 21:16:09 +0000
Subject: [issue40381] plistlib doesn't handle poorly-formatted plists
In-Reply-To: <1587757952.37.0.0995683897517.issue40381@roundup.psfhosted.org>
Message-ID: <1587762969.61.0.925725454725.issue40381@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
nosy: +ned.deily, ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40381>
_______________________________________

From report at bugs.python.org  Fri Apr 24 17:25:08 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 24 Apr 2020 21:25:08 +0000
Subject: [issue40378] ast.parse fails to trigger SyntaxWarning that normal
 execution does
In-Reply-To: <1587752284.4.0.62112080929.issue40378@roundup.psfhosted.org>
Message-ID: <1587763508.71.0.881208849585.issue40378@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

It is not a bug. Execution includes more stages than ast.parse().

----------
nosy: +serhiy.storchaka
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40378>
_______________________________________

From report at bugs.python.org  Fri Apr 24 17:41:41 2020
From: report at bugs.python.org (Anthony Sottile)
Date: Fri, 24 Apr 2020 21:41:41 +0000
Subject: [issue40378] ast.parse fails to trigger SyntaxWarning that normal
 execution does
In-Reply-To: <1587752284.4.0.62112080929.issue40378@roundup.psfhosted.org>
Message-ID: <1587764501.54.0.0873455739835.issue40378@roundup.psfhosted.org>


Anthony Sottile <asottile at umich.edu> added the comment:

I would really like to be able to trigger all warnings consistently and statically without executing the code.

This is useful (for instance) for this simple script which validates the ast: https://github.com/pre-commit/pre-commit-hooks/blob/master/pre_commit_hooks/check_ast.py

when run with PYTHONWARNINGS=error I get nice error reports for things such as invalid escape sequence, but I do not get them for string-call which I would like to

This does seem like a bug and prematurely closed, I'm a bit disappointed in the current resolution

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40378>
_______________________________________

From report at bugs.python.org  Fri Apr 24 17:45:39 2020
From: report at bugs.python.org (Anthony Sottile)
Date: Fri, 24 Apr 2020 21:45:39 +0000
Subject: [issue40335] Regression in multiline SyntaxError offsets
In-Reply-To: <1587332455.2.0.964330224308.issue40335@roundup.psfhosted.org>
Message-ID: <1587764739.54.0.46577909095.issue40335@roundup.psfhosted.org>


Anthony Sottile <asottile at umich.edu> added the comment:

pyflakes's testsuite has many failures under the new parser -- is the expectation that those will be fixed by 3.9 final?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40335>
_______________________________________

From report at bugs.python.org  Fri Apr 24 18:33:47 2020
From: report at bugs.python.org (Cajetan Rodrigues)
Date: Fri, 24 Apr 2020 22:33:47 +0000
Subject: [issue40279] Documentation example of module init function lacks
 error handling
In-Reply-To: <1586844509.3.0.451475770029.issue40279@roundup.psfhosted.org>
Message-ID: <1587767627.95.0.52397978638.issue40279@roundup.psfhosted.org>


Cajetan Rodrigues <caje731 at gmail.com> added the comment:

At the risk of sounding like a jerk, I'd very much want to say that copy-pasters should get what they deserve :) But then I remember I was once a copy-paster too!

Hello again, Stefan :)

Thanks for watching out for the community - I'll be happy to fix this!

----------
nosy: +cajetan.rodrigues

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40279>
_______________________________________

From report at bugs.python.org  Fri Apr 24 18:55:35 2020
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 24 Apr 2020 22:55:35 +0000
Subject: [issue40360] Deprecate lib2to3 (and 2to3) for future removal
In-Reply-To: <1587530454.25.0.44181585934.issue40360@roundup.psfhosted.org>
Message-ID: <1587768935.34.0.495475369749.issue40360@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:

I think what we're doing with the documentation update is fine.  We can add a warning on stderr to the tool in 3.11.  But I don't expect people will be using the tool _from_ the latest CPython 3.x by then.

2to3 is already included with Python 2.7 and the only real use for it is for people who still have code they maintain on 2.7 so they've got a copy already.  There is no value in running a 2to3 shipped with Python 3 vs the latest 2.7.  Meaningful updates to it were already back ported to 2.7 over time as it was intentionally exempt from feature freeze.

We should have sorted out a PyPI home for lib2to3 by 3.11 time and can also create a PyPI package for the 2to3 tool itself at that point.

I _think_ there is support for running 2to3 on sources at package install time from setup.py?  But I don't expect anything actually maintained and widely used to require that by the time this deprecation lands.  If it does, that becomes a plumbing issue within package tools to know that requiring 2to3 at either build or install time adds an implicit tool dependency on the new pypi package to get it.

Maybe I'm just in a good mood about all of this, but none of this seems worrisome.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40360>
_______________________________________

From report at bugs.python.org  Fri Apr 24 18:59:07 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 24 Apr 2020 22:59:07 +0000
Subject: [issue40335] Regression in multiline SyntaxError offsets
In-Reply-To: <1587332455.2.0.964330224308.issue40335@roundup.psfhosted.org>
Message-ID: <1587769147.16.0.475186645896.issue40335@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

> pyflakes's testsuite has many failures under the new parser

Can you report this also on the PEP 617 issue?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40335>
_______________________________________

From report at bugs.python.org  Fri Apr 24 19:09:21 2020
From: report at bugs.python.org (Anthony Sottile)
Date: Fri, 24 Apr 2020 23:09:21 +0000
Subject: [issue40334] PEP 617: new PEG-based parser
In-Reply-To: <1587327377.33.0.614039250584.issue40334@roundup.psfhosted.org>
Message-ID: <1587769761.74.0.307815647854.issue40334@roundup.psfhosted.org>


Anthony Sottile <asottile at umich.edu> added the comment:

:waves: -- seeing a lot of failures in pyflakes' testsuite around SyntaxErrors https://github.com/PyCQA/pyflakes/pull/532

(you can reproduce with `path/to/python -m unittest discover pyflakes` without needing any dependencies installed)

----------
nosy: +Anthony Sottile

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40334>
_______________________________________

From report at bugs.python.org  Fri Apr 24 19:09:40 2020
From: report at bugs.python.org (Anthony Sottile)
Date: Fri, 24 Apr 2020 23:09:40 +0000
Subject: [issue40335] Regression in multiline SyntaxError offsets
In-Reply-To: <1587332455.2.0.964330224308.issue40335@roundup.psfhosted.org>
Message-ID: <1587769780.57.0.19664706989.issue40335@roundup.psfhosted.org>


Anthony Sottile <asottile at umich.edu> added the comment:

cool, reported there as well!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40335>
_______________________________________

From report at bugs.python.org  Fri Apr 24 19:39:11 2020
From: report at bugs.python.org (Kyle Stanley)
Date: Fri, 24 Apr 2020 23:39:11 +0000
Subject: [issue40340] Programming FAQ about "How do I convert a string to a
 number?" contains a typo
In-Reply-To: <1587411465.5.0.0585658579804.issue40340@roundup.psfhosted.org>
Message-ID: <1587771551.76.0.199384016738.issue40340@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:


New changeset 5aafa548794d23b6d4cafb4fd88289cd0ba2a2a8 by Cajetan Rodrigues in branch 'master':
bpo-40340: Separate examples more clearly in the programming FAQ (GH-19688)
https://github.com/python/cpython/commit/5aafa548794d23b6d4cafb4fd88289cd0ba2a2a8


----------
nosy: +aeros

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40340>
_______________________________________

From report at bugs.python.org  Fri Apr 24 19:50:50 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Fri, 24 Apr 2020 23:50:50 +0000
Subject: [issue40378] ast.parse fails to trigger SyntaxWarning that normal
 execution does
In-Reply-To: <1587752284.4.0.62112080929.issue40378@roundup.psfhosted.org>
Message-ID: <1587772250.22.0.563720061307.issue40378@roundup.psfhosted.org>


Batuhan Taskaya <batuhanosmantaskaya at gmail.com> added the comment:

> This does seem like a bug and prematurely closed, I'm a bit disappointed in the current resolution

I would love to see it moved as a new step in the execution pipeline that we cane extend easily and use externally (like PyAST_Validate). But I'm not sure if the burden worths the gain. Though, for the current version it would be very simple to implement such checks (3-4) with a simple NodeVisitor. Just an example (should be pretty close to output, not exact): https://github.com/isidentical/astvalidate/blob/master/astvalidate/validators/syntatical.py

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40378>
_______________________________________

From report at bugs.python.org  Fri Apr 24 19:50:03 2020
From: report at bugs.python.org (Cajetan Rodrigues)
Date: Fri, 24 Apr 2020 23:50:03 +0000
Subject: [issue40279] Documentation example of module init function lacks
 error handling
In-Reply-To: <1586844509.3.0.451475770029.issue40279@roundup.psfhosted.org>
Message-ID: <1587772203.12.0.917225062666.issue40279@roundup.psfhosted.org>


Change by Cajetan Rodrigues <caje731 at gmail.com>:


----------
keywords: +patch
pull_requests: +19024
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/19705

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40279>
_______________________________________

From report at bugs.python.org  Fri Apr 24 19:55:08 2020
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 24 Apr 2020 23:55:08 +0000
Subject: [issue34028] Python 3.7.0 wont compile with SSL Support 1.1.0 >
 alledged missing X509_VERIFY_PARAM_set1_host() support
In-Reply-To: <1530609211.5.0.56676864532.issue34028@psf.upfronthosting.co.za>
Message-ID: <1587772508.52.0.266818222297.issue34028@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

That's a very dangerous trick and I advise against it. You are modifying the global linker path and inject custom OpenSSL libraries into it. This may affect and disrupt other programs or OS core tools.

Instead compile the _ssl and _hashlib module with rpath, e.g. LD_RUN_PATH. You also don't have to modify CFLAGS or LDFLAGS. --with-openssl does that for you.

$ export LD_RUN_PATH=/home/heimes/dev/python/multissl/openssl/1.1.1f/lib
$ ./configure --with-openssl=/home/heimes/dev/python/multissl/openssl/1.1.1f -C
$ make
$ unset LD_RUN_PATH
$ ldd build/lib.linux-x86_64-3.9/_ssl.cpython-39-x86_64-linux-gnu.so
        linux-vdso.so.1 (0x00007ffc124eb000)
        libssl.so.1.1 => /home/heimes/dev/python/multissl/openssl/1.1.1f/lib/libssl.so.1.1 (0x00007fd3d7cab000)
        libcrypto.so.1.1 => /home/heimes/dev/python/multissl/openssl/1.1.1f/lib/libcrypto.so.1.1 (0x00007fd3d7974000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fd3d791c000)
        libc.so.6 => /lib64/libc.so.6 (0x00007fd3d7753000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007fd3d774c000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fd3d7d8e000)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34028>
_______________________________________

From report at bugs.python.org  Fri Apr 24 20:19:36 2020
From: report at bugs.python.org (Nikolay Bryskin)
Date: Sat, 25 Apr 2020 00:19:36 +0000
Subject: [issue30491] Add a lightweight mechanism for detecting un-awaited
 coroutine objects
In-Reply-To: <1495867380.86.0.533205071954.issue30491@psf.upfronthosting.co.za>
Message-ID: <1587773976.85.0.790627852364.issue30491@roundup.psfhosted.org>


Change by Nikolay Bryskin <devel.niks at gmail.com>:


----------
nosy: +nikicat

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30491>
_______________________________________

From report at bugs.python.org  Fri Apr 24 20:20:03 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 25 Apr 2020 00:20:03 +0000
Subject: [issue40334] PEP 617: new PEG-based parser
In-Reply-To: <1587327377.33.0.614039250584.issue40334@roundup.psfhosted.org>
Message-ID: <1587774003.75.0.29808308647.issue40334@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:


New changeset 0e80b561d442769631d66f1cc8813ac30f97378e by Guido van Rossum in branch 'master':
bpo-40334: Add What's New sections for PEP 617 and PEP 585 (GH-19704)
https://github.com/python/cpython/commit/0e80b561d442769631d66f1cc8813ac30f97378e


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40334>
_______________________________________

From report at bugs.python.org  Fri Apr 24 20:20:55 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 25 Apr 2020 00:20:55 +0000
Subject: [issue39481] Implement PEP 585 (Type Hinting Generics In Standard
 Collections)
In-Reply-To: <1580231817.93.0.47144630055.issue39481@roundup.psfhosted.org>
Message-ID: <1587774055.93.0.657863788484.issue39481@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

In commit 0e80b561d442769631d66f1cc8813ac30f97378e a What's New section was added.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39481>
_______________________________________

From report at bugs.python.org  Fri Apr 24 20:22:01 2020
From: report at bugs.python.org (Cajetan Rodrigues)
Date: Sat, 25 Apr 2020 00:22:01 +0000
Subject: [issue37551] IDLE: Quitting with a new,
 unsaved editor window causes an exception
In-Reply-To: <1562785926.2.0.442729400594.issue37551@roundup.psfhosted.org>
Message-ID: <1587774121.96.0.318670848764.issue37551@roundup.psfhosted.org>


Cajetan Rodrigues <caje731 at gmail.com> added the comment:

Cannot reproduce on Ubuntu 19.10 with idle3.9 
(Python 3.9.0a5+ (heads/master:a25a04fea5, Apr 20 2020, 22:35:10))

----------
nosy: +cajetan.rodrigues

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37551>
_______________________________________

From report at bugs.python.org  Fri Apr 24 20:45:55 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 25 Apr 2020 00:45:55 +0000
Subject: [issue40334] PEP 617: new PEG-based parser
In-Reply-To: <1587327377.33.0.614039250584.issue40334@roundup.psfhosted.org>
Message-ID: <1587775555.76.0.153747075772.issue40334@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

@Anthony: Presumably some of these will be unavoidable. I see you have PYPY-specific checks in your code already.

You could also help by sending us the test programs and the different output produced by the old and the new parser. You could either create a Gist and link it here, or open bug reports here: https://github.com/we-like-parsers/cpython/issues . I opened one already for you: https://github.com/we-like-parsers/cpython/issues/121

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40334>
_______________________________________

From report at bugs.python.org  Fri Apr 24 20:55:03 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 25 Apr 2020 00:55:03 +0000
Subject: [issue40346] Add random.BaseRandom to ease implementation of
 subclasses
In-Reply-To: <1587419589.68.0.186666450831.issue40346@roundup.psfhosted.org>
Message-ID: <1587776103.09.0.506979948556.issue40346@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

SystemRandom is a weird special case.  Otherwise, almost every PRNG is going to need seed(), getstate(), and setstate().  A base class should each offer some reusable code to minimize the burden on the subclass:

* The existing seed method allows multiple input types to be collapsed to a long integer.  A subclass can extend this as needed or can override it completely.  This is useful and will tend to give a more consistent API across multiple RNGs.

* The getstate/setstate methods take care of the gauss_next value and allow the seeding to be versioned.  This is also useful and helps us insulate users from state related implementation details such as gauss_next.

Please don't lose the above functionality by default.

Also, please make sure that code written to the existing spec continues to work.?

+1 on offering a PCG generator; however, it should an additional alternative to MT and SystemRandom rather than a replacement.  Also, it needs to work well on 32-bit builds.  Notes should be added that its state space is *much* smaller than MT, so shuffle() becomes state space limited at much smaller population sizes -- meaning that a large number of possible permutations become unreachable by shuffle() -- for example, to cover all possible shuffles for a deck of 52 playing cards requires 226 bits.?  Also, I expect that PCG won't offer us the same performance advantage as it does for numpy because the MT code itself is only a fraction of the time in a call to random(); the rest of the time is in the function call overhead, converting the bytes to a C double, and creating a new Python float object.

I would still like to see a PEP for this. 


? https://code.activestate.com/recipes/576707/
? factorial(52).bit_length()

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40346>
_______________________________________

From report at bugs.python.org  Fri Apr 24 20:59:32 2020
From: report at bugs.python.org (Zackery Spytz)
Date: Sat, 25 Apr 2020 00:59:32 +0000
Subject: [issue27620] IDLE: Add keyboard equivalents for mouse actions.
In-Reply-To: <1469494491.39.0.22722488108.issue27620@psf.upfronthosting.co.za>
Message-ID: <1587776372.19.0.63972852108.issue27620@roundup.psfhosted.org>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
keywords: +patch
nosy: +ZackerySpytz
nosy_count: 3.0 -> 4.0
pull_requests: +19026
stage: test needed -> patch review
pull_request: https://github.com/python/cpython/pull/19706

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27620>
_______________________________________

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: [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:12:47 2020
From: report at bugs.python.org (OhBonsai)
Date: Sat, 25 Apr 2020 03:12:47 +0000
Subject: [issue40383] some class name are hardcoded in reprs
In-Reply-To: <1587783917.63.0.137882074418.issue40383@roundup.psfhosted.org>
Message-ID: <1587784367.6.0.317076038514.issue40383@roundup.psfhosted.org>


Change by OhBonsai <letbonsaibe at gmail.com>:


----------
keywords: +patch
pull_requests: +19027
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19707

_______________________________________
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: [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: [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:32:57 2020
From: report at bugs.python.org (Alex)
Date: Sat, 25 Apr 2020 03:32:57 +0000
Subject: [issue40384] IDLE: Undesired highlight
In-Reply-To: <1587785397.11.0.430287508325.issue40384@roundup.psfhosted.org>
Message-ID: <1587785577.13.0.931021396061.issue40384@roundup.psfhosted.org>


Alex <2423067593 at qq.com> added the comment:

The sharp is at line 2, not line 3. I made a mistake.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40384>
_______________________________________

From report at bugs.python.org  Fri Apr 24 23:38:57 2020
From: report at bugs.python.org (Ammar Askar)
Date: Sat, 25 Apr 2020 03:38:57 +0000
Subject: [issue13645] import machinery vulnerable to timestamp collisions
In-Reply-To: <1324470738.36.0.917497036729.issue13645@psf.upfronthosting.co.za>
Message-ID: <1587785937.86.0.0385699118554.issue13645@roundup.psfhosted.org>


Change by Ammar Askar <ammar at ammaraskar.com>:


----------
pull_requests:  -19023

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13645>
_______________________________________

From report at bugs.python.org  Fri Apr 24 23:39:58 2020
From: report at bugs.python.org (OhBonsai)
Date: Sat, 25 Apr 2020 03:39:58 +0000
Subject: [issue40383] weakref class name are hardcoded in reprs
In-Reply-To: <1587783917.63.0.137882074418.issue40383@roundup.psfhosted.org>
Message-ID: <1587785998.27.0.854162626119.issue40383@roundup.psfhosted.org>


Change by OhBonsai <letbonsaibe at gmail.com>:


----------
assignee:  -> docs at python
components: +Documentation -Extension Modules
nosy: +docs at python
title: some class name are hardcoded in reprs -> weakref class name are hardcoded in reprs

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40383>
_______________________________________

From report at bugs.python.org  Fri Apr 24 23:46:32 2020
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 25 Apr 2020 03:46:32 +0000
Subject: [issue40385] Tools/checkpyc.py has been broken since PEP 552
In-Reply-To: <1587785534.8.0.504830740261.issue40385@roundup.psfhosted.org>
Message-ID: <1587786392.33.0.777791686724.issue40385@roundup.psfhosted.org>


Benjamin Peterson <benjamin at python.org> added the comment:

I'd vote for axing it.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40385>
_______________________________________

From report at bugs.python.org  Fri Apr 24 23:53:51 2020
From: report at bugs.python.org (Ammar Askar)
Date: Sat, 25 Apr 2020 03:53:51 +0000
Subject: [issue34990] year 2038 problem in compileall.py
In-Reply-To: <1539602536.3.0.788709270274.issue34990@psf.upfronthosting.co.za>
Message-ID: <1587786831.66.0.34791752146.issue34990@roundup.psfhosted.org>


Change by Ammar Askar <ammar at ammaraskar.com>:


----------
pull_requests: +19029
pull_request: https://github.com/python/cpython/pull/19708

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34990>
_______________________________________

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: [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  Fri Apr 24 23:57:59 2020
From: report at bugs.python.org (wyz23x2)
Date: Sat, 25 Apr 2020 03:57:59 +0000
Subject: [issue40386] Strange behavior during invalid import of modules
 without if __name__ == "__main__"
In-Reply-To: <1587787049.96.0.282415448462.issue40386@roundup.psfhosted.org>
Message-ID: <1587787079.13.0.352096084533.issue40386@roundup.psfhosted.org>


Change by wyz23x2 <wyz23x2 at 163.com>:


----------
components: +Library (Lib)
versions: +Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40386>
_______________________________________

From report at bugs.python.org  Fri Apr 24 23:59:35 2020
From: report at bugs.python.org (wyz23x2)
Date: Sat, 25 Apr 2020 03:59:35 +0000
Subject: [issue40386] Strange behavior during invalid import of modules
 without if __name__ == "__main__"
In-Reply-To: <1587787049.96.0.282415448462.issue40386@roundup.psfhosted.org>
Message-ID: <1587787175.64.0.416081587467.issue40386@roundup.psfhosted.org>


wyz23x2 <wyz23x2 at 163.com> added the comment:

Sorry, it's "of 'this' is run", not "un".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40386>
_______________________________________

From report at bugs.python.org  Sat Apr 25 00:03:01 2020
From: report at bugs.python.org (wyz23x2)
Date: Sat, 25 Apr 2020 04:03:01 +0000
Subject: [issue40386] Strange behavior during invalid import of modules
 without if __name__ == "__main__"
In-Reply-To: <1587787049.96.0.282415448462.issue40386@roundup.psfhosted.org>
Message-ID: <1587787381.15.0.415384321824.issue40386@roundup.psfhosted.org>


Change by wyz23x2 <wyz23x2 at 163.com>:


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40386>
_______________________________________

From report at bugs.python.org  Sat Apr 25 00:12:25 2020
From: report at bugs.python.org (Ammar Askar)
Date: Sat, 25 Apr 2020 04:12:25 +0000
Subject: [issue40385] Tools/checkpyc.py has been broken since PEP 552
In-Reply-To: <1587785534.8.0.504830740261.issue40385@roundup.psfhosted.org>
Message-ID: <1587787945.78.0.755454548078.issue40385@roundup.psfhosted.org>


Change by Ammar Askar <ammar at ammaraskar.com>:


----------
keywords: +patch
pull_requests: +19030
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19709

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40385>
_______________________________________

From report at bugs.python.org  Sat Apr 25 00:34:06 2020
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 25 Apr 2020 04:34:06 +0000
Subject: [issue40385] Tools/checkpyc.py has been broken since PEP 552
In-Reply-To: <1587785534.8.0.504830740261.issue40385@roundup.psfhosted.org>
Message-ID: <1587789246.84.0.419018230093.issue40385@roundup.psfhosted.org>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset f82807746d26b4c047f7f3115065f20bb63fb5ff by Ammar Askar in branch 'master':
closes bpo-40385: Remove Tools/scripts/checkpyc.py (GH-19709)
https://github.com/python/cpython/commit/f82807746d26b4c047f7f3115065f20bb63fb5ff


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40385>
_______________________________________

From report at bugs.python.org  Sat Apr 25 00:51:17 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 25 Apr 2020 04:51:17 +0000
Subject: [issue40386] Strange behavior during invalid import of modules
 without if __name__ == "__main__"
In-Reply-To: <1587787049.96.0.282415448462.issue40386@roundup.psfhosted.org>
Message-ID: <1587790277.76.0.711683152662.issue40386@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Trying using "import this" instead of "import this.main".

The latter does an "import this" and then attempts to load a "main" package that doesn't exist.  You're observed the expected behavior.  See https://docs.python.org/3/tutorial/modules.html#packages for more details.

Hope that clears-up your understanding of what is happening.

----------
nosy: +rhettinger
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40386>
_______________________________________

From report at bugs.python.org  Sat Apr 25 01:28:02 2020
From: report at bugs.python.org (Stefan Behnel)
Date: Sat, 25 Apr 2020 05:28:02 +0000
Subject: [issue40279] Documentation example of module init function lacks
 error handling
In-Reply-To: <1586844509.3.0.451475770029.issue40279@roundup.psfhosted.org>
Message-ID: <1587792482.65.0.684820831299.issue40279@roundup.psfhosted.org>


Stefan Behnel <stefan_ml at behnel.de> added the comment:


New changeset d4f3923d5901ef1ccdbe6ad6c5a753af90832a0f by Cajetan Rodrigues in branch 'master':
bpo-40279: Add some error-handling to the module initialisation docs example (GH-19705)
https://github.com/python/cpython/commit/d4f3923d5901ef1ccdbe6ad6c5a753af90832a0f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40279>
_______________________________________

From report at bugs.python.org  Sat Apr 25 01:30:50 2020
From: report at bugs.python.org (miss-islington)
Date: Sat, 25 Apr 2020 05:30:50 +0000
Subject: [issue40279] Documentation example of module init function lacks
 error handling
In-Reply-To: <1586844509.3.0.451475770029.issue40279@roundup.psfhosted.org>
Message-ID: <1587792650.95.0.142006614074.issue40279@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
nosy: +miss-islington
nosy_count: 3.0 -> 4.0
pull_requests: +19031
pull_request: https://github.com/python/cpython/pull/19710

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40279>
_______________________________________

From report at bugs.python.org  Sat Apr 25 01:46:25 2020
From: report at bugs.python.org (Stefan Behnel)
Date: Sat, 25 Apr 2020 05:46:25 +0000
Subject: [issue40279] Documentation example of module init function lacks
 error handling
In-Reply-To: <1586844509.3.0.451475770029.issue40279@roundup.psfhosted.org>
Message-ID: <1587793585.52.0.333617536909.issue40279@roundup.psfhosted.org>


Stefan Behnel <stefan_ml at behnel.de> added the comment:

Hi Cajetan, thank you for your contribution! That's a nice documentation improvement.

----------
nosy:  -miss-islington
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40279>
_______________________________________

From report at bugs.python.org  Sat Apr 25 01:45:54 2020
From: report at bugs.python.org (Stefan Behnel)
Date: Sat, 25 Apr 2020 05:45:54 +0000
Subject: [issue40279] Documentation example of module init function lacks
 error handling
In-Reply-To: <1586844509.3.0.451475770029.issue40279@roundup.psfhosted.org>
Message-ID: <1587793554.91.0.557783464416.issue40279@roundup.psfhosted.org>


Stefan Behnel <stefan_ml at behnel.de> added the comment:


New changeset 882a7f44da08c6fb210bd9a17f80903cbca84034 by Miss Islington (bot) in branch '3.8':
bpo-40279: Add some error-handling to the module initialisation docs example (GH-19705) (GH-19710)
https://github.com/python/cpython/commit/882a7f44da08c6fb210bd9a17f80903cbca84034


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40279>
_______________________________________

From report at bugs.python.org  Sat Apr 25 02:33:43 2020
From: report at bugs.python.org (Kyle Stanley)
Date: Sat, 25 Apr 2020 06:33:43 +0000
Subject: [issue40340] Programming FAQ about "How do I convert a string to a
 number?" contains a typo
In-Reply-To: <1587411465.5.0.0585658579804.issue40340@roundup.psfhosted.org>
Message-ID: <1587796423.0.0.798397980459.issue40340@roundup.psfhosted.org>


Change by Kyle Stanley <aeros167 at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40340>
_______________________________________

From report at bugs.python.org  Sat Apr 25 02:50:06 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 25 Apr 2020 06:50:06 +0000
Subject: [issue40378] ast.parse fails to trigger SyntaxWarning that normal
 execution does
In-Reply-To: <1587752284.4.0.62112080929.issue40378@roundup.psfhosted.org>
Message-ID: <1587797406.5.0.252010704186.issue40378@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Compilation includes the following stages:

1. Tokenizing.
2. Creating CST (concrete syntax tree).
3. Creating AST (abstract syntax tree).
4. Optimizing AST.
5. Building symtable.
6. Generating bytecode.
7. Optimizing bytecode.

ast.parse() only includes stages 1-3. Many warnings and errors can be raised at stages 5 and 6 (for example errors for "break" outside of a loop and "unlocal" at module level). If you want to get all warnings and errors, use compile().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40378>
_______________________________________

From report at bugs.python.org  Sat Apr 25 03:04:14 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 25 Apr 2020 07:04:14 +0000
Subject: [issue40275] test.support has way too many imports
In-Reply-To: <1586816691.28.0.874442798421.issue40275@roundup.psfhosted.org>
Message-ID: <1587798254.25.0.366245591569.issue40275@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 3c8a5b459d68b4337776ada1e04f5b33f90a2275 by Serhiy Storchaka in branch 'master':
bpo-40275: Avoid importing asyncio in test.support (GH-19600)
https://github.com/python/cpython/commit/3c8a5b459d68b4337776ada1e04f5b33f90a2275


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40275>
_______________________________________

From report at bugs.python.org  Sat Apr 25 03:06:33 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 25 Apr 2020 07:06:33 +0000
Subject: [issue40275] test.support has way too many imports
In-Reply-To: <1586816691.28.0.874442798421.issue40275@roundup.psfhosted.org>
Message-ID: <1587798393.4.0.10135327716.issue40275@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 16994912c93e8e5db7365d48b75d67d3f70dd7b2 by Serhiy Storchaka in branch 'master':
bpo-40275: Avoid importing socket in test.support (GH-19603)
https://github.com/python/cpython/commit/16994912c93e8e5db7365d48b75d67d3f70dd7b2


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40275>
_______________________________________

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: [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:10:29 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Sat, 25 Apr 2020 08:10:29 +0000
Subject: [issue39482] Write 2to3 fixer for collections.abc imports
In-Reply-To: <1580270593.04.0.0568532174463.issue39482@roundup.psfhosted.org>
Message-ID: <1587802229.54.0.382315564785.issue39482@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

Since https://bugs.python.org/issue40360 is now discussing lib2to3 deprecating.
The feature would not be needed.

----------
resolution:  -> wont fix
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39482>
_______________________________________

From report at bugs.python.org  Sat Apr 25 04:11:24 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Sat, 25 Apr 2020 08:11:24 +0000
Subject: [issue40360] Deprecate lib2to3 (and 2to3) for future removal
In-Reply-To: <1587530454.25.0.44181585934.issue40360@roundup.psfhosted.org>
Message-ID: <1587802284.9.0.988660286976.issue40360@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
nosy: +corona10
nosy_count: 5.0 -> 6.0
pull_requests: +19032
pull_request: https://github.com/python/cpython/pull/18245

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40360>
_______________________________________

From report at bugs.python.org  Sat Apr 25 04:35:26 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 25 Apr 2020 08:35:26 +0000
Subject: [issue40275] test.support has way too many imports
In-Reply-To: <1586816691.28.0.874442798421.issue40275@roundup.psfhosted.org>
Message-ID: <1587803726.81.0.264573771032.issue40275@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 515fce4fc4bb0d2db97b17df275cf90640017f56 by Serhiy Storchaka in branch 'master':
bpo-40275: Avoid importing logging in test.support (GH-19601)
https://github.com/python/cpython/commit/515fce4fc4bb0d2db97b17df275cf90640017f56


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40275>
_______________________________________

From report at bugs.python.org  Sat Apr 25 04:56:28 2020
From: report at bugs.python.org (Nicholas Prowse)
Date: Sat, 25 Apr 2020 08:56:28 +0000
Subject: [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 05:18:39 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 25 Apr 2020 09:18:39 +0000
Subject: [issue40275] test.support has way too many imports
In-Reply-To: <1586816691.28.0.874442798421.issue40275@roundup.psfhosted.org>
Message-ID: <1587806319.67.0.50433413342.issue40275@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +19033
pull_request: https://github.com/python/cpython/pull/19711

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40275>
_______________________________________

From report at bugs.python.org  Sat Apr 25 05:25:48 2020
From: report at bugs.python.org (Saaheer Purav)
Date: Sat, 25 Apr 2020 09:25:48 +0000
Subject: [issue40031] Python Configure IDLE 'Ok' and 'Apply' buttons do not
 seem to work.
In-Reply-To: <1584783754.51.0.582471420619.issue40031@roundup.psfhosted.org>
Message-ID: <1587806748.14.0.438786736772.issue40031@roundup.psfhosted.org>


Saaheer Purav <saaheer.purav at gmail.com> added the comment:

This is the error message that I get:

Failed to import extension:  AutoExpand
Failed to load extension 'AutoExpand'
Traceback (most recent call last):
  File "C:\Users\saahe\AppData\Local\Programs\Python\Python38-32\lib\idlelib\editor.py", line 1115, in load_extension
    mod = importlib.import_module('.' + fname, package=__package__)
  File "C:\Users\saahe\AppData\Local\Programs\Python\Python38-32\lib\importlib\__init__.py", line 127, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "<frozen importlib._bootstrap>", line 1014, in _gcd_import
  File "<frozen importlib._bootstrap>", line 991, in _find_and_load
  File "<frozen importlib._bootstrap>", line 973, in _find_and_load_unlocked
ModuleNotFoundError: No module named 'idlelib.AutoExpand'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "C:\Users\saahe\AppData\Local\Programs\Python\Python38-32\lib\idlelib\editor.py", line 1099, in load_standard_extensions
    self.load_extension(name)
  File "C:\Users\saahe\AppData\Local\Programs\Python\Python38-32\lib\idlelib\editor.py", line 1117, in load_extension
    mod = importlib.import_module(fname)
  File "C:\Users\saahe\AppData\Local\Programs\Python\Python38-32\lib\importlib\__init__.py", line 127, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "<frozen importlib._bootstrap>", line 1014, in _gcd_import
  File "<frozen importlib._bootstrap>", line 991, in _find_and_load
  File "<frozen importlib._bootstrap>", line 973, in _find_and_load_unlocked
ModuleNotFoundError: No module named 'AutoExpand'

Failed to import extension:  CallTips
Failed to load extension 'CallTips'
Traceback (most recent call last):
  File "C:\Users\saahe\AppData\Local\Programs\Python\Python38-32\lib\idlelib\editor.py", line 1115, in load_extension
    mod = importlib.import_module('.' + fname, package=__package__)
  File "C:\Users\saahe\AppData\Local\Programs\Python\Python38-32\lib\importlib\__init__.py", line 127, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "<frozen importlib._bootstrap>", line 1014, in _gcd_import
  File "<frozen importlib._bootstrap>", line 991, in _find_and_load
  File "<frozen importlib._bootstrap>", line 973, in _find_and_load_unlocked
ModuleNotFoundError: No module named 'idlelib.CallTips'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "C:\Users\saahe\AppData\Local\Programs\Python\Python38-32\lib\idlelib\editor.py", line 1099, in load_standard_extensions
    self.load_extension(name)
  File "C:\Users\saahe\AppData\Local\Programs\Python\Python38-32\lib\idlelib\editor.py", line 1117, in load_extension
    mod = importlib.import_module(fname)
  File "C:\Users\saahe\AppData\Local\Programs\Python\Python38-32\lib\importlib\__init__.py", line 127, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "<frozen importlib._bootstrap>", line 1014, in _gcd_import
  File "<frozen importlib._bootstrap>", line 991, in _find_and_load
  File "<frozen importlib._bootstrap>", line 973, in _find_and_load_unlocked
ModuleNotFoundError: No module named 'CallTips'

Failed to import extension:  ZoomHeight
Failed to load extension 'ZoomHeight'
Traceback (most recent call last):
  File "C:\Users\saahe\AppData\Local\Programs\Python\Python38-32\lib\idlelib\editor.py", line 1115, in load_extension
    mod = importlib.import_module('.' + fname, package=__package__)
  File "C:\Users\saahe\AppData\Local\Programs\Python\Python38-32\lib\importlib\__init__.py", line 127, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "<frozen importlib._bootstrap>", line 1014, in _gcd_import
  File "<frozen importlib._bootstrap>", line 991, in _find_and_load
  File "<frozen importlib._bootstrap>", line 973, in _find_and_load_unlocked
ModuleNotFoundError: No module named 'idlelib.ZoomHeight'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "C:\Users\saahe\AppData\Local\Programs\Python\Python38-32\lib\idlelib\editor.py", line 1099, in load_standard_extensions
    self.load_extension(name)
  File "C:\Users\saahe\AppData\Local\Programs\Python\Python38-32\lib\idlelib\editor.py", line 1117, in load_extension
    mod = importlib.import_module(fname)
  File "C:\Users\saahe\AppData\Local\Programs\Python\Python38-32\lib\importlib\__init__.py", line 127, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "<frozen importlib._bootstrap>", line 1014, in _gcd_import
  File "<frozen importlib._bootstrap>", line 991, in _find_and_load
  File "<frozen importlib._bootstrap>", line 973, in _find_and_load_unlocked
ModuleNotFoundError: No module named 'ZoomHeight'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40031>
_______________________________________

From report at bugs.python.org  Sat Apr 25 05:26:50 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Sat, 25 Apr 2020 09:26:50 +0000
Subject: [issue40388] random.choice integer overflow v3.5.2
In-Reply-To: <1587804987.95.0.247989027545.issue40388@roundup.psfhosted.org>
Message-ID: <1587806810.23.0.376178179444.issue40388@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

What you are describing is not what we mean by a crash (a core dump or segfault); it sounds like a regular Python exception.

Python 3.5 is obsolete and there are no more bug fixes for it except for security fixes.

You have not given us enough information to reproduce the problem. The description you give:

    Function: random.choice()
    Input: 40 digit integer
    Expected output: no crash
    Actual output: Crash


works for me:

    py> import random
    py> random.choice(1234567890123456789012345678901234567890) # 40 digits
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
      File "/usr/local/lib/python3.5/random.py", line 253, in choice
        i = self._randbelow(len(seq))
    TypeError: object of type 'int' has no len()

is exactly the exception I would expect from using an int (whether 1 digit or 400 digits) as argument to random.choice.

Can you show us the actual code you run, and the actual traceback? Please copy and paste it as text, don't take a screen shot.

----------
nosy: +steven.daprano
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40388>
_______________________________________

From report at bugs.python.org  Sat Apr 25 05:46:39 2020
From: report at bugs.python.org (Tal Einat)
Date: Sat, 25 Apr 2020 09:46:39 +0000
Subject: [issue40031] Python Configure IDLE 'Ok' and 'Apply' buttons do not
 seem to work.
In-Reply-To: <1584783754.51.0.582471420619.issue40031@roundup.psfhosted.org>
Message-ID: <1587807999.83.0.672020151116.issue40031@roundup.psfhosted.org>


Tal Einat <taleinat+python at gmail.com> added the comment:

Saaheer, it seems like you have things from older versions of IDLE in your IDLE config file (in your .idlerc directory). Specifically, the built-in extensions have all been converted to be integral parts of IDLE, and must be removed from your configuration file.

I suggest moving/renaming your .idlerc directory so that IDLE can create a new, clean .idlerc. Then make your personal configurations again, preferably using IDLE's configuration dialog.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40031>
_______________________________________

From report at bugs.python.org  Sat Apr 25 06:06:02 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Sat, 25 Apr 2020 10:06:02 +0000
Subject: [issue40360] Deprecate lib2to3 (and 2to3) for future removal
In-Reply-To: <1587530454.25.0.44181585934.issue40360@roundup.psfhosted.org>
Message-ID: <1587809162.26.0.127043222785.issue40360@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
pull_requests:  -19032

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40360>
_______________________________________

From report at bugs.python.org  Sat Apr 25 06:16:33 2020
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 25 Apr 2020 10:16:33 +0000
Subject: [issue40217] The garbage collector doesn't take in account that
 objects of heap allocated types hold a strong reference to their type
In-Reply-To: <1586276621.78.0.843757244355.issue40217@roundup.psfhosted.org>
Message-ID: <1587809793.79.0.889302099397.issue40217@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Serhiy: would it be possible to fix this issue in alpha6? Can we merge PR 19414? In the lack of reply, I think that the best to merge PR 19414.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40217>
_______________________________________

From report at bugs.python.org  Sat Apr 25 06:17:10 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 25 Apr 2020 10:17:10 +0000
Subject: [issue40388] random.choice integer overflow v3.5.2
In-Reply-To: <1587804987.95.0.247989027545.issue40388@roundup.psfhosted.org>
Message-ID: <1587809830.31.0.0423585443559.issue40388@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I suspect that the OP is doing something like `random.choice(range(10**40))`:

    Python 3.8.2 (default, Feb 27 2020, 19:56:42) 
    [Clang 10.0.1 (clang-1001.0.46.4)] on darwin
    Type "help", "copyright", "credits" or "license" for more information.
    >>> import random
    >>> random.choice(range(10**40))
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
      File "/opt/local/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/random.py", line 288, in choice
        i = self._randbelow(len(seq))
    OverflowError: Python int too large to convert to C ssize_t

The advice in this case would be to use something like random.randrange(10**40) instead.

The actual bug here, if there is a bug, has nothing to do with random, but instead has to do with "virtual" sequences whose length exceeds 2**63 - 1. There are other issues in the tracker for this, for example issue 12159.

I suggest closing as "not a bug".

----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40388>
_______________________________________

From report at bugs.python.org  Sat Apr 25 06:58:24 2020
From: report at bugs.python.org (Kay Hayen)
Date: Sat, 25 Apr 2020 10:58:24 +0000
Subject: [issue9417] Declaring a class creates circular references
In-Reply-To: <1280413185.92.0.0897116981748.issue9417@psf.upfronthosting.co.za>
Message-ID: <1587812304.31.0.889312819693.issue9417@roundup.psfhosted.org>


Kay Hayen <kay.hayen at gmail.com> added the comment:

Today I changed my reference count tests to not use debug Python and came across this issue.

>From my testing, Python3.4 is the first affected version, Python3.3 was still fine, so were 2.7 and 2.6. 

This leaks:

def simpleFunction39():
    class Parent(str):
        pass

This does not:

def simpleFunction39():
    class Parent(object):
        pass

When comparing (or attempted to) gc.get_objects() before and after, I was unable to point to any count that would be different, that was confusing. I can rule out a mistake in my changes to how the counts are achieved, because every other reference count test works.

----------
nosy: +kayhayen

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue9417>
_______________________________________

From report at bugs.python.org  Sat Apr 25 06:59:26 2020
From: report at bugs.python.org (Kay Hayen)
Date: Sat, 25 Apr 2020 10:59:26 +0000
Subject: [issue9417] Declaring a class creates circular references
In-Reply-To: <1280413185.92.0.0897116981748.issue9417@psf.upfronthosting.co.za>
Message-ID: <1587812366.01.0.772521169733.issue9417@roundup.psfhosted.org>


Kay Hayen <kay.hayen at gmail.com> added the comment:

What I also meant to say, is that debug Python is not affected, and this had me deeply confused. Any ideas how that could happen?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue9417>
_______________________________________

From report at bugs.python.org  Sat Apr 25 07:35:44 2020
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Sat, 25 Apr 2020 11:35:44 +0000
Subject: [issue40387] queue example it does not work
In-Reply-To: <1587801535.61.0.75411956327.issue40387@roundup.psfhosted.org>
Message-ID: <1587814544.21.0.0474943630509.issue40387@roundup.psfhosted.org>


R?mi Lapeyre <remi.lapeyre at henki.fr> added the comment:

In general examples in the documentation may lack some things like imports as they are implicit but in this case it also lack do_work(), source() and num_worker_threads.

You could use os.cpu_count() instead of your hard-coded value and the comment.

Can you open a pull request with your change?

----------
nosy: +remi.lapeyre

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40387>
_______________________________________

From report at bugs.python.org  Sat Apr 25 08:55:22 2020
From: report at bugs.python.org (Stephan Troyer)
Date: Sat, 25 Apr 2020 12:55:22 +0000
Subject: [issue40377] APPDATA location in Microsoft Store version
In-Reply-To: <1587734754.85.0.727792315124.issue40377@roundup.psfhosted.org>
Message-ID: <1587819322.62.0.562759291562.issue40377@roundup.psfhosted.org>


Stephan Troyer <stephantroyer at live.at> added the comment:

> ... provide a way to output the relevant contents of the file on the console rather than just printing the path ...

Thanks, I didn't think of that option, that is probably the best way to deal with it. I'll file a bug to jupyter and vscode-python (which in my case relied on that data).
In principle I like the AppData redirection, since that way package specific data also automatically gets cleaned up when uninstalling the Python app.

Because returning paths which include ApplicationData.Current.LocalFolder (and having 3rd party apps accessing files in there) is also suboptimal, I'm closing this issue.

> ... apart from a little bit of startup code, it's exactly the same as the regular install.

I know, I only mentioned it, since I don't take it for granted to offer a Microsoft Store package and deal with such specific issues, if there exists already another package for Windows ?

----------
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40377>
_______________________________________

From report at bugs.python.org  Sat Apr 25 10:15:55 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Sat, 25 Apr 2020 14:15:55 +0000
Subject: [issue40375] Add the UNSELECT command to imaplib
In-Reply-To: <1587689097.33.0.419593805597.issue40375@roundup.psfhosted.org>
Message-ID: <1587824155.44.0.64228481223.issue40375@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
keywords: +patch
pull_requests: +19034
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/19712

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40375>
_______________________________________

From report at bugs.python.org  Sat Apr 25 10:48:40 2020
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 25 Apr 2020 14:48:40 +0000
Subject: [issue40387] queue example it does not work
In-Reply-To: <1587801535.61.0.75411956327.issue40387@roundup.psfhosted.org>
Message-ID: <1587826120.05.0.306737345527.issue40387@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch
nosy: +python-dev
nosy_count: 3.0 -> 4.0
pull_requests: +19035
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19713

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40387>
_______________________________________

From report at bugs.python.org  Sat Apr 25 12:18:48 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 25 Apr 2020 16:18:48 +0000
Subject: [issue15185] Validate callbacks in 'contextlib.ExitStack.callback()'
In-Reply-To: <1340663500.78.0.8609663108.issue15185@psf.upfronthosting.co.za>
Message-ID: <1587831528.61.0.0781253858188.issue15185@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I think it is rather a work for linter's and static type checking. Runtime check adds an overhead, and it is expected that in correct program it will always pass. You need the check only while write the program, it may help in debugging. But once it has been debugged and tested, the check becomes a waste of CPU time.

Since this issue was not touched for 8 years and there is a large progress in static code analysis, I suggest to close it.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue15185>
_______________________________________

From report at bugs.python.org  Sat Apr 25 12:54:49 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 25 Apr 2020 16:54:49 +0000
Subject: [issue40388] random.choice integer overflow v3.5.2
In-Reply-To: <1587804987.95.0.247989027545.issue40388@roundup.psfhosted.org>
Message-ID: <1587833689.85.0.585672646829.issue40388@roundup.psfhosted.org>


Change by Mark Dickinson <dickinsm at gmail.com>:


----------
resolution:  -> not a bug
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40388>
_______________________________________

From report at bugs.python.org  Sat Apr 25 13:06:07 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Sat, 25 Apr 2020 17:06:07 +0000
Subject: [issue40375] Add the UNSELECT command to imaplib
In-Reply-To: <1587689097.33.0.419593805597.issue40375@roundup.psfhosted.org>
Message-ID: <1587834367.94.0.943078250642.issue40375@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
assignee:  -> corona10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40375>
_______________________________________

From report at bugs.python.org  Sat Apr 25 13:54:07 2020
From: report at bugs.python.org (hai shi)
Date: Sat, 25 Apr 2020 17:54:07 +0000
Subject: [issue40092] Crash in _PyThreadState_DeleteExcept() at fork in the
 process child
In-Reply-To: <1585329415.65.0.534969367772.issue40092@roundup.psfhosted.org>
Message-ID: <1587837247.11.0.737930456274.issue40092@roundup.psfhosted.org>


hai shi <shihai1991 at 126.com> added the comment:

>since we are going to delete the threading.Thread object with its _tstate_lock object anymore.

Do we have any pep or discuss record about this plan?

> * Modify release_sentinel() to not use the lock: avoid PyThread_release_lock() call.

Hm, I am not sure about it. Looks like we can not remove it directly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40092>
_______________________________________

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: [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 14:06:40 2020
From: report at bugs.python.org (Vladislav Serebrennikov)
Date: Sat, 25 Apr 2020 18:06:40 +0000
Subject: [issue40389] No straightforward way to get repr of Optional
In-Reply-To: <1587837782.6.0.0357631726958.issue40389@roundup.psfhosted.org>
Message-ID: <1587838000.07.0.439864330497.issue40389@roundup.psfhosted.org>


Change by Vladislav Serebrennikov <brainvlad at gmail.com>:


----------
keywords: +patch
pull_requests: +19036
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19714

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40389>
_______________________________________

From report at bugs.python.org  Sat Apr 25 14:27:08 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 25 Apr 2020 18:27:08 +0000
Subject: [issue40387] queue example it does not work
In-Reply-To: <1587801535.61.0.75411956327.issue40387@roundup.psfhosted.org>
Message-ID: <1587839228.19.0.926326753632.issue40387@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

The example is supposed to be a sketch of the overall pattern.  IMO, putting concrete and useless implementations of do_work() and source() make the example less intelligible.

Instead, we can add a note that the user needs to supply their own do_work() and source().

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40387>
_______________________________________

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: [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 15:25:13 2020
From: report at bugs.python.org (Benjamin Edwards)
Date: Sat, 25 Apr 2020 19:25:13 +0000
Subject: [issue40390] Implement a C API for channel_send_wait for
 subinterpreters.
In-Reply-To: <1587842364.13.0.0340365069537.issue40390@roundup.psfhosted.org>
Message-ID: <1587842713.63.0.521579473482.issue40390@roundup.psfhosted.org>


Change by Benjamin Edwards <benjaminedwards at live.co.uk>:


----------
keywords: +patch
pull_requests: +19038
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19715

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40390>
_______________________________________

From report at bugs.python.org  Sat Apr 25 16:11:25 2020
From: report at bugs.python.org (Tal Einat)
Date: Sat, 25 Apr 2020 20:11:25 +0000
Subject: [issue38580] select()'s documentation claims only sequences are
 accepted, but it allows all iterables
In-Reply-To: <1571915326.93.0.150606644361.issue38580@roundup.psfhosted.org>
Message-ID: <1587845485.48.0.854185339039.issue38580@roundup.psfhosted.org>


Tal Einat <taleinat+python at gmail.com> added the comment:

It seems pretty clear to me that we should simply update the docs as suggested.

If nobody chimes in about this within a week, I intend to merge the PR (GH-16832) with the small fixes I've suggested there.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38580>
_______________________________________

From report at bugs.python.org  Sat Apr 25 16:55:43 2020
From: report at bugs.python.org (Frank Thommen)
Date: Sat, 25 Apr 2020 20:55:43 +0000
Subject: [issue34028] Python 3.7.0 wont compile with SSL Support 1.1.0 >
 alledged missing X509_VERIFY_PARAM_set1_host() support
In-Reply-To: <1530609211.5.0.56676864532.issue34028@psf.upfronthosting.co.za>
Message-ID: <1587848143.81.0.80982679089.issue34028@roundup.psfhosted.org>


Change by Frank Thommen <python at drosera.ch>:


----------
nosy:  -fthommen

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34028>
_______________________________________

From report at bugs.python.org  Sat Apr 25 17:06:38 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 25 Apr 2020 21:06:38 +0000
Subject: [issue40031] IDLE fails trying to inport old idlelib file names for
 config
In-Reply-To: <1584783754.51.0.582471420619.issue40031@roundup.psfhosted.org>
Message-ID: <1587848798.06.0.671443442828.issue40031@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Saaheer, using the 'File: Browse...' button under the comment box, please upload (if you still have it) the .../.idlerc/config-extensions.cfg that results in this failure.  Most idlelib files were renamed in 3.6.  'AutoExpand' and 'CallTips' are 2 of the old names.  Built-in extensions were converted after that, and I intended that the new code be compatible with existing customizations.  Current IDLE should not fail this way and your file should help with the fix.

You should only need to rename this file to config-extensions.cfg.old or something and leave the other files in .idlerc alone.

----------
stage:  -> test needed
title: Python Configure IDLE 'Ok' and 'Apply' buttons do not seem to work. -> IDLE fails trying to inport old idlelib file names for config

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40031>
_______________________________________

From report at bugs.python.org  Sat Apr 25 17:14:22 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 25 Apr 2020 21:14:22 +0000
Subject: [issue9417] Declaring a class creates circular references
In-Reply-To: <1280413185.92.0.0897116981748.issue9417@psf.upfronthosting.co.za>
Message-ID: <1587849262.35.0.163283192779.issue9417@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Kay, please ask your question on python-list or a similar forum.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue9417>
_______________________________________

From report at bugs.python.org  Sat Apr 25 17:23:15 2020
From: report at bugs.python.org (Gregory Szorc)
Date: Sat, 25 Apr 2020 21:23:15 +0000
Subject: [issue40333] Request for multi-phase initialization API to run code
 after importlib init
In-Reply-To: <1587327033.84.0.66503294203.issue40333@roundup.psfhosted.org>
Message-ID: <1587849795.14.0.963792908661.issue40333@roundup.psfhosted.org>


Gregory Szorc <gregory.szorc at gmail.com> added the comment:

Having approached this with a fresh brain, I was able to port PyOxidizer to use the multi-phase initialization API with minimal regressions!

The relevant code exists at https://github.com/indygreg/PyOxidizer/blob/b5aa2b3a96dbd01e9d78857e124f1052f42f86c6/pyembed/src/interpreter.rs#L550.

Here's the sequence:

1) Initialize core
2) Import our custom built-in extension module
3) Run some more code to initialize our extension module (update sys.meta_path, etc)
4) Initialize main
5) Remove PathFinder if filesystem imports are disabled

#5 isn't ideal: I would prefer an API to disable the registration of that importer completely. But PyOxidizer's importer is first on sys.meta_path and PathFinder shouldn't come into play. So it should be mostly harmless.

A super minor paper cut is the lack of a PyConfig_SetBytesString() variant for PyWideStringList_Append(). It was slightly annoying having to convert a POSIX char* path to a wchar_t* since paths on POSIX are bytes.

Another potential area for improvement is around error handling before main is initialized. I'd like to represent PyErr raised during initialization as a Rust String, as PyErr isn't appropriate since there isn't a fully initialized Python interpreter. However, I discovered that serializing PyErr to strings is a bit brittle before main is initialized. e.g. https://docs.python.org/3/faq/extending.html#id11 says to use PyErr_Print() and replace sys.stdout. But sys.stdout isn't initialized yet and I'm scared to touch it. It also appears various functions in traceback rely on facilities from an initialized interpreter (such as finding sources). It would be useful if there were some kind of PyErr API that returned a PyString (or PyStatus) and was guaranteed to work before main is initialized.

Overall, the new code in PyOxidizer is much, much cleaner! Thanks again for the new API!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40333>
_______________________________________

From report at bugs.python.org  Sat Apr 25 18:26:29 2020
From: report at bugs.python.org (Nicholas Prowse)
Date: Sat, 25 Apr 2020 22:26:29 +0000
Subject: [issue40388] random.choice integer overflow v3.5.2
In-Reply-To: <1587804987.95.0.247989027545.issue40388@roundup.psfhosted.org>
Message-ID: <1587853589.94.0.48167982649.issue40388@roundup.psfhosted.org>


Nicholas Prowse <nick5990 at yahoo.co.uk> added the comment:

Code as requested is similar to the below:

N = <40 digit int>
sequence=range(1,N)
a = random.choice(sequence)

Since you class the error previously mentioned as an exception, what function should be used instead for choosing a random integer between 1 and including N-1?

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40388>
_______________________________________

From report at bugs.python.org  Sat Apr 25 18:27:40 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Sat, 25 Apr 2020 22:27:40 +0000
Subject: [issue40337] builtins.RuntimeError: Caught RuntimeError in pin memory
 thread for device 0.
In-Reply-To: <1587391255.49.0.649010801229.issue40337@roundup.psfhosted.org>
Message-ID: <1587853660.38.0.440694142363.issue40337@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

If you have more information, please provide it and re-open this issue.

----------
resolution:  -> rejected
stage:  -> resolved
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40337>
_______________________________________

From report at bugs.python.org  Sat Apr 25 18:57:44 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Sat, 25 Apr 2020 22:57:44 +0000
Subject: [issue40388] random.choice integer overflow v3.5.2
In-Reply-To: <1587853589.94.0.48167982649.issue40388@roundup.psfhosted.org>
Message-ID: <20200425225349.GD10268@ando.pearwood.info>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

Take your pick between either of these:

random.randrange(1, N)
random.randint(1, N-1)

https://docs.python.org/3/library/random.html#functions-for-integers

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40388>
_______________________________________

From report at bugs.python.org  Sat Apr 25 20:50:57 2020
From: report at bugs.python.org (mike.parker)
Date: Sun, 26 Apr 2020 00:50:57 +0000
Subject: [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  Sat Apr 25 21:56:09 2020
From: report at bugs.python.org (Zachary Ware)
Date: Sun, 26 Apr 2020 01:56:09 +0000
Subject: [issue27540] msvcrt.ungetwch() calls _ungetch()
In-Reply-To: <1468745012.08.0.321893951317.issue27540@psf.upfronthosting.co.za>
Message-ID: <1587866169.79.0.665968317831.issue27540@roundup.psfhosted.org>


Change by Zachary Ware <zachary.ware at gmail.com>:


----------
resolution:  -> out of date
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27540>
_______________________________________

From report at bugs.python.org  Sat Apr 25 22:11:58 2020
From: report at bugs.python.org (Zachary Ware)
Date: Sun, 26 Apr 2020 02:11:58 +0000
Subject: [issue38601] Couldn't able to install multiple python minor version
 in windows due to EXE script
In-Reply-To: <1572178164.18.0.338058343246.issue38601@roundup.psfhosted.org>
Message-ID: <1587867118.3.0.317386704478.issue38601@roundup.psfhosted.org>


Change by Zachary Ware <zachary.ware at gmail.com>:


----------
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38601>
_______________________________________

From report at bugs.python.org  Sat Apr 25 22:11:47 2020
From: report at bugs.python.org (Zachary Ware)
Date: Sun, 26 Apr 2020 02:11:47 +0000
Subject: [issue38601] Couldn't able to install multiple python minor version
 in windows due to EXE script
In-Reply-To: <1572178164.18.0.338058343246.issue38601@roundup.psfhosted.org>
Message-ID: <1587867107.11.0.269799706075.issue38601@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

Lacking followup from the OP, I'm closing the issue.  If more information is brought forward later, it can be reopened.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38601>
_______________________________________

From report at bugs.python.org  Sat Apr 25 22:19:18 2020
From: report at bugs.python.org (Zachary Ware)
Date: Sun, 26 Apr 2020 02:19:18 +0000
Subject: [issue21614] Case sensitivity problem in multiprocessing.
In-Reply-To: <1401479749.7.0.550679517464.issue21614@psf.upfronthosting.co.za>
Message-ID: <1587867558.52.0.0134376513627.issue21614@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

With no activity here in over 5 years and no confirmation on any version but 2.7, I'm closing the issue.  If it can be confirmed on 3.8, the issue can be reopened.

----------
nosy: +zach.ware
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21614>
_______________________________________

From report at bugs.python.org  Sat Apr 25 23:19:09 2020
From: report at bugs.python.org (Zachary Ware)
Date: Sun, 26 Apr 2020 03:19:09 +0000
Subject: [issue34283] [Windows] Python 2 mishandles console code page after
 setlocale
In-Reply-To: <1532972971.81.0.56676864532.issue34283@psf.upfronthosting.co.za>
Message-ID: <1587871149.06.0.999241570245.issue34283@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

As this issue is specific to 2.7, I'm closing it.

----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34283>
_______________________________________

From report at bugs.python.org  Sun Apr 26 00:32:57 2020
From: report at bugs.python.org (Zachary Ware)
Date: Sun, 26 Apr 2020 04:32:57 +0000
Subject: [issue29796] [2.7] test_weakref hangs on Python 2.7 on Windows
In-Reply-To: <1489280495.74.0.987527414659.issue29796@psf.upfronthosting.co.za>
Message-ID: <1587875577.39.0.621584920971.issue29796@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

Looks like we forgot to close this one; as far as I can tell it was fixed.  Being 2.7-only, it's time to be closed anyway :)

----------
resolution:  -> fixed
stage: test needed -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29796>
_______________________________________

From report at bugs.python.org  Sun Apr 26 00:58:54 2020
From: report at bugs.python.org (Zackery Spytz)
Date: Sun, 26 Apr 2020 04:58:54 +0000
Subject: [issue25560] Unhandled warning in test_unicode_file
In-Reply-To: <1446748318.85.0.363249133538.issue25560@psf.upfronthosting.co.za>
Message-ID: <1587877134.21.0.944007570832.issue25560@roundup.psfhosted.org>


Zackery Spytz <zspytz at gmail.com> added the comment:

Python 2 is EOL.

----------
nosy: +ZackerySpytz

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25560>
_______________________________________

From report at bugs.python.org  Sun Apr 26 01:05:52 2020
From: report at bugs.python.org (Dennis Sweeney)
Date: Sun, 26 Apr 2020 05:05:52 +0000
Subject: [issue40380] Errors during make test python 3.8.2
In-Reply-To: <1587757709.05.0.540074868271.issue40380@roundup.psfhosted.org>
Message-ID: <1587877552.16.0.00364902973227.issue40380@roundup.psfhosted.org>


Dennis Sweeney <sweeney.dennis650 at gmail.com> added the comment:

Thanks for reaching out! This is about test failures, not problems with installation process, correct? I took a look at the failures:

======================================================================
ERROR: test_add_file_after_2107 (test.test_zipfile.StoredTestsWithSourceFile)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/gpfs/scratch/sjfleck/modulefiles/Python-3.8.2/Lib/test/test_zipfile.py", line 606, in test_add_file_after_2107
    os.utime(TESTFN, (ts, ts))
OSError: [Errno 75] Value too large for defined data type

----------------------------------------------------------------------

It looks like the test excepts an OverflowError but not an OSError, so I think it should do both.


======================================================================
ERROR: test_setrusage_refcount (test.test_resource.ResourceTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/gpfs/scratch/sjfleck/modulefiles/Python-3.8.2/Lib/test/test_resource.py", line 131, in test_setrusage_refcount
    resource.setrlimit(resource.RLIMIT_CPU, BadSequence())
ValueError: not allowed to raise maximum limit

----------------------------------------------------------------------

I think this is a bug in the test: a non-root process increasing its hard resource maximum should raise. So I think this maybe BadSequence()[i] should return limits[i].



======================================================================
FAIL: test_touch_common (test.test_pathlib.PosixPathTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/gpfs/scratch/sjfleck/modulefiles/Python-3.8.2/Lib/test/test_pathlib.py", line 1761, in test_touch_common
    self.assertGreaterEqual(st.st_mtime_ns, old_mtime_ns)
AssertionError: 1587754085552569712 not greater than or equal to 1587754085553625000

----------------------------------------------------------------------

Similar to: https://bugs.python.org/issue19715




======================================================================
FAIL: test_sendall_interrupted (test.test_socket.GeneralModuleTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/gpfs/scratch/sjfleck/modulefiles/Python-3.8.2/Lib/test/test_socket.py", line 1527, in test_sendall_interrupted
    self.check_sendall_interrupted(False)
  File "/gpfs/scratch/sjfleck/modulefiles/Python-3.8.2/Lib/test/test_socket.py", line 1514, in check_sendall_interrupted
    c.sendall(b"x" * support.SOCK_MAX_SIZE)
AssertionError: ZeroDivisionError not raised

======================================================================
FAIL: test_sendall_interrupted_with_timeout (test.test_socket.GeneralModuleTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/gpfs/scratch/sjfleck/modulefiles/Python-3.8.2/Lib/test/test_socket.py", line 1530, in test_sendall_interrupted_with_timeout
    self.check_sendall_interrupted(True)
  File "/gpfs/scratch/sjfleck/modulefiles/Python-3.8.2/Lib/test/test_socket.py", line 1514, in check_sendall_interrupted
    c.sendall(b"x" * support.SOCK_MAX_SIZE)
AssertionError: ZeroDivisionError not raised

----------------------------------------------------------------------

Looks related to https://bugs.python.org/issue18643 .
Perhaps SOCK_MAX_SIZE needs to be increased for this test, or be made system-dependent?



======================================================================
ERROR: test_ignore (test.test_multiprocessing_forkserver.TestIgnoreEINTR)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/gpfs/scratch/sjfleck/modulefiles/Python-3.8.2/Lib/test/_test_multiprocessing.py", line 4874, in test_ignore
    os.kill(p.pid, signal.SIGUSR1)
ProcessLookupError: [Errno 3] No such process

----------------------------------------------------------------------

Looks similar to: https://bugs.python.org/issue33532

----------
nosy: +Dennis Sweeney

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40380>
_______________________________________

From report at bugs.python.org  Sun Apr 26 01:13:15 2020
From: report at bugs.python.org (Dennis Sweeney)
Date: Sun, 26 Apr 2020 05:13:15 +0000
Subject: [issue40380] OS-related test failures on Linux in Python 3.8.2
In-Reply-To: <1587757709.05.0.540074868271.issue40380@roundup.psfhosted.org>
Message-ID: <1587877995.96.0.0142668875597.issue40380@roundup.psfhosted.org>


Change by Dennis Sweeney <sweeney.dennis650 at gmail.com>:


----------
components: +Tests -Installation
title: Errors during make test python 3.8.2 -> OS-related test failures on Linux in Python 3.8.2
type: compile error -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40380>
_______________________________________

From report at bugs.python.org  Sun Apr 26 01:21:02 2020
From: report at bugs.python.org (Zachary Ware)
Date: Sun, 26 Apr 2020 05:21:02 +0000
Subject: [issue32049] 2.7.14 does not uninstall cleanly if installation was
 run as SYSTEM account (SCCM)
In-Reply-To: <1510839557.93.0.213398074469.issue32049@psf.upfronthosting.co.za>
Message-ID: <1587878462.69.0.620552768451.issue32049@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

Hi Sven,

I'm sorry this issue never got attention before the end of 2.7, but as we have now reached that point I'm going to go ahead and close this issue.  I hope it didn't cause you too much trouble!  If you can also reproduce this with a current version of Python 3, please either reopen this issue or open a new one.

----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32049>
_______________________________________

From report at bugs.python.org  Sun Apr 26 01:22:09 2020
From: report at bugs.python.org (Zachary Ware)
Date: Sun, 26 Apr 2020 05:22:09 +0000
Subject: [issue30725] Windows installer for 2.7.13 doesn't install pip when
 installing to C:\Program Files
In-Reply-To: <1498067947.84.0.203482425844.issue30725@psf.upfronthosting.co.za>
Message-ID: <1587878529.49.0.664244493942.issue30725@roundup.psfhosted.org>


Change by Zachary Ware <zachary.ware at gmail.com>:


----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30725>
_______________________________________

From report at bugs.python.org  Sun Apr 26 01:29:04 2020
From: report at bugs.python.org (Zachary Ware)
Date: Sun, 26 Apr 2020 05:29:04 +0000
Subject: [issue26992] 64-bit Python 2.7.11 hangs in 64-bit Windows 10 - CMD
 and Git Bash
In-Reply-To: <1462886435.44.0.374942055679.issue26992@psf.upfronthosting.co.za>
Message-ID: <1587878944.42.0.519648182319.issue26992@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

As this appears to be a 2.7-only issue, I'm going to go ahead and close it.

----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26992>
_______________________________________

From report at bugs.python.org  Sun Apr 26 01:58:11 2020
From: report at bugs.python.org (Zachary Ware)
Date: Sun, 26 Apr 2020 05:58:11 +0000
Subject: [issue28551] sysconfig.py wrong _PROJECT_BASE for Py2.7 Windows 64bit
 PC/VS9.0
In-Reply-To: <1477691954.87.0.162134126472.issue28551@psf.upfronthosting.co.za>
Message-ID: <1587880691.29.0.642368529346.issue28551@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

Sorry I missed this one!  This was actually addressed in bpo-30342 (GH-1544), but it would have been fixed 7 months sooner if this one hadn't fallen off my radar.  Thanks for the patch anyway!

----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
superseder:  -> [2.7] sysconfig.is_python_build() doesn't work if Python is built with VS 2008

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28551>
_______________________________________

From report at bugs.python.org  Sun Apr 26 02:04:58 2020
From: report at bugs.python.org (OhBonsai)
Date: Sun, 26 Apr 2020 06:04:58 +0000
Subject: [issue40383] weakref class name are hardcoded in reprs
In-Reply-To: <1587783917.63.0.137882074418.issue40383@roundup.psfhosted.org>
Message-ID: <1587881098.56.0.242781059308.issue40383@roundup.psfhosted.org>


Change by OhBonsai <letbonsaibe at gmail.com>:


----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40383>
_______________________________________

From report at bugs.python.org  Sun Apr 26 02:09:15 2020
From: report at bugs.python.org (Zachary Ware)
Date: Sun, 26 Apr 2020 06:09:15 +0000
Subject: [issue14141] 2.7.2 64-bit Windows library has __impt_Py* for several
 symbols instead of __imp__Py*
In-Reply-To: <1330360352.45.0.311661027338.issue14141@psf.upfronthosting.co.za>
Message-ID: <1587881355.82.0.829849075578.issue14141@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

As 2.7 is now out of support, I'm going to go ahead and close the issue.

----------
nosy: +zach.ware
resolution:  -> out of date
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue14141>
_______________________________________

From report at bugs.python.org  Sun Apr 26 02:11:22 2020
From: report at bugs.python.org (Zachary Ware)
Date: Sun, 26 Apr 2020 06:11:22 +0000
Subject: [issue23121] pip.exe breaks if python 2.7.9 is installed under
 c:\Program Files\Python
In-Reply-To: <1419693013.55.0.898507304072.issue23121@psf.upfronthosting.co.za>
Message-ID: <1587881482.09.0.964502760671.issue23121@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

As 2.7 is now out of support, I'm going to go ahead and close this issue.

----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23121>
_______________________________________

From report at bugs.python.org  Sun Apr 26 02:14:17 2020
From: report at bugs.python.org (Zachary Ware)
Date: Sun, 26 Apr 2020 06:14:17 +0000
Subject: [issue21946] 'python -u' yields trailing carriage return '\r'
 (Python2 for Windows)
In-Reply-To: <1404910318.13.0.0636532194943.issue21946@psf.upfronthosting.co.za>
Message-ID: <1587881657.69.0.804229602599.issue21946@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

It's not entirely clear from a quick read whether this was actually fixed or not (probably?), but as 2.7 is out of support it no longer matters :)

----------
nosy: +zach.ware
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21946>
_______________________________________

From report at bugs.python.org  Sun Apr 26 02:15:47 2020
From: report at bugs.python.org (Zachary Ware)
Date: Sun, 26 Apr 2020 06:15:47 +0000
Subject: [issue19351] python msi installers - silent mode
In-Reply-To: <1382450332.98.0.946317884841.issue19351@psf.upfronthosting.co.za>
Message-ID: <1587881747.33.0.176894972153.issue19351@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

As all versions using the MSI installer are now out of support, I'm closing the issue.

----------
nosy: +zach.ware
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19351>
_______________________________________

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: [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 02:27:42 2020
From: report at bugs.python.org (Zachary Ware)
Date: Sun, 26 Apr 2020 06:27:42 +0000
Subject: [issue25563] Windows 10: _tkinter import fails
In-Reply-To: <1446762509.1.0.723427764258.issue25563@psf.upfronthosting.co.za>
Message-ID: <1587882462.2.0.0615282251048.issue25563@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

With no other context, I'm going to assume this was specific to 2.7, which is now out of support.

----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25563>
_______________________________________

From report at bugs.python.org  Sun Apr 26 02:34:02 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 26 Apr 2020 06:34:02 +0000
Subject: [issue40392] Remove deprecated _field_types in typing.NamedTuple
In-Reply-To: <1587881873.08.0.712123124267.issue40392@roundup.psfhosted.org>
Message-ID: <1587882842.21.0.531360267251.issue40392@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Sorry for the noise, I didn't check the master branch properly. Closing this as duplicate.

----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Remove the _field_types attribute of NamedTuple

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40392>
_______________________________________

From report at bugs.python.org  Sun Apr 26 02:57:17 2020
From: report at bugs.python.org (Zachary Ware)
Date: Sun, 26 Apr 2020 06:57:17 +0000
Subject: [issue25560] Unhandled warning in test_unicode_file
In-Reply-To: <1446748318.85.0.363249133538.issue25560@psf.upfronthosting.co.za>
Message-ID: <1587884237.42.0.334799518121.issue25560@roundup.psfhosted.org>


Change by Zachary Ware <zachary.ware at gmail.com>:


----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25560>
_______________________________________

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: [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 05:59:10 2020
From: report at bugs.python.org (OhBonsai)
Date: Sun, 26 Apr 2020 09:59:10 +0000
Subject: [issue40383] weakref class name are hardcoded in reprs
In-Reply-To: <1587783917.63.0.137882074418.issue40383@roundup.psfhosted.org>
Message-ID: <1587895150.33.0.765993644089.issue40383@roundup.psfhosted.org>


Change by OhBonsai <letbonsaibe at gmail.com>:


----------
components: +Library (Lib) -Documentation
nosy:  -docs at python

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40383>
_______________________________________

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: [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: [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 10:24:33 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 26 Apr 2020 14:24:33 +0000
Subject: [issue40394] difflib.SequenceMatcher.find_longest_match default
 arguments
In-Reply-To: <1587910558.56.0.865649390619.issue40394@roundup.psfhosted.org>
Message-ID: <1587911073.64.0.127134779863.issue40394@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +tim.peters

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40394>
_______________________________________

From report at bugs.python.org  Sun Apr 26 10:25:05 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 26 Apr 2020 14:25:05 +0000
Subject: [issue40395] Scripts folder is Empty in python 3.8.2 for Windows 7.
In-Reply-To: <1587910690.73.0.0218819691356.issue40395@roundup.psfhosted.org>
Message-ID: <1587911105.12.0.825038446681.issue40395@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
components: +Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/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: [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:08:41 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 26 Apr 2020 16:08:41 +0000
Subject: [issue40396] Support GenericAlias in typing
In-Reply-To: <1587916977.12.0.758725068649.issue40396@roundup.psfhosted.org>
Message-ID: <1587917321.25.0.674416936009.issue40396@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch
pull_requests: +19039
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19718

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40396>
_______________________________________

From report at bugs.python.org  Sun Apr 26 12:14:22 2020
From: report at bugs.python.org (Zachary Ware)
Date: Sun, 26 Apr 2020 16:14:22 +0000
Subject: [issue27562] Import error encodings (Windows xp compatibility)
In-Reply-To: <1468849701.41.0.980015051967.issue27562@psf.upfronthosting.co.za>
Message-ID: <1587917662.69.0.0960832718382.issue27562@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

As 2.7 has now reached end-of-life and with it the last version to support Windows XP, I'm closing the issue.

----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27562>
_______________________________________

From report at bugs.python.org  Sun Apr 26 12:25:30 2020
From: report at bugs.python.org (Zachary Ware)
Date: Sun, 26 Apr 2020 16:25:30 +0000
Subject: [issue37518] Python-2.7.16 fails to build with --enable-shared
In-Reply-To: <1562467439.87.0.798383157729.issue37518@roundup.psfhosted.org>
Message-ID: <1587918330.77.0.268211954778.issue37518@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

Hi Willie,

Sorry this never got attention before 2.7 reached end-of-life, but as that has now happened, I'm closing the issue.

That said, I suspect your issue here was with library search path; it wasn't actually 2.7.5 that was installed by the install of 2.7.16, but rather it was the system's 2.7.5 library that was loaded instead of the installation's 2.7.16 due to the latter's directory being either not on the search path or after the system's Python library location.  I'm not sure if there's really a good way to have two separate patch versions of Python, both with shared libraries rather than static, without winding up with some confusion about which library should be loaded by which application.

----------
nosy: +zach.ware
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37518>
_______________________________________

From report at bugs.python.org  Sun Apr 26 12:27:46 2020
From: report at bugs.python.org (Zachary Ware)
Date: Sun, 26 Apr 2020 16:27:46 +0000
Subject: [issue12503] "with" statement error message is more confusing in Py2.7
In-Reply-To: <1309924683.37.0.310972531328.issue12503@psf.upfronthosting.co.za>
Message-ID: <1587918466.66.0.500530964585.issue12503@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

As 2.7 has reached end-of-life, I'm closing the issue.

----------
nosy: +zach.ware
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue12503>
_______________________________________

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: [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:37:04 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 26 Apr 2020 16:37:04 +0000
Subject: [issue40397] Refactor typing._GenericAlias
In-Reply-To: <1587918915.07.0.818996162208.issue40397@roundup.psfhosted.org>
Message-ID: <1587919024.34.0.899008903868.issue40397@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch
pull_requests: +19040
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19719

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40397>
_______________________________________

From report at bugs.python.org  Sun Apr 26 12:42:13 2020
From: report at bugs.python.org (Segev Finer)
Date: Sun, 26 Apr 2020 16:42:13 +0000
Subject: [issue39010] ProactorEventLoop raises unhandled ConnectionResetError
In-Reply-To: <1575924458.67.0.403977169674.issue39010@roundup.psfhosted.org>
Message-ID: <1587919333.82.0.915256563292.issue39010@roundup.psfhosted.org>


Change by Segev Finer <segev208 at gmail.com>:


----------
nosy: +Segev Finer

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39010>
_______________________________________

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: [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:48:14 2020
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Sun, 26 Apr 2020 16:48:14 +0000
Subject: [issue40372] doctest example programs should exit 1 if any test fails
In-Reply-To: <1587629772.69.0.383881965755.issue40372@roundup.psfhosted.org>
Message-ID: <1587919694.89.0.653397182997.issue40372@roundup.psfhosted.org>


Change by R?mi Lapeyre <remi.lapeyre at henki.fr>:


----------
nosy: +remi.lapeyre, tim.peters
versions:  -Python 2.7, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40372>
_______________________________________

From report at bugs.python.org  Sun Apr 26 12:51:38 2020
From: report at bugs.python.org (Zachary Ware)
Date: Sun, 26 Apr 2020 16:51:38 +0000
Subject: [issue8536] Support new features of ZLIB 1.2.7
In-Reply-To: <1272302591.08.0.11918516326.issue8536@psf.upfronthosting.co.za>
Message-ID: <1587919898.61.0.830214098126.issue8536@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

In the intervening 8 years since there was last activity in this issue, zlib 1.2.11 has been released and probably has even more new features.  However, I think rather than looking for new features to implement, we should create specific issues to implement new features as use cases for them come up; chances are, some of these have already happened without reference to this isuse.  As such, I'm going to go ahead and close this issue.

----------
nosy: +zach.ware
resolution:  -> postponed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue8536>
_______________________________________

From report at bugs.python.org  Sun Apr 26 12:54:07 2020
From: report at bugs.python.org (Zachary Ware)
Date: Sun, 26 Apr 2020 16:54:07 +0000
Subject: [issue15408] os.fork/os.popen behaviour change between 2.7 and 3.2
In-Reply-To: <1342799760.81.0.0479132559422.issue15408@psf.upfronthosting.co.za>
Message-ID: <1587920047.03.0.426945608251.issue15408@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

Given that you both nearly agreed to "wont fix" 8 years ago and 2.7 is now EOL, I'm going to go ahead and close the issue that way :)

----------
nosy: +zach.ware
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue15408>
_______________________________________

From report at bugs.python.org  Sun Apr 26 12:57:43 2020
From: report at bugs.python.org (Zachary Ware)
Date: Sun, 26 Apr 2020 16:57:43 +0000
Subject: [issue17268] Context managers written as C types no longer work in
 Python 2.7
In-Reply-To: <1361464311.73.0.77004817262.issue17268@psf.upfronthosting.co.za>
Message-ID: <1587920263.75.0.383337172094.issue17268@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

As 2.7 has reached EOL, I'm going to go ahead and close the issue.

----------
nosy: +zach.ware
resolution:  -> out of date
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17268>
_______________________________________

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: [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 13:04:27 2020
From: report at bugs.python.org (Zachary Ware)
Date: Sun, 26 Apr 2020 17:04:27 +0000
Subject: [issue18024] dbm module fails to build on SLES11SP1 using 2.7.5 source
In-Reply-To: <1369080710.44.0.400005629221.issue18024@psf.upfronthosting.co.za>
Message-ID: <1587920667.48.0.0771842478694.issue18024@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

As 2.7 has now reached EOL, I'm going to go ahead and close the issue.  Sorry this never got attention, but I'm glad you found a workaround!

----------
nosy: +zach.ware
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18024>
_______________________________________

From report at bugs.python.org  Sun Apr 26 13:06:49 2020
From: report at bugs.python.org (Zachary Ware)
Date: Sun, 26 Apr 2020 17:06:49 +0000
Subject: [issue18567] Python 2.7.5 CENTOS6 Error building dbm using bdb
In-Reply-To: <1374902875.32.0.446892441408.issue18567@psf.upfronthosting.co.za>
Message-ID: <1587920809.61.0.720345331915.issue18567@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

Sorry this issue never got attention, but Python 2.7 has now reached end-of-life and with it the _bsddb module.  As such, I'm going to go ahead and close this issue.

----------
nosy: +zach.ware
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18567>
_______________________________________

From report at bugs.python.org  Sun Apr 26 13:07:44 2020
From: report at bugs.python.org (Zachary Ware)
Date: Sun, 26 Apr 2020 17:07:44 +0000
Subject: [issue18936] 2.7 distutils getopt chokes on unicode option names
In-Reply-To: <1378411388.86.0.748005801735.issue18936@psf.upfronthosting.co.za>
Message-ID: <1587920864.12.0.862895936636.issue18936@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

As 2.7 is now EOL, I'm closing the issue.

----------
nosy: +zach.ware
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18936>
_______________________________________

From report at bugs.python.org  Sun Apr 26 13:12:02 2020
From: report at bugs.python.org (Zachary Ware)
Date: Sun, 26 Apr 2020 17:12:02 +0000
Subject: [issue16326] distutils build_ext fails to set library_dirs in 2.7.2
 on Linux
In-Reply-To: <1351194264.28.0.869819451271.issue16326@psf.upfronthosting.co.za>
Message-ID: <1587921122.89.0.648334863848.issue16326@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

Given that #18976 was said to have fixed this and is now closed as "fixed", and every tagged version is now EOL, I'm closing the issue.

----------
nosy: +zach.ware
resolution:  -> out of date
stage: test needed -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue16326>
_______________________________________

From report at bugs.python.org  Sun Apr 26 13:24:56 2020
From: report at bugs.python.org (hai shi)
Date: Sun, 26 Apr 2020 17:24:56 +0000
Subject: [issue40275] test.support has way too many imports
In-Reply-To: <1586816691.28.0.874442798421.issue40275@roundup.psfhosted.org>
Message-ID: <1587921896.12.0.319244666194.issue40275@roundup.psfhosted.org>


Change by hai shi <shihai1991 at 126.com>:


----------
pull_requests: +19041
pull_request: https://github.com/python/cpython/pull/19716

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40275>
_______________________________________

From report at bugs.python.org  Sun Apr 26 13:47:53 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 26 Apr 2020 17:47:53 +0000
Subject: [issue40398] get_args(Callable) fails
In-Reply-To: <1587919567.44.0.458722941462.issue40398@roundup.psfhosted.org>
Message-ID: <1587923273.07.0.325188764892.issue40398@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

Maybe it could return (Ellipsis, Any) in that case. The most general form of Callable is Callable[..., Any] and that's that get_args() returns for that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40398>
_______________________________________

From report at bugs.python.org  Sun Apr 26 13:57:40 2020
From: report at bugs.python.org (Santiago Blanco)
Date: Sun, 26 Apr 2020 17:57:40 +0000
Subject: [issue40387] queue example it does not work
In-Reply-To: <1587801535.61.0.75411956327.issue40387@roundup.psfhosted.org>
Message-ID: <1587923860.38.0.253687960745.issue40387@roundup.psfhosted.org>


Santiago Blanco <sblancov84 at gmail.com> added the comment:

I am trying to help, if you want I change something of my PR tell me what.

I think most people need concrete examples to learn anything, but I may be wrong.

I consider that a note will not change anything.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40387>
_______________________________________

From report at bugs.python.org  Sun Apr 26 14:12:08 2020
From: report at bugs.python.org (Willie Lopez)
Date: Sun, 26 Apr 2020 18:12:08 +0000
Subject: [issue37518] Python-2.7.16 fails to build with --enable-shared
In-Reply-To: <1587918330.77.0.268211954778.issue37518@roundup.psfhosted.org>
Message-ID: <2FBAB089-957C-47A5-AD12-A047F04BE8B1@yahoo.com>


Willie Lopez <willie.lopez at yahoo.com> added the comment:

Thank you anyway. I was able to finally resolve the issue, which did turn out to be the environment variable PYTHONPATH. When compiling python from source, that variable must be empty (not null). After emptying the string value the compilation worked. 

This probably has to do more with having two versions of python, the system and our application side. The env variable is always set on our dev and app servers. Not a good practice when compiling from source.

Thanks!

Willie Lopez
???????????-
Willie.lopez at yahoo.com
970.481.8246

> On Apr 26, 2020, at 10:25 AM, Zachary Ware <report at bugs.python.org> wrote:
> 
> ?
> Zachary Ware <zachary.ware at gmail.com> added the comment:
> 
> Hi Willie,
> 
> Sorry this never got attention before 2.7 reached end-of-life, but as that has now happened, I'm closing the issue.
> 
> That said, I suspect your issue here was with library search path; it wasn't actually 2.7.5 that was installed by the install of 2.7.16, but rather it was the system's 2.7.5 library that was loaded instead of the installation's 2.7.16 due to the latter's directory being either not on the search path or after the system's Python library location.  I'm not sure if there's really a good way to have two separate patch versions of Python, both with shared libraries rather than static, without winding up with some confusion about which library should be loaded by which application.
> 
> ----------
> nosy: +zach.ware
> resolution:  -> out of date
> stage:  -> resolved
> status: open -> closed
> 
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue37518>
> _______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37518>
_______________________________________

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: [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 14:21:15 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 26 Apr 2020 18:21:15 +0000
Subject: [issue40396] Support GenericAlias in typing
In-Reply-To: <1587916977.12.0.758725068649.issue40396@roundup.psfhosted.org>
Message-ID: <1587925275.26.0.438488382229.issue40396@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 68b352a6982f51e19bf9b9f4ae61b34f5864d131 by Serhiy Storchaka in branch 'master':
bpo-40396: Support GenericAlias in the typing functions. (GH-19718)
https://github.com/python/cpython/commit/68b352a6982f51e19bf9b9f4ae61b34f5864d131


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40396>
_______________________________________

From report at bugs.python.org  Sun Apr 26 14:23:25 2020
From: report at bugs.python.org (Ned Deily)
Date: Sun, 26 Apr 2020 18:23:25 +0000
Subject: [issue40400] Mac build-installer.py doesn't support new plist format
In-Reply-To: <1587925038.05.0.935755179102.issue40400@roundup.psfhosted.org>
Message-ID: <1587925405.26.0.66633271636.issue40400@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


----------
assignee:  -> ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40400>
_______________________________________

From report at bugs.python.org  Sun Apr 26 14:38:25 2020
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Sun, 26 Apr 2020 18:38:25 +0000
Subject: [issue40398] get_args(Callable) fails
In-Reply-To: <1587919567.44.0.458722941462.issue40398@roundup.psfhosted.org>
Message-ID: <1587926305.46.0.498963540866.issue40398@roundup.psfhosted.org>


Ivan Levkivskyi <levkivskyi at gmail.com> added the comment:

I think it should return empty tuple: First, for consistency with other things like get_args(Tuple) == () and get_args(List) == (). Second, although Callable is equivalent to Callable[..., Any] in the static world, authors of some runtime checkers might want to distinguish whether a user wrote one or another.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40398>
_______________________________________

From report at bugs.python.org  Sun Apr 26 14:39:19 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 26 Apr 2020 18:39:19 +0000
Subject: [issue40398] get_args(Callable) fails
In-Reply-To: <1587919567.44.0.458722941462.issue40398@roundup.psfhosted.org>
Message-ID: <1587926359.46.0.526068862601.issue40398@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

Agreed, that's better!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40398>
_______________________________________

From report at bugs.python.org  Sun Apr 26 14:41:39 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 26 Apr 2020 18:41:39 +0000
Subject: [issue40398] get_args(Callable) fails
In-Reply-To: <1587919567.44.0.458722941462.issue40398@roundup.psfhosted.org>
Message-ID: <1587926499.0.0.993563550358.issue40398@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

get_args(List) == (T,)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40398>
_______________________________________

From report at bugs.python.org  Sun Apr 26 14:56:38 2020
From: report at bugs.python.org (Zachary Ware)
Date: Sun, 26 Apr 2020 18:56:38 +0000
Subject: [issue13733] Change required to sysconfig.py for Python 2.7.2 on OS/2
In-Reply-To: <1325980402.33.0.867781342076.issue13733@psf.upfronthosting.co.za>
Message-ID: <1587927398.13.0.437788517908.issue13733@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

As Python 2.7 is now EOL and was the last remaining version to support OS/2, I'm closing the issue.

----------
nosy: +zach.ware
resolution:  -> out of date
stage: test needed -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13733>
_______________________________________

From report at bugs.python.org  Sun Apr 26 14:56:43 2020
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Sun, 26 Apr 2020 18:56:43 +0000
Subject: [issue40398] get_args(Callable) fails
In-Reply-To: <1587919567.44.0.458722941462.issue40398@roundup.psfhosted.org>
Message-ID: <1587927403.87.0.070158068023.issue40398@roundup.psfhosted.org>


Ivan Levkivskyi <levkivskyi at gmail.com> added the comment:

Oh my, this looks like another bug. I don't have Python 3.8 at hand so just tried `typing_inspect` on Python 3.6. I think this may be caused by the "double use" of _GenericAlias for which you opened your WIP PR.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40398>
_______________________________________

From report at bugs.python.org  Sun Apr 26 14:59:42 2020
From: report at bugs.python.org (Zachary Ware)
Date: Sun, 26 Apr 2020 18:59:42 +0000
Subject: [issue16275] test_ctypes fails on Solaris 10 SPARC 2.7
 (nitrogen/s10)	(Sun C compiler)
In-Reply-To: <1350552289.03.0.785225307416.issue16275@psf.upfronthosting.co.za>
Message-ID: <1587927582.01.0.26840994432.issue16275@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

As 2.7 is EOL and the bundled copy of libffi no longer exists, I'm closing the issue.

----------
nosy: +zach.ware
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue16275>
_______________________________________

From report at bugs.python.org  Sun Apr 26 15:27:10 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 26 Apr 2020 19:27:10 +0000
Subject: [issue40398] get_args(Callable) fails
In-Reply-To: <1587919567.44.0.458722941462.issue40398@roundup.psfhosted.org>
Message-ID: <1587929230.93.0.403251888184.issue40398@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch
pull_requests: +19042
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19720

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40398>
_______________________________________

From report at bugs.python.org  Sun Apr 26 15:27:57 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 26 Apr 2020 19:27:57 +0000
Subject: [issue40396] Support GenericAlias in typing
In-Reply-To: <1587916977.12.0.758725068649.issue40396@roundup.psfhosted.org>
Message-ID: <1587929277.41.0.325365100775.issue40396@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40396>
_______________________________________

From report at bugs.python.org  Sun Apr 26 16:36:06 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 26 Apr 2020 20:36:06 +0000
Subject: [issue40334] PEP 617: new PEG-based parser
In-Reply-To: <1587327377.33.0.614039250584.issue40334@roundup.psfhosted.org>
Message-ID: <1587933366.7.0.725740145768.issue40334@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
pull_requests: +19043
pull_request: https://github.com/python/cpython/pull/19721

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40334>
_______________________________________

From report at bugs.python.org  Sun Apr 26 17:56:52 2020
From: report at bugs.python.org (Tal Einat)
Date: Sun, 26 Apr 2020 21:56:52 +0000
Subject: [issue40383] weakref class name are hardcoded in reprs
In-Reply-To: <1587783917.63.0.137882074418.issue40383@roundup.psfhosted.org>
Message-ID: <1587938212.48.0.00137473395028.issue40383@roundup.psfhosted.org>


Change by Tal Einat <taleinat+python at gmail.com>:


----------
nosy:  -taleinat

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40383>
_______________________________________

From report at bugs.python.org  Sun Apr 26 18:01:22 2020
From: report at bugs.python.org (Jason R. Coombs)
Date: Sun, 26 Apr 2020 22:01:22 +0000
Subject: [issue39791] New `files()` api from importlib_resources.
In-Reply-To: <1582949490.73.0.868974160192.issue39791@roundup.psfhosted.org>
Message-ID: <1587938482.51.0.925322171382.issue39791@roundup.psfhosted.org>


Change by Jason R. Coombs <jaraco at jaraco.com>:


----------
keywords: +patch
pull_requests: +19044
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19722

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39791>
_______________________________________

From report at bugs.python.org  Sun Apr 26 18:42:26 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 26 Apr 2020 22:42:26 +0000
Subject: [issue40334] PEP 617: new PEG-based parser
In-Reply-To: <1587327377.33.0.614039250584.issue40334@roundup.psfhosted.org>
Message-ID: <1587940946.17.0.225330429945.issue40334@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
pull_requests: +19045
pull_request: https://github.com/python/cpython/pull/19723

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40334>
_______________________________________

From report at bugs.python.org  Sun Apr 26 19:29:34 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 26 Apr 2020 23:29:34 +0000
Subject: [issue40387] queue example is a sketch
In-Reply-To: <1587801535.61.0.75411956327.issue40387@roundup.psfhosted.org>
Message-ID: <1587943774.66.0.406376296331.issue40387@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I'm thinking of simplifying the example to focus on its core goal of demonstrating how to enqueue tasks and then wait for them to be finished:

    import threading, queue

    q = queue.Queue()

    def worker():
        while True:
            item = q.get()
            print(f'Working on {item}')
            print(f'Finished {item}')
            q.task_done()

    # turn-on the worker thread
    worker_thread = threading.Thread(target=worker)
    worker_thread.daemon = True
    worker_thread.start()

    # send thirty task requests to the worker
    for item in range(30):
        q.put(item)
    print('All task requests sent\n', end='')    

    # block until all tasks are done
    q.join()
    print('All work completed')

----------
assignee: docs at python -> rhettinger
title: queue example it does not work -> queue example is a sketch
versions:  -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40387>
_______________________________________

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: [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 19:53:25 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 26 Apr 2020 23:53:25 +0000
Subject: [issue40387] queue example is a sketch
In-Reply-To: <1587801535.61.0.75411956327.issue40387@roundup.psfhosted.org>
Message-ID: <1587945205.53.0.365416164259.issue40387@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
pull_requests: +19046
pull_request: https://github.com/python/cpython/pull/19724

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40387>
_______________________________________

From report at bugs.python.org  Sun Apr 26 19:56:00 2020
From: report at bugs.python.org (Ammar Askar)
Date: Sun, 26 Apr 2020 23:56:00 +0000
Subject: [issue40401] pythoncore.vcxproj fails to load due to duplicated
 "..\Include\pyhash.h"
In-Reply-To: <1587945187.18.0.146744366129.issue40401@roundup.psfhosted.org>
Message-ID: <1587945360.68.0.821819662467.issue40401@roundup.psfhosted.org>


Change by Ammar Askar <ammar at ammaraskar.com>:


----------
keywords: +patch
pull_requests: +19047
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19725

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40401>
_______________________________________

From report at bugs.python.org  Sun Apr 26 19:59:47 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 26 Apr 2020 23:59:47 +0000
Subject: [issue40394] difflib.SequenceMatcher.find_longest_match default
 arguments
In-Reply-To: <1587910558.56.0.865649390619.issue40394@roundup.psfhosted.org>
Message-ID: <1587945587.79.0.494320255989.issue40394@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee:  -> tim.peters

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40394>
_______________________________________

From report at bugs.python.org  Sun Apr 26 20:01:29 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 27 Apr 2020 00:01:29 +0000
Subject: [issue40388] random.choice integer overflow v3.5.2
In-Reply-To: <1587804987.95.0.247989027545.issue40388@roundup.psfhosted.org>
Message-ID: <1587945689.71.0.596734053397.issue40388@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40388>
_______________________________________

From report at bugs.python.org  Sun Apr 26 20:03:30 2020
From: report at bugs.python.org (Dima Tisnek)
Date: Mon, 27 Apr 2020 00:03:30 +0000
Subject: [issue31122] SSLContext.wrap_socket() throws OSError with errno == 0
In-Reply-To: <1501874201.48.0.0126792321555.issue31122@psf.upfronthosting.co.za>
Message-ID: <1587945810.04.0.0946906641255.issue31122@roundup.psfhosted.org>


Dima Tisnek <dimaqq at gmail.com> added the comment:

I know Christian is very busy, so what can I do to have this patch reviewed?
* it's concise
* there's a reproducer

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31122>
_______________________________________

From report at bugs.python.org  Sun Apr 26 20:26:48 2020
From: report at bugs.python.org (Santiago Blanco)
Date: Mon, 27 Apr 2020 00:26:48 +0000
Subject: [issue40387] queue example is a sketch
In-Reply-To: <1587801535.61.0.75411956327.issue40387@roundup.psfhosted.org>
Message-ID: <1587947208.42.0.954321692559.issue40387@roundup.psfhosted.org>


Santiago Blanco <sblancov84 at gmail.com> added the comment:

That is pretty clear! Thank you Raymond.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40387>
_______________________________________

From report at bugs.python.org  Sun Apr 26 20:57:33 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 27 Apr 2020 00:57:33 +0000
Subject: [issue40384] IDLE: Wrong highlighting when \n follows def/class
In-Reply-To: <1587785397.11.0.430287508325.issue40384@roundup.psfhosted.org>
Message-ID: <1587949053.39.0.706385310107.issue40384@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

For me, on Mac, only  the 3rd 'def', on line 4, changes to blue, the default highlight for defined names (those immediately following 'def' or 'class').  This is because deleting the '#' causes recoloring from there onward, and IDLE's handling of newlines after 'def' or 'class' is buggy. I presume that you see the same.

I most concerned with correctly highlighting correct code.  It may be ambiguous what to do with incorrect code.  If one types 'def name' or 'class name' to start a line, name is colored blue as a definition name.  If name happens to be misspelled to match a keyword, should it be colored as a keyword?  Maybe, but in this context, it will not function as such.  Perhaps it should be immediately colored as a syntax error (default red), instead of waiting for an explicit syntax check.  But this an innovation for IDLE and should be a different issue from this one.

If there is a newline between def/class and the name, python sees it as a space if escaped with '\' but a syntax error if not.  IDLE effectively does the opposite.  The idprog in idlelib.colorizer uses \s, which matches a bare newline, among other things, but not 'backslash newline'.    I intend to replace '\s' with alternatives legal in this context.

def\
name ...  # Name should be blue, at least after multiline recolor.

def
name ...  # 'def\n' is error; name should not be blue ever.

----------
stage:  -> needs patch
title: IDLE: Undesired highlight -> IDLE: Wrong highlighting when \n follows def/class
versions: +Python 3.7, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40384>
_______________________________________

From report at bugs.python.org  Sun Apr 26 21:11:34 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 27 Apr 2020 01:11:34 +0000
Subject: [issue40387] queue example is a sketch
In-Reply-To: <1587801535.61.0.75411956327.issue40387@roundup.psfhosted.org>
Message-ID: <1587949894.22.0.633773104803.issue40387@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:


New changeset 88499f15f547ccf7b15d37b0eaf51cc40bad5c39 by Raymond Hettinger in branch 'master':
bpo-40387: Improve queue join() example. (GH-19724)
https://github.com/python/cpython/commit/88499f15f547ccf7b15d37b0eaf51cc40bad5c39


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40387>
_______________________________________

From report at bugs.python.org  Sun Apr 26 21:11:57 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 27 Apr 2020 01:11:57 +0000
Subject: [issue40387] queue example is a sketch
In-Reply-To: <1587801535.61.0.75411956327.issue40387@roundup.psfhosted.org>
Message-ID: <1587949917.34.0.213052408181.issue40387@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
nosy: +miss-islington
nosy_count: 5.0 -> 6.0
pull_requests: +19048
pull_request: https://github.com/python/cpython/pull/19726

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40387>
_______________________________________

From report at bugs.python.org  Sun Apr 26 21:23:21 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 27 Apr 2020 01:23:21 +0000
Subject: [issue40387] queue example is a sketch
In-Reply-To: <1587801535.61.0.75411956327.issue40387@roundup.psfhosted.org>
Message-ID: <1587950601.06.0.403473832998.issue40387@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:


New changeset 179f22c3b786ce9baa3445923f8f9708dfa5d5b7 by Miss Islington (bot) in branch '3.8':
bpo-40387: Improve queue join() example. (GH-19724) (GH-19726)
https://github.com/python/cpython/commit/179f22c3b786ce9baa3445923f8f9708dfa5d5b7


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40387>
_______________________________________

From report at bugs.python.org  Sun Apr 26 21:24:14 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 27 Apr 2020 01:24:14 +0000
Subject: [issue40387] queue example is a sketch
In-Reply-To: <1587801535.61.0.75411956327.issue40387@roundup.psfhosted.org>
Message-ID: <1587950654.45.0.616499665397.issue40387@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40387>
_______________________________________

From report at bugs.python.org  Sun Apr 26 21:29:42 2020
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 27 Apr 2020 01:29:42 +0000
Subject: [issue21615] Curses bug report for Python 2.7 and Python 3.2
In-Reply-To: <F67AE7B5-17CD-4FF2-92DA-27153389C62D@comcast.net>
Message-ID: <1587950982.57.0.0280281577739.issue21615@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

Hi Richard, sorry it too so long for anyone to respond to this issue!  It's been long enough that I'm going to assume that this has long since been fixed or worked around.  However, if you can still reproduce this with a modern version of Python (3.6-3.8), do please reopen the issue and attach some code that shows what's going on.

----------
nosy: +zach.ware
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21615>
_______________________________________

From report at bugs.python.org  Sun Apr 26 21:31:15 2020
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 27 Apr 2020 01:31:15 +0000
Subject: [issue17904] bytes should be listed as built-in function for 2.7
In-Reply-To: <1367663679.93.0.0164308850832.issue17904@psf.upfronthosting.co.za>
Message-ID: <1587951075.27.0.451170834604.issue17904@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

As 2.7 has now reached EOL, I'm closing the issue.

----------
nosy: +zach.ware
resolution:  -> out of date
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17904>
_______________________________________

From report at bugs.python.org  Sun Apr 26 21:32:46 2020
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 27 Apr 2020 01:32:46 +0000
Subject: [issue22863] https://docs.python.org/ should make a true 2.7.8
 version available
In-Reply-To: <1415888918.09.0.104485569089.issue22863@psf.upfronthosting.co.za>
Message-ID: <1587951166.52.0.724335370382.issue22863@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

As 2.7 is now EOL, I'm closing this issue.

----------
nosy: +zach.ware
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22863>
_______________________________________

From report at bugs.python.org  Sun Apr 26 21:34:24 2020
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 27 Apr 2020 01:34:24 +0000
Subject: [issue22912] urlretreive locks up in 2.7.8
In-Reply-To: <1416599758.35.0.866747041142.issue22912@psf.upfronthosting.co.za>
Message-ID: <1587951264.79.0.821561237921.issue22912@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

As 2.7 has reached EOL, I'm closing this issue.

----------
nosy: +zach.ware
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22912>
_______________________________________

From report at bugs.python.org  Sun Apr 26 21:35:40 2020
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 27 Apr 2020 01:35:40 +0000
Subject: [issue22583] C stack overflow in the Python 2.7 compiler
In-Reply-To: <1412793209.1.0.692810866448.issue22583@psf.upfronthosting.co.za>
Message-ID: <1587951340.09.0.200104706426.issue22583@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

As 2.7 has reached EOL, I'm closing this issue.

----------
nosy: +zach.ware
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22583>
_______________________________________

From report at bugs.python.org  Sun Apr 26 21:36:35 2020
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 27 Apr 2020 01:36:35 +0000
Subject: [issue24182] test_tcl assertion failure, 2.7, Win 7
In-Reply-To: <1431554287.05.0.384397214911.issue24182@psf.upfronthosting.co.za>
Message-ID: <1587951395.57.0.854961898156.issue24182@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

As 2.7 is EOL and 3.x use Tcl/Tk 8.6.x, I'm closing this issue.

----------
nosy: +zach.ware
resolution:  -> out of date
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24182>
_______________________________________

From report at bugs.python.org  Sun Apr 26 21:48:27 2020
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 27 Apr 2020 01:48:27 +0000
Subject: [issue24616] 'make install' fails installation of man pages for
 Python 2.7.10 on Unixware 7.1.4
In-Reply-To: <1436701515.32.0.902872028806.issue24616@psf.upfronthosting.co.za>
Message-ID: <1587952107.14.0.137220873135.issue24616@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

At a guess, the version of `make` used in your environment was not able to handle a comment.  However, Python 2.7 has now reached end-of-life and as such I'm closing this issue.  If you can still reproduce the issue with a modern version of Python (3.6-3.8) we can consider reopening the issue, but as UnixWare is not a supported platform the chances of anyone else being able to track down the issue and supply a patch are pretty slim.

----------
nosy: +zach.ware
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24616>
_______________________________________

From report at bugs.python.org  Sun Apr 26 21:50:48 2020
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 27 Apr 2020 01:50:48 +0000
Subject: [issue25463] 2.7.10 glibc double free detected
In-Reply-To: <1445548102.26.0.143608380195.issue25463@psf.upfronthosting.co.za>
Message-ID: <1587952248.83.0.0379643343457.issue25463@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

As Python 2.7 is now at end-of-life, I'm closing this issue.  If you can still reproduce the problem with a modern version of Python (3.6-3.8), please reopen it.

----------
nosy: +zach.ware
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25463>
_______________________________________

From report at bugs.python.org  Sun Apr 26 21:55:28 2020
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 27 Apr 2020 01:55:28 +0000
Subject: [issue38959] Parboil -- OpenMP CUTCP performance regression when
 upgrade from python 2.7.15 to 2.7.17
In-Reply-To: <1575354960.22.0.085059134503.issue38959@roundup.psfhosted.org>
Message-ID: <1587952528.84.0.814613964528.issue38959@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

Hi Jiebin,

Sorry that nobody was able to respond to this before the end of support for 2.7.  However, that version is now EOL, and as such I'm closing this issue.

----------
nosy: +zach.ware
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38959>
_______________________________________

From report at bugs.python.org  Sun Apr 26 21:56:26 2020
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 27 Apr 2020 01:56:26 +0000
Subject: [issue26360] Deadlock in thread.join on Python 2.7/macOS
In-Reply-To: <1455449924.98.0.400633064774.issue26360@psf.upfronthosting.co.za>
Message-ID: <1587952586.58.0.611471869479.issue26360@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

As 2.7 is now EOL, I'm closing the issue.

----------
nosy: +zach.ware
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26360>
_______________________________________

From report at bugs.python.org  Sun Apr 26 22:04:28 2020
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 27 Apr 2020 02:04:28 +0000
Subject: [issue36803] Getting a lot of runtime misaligned address error while
 building python 2.7.6 with UBSAN
In-Reply-To: <1557070423.41.0.167231888065.issue36803@roundup.psfhosted.org>
Message-ID: <1587953068.45.0.353424334795.issue36803@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

As Python 2.7 has reached EOL, I'm closing this issue.  However, if you can reproduce the problem with a modern version of Python (3.6-3.8), please reopen it and adjust the versions field appropriately.

----------
nosy: +zach.ware
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36803>
_______________________________________

From report at bugs.python.org  Sun Apr 26 22:05:54 2020
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 27 Apr 2020 02:05:54 +0000
Subject: [issue10417] [2.7] unittest triggers UnicodeEncodeError with
 non-ASCII character in the docstring of the test function
In-Reply-To: <1289739891.46.0.690681439003.issue10417@psf.upfronthosting.co.za>
Message-ID: <1587953154.68.0.370142389827.issue10417@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

With 2.7 now EOL, I'm closing the issue.

----------
nosy: +zach.ware
resolution:  -> out of date
stage: test needed -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue10417>
_______________________________________

From report at bugs.python.org  Sun Apr 26 22:08:23 2020
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 27 Apr 2020 02:08:23 +0000
Subject: [issue40401] pythoncore.vcxproj fails to load due to duplicated
 "..\Include\pyhash.h"
In-Reply-To: <1587945187.18.0.146744366129.issue40401@roundup.psfhosted.org>
Message-ID: <1587953303.9.0.563009830544.issue40401@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:


New changeset a494caa14bfa412af77792007c34274902fabb7b by Ammar Askar in branch 'master':
bpo-40401: Remove duplicate pyhash.h include from pythoncore.vcxproj (GH-19725)
https://github.com/python/cpython/commit/a494caa14bfa412af77792007c34274902fabb7b


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40401>
_______________________________________

From report at bugs.python.org  Sun Apr 26 22:09:02 2020
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 27 Apr 2020 02:09:02 +0000
Subject: [issue40401] pythoncore.vcxproj fails to load due to duplicated
 "..\Include\pyhash.h"
In-Reply-To: <1587945187.18.0.146744366129.issue40401@roundup.psfhosted.org>
Message-ID: <1587953342.79.0.831528529199.issue40401@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

Thanks for the patch :)

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40401>
_______________________________________

From report at bugs.python.org  Sun Apr 26 22:22:18 2020
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 27 Apr 2020 02:22:18 +0000
Subject: [issue16117] python2.7.3 struct misaligned when returned
In-Reply-To: <1349256639.78.0.287581020931.issue16117@psf.upfronthosting.co.za>
Message-ID: <1587954138.92.0.104562960903.issue16117@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

As Python 2.7 has now reached end-of-life, I'm closing the issue.  If you can still reproduce this issue in a modern version of Python (3.6-3.8), please reopen it and hopefully we can get someone who understands what's going on to actually look at it :)

----------
nosy: +zach.ware
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue16117>
_______________________________________

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: [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 22:31:52 2020
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 27 Apr 2020 02:31:52 +0000
Subject: [issue38387] Document PyDoc_STRVAR
In-Reply-To: <1570405430.86.0.169338229908.issue38387@roundup.psfhosted.org>
Message-ID: <1587954712.13.0.454251250508.issue38387@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:


New changeset b54e46cb57ebac5c525a9a6be241412cd57bc935 by Brad Solomon in branch 'master':
bpo-38387: Formally document PyDoc_STRVAR and PyDoc_STR macros (GH-16607)
https://github.com/python/cpython/commit/b54e46cb57ebac5c525a9a6be241412cd57bc935


----------
nosy: +zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38387>
_______________________________________

From report at bugs.python.org  Sun Apr 26 22:33:01 2020
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 27 Apr 2020 02:33:01 +0000
Subject: [issue38387] Document PyDoc_STRVAR and PyDoc_STR macros
In-Reply-To: <1570405430.86.0.169338229908.issue38387@roundup.psfhosted.org>
Message-ID: <1587954781.65.0.176825633404.issue38387@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

Thanks for the patch!

----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
title: Document PyDoc_STRVAR -> Document PyDoc_STRVAR and PyDoc_STR macros
versions: +Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38387>
_______________________________________

From report at bugs.python.org  Sun Apr 26 22:35:01 2020
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 27 Apr 2020 02:35:01 +0000
Subject: [issue38387] Document PyDoc_STRVAR and PyDoc_STR macros
In-Reply-To: <1570405430.86.0.169338229908.issue38387@roundup.psfhosted.org>
Message-ID: <1587954901.47.0.827313160945.issue38387@roundup.psfhosted.org>


Change by Zachary Ware <zachary.ware at gmail.com>:


----------
pull_requests: +19049
pull_request: https://github.com/python/cpython/pull/19727

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38387>
_______________________________________

From report at bugs.python.org  Sun Apr 26 22:37:30 2020
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 27 Apr 2020 02:37:30 +0000
Subject: [issue38387] Document PyDoc_STRVAR and PyDoc_STR macros
In-Reply-To: <1570405430.86.0.169338229908.issue38387@roundup.psfhosted.org>
Message-ID: <1587955050.4.0.789871191713.issue38387@roundup.psfhosted.org>


Change by Zachary Ware <zachary.ware at gmail.com>:


----------
pull_requests: +19050
pull_request: https://github.com/python/cpython/pull/19728

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38387>
_______________________________________

From report at bugs.python.org  Sun Apr 26 22:39:18 2020
From: report at bugs.python.org (Zackery Spytz)
Date: Mon, 27 Apr 2020 02:39:18 +0000
Subject: [issue40348] Programming FAQ about "What is delegation?": Fix typos
In-Reply-To: <1587419868.54.0.356271490131.issue40348@roundup.psfhosted.org>
Message-ID: <1587955158.12.0.725097264177.issue40348@roundup.psfhosted.org>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
keywords: +patch
nosy: +ZackerySpytz
nosy_count: 3.0 -> 4.0
pull_requests: +19051
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19729

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40348>
_______________________________________

From report at bugs.python.org  Sun Apr 26 22:40:33 2020
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 27 Apr 2020 02:40:33 +0000
Subject: [issue14759] BSDDB license missing from liscense page in 2.7.
In-Reply-To: <1336525700.66.0.626657341837.issue14759@psf.upfronthosting.co.za>
Message-ID: <1587955233.14.0.978488398077.issue14759@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

As Python 2.7 has reached end-of-life and the bsddb module is not shipped with Python 3, I'm closing the issue.

----------
nosy: +zach.ware
resolution:  -> out of date
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue14759>
_______________________________________

From report at bugs.python.org  Sun Apr 26 22:45:13 2020
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 27 Apr 2020 02:45:13 +0000
Subject: [issue38387] Document PyDoc_STRVAR and PyDoc_STR macros
In-Reply-To: <1570405430.86.0.169338229908.issue38387@roundup.psfhosted.org>
Message-ID: <1587955513.14.0.0165866000887.issue38387@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:


New changeset ca5649c4c1ab260c8ceb8a57ec703c06e2707986 by Zachary Ware in branch '3.8':
[3.8] bpo-38387: Formally document PyDoc_STRVAR and PyDoc_STR macros (GH-16607) (GH-19727)
https://github.com/python/cpython/commit/ca5649c4c1ab260c8ceb8a57ec703c06e2707986


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38387>
_______________________________________

From report at bugs.python.org  Sun Apr 26 22:46:14 2020
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 27 Apr 2020 02:46:14 +0000
Subject: [issue38387] Document PyDoc_STRVAR and PyDoc_STR macros
In-Reply-To: <1570405430.86.0.169338229908.issue38387@roundup.psfhosted.org>
Message-ID: <1587955574.1.0.958835661203.issue38387@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:


New changeset 70ba81459eeb5818848f86b65cdf78feb86f9612 by Zachary Ware in branch '3.7':
[3.7] bpo-38387: Formally document PyDoc_STRVAR and PyDoc_STR macros (GH-16607) (GH-19728)
https://github.com/python/cpython/commit/70ba81459eeb5818848f86b65cdf78feb86f9612


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38387>
_______________________________________

From report at bugs.python.org  Sun Apr 26 22:49:24 2020
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 27 Apr 2020 02:49:24 +0000
Subject: [issue23137] Python 2.7.9 test_gdb fails on CentOS 7
In-Reply-To: <1419983350.87.0.850193733351.issue23137@psf.upfronthosting.co.za>
Message-ID: <1587955764.82.0.325588468461.issue23137@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

As Python 2.7 has reached end-of-life, I'm closing this issue.  As Martin mentioned, this looks likely to be a duplicate of bpo-17126 anyway.

----------
nosy: +zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23137>
_______________________________________

From report at bugs.python.org  Sun Apr 26 22:49:31 2020
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 27 Apr 2020 02:49:31 +0000
Subject: [issue23137] Python 2.7.9 test_gdb fails on CentOS 7
In-Reply-To: <1419983350.87.0.850193733351.issue23137@psf.upfronthosting.co.za>
Message-ID: <1587955771.48.0.194213727135.issue23137@roundup.psfhosted.org>


Change by Zachary Ware <zachary.ware at gmail.com>:


----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23137>
_______________________________________

From report at bugs.python.org  Sun Apr 26 22:54:32 2020
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 27 Apr 2020 02:54:32 +0000
Subject: [issue17126] test_gdb fails
In-Reply-To: <1360000320.96.0.343533657729.issue17126@psf.upfronthosting.co.za>
Message-ID: <1587956072.44.0.0357887116291.issue17126@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

As Python 2.7 has now reached end-of-life, I'm closing the issue.  gdb support has seen some significant changes in the interim anyway; it's entirely possible that this was actually fixed in 2.7 before it died :)

----------
nosy: +zach.ware
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17126>
_______________________________________

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: [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  Sun Apr 26 23:18:33 2020
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 27 Apr 2020 03:18:33 +0000
Subject: [issue21031] [patch] Add AlpineLinux to the platform module's
 supported distributions list
In-Reply-To: <1395547536.87.0.0316178193706.issue21031@psf.upfronthosting.co.za>
Message-ID: <1587957513.86.0.11677983081.issue21031@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

As `linux_distribution` was removed in 3.8 (bpo-28167), I'm closing the issue.  Thanks for the patch anyway, Elizabeth, and I'm sorry it didn't end up better!

----------
nosy: +zach.ware
resolution:  -> out of date
stage: patch review -> resolved
status: languishing -> closed
versions: +Python 3.5 -Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21031>
_______________________________________

From report at bugs.python.org  Sun Apr 26 23:24:06 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 27 Apr 2020 03:24:06 +0000
Subject: [issue40348] Programming FAQ about "What is delegation?": Fix typos
In-Reply-To: <1587419868.54.0.356271490131.issue40348@roundup.psfhosted.org>
Message-ID: <1587957846.14.0.876886362193.issue40348@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +19052
pull_request: https://github.com/python/cpython/pull/19730

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40348>
_______________________________________

From report at bugs.python.org  Sun Apr 26 23:24:00 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 27 Apr 2020 03:24:00 +0000
Subject: [issue40348] Programming FAQ about "What is delegation?": Fix typos
In-Reply-To: <1587419868.54.0.356271490131.issue40348@roundup.psfhosted.org>
Message-ID: <1587957840.94.0.253081563083.issue40348@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset caf1aadf3d020f742ba3d7fcf678ca700224914b by Zackery Spytz in branch 'master':
bpo-40348: Fix typos in the programming FAQ (GH-19729)
https://github.com/python/cpython/commit/caf1aadf3d020f742ba3d7fcf678ca700224914b


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40348>
_______________________________________

From report at bugs.python.org  Sun Apr 26 23:24:13 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 27 Apr 2020 03:24:13 +0000
Subject: [issue40348] Programming FAQ about "What is delegation?": Fix typos
In-Reply-To: <1587419868.54.0.356271490131.issue40348@roundup.psfhosted.org>
Message-ID: <1587957853.89.0.0889219883926.issue40348@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +19053
pull_request: https://github.com/python/cpython/pull/19731

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40348>
_______________________________________

From report at bugs.python.org  Sun Apr 26 23:26:46 2020
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 27 Apr 2020 03:26:46 +0000
Subject: [issue22559] [2.7] Backport ssl.MemoryBIO to Python 2.7 - PEP 546
In-Reply-To: <1412540756.02.0.793381062078.issue22559@psf.upfronthosting.co.za>
Message-ID: <1587958006.31.0.334642723359.issue22559@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

With PEP 546 withdrawn/rejected and 2.7 at EOL, I'm closing the issue.

----------
nosy: +zach.ware
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22559>
_______________________________________

From report at bugs.python.org  Sun Apr 26 23:27:58 2020
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 27 Apr 2020 03:27:58 +0000
Subject: [issue31474] [2.7] Fix  -Wnonnull and -Wint-in-bool-context warnings
In-Reply-To: <1505410650.2.0.862260901795.issue31474@psf.upfronthosting.co.za>
Message-ID: <1587958078.02.0.0178171034727.issue31474@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

This seems to have been fixed but never closed?  Closing it now anyway due to EOL :)

----------
nosy: +zach.ware
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31474>
_______________________________________

From report at bugs.python.org  Sun Apr 26 23:29:10 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 27 Apr 2020 03:29:10 +0000
Subject: [issue40348] Programming FAQ about "What is delegation?": Fix typos
In-Reply-To: <1587419868.54.0.356271490131.issue40348@roundup.psfhosted.org>
Message-ID: <1587958150.45.0.115644709124.issue40348@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 25def5f2187154ccb6d75751f395a949f4726b1c by Miss Islington (bot) in branch '3.7':
bpo-40348: Fix typos in the programming FAQ (GH-19729)
https://github.com/python/cpython/commit/25def5f2187154ccb6d75751f395a949f4726b1c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40348>
_______________________________________

From report at bugs.python.org  Sun Apr 26 23:29:12 2020
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 27 Apr 2020 03:29:12 +0000
Subject: [issue33586] 2.7.15 missing release notes on download page
In-Reply-To: <1526833708.19.0.682650639539.issue33586@psf.upfronthosting.co.za>
Message-ID: <1587958152.66.0.582585595865.issue33586@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

Superseded by the pythondotorg issue.

----------
nosy: +zach.ware
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33586>
_______________________________________

From report at bugs.python.org  Sun Apr 26 23:29:37 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 27 Apr 2020 03:29:37 +0000
Subject: [issue40348] Programming FAQ about "What is delegation?": Fix typos
In-Reply-To: <1587419868.54.0.356271490131.issue40348@roundup.psfhosted.org>
Message-ID: <1587958177.44.0.199701815857.issue40348@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 9412f4d1ad28d48d8bb4725f05fd8f8d0daf8cd2 by Miss Islington (bot) in branch '3.8':
bpo-40348: Fix typos in the programming FAQ (GH-19729)
https://github.com/python/cpython/commit/9412f4d1ad28d48d8bb4725f05fd8f8d0daf8cd2


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40348>
_______________________________________

From report at bugs.python.org  Sun Apr 26 23:35:58 2020
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 27 Apr 2020 03:35:58 +0000
Subject: [issue29006] 2.7.13 _sqlite more prone to "database table is locked"
In-Reply-To: <1482095939.25.0.891516594682.issue29006@psf.upfronthosting.co.za>
Message-ID: <1587958558.32.0.207195948906.issue29006@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

As far as I can tell from the commit history associated with this issue this seems to have not been a bug, so I'm closing it.  If anyone disagrees, please reopen :)

----------
nosy: +zach.ware
resolution:  -> not a bug
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29006>
_______________________________________

From report at bugs.python.org  Sun Apr 26 23:37:00 2020
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 27 Apr 2020 03:37:00 +0000
Subject: [issue34836] test_ssl.test_default_ecdh_curve needs no tls1.3 flag in
 2.7, for now
In-Reply-To: <1538152364.12.0.545547206417.issue34836@psf.upfronthosting.co.za>
Message-ID: <1587958620.66.0.194086026849.issue34836@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

This seems to have been fixed, so I'm closing it as such.  With 2.7 at EOL, this would be closed anyway, but "fixed" sounds nicer :)

----------
nosy: +zach.ware
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34836>
_______________________________________

From report at bugs.python.org  Sun Apr 26 23:38:51 2020
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 27 Apr 2020 03:38:51 +0000
Subject: [issue31391] Forward-port test_xpickle from 2.7 to 3.x
In-Reply-To: <1504838590.9.0.36921288266.issue31391@psf.upfronthosting.co.za>
Message-ID: <1587958731.53.0.383007156141.issue31391@roundup.psfhosted.org>


Change by Zachary Ware <zachary.ware at gmail.com>:


----------
keywords: +newcomer friendly
versions: +Python 3.9 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31391>
_______________________________________

From report at bugs.python.org  Sun Apr 26 23:43:10 2020
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 27 Apr 2020 03:43:10 +0000
Subject: [issue33732] Python 2.7.15: xml.sax.parse() closes file objects
 passed to it
In-Reply-To: <1527857998.29.0.682650639539.issue33732@psf.upfronthosting.co.za>
Message-ID: <1587958990.53.0.0161334649375.issue33732@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

Hi Gibson,

I'm sorry this issue didn't get any attention before Python 2.7 reached EOL, but as that milestone has now passed I'm closing the issue.  Thank you for the report anyway!

----------
nosy: +zach.ware
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33732>
_______________________________________

From report at bugs.python.org  Sun Apr 26 23:45:58 2020
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 27 Apr 2020 03:45:58 +0000
Subject: [issue33500] Python TKinter for Mac on latest 2.7.15 still extremely
 slow vs Windows
In-Reply-To: <1526312324.63.0.682650639539.issue33500@psf.upfronthosting.co.za>
Message-ID: <1587959158.36.0.919394221389.issue33500@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

As Python 2.7 has now reached end-of-life, I'm closing the issue.

----------
nosy: +zach.ware
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33500>
_______________________________________

From report at bugs.python.org  Sun Apr 26 23:47:04 2020
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 27 Apr 2020 03:47:04 +0000
Subject: [issue30882] Built-in list disappeared from Python 2.7 intersphinx
 inventory
In-Reply-To: <1499622808.04.0.381858845257.issue30882@psf.upfronthosting.co.za>
Message-ID: <1587959224.08.0.578962498804.issue30882@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

As Python 2.7 has now reached end-of-life, I'm closing the issue.

----------
nosy: +zach.ware
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30882>
_______________________________________

From report at bugs.python.org  Sun Apr 26 23:54:03 2020
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 27 Apr 2020 03:54:03 +0000
Subject: [issue29846] ImportError: Symbol not found:
 __PyCodecInfo_GetIncrementalDecoder when building 2.7.x on macOS
In-Reply-To: <1489847707.41.0.897250288335.issue29846@psf.upfronthosting.co.za>
Message-ID: <1587959643.74.0.399234303151.issue29846@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

As this appears to be specific to Python 2.7 which has now reached end-of-life, I'm closing the issue.  Thanks for the report anyway, and I'm sorry we couldn't get it a bit more straightened out before EOL!

----------
nosy: +zach.ware
resolution:  -> out of date
stage: test needed -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29846>
_______________________________________

From report at bugs.python.org  Sun Apr 26 23:56:37 2020
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 27 Apr 2020 03:56:37 +0000
Subject: [issue16058] ConfigParser no longer deepcopy compatible in 2.7
In-Reply-To: <1348705133.3.0.138375656992.issue16058@psf.upfronthosting.co.za>
Message-ID: <1587959797.99.0.675793732362.issue16058@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

With 2.7 now EOL, I'm closing the issue.

----------
nosy: +zach.ware
resolution: fixed -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue16058>
_______________________________________

From report at bugs.python.org  Sun Apr 26 23:58:13 2020
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 27 Apr 2020 03:58:13 +0000
Subject: [issue26665] pip is not bootstrapped by default on 2.7
In-Reply-To: <1459261486.77.0.745706792357.issue26665@psf.upfronthosting.co.za>
Message-ID: <1587959893.02.0.914374900577.issue26665@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

As 2.7 is now EOL, I'm closing the issue.  Thanks for the report anyway, Axel!

----------
nosy: +zach.ware
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26665>
_______________________________________

From report at bugs.python.org  Sun Apr 26 23:59:46 2020
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 27 Apr 2020 03:59:46 +0000
Subject: [issue26697] tkFileDialog crash on askopenfilename Python 2.7 64-bit
 Win7
In-Reply-To: <1459891996.57.0.225918514546.issue26697@psf.upfronthosting.co.za>
Message-ID: <1587959986.87.0.699780077793.issue26697@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

As 2.7 is now EOL, I'm closing the issue.  Thanks for the report anyway, Eric, and I'm sorry we didn't get it looked into before now.

----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26697>
_______________________________________

From report at bugs.python.org  Mon Apr 27 00:00:51 2020
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 27 Apr 2020 04:00:51 +0000
Subject: [issue26652] Cannot install Python 2.7.11 on Windows Server 2008 R2
In-Reply-To: <1459136056.53.0.428865643545.issue26652@psf.upfronthosting.co.za>
Message-ID: <1587960051.12.0.627925050747.issue26652@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

Sorry this didn't get any attention before now, but as 2.7 is now EOL there's nothing we could fix for this, so I'm closing the issue.

----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26652>
_______________________________________

From report at bugs.python.org  Mon Apr 27 00:00:42 2020
From: report at bugs.python.org (Tim Peters)
Date: Mon, 27 Apr 2020 04:00:42 +0000
Subject: [issue40394] difflib.SequenceMatcher.find_longest_match default
 arguments
In-Reply-To: <1587910558.56.0.865649390619.issue40394@roundup.psfhosted.org>
Message-ID: <1587960042.49.0.485324054344.issue40394@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

Sounds good to me, Lewis - thanks!  Note, though, that alo and blo should default to 0.  `None` is best reserved for cases where the default value needs to be computed at runtime.  But alo == blo == 0 apply to all possible instances.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40394>
_______________________________________

From report at bugs.python.org  Mon Apr 27 00:01:42 2020
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 27 Apr 2020 04:01:42 +0000
Subject: [issue26326] Named entity "vertical line" missed in 2.7
 htmlentitydefs.py
In-Reply-To: <56BB13AF.2030906@online.de>
Message-ID: <1587960102.89.0.245872957545.issue26326@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

With 2.7 now at end-of-life, I'm closing the issue.  Thanks for the report anyway!

----------
nosy: +zach.ware
resolution:  -> out of date
stage: test needed -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26326>
_______________________________________

From report at bugs.python.org  Mon Apr 27 00:03:34 2020
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 27 Apr 2020 04:03:34 +0000
Subject: [issue14418] Document differences in SocketServer between Python 2.6
 and 2.7
In-Reply-To: <1332795225.64.0.202093290254.issue14418@psf.upfronthosting.co.za>
Message-ID: <1587960214.4.0.388825740967.issue14418@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

Since Python 2.7 is now at end-of-life, I'm closing the issue.

----------
nosy: +zach.ware
resolution:  -> out of date
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue14418>
_______________________________________

From report at bugs.python.org  Mon Apr 27 00:05:28 2020
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 27 Apr 2020 04:05:28 +0000
Subject: [issue34884] Python may load incorrect libraries when embedding the
 macOS system python 2.7
In-Reply-To: <1538562876.74.0.545547206417.issue34884@psf.upfronthosting.co.za>
Message-ID: <1587960328.84.0.847473337749.issue34884@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

With 2.7 now at end-of-life, I'm closing this issue.  Thanks for the report anyway, Tim!

----------
nosy: +zach.ware
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34884>
_______________________________________

From report at bugs.python.org  Mon Apr 27 00:09:01 2020
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 27 Apr 2020 04:09:01 +0000
Subject: [issue27435] ctypes library loading and AIX - also for 2.7.X (and
 later)
In-Reply-To: <1467383699.63.0.495142233463.issue27435@psf.upfronthosting.co.za>
Message-ID: <1587960541.15.0.00271788532348.issue27435@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

Thanks Michael, finally getting it closed :)

----------
nosy: +zach.ware
resolution:  -> out of date
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27435>
_______________________________________

From report at bugs.python.org  Mon Apr 27 00:10:24 2020
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 27 Apr 2020 04:10:24 +0000
Subject: [issue31297] Unpickleable ModuleImportError in unittest patch not
 backported to 2.7
In-Reply-To: <1503964395.2.0.931089155502.issue31297@psf.upfronthosting.co.za>
Message-ID: <1587960624.22.0.496799161939.issue31297@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

With 2.7 now EOL, I'm closing the issue.

----------
nosy: +zach.ware
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31297>
_______________________________________

From report at bugs.python.org  Mon Apr 27 00:16:49 2020
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 27 Apr 2020 04:16:49 +0000
Subject: [issue18493] make profile-opt fails with pre-existing python2.7 in
 path
In-Reply-To: <1374169657.94.0.400718605789.issue18493@psf.upfronthosting.co.za>
Message-ID: <1587961009.28.0.985635378169.issue18493@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

This was fixed in 3.x in 2015 and later backported to 2.7 in 2017.  Thanks for the report, Claudio, and I'm sorry nobody noticed this earlier or we could have fixed the issue two years earlier!

----------
nosy: +zach.ware
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18493>
_______________________________________

From report at bugs.python.org  Mon Apr 27 00:18:10 2020
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 27 Apr 2020 04:18:10 +0000
Subject: [issue30967] Crash in PyThread_ReInitTLS() in the child process after
 os.fork() on CentOS 6.5 (Python 2.7.13)
In-Reply-To: <1500457606.55.0.0362958437729.issue30967@psf.upfronthosting.co.za>
Message-ID: <1587961090.09.0.653804538893.issue30967@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

Sorry we didn't really reach a conclusion here, Thomas, but as 2.7 is now EOL I'm going ahead and closing the issue.

----------
nosy: +zach.ware
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30967>
_______________________________________

From report at bugs.python.org  Mon Apr 27 00:19:17 2020
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 27 Apr 2020 04:19:17 +0000
Subject: [issue29640] _PyThreadState_Init and fork race leads to inconsistent
 key list
In-Reply-To: <1487927038.37.0.851881550844.issue29640@psf.upfronthosting.co.za>
Message-ID: <1587961157.4.0.344917319783.issue29640@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

As 2.7 is now EOL, I'm closing the issue.

----------
nosy: +zach.ware
resolution:  -> out of date
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29640>
_______________________________________

From report at bugs.python.org  Mon Apr 27 00:38:54 2020
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 27 Apr 2020 04:38:54 +0000
Subject: [issue11955] 3.3 : test_argparse.py fails 'make test'
In-Reply-To: <1304093741.94.0.09129303291.issue11955@psf.upfronthosting.co.za>
Message-ID: <1587962334.32.0.321567451526.issue11955@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

As we've not seen any issues with this on the buildbots, I'm going ahead and closing it.

----------
nosy: +zach.ware
resolution:  -> fixed
stage: needs patch -> resolved
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue11955>
_______________________________________

From report at bugs.python.org  Mon Apr 27 00:39:40 2020
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 27 Apr 2020 04:39:40 +0000
Subject: [issue15192] test_bufio failures on Win64 buildbot
In-Reply-To: <1340715209.45.0.994879492682.issue15192@psf.upfronthosting.co.za>
Message-ID: <1587962380.11.0.914527817572.issue15192@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

I've not seen this issue on that worker for a very long time; closing the issue.

----------
nosy: +zach.ware
resolution:  -> out of date
stage:  -> resolved
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue15192>
_______________________________________

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: [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 00:46:47 2020
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 27 Apr 2020 04:46:47 +0000
Subject: [issue8940] *HTTPServer need a summary page with API inheritance table
In-Reply-To: <1276003396.33.0.469317406109.issue8940@psf.upfronthosting.co.za>
Message-ID: <1587962807.78.0.163844943463.issue8940@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

Lacking a clearer description of exactly what should be changed and with an official warning in the docs against using the http.server module in production, I'm going to go ahead and close the issue (which happened to be the last issue with "languishing" status).

----------
nosy: +zach.ware
resolution:  -> rejected
stage: needs patch -> resolved
status: languishing -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue8940>
_______________________________________

From report at bugs.python.org  Mon Apr 27 00:59:55 2020
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 27 Apr 2020 04:59:55 +0000
Subject: [issue15426] On a x86_64 Linux workstation,
 the build-from-source is borked.
In-Reply-To: <1342987672.67.0.931013334684.issue15426@psf.upfronthosting.co.za>
Message-ID: <1587963595.95.0.249917530697.issue15426@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

This appears to have likely been addressed by bpo-1294959 and/or other issues over the years.

----------
nosy: +zach.ware
stage: patch review -> resolved
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue15426>
_______________________________________

From report at bugs.python.org  Mon Apr 27 01:03:26 2020
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 27 Apr 2020 05:03:26 +0000
Subject: [issue22866] ssl module in 2.7 should provide a way to configure
 default context options
In-Reply-To: <1415905159.27.0.459058409364.issue22866@psf.upfronthosting.co.za>
Message-ID: <1587963806.17.0.460079844864.issue22866@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

With 2.7 now EOL, I'm closing the issue.

----------
nosy: +zach.ware
resolution:  -> out of date
stage: needs patch -> resolved
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22866>
_______________________________________

From report at bugs.python.org  Mon Apr 27 01:09:18 2020
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 27 Apr 2020 05:09:18 +0000
Subject: [issue7101] tarfile: OSError with TarFile.add(...,
 recursive=True) about non-existing file
In-Reply-To: <1255218562.66.0.694569702907.issue7101@psf.upfronthosting.co.za>
Message-ID: <1587964158.39.0.54016524581.issue7101@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

I agree with Sandro; this should be handled at application level.

----------
nosy: +zach.ware
resolution:  -> not a bug
stage:  -> resolved
status: languishing -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue7101>
_______________________________________

From report at bugs.python.org  Mon Apr 27 01:13:33 2020
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 27 Apr 2020 05:13:33 +0000
Subject: [issue15028] PySys_SetArgv escapes quotes in argv[]
In-Reply-To: <1339089234.78.0.185097327197.issue15028@psf.upfronthosting.co.za>
Message-ID: <1587964413.95.0.927987800695.issue15028@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

Lacking a response from the OP, I'm closing the issue.

----------
nosy: +zach.ware
resolution:  -> not a bug
stage:  -> resolved
status: languishing -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue15028>
_______________________________________

From report at bugs.python.org  Mon Apr 27 01:28:28 2020
From: report at bugs.python.org (Ned Deily)
Date: Mon, 27 Apr 2020 05:28:28 +0000
Subject: [issue40404] Python quit unexpectedly
In-Reply-To: <1587961471.91.0.139904517244.issue40404@roundup.psfhosted.org>
Message-ID: <1587965308.98.0.458401861421.issue40404@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

I'm sorry you are seeing that crash but I'm afraid it is difficult to know exactly what is going here without more information. It appears you are using a Python 3.7.7 from Homebrew along with NumPy and other similar third-party packages from somewhere. The macOS crash trace indicates that the crash occurred within the system dynamic loader, dyld, while apparently being called to find a function pointer for Python's import machinery (in _PyImport_FindSharedFuncptr) to dynamically link to. But with a standard non-debug build of Python, it's not really possible to figure out what was being called and exactly why. Without a reproducible test case, there is nothing much more we can do and, even so, it's pretty unlikely to be a problem in Python itself, more likely some combination of incompatibly-built C or C++ extension modules, environment variable, etc.  Also, without knowing any context here, e.g. was this something that worked before you did some upgrade, etc, it makes it even harder for anyone to speculate.  If you can provide a simple test case, starting with how you installed everything and the exact steps to reproduce, somebody here *might* be able to give a better hint but you will likely get better help if you submit all that information to another forum that specializes in macOS NumPy, if nowhere else, StackOverflow.  Good luck!

----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40404>
_______________________________________

From report at bugs.python.org  Mon Apr 27 01:41:08 2020
From: report at bugs.python.org (Joseph)
Date: Mon, 27 Apr 2020 05:41:08 +0000
Subject: [issue40404] Python quit unexpectedly
In-Reply-To: <1587961471.91.0.139904517244.issue40404@roundup.psfhosted.org>
Message-ID: <1587966068.54.0.244637892054.issue40404@roundup.psfhosted.org>


Joseph <drjosephliu at gmail.com> added the comment:

Sorry I should've added more context. I recently re-installed python on my computer and started getting these errors. It's hard to pinpoint when I get the error exactly, but I find it happens when I shutdown a Jupyter notebook. I'm wondering if this may be alluded to the fact that python has been incorrectly installed on my computer.

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40404>
_______________________________________

From report at bugs.python.org  Mon Apr 27 02:03:35 2020
From: report at bugs.python.org (Ned Deily)
Date: Mon, 27 Apr 2020 06:03:35 +0000
Subject: [issue40404] Python quit unexpectedly
In-Reply-To: <1587961471.91.0.139904517244.issue40404@roundup.psfhosted.org>
Message-ID: <1587967415.82.0.80212031626.issue40404@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

Thanks for the additional info but that still does not really narrow things down much. You don't say how you upgraded Python (from where, from what previous version) nor how you obtained NumPy or Juypter. If you didn't already, I would suggest trying to upgrade all the installed packages that you may have installed manually with pip and make sure you are running the latest versions of everything from Homebrew. Again, unless it's clearly a problem in Python itself, this sort of debugging is out-of-scope for this bug tracker. If you can provide a reproducible test case including installation steps that gives a reasonable indication that Python itself is failing, we could try to proceed further. Sorry!

----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40404>
_______________________________________

From report at bugs.python.org  Mon Apr 27 02:25:09 2020
From: report at bugs.python.org (Ned Deily)
Date: Mon, 27 Apr 2020 06:25:09 +0000
Subject: [issue40272] ModuleNotFoundEror thrown by system python while
 accessing it specifically via venv python
In-Reply-To: <1586774791.09.0.0735699698392.issue40272@roundup.psfhosted.org>
Message-ID: <1587968709.91.0.801153964578.issue40272@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

Without more information, in particular, a reproducible test case, we can only speculate what might be going on.  Suggest you try using some of the debugging tools Python includes, starting with invoking your virtualenv python with the -vv flag. As described here (https://docs.python.org/3/using/cmdline.html#id4) that should show what files are being searched when you attempt to do the failing import.  You should also try looking at the results of invoking that python with -m test.pythoninfo and examining the values of sys.path and any PYTHON* environment variables. If the problem persists, copy the results here. Good luck! (Note that Python 2.7 has reached end-of-life and is no longer supported here.)

----------
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40272>
_______________________________________

From report at bugs.python.org  Mon Apr 27 02:42:47 2020
From: report at bugs.python.org (Chris Withers)
Date: Mon, 27 Apr 2020 06:42:47 +0000
Subject: [issue39966] mock 3.9 bug: Wrapped objects without __bool__ raise
 exception
In-Reply-To: <1584254384.28.0.0187140133308.issue39966@roundup.psfhosted.org>
Message-ID: <1587969767.17.0.330647607135.issue39966@roundup.psfhosted.org>


Chris Withers <chris at withers.org> added the comment:

I'd go with your instincts on what to do next, I'd have a slight preference to keeping behaviour the same as it was in 3.8 if the changes for 3.9 cause more problems. That leaves us no worse off than we were before, and with the opportunity to improve from the current position in a future release.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39966>
_______________________________________

From report at bugs.python.org  Mon Apr 27 03:03:04 2020
From: report at bugs.python.org (Ned Deily)
Date: Mon, 27 Apr 2020 07:03:04 +0000
Subject: [issue40272] ModuleNotFoundEror thrown by system python while
 accessing it specifically via venv python
In-Reply-To: <1586774791.09.0.0735699698392.issue40272@roundup.psfhosted.org>
Message-ID: <1587970984.18.0.137420102502.issue40272@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

One additional thought: there was a longstanding issue specific to using venv on macOS that has recently been fixed (Issue22490); that fix will be released first in Python 3.8.3 which should be available in a few weeks (or, if you are comfortable doing so, you could build it yourself from the current 3.8 branch on Github). If the problem isn't solved otherwise, you could try to see if that fix in 3.8.3 helps.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40272>
_______________________________________

From report at bugs.python.org  Mon Apr 27 03:15:57 2020
From: report at bugs.python.org (Ned Deily)
Date: Mon, 27 Apr 2020 07:15:57 +0000
Subject: [issue40261] Build of Python where make is called from subprocess,
 within a virtualenv, breaks on macOS
In-Reply-To: <1586689461.86.0.934526151918.issue40261@roundup.psfhosted.org>
Message-ID: <1587971757.6.0.6112051807.issue40261@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

Thanks for the easy-to-reproduce test case! It looks like you are running into the problem described in Issue22490 where venv with macOS framework builds could run into problems. A fix for this issue has recently been merged and will be released in upcoming 3.8.3 (a 3.8.3 release candidate should be available in the very near future) and 3.7.8.  I've verified that your test case now works with the current HEAD of 3.8 and fails with 3.8.2.

----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Using realpath for __PYVENV_LAUNCHER__ makes Homebrew installs fragile

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40261>
_______________________________________

From report at bugs.python.org  Mon Apr 27 03:27:29 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 27 Apr 2020 07:27:29 +0000
Subject: [issue40398] get_args(Callable) fails
In-Reply-To: <1587919567.44.0.458722941462.issue40398@roundup.psfhosted.org>
Message-ID: <1587972449.53.0.636970439029.issue40398@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 6292be7adf247589bbf03524f8883cb4cb61f3e9 by Serhiy Storchaka in branch 'master':
bpo-40398: Fix typing.get_args() for special generic aliases. (GH-19720)
https://github.com/python/cpython/commit/6292be7adf247589bbf03524f8883cb4cb61f3e9


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40398>
_______________________________________

From report at bugs.python.org  Mon Apr 27 03:37:57 2020
From: report at bugs.python.org (Ned Deily)
Date: Mon, 27 Apr 2020 07:37:57 +0000
Subject: [issue32444] python -m venv symlink dependency on how python binary
 is called is not documented
In-Reply-To: <1514515697.43.0.213398074469.issue32444@psf.upfronthosting.co.za>
Message-ID: <1587973077.99.0.575246724011.issue32444@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

The behavior of venv has been changed in Python 3.9 to always create a "pythonM.N" link in the venv bin directory, in addition to "pythonM", regardless of how venv was invoked.

----------
nosy: +ned.deily
resolution:  -> duplicate
stage: needs patch -> resolved
status: open -> closed
superseder:  -> shebanged scripts can escape from `venv` depending on how it was created
versions: +Python 3.9 -Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32444>
_______________________________________

From report at bugs.python.org  Mon Apr 27 03:40:52 2020
From: report at bugs.python.org (Ned Deily)
Date: Mon, 27 Apr 2020 07:40:52 +0000
Subject: [issue31363] __PYVENV_LAUNCHER__ breaks calling another venv's
 interpreter
In-Reply-To: <1504684762.02.0.94557793581.issue31363@psf.upfronthosting.co.za>
Message-ID: <1587973252.75.0.559823272448.issue31363@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

This issue has been fixed in the code for Issue22490 which will be released in Python 3.8.3 and 3.7.8.

----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Using realpath for __PYVENV_LAUNCHER__ makes Homebrew installs fragile
versions: +Python 3.7, Python 3.8, Python 3.9 -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31363>
_______________________________________

From report at bugs.python.org  Mon Apr 27 04:59:10 2020
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Mon, 27 Apr 2020 08:59:10 +0000
Subject: [issue31122] SSLContext.wrap_socket() throws OSError with errno == 0
In-Reply-To: <1501874201.48.0.0126792321555.issue31122@psf.upfronthosting.co.za>
Message-ID: <1587977950.43.0.993489013371.issue31122@roundup.psfhosted.org>


Change by R?mi Lapeyre <remi.lapeyre at henki.fr>:


----------
nosy: +remi.lapeyre

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31122>
_______________________________________

From report at bugs.python.org  Mon Apr 27 05:01:53 2020
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Mon, 27 Apr 2020 09:01:53 +0000
Subject: [issue40402] multiprocessing/connection.py broken handle
In-Reply-To: <1587954709.44.0.390905431083.issue40402@roundup.psfhosted.org>
Message-ID: <1587978113.43.0.158555606318.issue40402@roundup.psfhosted.org>


R?mi Lapeyre <remi.lapeyre at henki.fr> added the comment:

Hi Maxi, Python 3.5 now only accept security fixes. Can you reproduce this issue with recent releases and post an example here?

----------
nosy: +remi.lapeyre
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40402>
_______________________________________

From report at bugs.python.org  Mon Apr 27 06:48:59 2020
From: report at bugs.python.org (Riccardo Schirone)
Date: Mon, 27 Apr 2020 10:48:59 +0000
Subject: [issue40338] [Security] urllib and anti-slash (\) in the hostname
In-Reply-To: <1587393818.69.0.0669874545699.issue40338@roundup.psfhosted.org>
Message-ID: <1587984539.96.0.955770457143.issue40338@roundup.psfhosted.org>


Riccardo Schirone <rschiron at redhat.com> added the comment:

I agree I don't see a clear vulnerability here.

----------
nosy: +rschiron

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40338>
_______________________________________

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: [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 07:15:01 2020
From: report at bugs.python.org (Bar Harel)
Date: Mon, 27 Apr 2020 11:15:01 +0000
Subject: [issue40405] asyncio.as_completed documentation misleading
In-Reply-To: <1587986090.72.0.850288416668.issue40405@roundup.psfhosted.org>
Message-ID: <1587986101.86.0.51047094073.issue40405@roundup.psfhosted.org>


Change by Bar Harel <bzvi7919 at gmail.com>:


----------
title: ast -> asyncio.as_completed documentation misleading

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40405>
_______________________________________

From report at bugs.python.org  Mon Apr 27 08:17:59 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 27 Apr 2020 12:17:59 +0000
Subject: [issue29796] [2.7] test_weakref hangs on Python 2.7 on Windows
In-Reply-To: <1489280495.74.0.987527414659.issue29796@psf.upfronthosting.co.za>
Message-ID: <1587989879.79.0.606233587924.issue29796@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Yep, I didn't see any test_weakref hang anymore since this commit.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29796>
_______________________________________

From report at bugs.python.org  Mon Apr 27 08:22:26 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 27 Apr 2020 12:22:26 +0000
Subject: [issue40217] The garbage collector doesn't take in account that
 objects of heap allocated types hold a strong reference to their type
In-Reply-To: <1586276621.78.0.843757244355.issue40217@roundup.psfhosted.org>
Message-ID: <1587990146.67.0.237331307888.issue40217@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 0169d3003be3d072751dd14a5c84748ab63a249f by Pablo Galindo in branch 'master':
bpo-40217: Ensure Py_VISIT(Py_TYPE(self)) is always called for PyType_FromSpec types (GH-19414)
https://github.com/python/cpython/commit/0169d3003be3d072751dd14a5c84748ab63a249f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40217>
_______________________________________

From report at bugs.python.org  Mon Apr 27 08:26:06 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 27 Apr 2020 12:26:06 +0000
Subject: [issue40217] The garbage collector doesn't take in account that
 objects of heap allocated types hold a strong reference to their type
In-Reply-To: <1586276621.78.0.843757244355.issue40217@roundup.psfhosted.org>
Message-ID: <1587990366.33.0.854329599215.issue40217@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> Serhiy: would it be possible to fix this issue in alpha6? Can we merge PR 19414? In the lack of reply, I think that the best to merge PR 19414.

I asked Lukasz (Python 3.9 release manager) in private and he is ok to merge this PR. He plans to wait until Refleak buildbots turn green again before tagging Python 3.9.0alpha6.


Serhiy:
> I do not think it is right. Please wait, I'll submit an alternate solution.

Serhiy: I merged Pablo's PR to unblock Refleak buildbots, but I'm still curious to see what you have to propose. We can still change the code before 3.9.0beta1.

Don't hesitate to propose your PR! (your PR will have to revert commit 0169d3003be3d072751dd14a5c84748ab63a249f).

--

Pablo: would you mind to write a NEWS entry (in the C API category) for your change? IMHO the commit title is good enough to be reused as the NEWS entry. I added "skip news" label just to unblock buildbots.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40217>
_______________________________________

From report at bugs.python.org  Mon Apr 27 08:41:32 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 27 Apr 2020 12:41:32 +0000
Subject: [issue40335] [PEP 617 new parser] Regression in multiline SyntaxError
 offsets
In-Reply-To: <1587332455.2.0.964330224308.issue40335@roundup.psfhosted.org>
Message-ID: <1587991292.61.0.916058128336.issue40335@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Until a fix is shipped, you can use -X oldparser command line option or PYTHONOLDPARSER=1 environment variable:
https://docs.python.org/dev/whatsnew/3.9.html#pep-617-new-parser

----------
nosy: +vstinner
title: Regression in multiline SyntaxError offsets -> [PEP 617 new parser] Regression in multiline SyntaxError offsets

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40335>
_______________________________________

From report at bugs.python.org  Mon Apr 27 08:58:38 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 27 Apr 2020 12:58:38 +0000
Subject: [issue40149] test_threading leaked [38, 38, 38] references, sum=114
In-Reply-To: <1585792445.62.0.0518463995906.issue40149@roundup.psfhosted.org>
Message-ID: <1587992318.71.0.219086055157.issue40149@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> I created bpo-40217: "The garbage collector doesn't take in account that objects of heap allocated types hold a strong reference to their type".

This issue is now fixed. I tested manually: I confirm that it does fix the test_threading leak, so I close the issue.

$ ./python -m test -R 3:3 test_threading
(...)
== Tests result: SUCCESS ==

1 test OK.

Total duration: 1 min 14 sec
Tests result: SUCCESS

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40149>
_______________________________________

From report at bugs.python.org  Mon Apr 27 09:01:59 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 27 Apr 2020 13:01:59 +0000
Subject: [issue40217] The garbage collector doesn't take in account that
 objects of heap allocated types hold a strong reference to their type
In-Reply-To: <1586276621.78.0.843757244355.issue40217@roundup.psfhosted.org>
Message-ID: <1587992519.07.0.797340820693.issue40217@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
pull_requests: +19054
pull_request: https://github.com/python/cpython/pull/19733

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40217>
_______________________________________

From report at bugs.python.org  Mon Apr 27 09:01:46 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 27 Apr 2020 13:01:46 +0000
Subject: [issue40217] The garbage collector doesn't take in account that
 objects of heap allocated types hold a strong reference to their type
In-Reply-To: <1586276621.78.0.843757244355.issue40217@roundup.psfhosted.org>
Message-ID: <1587992506.28.0.428074899358.issue40217@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

FYI I closed bpo-40149: the commit 0169d3003be3d072751dd14a5c84748ab63a249f fixed test_threading leak.

--

For master, it would be nice to have a NEWS entry, and maybe also a What's New in Python 3.9 entry, maybe in the "Changes in the C API" section.

--

Now, what about Python 3.8? The commit 364f0b0f19cc3f0d5e63f571ec9163cf41c62958 is part of Python 3.8.0. Is it ok to backport the commit 0169d3003be3d072751dd14a5c84748ab63a249f into Python 3.8.3?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40217>
_______________________________________

From report at bugs.python.org  Mon Apr 27 09:22:02 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 27 Apr 2020 13:22:02 +0000
Subject: [issue40405] asyncio.as_completed documentation misleading
In-Reply-To: <1587986090.72.0.850288416668.issue40405@roundup.psfhosted.org>
Message-ID: <1587993722.41.0.0501457761067.issue40405@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy:  -vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40405>
_______________________________________

From report at bugs.python.org  Mon Apr 27 09:23:13 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 27 Apr 2020 13:23:13 +0000
Subject: [issue40338] [Security] urllib and anti-slash (\) in the hostname
In-Reply-To: <1587393818.69.0.0669874545699.issue40338@roundup.psfhosted.org>
Message-ID: <1587993793.45.0.931824216523.issue40338@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

We consider that the stdlib is not vulnerable, so I close the issue.

Feel free to report vulnerabilities to third party projects which are vulnerable.

Thanks for the report anyway David Sch?tz!

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40338>
_______________________________________

From report at bugs.python.org  Mon Apr 27 09:23:42 2020
From: report at bugs.python.org (Maxi)
Date: Mon, 27 Apr 2020 13:23:42 +0000
Subject: [issue40402] multiprocessing/connection.py broken handle
In-Reply-To: <1587978113.43.0.158555606318.issue40402@roundup.psfhosted.org>
Message-ID: <tdl2a1ITaLv3RZVIzqF-WdSavQ1PY6nbjCLUwCQDp9jcFFIQkAKQmMs6T0Jy191WxAGtKXYhrAOo8A2lk2OWiQpuULdJY7k9OnFyilP34hE=@protonmail.com>


Maxi <maxicooper at protonmail.com> added the comment:

Hi R?mi. This is a production environment and can't reproduce it in the dev server (probably because of the lack of volume).

I did checked that the code is the same up to Python 3.8, but can't confirm an actual case until we upgrade in prod.

??????? Original Message ???????
On Monday, 27 de April de 2020 6:01, R?mi Lapeyre <report at bugs.python.org> wrote:

> R?mi Lapeyre remi.lapeyre at henki.fr added the comment:
>
> Hi Maxi, Python 3.5 now only accept security fixes. Can you reproduce this issue with recent releases and post an example here?
>
> ----------------------------------------------------------------------------------------------------------------------------------
>
> nosy: +remi.lapeyre
> type: crash -> behavior
>
> Python tracker report at bugs.python.org
> https://bugs.python.org/issue40402

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40402>
_______________________________________

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: [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 09:34:16 2020
From: report at bugs.python.org (Thomas Grainger)
Date: Mon, 27 Apr 2020 13:34:16 +0000
Subject: [issue40406] MagicMock __aenter__ should be
 AsyncMock(return_value=MagicMock())
In-Reply-To: <1587994408.9.0.812209740883.issue40406@roundup.psfhosted.org>
Message-ID: <1587994456.1.0.965820284744.issue40406@roundup.psfhosted.org>


Thomas Grainger <tagrain at gmail.com> added the comment:

Perhaps there could be a MagicAsyncMock that supports .__await__ and .__aenter__ etc?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40406>
_______________________________________

From report at bugs.python.org  Mon Apr 27 09:40:17 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 27 Apr 2020 13:40:17 +0000
Subject: [issue40333] Request for multi-phase initialization API to run code
 after importlib init
In-Reply-To: <1587327033.84.0.66503294203.issue40333@roundup.psfhosted.org>
Message-ID: <1587994817.03.0.320897018479.issue40333@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> 5) Remove PathFinder if filesystem imports are disabled

Extract of importlib._bootstrap_external._install():

def _install(_bootstrap_module):
    ...
    sys.meta_path.append(PathFinder)

PathFinder is always registered. So you are not only asking for an API to customize sys.path, but also to customize sys.meta_path, right?


> A super minor paper cut is the lack of a PyConfig_SetBytesString() variant for PyWideStringList_Append(). It was slightly annoying having to convert a POSIX char* path to a wchar_t* since paths on POSIX are bytes.

Would you mind to open a separated issue for this feature request?


> It would be useful if there were some kind of PyErr API that returned a PyString (or PyStatus) and was guaranteed to work before main is initialized.

Are you asking to format the current exception as a string? Something like traceback.format_exc() but as a C function?


> Overall, the new code in PyOxidizer is much, much cleaner! Thanks again for the new API!

You're welcome. PyOxidizer is a good use case for PEP 587 (PyConfig). Sadly, you have to drop support for Python 3.8 and older, or maintain two code paths. I saw many projects which maintains two code paths: one for Python 3 (use Unicode and a few other changes), one for Python 2 (use bytes).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40333>
_______________________________________

From report at bugs.python.org  Mon Apr 27 09:42:26 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 27 Apr 2020 13:42:26 +0000
Subject: [issue40092] Crash in _PyThreadState_DeleteExcept() at fork in the
 process child
In-Reply-To: <1585329415.65.0.534969367772.issue40092@roundup.psfhosted.org>
Message-ID: <1587994946.07.0.570963979369.issue40092@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> Do we have any pep or discuss record about this plan?

"since we are going to delete the threading.Thread object with its _tstate_lock object anyway" sentence is a description of the current _PyThreadState_DeleteExcept() implementation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40092>
_______________________________________

From report at bugs.python.org  Mon Apr 27 10:01:14 2020
From: report at bugs.python.org (Avram)
Date: Mon, 27 Apr 2020 14:01:14 +0000
Subject: [issue39966] mock 3.9 bug: Wrapped objects without __bool__ raise
 exception
In-Reply-To: <1584254384.28.0.0187140133308.issue39966@roundup.psfhosted.org>
Message-ID: <1587996074.53.0.984058713266.issue39966@roundup.psfhosted.org>


Avram <python at avram.us> added the comment:

Checking for presence and then falling through to the <=3.8 behavior as in the patch, seems reasonable. The default magic method behavior presumably comes out of research, trial, and error. If the docs need to be clearer, I think that's different that scrapping the whole approach.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39966>
_______________________________________

From report at bugs.python.org  Mon Apr 27 10:02:36 2020
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Mon, 27 Apr 2020 14:02:36 +0000
Subject: [issue40217] The garbage collector doesn't take in account that
 objects of heap allocated types hold a strong reference to their type
In-Reply-To: <1586276621.78.0.843757244355.issue40217@roundup.psfhosted.org>
Message-ID: <1587996156.46.0.870033495684.issue40217@roundup.psfhosted.org>


?ukasz Langa <lukasz at langa.pl> added the comment:

Please backport to 3.8, then it will become part of 3.8.3rc1 which I'll be releasing tomorrow.

----------
nosy: +lukasz.langa

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40217>
_______________________________________

From report at bugs.python.org  Mon Apr 27 10:07:09 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 27 Apr 2020 14:07:09 +0000
Subject: [issue40406] MagicMock __aenter__ should be
 AsyncMock(return_value=MagicMock())
In-Reply-To: <1587994408.9.0.812209740883.issue40406@roundup.psfhosted.org>
Message-ID: <1587996429.13.0.781071944105.issue40406@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +lisroach, xtreak
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40406>
_______________________________________

From report at bugs.python.org  Mon Apr 27 10:24:38 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 27 Apr 2020 14:24:38 +0000
Subject: [issue40217] The garbage collector doesn't take in account that
 objects of heap allocated types hold a strong reference to their type
In-Reply-To: <1586276621.78.0.843757244355.issue40217@roundup.psfhosted.org>
Message-ID: <1587997478.86.0.714918103586.issue40217@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset 91a5ae18351027867e99c96db5ea235d9c42e47a by Pablo Galindo in branch 'master':
bpo-40217: Clean code in PyType_FromSpec_Alloc and add NEWS entry (GH-19733)
https://github.com/python/cpython/commit/91a5ae18351027867e99c96db5ea235d9c42e47a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40217>
_______________________________________

From report at bugs.python.org  Mon Apr 27 10:43:50 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 27 Apr 2020 14:43:50 +0000
Subject: [issue25597] unittest.mock does not wrap dunder methods (__getitem__
 etc)
In-Reply-To: <1447174958.96.0.448093662654.issue25597@psf.upfronthosting.co.za>
Message-ID: <1587998630.29.0.135921043394.issue25597@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
pull_requests: +19056
pull_request: https://github.com/python/cpython/pull/19734

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25597>
_______________________________________

From report at bugs.python.org  Mon Apr 27 10:43:50 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 27 Apr 2020 14:43:50 +0000
Subject: [issue39966] mock 3.9 bug: Wrapped objects without __bool__ raise
 exception
In-Reply-To: <1584254384.28.0.0187140133308.issue39966@roundup.psfhosted.org>
Message-ID: <1587998630.11.0.29158941754.issue39966@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
pull_requests: +19055
pull_request: https://github.com/python/cpython/pull/19734

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39966>
_______________________________________

From report at bugs.python.org  Mon Apr 27 10:52:47 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 27 Apr 2020 14:52:47 +0000
Subject: [issue39966] mock 3.9 bug: Wrapped objects without __bool__ raise
 exception
In-Reply-To: <1584254384.28.0.0187140133308.issue39966@roundup.psfhosted.org>
Message-ID: <1587999167.47.0.143438191674.issue39966@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

I opened a PR to revert the change. issue25597 was open for sometime and the implications as reported here seem to be greater than the original report to just call the magicmethod. So we can revert the change to ensure there are no regressions in Python 3.9 for first beta and discuss the behavior for a later release.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39966>
_______________________________________

From report at bugs.python.org  Mon Apr 27 10:53:01 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Mon, 27 Apr 2020 14:53:01 +0000
Subject: [issue40375] Add the UNSELECT command to imaplib
In-Reply-To: <1587689097.33.0.419593805597.issue40375@roundup.psfhosted.org>
Message-ID: <1587999181.86.0.630643930098.issue40375@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:


New changeset c5c42815ecb560bbf34db99b0e15fe9b604be889 by Dong-hee Na in branch 'master':
bpo-40375: Implement imaplib.IMAP4.unselect (GH-19712)
https://github.com/python/cpython/commit/c5c42815ecb560bbf34db99b0e15fe9b604be889


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40375>
_______________________________________

From report at bugs.python.org  Mon Apr 27 10:59:53 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Mon, 27 Apr 2020 14:59:53 +0000
Subject: [issue40375] Add the UNSELECT command to imaplib
In-Reply-To: <1587689097.33.0.419593805597.issue40375@roundup.psfhosted.org>
Message-ID: <1587999593.51.0.281183224489.issue40375@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

I am now closing this issue.

Thank you Eric and Victor for the review!

----------
nosy: +vstinner
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40375>
_______________________________________

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: [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:20:29 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 27 Apr 2020 15:20:29 +0000
Subject: [issue30966] multiprocessing.queues.SimpleQueue leaks 2 fds
In-Reply-To: <1500454402.66.0.425527808924.issue30966@psf.upfronthosting.co.za>
Message-ID: <1588000829.08.0.687358850222.issue30966@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
keywords: +patch
pull_requests: +19057
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19735

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30966>
_______________________________________

From report at bugs.python.org  Mon Apr 27 11:28:06 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 27 Apr 2020 15:28:06 +0000
Subject: [issue40405] asyncio.as_completed documentation misleading
In-Reply-To: <1587986090.72.0.850288416668.issue40405@roundup.psfhosted.org>
Message-ID: <1588001286.31.0.539795030688.issue40405@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

I declare this not a bug.

The docs do not promise that the Futures being returned are the *same* Futures that were passed in. They are not. They are (or at least may be) new Futures that represent the same event. Since Futures, when used as dict keys, use identity as equality, those new Futures will not be present as keys in the mapping of Futures passed in by the OP.

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40405>
_______________________________________

From report at bugs.python.org  Mon Apr 27 11:45:22 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 27 Apr 2020 15:45:22 +0000
Subject: [issue18999] Support different contexts in multiprocessing
In-Reply-To: <1378824821.26.0.31883015251.issue18999@psf.upfronthosting.co.za>
Message-ID: <1588002322.91.0.523355224972.issue18999@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

It seems like this issue has been fixed, so I set its status to closed.

----------
nosy: +vstinner
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18999>
_______________________________________

From report at bugs.python.org  Mon Apr 27 11:47:07 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 27 Apr 2020 15:47:07 +0000
Subject: [issue30966] multiprocessing.queues.SimpleQueue leaks 2 fds
In-Reply-To: <1500454402.66.0.425527808924.issue30966@psf.upfronthosting.co.za>
Message-ID: <1588002427.6.0.576184393581.issue30966@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

bpo-23267 is marked as a duplicate of this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30966>
_______________________________________

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: [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 12:02:06 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 27 Apr 2020 16:02:06 +0000
Subject: [issue39995] test_concurrent_futures:
 ProcessPoolSpawnExecutorDeadlockTest.test_crash() fails with OSError: [Errno
 9] Bad file descriptor
In-Reply-To: <1584464514.72.0.0566985296328.issue39995@roundup.psfhosted.org>
Message-ID: <1588003326.9.0.949198552903.issue39995@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

See also bpo-30966 "Add multiprocessing.SimpleQueue.close()".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39995>
_______________________________________

From report at bugs.python.org  Mon Apr 27 12:02:38 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 27 Apr 2020 16:02:38 +0000
Subject: [issue30966] Add multiprocessing.queues.SimpleQueue.close()
In-Reply-To: <1500454402.66.0.425527808924.issue30966@psf.upfronthosting.co.za>
Message-ID: <1588003358.28.0.453648906094.issue30966@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
title: multiprocessing.queues.SimpleQueue leaks 2 fds -> Add multiprocessing.queues.SimpleQueue.close()

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30966>
_______________________________________

From report at bugs.python.org  Mon Apr 27 12:11:20 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 27 Apr 2020 16:11:20 +0000
Subject: [issue30966] Add multiprocessing.queues.SimpleQueue.close()
In-Reply-To: <1500454402.66.0.425527808924.issue30966@psf.upfronthosting.co.za>
Message-ID: <1588003880.5.0.0203543902037.issue30966@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 9adccc1384568f4d46e37f698cb3e3a4f6ca0252 by Victor Stinner in branch 'master':
bpo-30966: Add multiprocessing.SimpleQueue.close() (GH-19735)
https://github.com/python/cpython/commit/9adccc1384568f4d46e37f698cb3e3a4f6ca0252


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30966>
_______________________________________

From report at bugs.python.org  Mon Apr 27 12:16:01 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 27 Apr 2020 16:16:01 +0000
Subject: [issue40405] asyncio.as_completed documentation misleading
In-Reply-To: <1587986090.72.0.850288416668.issue40405@roundup.psfhosted.org>
Message-ID: <1588004161.92.0.970367118013.issue40405@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

Reopening so as to give the OP one more chance to state their case. They wrote:

"""
You've immediately closed the issue so I couldn't even reply to it,
Unfortunately, it doesn't return a Future object at all, so technically you're wrong, together with the docs of course, which was the bug I reported...
"""

If it's not a Future then what? You're not showing that in your report.

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40405>
_______________________________________

From report at bugs.python.org  Mon Apr 27 12:25:00 2020
From: report at bugs.python.org (Bar Harel)
Date: Mon, 27 Apr 2020 16:25:00 +0000
Subject: [issue40405] asyncio.as_completed documentation misleading
In-Reply-To: <1587986090.72.0.850288416668.issue40405@roundup.psfhosted.org>
Message-ID: <1588004700.79.0.576663440786.issue40405@roundup.psfhosted.org>


Bar Harel <bzvi7919 at gmail.com> added the comment:

It's a coroutine. Basically the same coroutine yielded over and over, returning the first future's result each time.
Like I said, I'm not entirely sure how to phrase it.
Maybe "Returns an iterator of awaitables"?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40405>
_______________________________________

From report at bugs.python.org  Mon Apr 27 12:41:12 2020
From: report at bugs.python.org (Peter Ludemann)
Date: Mon, 27 Apr 2020 16:41:12 +0000
Subject: [issue40360] Deprecate lib2to3 (and 2to3) for future removal
In-Reply-To: <1587530454.25.0.44181585934.issue40360@roundup.psfhosted.org>
Message-ID: <1588005672.52.0.647740963956.issue40360@roundup.psfhosted.org>


Change by Peter Ludemann <peter.ludemann at gmail.com>:


----------
nosy: +Peter Ludemann

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40360>
_______________________________________

From report at bugs.python.org  Mon Apr 27 12:49:28 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 27 Apr 2020 16:49:28 +0000
Subject: [issue40405] asyncio.as_completed documentation misleading
In-Reply-To: <1587986090.72.0.850288416668.issue40405@roundup.psfhosted.org>
Message-ID: <1588006168.63.0.214401135662.issue40405@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

Oh, you're right. The docstring correctly says this. :-(

Do you have the power to submit a PR? I think it should just say that the return values are coroutines (which is what it does). @Yury what do you think?

----------
resolution: not a bug -> 

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40405>
_______________________________________

From report at bugs.python.org  Mon Apr 27 13:02:14 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 27 Apr 2020 17:02:14 +0000
Subject: [issue40334] PEP 617: new PEG-based parser
In-Reply-To: <1587327377.33.0.614039250584.issue40334@roundup.psfhosted.org>
Message-ID: <1588006934.86.0.434343743418.issue40334@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset 2b74c835a7280840a853e3a9aaeb83758b13a458 by Pablo Galindo in branch 'master':
bpo-40334: Support CO_FUTURE_BARRY_AS_BDFL in the new parser (GH-19721)
https://github.com/python/cpython/commit/2b74c835a7280840a853e3a9aaeb83758b13a458


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40334>
_______________________________________

From report at bugs.python.org  Mon Apr 27 13:13:52 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 27 Apr 2020 17:13:52 +0000
Subject: [issue40334] PEP 617: new PEG-based parser
In-Reply-To: <1587327377.33.0.614039250584.issue40334@roundup.psfhosted.org>
Message-ID: <1588007632.1.0.413410799321.issue40334@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
pull_requests: +19058
pull_request: https://github.com/python/cpython/pull/19736

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40334>
_______________________________________

From report at bugs.python.org  Mon Apr 27 13:36:04 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 27 Apr 2020 17:36:04 +0000
Subject: [issue40334] PEP 617: new PEG-based parser
In-Reply-To: <1587327377.33.0.614039250584.issue40334@roundup.psfhosted.org>
Message-ID: <1588008964.59.0.290964357312.issue40334@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset b94dbd7ac34dc0c79512656eb17f6f07e09fca7a by Pablo Galindo in branch 'master':
bpo-40334: Support PyPARSE_DONT_IMPLY_DEDENT in the new parser (GH-19736)
https://github.com/python/cpython/commit/b94dbd7ac34dc0c79512656eb17f6f07e09fca7a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40334>
_______________________________________

From report at bugs.python.org  Mon Apr 27 13:37:48 2020
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Mon, 27 Apr 2020 17:37:48 +0000
Subject: [issue40402] Race condition in multiprocessing/connection.py: broken
 handle
In-Reply-To: <1587954709.44.0.390905431083.issue40402@roundup.psfhosted.org>
Message-ID: <1588009068.49.0.200808954815.issue40402@roundup.psfhosted.org>


R?mi Lapeyre <remi.lapeyre at henki.fr> added the comment:

A call to self._check_closed() is already present in Python 3.5 https://github.com/python/cpython/blob/3.5/Lib/multiprocessing/connection.py#L202-L206

It is possible for some issues to appear when mixing multiprocessing and multithreading thought:

In [17]: from time import sleep 
    ...: import multiprocessing, threading 
    ...:  
    ...: class Test: 
    ...:     def __reduce__(self): 
    ...:         sleep(1) 
    ...:         return (Test, ()) 
    ...:  
    ...: parent, child = multiprocessing.Pipe() 
    ...: threading.Thread(target=lambda: parent.send(Test())).start() 
    ...: parent.close()                                                                         

Exception in thread Thread-7:
Traceback (most recent call last):
  File "/Users/remi/src/cpython/Lib/threading.py", line 950, in _bootstrap_inner
    self.run()
  File "/Users/remi/src/cpython/Lib/threading.py", line 888, in run
    self._target(*self._args, **self._kwargs)
  File "<ipython-input-17-43406d743010>", line 10, in <lambda>
/Users/remi/src/cpython/venv/lib/python3.9/site-packages/prompt_toolkit/renderer.py:514: DeprecationWarning: The explicit passing of coroutine objects to asyncio.wait() is deprecated since Python 3.8, and scheduled for removal in Python 3.11.
  await wait(coroutines, return_when=FIRST_COMPLETED)
  File "/Users/remi/src/cpython/Lib/multiprocessing/connection.py", line 211, in send
    self._send_bytes(_ForkingPickler.dumps(obj))
  File "/Users/remi/src/cpython/Lib/multiprocessing/connection.py", line 416, in _send_bytes
    self._send(header + buf)
  File "/Users/remi/src/cpython/Lib/multiprocessing/connection.py", line 373, in _send
    n = write(self._handle, buf)
TypeError: an integer is required (got type NoneType)



Maybe using a try-catch block could be more appropriate than the current check.

CC-ing Antoine Pitrou as he is the original author of this part in 87cf220972c9cb400ddcd577962883dcc5dca51a. If you are OK with replacing calls to self._check_closed() by an exception block I would be happy to open a PR for this.

----------
components: +Library (Lib)
nosy: +pitrou
title: multiprocessing/connection.py broken handle -> Race condition in multiprocessing/connection.py: broken handle
versions: +Python 3.7, Python 3.8, Python 3.9 -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40402>
_______________________________________

From report at bugs.python.org  Mon Apr 27 14:01:00 2020
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 27 Apr 2020 18:01:00 +0000
Subject: [issue32117] Tuple unpacking in return and yield statements
In-Reply-To: <1511393509.38.0.213398074469.issue32117@psf.upfronthosting.co.za>
Message-ID: <1588010460.07.0.473077276863.issue32117@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
nosy: +python-dev
nosy_count: 6.0 -> 7.0
pull_requests: +19059
pull_request: https://github.com/python/cpython/pull/19737

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32117>
_______________________________________

From report at bugs.python.org  Mon Apr 27 14:11:46 2020
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 27 Apr 2020 18:11:46 +0000
Subject: [issue40402] Race condition in multiprocessing/connection.py: broken
 handle
In-Reply-To: <1587954709.44.0.390905431083.issue40402@roundup.psfhosted.org>
Message-ID: <1588011106.52.0.872429401706.issue40402@roundup.psfhosted.org>


Antoine Pitrou <solipsis at pitrou.net> added the comment:

I don't know if a try..except block is the best solution, but feel free to submit a PR and we can iterate on that :-)

----------
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40402>
_______________________________________

From report at bugs.python.org  Mon Apr 27 14:30:11 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 27 Apr 2020 18:30:11 +0000
Subject: [issue30966] Add multiprocessing.queues.SimpleQueue.close()
In-Reply-To: <1500454402.66.0.425527808924.issue30966@psf.upfronthosting.co.za>
Message-ID: <1588012211.02.0.418425051402.issue30966@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +19060
pull_request: https://github.com/python/cpython/pull/19738

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30966>
_______________________________________

From report at bugs.python.org  Mon Apr 27 14:47:35 2020
From: report at bugs.python.org (Steve Dower)
Date: Mon, 27 Apr 2020 18:47:35 +0000
Subject: [issue40395] Scripts folder is Empty in python 3.8.2 for Windows 7.
In-Reply-To: <1587910690.73.0.0218819691356.issue40395@roundup.psfhosted.org>
Message-ID: <1588013254.98.0.480507384301.issue40395@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Thanks for including logs!

It looks like pip ran into an issue during install:

C:\Users\<User>\AppData\Local\Temp\tmpppkvx8p2\pip-19.2.3-py2.py3-none-any.whl\pip\_vendor\ipaddress.py:1106: SyntaxWarning: 'str' object is not callable; perhaps you missed a comma?
C:\Users\<User>\AppData\Local\Temp\tmpppkvx8p2\pip-19.2.3-py2.py3-none-any.whl\pip\_vendor\ipaddress.py:1106: SyntaxWarning: 'str' object is not callable; perhaps you missed a comma?
Traceback (most recent call last):
  File "C:\Python\Python38-32\lib\runpy.py", line 193, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "C:\Python\Python38-32\lib\runpy.py", line 86, in _run_code
    exec(code, run_globals)
  File "C:\Python\Python38-32\lib\ensurepip\__main__.py", line 5, in <module>
    sys.exit(ensurepip._main())
  File "C:\Python\Python38-32\lib\ensurepip\__init__.py", line 200, in _main
    return _bootstrap(
  File "C:\Python\Python38-32\lib\ensurepip\__init__.py", line 119, in _bootstrap
    return _run_pip(args + , additional_paths)
  File "C:\Python\Python38-32\lib\ensurepip\__init__.py", line 27, in _run_pip
    import pip._internal
  File "<frozen zipimport>", line 259, in load_module
  File "C:\Users\<User>\AppData\Local\Temp\tmpppkvx8p2\pip-19.2.3-py2.py3-none-any.whl\pip\_internal\__init__.py", line 40, in <module>
  File "<frozen zipimport>", line 259, in load_module
  File "C:\Users\<User>\AppData\Local\Temp\tmpppkvx8p2\pip-19.2.3-py2.py3-none-any.whl\pip\_internal\cli\autocompletion.py", line 8, in <module>
  File "<frozen zipimport>", line 259, in load_module
  File "C:\Users\<User>\AppData\Local\Temp\tmpppkvx8p2\pip-19.2.3-py2.py3-none-any.whl\pip\_internal\cli\main_parser.py", line 7, in <module>
  File "<frozen zipimport>", line 259, in load_module
  File "C:\Users\<User>\AppData\Local\Temp\tmpppkvx8p2\pip-19.2.3-py2.py3-none-any.whl\pip\_internal\cli\cmdoptions.py", line 24, in <module>
  File "<frozen zipimport>", line 259, in load_module
  File "C:\Users\<User>\AppData\Local\Temp\tmpppkvx8p2\pip-19.2.3-py2.py3-none-any.whl\pip\_internal\models\search_scope.py", line 11, in <module>
  File "<frozen zipimport>", line 259, in load_module
  File "C:\Users\<User>\AppData\Local\Temp\tmpppkvx8p2\pip-19.2.3-py2.py3-none-any.whl\pip\_internal\utils\misc.py", line 21, in <module>
  File "<frozen zipimport>", line 259, in load_module
  File "C:\Users\<User>\AppData\Local\Temp\tmpppkvx8p2\pip-19.2.3-py2.py3-none-any.whl\pip\_vendor\pkg_resources\__init__.py", line 35, in <module>
  File "C:\Python\Python38-32\lib\plistlib.py", line 65, in <module>
    from xml.parsers.expat import ParserCreate
  File "C:\Python\Python38-32\lib\xml\parsers\expat.py", line 4, in <module>
    from pyexpat import *
ImportError: DLL load failed while importing pyexpat: The specified module could not be found.
Error 0x80070001: Command line returned an error.
Error 0x80070001: QuietExec Failed

However, as far as I can tell, all the dependencies it needs were installed. So the most likely cause is a virus scanner interfering. (Unless Python does not work for you at all, though that is still likely to be a scanner, since the setup logs seem fine.)

The easiest fix will be to disable your virus scanner and run a Repair install. That should make sure that everything is installed. If pip is the only thing missing, you could also run "python -m ensurepip" as admin.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40395>
_______________________________________

From report at bugs.python.org  Mon Apr 27 14:49:33 2020
From: report at bugs.python.org (Steve Dower)
Date: Mon, 27 Apr 2020 18:49:33 +0000
Subject: [issue40395] Scripts folder is Empty in python 3.8.2 for Windows 7.
In-Reply-To: <1587910690.73.0.0218819691356.issue40395@roundup.psfhosted.org>
Message-ID: <1588013373.95.0.439981728734.issue40395@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

As a secondary issue, why didn't the installer fail on the pip failure? Did we decide at some point not to fail the whole thing just because of pip? (It's probably the most unreliable part, as it's a custom action rather than simple installation.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40395>
_______________________________________

From report at bugs.python.org  Mon Apr 27 14:53:43 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 27 Apr 2020 18:53:43 +0000
Subject: [issue30966] Add multiprocessing.queues.SimpleQueue.close()
In-Reply-To: <1500454402.66.0.425527808924.issue30966@psf.upfronthosting.co.za>
Message-ID: <1588013623.99.0.475522266561.issue30966@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 1a275013d1ecc2e3778d64fda86174b2f13d6969 by Victor Stinner in branch 'master':
bpo-30966: concurrent.futures.Process.shutdown() closes queue (GH-19738)
https://github.com/python/cpython/commit/1a275013d1ecc2e3778d64fda86174b2f13d6969


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30966>
_______________________________________

From report at bugs.python.org  Mon Apr 27 15:06:22 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 27 Apr 2020 19:06:22 +0000
Subject: [issue39995] test_concurrent_futures:
 ProcessPoolSpawnExecutorDeadlockTest.test_crash() fails with OSError: [Errno
 9] Bad file descriptor
In-Reply-To: <1584464514.72.0.0566985296328.issue39995@roundup.psfhosted.org>
Message-ID: <1588014382.68.0.611970091785.issue39995@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
keywords: +patch
pull_requests: +19061
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19739

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39995>
_______________________________________

From report at bugs.python.org  Mon Apr 27 15:16:37 2020
From: report at bugs.python.org (Mario Corchero)
Date: Mon, 27 Apr 2020 19:16:37 +0000
Subject: [issue17013] Allow waiting on a mock
In-Reply-To: <1358856947.82.0.71016271567.issue17013@psf.upfronthosting.co.za>
Message-ID: <1588014997.92.0.772133216136.issue17013@roundup.psfhosted.org>


Mario Corchero <mariocj89 at gmail.com> added the comment:

For the record, I have no strong preference over either implementation. @voidspace preferred offline the new mock class, but sadly the rationale is lost in the physical word.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17013>
_______________________________________

From report at bugs.python.org  Mon Apr 27 15:19:03 2020
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 27 Apr 2020 19:19:03 +0000
Subject: [issue38728] Update PC/pyconfig.h to support disabling auto linking
In-Reply-To: <1573080091.42.0.697826916573.issue38728@roundup.psfhosted.org>
Message-ID: <1588015143.91.0.599954964199.issue38728@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch
nosy: +python-dev
nosy_count: 6.0 -> 7.0
pull_requests: +19062
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19740

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38728>
_______________________________________

From report at bugs.python.org  Mon Apr 27 15:20:20 2020
From: report at bugs.python.org (Ronald Oussoren)
Date: Mon, 27 Apr 2020 19:20:20 +0000
Subject: [issue40381] plistlib doesn't handle poorly-formatted plists
In-Reply-To: <1587757952.37.0.0995683897517.issue40381@roundup.psfhosted.org>
Message-ID: <1588015220.15.0.135300356479.issue40381@roundup.psfhosted.org>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

IMHO this is a bug and plistlib should behave the same as Apple?s libraries here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40381>
_______________________________________

From report at bugs.python.org  Mon Apr 27 15:21:03 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 27 Apr 2020 19:21:03 +0000
Subject: [issue40334] PEP 617: new PEG-based parser
In-Reply-To: <1587327377.33.0.614039250584.issue40334@roundup.psfhosted.org>
Message-ID: <1588015263.18.0.193252949588.issue40334@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

The parser generator imports modules token and tokenize. It is not correct, because they are relevant to the Python version used to run the parser generator, and not to the Python version for which the parser is generated. It works currently only because there is no differences between 3.8 and 3.9, but it will fail when you add a new token or change/remove an old one.

It should either parse the correct Grammar/Tokens file, or read the content of corresponding files Lib/token.py and Lib/tokenize.py and evaluate them with eval(). See for example Tools/scripts/generate_token.py.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40334>
_______________________________________

From report at bugs.python.org  Mon Apr 27 15:36:58 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 27 Apr 2020 19:36:58 +0000
Subject: [issue39995] test_concurrent_futures:
 ProcessPoolSpawnExecutorDeadlockTest.test_crash() fails with OSError: [Errno
 9] Bad file descriptor
In-Reply-To: <1584464514.72.0.0566985296328.issue39995@roundup.psfhosted.org>
Message-ID: <1588016218.32.0.932169411942.issue39995@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 5d1f32d33ba24d0aa87235ae40207bb57778388b by Victor Stinner in branch 'master':
bpo-39995: Split test_concurrent_futures.test_crash() into sub-tests (GH-19739)
https://github.com/python/cpython/commit/5d1f32d33ba24d0aa87235ae40207bb57778388b


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39995>
_______________________________________

From report at bugs.python.org  Mon Apr 27 15:46:17 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 27 Apr 2020 19:46:17 +0000
Subject: [issue39995] test_concurrent_futures:
 ProcessPoolSpawnExecutorDeadlockTest.test_crash() fails with OSError: [Errno
 9] Bad file descriptor
In-Reply-To: <1584464514.72.0.0566985296328.issue39995@roundup.psfhosted.org>
Message-ID: <1588016777.39.0.470940590455.issue39995@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

AMD64 Ubuntu Shared 3.x:
https://buildbot.python.org/all/#/builders/101/builds/809

======================================================================
ERROR: test_shutdown_no_wait (test.test_concurrent_futures.ProcessPoolForkserverProcessPoolShutdownTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/test_concurrent_futures.py", line 542, in test_shutdown_no_wait
    executor.shutdown(wait=False)
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/concurrent/futures/process.py", line 724, in shutdown
    self._executor_manager_thread_wakeup.wakeup()
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/concurrent/futures/process.py", line 80, in wakeup
    self._writer.send_bytes(b"")
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/multiprocessing/connection.py", line 188, in send_bytes
    self._check_closed()
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/multiprocessing/connection.py", line 141, in _check_closed
    raise OSError("handle is closed")
OSError: handle is closed

(...)
0:32:37 load avg: 1.64 Re-running test_concurrent_futures in verbose mode
(...)

======================================================================
ERROR: test_shutdown_no_wait (test.test_concurrent_futures.ProcessPoolForkProcessPoolShutdownTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/test_concurrent_futures.py", line 542, in test_shutdown_no_wait
    executor.shutdown(wait=False)
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/concurrent/futures/process.py", line 724, in shutdown
    self._executor_manager_thread_wakeup.wakeup()
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/concurrent/futures/process.py", line 80, in wakeup
    self._writer.send_bytes(b"")
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/multiprocessing/connection.py", line 205, in send_bytes
    self._send_bytes(m[offset:offset + size])
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/multiprocessing/connection.py", line 416, in _send_bytes
    self._send(header + buf)
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/multiprocessing/connection.py", line 373, in _send
    n = write(self._handle, buf)
OSError: [Errno 9] Bad file descriptor

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39995>
_______________________________________

From report at bugs.python.org  Mon Apr 27 15:54:18 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 27 Apr 2020 19:54:18 +0000
Subject: [issue39995] test_concurrent_futures:
 ProcessPoolSpawnExecutorDeadlockTest.test_crash() fails with OSError: [Errno
 9] Bad file descriptor
In-Reply-To: <1584464514.72.0.0566985296328.issue39995@roundup.psfhosted.org>
Message-ID: <1588017258.37.0.311355532542.issue39995@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> See also bpo-30966 "Add multiprocessing.SimpleQueue.close()".

I pushed a commit 1a275013d1ecc2e3778d64fda86174b2f13d6969: 
"Process.shutdown(wait=True) of concurrent.futures now closes
explicitly the result queue."

test_shutdown_deadlock_pickle() still rely on the queue to be closed implicitly. Queue created at:

  (...)
  File "/home/vstinner/python/master/Lib/test/test_concurrent_futures.py", lineno 1196
    with self.executor_type(max_workers=2,
  File "/home/vstinner/python/master/Lib/concurrent/futures/process.py", lineno 637
    self._result_queue = mp_context.SimpleQueue()
  File "/home/vstinner/python/master/Lib/multiprocessing/context.py", lineno 113
    return SimpleQueue(ctx=self.get_context())
  File "/home/vstinner/python/master/Lib/multiprocessing/queues.py", lineno 341
    self._reader, self._writer = connection.Pipe(duplex=False)
  File "/home/vstinner/python/master/Lib/multiprocessing/connection.py", lineno 539
    c2 = Connection(fd2, readable=False)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39995>
_______________________________________

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: [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 16:09:06 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 27 Apr 2020 20:09:06 +0000
Subject: [issue40408] GenericAlias does not support nested type variables
In-Reply-To: <1588003077.18.0.979842098769.issue40408@roundup.psfhosted.org>
Message-ID: <1588018146.05.0.27906587068.issue40408@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

Good catch. Is there a reasonable fix?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40408>
_______________________________________

From report at bugs.python.org  Mon Apr 27 16:09:04 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 27 Apr 2020 20:09:04 +0000
Subject: [issue39995] test_concurrent_futures:
 ProcessPoolSpawnExecutorDeadlockTest.test_crash() fails with OSError: [Errno
 9] Bad file descriptor
In-Reply-To: <1584464514.72.0.0566985296328.issue39995@roundup.psfhosted.org>
Message-ID: <1588018144.1.0.152928530949.issue39995@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

AMD64 Fedora Stable Clang Installed 3.x:
https://buildbot.python.org/all/#/builders/127/builds/679

0:04:21 load avg: 1.29 [423/423/1] test_concurrent_futures failed (2 min 39 sec)
Warning -- threading_cleanup() failed to cleanup -1 threads (count: 0, dangling: 3)
Warning -- Dangling thread: <_MainThread(MainThread, started 139673296918336)>
Warning -- Dangling thread: <Thread(QueueFeederThread, stopped daemon 139673045362432)>
Warning -- Dangling thread: <_ExecutorManagerThread(Thread-145, stopped 139673053914880)>
Warning -- threading_cleanup() failed to cleanup 0 threads (count: 0, dangling: 3)
Warning -- Dangling thread: <_MainThread(MainThread, started 139673296918336)>
Warning -- Dangling thread: <Thread(QueueFeederThread, stopped daemon 139673045362432)>
Warning -- Dangling thread: <_ExecutorManagerThread(Thread-145, stopped 139673053914880)>
/home/buildbot/buildarea/3.x.cstratak-fedora-stable-x86_64.clang-installed/build/target/lib/python3.9/multiprocessing/resource_tracker.py:216: UserWarning: resource_tracker: There appear to be 5 leaked semaphore objects to clean up at shutdown
  warnings.warn('resource_tracker: There appear to be %d '
Warning -- multiprocessing.process._dangling was modified by test_concurrent_futures
Warning -- threading._dangling was modified by test_concurrent_futures
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_first_exception_some_already_complete (test.test_concurrent_futures.ThreadPoolWaitTests) ... 1.60s ok
test_pending_calls_race (test.test_concurrent_futures.ThreadPoolWaitTests) ... 0.11s ok
test_timeout (test.test_concurrent_futures.ThreadPoolWaitTests) ... 6.11s ok
Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-stable-x86_64.clang-installed/build/target/lib/python3.9/multiprocessing/util.py", line 300, in _run_finalizers
    finalizer()
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-stable-x86_64.clang-installed/build/target/lib/python3.9/multiprocessing/util.py", line 224, in __call__
    res = self._callback(*self._args, **self._kwargs)
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-stable-x86_64.clang-installed/build/target/lib/python3.9/multiprocessing/synchronize.py", line 87, in _cleanup
    sem_unlink(name)
FileNotFoundError: [Errno 2] No such file or directory
Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-stable-x86_64.clang-installed/build/target/lib/python3.9/multiprocessing/util.py", line 300, in _run_finalizers
    finalizer()
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-stable-x86_64.clang-installed/build/target/lib/python3.9/multiprocessing/util.py", line 224, in __call__
    res = self._callback(*self._args, **self._kwargs)
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-stable-x86_64.clang-installed/build/target/lib/python3.9/multiprocessing/synchronize.py", line 87, in _cleanup
    sem_unlink(name)
FileNotFoundError: [Errno 2] No such file or directory
Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-stable-x86_64.clang-installed/build/target/lib/python3.9/multiprocessing/util.py", line 300, in _run_finalizers
    finalizer()
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-stable-x86_64.clang-installed/build/target/lib/python3.9/multiprocessing/util.py", line 224, in __call__
    res = self._callback(*self._args, **self._kwargs)
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-stable-x86_64.clang-installed/build/target/lib/python3.9/multiprocessing/synchronize.py", line 87, in _cleanup
    sem_unlink(name)
FileNotFoundError: [Errno 2] No such file or directory
Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-stable-x86_64.clang-installed/build/target/lib/python3.9/multiprocessing/util.py", line 300, in _run_finalizers
    finalizer()
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-stable-x86_64.clang-installed/build/target/lib/python3.9/multiprocessing/util.py", line 224, in __call__
    res = self._callback(*self._args, **self._kwargs)
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-stable-x86_64.clang-installed/build/target/lib/python3.9/multiprocessing/synchronize.py", line 87, in _cleanup
    sem_unlink(name)
FileNotFoundError: [Errno 2] No such file or directory
Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-stable-x86_64.clang-installed/build/target/lib/python3.9/multiprocessing/util.py", line 300, in _run_finalizers
    finalizer()
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-stable-x86_64.clang-installed/build/target/lib/python3.9/multiprocessing/util.py", line 224, in __call__
    res = self._callback(*self._args, **self._kwargs)
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-stable-x86_64.clang-installed/build/target/lib/python3.9/multiprocessing/synchronize.py", line 87, in _cleanup
    sem_unlink(name)
FileNotFoundError: [Errno 2] No such file or directory

======================================================================
ERROR: test_killed_child (test.test_concurrent_futures.ProcessPoolSpawnProcessPoolExecutorTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-stable-x86_64.clang-installed/build/target/lib/python3.9/test/test_concurrent_futures.py", line 130, in tearDown
    self.executor.shutdown(wait=True)
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-stable-x86_64.clang-installed/build/target/lib/python3.9/concurrent/futures/process.py", line 724, in shutdown
    self._executor_manager_thread_wakeup.wakeup()
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-stable-x86_64.clang-installed/build/target/lib/python3.9/concurrent/futures/process.py", line 80, in wakeup
    self._writer.send_bytes(b"")
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-stable-x86_64.clang-installed/build/target/lib/python3.9/multiprocessing/connection.py", line 205, in send_bytes
    self._send_bytes(m[offset:offset + size])
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-stable-x86_64.clang-installed/build/target/lib/python3.9/multiprocessing/connection.py", line 416, in _send_bytes
    self._send(header + buf)
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-stable-x86_64.clang-installed/build/target/lib/python3.9/multiprocessing/connection.py", line 373, in _send
    n = write(self._handle, buf)
OSError: [Errno 9] Bad file descriptor

----------------------------------------------------------------------

Ran 193 tests in 159.805s

FAILED (errors=1, skipped=6)
  Before: set()
  After:  {<weakref at 0x7f0828b17bd0; to 'SpawnProcess' at 0x7f082ace7400>, <weakref at 0x7f0828b17b80; to 'SpawnProcess' at 0x7f082ace7880>, <weakref at 0x7f0828b17b30; to 'SpawnProcess' at 0x7f0828bbc0a0>, <weakref at 0x7f0828b17720; to 'SpawnProcess' at 0x7f082ace72e0>, <weakref at 0x7f0828b17a90; to 'SpawnProcess' at 0x7f082ace7910>} 
  Before: {<weakref at 0x7f082b5ad400; to '_MainThread' at 0x7f082bcd8850>}
  After:  {<weakref at 0x7f0828b4d900; to 'Thread' at 0x7f0828bbc4c0>, <weakref at 0x7f0828b4d0e0; to '_MainThread' at 0x7f082bcd8850>, <weakref at 0x7f0828b17a40; to '_ExecutorManagerThread' at 0x7f0828bbc8e0>} 
test test_concurrent_futures failed

== Tests result: FAILURE ==

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39995>
_______________________________________

From report at bugs.python.org  Mon Apr 27 16:21:34 2020
From: report at bugs.python.org (Samani Gikandi)
Date: Mon, 27 Apr 2020 20:21:34 +0000
Subject: [issue40409] urllib.parse.urlsplit parses schemes that do not begin
 with letters
In-Reply-To: <1588017589.4.0.372039789784.issue40409@roundup.psfhosted.org>
Message-ID: <1588018894.79.0.287114967693.issue40409@roundup.psfhosted.org>


Change by Samani Gikandi <samani at gojulas.com>:


----------
keywords: +patch
pull_requests: +19063
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19741

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40409>
_______________________________________

From report at bugs.python.org  Mon Apr 27 16:34:21 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 27 Apr 2020 20:34:21 +0000
Subject: [issue39995] test_concurrent_futures:
 ProcessPoolSpawnExecutorDeadlockTest.test_crash() fails with OSError: [Errno
 9] Bad file descriptor
In-Reply-To: <1584464514.72.0.0566985296328.issue39995@roundup.psfhosted.org>
Message-ID: <1588019661.93.0.175807114745.issue39995@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

x86 Gentoo Installed with X 3.x:
https://buildbot.python.org/all/#/builders/128/builds/726

test_del_shutdown (test.test_concurrent_futures.ProcessPoolSpawnProcessPoolShutdownTest) ...

Warning -- Unraisable exception
Exception ignored in: <function _ExecutorManagerThread.__init__.<locals>.weakref_cb at 0xb5067898>
Traceback (most recent call last):
  File "/buildbot/buildarea/cpython/3.x.ware-gentoo-x86.installed/build/target/lib/python3.9/concurrent/futures/process.py", line 281, in weakref_cb
    thread_wakeup.wakeup()
  File "/buildbot/buildarea/cpython/3.x.ware-gentoo-x86.installed/build/target/lib/python3.9/concurrent/futures/process.py", line 80, in wakeup
    self._writer.send_bytes(b"")
  File "/buildbot/buildarea/cpython/3.x.ware-gentoo-x86.installed/build/target/lib/python3.9/multiprocessing/connection.py", line 205, in send_bytes
    self._send_bytes(m[offset:offset + size])
  File "/buildbot/buildarea/cpython/3.x.ware-gentoo-x86.installed/build/target/lib/python3.9/multiprocessing/connection.py", line 416, in _send_bytes
    self._send(header + buf)
  File "/buildbot/buildarea/cpython/3.x.ware-gentoo-x86.installed/build/target/lib/python3.9/multiprocessing/connection.py", line 373, in _send
    n = write(self._handle, buf)
OSError: [Errno 9] Bad file descriptor

0.04s ok

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39995>
_______________________________________

From report at bugs.python.org  Mon Apr 27 16:34:48 2020
From: report at bugs.python.org (Lewis Ball)
Date: Mon, 27 Apr 2020 20:34:48 +0000
Subject: [issue40394] difflib.SequenceMatcher.find_longest_match default
 arguments
In-Reply-To: <1587910558.56.0.865649390619.issue40394@roundup.psfhosted.org>
Message-ID: <1588019688.79.0.293977219863.issue40394@roundup.psfhosted.org>


Lewis Ball <lrjball at gmail.com> added the comment:

Okay, that makes sense. I will raise a PR

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40394>
_______________________________________

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: [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 17:15:57 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 27 Apr 2020 21:15:57 +0000
Subject: [issue39995] test_concurrent_futures:
 ProcessPoolSpawnExecutorDeadlockTest.test_crash() fails with OSError: [Errno
 9] Bad file descriptor
In-Reply-To: <1584464514.72.0.0566985296328.issue39995@roundup.psfhosted.org>
Message-ID: <1588022157.48.0.118072866997.issue39995@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

ERROR: test_killed_child (test.test_concurrent_futures.ProcessPoolSpawnProcessPoolExecutorTest)
  (...)
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-stable-x86_64.clang-installed/build/target/lib/python3.9/multiprocessing/connection.py", line 373, in _send
    n = write(self._handle, buf)
OSError: [Errno 9] Bad file descriptor

It seems like Connection.close() was called while Connection._send() was called. I added debug logs:

* self._handle was equal to 4 at the function entry
* self._handle was equal to None when write() was called

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39995>
_______________________________________

From report at bugs.python.org  Mon Apr 27 17:18:55 2020
From: report at bugs.python.org (Lewis Ball)
Date: Mon, 27 Apr 2020 21:18:55 +0000
Subject: [issue40394] difflib.SequenceMatcher.find_longest_match default
 arguments
In-Reply-To: <1587910558.56.0.865649390619.issue40394@roundup.psfhosted.org>
Message-ID: <1588022335.77.0.245630760908.issue40394@roundup.psfhosted.org>


Lewis Ball <lrjball at gmail.com> added the comment:

Adding a test for this and noticed I can add one more test case to get the method to full coverage. Can I add that to this PR or should I raise a separate one?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40394>
_______________________________________

From report at bugs.python.org  Mon Apr 27 17:26:50 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 27 Apr 2020 21:26:50 +0000
Subject: [issue39995] test_concurrent_futures:
 ProcessPoolSpawnExecutorDeadlockTest.test_crash() fails with OSError: [Errno
 9] Bad file descriptor
In-Reply-To: <1584464514.72.0.0566985296328.issue39995@roundup.psfhosted.org>
Message-ID: <1588022810.67.0.295026123885.issue39995@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> It seems like Connection.close() was called while Connection._send() was called. I added debug logs:

The connection was closed by terminate_broken() called by _ExecutorManagerThread.run() thread:

test_killed_child (test.test_concurrent_futures.ProcessPoolSpawnProcessPoolExecutorTest) ... close handle 4
  File "/home/vstinner/python/master/Lib/threading.py", line 908, in _bootstrap
    self._bootstrap_inner()
  File "/home/vstinner/python/master/Lib/threading.py", line 950, in _bootstrap_inner
    self.run()
  File "/home/vstinner/python/master/Lib/concurrent/futures/process.py", line 313, in run
    self.terminate_broken(cause)
  File "/home/vstinner/python/master/Lib/concurrent/futures/process.py", line 456, in terminate_broken
    self.join_executor_internals()
  File "/home/vstinner/python/master/Lib/concurrent/futures/process.py", line 503, in join_executor_internals
    self.thread_wakeup.close()
  File "/home/vstinner/python/master/Lib/concurrent/futures/process.py", line 75, in close
    self._writer.close()

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39995>
_______________________________________

From report at bugs.python.org  Mon Apr 27 17:27:46 2020
From: report at bugs.python.org (Tim Peters)
Date: Mon, 27 Apr 2020 21:27:46 +0000
Subject: [issue40394] difflib.SequenceMatcher.find_longest_match default
 arguments
In-Reply-To: <1587910558.56.0.865649390619.issue40394@roundup.psfhosted.org>
Message-ID: <1588022866.33.0.421677445131.issue40394@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

I'm not clear on exactly what it is you're asking, but it's better to ask for forgiveness than permission ;-)  That is, it's unlikely anyone will object to adding a test in a feature PR.

----------
stage:  -> needs patch
versions: +Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40394>
_______________________________________

From report at bugs.python.org  Mon Apr 27 17:46:19 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 27 Apr 2020 21:46:19 +0000
Subject: [issue39995] test_concurrent_futures:
 ProcessPoolSpawnExecutorDeadlockTest.test_crash() fails with OSError: [Errno
 9] Bad file descriptor
In-Reply-To: <1584464514.72.0.0566985296328.issue39995@roundup.psfhosted.org>
Message-ID: <1588023979.49.0.198584026319.issue39995@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

terminate_broken() method was added by:

commit 0e89076247580ba0e570c4816f0e5628a7e36e83
Author: Thomas Moreau <thomas.moreau.2010 at gmail.com>
Date:   Sun Mar 1 21:49:14 2020 +0100

    bpo-39678: refactor queue manager thread (GH-18551)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39995>
_______________________________________

From report at bugs.python.org  Mon Apr 27 17:48:28 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 27 Apr 2020 21:48:28 +0000
Subject: [issue39995] test_concurrent_futures:
 ProcessPoolSpawnExecutorDeadlockTest.test_crash() fails with OSError: [Errno
 9] Bad file descriptor
In-Reply-To: <1584464514.72.0.0566985296328.issue39995@roundup.psfhosted.org>
Message-ID: <1588024108.26.0.879942960166.issue39995@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> ERROR: test_killed_child (test.test_concurrent_futures.ProcessPoolSpawnProcessPoolExecutorTest)

The patch below makes this test failure more likely:

diff --git a/Lib/multiprocessing/connection.py b/Lib/multiprocessing/connection.py
index 510e4b5aba..63518e55d9 100644
--- a/Lib/multiprocessing/connection.py
+++ b/Lib/multiprocessing/connection.py
@@ -370,6 +370,7 @@ class Connection(_ConnectionBase):
     def _send(self, buf, write=_write):
         remaining = len(buf)
         while True:
+            time.sleep(0.050)
             n = write(self._handle, buf)
             remaining -= n
             if remaining == 0:

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39995>
_______________________________________

From report at bugs.python.org  Mon Apr 27 17:52:36 2020
From: report at bugs.python.org (Lewis Ball)
Date: Mon, 27 Apr 2020 21:52:36 +0000
Subject: [issue40394] difflib.SequenceMatcher.find_longest_match default
 arguments
In-Reply-To: <1587910558.56.0.865649390619.issue40394@roundup.psfhosted.org>
Message-ID: <1588024356.64.0.249997514739.issue40394@roundup.psfhosted.org>


Change by Lewis Ball <lrjball at gmail.com>:


----------
keywords: +patch
pull_requests: +19064
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/19742

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40394>
_______________________________________

From report at bugs.python.org  Mon Apr 27 17:55:19 2020
From: report at bugs.python.org (Lewis Ball)
Date: Mon, 27 Apr 2020 21:55:19 +0000
Subject: [issue40394] difflib.SequenceMatcher.find_longest_match default
 arguments
In-Reply-To: <1587910558.56.0.865649390619.issue40394@roundup.psfhosted.org>
Message-ID: <1588024519.35.0.640689179906.issue40394@roundup.psfhosted.org>


Lewis Ball <lrjball at gmail.com> added the comment:

Oh okay, well I was just saying I have added a test which is unrelated to the feature I have added, but it does test a different part of the same function. Anyway, I have raised a PR for this now (19742) and can separate it out if needed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40394>
_______________________________________

From report at bugs.python.org  Mon Apr 27 18:05:35 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 27 Apr 2020 22:05:35 +0000
Subject: [issue39995] test_concurrent_futures:
 ProcessPoolSpawnExecutorDeadlockTest.test_crash() fails with OSError: [Errno
 9] Bad file descriptor
In-Reply-To: <1584464514.72.0.0566985296328.issue39995@roundup.psfhosted.org>
Message-ID: <1588025135.52.0.40395328882.issue39995@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

It seems like test_killed_child() race condition was introduced by:

commit a5cbab552d294d99fde864306632d7e511a75d3c (refs/bisect/bad)
Author: Thomas Moreau <thomas.moreau.2010 at gmail.com>
Date:   Sun Feb 16 19:09:26 2020 +0100

    bpo-39104: Fix hanging ProcessPoolExecutor on shutdown nowait with pickling failure (GH-17670)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39995>
_______________________________________

From report at bugs.python.org  Mon Apr 27 18:08:26 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 27 Apr 2020 22:08:26 +0000
Subject: [issue39104] ProcessPoolExecutor hangs on shutdown nowait with
 pickling failure
In-Reply-To: <1576824742.02.0.740148547005.issue39104@roundup.psfhosted.org>
Message-ID: <1588025306.83.0.116675956091.issue39104@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> bpo-39104: Fix hanging ProcessPoolExecutor on shutdown nowait with pickling failure (GH-17670)
> https://github.com/python/cpython/commit/a5cbab552d294d99fde864306632d7e511a75d3c

ProcessPoolSpawnProcessPoolExecutorTest.test_killed_child() of test_concurrent_futures started to fail randomly since this change: see bpo-39995.

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39104>
_______________________________________

From report at bugs.python.org  Mon Apr 27 18:15:32 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 27 Apr 2020 22:15:32 +0000
Subject: [issue40334] PEP 617: new PEG-based parser
In-Reply-To: <1587327377.33.0.614039250584.issue40334@roundup.psfhosted.org>
Message-ID: <1588025732.5.0.00659098782067.issue40334@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

> The parser generator imports modules token and tokenize. It is not correct, because they are relevant to the Python version used to run the parser generator, and not to the Python version for which the parser is generated. It works currently only because there is no differences between 3.8 and 3.9, but it will fail when you add a new token or change/remove an old one.

Very good point, Serhiy! Thanks for catching that

So there are two parts of the parser generator where we use these modules:

- For the grammar parser and the python-based generator (that generates the grammar parser) we are good because we just need the modules to parse the grammars and generate the metaparser so there is no need for those modules to be updated. Running the grammar parser (the one generated with the meta-grammar) is also fine.

- For the C generator we need the current set of "exact_token_types" and in this case we need them to be synchronized with the Tokens file. I think we can do as pgen and take the path to that file as part of the command line interface and parse it.

I will make a PR for this soon.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40334>
_______________________________________

From report at bugs.python.org  Mon Apr 27 18:19:23 2020
From: report at bugs.python.org (Daniel Lenski)
Date: Mon, 27 Apr 2020 22:19:23 +0000
Subject: [issue2190] MozillaCookieJar ignore HttpOnly cookies
In-Reply-To: <1203957546.34.0.123660895963.issue2190@psf.upfronthosting.co.za>
Message-ID: <1588025963.39.0.575692765418.issue2190@roundup.psfhosted.org>


Daniel Lenski <dlenski at gmail.com> added the comment:

Also confused about why this was closed.

This format is still frequently used. In the absence of a solution in the standard library, I'm using this kludge to strip the leading `#HttpOnly_`.


    from tempfile import NamedTemporaryFile
    from http.cookiejar import MozillaCookieJar
    from contextlib import contextmanager

    def fix_cookie_jar_file(orig_cookiejarfile):
        with NamedTemporaryFile(mode='w+') as cjf:
            with open(orig_cookiejarfile, 'r') as ocf:
            for l in ocf:            
                cjf.write(l[10:] if l.startswith('#HttpOnly_') else l)
            cjf.seek(0)
        yield cjf.name

    MozillaCookieJar(filename=fix_cookie_jar_file(orig_cookiejarfile))

----------
nosy: +dlenski

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue2190>
_______________________________________

From report at bugs.python.org  Mon Apr 27 18:45:47 2020
From: report at bugs.python.org (Lysandros Nikolaou)
Date: Mon, 27 Apr 2020 22:45:47 +0000
Subject: [issue40334] PEP 617: new PEG-based parser
In-Reply-To: <1587327377.33.0.614039250584.issue40334@roundup.psfhosted.org>
Message-ID: <1588027547.88.0.900807676453.issue40334@roundup.psfhosted.org>


Change by Lysandros Nikolaou <lisandrosnik at gmail.com>:


----------
pull_requests: +19065
pull_request: https://github.com/python/cpython/pull/19743

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40334>
_______________________________________

From report at bugs.python.org  Mon Apr 27 18:58:04 2020
From: report at bugs.python.org (Lysandros Nikolaou)
Date: Mon, 27 Apr 2020 22:58:04 +0000
Subject: [issue40334] PEP 617: new PEG-based parser
In-Reply-To: <1587327377.33.0.614039250584.issue40334@roundup.psfhosted.org>
Message-ID: <1588028284.36.0.634694839969.issue40334@roundup.psfhosted.org>


Change by Lysandros Nikolaou <lisandrosnik at gmail.com>:


----------
pull_requests: +19066
pull_request: https://github.com/python/cpython/pull/19744

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40334>
_______________________________________

From report at bugs.python.org  Mon Apr 27 19:52:13 2020
From: report at bugs.python.org (paul rubin)
Date: Mon, 27 Apr 2020 23:52:13 +0000
Subject: [issue40334] PEP 617: new PEG-based parser
In-Reply-To: <1587327377.33.0.614039250584.issue40334@roundup.psfhosted.org>
Message-ID: <1588031533.82.0.984763752411.issue40334@roundup.psfhosted.org>


paul rubin <phr-pythonbugs at nightsong.com> added the comment:

I just saw this.  Interesting.  Sometimes I use ast.literal_eval to read big, deeply nested data objects.  I can probably convert to JSON if necessary but it's another thing to watch out for.  I might try to benchmark some of these.

----------
nosy: +phr

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40334>
_______________________________________

From report at bugs.python.org  Mon Apr 27 19:52:04 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 27 Apr 2020 23:52:04 +0000
Subject: [issue2190] MozillaCookieJar ignore HttpOnly cookies
In-Reply-To: <1203957546.34.0.123660895963.issue2190@psf.upfronthosting.co.za>
Message-ID: <1588031524.81.0.721076430835.issue2190@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

This issue was closed as useless for Firefox in 2010 by the original poster, msg109958.  My participation here is only as tracker triager, as I only have a consumer knowledge of cookies.  Unfortunately, there is no core developer expert for http, let alone the http.cookiejar.  The person who once handled some cookie related patches is no longer active.

Adding a patch to a closed issue is somewhat useless.  In any case, a possible revised PR would be needed.  My suggestion is to ask on python-ideas whether this enhancement might be accepted now and whether better to reopen this issue or open a new one.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue2190>
_______________________________________

From report at bugs.python.org  Mon Apr 27 19:55:52 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 27 Apr 2020 23:55:52 +0000
Subject: [issue40334] PEP 617: new PEG-based parser
In-Reply-To: <1587327377.33.0.614039250584.issue40334@roundup.psfhosted.org>
Message-ID: <1588031752.84.0.135345944547.issue40334@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

@phr: examples welcome! The bigger and nastier, the better. This *should* all be speedy but it wouldn't hurt to check.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40334>
_______________________________________

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: [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:15:11 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 28 Apr 2020 00:15:11 +0000
Subject: [issue40334] PEP 617: new PEG-based parser
In-Reply-To: <1587327377.33.0.614039250584.issue40334@roundup.psfhosted.org>
Message-ID: <1588032911.92.0.160818398422.issue40334@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
pull_requests: +19067
pull_request: https://github.com/python/cpython/pull/19745

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40334>
_______________________________________

From report at bugs.python.org  Mon Apr 27 20:23:39 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 28 Apr 2020 00:23:39 +0000
Subject: [issue40334] PEP 617: new PEG-based parser
In-Reply-To: <1587327377.33.0.614039250584.issue40334@roundup.psfhosted.org>
Message-ID: <1588033419.84.0.701771518236.issue40334@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset d55133f49fe678fbf047a647aa8bb8b520410e8d by Lysandros Nikolaou in branch 'master':
bpo-40334: Catch E_EOF error, when the tokenizer returns ERRORTOKEN (GH-19743)
https://github.com/python/cpython/commit/d55133f49fe678fbf047a647aa8bb8b520410e8d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40334>
_______________________________________

From report at bugs.python.org  Mon Apr 27 20:24:54 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 28 Apr 2020 00:24:54 +0000
Subject: [issue40334] PEP 617: new PEG-based parser
In-Reply-To: <1587327377.33.0.614039250584.issue40334@roundup.psfhosted.org>
Message-ID: <1588033494.35.0.450845027607.issue40334@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset 3d53d8756f0403eec6a4e12f183103d651bed6c5 by Lysandros Nikolaou in branch 'master':
bpo-40334: Don't skip test_parser:test_trigget_memory_error (GH-19744)
https://github.com/python/cpython/commit/3d53d8756f0403eec6a4e12f183103d651bed6c5


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40334>
_______________________________________

From report at bugs.python.org  Mon Apr 27 20:26:58 2020
From: report at bugs.python.org (paul rubin)
Date: Tue, 28 Apr 2020 00:26:58 +0000
Subject: [issue40334] PEP 617: new PEG-based parser
In-Reply-To: <1587327377.33.0.614039250584.issue40334@roundup.psfhosted.org>
Message-ID: <1588033618.63.0.901386402321.issue40334@roundup.psfhosted.org>


Change by paul rubin <phr-pythonbugs at nightsong.com>:


----------
nosy:  -phr

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40334>
_______________________________________

From report at bugs.python.org  Mon Apr 27 20:42:25 2020
From: report at bugs.python.org (Kyle Stanley)
Date: Tue, 28 Apr 2020 00:42:25 +0000
Subject: [issue40411] frozen collection.Counter
In-Reply-To: <1588031999.2.0.641079021792.issue40411@roundup.psfhosted.org>
Message-ID: <1588034545.12.0.418965770536.issue40411@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:

Rather than starting this out as a bpo issue, I would highly recommend bringing forth a proposal for this in python-ideas at python.org and explaining in as much detail as possible:

1) How a frozen variation of collection.Counter would benefit your specific use case
2) The current available workaround you mentioned, issues with it, and the comparative benefit your proposal would provide
3) Why it should be included in the standard library, compared to a 3rd party package on PyPI

The 3rd one can be a bit tricky, but it typically involves explaining how widespread the potential use case(s) would be and how tricky it would be for users to implement something like this on their own (from both a functionality and performance perspective).

>From a brief glance of the archives, it doesn't look like this specific idea was proposed, other than part of a more generalized one to add frozen equivalents for the entire collections module, which was rejected on the basis of the use cases being too theoretical and overly broad.

Also, while not specific to your particular proposal, I would recommend reading over the following post from Raymond Hettinger in the python-ideas archive (from the previously mentioned thread): https://mail.python.org/archives/list/python-ideas at python.org/message/QVBVJU4RNJ5MDKBJ5CNGINYG24WZDZX7/. It explains why the collections module tries to be minimalist, and specifically the requirement of new features providing a tangible, real-world benefit.

It's of course up to you how you decide to format the proposal, but by answering the above points and demonstrating clear value in specific use cases, it has a much better chance of eventually making into the standard library (or at the least, a constructive discussion about it).

----------
nosy: +aeros

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40411>
_______________________________________

From report at bugs.python.org  Mon Apr 27 20:45:21 2020
From: report at bugs.python.org (Kyle Stanley)
Date: Tue, 28 Apr 2020 00:45:21 +0000
Subject: [issue40411] frozen collection.Counter
In-Reply-To: <1588031999.2.0.641079021792.issue40411@roundup.psfhosted.org>
Message-ID: <1588034721.66.0.583870132592.issue40411@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:

Also, adding Raymond to the nosy list in case he has any specific comments about a frozen collections.Counter.

----------
nosy: +rhettinger
versions: +Python 3.9

_______________________________________
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: [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 20:52:59 2020
From: report at bugs.python.org (Kyle Stanley)
Date: Tue, 28 Apr 2020 00:52:59 +0000
Subject: [issue39995] test_concurrent_futures:
 ProcessPoolSpawnExecutorDeadlockTest.test_crash() fails with OSError: [Errno
 9] Bad file descriptor
In-Reply-To: <1584464514.72.0.0566985296328.issue39995@roundup.psfhosted.org>
Message-ID: <1588035179.01.0.221527112047.issue39995@roundup.psfhosted.org>


Change by Kyle Stanley <aeros167 at gmail.com>:


----------
nosy: +aeros

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39995>
_______________________________________

From report at bugs.python.org  Mon Apr 27 20:53:13 2020
From: report at bugs.python.org (Gregory Szorc)
Date: Tue, 28 Apr 2020 00:53:13 +0000
Subject: [issue40412] inittab_copy not set to NULL after free,
 can lead to crashes when running multiple interpreters in a single
 process
In-Reply-To: <1588035109.97.0.994346077967.issue40412@roundup.psfhosted.org>
Message-ID: <1588035193.59.0.310804806149.issue40412@roundup.psfhosted.org>


Change by Gregory Szorc <gregory.szorc at gmail.com>:


----------
keywords: +patch
pull_requests: +19068
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19746

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40412>
_______________________________________

From report at bugs.python.org  Mon Apr 27 20:55:08 2020
From: report at bugs.python.org (paul rubin)
Date: Tue, 28 Apr 2020 00:55:08 +0000
Subject: [issue1726707] add itertools.ichain function and count.getvalue
Message-ID: <1588035308.49.0.0211532698307.issue1726707@roundup.psfhosted.org>


paul rubin <phr-pythonbugs at nightsong.com> added the comment:

Note, nowadays this is implement as itertools.chain.from_iterable .

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1726707>
_______________________________________

From report at bugs.python.org  Mon Apr 27 21:08:28 2020
From: report at bugs.python.org (Kyle Stanley)
Date: Tue, 28 Apr 2020 01:08:28 +0000
Subject: [issue39995] test_concurrent_futures:
 ProcessPoolSpawnExecutorDeadlockTest.test_crash() fails with OSError: [Errno
 9] Bad file descriptor
In-Reply-To: <1584464514.72.0.0566985296328.issue39995@roundup.psfhosted.org>
Message-ID: <1588036108.78.0.665169202063.issue39995@roundup.psfhosted.org>


Change by Kyle Stanley <aeros167 at gmail.com>:


----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39995>
_______________________________________

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: [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:01:32 2020
From: report at bugs.python.org (Gregory Szorc)
Date: Tue, 28 Apr 2020 02:01:32 +0000
Subject: [issue40413] Py_RunMain() crashes on subsequence call
In-Reply-To: <1588038871.72.0.754759187006.issue40413@roundup.psfhosted.org>
Message-ID: <1588039292.6.0.534315134651.issue40413@roundup.psfhosted.org>


Gregory Szorc <gregory.szorc at gmail.com> added the comment:

Actually, I can reproduce the crash without Py_RunMain(). So I don't think the crash is related to the additional cleanup that Py_RunMain() does in addition to Py_FinalizeEx().

But I'd like to keep this issue open to track the original question about expected behavior.

----------

_______________________________________
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: [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:17:38 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 28 Apr 2020 02:17:38 +0000
Subject: [issue40411] frozen collection.Counter
In-Reply-To: <1588031999.2.0.641079021792.issue40411@roundup.psfhosted.org>
Message-ID: <1588040258.44.0.549099885292.issue40411@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Do you want to freeze a counter to prevent future count changes or bto make it to be hashable?  Essentially the only reason we have frozenset is to use sets as dict keys to model graphs, but that wouldn't make much sense for counters.

What multiset methods do you need? We already have addition, subtraction, union, and intersection.  A symmetric_difference doesn't seem to make sense or have a use case.   AFAICT, all that is missing are subset/superset tests which were omitted because their semantics conflict with the existing dict equality semantics and because the use cases are rare.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40411>
_______________________________________

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: [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  Mon Apr 27 22:27:39 2020
From: report at bugs.python.org (Gregory Szorc)
Date: Tue, 28 Apr 2020 02:27:39 +0000
Subject: [issue40415] _asyncio extensions crashes if initialized multiple
 times in same process
In-Reply-To: <1588040845.09.0.680555822876.issue40415@roundup.psfhosted.org>
Message-ID: <1588040859.26.0.754148822288.issue40415@roundup.psfhosted.org>


Change by Gregory Szorc <gregory.szorc at gmail.com>:


----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40415>
_______________________________________

From report at bugs.python.org  Mon Apr 27 22:30:45 2020
From: report at bugs.python.org (Gregory Szorc)
Date: Tue, 28 Apr 2020 02:30:45 +0000
Subject: [issue40415] _asyncio extensions crashes if initialized multiple
 times in same process
In-Reply-To: <1588040845.09.0.680555822876.issue40415@roundup.psfhosted.org>
Message-ID: <1588041045.95.0.431699507578.issue40415@roundup.psfhosted.org>


Gregory Szorc <gregory.szorc at gmail.com> added the comment:

Oh, I just went to patch this and it is a dupe of 40294, which has already been fixed and backported.

----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40415>
_______________________________________

From report at bugs.python.org  Mon Apr 27 22:44:56 2020
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 28 Apr 2020 02:44:56 +0000
Subject: [issue40405] asyncio.as_completed documentation misleading
In-Reply-To: <1587986090.72.0.850288416668.issue40405@roundup.psfhosted.org>
Message-ID: <1588041896.89.0.602790821743.issue40405@roundup.psfhosted.org>


Yury Selivanov <yselivanov at gmail.com> added the comment:

> @Yury what do you think?

Yeah, the documentation needs to be fixed.

> Maybe "Returns an iterator of awaitables"?

I'd suggest to change to: "Return an iterator of coroutines.  Each coroutine allows to wait for the earliest next result from the set of the remaining awaitables."

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40405>
_______________________________________

From report at bugs.python.org  Mon Apr 27 23:09:33 2020
From: report at bugs.python.org (Kyle Stanley)
Date: Tue, 28 Apr 2020 03:09:33 +0000
Subject: [issue39995] test_concurrent_futures:
 ProcessPoolSpawnExecutorDeadlockTest.test_crash() fails with OSError: [Errno
 9] Bad file descriptor
In-Reply-To: <1584464514.72.0.0566985296328.issue39995@roundup.psfhosted.org>
Message-ID: <1588043373.82.0.392823623422.issue39995@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:

I can't be certain for the other failures, but I'm currently exploring a potential solution for addressing the `test_killed_child` failure. To me, it seems to be a race condition with attempting to call _ThreadWakeup.close() while there are still bytes being sent. IMO, we should wait until closing the pipe's reader and writer until it's finished sending or receiving bytes. Here's one way to implement that w/ threading.Event:

diff --git a/Lib/concurrent/futures/process.py b/Lib/concurrent/futures/process.py
index 8e9b69a8f0..9bf073fc34 100644
--- a/Lib/concurrent/futures/process.py
+++ b/Lib/concurrent/futures/process.py
@@ -68,21 +68,30 @@ class _ThreadWakeup:
     def __init__(self):
         self._closed = False
         self._reader, self._writer = mp.Pipe(duplex=False)
+        # Used to ensure pipe is not closed while sending or receiving bytes
+        self._not_running = threading.Event()
+        # Initialize event as True
+        self._not_running.set()
 
     def close(self):
         if not self._closed:
+            self._not_running.wait()
             self._closed = True
             self._writer.close()
             self._reader.close()
 
     def wakeup(self):
         if not self._closed:
+            self._not_running.clear()
             self._writer.send_bytes(b"")
+            self._not_running.set()
 
     def clear(self):
         if not self._closed:
+            self._not_running.clear()
             while self._reader.poll():
                 self._reader.recv_bytes()
+            self._not_running.set()


>From using Victor's method of replicating the failure with inserting a `time.sleep(0.050)` in multiprocessing.Connection._send(), it appears to fix the failure in test_killed_child. I believe it would also fix the other failures since they appear to be caused by the same core issue, but I've been unable to replicate them locally so I'm not 100% certain.

----------
assignee:  -> aeros

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39995>
_______________________________________

From report at bugs.python.org  Mon Apr 27 23:16:43 2020
From: report at bugs.python.org (Kyle Stanley)
Date: Tue, 28 Apr 2020 03:16:43 +0000
Subject: [issue39995] test_concurrent_futures:
 ProcessPoolSpawnExecutorDeadlockTest.test_crash() fails with OSError: [Errno
 9] Bad file descriptor
In-Reply-To: <1584464514.72.0.0566985296328.issue39995@roundup.psfhosted.org>
Message-ID: <1588043803.05.0.0715530377854.issue39995@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:

After writing the above out and a bit of further consideration, I think it might make more sense to wait for the event after setting `self._closed = True` so that it prevents future wakeup() and clear() calls from reading/writing to the pipe, while still allowing ones that are currently ongoing to finish.

Thoughts?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39995>
_______________________________________

From report at bugs.python.org  Mon Apr 27 23:35:19 2020
From: report at bugs.python.org (paul rubin)
Date: Tue, 28 Apr 2020 03:35:19 +0000
Subject: [issue40411] frozen collection.Counter
In-Reply-To: <1588031999.2.0.641079021792.issue40411@roundup.psfhosted.org>
Message-ID: <1588044919.37.0.564324477071.issue40411@roundup.psfhosted.org>


paul rubin <phr-pythonbugs at nightsong.com> added the comment:

Yes, the idea was for them to be hashable, to be used as dict keys.  E.g. if you use frozensets to model graphs, you'd use frozen multisets for hypergraphs.  My immediate use case involved word puzzles, e.g. treating words as bags of scrabble tiles with letters on them, and finding out what other words you could form from the letters.  It is not a pressing need.  

I'm trying to remember what the other missing operation I ran into was, a few days ago.  It may have been subset.  I found a workaround but it seemed a bit ugly.  It would be nice if Counters could also be thought of as multisets which can do the same things sets can do with unneeded head scratching.  It seems like counters and multisets/bags really are different things conceptually.  Their operations and implementations overlap, but they are different.  E.g. it can make sense for a counter to have a negative count of something, but not for a bag.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40411>
_______________________________________

From report at bugs.python.org  Mon Apr 27 23:50:39 2020
From: report at bugs.python.org (paul rubin)
Date: Tue, 28 Apr 2020 03:50:39 +0000
Subject: [issue40411] frozen collection.Counter
In-Reply-To: <1588031999.2.0.641079021792.issue40411@roundup.psfhosted.org>
Message-ID: <1588045839.01.0.673122660276.issue40411@roundup.psfhosted.org>


paul rubin <phr-pythonbugs at nightsong.com> added the comment:

Kyle, thanks, I saw your comment after posting my own, and I looked at Raymond's mailing list post that you linked.  I do think that "completing the grid" is a good thing in the cases where it's obvious how to do it (if there's one and one obvious way, then doing it that way should work), and having missing combinations in the grid is also a form of interface complexity (expect subset to work, find that it doesn't, and implement some hack).  Also it seems to me that sets, dicts, bags are basic data objects in many languages these days, without a lot of design space to move around in.  So we don't have to worry much about constraining future choices.  We could just look at Smalltalk or Ruby or whatever and just do what they did.  

However, that is philosophical.  I did learn from Raymond's message that Counter doesn't really attempt to be a multiset implementation.  In that case, it works for what it is made for, so it really then is a separate question of whether implementing multisets properly is worthwhile.  (That's as opposed to saying we already have a multiset implementation but some functionality is missing from it).

I dislike the concept of shovelling off basic functionality to 3rd party libraries.  The rejection of that philosophy (Python's old motto "Batteries included") is one of the things that attracted me to Python in the first place.  Though that value is mostly historical now, I'm sad about the loss.  It's impossible to write a large Ruby or Javascript (npm) application with 100s of third party modules, every one of which is an attack vector ("supply chain attack" is the current buzzword), and  whose implementations vary widely in quality and usability.  I looked at the docs for Ruby's multiset gem (https://maraigue.hhiro.net/multiset/) and they are partly in Japanese.  Python has until the past few years managed to keep away from that kind of thing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40411>
_______________________________________

From report at bugs.python.org  Mon Apr 27 23:52:45 2020
From: report at bugs.python.org (Domenico Ragusa)
Date: Tue, 28 Apr 2020 03:52:45 +0000
Subject: [issue40358] pathlib's relative_to should behave like os.path.relpath
In-Reply-To: <1587585021.43.0.391857493828.issue40358@roundup.psfhosted.org>
Message-ID: <CAHsu_9UApsnRzvgCoKiq2RTv_hMwF0O-T9bpZY20yGTNn_X=9w@mail.gmail.com>


Domenico Ragusa <domenicoragusa at gmail.com> added the comment:

Yeah, you're right, there's no access to the filesystem and the result
is generated assuming the paths are already resolved.
`strict` seems to be an appropriate name for the option, thanks.

I've looked into the test suite, it helped a lot especially with
Windows paths, they were more complicated than I though.
I've duplicated the tests to verify that it still function as before
and I've added some tests for values that would raise an exception. It
works.
I'm not overly fond of the way I check for unrelated paths, but I
couldn't think of something more elegant.

Any input is appreciated.

----------
Added file: https://bugs.python.org/file49095/relative_to.patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40358>
_______________________________________
-------------- next part --------------
diff --git a/Lib/pathlib.py b/Lib/pathlib.py
index f98d69e..eb25761 100644
--- a/Lib/pathlib.py
+++ b/Lib/pathlib.py
@@ -895,10 +895,10 @@ class PurePath(object):
         return self._from_parsed_parts(self._drv, self._root,
                                        self._parts[:-1] + [name])
 
-    def relative_to(self, *other):
+    def relative_to(self, *other, strict=True):
         """Return the relative path to another path identified by the passed
         arguments.  If the operation is not possible (because this is not
-        a subpath of the other path), raise ValueError.
+        related to the other path), raise ValueError.
         """
         # For the purpose of this method, drive and root are considered
         # separate parts, i.e.:
@@ -918,14 +918,31 @@ class PurePath(object):
             to_abs_parts = [to_drv, to_root] + to_parts[1:]
         else:
             to_abs_parts = to_parts
+        
         n = len(to_abs_parts)
         cf = self._flavour.casefold_parts
-        if (root or drv) if n == 0 else cf(abs_parts[:n]) != cf(to_abs_parts):
+        common = 0
+        for p, tp in zip(cf(abs_parts), cf(to_abs_parts)):
+            if p != tp:
+                break
+            common += 1
+        
+        if strict:
+            failure = (root or drv) if n == 0 else common != n
+            error_message = "{!r} does not start with {!r}"
+            up_parts = []
+        else:
+            failure = root != to_root
+            if drv or to_drv:
+                failure = cf([drv]) != cf([to_drv]) or (failure and n > 1)
+            error_message = "{!r} is not related to {!r}"
+            up_parts = (n-common)*['..']
+        
+        if failure:
             formatted = self._format_parsed_parts(to_drv, to_root, to_parts)
-            raise ValueError("{!r} does not start with {!r}"
-                             .format(str(self), str(formatted)))
-        return self._from_parsed_parts('', root if n == 1 else '',
-                                       abs_parts[n:])
+            raise ValueError(error_message.format(str(self), str(formatted)))
+        return self._from_parsed_parts('', root if common == 1 else '',
+                                       up_parts+abs_parts[common:])
 
     def is_relative_to(self, *other):
         """Return True if the path is relative to another path or False.
diff --git a/Lib/test/test_pathlib.py b/Lib/test/test_pathlib.py
index 1589282..a6d8fe4 100644
--- a/Lib/test/test_pathlib.py
+++ b/Lib/test/test_pathlib.py
@@ -613,13 +613,30 @@ class _BasePurePathTest(object):
         self.assertEqual(p.relative_to('a/'), P('b'))
         self.assertEqual(p.relative_to(P('a/b')), P())
         self.assertEqual(p.relative_to('a/b'), P())
+        self.assertEqual(p.relative_to(P(), strict=False), P('a/b'))
+        self.assertEqual(p.relative_to('', strict=False), P('a/b'))
+        self.assertEqual(p.relative_to(P('a'), strict=False), P('b'))
+        self.assertEqual(p.relative_to('a', strict=False), P('b'))
+        self.assertEqual(p.relative_to('a/', strict=False), P('b'))
+        self.assertEqual(p.relative_to(P('a/b'), strict=False), P())
+        self.assertEqual(p.relative_to('a/b', strict=False), P())
+        self.assertEqual(p.relative_to(P('a/c'), strict=False), P('../b'))
+        self.assertEqual(p.relative_to('a/c', strict=False), P('../b'))
+        self.assertEqual(p.relative_to(P('a/b/c'), strict=False), P('..'))
+        self.assertEqual(p.relative_to('a/b/c', strict=False), P('..'))
+        self.assertEqual(p.relative_to(P('c'), strict=False), P('../a/b'))
+        self.assertEqual(p.relative_to('c', strict=False), P('../a/b'))
         # With several args.
         self.assertEqual(p.relative_to('a', 'b'), P())
+        self.assertEqual(p.relative_to('a', 'b', strict=False), P())
         # Unrelated paths.
         self.assertRaises(ValueError, p.relative_to, P('c'))
         self.assertRaises(ValueError, p.relative_to, P('a/b/c'))
         self.assertRaises(ValueError, p.relative_to, P('a/c'))
         self.assertRaises(ValueError, p.relative_to, P('/a'))
+        self.assertRaises(ValueError, p.relative_to, P('/'), strict=False)
+        self.assertRaises(ValueError, p.relative_to, P('/a'), strict=False)
+        
         p = P('/a/b')
         self.assertEqual(p.relative_to(P('/')), P('a/b'))
         self.assertEqual(p.relative_to('/'), P('a/b'))
@@ -628,6 +645,19 @@ class _BasePurePathTest(object):
         self.assertEqual(p.relative_to('/a/'), P('b'))
         self.assertEqual(p.relative_to(P('/a/b')), P())
         self.assertEqual(p.relative_to('/a/b'), P())
+        self.assertEqual(p.relative_to(P('/'), strict=False), P('a/b'))
+        self.assertEqual(p.relative_to('/', strict=False), P('a/b'))
+        self.assertEqual(p.relative_to(P('/a'), strict=False), P('b'))
+        self.assertEqual(p.relative_to('/a', strict=False), P('b'))
+        self.assertEqual(p.relative_to('/a/', strict=False), P('b'))
+        self.assertEqual(p.relative_to(P('/a/b'), strict=False), P())
+        self.assertEqual(p.relative_to('/a/b', strict=False), P())
+        self.assertEqual(p.relative_to(P('/a/c'), strict=False), P('../b'))
+        self.assertEqual(p.relative_to('/a/c', strict=False), P('../b'))
+        self.assertEqual(p.relative_to(P('/a/b/c'), strict=False), P('..'))
+        self.assertEqual(p.relative_to('/a/b/c', strict=False), P('..'))
+        self.assertEqual(p.relative_to(P('/c'), strict=False), P('../a/b'))
+        self.assertEqual(p.relative_to('/c', strict=False), P('../a/b'))
         # Unrelated paths.
         self.assertRaises(ValueError, p.relative_to, P('/c'))
         self.assertRaises(ValueError, p.relative_to, P('/a/b/c'))
@@ -635,6 +665,8 @@ class _BasePurePathTest(object):
         self.assertRaises(ValueError, p.relative_to, P())
         self.assertRaises(ValueError, p.relative_to, '')
         self.assertRaises(ValueError, p.relative_to, P('a'))
+        self.assertRaises(ValueError, p.relative_to, P(''), strict=False)
+        self.assertRaises(ValueError, p.relative_to, P('a'), strict=False)
 
     def test_is_relative_to_common(self):
         P = self.cls
@@ -1079,6 +1111,17 @@ class PureWindowsPathTest(_BasePurePathTest, unittest.TestCase):
         self.assertEqual(p.relative_to('c:foO/'), P('Bar'))
         self.assertEqual(p.relative_to(P('c:foO/baR')), P())
         self.assertEqual(p.relative_to('c:foO/baR'), P())
+        self.assertEqual(p.relative_to(P('c:'), strict=False), P('Foo/Bar'))
+        self.assertEqual(p.relative_to('c:', strict=False), P('Foo/Bar'))
+        self.assertEqual(p.relative_to(P('c:foO'), strict=False), P('Bar'))
+        self.assertEqual(p.relative_to('c:foO', strict=False), P('Bar'))
+        self.assertEqual(p.relative_to('c:foO/', strict=False), P('Bar'))
+        self.assertEqual(p.relative_to(P('c:foO/baR'), strict=False), P())
+        self.assertEqual(p.relative_to('c:foO/baR', strict=False), P())
+        self.assertEqual(p.relative_to(P('C:Foo/Bar/Baz'), strict=False), P('..'))
+        self.assertEqual(p.relative_to(P('C:Foo/Baz'), strict=False), P('../Bar'))
+        self.assertEqual(p.relative_to(P('C:Baz/Bar'), strict=False), P('../../Foo/Bar'))
+        
         # Unrelated paths.
         self.assertRaises(ValueError, p.relative_to, P())
         self.assertRaises(ValueError, p.relative_to, '')
@@ -1089,6 +1132,13 @@ class PureWindowsPathTest(_BasePurePathTest, unittest.TestCase):
         self.assertRaises(ValueError, p.relative_to, P('C:/Foo'))
         self.assertRaises(ValueError, p.relative_to, P('C:Foo/Bar/Baz'))
         self.assertRaises(ValueError, p.relative_to, P('C:Foo/Baz'))
+        self.assertRaises(ValueError, p.relative_to, P(), strict=False)
+        self.assertRaises(ValueError, p.relative_to, '', strict=False)
+        self.assertRaises(ValueError, p.relative_to, P('d:'), strict=False)
+        self.assertRaises(ValueError, p.relative_to, P('/'), strict=False)
+        self.assertRaises(ValueError, p.relative_to, P('Foo'), strict=False)
+        self.assertRaises(ValueError, p.relative_to, P('/Foo'), strict=False)
+        self.assertRaises(ValueError, p.relative_to, P('C:/Foo'), strict=False)
         p = P('C:/Foo/Bar')
         self.assertEqual(p.relative_to(P('c:')), P('/Foo/Bar'))
         self.assertEqual(p.relative_to('c:'), P('/Foo/Bar'))
@@ -1101,6 +1151,20 @@ class PureWindowsPathTest(_BasePurePathTest, unittest.TestCase):
         self.assertEqual(p.relative_to('c:/foO/'), P('Bar'))
         self.assertEqual(p.relative_to(P('c:/foO/baR')), P())
         self.assertEqual(p.relative_to('c:/foO/baR'), P())
+        self.assertEqual(p.relative_to(P('c:'), strict=False), P('/Foo/Bar'))
+        self.assertEqual(p.relative_to('c:', strict=False), P('/Foo/Bar'))
+        self.assertEqual(str(p.relative_to(P('c:'), strict=False)), '\\Foo\\Bar')
+        self.assertEqual(str(p.relative_to('c:', strict=False)), '\\Foo\\Bar')
+        self.assertEqual(p.relative_to(P('c:/'), strict=False), P('Foo/Bar'))
+        self.assertEqual(p.relative_to('c:/', strict=False), P('Foo/Bar'))
+        self.assertEqual(p.relative_to(P('c:/foO'), strict=False), P('Bar'))
+        self.assertEqual(p.relative_to('c:/foO', strict=False), P('Bar'))
+        self.assertEqual(p.relative_to('c:/foO/', strict=False), P('Bar'))
+        self.assertEqual(p.relative_to(P('c:/foO/baR'), strict=False), P())
+        self.assertEqual(p.relative_to('c:/foO/baR', strict=False), P())
+        self.assertEqual(p.relative_to('C:/Baz', strict=False), P('../Foo/Bar'))
+        self.assertEqual(p.relative_to('C:/Foo/Bar/Baz', strict=False), P('..'))
+        self.assertEqual(p.relative_to('C:/Foo/Baz', strict=False), P('../Bar'))
         # Unrelated paths.
         self.assertRaises(ValueError, p.relative_to, P('C:/Baz'))
         self.assertRaises(ValueError, p.relative_to, P('C:/Foo/Bar/Baz'))
@@ -1111,6 +1175,13 @@ class PureWindowsPathTest(_BasePurePathTest, unittest.TestCase):
         self.assertRaises(ValueError, p.relative_to, P('/'))
         self.assertRaises(ValueError, p.relative_to, P('/Foo'))
         self.assertRaises(ValueError, p.relative_to, P('//C/Foo'))
+        self.assertRaises(ValueError, p.relative_to, P('C:Foo'), strict=False)
+        self.assertRaises(ValueError, p.relative_to, P('d:'), strict=False)
+        self.assertRaises(ValueError, p.relative_to, P('d:/'), strict=False)
+        self.assertRaises(ValueError, p.relative_to, P('/'), strict=False)
+        self.assertRaises(ValueError, p.relative_to, P('/Foo'), strict=False)
+        self.assertRaises(ValueError, p.relative_to, P('//C/Foo'), strict=False)
+        
         # UNC paths.
         p = P('//Server/Share/Foo/Bar')
         self.assertEqual(p.relative_to(P('//sErver/sHare')), P('Foo/Bar'))
@@ -1121,11 +1192,25 @@ class PureWindowsPathTest(_BasePurePathTest, unittest.TestCase):
         self.assertEqual(p.relative_to('//sErver/sHare/Foo/'), P('Bar'))
         self.assertEqual(p.relative_to(P('//sErver/sHare/Foo/Bar')), P())
         self.assertEqual(p.relative_to('//sErver/sHare/Foo/Bar'), P())
+        self.assertEqual(p.relative_to(P('//sErver/sHare'), strict=False), P('Foo/Bar'))
+        self.assertEqual(p.relative_to('//sErver/sHare', strict=False), P('Foo/Bar'))
+        self.assertEqual(p.relative_to('//sErver/sHare/', strict=False), P('Foo/Bar'))
+        self.assertEqual(p.relative_to(P('//sErver/sHare/Foo'), strict=False), P('Bar'))
+        self.assertEqual(p.relative_to('//sErver/sHare/Foo', strict=False), P('Bar'))
+        self.assertEqual(p.relative_to('//sErver/sHare/Foo/', strict=False), P('Bar'))
+        self.assertEqual(p.relative_to(P('//sErver/sHare/Foo/Bar'), strict=False), P())
+        self.assertEqual(p.relative_to('//sErver/sHare/Foo/Bar', strict=False), P())
+        self.assertEqual(p.relative_to(P('//sErver/sHare/bar'), strict=False), P('../Foo/Bar'))
+        self.assertEqual(p.relative_to('//sErver/sHare/bar', strict=False), P('../Foo/Bar'))
         # Unrelated paths.
         self.assertRaises(ValueError, p.relative_to, P('/Server/Share/Foo'))
         self.assertRaises(ValueError, p.relative_to, P('c:/Server/Share/Foo'))
         self.assertRaises(ValueError, p.relative_to, P('//z/Share/Foo'))
         self.assertRaises(ValueError, p.relative_to, P('//Server/z/Foo'))
+        self.assertRaises(ValueError, p.relative_to, P('/Server/Share/Foo'), strict=False)
+        self.assertRaises(ValueError, p.relative_to, P('c:/Server/Share/Foo'), strict=False)
+        self.assertRaises(ValueError, p.relative_to, P('//z/Share/Foo'), strict=False)
+        self.assertRaises(ValueError, p.relative_to, P('//Server/z/Foo'), strict=False)
 
     def test_is_relative_to(self):
         P = self.cls

From report at bugs.python.org  Mon Apr 27 23:53:15 2020
From: report at bugs.python.org (Domenico Ragusa)
Date: Tue, 28 Apr 2020 03:53:15 +0000
Subject: [issue40358] pathlib's relative_to should behave like os.path.relpath
In-Reply-To: <1587513783.17.0.6950267733.issue40358@roundup.psfhosted.org>
Message-ID: <1588045995.18.0.624884537213.issue40358@roundup.psfhosted.org>


Change by Domenico Ragusa <domenicoragusa at gmail.com>:


Removed 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  Mon Apr 27 23:54:03 2020
From: report at bugs.python.org (paul rubin)
Date: Tue, 28 Apr 2020 03:54:03 +0000
Subject: [issue40411] frozen collection.Counter
In-Reply-To: <1588031999.2.0.641079021792.issue40411@roundup.psfhosted.org>
Message-ID: <1588046043.93.0.883290854745.issue40411@roundup.psfhosted.org>


paul rubin <phr-pythonbugs at nightsong.com> added the comment:

Oops I meant "*without* 100s of third party modules" in the case of ruby gems or npm.  There are just a few pip modules that I really use all the time, most notably bs4.  I continue to use urllib/urllib2 instead of requests because I'm used to them and because they eliminate an unnecessary dependency.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40411>
_______________________________________

From report at bugs.python.org  Tue Apr 28 00:12:29 2020
From: report at bugs.python.org (=?utf-8?b?VmVkcmFuIMSMYcSNacSH?=)
Date: Tue, 28 Apr 2020 04:12:29 +0000
Subject: [issue40411] frozen collection.Counter
In-Reply-To: <1588031999.2.0.641079021792.issue40411@roundup.psfhosted.org>
Message-ID: <1588047149.85.0.574717268532.issue40411@roundup.psfhosted.org>


Vedran ?a?i? <vedgar at gmail.com> added the comment:

Just another usecase: one of my students is writing an implementation of ordinal arithmetic in Python as a graduate thesis. FrozenCounters whose keys are FrozenCounters and whose values are natural numbers are _exactly_ isomorphic (via Cantor's normal form) to countable ordinals below epsilon_0 (and if a Counter can have itself as a key, we can go above epsilon_0 too).

Examples: zero = f{}
          one = f{zero: 1}
          seven = f{zero: 7}
          omega = f{one: 1}
          w^7*3+5 = f{seven: 3, zero: 5}
          w^w^w = f{f{omega: 1}: 1}
          epsilon0 = f{epsilon0: 1}
          and so on

I realize this is not something everybody does, but just to show that the need exists. We started with https://github.com/tamuhey/python-frozen-counter, afterwards we rolled our own implementation. But if it were in the stdlib, it would have saved us a lot of work.

----------
nosy: +veky

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40411>
_______________________________________

From report at bugs.python.org  Tue Apr 28 00:26:56 2020
From: report at bugs.python.org (Matthew Davis)
Date: Tue, 28 Apr 2020 04:26:56 +0000
Subject: [issue40359] email.parse part.get_filename() fails to unwrap long
 attachment file names (legacy API)
In-Reply-To: <1587515187.44.0.744042033479.issue40359@roundup.psfhosted.org>
Message-ID: <1588048016.55.0.889748686795.issue40359@roundup.psfhosted.org>


Matthew Davis <ubuntu.one at mdavis.xyz> added the comment:

Ah, yes that workaround works. Thanks!

So what's the exact status of this policy? It's called the default policy, but it's not used by default?

If I download the latest version of python, will this be parsed correctly without explicitly setting the policy?

i.e. Is this still something that should be changed in the code?

(Yes, I already use message_from_bytes in my real application. I just used message_from_string in the MWE, because I could only attach one file in this web page, so I embedded the email body as a string in the script.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40359>
_______________________________________

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: [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 01:00:52 2020
From: report at bugs.python.org (Kyle Stanley)
Date: Tue, 28 Apr 2020 05:00:52 +0000
Subject: [issue40411] frozen collection.Counter
In-Reply-To: <1588031999.2.0.641079021792.issue40411@roundup.psfhosted.org>
Message-ID: <1588050052.9.0.265118566947.issue40411@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:

paul rubin wrote:
> In that case, it works for what it is made for, so it really then is a separate question of whether implementing multisets properly is worthwhile.

Indeed, that seems to be the primary question to address. Personally, I don't have any strong opposition to including a multiset implementation in collections, I'm just not yet convinced they have enough widespread practical utility (that can't already be provided with Counter or a slightly modified version of it) to justify including them in collections.
 
> I dislike the concept of shovelling off basic functionality to 3rd party libraries.  The rejection of that philosophy (Python's old motto "Batteries included") is one of the things that attracted me to Python in the first place.  Though that value is mostly historical now, I'm sad about the loss.  It's impossible to write a large Ruby or Javascript (npm) application with 100s of third party modules, every one of which is an attack vector ("supply chain attack" is the current buzzword), and  whose implementations vary widely in quality and usability.

I can certainly sympathize with that sentiment of wanting to avoid excessive dependencies, and I think in general that we do still try to include more in the Python standard library compared to many other ecosystems. AFAIK, there's zero desire for the Python ecosystem to slowly turn into the "dependency hell" that NPM has become, with almost every library relying on a chain of minor 3rd party utilities.

However, rather than including everything that *might* be useful, the goal has been to include features that have substantial practical utility for a decent volume of users (and library maintainers), as long as they fit with the existing theme of a module (or are widely needed enough to justify a separate module) for a couple of primary reasons:

1) Making the stdlib modules as digestible as reasonably possible
2) Maximizing the ratio of practical benefit to implementation and long-term maintenance cost, which is especially important since development is voluntarily driven

Also, I would consider "batteries included" to still be a general goal, but it's practically impossible for the stdlib to fully cover what everyone would consider to be "basic functionality" while still maintaining its present quality. It's even more complicated by the fact that "basic functionality" will differ significantly depending upon who you ask, based upon what they personally use Python for and their unique experiences.

So, we tend to lean towards minimalism, focusing on implementing and improving features that have the most or strongest concrete use cases for a large volume of users. There are of course exceptions to this, such as features that are highly useful for a relatively small volume of users, but are difficult to implement a proper or optimized version. That has to be determined on a case-by-case basis though.

----------
nosy:  -veky

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40411>
_______________________________________

From report at bugs.python.org  Tue Apr 28 01:12:33 2020
From: report at bugs.python.org (hai shi)
Date: Tue, 28 Apr 2020 05:12:33 +0000
Subject: [issue40092] Crash in _PyThreadState_DeleteExcept() at fork in the
 process child
In-Reply-To: <1585329415.65.0.534969367772.issue40092@roundup.psfhosted.org>
Message-ID: <1588050753.75.0.184951023474.issue40092@roundup.psfhosted.org>


hai shi <shihai1991 at 126.com> added the comment:

> "since we are going to delete the threading.Thread object with its _tstate_lock object anyway" sentence is a description of the current _PyThreadState_DeleteExcept() implementation.

Oh, got it. thanks for your explanation :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40092>
_______________________________________

From report at bugs.python.org  Tue Apr 28 01:16:38 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 28 Apr 2020 05:16:38 +0000
Subject: [issue40411] frozen collection.Counter
In-Reply-To: <1588031999.2.0.641079021792.issue40411@roundup.psfhosted.org>
Message-ID: <1588050998.35.0.932147194287.issue40411@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

If you're interested in pursuing this, please follow Kyle's suggestion and move this to Python ideas.  The two frozencounter use cases presented are pretty exotic, something encountered rarely in a lifetime.  That is well below the threshold for growing the standard library.  We cater to the commonplace. It is for PyPI to cater to everything else :-)

----------
resolution:  -> postponed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40411>
_______________________________________

From report at bugs.python.org  Tue Apr 28 01:29:52 2020
From: report at bugs.python.org (paul rubin)
Date: Tue, 28 Apr 2020 05:29:52 +0000
Subject: [issue40411] frozen collection.Counter
In-Reply-To: <1588031999.2.0.641079021792.issue40411@roundup.psfhosted.org>
Message-ID: <1588051792.01.0.0553426451546.issue40411@roundup.psfhosted.org>


paul rubin <phr-pythonbugs at nightsong.com> added the comment:

Yeah I think the basic answer to this ticket is "Python doesn't really have multisets and a proposal to add them should go somewhere else".  Fair enough-- consider the request withdrawn from here.

Regarding minimalism vs completeness, regarding some feature X (say X is multisets), it's reasonable per minimalism to decide not to have X.  But if on weighing the use cases you decide to have X after all, I think it's best to implement X properly and completely with all the edge cases handled, rather than implement a half-baked subset.  That was something Java was historically very good at and Python wasn't.  I guess that is one for the theorists though.  Thanks everyone.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40411>
_______________________________________

From report at bugs.python.org  Tue Apr 28 01:37:02 2020
From: report at bugs.python.org (Zackery Spytz)
Date: Tue, 28 Apr 2020 05:37:02 +0000
Subject: [issue40061] Possible refleak in _asynciomodule.c
 future_add_done_callback()
In-Reply-To: <1585129013.48.0.185605805596.issue40061@roundup.psfhosted.org>
Message-ID: <1588052222.16.0.727439931275.issue40061@roundup.psfhosted.org>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
keywords: +patch
nosy: +ZackerySpytz
nosy_count: 3.0 -> 4.0
pull_requests: +19069
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19748

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40061>
_______________________________________

From report at bugs.python.org  Tue Apr 28 01:40:47 2020
From: report at bugs.python.org (BenTen Jan)
Date: Tue, 28 Apr 2020 05:40:47 +0000
Subject: [issue40395] Scripts folder is Empty in python 3.8.2 for Windows 7.
In-Reply-To: <1587910690.73.0.0218819691356.issue40395@roundup.psfhosted.org>
Message-ID: <1588052447.55.0.206217128147.issue40395@roundup.psfhosted.org>


BenTen Jan <bentenjan365 at gmail.com> added the comment:

First and foremost thanks for replying,

1. I don't have any virus scanner installed.
2. I have tried running "python -m ensurepip" it shows me Following error 

C:\Python>Python get-pip.py
Traceback (most recent call last):
  File "get-pip.py", line 22711, in <module>
    main()
  File "get-pip.py", line 198, in main
    bootstrap(tmpdir=tmpdir)
  File "get-pip.py", line 82, in bootstrap
    from pip._internal.cli.main import main as pip_entry_point
  File "<frozen zipimport>", line 259, in load_module
  File "C:\Users\KNN\AppData\Local\Temp\tmpvrhu1rqz\pip.zip\pip\_internal\cli\main.py", line 10, in <module>
  File "<frozen zipimport>", line 259, in load_module
  File "C:\Users\KNN\AppData\Local\Temp\tmpvrhu1rqz\pip.zip\pip\_internal\cli\autocompletion.py", line 9, in <module>
  File "<frozen zipimport>", line 259, in load_module
  File "C:\Users\KNN\AppData\Local\Temp\tmpvrhu1rqz\pip.zip\pip\_internal\cli\main_parser.py", line 7, in <module>
  File "<frozen zipimport>", line 259, in load_module
  File "C:\Users\KNN\AppData\Local\Temp\tmpvrhu1rqz\pip.zip\pip\_internal\cli\cmdoptions.py", line 28, in <module>
  File "<frozen zipimport>", line 259, in load_module
  File "C:\Users\KNN\AppData\Local\Temp\tmpvrhu1rqz\pip.zip\pip\_internal\models\target_python.py", line 4, in <module>
  File "<frozen zipimport>", line 259, in load_module
  File "C:\Users\KNN\AppData\Local\Temp\tmpvrhu1rqz\pip.zip\pip\_internal\utils\misc.py", line 20, in <module>
  File "<frozen zipimport>", line 259, in load_module
  File "C:\Users\KNN\AppData\Local\Temp\tmpvrhu1rqz\pip.zip\pip\_vendor\pkg_resources\__init__.py", line 35, in <module>
  File "C:\Python\Python38-32\lib\plistlib.py", line 65, in <module>
    from xml.parsers.expat import ParserCreate
  File "C:\Python\Python38-32\lib\xml\parsers\expat.py", line 4, in <module>
    from pyexpat import *
ImportError: DLL load failed while importing pyexpat: The specified module could not be found.

3. Whole Scripts folder in python root is empty, i don't know if its ok with 3.8.2 but Scripts folder was having files in 2.X versions...

Thanks & Appreciate The Handwork of yours towards PY.COMM..

Ben

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40395>
_______________________________________

From report at bugs.python.org  Tue Apr 28 01:50:09 2020
From: report at bugs.python.org (paul rubin)
Date: Tue, 28 Apr 2020 05:50:09 +0000
Subject: [issue40411] frozen collection.Counter
In-Reply-To: <1588031999.2.0.641079021792.issue40411@roundup.psfhosted.org>
Message-ID: <1588053009.57.0.309198230638.issue40411@roundup.psfhosted.org>


paul rubin <phr-pythonbugs at nightsong.com> added the comment:

Totally tangential: Veky, your ordinal example would work ok in Haskell and you'd have omega work the same way as epsilon0.  Take a look at Herman Ruge Jervell's book "Proof Theory" for a really nice tree-based ordinal notation that goes much higher than epsilon0.  It would be cool if your student implemented it.  Raymond, I agree that ordinals are a very esoteric use of multisets ;).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40411>
_______________________________________

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: [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: [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 02:56:12 2020
From: report at bugs.python.org (Dennis Sweeney)
Date: Tue, 28 Apr 2020 06:56:12 +0000
Subject: [issue40418] Small Refactoring: Use the bytes.hex() in
 secrets.token_hex()
In-Reply-To: <1588056928.85.0.969050564689.issue40418@roundup.psfhosted.org>
Message-ID: <1588056972.43.0.81643699012.issue40418@roundup.psfhosted.org>


Change by Dennis Sweeney <sweeney.dennis650 at gmail.com>:


----------
keywords: +patch
pull_requests: +19070
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19749

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40418>
_______________________________________

From report at bugs.python.org  Tue Apr 28 02:59:37 2020
From: report at bugs.python.org (Dennis Sweeney)
Date: Tue, 28 Apr 2020 06:59:37 +0000
Subject: [issue40418] Small Refactoring: Use bytes.hex() in secrets.token_hex()
In-Reply-To: <1588056928.85.0.969050564689.issue40418@roundup.psfhosted.org>
Message-ID: <1588057177.41.0.253981413252.issue40418@roundup.psfhosted.org>


Change by Dennis Sweeney <sweeney.dennis650 at gmail.com>:


----------
title: Small Refactoring: Use the bytes.hex() in secrets.token_hex() -> Small Refactoring: Use bytes.hex() in secrets.token_hex()

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40418>
_______________________________________

From report at bugs.python.org  Tue Apr 28 03:05:56 2020
From: report at bugs.python.org (Thomas Moreau)
Date: Tue, 28 Apr 2020 07:05:56 +0000
Subject: [issue39995] test_concurrent_futures:
 ProcessPoolSpawnExecutorDeadlockTest.test_crash() fails with OSError: [Errno
 9] Bad file descriptor
In-Reply-To: <1584464514.72.0.0566985296328.issue39995@roundup.psfhosted.org>
Message-ID: <1588057556.43.0.684386495958.issue39995@roundup.psfhosted.org>


Thomas Moreau <thomas.moreau.2010 at gmail.com> added the comment:

Sorry I just saw this. It seems that I introduced this regression.

One of the goal of having a `ThreadWakeup` and not a `SimpleQueue` is to avoid using locks that can hinder the performance of the executor. I don't remember the exact details but I think I did some benchmark and it was giving lower performances for large set of small tasks (not so sure anymore). If a fully synchronous method is chosen, maybe it is safer to rely on a `SimpleQueue` as it will be lower maintenance. If the solution proposed by aeros is chosen, the event can probably be replaced by a lock no? It would be easier to understand I guess.

>From the failures, it seems to be a race condition between `shutdown` and `terminate_broken`. The race condition should not be possible in `submit` as in principle, the `join_executor_internals` is only called when no new task can be submitted.
One solution would be to use the `self._shutdown_lock` from the executor to protect the call to `close` in `terminate_broken` and the call to `self._thread_wakeup.wakeup` in `shutdown`. That way, the lock is only acquired at critical points without being used all the time. This could also be done by adding `lock=True/False` to only lock the potentially dangerous calls.

----------
nosy: +tomMoral

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39995>
_______________________________________

From report at bugs.python.org  Tue Apr 28 03:08:54 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 28 Apr 2020 07:08:54 +0000
Subject: [issue40414] Incorrect mouse and keyboard mapping
In-Reply-To: <1588039574.12.0.381855507551.issue40414@roundup.psfhosted.org>
Message-ID: <1588057734.02.0.595422948356.issue40414@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

On which platform and Python version they were mapped to keyboard number buttons?

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40414>
_______________________________________

From report at bugs.python.org  Tue Apr 28 03:16:44 2020
From: report at bugs.python.org (Kyle Stanley)
Date: Tue, 28 Apr 2020 07:16:44 +0000
Subject: [issue40411] frozen collection.Counter
In-Reply-To: <1588031999.2.0.641079021792.issue40411@roundup.psfhosted.org>
Message-ID: <1588058204.87.0.233310866046.issue40411@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:

paul rubin wrote:
> Yeah I think the basic answer to this ticket is "Python doesn't really have multisets and a proposal to add them should go somewhere else".  Fair enough-- consider the request withdrawn from here.

Not necessarily, python-ideas is just more so the designated location for cultivating Python change proposals in their early stages. If you're interested enough in this being added to the standard library, you can present your case there using some of the guidelines I suggested earlier. Also, if others are interested in the feature and have specific use cases for it, that can significantly increase the odds of it being added. The python-ideas mailing list tends to get much more traffic than an individual open issue on bpo.

In the context of significant new feature proposals, bpo is typically used once it's been approved of (with a formal PEP for especially large changes), to further discuss the implementation details and for tracking related PRs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40411>
_______________________________________

From report at bugs.python.org  Tue Apr 28 03:22:15 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 28 Apr 2020 07:22:15 +0000
Subject: [issue40408] GenericAlias does not support nested type variables
In-Reply-To: <1588003077.18.0.979842098769.issue40408@roundup.psfhosted.org>
Message-ID: <1588058535.28.0.123746741587.issue40408@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Not yet. If you don't prefer to fix it yourself, I'll do it as soon as I have time.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40408>
_______________________________________

From report at bugs.python.org  Tue Apr 28 03:24:09 2020
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 28 Apr 2020 07:24:09 +0000
Subject: [issue40417] PyImport_ReloadModule emits deprecation warning
In-Reply-To: <1588056055.69.0.268035650537.issue40417@roundup.psfhosted.org>
Message-ID: <1588058649.7.0.506252510576.issue40417@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch
nosy: +python-dev
nosy_count: 1.0 -> 2.0
pull_requests: +19071
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19750

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40417>
_______________________________________

From report at bugs.python.org  Tue Apr 28 03:56:16 2020
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 28 Apr 2020 07:56:16 +0000
Subject: [issue40061] Possible refleak in _asynciomodule.c
 future_add_done_callback()
In-Reply-To: <1585129013.48.0.185605805596.issue40061@roundup.psfhosted.org>
Message-ID: <1588060576.09.0.551076063959.issue40061@roundup.psfhosted.org>


Antoine Pitrou <solipsis at pitrou.net> added the comment:

You're right that a Py_DECREF is missing there.  However, it seems unlikely that this is triggering the test failure, because `PyList_New(1)` will practically never fail in normal conditions (and even making it deliberately fail would be quite difficult).

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40061>
_______________________________________

From report at bugs.python.org  Tue Apr 28 04:08:36 2020
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 28 Apr 2020 08:08:36 +0000
Subject: [issue39995] test_concurrent_futures:
 ProcessPoolSpawnExecutorDeadlockTest.test_crash() fails with OSError: [Errno
 9] Bad file descriptor
In-Reply-To: <1584464514.72.0.0566985296328.issue39995@roundup.psfhosted.org>
Message-ID: <1588061316.74.0.479206287444.issue39995@roundup.psfhosted.org>


Antoine Pitrou <solipsis at pitrou.net> added the comment:

How about the following (untested):

diff --git a/Lib/concurrent/futures/process.py b/Lib/concurrent/futures/process.py
index 8e9b69a8f0..c0c2eb3032 100644
--- a/Lib/concurrent/futures/process.py
+++ b/Lib/concurrent/futures/process.py
@@ -66,23 +66,29 @@ _global_shutdown = False
 
 class _ThreadWakeup:
     def __init__(self):
-        self._closed = False
         self._reader, self._writer = mp.Pipe(duplex=False)
 
     def close(self):
-        if not self._closed:
-            self._closed = True
-            self._writer.close()
-            self._reader.close()
+        r, w = self._reader, self._writer
+        self._reader = self._writer = None
+        if r is not None:
+            r.close()
+            w.close()
 
     def wakeup(self):
-        if not self._closed:
+        try:
             self._writer.send_bytes(b"")
+        except AttributeError:
+            # Closed
+            pass
 
     def clear(self):
-        if not self._closed:
+        try:
             while self._reader.poll():
                 self._reader.recv_bytes()
+        except AttributeError:
+            # Closed
+            pass
 
 
 def _python_exit():

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39995>
_______________________________________

From report at bugs.python.org  Tue Apr 28 04:33:23 2020
From: report at bugs.python.org (Delgan)
Date: Tue, 28 Apr 2020 08:33:23 +0000
Subject: [issue40399] Program hangs if process created right after adding
 object to a Queue
In-Reply-To: <1587920302.07.0.276002968457.issue40399@roundup.psfhosted.org>
Message-ID: <1588062803.12.0.525075528099.issue40399@roundup.psfhosted.org>


Delgan <delgan.py at gmail.com> added the comment:

I noticed the bug is reproducible even if the child process does not put object in the queue:




    import multiprocessing 
    import threading 
    import time 

    if __name__ == "__main__": 
      queue = multiprocessing.SimpleQueue() 

      def consume(queue):
        while True:
          print("Consumed:", queue.get())

      thread = threading.Thread(target=consume, args=(queue,))
      thread.start()
      
      for i in range(10000):
        queue.put(i)
        p = multiprocessing.Process(target=lambda: None) 
        p.start() 
        p.join()

        print("Not hanging yet", i)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40399>
_______________________________________

From report at bugs.python.org  Tue Apr 28 04:44:37 2020
From: report at bugs.python.org (Kyle Stanley)
Date: Tue, 28 Apr 2020 08:44:37 +0000
Subject: [issue39995] test_concurrent_futures:
 ProcessPoolSpawnExecutorDeadlockTest.test_crash() fails with OSError: [Errno
 9] Bad file descriptor
In-Reply-To: <1584464514.72.0.0566985296328.issue39995@roundup.psfhosted.org>
Message-ID: <1588063477.48.0.777442720539.issue39995@roundup.psfhosted.org>


Change by Kyle Stanley <aeros167 at gmail.com>:


----------
pull_requests: +19072
pull_request: https://github.com/python/cpython/pull/19751

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39995>
_______________________________________

From report at bugs.python.org  Tue Apr 28 04:58:50 2020
From: report at bugs.python.org (Delgan)
Date: Tue, 28 Apr 2020 08:58:50 +0000
Subject: [issue40399] Program hangs if process created right after adding
 object to a Queue
In-Reply-To: <1587920302.07.0.276002968457.issue40399@roundup.psfhosted.org>
Message-ID: <1588064330.44.0.0813793477058.issue40399@roundup.psfhosted.org>


Delgan <delgan.py at gmail.com> added the comment:

Another curiosity: if 'print("Consumed:", queue.get())' is replaced by either 'print("Consumed")' or 'queue.get()', then the program keeps running without stopping. Only a combination of both makes the program to hang.

Also reproducible on 3.5.2.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40399>
_______________________________________

From report at bugs.python.org  Tue Apr 28 05:01:16 2020
From: report at bugs.python.org (Kyle Stanley)
Date: Tue, 28 Apr 2020 09:01:16 +0000
Subject: [issue40061] Possible refleak in _asynciomodule.c
 future_add_done_callback()
In-Reply-To: <1585129013.48.0.185605805596.issue40061@roundup.psfhosted.org>
Message-ID: <1588064476.64.0.0826655854244.issue40061@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:

Antoine Pitrou wrote:
> You're right that a Py_DECREF is missing there.  However, it seems unlikely that this is triggering the test failure, because `PyList_New(1)` will practically never fail in normal conditions (and even making it deliberately fail would be quite difficult).

Thanks for clarifying; spotting refleaks is something that I've only recently started to get the hang of, so I wanted to double check first. :-)

I should have updated this issue, but I resolved the main test_asyncio failure that I saw from GH-19149 in GH-19282. Either way though, I think this could still be fixed (even if it would rarely be an issue in most situations).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40061>
_______________________________________

From report at bugs.python.org  Tue Apr 28 05:10:32 2020
From: report at bugs.python.org (Kyle Stanley)
Date: Tue, 28 Apr 2020 09:10:32 +0000
Subject: [issue39995] test_concurrent_futures:
 ProcessPoolSpawnExecutorDeadlockTest.test_crash() fails with OSError: [Errno
 9] Bad file descriptor
In-Reply-To: <1584464514.72.0.0566985296328.issue39995@roundup.psfhosted.org>
Message-ID: <1588065032.53.0.550309498997.issue39995@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:

Oops, it seems that I opened PR-19751 a bit preemptively. When I get the chance, I'll see if Antoine's implementation can address the failures and do some comparisons.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39995>
_______________________________________

From report at bugs.python.org  Tue Apr 28 05:21:17 2020
From: report at bugs.python.org (Kyle Stanley)
Date: Tue, 28 Apr 2020 09:21:17 +0000
Subject: [issue39995] test_concurrent_futures:
 ProcessPoolSpawnExecutorDeadlockTest.test_crash() fails with OSError: [Errno
 9] Bad file descriptor
In-Reply-To: <1584464514.72.0.0566985296328.issue39995@roundup.psfhosted.org>
Message-ID: <1588065677.72.0.380586559732.issue39995@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:

I decided to close PR-19751. Both because it does not correctly address the race condition (due to an oversight on my part) and it would add substantial overhead to _ThreadWakeup. Instead, I agree that we should explore a non-locking solution.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39995>
_______________________________________

From report at bugs.python.org  Tue Apr 28 06:43:10 2020
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 28 Apr 2020 10:43:10 +0000
Subject: [issue40399] IO streams locking can be broken after fork() with
 threads
In-Reply-To: <1587920302.07.0.276002968457.issue40399@roundup.psfhosted.org>
Message-ID: <1588070590.14.0.700323063589.issue40399@roundup.psfhosted.org>


Antoine Pitrou <solipsis at pitrou.net> added the comment:

I can reproduce on Ubuntu 18.04 with git master.

Here is a better example which clearly shows the issue:
https://gist.github.com/pitrou/d9784d5ec679059cd02fce4b38ea2fa6

After a few runs, you'll see that the child Process hangs when trying to flush the standard streams:
Timeout (0:00:01)!
Thread 0x00007efbff6c0080 (most recent call first):
  File "/home/antoine/cpython/default/Lib/multiprocessing/util.py", line 435 in _flush_std_streams
  File "/home/antoine/cpython/default/Lib/multiprocessing/process.py", line 335 in _bootstrap
  File "/home/antoine/cpython/default/Lib/multiprocessing/popen_fork.py", line 71 in _launch
  File "/home/antoine/cpython/default/Lib/multiprocessing/popen_fork.py", line 19 in __init__
  File "/home/antoine/cpython/default/Lib/multiprocessing/context.py", line 276 in _Popen
  File "/home/antoine/cpython/default/Lib/multiprocessing/context.py", line 224 in _Popen
  File "/home/antoine/cpython/default/Lib/multiprocessing/process.py", line 121 in start
  File "/home/antoine/cpython/default/bpo40399.py", line 25 in <module>
Child process failed!


@Delgan, mixing processes and threads is problematic with the default settings.  See here:
https://docs.python.org/3/library/multiprocessing.html#contexts-and-start-methods

"""Note that safely forking a multithreaded process is problematic."""

If you call `multiprocessing.set_start_method("forkserver")` at the start of your program, the problem will disappear.

----------
nosy: +pitrou, vstinner
title: Program hangs if process created right after adding object to a Queue -> IO streams locking can be broken after fork() with threads
versions: +Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40399>
_______________________________________

From report at bugs.python.org  Tue Apr 28 06:48:16 2020
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 28 Apr 2020 10:48:16 +0000
Subject: [issue40381] plistlib doesn't handle poorly-formatted plists
In-Reply-To: <1587757952.37.0.0995683897517.issue40381@roundup.psfhosted.org>
Message-ID: <1588070896.48.0.863481807518.issue40381@roundup.psfhosted.org>


Change by Ronald Oussoren <ronaldoussoren at mac.com>:


----------
stage:  -> needs patch
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40381>
_______________________________________

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: [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 06:54:30 2020
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 28 Apr 2020 10:54:30 +0000
Subject: [issue40419] timeit CLI docs still mention old power sequence
In-Reply-To: <1588071150.59.0.956744642529.issue40419@roundup.psfhosted.org>
Message-ID: <1588071270.1.0.366210042287.issue40419@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch
nosy: +python-dev
nosy_count: 2.0 -> 3.0
pull_requests: +19073
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19752

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40419>
_______________________________________

From report at bugs.python.org  Tue Apr 28 07:20:13 2020
From: report at bugs.python.org (Hieu Nguyen)
Date: Tue, 28 Apr 2020 11:20:13 +0000
Subject: [issue21081] missing vietnamese codec TCVN 5712:1993 in Python
In-Reply-To: <1395970721.88.0.828263715521.issue21081@psf.upfronthosting.co.za>
Message-ID: <1588072813.13.0.662239977621.issue21081@roundup.psfhosted.org>


Change by Hieu Nguyen <hieuh25 at gmail.com>:


----------
nosy: +hieu.nguyen

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21081>
_______________________________________

From report at bugs.python.org  Tue Apr 28 07:29:26 2020
From: report at bugs.python.org (Antti Haapala)
Date: Tue, 28 Apr 2020 11:29:26 +0000
Subject: [issue21081] missing vietnamese codec TCVN 5712:1993 in Python
In-Reply-To: <1395970721.88.0.828263715521.issue21081@psf.upfronthosting.co.za>
Message-ID: <1588073366.59.0.355511052686.issue21081@roundup.psfhosted.org>


Antti Haapala <antti at haapala.name> added the comment:

The messages above seem to be a (quite likely a machine) translation of Andr?'s comment with a spam link to a paint ad site, so no need to bother to translate it.

Also, I invited Hi?u to the nosy list in case this patch needs some info that requires a native Vietnamese reader, to push this forward ;)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21081>
_______________________________________

From report at bugs.python.org  Tue Apr 28 07:34:34 2020
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 28 Apr 2020 11:34:34 +0000
Subject: [issue21081] missing vietnamese codec TCVN 5712:1993 in Python
In-Reply-To: <1395970721.88.0.828263715521.issue21081@psf.upfronthosting.co.za>
Message-ID: <1588073674.97.0.000404474025726.issue21081@roundup.psfhosted.org>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

I have marked the messages as spam. Can't seem to remove them, though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21081>
_______________________________________

From report at bugs.python.org  Tue Apr 28 07:35:19 2020
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 28 Apr 2020 11:35:19 +0000
Subject: [issue21081] missing vietnamese codec TCVN 5712:1993 in Python
In-Reply-To: <1395970721.88.0.828263715521.issue21081@psf.upfronthosting.co.za>
Message-ID: <1588073719.77.0.925610772452.issue21081@roundup.psfhosted.org>


Change by Marc-Andre Lemburg <mal at egenix.com>:


----------
Removed message: https://bugs.python.org/msg320603

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21081>
_______________________________________

From report at bugs.python.org  Tue Apr 28 07:35:22 2020
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 28 Apr 2020 11:35:22 +0000
Subject: [issue21081] missing vietnamese codec TCVN 5712:1993 in Python
In-Reply-To: <1395970721.88.0.828263715521.issue21081@psf.upfronthosting.co.za>
Message-ID: <1588073722.9.0.419147562679.issue21081@roundup.psfhosted.org>


Change by Marc-Andre Lemburg <mal at egenix.com>:


----------
Removed message: https://bugs.python.org/msg367515

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21081>
_______________________________________

From report at bugs.python.org  Tue Apr 28 07:35:14 2020
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 28 Apr 2020 11:35:14 +0000
Subject: [issue21081] missing vietnamese codec TCVN 5712:1993 in Python
In-Reply-To: <1395970721.88.0.828263715521.issue21081@psf.upfronthosting.co.za>
Message-ID: <1588073714.8.0.710858676868.issue21081@roundup.psfhosted.org>


Change by Marc-Andre Lemburg <mal at egenix.com>:


----------
Removed message: https://bugs.python.org/msg367514

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21081>
_______________________________________

From report at bugs.python.org  Tue Apr 28 07:35:56 2020
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 28 Apr 2020 11:35:56 +0000
Subject: [issue21081] missing vietnamese codec TCVN 5712:1993 in Python
In-Reply-To: <1395970721.88.0.828263715521.issue21081@psf.upfronthosting.co.za>
Message-ID: <1588073756.3.0.517197601557.issue21081@roundup.psfhosted.org>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Found an "Unlink" bottom at the bottom of the message view. This appears to remove the messages from the issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21081>
_______________________________________

From report at bugs.python.org  Tue Apr 28 08:12:05 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 28 Apr 2020 12:12:05 +0000
Subject: [issue40334] PEP 617: new PEG-based parser
In-Reply-To: <1587327377.33.0.614039250584.issue40334@roundup.psfhosted.org>
Message-ID: <1588075925.02.0.680804855436.issue40334@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset 5b9f4988c94f47fa35e84f154a7b5aa17bc04722 by Pablo Galindo in branch 'master':
bpo-40334: Refactor peg_generator to receive a Tokens file when building c code (GH-19745)
https://github.com/python/cpython/commit/5b9f4988c94f47fa35e84f154a7b5aa17bc04722


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40334>
_______________________________________

From report at bugs.python.org  Tue Apr 28 08:23:22 2020
From: report at bugs.python.org (Delgan)
Date: Tue, 28 Apr 2020 12:23:22 +0000
Subject: [issue40399] IO streams locking can be broken after fork() with
 threads
In-Reply-To: <1587920302.07.0.276002968457.issue40399@roundup.psfhosted.org>
Message-ID: <1588076602.43.0.765193823856.issue40399@roundup.psfhosted.org>


Delgan <delgan.py at gmail.com> added the comment:

Thank you for having looked into the problem.

To be more specific, I don't generally mix threads with multiprocessing, but it's a situation where there is one global and hidden consumer thread listening to a queue for non-blocking logging.

Actually, I think the problem is reproducible using the QueueListener provided in "logging.handlers". The following snippet is inspired by this part of the documentation: https://docs.python.org/3/howto/logging-cookbook.html#dealing-with-handlers-that-block

----------------------

import logging
import multiprocessing
import queue
from logging.handlers import QueueHandler, QueueListener


if __name__ == "__main__":
    que = multiprocessing.Queue()
    
    queue_handler = QueueHandler(que)
    handler = logging.StreamHandler()
    listener = QueueListener(que, handler)
    root = logging.getLogger()
    root.addHandler(queue_handler)
    listener.start()

    for i in range(10000):
        root.warning('Look out!')
        p = multiprocessing.Process(target=lambda: None)
        p.start()
        p.join()
        print("Not hanging yet", i)


    listener.stop()

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40399>
_______________________________________

From report at bugs.python.org  Tue Apr 28 08:27:30 2020
From: report at bugs.python.org (R. David Murray)
Date: Tue, 28 Apr 2020 12:27:30 +0000
Subject: [issue40359] email.parse part.get_filename() fails to unwrap long
 attachment file names (legacy API)
In-Reply-To: <1587515187.44.0.744042033479.issue40359@roundup.psfhosted.org>
Message-ID: <1588076850.38.0.355175215211.issue40359@roundup.psfhosted.org>


R. David Murray <rdmurray at bitdance.com> added the comment:

As far as I know you currently still have to specify the policy.  It was, yes, intended that 'default' become the actual default.  I could have sworn there was an open issue for doing this, but I can't find it.  I remember having a conversation with someone who said they were going to work on getting it done, but unfortunately I don't remember who :(

I'm not very active in the python community currently so I can't really drive it, but it should definitely happen.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40359>
_______________________________________

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: [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 08:35:41 2020
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 28 Apr 2020 12:35:41 +0000
Subject: [issue40399] IO streams locking can be broken after fork() with
 threads
In-Reply-To: <1587920302.07.0.276002968457.issue40399@roundup.psfhosted.org>
Message-ID: <1588077341.57.0.0450098162212.issue40399@roundup.psfhosted.org>


Antoine Pitrou <solipsis at pitrou.net> added the comment:

Well, as the documentation states, `QueueListener.start` """starts up a background thread to monitor the queue for LogRecords to process""" :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40399>
_______________________________________

From report at bugs.python.org  Tue Apr 28 08:38:13 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Apr 2020 12:38:13 +0000
Subject: [issue40399] IO streams locking can be broken after fork() with
 threads
In-Reply-To: <1587920302.07.0.276002968457.issue40399@roundup.psfhosted.org>
Message-ID: <1588077493.07.0.0880014760296.issue40399@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy:  -vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40399>
_______________________________________

From report at bugs.python.org  Tue Apr 28 08:41:45 2020
From: report at bugs.python.org (Bar Harel)
Date: Tue, 28 Apr 2020 12:41:45 +0000
Subject: [issue40405] asyncio.as_completed documentation misleading
In-Reply-To: <1587986090.72.0.850288416668.issue40405@roundup.psfhosted.org>
Message-ID: <1588077705.6.0.476410797137.issue40405@roundup.psfhosted.org>


Change by Bar Harel <bzvi7919 at gmail.com>:


----------
keywords: +patch
pull_requests: +19074
stage: resolved -> patch review
pull_request: https://github.com/python/cpython/pull/19753

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40405>
_______________________________________

From report at bugs.python.org  Tue Apr 28 08:44:07 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Apr 2020 12:44:07 +0000
Subject: [issue40415] _asyncio extensions crashes if initialized multiple
 times in same process
In-Reply-To: <1588040845.09.0.680555822876.issue40415@roundup.psfhosted.org>
Message-ID: <1588077847.32.0.443235536802.issue40415@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
superseder:  -> Use-after-free crash if multiple interpreters import asyncio module

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40415>
_______________________________________

From report at bugs.python.org  Tue Apr 28 08:45:45 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 28 Apr 2020 12:45:45 +0000
Subject: [issue40420] argparse choices formatter
In-Reply-To: <1588077262.4.0.512927383758.issue40420@roundup.psfhosted.org>
Message-ID: <1588077945.46.0.67357083945.issue40420@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +paul.j3, rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40420>
_______________________________________

From report at bugs.python.org  Tue Apr 28 08:46:11 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Apr 2020 12:46:11 +0000
Subject: [issue40413] Py_RunMain() crashes on subsequence call
In-Reply-To: <1588038871.72.0.754759187006.issue40413@roundup.psfhosted.org>
Message-ID: <1588077971.29.0.472769197418.issue40413@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I never tried, but I expect that the following pattern is fine:

for (i=0; i<5; i++) {
    Py_Initialize(); Py_RunMain()
}

Maybe Py_RunMain() must fail with a fatal error if it's called when Python is not initialized.

Since Py_RunMain() finalizes Python, you cannot call it multiple times without calling Py_Initialize() between calls.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40413>
_______________________________________

From report at bugs.python.org  Tue Apr 28 08:46:41 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Apr 2020 12:46:41 +0000
Subject: [issue40416] Calling TextIOWrapper.tell() in the middle of reading a
 gb2312-encoded file causes UnicodeDecodeError
In-Reply-To: <1588048436.43.0.594940005352.issue40416@roundup.psfhosted.org>
Message-ID: <1588078001.62.0.612407739688.issue40416@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy:  -vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40416>
_______________________________________

From report at bugs.python.org  Tue Apr 28 08:47:03 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Apr 2020 12:47:03 +0000
Subject: [issue40334] PEP 617: new PEG-based parser
In-Reply-To: <1587327377.33.0.614039250584.issue40334@roundup.psfhosted.org>
Message-ID: <1588078023.46.0.832880109819.issue40334@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy:  -vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40334>
_______________________________________

From report at bugs.python.org  Tue Apr 28 08:48:12 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Apr 2020 12:48:12 +0000
Subject: [issue21081] missing vietnamese codec TCVN 5712:1993 in Python
In-Reply-To: <1395970721.88.0.828263715521.issue21081@psf.upfronthosting.co.za>
Message-ID: <1588078092.23.0.63662923892.issue21081@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy:  -vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21081>
_______________________________________

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: [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:20:23 2020
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 28 Apr 2020 13:20:23 +0000
Subject: [issue6721] Locks in the standard library should be sanitized on fork
In-Reply-To: <1250550378.97.0.072881968798.issue6721@psf.upfronthosting.co.za>
Message-ID: <1588080023.48.0.291237396021.issue6721@roundup.psfhosted.org>


Antoine Pitrou <solipsis at pitrou.net> added the comment:

Related issue:
https://bugs.python.org/issue40399
"""
IO streams locking can be broken after fork() with threads
"""

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue6721>
_______________________________________

From report at bugs.python.org  Tue Apr 28 09:29:25 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 28 Apr 2020 13:29:25 +0000
Subject: [issue40418] Small Refactoring: Use bytes.hex() in secrets.token_hex()
In-Reply-To: <1588056928.85.0.969050564689.issue40418@roundup.psfhosted.org>
Message-ID: <1588080565.04.0.0829245577191.issue40418@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +steven.daprano

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40418>
_______________________________________

From report at bugs.python.org  Tue Apr 28 09:33:25 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 28 Apr 2020 13:33:25 +0000
Subject: [issue40419] timeit CLI docs still mention old power sequence
In-Reply-To: <1588071150.59.0.956744642529.issue40419@roundup.psfhosted.org>
Message-ID: <1588080805.29.0.944019146241.issue40419@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Thanks for the report. This was changed as part of issue28469 where autorange docstring was updated. I guess this was missed out.

----------
nosy: +serhiy.storchaka, xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40419>
_______________________________________

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: [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 09:43:01 2020
From: report at bugs.python.org (Kyle Evans)
Date: Tue, 28 Apr 2020 13:43:01 +0000
Subject: [issue40422] Light refactor: create a common _Py_closerange API
In-Reply-To: <1588080944.1.0.768613011974.issue40422@roundup.psfhosted.org>
Message-ID: <1588081381.63.0.0589459644111.issue40422@roundup.psfhosted.org>


Change by Kyle Evans <kevans at FreeBSD.org>:


----------
keywords: +patch
nosy: +kevans
nosy_count: 1.0 -> 2.0
pull_requests: +19075
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19754

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40422>
_______________________________________

From report at bugs.python.org  Tue Apr 28 10:07:09 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Apr 2020 14:07:09 +0000
Subject: [issue40421] [C API] Add getter functions for PyFrameObject and maybe
 move PyFrameObject to the internal C API
In-Reply-To: <1588079870.34.0.984904607646.issue40421@roundup.psfhosted.org>
Message-ID: <1588082829.51.0.880472776541.issue40421@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
keywords: +patch
pull_requests: +19076
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19755

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40421>
_______________________________________

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: [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 10:32:52 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Apr 2020 14:32:52 +0000
Subject: [issue40421] [C API] Add getter functions for PyFrameObject and maybe
 move PyFrameObject to the internal C API
In-Reply-To: <1588079870.34.0.984904607646.issue40421@roundup.psfhosted.org>
Message-ID: <1588084372.47.0.639161250129.issue40421@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 7c59d7c9860cdbaf4a9c26c9142aebd3259d046e by Victor Stinner in branch 'master':
bpo-40421: Add pyframe.h header file (GH-19755)
https://github.com/python/cpython/commit/7c59d7c9860cdbaf4a9c26c9142aebd3259d046e


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40421>
_______________________________________

From report at bugs.python.org  Tue Apr 28 10:36:17 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 28 Apr 2020 14:36:17 +0000
Subject: [issue40291] socket library support for CAN_J1939
In-Reply-To: <1586928559.09.0.469111314858.issue40291@roundup.psfhosted.org>
Message-ID: <1588084577.26.0.0688644372968.issue40291@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

Looks reasonable.

----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40291>
_______________________________________

From report at bugs.python.org  Tue Apr 28 10:36:14 2020
From: report at bugs.python.org (=?utf-8?q?Alex_Gr=C3=B6nholm?=)
Date: Tue, 28 Apr 2020 14:36:14 +0000
Subject: [issue35829] datetime: parse "Z" timezone suffix in fromisoformat()
In-Reply-To: <1548445007.56.0.14925163397.issue35829@roundup.psfhosted.org>
Message-ID: <1588084574.97.0.226219359296.issue35829@roundup.psfhosted.org>


Alex Gr?nholm <alex.gronholm at nextday.fi> added the comment:

Has this effort gone forwards lately, or has there been any discussion elsewhere? I implemented support for "Z" in .fromisoformat() before finding this issue. Even after reading the discussion I still don't quite understand why it's such a big problem.

----------
nosy: +alex.gronholm

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35829>
_______________________________________

From report at bugs.python.org  Tue Apr 28 10:40:21 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Apr 2020 14:40:21 +0000
Subject: [issue40422] Light refactor: create a common _Py_closerange API
In-Reply-To: <1588080944.1.0.768613011974.issue40422@roundup.psfhosted.org>
Message-ID: <1588084821.38.0.997426457955.issue40422@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40422>
_______________________________________

From report at bugs.python.org  Tue Apr 28 10:45:35 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Apr 2020 14:45:35 +0000
Subject: [issue35134] Add a new Include/cpython/ subdirectory for the "CPython
 API" with implementation details
In-Reply-To: <1541076409.33.0.788709270274.issue35134@psf.upfronthosting.co.za>
Message-ID: <1588085135.73.0.963349360249.issue35134@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +19078
pull_request: https://github.com/python/cpython/pull/19756

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35134>
_______________________________________

From report at bugs.python.org  Tue Apr 28 10:45:35 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Apr 2020 14:45:35 +0000
Subject: [issue40421] [C API] Add getter functions for PyFrameObject and maybe
 move PyFrameObject to the internal C API
In-Reply-To: <1588079870.34.0.984904607646.issue40421@roundup.psfhosted.org>
Message-ID: <1588085135.62.0.371675925786.issue40421@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +19077
pull_request: https://github.com/python/cpython/pull/19756

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40421>
_______________________________________

From report at bugs.python.org  Tue Apr 28 11:07:16 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Apr 2020 15:07:16 +0000
Subject: [issue35134] Add a new Include/cpython/ subdirectory for the "CPython
 API" with implementation details
In-Reply-To: <1541076409.33.0.788709270274.issue35134@psf.upfronthosting.co.za>
Message-ID: <1588086436.12.0.0103875820591.issue35134@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset b8f704d2190125a7750b50cd9b67267b9c20fd43 by Victor Stinner in branch 'master':
bpo-40421: Add Include/cpython/code.h header file (GH-19756)
https://github.com/python/cpython/commit/b8f704d2190125a7750b50cd9b67267b9c20fd43


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35134>
_______________________________________

From report at bugs.python.org  Tue Apr 28 11:07:16 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Apr 2020 15:07:16 +0000
Subject: [issue40421] [C API] Add getter functions for PyFrameObject and maybe
 move PyFrameObject to the internal C API
In-Reply-To: <1588079870.34.0.984904607646.issue40421@roundup.psfhosted.org>
Message-ID: <1588086436.04.0.631857684424.issue40421@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset b8f704d2190125a7750b50cd9b67267b9c20fd43 by Victor Stinner in branch 'master':
bpo-40421: Add Include/cpython/code.h header file (GH-19756)
https://github.com/python/cpython/commit/b8f704d2190125a7750b50cd9b67267b9c20fd43


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40421>
_______________________________________

From report at bugs.python.org  Tue Apr 28 11:27:56 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Apr 2020 15:27:56 +0000
Subject: [issue40421] [C API] Add getter functions for PyFrameObject and maybe
 move PyFrameObject to the internal C API
In-Reply-To: <1588079870.34.0.984904607646.issue40421@roundup.psfhosted.org>
Message-ID: <1588087676.82.0.83275261321.issue40421@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +19079
pull_request: https://github.com/python/cpython/pull/19757

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40421>
_______________________________________

From report at bugs.python.org  Tue Apr 28 11:50:18 2020
From: report at bugs.python.org (paul j3)
Date: Tue, 28 Apr 2020 15:50:18 +0000
Subject: [issue40420] argparse choices formatter
In-Reply-To: <1588077262.4.0.512927383758.issue40420@roundup.psfhosted.org>
Message-ID: <1588089018.59.0.269581028155.issue40420@roundup.psfhosted.org>


paul j3 <ajipanca at gmail.com> added the comment:

The display of the choices has been discussed in previous issues.  When the choices is long there isn't a clean way of handling the display.

I'd suggest using a 'metavar' to show a short value, and then enumerate the choices in the help text.  Use the 'Raw' help formatter to handle newlines as desired.

Choices get displayed in 3 places - the usage, the help, and error messages.  Metavar replaces 2 of those.

An alternative to choices is a custom 'type' function.  An example would be all integers between 0 and 100.  Choices would work, but make a poor display regardless of formatting.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40420>
_______________________________________

From report at bugs.python.org  Tue Apr 28 11:51:20 2020
From: report at bugs.python.org (Ethan Onstott)
Date: Tue, 28 Apr 2020 15:51:20 +0000
Subject: [issue40025] enum: _generate_next_value_ is not called if its
 definition occurs after calls to auto()
In-Reply-To: <1584703504.0.0.0724934497115.issue40025@roundup.psfhosted.org>
Message-ID: <1588089080.26.0.240907598278.issue40025@roundup.psfhosted.org>


Ethan Onstott <ethanaonstott at gmail.com> added the comment:

Ankesh, that is the expected behavior as no patch has been merged yet.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40025>
_______________________________________

From report at bugs.python.org  Tue Apr 28 11:58:40 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Apr 2020 15:58:40 +0000
Subject: [issue39995] test_concurrent_futures:
 ProcessPoolSpawnExecutorDeadlockTest.test_crash() fails with OSError: [Errno
 9] Bad file descriptor
In-Reply-To: <1584464514.72.0.0566985296328.issue39995@roundup.psfhosted.org>
Message-ID: <1588089520.84.0.796752737928.issue39995@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +19080
pull_request: https://github.com/python/cpython/pull/19758

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39995>
_______________________________________

From report at bugs.python.org  Tue Apr 28 12:06:39 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Apr 2020 16:06:39 +0000
Subject: [issue39995] test_concurrent_futures:
 ProcessPoolSpawnExecutorDeadlockTest.test_crash() fails with OSError: [Errno
 9] Bad file descriptor
In-Reply-To: <1584464514.72.0.0566985296328.issue39995@roundup.psfhosted.org>
Message-ID: <1588089999.74.0.41819417338.issue39995@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Antoine Pitrou: "How about the following (untested): (...)"

Using Antoine's patch, test_killed_child() still fails (I used my msg367463 patch to make the failure more likely).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39995>
_______________________________________

From report at bugs.python.org  Tue Apr 28 12:09:22 2020
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 28 Apr 2020 16:09:22 +0000
Subject: [issue39995] test_concurrent_futures:
 ProcessPoolSpawnExecutorDeadlockTest.test_crash() fails with OSError: [Errno
 9] Bad file descriptor
In-Reply-To: <1584464514.72.0.0566985296328.issue39995@roundup.psfhosted.org>
Message-ID: <1588090162.83.0.0441226250027.issue39995@roundup.psfhosted.org>


Antoine Pitrou <solipsis at pitrou.net> added the comment:

With the same traceback and error message?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39995>
_______________________________________

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: [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 12:29:50 2020
From: report at bugs.python.org (Michael Felt)
Date: Tue, 28 Apr 2020 16:29:50 +0000
Subject: [issue40424] AIX: parallel build and ld WARNINGS
In-Reply-To: <1588090800.25.0.961976947202.issue40424@roundup.psfhosted.org>
Message-ID: <1588091390.6.0.628935485121.issue40424@roundup.psfhosted.org>


Change by Michael Felt <aixtools at felt.demon.nl>:


----------
keywords: +patch
pull_requests: +19081
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19759

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40424>
_______________________________________

From report at bugs.python.org  Tue Apr 28 12:37:48 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Apr 2020 16:37:48 +0000
Subject: [issue39995] test_concurrent_futures:
 ProcessPoolSpawnExecutorDeadlockTest.test_crash() fails with OSError: [Errno
 9] Bad file descriptor
In-Reply-To: <1584464514.72.0.0566985296328.issue39995@roundup.psfhosted.org>
Message-ID: <1588091868.4.0.17704604719.issue39995@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +19082
pull_request: https://github.com/python/cpython/pull/19760

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39995>
_______________________________________

From report at bugs.python.org  Tue Apr 28 12:38:42 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Apr 2020 16:38:42 +0000
Subject: [issue39995] test_concurrent_futures:
 ProcessPoolSpawnExecutorDeadlockTest.test_crash() fails with OSError: [Errno
 9] Bad file descriptor
In-Reply-To: <1584464514.72.0.0566985296328.issue39995@roundup.psfhosted.org>
Message-ID: <1588091922.19.0.396082003439.issue39995@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

With my msg367463 patch (add sleep), test_cancel_futures() fails. Example:

======================================================================
FAIL: test_cancel_futures (test.test_concurrent_futures.ProcessPoolForkProcessPoolShutdownTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/vstinner/python/master/Lib/test/test_concurrent_futures.py", line 353, in test_cancel_futures
    self.assertTrue(len(cancelled) >= 35, msg=f"{len(cancelled)=}")
AssertionError: False is not true : len(cancelled)=0

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39995>
_______________________________________

From report at bugs.python.org  Tue Apr 28 12:43:01 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Apr 2020 16:43:01 +0000
Subject: [issue39995] test_concurrent_futures:
 ProcessPoolSpawnExecutorDeadlockTest.test_crash() fails with OSError: [Errno
 9] Bad file descriptor
In-Reply-To: <1584464514.72.0.0566985296328.issue39995@roundup.psfhosted.org>
Message-ID: <1588092181.18.0.134049447708.issue39995@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Thomas Moreau: "One solution would be to use the `self._shutdown_lock` from the executor to protect the call to `close` in `terminate_broken` and the call to `self._thread_wakeup.wakeup` in `shutdown`. That way, the lock is only acquired at critical points without being used all the time. This could also be done by adding `lock=True/False` to only lock the potentially dangerous calls."

I wrote a conservative PR 19760 which always lock ProcessPoolExecutor._shutdown_lock while accessing _ThreadWakeup.

PR 19760 fix test_killed_child(): it doesn't fail anymore, even with my msg367463 patch (add sleep).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39995>
_______________________________________

From report at bugs.python.org  Tue Apr 28 13:00:11 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Apr 2020 17:00:11 +0000
Subject: [issue39995] test_concurrent_futures:
 ProcessPoolSpawnExecutorDeadlockTest.test_crash() fails with OSError: [Errno
 9] Bad file descriptor
In-Reply-To: <1584464514.72.0.0566985296328.issue39995@roundup.psfhosted.org>
Message-ID: <1588093211.2.0.495798147366.issue39995@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> With my msg367463 patch (add sleep), test_cancel_futures() fails.

The test uses sleep() as a synchronization primitive:

   executor.submit(time.sleep, .1).

That's bad, but it doesn't *have to* be fixed now. My msg367463 patch adds an artifical sleep: the test looks fine in practice. I prefer to wait until it fails on a buildbot worker before spending time to make the test more reliable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39995>
_______________________________________

From report at bugs.python.org  Tue Apr 28 13:01:39 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Apr 2020 17:01:39 +0000
Subject: [issue40421] [C API] Add getter functions for PyFrameObject and maybe
 move PyFrameObject to the internal C API
In-Reply-To: <1588079870.34.0.984904607646.issue40421@roundup.psfhosted.org>
Message-ID: <1588093299.08.0.70737443857.issue40421@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset a42ca74fa30227e2f89a619332557cf093a937d5 by Victor Stinner in branch 'master':
bpo-40421: Add PyFrame_GetCode() function (GH-19757)
https://github.com/python/cpython/commit/a42ca74fa30227e2f89a619332557cf093a937d5


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40421>
_______________________________________

From report at bugs.python.org  Tue Apr 28 13:20:52 2020
From: report at bugs.python.org (Fred AYERS)
Date: Tue, 28 Apr 2020 17:20:52 +0000
Subject: [issue36207] robotsparser deny all with some rules
In-Reply-To: <1551865321.24.0.407834320039.issue36207@roundup.psfhosted.org>
Message-ID: <1588094452.36.0.735757276098.issue36207@roundup.psfhosted.org>


Fred AYERS <fred.ayers9673 at gmail.com> added the comment:

I tried this one <a href="http://gtxgamer.fr/robots.txt/">http://gtxgamer.fr/robots.txt</a> and it seems to work.

----------
nosy: +Fred AYERS

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36207>
_______________________________________

From report at bugs.python.org  Tue Apr 28 13:21:03 2020
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 28 Apr 2020 17:21:03 +0000
Subject: [issue40025] enum: _generate_next_value_ is not called if its
 definition occurs after calls to auto()
In-Reply-To: <1584703504.0.0.0724934497115.issue40025@roundup.psfhosted.org>
Message-ID: <1588094463.75.0.381317916374.issue40025@roundup.psfhosted.org>


Ethan Furman <ethan at stoneleaf.us> added the comment:


New changeset d9a43e20facdf4ad10186f820601c6580e1baa80 by Ethan Onstott in branch 'master':
bpo-40025: Require _generate_next_value_ to be defined before members (GH-19098)
https://github.com/python/cpython/commit/d9a43e20facdf4ad10186f820601c6580e1baa80


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40025>
_______________________________________

From report at bugs.python.org  Tue Apr 28 13:22:44 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 28 Apr 2020 17:22:44 +0000
Subject: [issue40025] enum: _generate_next_value_ is not called if its
 definition occurs after calls to auto()
In-Reply-To: <1584703504.0.0.0724934497115.issue40025@roundup.psfhosted.org>
Message-ID: <1588094564.34.0.681974356212.issue40025@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
nosy: +miss-islington
nosy_count: 8.0 -> 9.0
pull_requests: +19083
pull_request: https://github.com/python/cpython/pull/19762

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40025>
_______________________________________

From report at bugs.python.org  Tue Apr 28 13:22:53 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 28 Apr 2020 17:22:53 +0000
Subject: [issue40025] enum: _generate_next_value_ is not called if its
 definition occurs after calls to auto()
In-Reply-To: <1584703504.0.0.0724934497115.issue40025@roundup.psfhosted.org>
Message-ID: <1588094573.95.0.213326841347.issue40025@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +19084
pull_request: https://github.com/python/cpython/pull/19763

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40025>
_______________________________________

From report at bugs.python.org  Tue Apr 28 13:27:58 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Apr 2020 17:27:58 +0000
Subject: [issue40421] [C API] Add getter functions for PyFrameObject and maybe
 move PyFrameObject to the internal C API
In-Reply-To: <1588079870.34.0.984904607646.issue40421@roundup.psfhosted.org>
Message-ID: <1588094878.19.0.387430332079.issue40421@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +19085
pull_request: https://github.com/python/cpython/pull/19764

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40421>
_______________________________________

From report at bugs.python.org  Tue Apr 28 13:33:15 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Apr 2020 17:33:15 +0000
Subject: [issue40421] [C API] Add getter functions for PyFrameObject and maybe
 move PyFrameObject to the internal C API
In-Reply-To: <1588079870.34.0.984904607646.issue40421@roundup.psfhosted.org>
Message-ID: <1588095195.93.0.804221300523.issue40421@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +19086
pull_request: https://github.com/python/cpython/pull/19765

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40421>
_______________________________________

From report at bugs.python.org  Tue Apr 28 13:38:00 2020
From: report at bugs.python.org (Steve Dower)
Date: Tue, 28 Apr 2020 17:38:00 +0000
Subject: [issue40395] Scripts folder is Empty in python 3.8.2 for Windows 7.
In-Reply-To: <1587910690.73.0.0218819691356.issue40395@roundup.psfhosted.org>
Message-ID: <1588095480.92.0.371743193047.issue40395@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Yes, the only thing that should be in your Scripts folder after install is pip. Python itself never puts anything there - it's for other things that you may install.

Could you try running these environment commands and then try installing pip again?

set PYTHONHOME=
set PYTHONPATH=
set PATH=C:\Windows\System32;C:\Windows
python get-pip.py

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40395>
_______________________________________

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: [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 13:45:57 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Apr 2020 17:45:57 +0000
Subject: [issue40421] [C API] Add getter functions for PyFrameObject and maybe
 move PyFrameObject to the internal C API
In-Reply-To: <1588079870.34.0.984904607646.issue40421@roundup.psfhosted.org>
Message-ID: <1588095957.63.0.60555205957.issue40421@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I looked how Cython uses PyFrameObject:

* read f_lasti
* read/write f_back
* write f_lineno
* read f_localsplus
* read/write f_trace

Details:

* Cython/Debugger/libpython.py: code using the Python API of gdb to read PyFrameObject.f_lasti. It it used to compute the line number of a frame. The python_step() function puts a watch point on "f->f_lasti".
* Cython/Utility/Coroutine.c: set PyFrameObject.f_back using "f->f_back = tstate->frame;" and "Py_CLEAR(f->f_back);".
* Cython/Utility/ModuleSetupCode.c, __Pyx_PyFrame_SetLineNumber(): set PyFrameObject.f_lineno member. The limited C API flavor of this function does nothing, since this member cannot be set in the limited C API.
* Cython/Utility/ObjectHandling.c, __Pyx_PyFrame_GetLocalsplus(): complex implementation to access PyFrameObject.f_localsplus:

  // Initialised by module init code.
  static size_t __pyx_pyframe_localsplus_offset = 0;

  #include "frameobject.h"
  // This is the long runtime version of
  //     #define __Pyx_PyFrame_GetLocalsplus(frame)  ((frame)->f_localsplus)
  // offsetof(PyFrameObject, f_localsplus) differs between regular C-Python and Stackless Python.
  // Therefore the offset is computed at run time from PyFrame_type.tp_basicsize. That is feasible,
  // because f_localsplus is the last field of PyFrameObject (checked by Py_BUILD_ASSERT_EXPR below).
  #define __Pxy_PyFrame_Initialize_Offsets()  \
    ((void)__Pyx_BUILD_ASSERT_EXPR(sizeof(PyFrameObject) == offsetof(PyFrameObject, f_localsplus) + Py_MEMBER_SIZE(PyFrameObject, f_localsplus)), \
     (void)(__pyx_pyframe_localsplus_offset = ((size_t)PyFrame_Type.tp_basicsize) - Py_MEMBER_SIZE(PyFrameObject, f_localsplus)))
  #define __Pyx_PyFrame_GetLocalsplus(frame)  \
    (assert(__pyx_pyframe_localsplus_offset), (PyObject **)(((char *)(frame)) + __pyx_pyframe_localsplus_offset))

* Cython/Utility/Profile.c, __Pyx_TraceLine(): read PyFrameObject.f_trace.

* Cython/Utility/Profile.c, __Pyx_TraceSetupAndCall(): set PyFrameObject.f_trace.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40421>
_______________________________________

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: [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 14:18:30 2020
From: report at bugs.python.org (Stefan Behnel)
Date: Tue, 28 Apr 2020 18:18:30 +0000
Subject: [issue38787] PEP 573: Module State Access from C Extension Methods
In-Reply-To: <1573655440.57.0.563143759574.issue38787@roundup.psfhosted.org>
Message-ID: <1588097910.89.0.451388117755.issue38787@roundup.psfhosted.org>


Stefan Behnel <stefan_ml at behnel.de> added the comment:

What can we do to move this forward? I see that the original PR was closed in January. Is there or will there be a new one? Can I help with anything?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38787>
_______________________________________

From report at bugs.python.org  Tue Apr 28 14:37:14 2020
From: report at bugs.python.org (E Kawashima)
Date: Tue, 28 Apr 2020 18:37:14 +0000
Subject: [issue40426] Unable to use lowercase hexadecimal digits for percent
 encoding
In-Reply-To: <1588097651.68.0.271507304283.issue40426@roundup.psfhosted.org>
Message-ID: <1588099034.08.0.604118994094.issue40426@roundup.psfhosted.org>


Change by E Kawashima <e.kawaschima+python at gmail.com>:


----------
keywords: +patch
nosy: +E Kawashima
nosy_count: 1.0 -> 2.0
pull_requests: +19087
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19766

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40426>
_______________________________________

From report at bugs.python.org  Tue Apr 28 14:40:06 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 28 Apr 2020 18:40:06 +0000
Subject: [issue40269] Inconsistent complex behavior with (-1j)
In-Reply-To: <1586736208.71.0.129112794549.issue40269@roundup.psfhosted.org>
Message-ID: <1588099206.65.0.111367804709.issue40269@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Closing this. Please open a separate issue for changing the complex repr if that's the way that you want to go.

----------
resolution:  -> not a bug
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40269>
_______________________________________

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: [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 15:08:01 2020
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 28 Apr 2020 19:08:01 +0000
Subject: [issue40427] importlib of module results in different id than when
 imported with import keyword
In-Reply-To: <1588100454.16.0.607696168199.issue40427@roundup.psfhosted.org>
Message-ID: <1588100881.33.0.702009532092.issue40427@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

That's expected because you are constructing a completely new module object with importlib.util.module_from_spec(). You're also completely circumventing sys.modules with the code you wrote which is the only way you would get equivalent IDs compared to using the import statement.

So this is working as intended.

----------
nosy: +brett.cannon
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40427>
_______________________________________

From report at bugs.python.org  Tue Apr 28 15:18:56 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 28 Apr 2020 19:18:56 +0000
Subject: [issue39117] Performance regression for making bound methods
In-Reply-To: <1576959181.43.0.150480407259.issue39117@roundup.psfhosted.org>
Message-ID: <1588101536.99.0.486360233962.issue39117@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

This performance regression in still present in 3.9.0a6

Results from Tools/scripts/var_access_benchmark.py:

                         Python 3.8.2       Python 3.9.0a6
                         ------------       --------------
  read_boundmethod          27.7 ns	        47.1 ns




> Is this regression is large enough to revive the free_list 
> for bound methods?

Yes!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39117>
_______________________________________

From report at bugs.python.org  Tue Apr 28 15:21:48 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 28 Apr 2020 19:21:48 +0000
Subject: [issue37340] remove free_list for bound method objects
In-Reply-To: <1560948861.51.0.564500331945.issue37340@roundup.psfhosted.org>
Message-ID: <1588101708.28.0.088312938572.issue37340@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

This caused a performance regression (70%) for a fundamental operation.  See issue 37340.

Sometimes, bound methods are used directly and not through LOAD_METHOD:

     sorted(data, key=str.upper)

----------
nosy: +rhettinger
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37340>
_______________________________________

From report at bugs.python.org  Tue Apr 28 15:22:39 2020
From: report at bugs.python.org (Chris Withers)
Date: Tue, 28 Apr 2020 19:22:39 +0000
Subject: [issue25597] unittest.mock does not wrap dunder methods (__getitem__
 etc)
In-Reply-To: <1447174958.96.0.448093662654.issue25597@psf.upfronthosting.co.za>
Message-ID: <1588101759.11.0.636926738298.issue25597@roundup.psfhosted.org>


Chris Withers <chris at withers.org> added the comment:


New changeset 521c8d6806adf0305c158d280ec00cca48e8ab22 by Karthikeyan Singaravelan in branch 'master':
bpo-39966: Revert "bpo-25597: Ensure wraps' return value is used for magic methods in MagicMock" (GH-19734)
https://github.com/python/cpython/commit/521c8d6806adf0305c158d280ec00cca48e8ab22


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25597>
_______________________________________

From report at bugs.python.org  Tue Apr 28 15:22:38 2020
From: report at bugs.python.org (Chris Withers)
Date: Tue, 28 Apr 2020 19:22:38 +0000
Subject: [issue39966] mock 3.9 bug: Wrapped objects without __bool__ raise
 exception
In-Reply-To: <1584254384.28.0.0187140133308.issue39966@roundup.psfhosted.org>
Message-ID: <1588101758.87.0.155306624967.issue39966@roundup.psfhosted.org>


Chris Withers <chris at withers.org> added the comment:


New changeset 521c8d6806adf0305c158d280ec00cca48e8ab22 by Karthikeyan Singaravelan in branch 'master':
bpo-39966: Revert "bpo-25597: Ensure wraps' return value is used for magic methods in MagicMock" (GH-19734)
https://github.com/python/cpython/commit/521c8d6806adf0305c158d280ec00cca48e8ab22


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39966>
_______________________________________

From report at bugs.python.org  Tue Apr 28 15:30:42 2020
From: report at bugs.python.org (Eric Snow)
Date: Tue, 28 Apr 2020 19:30:42 +0000
Subject: [issue32604] Expose the subinterpreters C-API in Python for testing
 use.
In-Reply-To: <1516413482.13.0.467229070634.issue32604@psf.upfronthosting.co.za>
Message-ID: <1588102242.33.0.242656728063.issue32604@roundup.psfhosted.org>


Change by Eric Snow <ericsnowcurrently at gmail.com>:


----------
pull_requests: +19088
pull_request: https://github.com/python/cpython/pull/19768

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32604>
_______________________________________

From report at bugs.python.org  Tue Apr 28 15:41:19 2020
From: report at bugs.python.org (Eric Snow)
Date: Tue, 28 Apr 2020 19:41:19 +0000
Subject: [issue40390] Implement _xxsubinterpreters.channel_send_wait().
In-Reply-To: <1587842364.13.0.0340365069537.issue40390@roundup.psfhosted.org>
Message-ID: <1588102879.11.0.809126464092.issue40390@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

Thanks, Ben.  I'll take a look.

----------
components: +Library (Lib) -C API
title: Implement a C API for channel_send_wait for subinterpreters. -> Implement _xxsubinterpreters.channel_send_wait().

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40390>
_______________________________________

From report at bugs.python.org  Tue Apr 28 16:58:07 2020
From: report at bugs.python.org (Joseph Sible)
Date: Tue, 28 Apr 2020 20:58:07 +0000
Subject: [issue40425] Refleak in CDataObject
In-Reply-To: <1588095498.31.0.363636876654.issue40425@roundup.psfhosted.org>
Message-ID: <1588107487.16.0.518115468828.issue40425@roundup.psfhosted.org>


Change by Joseph Sible <josephcsible at gmail.com>:


----------
nosy: +Joseph Sible

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40425>
_______________________________________

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: [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:16:15 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Apr 2020 21:16:15 +0000
Subject: [issue40428] [C API] Remove PyTuple_ClearFreeList() function
In-Reply-To: <1588107853.55.0.523053148553.issue40428@roundup.psfhosted.org>
Message-ID: <1588108575.59.0.387808740689.issue40428@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
title: [C API] Move PyXXX_ClearFreeLists() functions to the internal C API -> [C API] Remove PyTuple_ClearFreeList() function

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40428>
_______________________________________

From report at bugs.python.org  Tue Apr 28 17:16:35 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Apr 2020 21:16:35 +0000
Subject: [issue40428] [C API] Remove PyTuple_ClearFreeList() function (move it
 to the internal C API)
In-Reply-To: <1588107853.55.0.523053148553.issue40428@roundup.psfhosted.org>
Message-ID: <1588108595.68.0.862617918367.issue40428@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
title: [C API] Remove PyTuple_ClearFreeList() function -> [C API] Remove PyTuple_ClearFreeList() function (move it to the internal C API)

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40428>
_______________________________________

From report at bugs.python.org  Tue Apr 28 17:18:57 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Apr 2020 21:18:57 +0000
Subject: [issue40428] [C API] Remove PyTuple_ClearFreeList() function (move it
 to the internal C API)
In-Reply-To: <1588107853.55.0.523053148553.issue40428@roundup.psfhosted.org>
Message-ID: <1588108737.11.0.113029364843.issue40428@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
keywords: +patch
pull_requests: +19089
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19769

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40428>
_______________________________________

From report at bugs.python.org  Tue Apr 28 17:19:38 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Apr 2020 21:19:38 +0000
Subject: [issue40428] [C API] Remove PyTuple_ClearFreeList() function (move it
 to the internal C API)
In-Reply-To: <1588107853.55.0.523053148553.issue40428@roundup.psfhosted.org>
Message-ID: <1588108778.99.0.563209649497.issue40428@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Only PyTuple_ClearFreeList() was exported by PC/python3.def.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40428>
_______________________________________

From report at bugs.python.org  Tue Apr 28 17:20:39 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Apr 2020 21:20:39 +0000
Subject: [issue37340] remove free_list for bound method objects
In-Reply-To: <1560948861.51.0.564500331945.issue37340@roundup.psfhosted.org>
Message-ID: <1588108839.08.0.368200163961.issue37340@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> This caused a performance regression (70%) for a fundamental operation.  See issue 37340.

Which issue? This is bpo-37340.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37340>
_______________________________________

From report at bugs.python.org  Tue Apr 28 17:27:47 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Apr 2020 21:27:47 +0000
Subject: [issue40334] PEP 617: new PEG-based parser
In-Reply-To: <1587327377.33.0.614039250584.issue40334@roundup.psfhosted.org>
Message-ID: <1588109267.66.0.337147776148.issue40334@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

On x86 Gentoo Non-Debug with X 3.x buildbot, test_peg_generator timed out twice after 15 minutes (first time when tests are run in parallel, then when the test is run sequentially).

Maybe the buildbot worker is just slow. On a previous build (749), test_peg_generator timed out after 15 min (parallel run), but then passed in 12 minutes when re-run in verbose mode.

The buildbot worker should get a larger timeout. I suggest to increase the timeout, or the test should be optimized to take less time.

Pablo: Would you mind to increase ware-gentoo-x86 timeout? Ex: 30 min instead of 15 min.

--

The failed build 750:
https://buildbot.python.org/all/#/builders/188/builds/750

0:58:45 load avg: 4.59 [423/423/2] test_peg_generator crashed (Exit code 1)
(... many compiler warnings ...)
Timeout (0:15:00)!
Thread 0xb7bba700 (most recent call first):
  File "/buildbot/buildarea/cpython/3.x.ware-gentoo-x86.nondebug/build/Lib/subprocess.py", line 1873 in _try_wait
  File "/buildbot/buildarea/cpython/3.x.ware-gentoo-x86.nondebug/build/Lib/subprocess.py", line 1915 in _wait
  File "/buildbot/buildarea/cpython/3.x.ware-gentoo-x86.nondebug/build/Lib/subprocess.py", line 1185 in wait
  File "/buildbot/buildarea/cpython/3.x.ware-gentoo-x86.nondebug/build/Lib/distutils/spawn.py", line 75 in spawn
  File "/buildbot/buildarea/cpython/3.x.ware-gentoo-x86.nondebug/build/Lib/distutils/ccompiler.py", line 910 in spawn
  File "/buildbot/buildarea/cpython/3.x.ware-gentoo-x86.nondebug/build/Lib/distutils/unixccompiler.py", line 117 in _compile
  File "/buildbot/buildarea/cpython/3.x.ware-gentoo-x86.nondebug/build/Lib/distutils/ccompiler.py", line 574 in compile
  File "/buildbot/buildarea/cpython/3.x.ware-gentoo-x86.nondebug/build/Lib/distutils/command/build_ext.py", line 529 in build_extension
  File "/buildbot/buildarea/cpython/3.x.ware-gentoo-x86.nondebug/build/Lib/distutils/command/build_ext.py", line 474 in _build_extensions_serial
  File "/buildbot/buildarea/cpython/3.x.ware-gentoo-x86.nondebug/build/Lib/distutils/command/build_ext.py", line 449 in build_extensions
  File "/buildbot/buildarea/cpython/3.x.ware-gentoo-x86.nondebug/build/Lib/distutils/command/build_ext.py", line 340 in run
  File "/buildbot/buildarea/cpython/3.x.ware-gentoo-x86.nondebug/build/Tools/peg_generator/pegen/build.py", line 89 in compile_c_extension
  File "/buildbot/buildarea/cpython/3.x.ware-gentoo-x86.nondebug/build/Tools/peg_generator/pegen/testutil.py", line 101 in generate_parser_c_extension
  File "/buildbot/buildarea/cpython/3.x.ware-gentoo-x86.nondebug/build/Lib/test/test_peg_generator/test_c_parser.py", line 76 in build_extension
  File "/buildbot/buildarea/cpython/3.x.ware-gentoo-x86.nondebug/build/Lib/test/test_peg_generator/test_c_parser.py", line 79 in run_test
  File "/buildbot/buildarea/cpython/3.x.ware-gentoo-x86.nondebug/build/Lib/test/test_peg_generator/test_c_parser.py", line 240 in test_return_stmt_noexpr_action
  (...)

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40334>
_______________________________________

From report at bugs.python.org  Tue Apr 28 17:28:25 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Apr 2020 21:28:25 +0000
Subject: [issue37340] remove free_list for bound method objects
In-Reply-To: <1560948861.51.0.564500331945.issue37340@roundup.psfhosted.org>
Message-ID: <1588109305.18.0.476565388598.issue37340@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> sorted(data, key=str.upper)

Oh, I guess that it's bpo-39117.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37340>
_______________________________________

From report at bugs.python.org  Tue Apr 28 17:31:21 2020
From: report at bugs.python.org (Eric Snow)
Date: Tue, 28 Apr 2020 21:31:21 +0000
Subject: [issue32604] Expose the subinterpreters C-API in Python for testing
 use.
In-Reply-To: <1516413482.13.0.467229070634.issue32604@psf.upfronthosting.co.za>
Message-ID: <1588109481.89.0.339399626125.issue32604@roundup.psfhosted.org>


Change by Eric Snow <ericsnowcurrently at gmail.com>:


----------
pull_requests: +19090
pull_request: https://github.com/python/cpython/pull/19770

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32604>
_______________________________________

From report at bugs.python.org  Tue Apr 28 17:34:08 2020
From: report at bugs.python.org (Lysandros Nikolaou)
Date: Tue, 28 Apr 2020 21:34:08 +0000
Subject: [issue40334] PEP 617: new PEG-based parser
In-Reply-To: <1587327377.33.0.614039250584.issue40334@roundup.psfhosted.org>
Message-ID: <1588109648.96.0.413376588237.issue40334@roundup.psfhosted.org>


Change by Lysandros Nikolaou <lisandrosnik at gmail.com>:


----------
pull_requests: +19091
pull_request: https://github.com/python/cpython/pull/19771

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40334>
_______________________________________

From report at bugs.python.org  Tue Apr 28 17:37:41 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Apr 2020 21:37:41 +0000
Subject: [issue39117] Performance regression for making bound methods
In-Reply-To: <1576959181.43.0.150480407259.issue39117@roundup.psfhosted.org>
Message-ID: <1588109861.78.0.78545197135.issue39117@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

>  read_boundmethod          27.7 ns	        47.1 ns

Extract of Tools/scripts/var_access_benchmark.py:

def read_boundmethod(trials=trials, a=A()):
    for t in trials:
        a.m;    a.m;    a.m;    a.m;    a.m
        a.m;    a.m;    a.m;    a.m;    a.m
        a.m;    a.m;    a.m;    a.m;    a.m
        a.m;    a.m;    a.m;    a.m;    a.m
        a.m;    a.m;    a.m;    a.m;    a.m

Which kind of code pattern is impacted by this performance regression, apart this micro-benchmark? Do you notice a significant slowdown in pyperformance?

When pyperformance was run before the change was merged, there was no significant difference:
https://bugs.python.org/issue37340#msg348425

In bpo-37340, you wrote that sorted(data, key=str.upper) is 70% slower. Would you mind to provide the benchmark?

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39117>
_______________________________________

From report at bugs.python.org  Tue Apr 28 17:49:27 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Apr 2020 21:49:27 +0000
Subject: [issue39117] Performance regression for making bound methods
In-Reply-To: <1576959181.43.0.150480407259.issue39117@roundup.psfhosted.org>
Message-ID: <1588110567.29.0.648965172409.issue39117@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I compared sorted(data, key=str.upper) performance between before the removal of the free list (parent of commit 3e54b575313c64f541e98216ed079fafed01ff5d) and the current master branch, I get:

Mean +- std dev: [master] 167 us +- 4 us -> [cache] 179 us +- 7 us: 1.07x slower (+7%)

I cannot reproduce the "70% slowdown".

Raymond: How did you compile Python? What is your OS? How did you run your benchmark?

---

It's a quick & dirty benchmark run. I didn't use LTO+PGO and I didn't isolate my CPU. Maybe the difference of 12 ns is just caused by the noise of my coarse benchmark procedure.

I used commands:

# master
git checkout master
git clean -fdx
./configure && make && ./python -m venv env && env/bin/python -m pip install pyperf
env/bin/python -m pyperf timeit -s 'import random; data = [f"x{i}" for i in range(1000)]; random.shuffle(data)' 'sorted(data, key=str.upper)' -o ../master.json

# before removal of the free list
git checkout 3e54b575313c64f541e98216ed079fafed01ff5d^
git clean -fdx
./configure && make && ./python -m venv env && env/bin/python -m pip install pyperf
env/bin/python -m pyperf timeit -s 'import random; data = [f"x{i}" for i in range(1000)]; random.shuffle(data)' 'sorted(data, key=str.upper)' -o ../master.json

That's a Fedora 31 using GCC -O3 (GCC 9.3.1).

--

The commit before the removal of the free list is:

commit 76b645124b3aaa34bc664eece43707c01ef1b382 (HEAD)
Date:   Fri Jul 26 03:30:33 2019 +0200

Well, maybe I did a mistake.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39117>
_______________________________________

From report at bugs.python.org  Tue Apr 28 17:51:46 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Apr 2020 21:51:46 +0000
Subject: [issue39117] Performance regression for making bound methods
In-Reply-To: <1576959181.43.0.150480407259.issue39117@roundup.psfhosted.org>
Message-ID: <1588110706.11.0.475218060553.issue39117@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

By the way, in sorted(data, key=str.upper): str.upper is an unbound method, no?

$ ./python
Python 3.9.0a6+ (heads/master:d9a43e20fa, Apr 28 2020, 23:50:37) 
>>> type(str.upper)
<class 'method_descriptor'>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39117>
_______________________________________

From report at bugs.python.org  Tue Apr 28 17:54:40 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 28 Apr 2020 21:54:40 +0000
Subject: [issue38787] PEP 573: Module State Access from C Extension Methods
In-Reply-To: <1573655440.57.0.563143759574.issue38787@roundup.psfhosted.org>
Message-ID: <1588110880.01.0.0494503053717.issue38787@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

The PEP is listed as accepted, with you as the BDFL-delegate, but it lacks a link to the public acceptance message (usually on pydev list).

The PR was not rejected by a core dev but was closed without explanation by the author on the same day the last commits were added.  Perhaps OP just gave up getting tests to pass.  But they disappear on closes.  

However, the contribution had been made under the CLA and you or Petr or any other core dev should be able to download it to a local branch, try to whip it into shape, and make a new PR before beta 1, in about a month.  Or start from scratch.

I cannot test downloading at the moment.  Apparently, OP's fork branch has been altered, so that merely reopening is not an option.  The OP used force-pushes rather than update merges, and this often creates problems.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38787>
_______________________________________

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: [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:35:30 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Apr 2020 22:35:30 +0000
Subject: [issue40429] [C API] PyThreadState_GetFrame() and PyFrame_GetCode()
 should return a strong refrence
In-Reply-To: <1588110917.55.0.0908942535567.issue40429@roundup.psfhosted.org>
Message-ID: <1588113330.31.0.474527349006.issue40429@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
keywords: +patch
pull_requests: +19092
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19772

_______________________________________
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: [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 18:57:01 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Apr 2020 22:57:01 +0000
Subject: [issue40429] [C API] PyThreadState_GetFrame() and PyFrame_GetCode()
 should return a strong refrence
In-Reply-To: <1588110917.55.0.0908942535567.issue40429@roundup.psfhosted.org>
Message-ID: <1588114621.51.0.940865524837.issue40429@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 6d86a2331e6b64a2ae80c1a21f81baa5a71ac594 by Victor Stinner in branch 'master':
bpo-40429: PyFrame_GetCode() result cannot be NULL (GH-19772)
https://github.com/python/cpython/commit/6d86a2331e6b64a2ae80c1a21f81baa5a71ac594


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40429>
_______________________________________

From report at bugs.python.org  Tue Apr 28 19:06:03 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Apr 2020 23:06:03 +0000
Subject: [issue40429] [C API] PyThreadState_GetFrame() and PyFrame_GetCode()
 should return a strong refrence
In-Reply-To: <1588110917.55.0.0908942535567.issue40429@roundup.psfhosted.org>
Message-ID: <1588115163.28.0.424449291384.issue40429@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +19093
pull_request: https://github.com/python/cpython/pull/19773

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40429>
_______________________________________

From report at bugs.python.org  Tue Apr 28 19:07:01 2020
From: report at bugs.python.org (Lysandros Nikolaou)
Date: Tue, 28 Apr 2020 23:07:01 +0000
Subject: [issue40334] PEP 617: new PEG-based parser
In-Reply-To: <1587327377.33.0.614039250584.issue40334@roundup.psfhosted.org>
Message-ID: <1588115221.69.0.938272285119.issue40334@roundup.psfhosted.org>


Change by Lysandros Nikolaou <lisandrosnik at gmail.com>:


----------
pull_requests: +19094
pull_request: https://github.com/python/cpython/pull/19774

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40334>
_______________________________________

From report at bugs.python.org  Tue Apr 28 19:11:36 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 28 Apr 2020 23:11:36 +0000
Subject: [issue32604] Expose the subinterpreters C-API in Python for testing
 use.
In-Reply-To: <1516413482.13.0.467229070634.issue32604@psf.upfronthosting.co.za>
Message-ID: <1588115496.23.0.830789663375.issue32604@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 5e8c691594d68925213d36296ce7c4b3e90bcb1d by Eric Snow in branch 'master':
bpo-32604: Add support for a "default" arg in channel_recv(). (GH-19770)
https://github.com/python/cpython/commit/5e8c691594d68925213d36296ce7c4b3e90bcb1d


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32604>
_______________________________________

From report at bugs.python.org  Tue Apr 28 19:23:58 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 28 Apr 2020 23:23:58 +0000
Subject: [issue40334] PEP 617: new PEG-based parser
In-Reply-To: <1587327377.33.0.614039250584.issue40334@roundup.psfhosted.org>
Message-ID: <1588116238.36.0.328094398367.issue40334@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
pull_requests: +19095
pull_request: https://github.com/python/cpython/pull/19775

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40334>
_______________________________________

From report at bugs.python.org  Tue Apr 28 19:28:19 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Apr 2020 23:28:19 +0000
Subject: [issue40429] [C API] PyThreadState_GetFrame() and PyFrame_GetCode()
 should return a strong refrence
In-Reply-To: <1588110917.55.0.0908942535567.issue40429@roundup.psfhosted.org>
Message-ID: <1588116499.97.0.960981892391.issue40429@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 8852ad4208e34825f74e24945edb5bcf055d94fe by Victor Stinner in branch 'master':
bpo-40429: PyFrame_GetCode() now returns a strong reference (GH-19773)
https://github.com/python/cpython/commit/8852ad4208e34825f74e24945edb5bcf055d94fe


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40429>
_______________________________________

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: [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 19:32:56 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Apr 2020 23:32:56 +0000
Subject: [issue40429] [C API] PyThreadState_GetFrame() and PyFrame_GetCode()
 should return a strong refrence
In-Reply-To: <1588110917.55.0.0908942535567.issue40429@roundup.psfhosted.org>
Message-ID: <1588116776.37.0.138218999195.issue40429@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +19096
pull_request: https://github.com/python/cpython/pull/19776

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40429>
_______________________________________

From report at bugs.python.org  Tue Apr 28 19:35:22 2020
From: report at bugs.python.org (=?utf-8?q?Miro_Hron=C4=8Dok?=)
Date: Tue, 28 Apr 2020 23:35:22 +0000
Subject: [issue40431] turtledemo/__main__.py: SyntaxError: invalid string
 prefix else"#fca"
In-Reply-To: <1588116558.63.0.121077562738.issue40431@roundup.psfhosted.org>
Message-ID: <1588116922.45.0.182619243854.issue40431@roundup.psfhosted.org>


Change by Miro Hron?ok <miro at hroncok.cz>:


----------
keywords: +patch
pull_requests: +19097
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19777

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40431>
_______________________________________

From report at bugs.python.org  Tue Apr 28 19:36:53 2020
From: report at bugs.python.org (Lysandros Nikolaou)
Date: Tue, 28 Apr 2020 23:36:53 +0000
Subject: [issue40334] PEP 617: new PEG-based parser
In-Reply-To: <1587327377.33.0.614039250584.issue40334@roundup.psfhosted.org>
Message-ID: <1588117013.61.0.296404617452.issue40334@roundup.psfhosted.org>


Change by Lysandros Nikolaou <lisandrosnik at gmail.com>:


----------
pull_requests: +19098
pull_request: https://github.com/python/cpython/pull/19778

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40334>
_______________________________________

From report at bugs.python.org  Tue Apr 28 19:43:20 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 28 Apr 2020 23:43:20 +0000
Subject: [issue40334] PEP 617: new PEG-based parser
In-Reply-To: <1587327377.33.0.614039250584.issue40334@roundup.psfhosted.org>
Message-ID: <1588117400.93.0.514751975345.issue40334@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

> Pablo: Would you mind to increase ware-gentoo-x86 timeout? Ex: 30 min instead of 15 min.


Done: https://github.com/python/buildmaster-config/pull/190

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40334>
_______________________________________

From report at bugs.python.org  Tue Apr 28 19:45:33 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Apr 2020 23:45:33 +0000
Subject: [issue40334] PEP 617: new PEG-based parser
In-Reply-To: <1587327377.33.0.614039250584.issue40334@roundup.psfhosted.org>
Message-ID: <1588117533.14.0.587831898058.issue40334@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

It seems like building Python on Windows 64-bit emits a few warnings:

D:\a\1\s\Parser\pegen\pegen.c(610,91): warning C4267: '=': conversion from 'size_t' to 'int', possible loss of data [D:\a\1\s\PCbuild\pythoncore.vcxproj]
D:\a\1\s\Parser\pegen\pegen.c(611,52): warning C4267: '=': conversion from 'size_t' to 'int', possible loss of data [D:\a\1\s\PCbuild\pythoncore.vcxproj]
D:\a\1\s\Parser\pegen\pegen.c(612,103): warning C4267: '=': conversion from 'size_t' to 'int', possible loss of data [D:\a\1\s\PCbuild\pythoncore.vcxproj]

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40334>
_______________________________________

From report at bugs.python.org  Tue Apr 28 19:49:27 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Apr 2020 23:49:27 +0000
Subject: [issue39837] Remove Azure Pipelines from GitHub PRs
In-Reply-To: <1583255119.77.0.277327127951.issue39837@roundup.psfhosted.org>
Message-ID: <1588117767.6.0.153522428687.issue39837@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Another Azure Pipeline failure on my https://github.com/python/cpython/pull/19769 PR, it looks like a random networking failure.

Sadly, I had to close/reopen my PR since there is no button to only restart the failure job, or even restart all Azure Pipeline jobs. This retrigger all CI jobs :-(

https://dev.azure.com/Python/cpython/_build/results?buildId=61891&view=logs&j=c83831cd-3752-5cc7-2f01-8276919eb334&t=6bd3fafc-d115-560e-4a08-fa9326c4b5c7

The win64 job of Azure Pipelines PR fails to build Python because it failed to fetch bzip2:

Fetching bzip2-1.0.6...
(...)
  File "C:\hostedtoolcache\windows\Python\3.8.2\x64\lib\http\client.py", line 915, in connect
    self.sock = self._create_connection(
  File "C:\hostedtoolcache\windows\Python\3.8.2\x64\lib\socket.py", line 787, in create_connection
    for res in getaddrinfo(host, port, 0, SOCK_STREAM):
  File "C:\hostedtoolcache\windows\Python\3.8.2\x64\lib\socket.py", line 918, in getaddrinfo
    for res in _socket.getaddrinfo(host, port, family, type, proto, flags):
socket.gaierror: [Errno 11001] getaddrinfo failed
(...)
  File "C:\hostedtoolcache\windows\Python\3.8.2\x64\lib\urllib\request.py", line 1362, in https_open
    return self.do_open(http.client.HTTPSConnection, req,
  File "C:\hostedtoolcache\windows\Python\3.8.2\x64\lib\urllib\request.py", line 1322, in do_open
    raise URLError(err)
urllib.error.URLError: <urlopen error [Errno 11001] getaddrinfo failed>
(...)
c1 : fatal error C1083: Cannot open source file: 'd:\a\1\b\externals\bzip2-1.0.6\blocksort.c': No such file or directory [D:\a\1\s\PCbuild\_bz2.vcxproj]
c1 : fatal error C1083: Cannot open source file: 'd:\a\1\b\externals\bzip2-1.0.6\bzlib.c': No such file or directory [D:\a\1\s\PCbuild\_bz2.vcxproj]
c1 : fatal error C1083: Cannot open source file: 'd:\a\1\b\externals\bzip2-1.0.6\compress.c': No such file or directory [D:\a\1\s\PCbuild\_bz2.vcxproj]
c1 : fatal error C1083: Cannot open source file: 'd:\a\1\b\externals\bzip2-1.0.6\crctable.c': No such file or directory [D:\a\1\s\PCbuild\_bz2.vcxproj]
c1 : fatal error C1083: Cannot open source file: 'd:\a\1\b\externals\bzip2-1.0.6\decompress.c': No such file or directory [D:\a\1\s\PCbuild\_bz2.vcxproj]
c1 : fatal error C1083: Cannot open source file: 'd:\a\1\b\externals\bzip2-1.0.6\huffman.c': No such file or directory [D:\a\1\s\PCbuild\_bz2.vcxproj]
c1 : fatal error C1083: Cannot open source file: 'd:\a\1\b\externals\bzip2-1.0.6\randtable.c': No such file or directory [D:\a\1\s\PCbuild\_bz2.vcxproj]

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39837>
_______________________________________

From report at bugs.python.org  Tue Apr 28 19:52:00 2020
From: report at bugs.python.org (Ammar Askar)
Date: Tue, 28 Apr 2020 23:52:00 +0000
Subject: [issue40317] inspect.getsource() examines incorrect target
In-Reply-To: <1587210637.54.0.0432450975105.issue40317@roundup.psfhosted.org>
Message-ID: <1588117920.47.0.301347249269.issue40317@roundup.psfhosted.org>


Ammar Askar <ammar at ammaraskar.com> added the comment:

Did you mean to close this Karthik?

----------
nosy: +ammar2

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40317>
_______________________________________

From report at bugs.python.org  Tue Apr 28 19:55:34 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 28 Apr 2020 23:55:34 +0000
Subject: [issue40334] PEP 617: new PEG-based parser
In-Reply-To: <1587327377.33.0.614039250584.issue40334@roundup.psfhosted.org>
Message-ID: <1588118134.99.0.343691176667.issue40334@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
pull_requests: +19099
pull_request: https://github.com/python/cpython/pull/19779

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40334>
_______________________________________

From report at bugs.python.org  Tue Apr 28 19:58:07 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Apr 2020 23:58:07 +0000
Subject: [issue40334] PEP 617: new PEG-based parser
In-Reply-To: <1587327377.33.0.614039250584.issue40334@roundup.psfhosted.org>
Message-ID: <1588118287.47.0.580154674218.issue40334@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

The following code works on Python 3.8, but fails with SyntaxError on Python 3.9.0a6 with the old and the new parser (see bpo-40431):

    clear = "NORMAL"
    print(dict(state=clear, bg="#d00" if clear else"#fca"))

Well, the code looks like a typo error... but it worked previously. Not sure if we should keep the SyntaxError or not. Fixing the code is trivial: see PR 19777 attached to bpo-40431; replace >else"#fca"< with >else "#fca"<.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40334>
_______________________________________

From report at bugs.python.org  Tue Apr 28 20:00:10 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Apr 2020 00:00:10 +0000
Subject: [issue40431] turtledemo/__main__.py: SyntaxError: invalid string
 prefix else"#fca"
In-Reply-To: <1588116558.63.0.121077562738.issue40431@roundup.psfhosted.org>
Message-ID: <1588118410.96.0.884823222164.issue40431@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 49f70db83e2c62ad06805927f53f6c3e8f4b798e by Miro Hron?ok in branch 'master':
bpo-40431: Fix syntax typo in turtledemo (GH-19777)
https://github.com/python/cpython/commit/49f70db83e2c62ad06805927f53f6c3e8f4b798e


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40431>
_______________________________________

From report at bugs.python.org  Tue Apr 28 20:00:42 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 29 Apr 2020 00:00:42 +0000
Subject: [issue40334] PEP 617: new PEG-based parser
In-Reply-To: <1587327377.33.0.614039250584.issue40334@roundup.psfhosted.org>
Message-ID: <1588118442.97.0.54343404468.issue40334@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

> The following code works on Python 3.8, but fails with SyntaxError on Python 3.9.0a6 with the old and the new parser (see bpo-40431):


This is not due to the new parser but due to https://bugs.python.org/issue40246. Please, report it there as well (you can reopen that issue for further discussion).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40334>
_______________________________________

From report at bugs.python.org  Tue Apr 28 20:01:10 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Apr 2020 00:01:10 +0000
Subject: [issue40431] turtledemo/__main__.py: SyntaxError: invalid string
 prefix else"#fca"
In-Reply-To: <1588116558.63.0.121077562738.issue40431@roundup.psfhosted.org>
Message-ID: <1588118470.35.0.796993622761.issue40431@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I don't think that it's worth it to backport the change to 3.7 and 3.8: in Python 3.7 and 3.8, the code is accepted.

I also reported the issue to: https://bugs.python.org/issue40334#msg367580

Miro: are you ok to close the issue (not backport)?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40431>
_______________________________________

From report at bugs.python.org  Tue Apr 28 20:07:15 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Wed, 29 Apr 2020 00:07:15 +0000
Subject: [issue40430] ast.Slice is no longer a subclass of ast.slice
In-Reply-To: <1588114083.65.0.758237100014.issue40430@roundup.psfhosted.org>
Message-ID: <1588118835.69.0.384838542647.issue40430@roundup.psfhosted.org>


Batuhan Taskaya <batuhanosmantaskaya at gmail.com> added the comment:

This has been discussee and rejected (for certain reasonsons): https://github.com/python/cpython/pull/19056#discussion_r396087689

----------
nosy: +BTaskaya, serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40430>
_______________________________________

From report at bugs.python.org  Tue Apr 28 20:07:18 2020
From: report at bugs.python.org (=?utf-8?q?Miro_Hron=C4=8Dok?=)
Date: Wed, 29 Apr 2020 00:07:18 +0000
Subject: [issue40431] turtledemo/__main__.py: SyntaxError: invalid string
 prefix else"#fca"
In-Reply-To: <1588116558.63.0.121077562738.issue40431@roundup.psfhosted.org>
Message-ID: <1588118838.69.0.247925865484.issue40431@roundup.psfhosted.org>


Miro Hron?ok <miro at hroncok.cz> added the comment:

I am OK. I don't see why not to backport it, but I don't care much.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40431>
_______________________________________

From report at bugs.python.org  Tue Apr 28 20:10:25 2020
From: report at bugs.python.org (Lysandros Nikolaou)
Date: Wed, 29 Apr 2020 00:10:25 +0000
Subject: [issue40246] Different error messages for same error - invalid string
 prefixes
In-Reply-To: <1586541958.33.0.891000303304.issue40246@roundup.psfhosted.org>
Message-ID: <1588119025.19.0.883016739931.issue40246@roundup.psfhosted.org>


Lysandros Nikolaou <lisandrosnik at gmail.com> added the comment:

On bpo-40334 @vstinner reported that this change broke some code in turtledemo. The code looks like this:

print(dict(state=clear, bg="#d00" if clear else"#fca"))

Due to the absence of a space between `else` and `"`, the else keyword is now interpreted as an invalid string prefix. Is that acceptable?

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40246>
_______________________________________

From report at bugs.python.org  Tue Apr 28 20:17:06 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Apr 2020 00:17:06 +0000
Subject: [issue40246] Different error messages for same error - invalid string
 prefixes
In-Reply-To: <1586541958.33.0.891000303304.issue40246@roundup.psfhosted.org>
Message-ID: <1588119426.6.0.0375929175159.issue40246@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I reopen the issue.

The following code works on Python 3.8, but fails with SyntaxError on Python 3.9.0a6 with the old and the new parser (see bpo-40431):

    clear = "NORMAL"
    print(dict(state=clear, bg="#d00" if clear else"#fca"))

Well, the code looks like a typo error... but it worked previously.

Not sure if we should keep the SyntaxError or not. Fixing the code is trivial: see PR 19777 attached to bpo-40431; replace >else"#fca"< with >else "#fca"<.

Note: I first reported the issue to https://bugs.python.org/issue40334#msg367580

----------
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40246>
_______________________________________

From report at bugs.python.org  Tue Apr 28 20:18:23 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 29 Apr 2020 00:18:23 +0000
Subject: [issue40334] PEP 617: new PEG-based parser
In-Reply-To: <1587327377.33.0.614039250584.issue40334@roundup.psfhosted.org>
Message-ID: <1588119503.71.0.465159082284.issue40334@roundup.psfhosted.org>


Change by Guido van Rossum <guido at python.org>:


----------
pull_requests: +19100
pull_request: https://github.com/python/cpython/pull/19780

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40334>
_______________________________________

From report at bugs.python.org  Tue Apr 28 20:18:39 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 29 Apr 2020 00:18:39 +0000
Subject: [issue40246] Different error messages for same error - invalid string
 prefixes
In-Reply-To: <1586541958.33.0.891000303304.issue40246@roundup.psfhosted.org>
Message-ID: <1588119519.02.0.885538260265.issue40246@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

I personally think the new behaviour is more consistent and more likely to catch errors.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40246>
_______________________________________

From report at bugs.python.org  Tue Apr 28 20:18:49 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 29 Apr 2020 00:18:49 +0000
Subject: [issue38880] Subinterpreters: List interpreters associated with a
 channel end
In-Reply-To: <1574352893.51.0.220552171167.issue38880@roundup.psfhosted.org>
Message-ID: <1588119529.73.0.164789361574.issue38880@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset f7bbf58aa9299e9dd00b7a1bdd1113b4dcb6dfdf by Lewis Gaul in branch 'master':
bpo-38880: List interpreters associated with a channel end (GH-17323)
https://github.com/python/cpython/commit/f7bbf58aa9299e9dd00b7a1bdd1113b4dcb6dfdf


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38880>
_______________________________________

From report at bugs.python.org  Tue Apr 28 20:19:56 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Apr 2020 00:19:56 +0000
Subject: [issue40431] turtledemo/__main__.py: SyntaxError: invalid string
 prefix else"#fca"
In-Reply-To: <1588116558.63.0.121077562738.issue40431@roundup.psfhosted.org>
Message-ID: <1588119596.16.0.954479099696.issue40431@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> I am OK. I don't see why not to backport it, but I don't care much.

Python 3.7 and 3.8 are not broken, so there is no need to fix them :-) Thanks for the fix.

I reported the issue to:
https://bugs.python.org/issue40246#msg367587

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions:  -Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40431>
_______________________________________

From report at bugs.python.org  Tue Apr 28 20:22:07 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Apr 2020 00:22:07 +0000
Subject: [issue40246] Different error messages for same error - invalid string
 prefixes
In-Reply-To: <1586541958.33.0.891000303304.issue40246@roundup.psfhosted.org>
Message-ID: <1588119727.22.0.732741375199.issue40246@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> I personally think the new behaviour is more consistent and more likely to catch errors.

Would it be possible to emit a SyntaxWarning in 3.9 and only emit a SyntaxError in 3.10?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40246>
_______________________________________

From report at bugs.python.org  Tue Apr 28 20:26:21 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 29 Apr 2020 00:26:21 +0000
Subject: [issue40246] Different error messages for same error - invalid string
 prefixes
In-Reply-To: <1586541958.33.0.891000303304.issue40246@roundup.psfhosted.org>
Message-ID: <1588119981.73.0.607254222569.issue40246@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

Personally I don't think that `else"stuff"` should become a syntax error. It's no different from other edge cases where for some reason the space seems optional, like `1and 2`.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40246>
_______________________________________

From report at bugs.python.org  Tue Apr 28 20:27:52 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Apr 2020 00:27:52 +0000
Subject: [issue39837] Remove Azure Pipelines from GitHub PRs
In-Reply-To: <1583255119.77.0.277327127951.issue39837@roundup.psfhosted.org>
Message-ID: <1588120072.35.0.157152032914.issue39837@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> Sadly, I had to close/reopen my PR since there is no button to only restart the failure job, or even restart all Azure Pipeline jobs. This retrigger all CI jobs :-(

Sadly (again), closing/reopening a PR re-runs all CIs. At the first run, GH Action macOS job passed. At the second run, the "Tests" step of GH Action macOS job, but I'm clueless with its logs:

https://github.com/python/cpython/pull/19776/checks?check_run_id=627916923

2020-04-28T23:33:03.5559341Z ##[section]Starting: Request a runner to run this job
2020-04-28T23:33:04.1879823Z Requesting a hosted runner in current repository's account/organization with labels: 'macos-latest', require runner match: True
2020-04-28T23:33:04.2799035Z Labels matched hosted runners has been found, waiting for one of them get assigned for this job.
2020-04-28T23:33:04.3183702Z ##[section]Finishing: Request a runner to run this job

On the web UI, I see that 6 steps completed, only the last "Tests" step failed. But can't I see logs of other steps?

I would prefer to be able to merge a PR even when Azure Pipelines fails: make the job optional.

Hopefully, GH Action macOS job is optional and so I can merge my PR ;-)

Note: I'm not sure if it's the right place to report GH Action macOS failure, but it seems to be related to Azure Pipelines.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39837>
_______________________________________

From report at bugs.python.org  Tue Apr 28 20:28:30 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Apr 2020 00:28:30 +0000
Subject: [issue40429] [C API] PyThreadState_GetFrame() and PyFrame_GetCode()
 should return a strong refrence
In-Reply-To: <1588110917.55.0.0908942535567.issue40429@roundup.psfhosted.org>
Message-ID: <1588120110.38.0.580774292176.issue40429@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset cc0dc7e484c9626857e9a8b4c40eee37473702ed by Victor Stinner in branch 'master':
bpo-40429: Refactor super_init() (GH-19776)
https://github.com/python/cpython/commit/cc0dc7e484c9626857e9a8b4c40eee37473702ed


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40429>
_______________________________________

From report at bugs.python.org  Tue Apr 28 20:29:24 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Apr 2020 00:29:24 +0000
Subject: [issue40428] [C API] Remove PyTuple_ClearFreeList() function (move it
 to the internal C API)
In-Reply-To: <1588107853.55.0.523053148553.issue40428@roundup.psfhosted.org>
Message-ID: <1588120164.24.0.72592326346.issue40428@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset ae00a5a88534fd45939f86c12e038da9fa6f9ed6 by Victor Stinner in branch 'master':
bpo-40428: Remove PyTuple_ClearFreeList() function (GH-19769)
https://github.com/python/cpython/commit/ae00a5a88534fd45939f86c12e038da9fa6f9ed6


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40428>
_______________________________________

From report at bugs.python.org  Tue Apr 28 20:29:40 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Apr 2020 00:29:40 +0000
Subject: [issue40428] [C API] Remove PyTuple_ClearFreeList() function (move it
 to the internal C API)
In-Reply-To: <1588107853.55.0.523053148553.issue40428@roundup.psfhosted.org>
Message-ID: <1588120180.54.0.194302832857.issue40428@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40428>
_______________________________________

From report at bugs.python.org  Tue Apr 28 20:30:34 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Apr 2020 00:30:34 +0000
Subject: [issue40428] [C API] Remove PyTuple_ClearFreeList() function (move it
 to the internal C API)
In-Reply-To: <1588107853.55.0.523053148553.issue40428@roundup.psfhosted.org>
Message-ID: <1588120234.59.0.278170791416.issue40428@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Note: I created this issue while working on bpo-40421, when I moved PyFrame_ClearFreeList() definition from Include/frameobject.h to Include/cpython/frameobject.h.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40428>
_______________________________________

From report at bugs.python.org  Tue Apr 28 20:35:48 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Apr 2020 00:35:48 +0000
Subject: [issue40246] Different error messages for same error - invalid string
 prefixes
In-Reply-To: <1586541958.33.0.891000303304.issue40246@roundup.psfhosted.org>
Message-ID: <1588120548.34.0.560009880489.issue40246@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I think that a linter can be very pedantic on such code. My concern is about backward compatibility.

The >else"#fca"< code was added 6 years ago (commit 8b95d5e0bf00d9d0098579d29fd6bb9322071879) and nobody complained, it "just worked". If we keep the SyntaxError, random projects will be broken, but I don't see much benefits for the users.

In short, I concur with Guido :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40246>
_______________________________________

From report at bugs.python.org  Tue Apr 28 20:36:23 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Apr 2020 00:36:23 +0000
Subject: [issue40429] [C API] PyThreadState_GetFrame() and PyFrame_GetCode()
 should return a strong refrence
In-Reply-To: <1588110917.55.0.0908942535567.issue40429@roundup.psfhosted.org>
Message-ID: <1588120583.74.0.460537305451.issue40429@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +19101
pull_request: https://github.com/python/cpython/pull/19781

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40429>
_______________________________________

From report at bugs.python.org  Tue Apr 28 20:43:54 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 29 Apr 2020 00:43:54 +0000
Subject: [issue40334] PEP 617: new PEG-based parser
In-Reply-To: <1587327377.33.0.614039250584.issue40334@roundup.psfhosted.org>
Message-ID: <1588121034.66.0.709839015518.issue40334@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset 37af21b667a9f41437b5b8e451497d7725016df5 by Lysandros Nikolaou in branch 'master':
bpo-40334: Fix shifting of nested f-strings in the new parser (GH-19771)
https://github.com/python/cpython/commit/37af21b667a9f41437b5b8e451497d7725016df5


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40334>
_______________________________________

From report at bugs.python.org  Tue Apr 28 20:45:55 2020
From: report at bugs.python.org (Lysandros Nikolaou)
Date: Wed, 29 Apr 2020 00:45:55 +0000
Subject: [issue40246] Different error messages for same error - invalid string
 prefixes
In-Reply-To: <1586541958.33.0.891000303304.issue40246@roundup.psfhosted.org>
Message-ID: <1588121155.15.0.82173873873.issue40246@roundup.psfhosted.org>


Lysandros Nikolaou <lisandrosnik at gmail.com> added the comment:

A possible solution would be to only emit a SyntaxError if the NAME directly preceding a STRING token contains one of the valid string prefixes (either one of 'f', 'r', 'u', 'b'). This would still output a nicer error message, but would not break code like the one of the example. What do you think about this?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40246>
_______________________________________

From report at bugs.python.org  Tue Apr 28 20:52:53 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Apr 2020 00:52:53 +0000
Subject: [issue39837] Remove Azure Pipelines from GitHub PRs
In-Reply-To: <1583255119.77.0.277327127951.issue39837@roundup.psfhosted.org>
Message-ID: <1588121573.38.0.00390816618373.issue39837@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> Sadly (again), closing/reopening a PR re-runs all CIs. At the first run, GH Action macOS job passed. At the second run, the "Tests" step of GH Action macOS job, but I'm clueless with its logs: (...)

Oops, I looked at two different PRs. In fact, the two CI failures are unrelated.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39837>
_______________________________________

From report at bugs.python.org  Tue Apr 28 21:01:49 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Apr 2020 01:01:49 +0000
Subject: [issue40429] [C API] PyThreadState_GetFrame() and PyFrame_GetCode()
 should return a strong refrence
In-Reply-To: <1588110917.55.0.0908942535567.issue40429@roundup.psfhosted.org>
Message-ID: <1588122109.88.0.803756632734.issue40429@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 4386b9045e5fe1151e65c2816264b5710000eb9f by Victor Stinner in branch 'master':
bpo-40429: PyThreadState_GetFrame() returns a strong ref (GH-19781)
https://github.com/python/cpython/commit/4386b9045e5fe1151e65c2816264b5710000eb9f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40429>
_______________________________________

From report at bugs.python.org  Tue Apr 28 21:04:09 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 29 Apr 2020 01:04:09 +0000
Subject: [issue40334] PEP 617: new PEG-based parser
In-Reply-To: <1587327377.33.0.614039250584.issue40334@roundup.psfhosted.org>
Message-ID: <1588122249.68.0.133520945501.issue40334@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset 2208134918ee673451e4fc525bbeab71142d794a by Pablo Galindo in branch 'master':
bpo-40334: Explicitly cast to int in pegen.c to fix a compiler warning (GH-19779)
https://github.com/python/cpython/commit/2208134918ee673451e4fc525bbeab71142d794a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40334>
_______________________________________

From report at bugs.python.org  Tue Apr 28 21:04:43 2020
From: report at bugs.python.org (hai shi)
Date: Wed, 29 Apr 2020 01:04:43 +0000
Subject: [issue40275] test.support has way too many imports
In-Reply-To: <1586816691.28.0.874442798421.issue40275@roundup.psfhosted.org>
Message-ID: <1588122283.55.0.358796131927.issue40275@roundup.psfhosted.org>


Change by hai shi <shihai1991 at 126.com>:


----------
pull_requests: +19102
pull_request: https://github.com/python/cpython/pull/19761

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40275>
_______________________________________

From report at bugs.python.org  Tue Apr 28 21:11:36 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Apr 2020 01:11:36 +0000
Subject: [issue40275] test.support has way too many imports
In-Reply-To: <1586816691.28.0.874442798421.issue40275@roundup.psfhosted.org>
Message-ID: <1588122696.08.0.480336310108.issue40275@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 66abe98a816de84f89e2de4aa78cf09056227c25 by Hai Shi in branch 'master':
bpo-40275: Move requires_hashdigest() to test.support.hashlib_helper (GH-19716)
https://github.com/python/cpython/commit/66abe98a816de84f89e2de4aa78cf09056227c25


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40275>
_______________________________________

From report at bugs.python.org  Tue Apr 28 21:28:50 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Apr 2020 01:28:50 +0000
Subject: [issue40421] [C API] Add getter functions for PyFrameObject and maybe
 move PyFrameObject to the internal C API
In-Reply-To: <1588079870.34.0.984904607646.issue40421@roundup.psfhosted.org>
Message-ID: <1588123730.26.0.714940242424.issue40421@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 703647732359200c54f1d2e695cc3a06b9a96c9a by Victor Stinner in branch 'master':
bpo-40421: Add PyFrame_GetBack() function (GH-19765)
https://github.com/python/cpython/commit/703647732359200c54f1d2e695cc3a06b9a96c9a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40421>
_______________________________________

From report at bugs.python.org  Tue Apr 28 21:29:21 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Wed, 29 Apr 2020 01:29:21 +0000
Subject: [issue40344] Programming FAQ about "What is the most efficient way to
 concatenate many strings together?" -- Improving the example
In-Reply-To: <1587418050.72.0.944089786988.issue40344@roundup.psfhosted.org>
Message-ID: <1588123761.51.0.408854725134.issue40344@roundup.psfhosted.org>


Change by Batuhan Taskaya <batuhanosmantaskaya at gmail.com>:


----------
keywords: +patch
nosy: +BTaskaya
nosy_count: 4.0 -> 5.0
pull_requests: +19103
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19782

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40344>
_______________________________________

From report at bugs.python.org  Tue Apr 28 21:32:14 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Apr 2020 01:32:14 +0000
Subject: [issue39995] test_concurrent_futures:
 ProcessPoolSpawnExecutorDeadlockTest.test_crash() fails with OSError: [Errno
 9] Bad file descriptor
In-Reply-To: <1584464514.72.0.0566985296328.issue39995@roundup.psfhosted.org>
Message-ID: <1588123934.49.0.0112093433294.issue39995@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset a4dfe8ede5a37576e17035dccfe109ba7752237e by Victor Stinner in branch 'master':
bpo-39995: Fix concurrent.futures _ThreadWakeup (GH-19760)
https://github.com/python/cpython/commit/a4dfe8ede5a37576e17035dccfe109ba7752237e


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39995>
_______________________________________

From report at bugs.python.org  Tue Apr 28 21:32:29 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Wed, 29 Apr 2020 01:32:29 +0000
Subject: [issue40344] Programming FAQ about "What is the most efficient way to
 concatenate many strings together?" -- Improving the example
In-Reply-To: <1587418050.72.0.944089786988.issue40344@roundup.psfhosted.org>
Message-ID: <1588123949.63.0.836776851452.issue40344@roundup.psfhosted.org>


Change by Batuhan Taskaya <batuhanosmantaskaya at gmail.com>:


----------
pull_requests:  -19103

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40344>
_______________________________________

From report at bugs.python.org  Tue Apr 28 21:33:48 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Wed, 29 Apr 2020 01:33:48 +0000
Subject: [issue40344] Programming FAQ about "What is the most efficient way to
 concatenate many strings together?" -- Improving the example
In-Reply-To: <1587418050.72.0.944089786988.issue40344@roundup.psfhosted.org>
Message-ID: <1588124028.1.0.52129508521.issue40344@roundup.psfhosted.org>


Batuhan Taskaya <batuhanosmantaskaya at gmail.com> added the comment:

Sorry for the noise, wrong issue (thought 344, but actually was 334)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40344>
_______________________________________

From report at bugs.python.org  Tue Apr 28 21:34:46 2020
From: report at bugs.python.org (Kyle Stanley)
Date: Wed, 29 Apr 2020 01:34:46 +0000
Subject: [issue40431] turtledemo/__main__.py: SyntaxError: invalid string
 prefix else"#fca"
In-Reply-To: <1588116558.63.0.121077562738.issue40431@roundup.psfhosted.org>
Message-ID: <1588124086.59.0.998136781277.issue40431@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:

> I don't think that it's worth it to backport the change to 3.7 and 3.8: in Python 3.7 and 3.8, the code is accepted.

> Python 3.7 and 3.8 are not broken, so there is no need to fix them :-)

I think we could very reasonably change  `else"#fca"` -> `else "#fca"` on the current bugfix branches, or at least 3.8. Even when it doesn't cause a syntax error and the attempted prefix is ignored, it's still more syntactically correct compared to attempting to use an "e-string" (which of course doesn't exist) and has nearly zero cost on our end to fix. 

While it's a low priority issue since it doesn't raise an error, that doesn't necessarily mean it's correct. In the latest stable version of the stdlib, we should aim to provide a good example IMO, especially if it comes at practically zero cost to us.

----------
nosy: +aeros
resolution: fixed -> 
stage: resolved -> patch review
status: closed -> open
versions: +Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40431>
_______________________________________

From report at bugs.python.org  Tue Apr 28 21:34:47 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Wed, 29 Apr 2020 01:34:47 +0000
Subject: [issue40334] PEP 617: new PEG-based parser
In-Reply-To: <1587327377.33.0.614039250584.issue40334@roundup.psfhosted.org>
Message-ID: <1588124087.05.0.178183963699.issue40334@roundup.psfhosted.org>


Change by Batuhan Taskaya <batuhanosmantaskaya at gmail.com>:


----------
pull_requests: +19104
pull_request: https://github.com/python/cpython/pull/19782

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40334>
_______________________________________

From report at bugs.python.org  Tue Apr 28 21:34:47 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Wed, 29 Apr 2020 01:34:47 +0000
Subject: [issue40344] Programming FAQ about "What is the most efficient way to
 concatenate many strings together?" -- Improving the example
In-Reply-To: <1587418050.72.0.944089786988.issue40344@roundup.psfhosted.org>
Message-ID: <1588124087.2.0.318427486032.issue40344@roundup.psfhosted.org>


Change by Batuhan Taskaya <batuhanosmantaskaya at gmail.com>:


----------
pull_requests: +19105
pull_request: https://github.com/python/cpython/pull/19782

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40344>
_______________________________________

From report at bugs.python.org  Tue Apr 28 21:34:52 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Apr 2020 01:34:52 +0000
Subject: [issue39995] test_concurrent_futures:
 ProcessPoolSpawnExecutorDeadlockTest.test_crash() fails with OSError: [Errno
 9] Bad file descriptor
In-Reply-To: <1584464514.72.0.0566985296328.issue39995@roundup.psfhosted.org>
Message-ID: <1588124092.92.0.144902501542.issue39995@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I'm still getting more and more buildbot emails about test_concurrent_futures, so I merged my PR 19760 to fix buildbots.

Please revert or modify my PR 19760 if you have a better approach, but please check that test_killed_child() and ProcessPoolForkExecutorDeadlockTest tests don't fail with my msg367463 patch.

I would still appreciated a post-commit review of my change, since I don't know well concurrent.futures code :

bpo-39995: Fix concurrent.futures _ThreadWakeup (GH-19760)
https://github.com/python/cpython/commit/a4dfe8ede5a37576e17035dccfe109ba7752237e

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39995>
_______________________________________

From report at bugs.python.org  Tue Apr 28 21:35:35 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Apr 2020 01:35:35 +0000
Subject: [issue40334] PEP 617: new PEG-based parser
In-Reply-To: <1587327377.33.0.614039250584.issue40334@roundup.psfhosted.org>
Message-ID: <1588124135.4.0.680317315596.issue40334@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy:  -vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40334>
_______________________________________

From report at bugs.python.org  Tue Apr 28 21:37:05 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Apr 2020 01:37:05 +0000
Subject: [issue40431] turtledemo/__main__.py: SyntaxError: invalid string
 prefix else"#fca"
In-Reply-To: <1588116558.63.0.121077562738.issue40431@roundup.psfhosted.org>
Message-ID: <1588124225.03.0.487233533545.issue40431@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

If you backport the change, please remove the NEWS entry, since it's not a SyntaxError in 3.7 and 3.8.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40431>
_______________________________________

From report at bugs.python.org  Tue Apr 28 21:38:15 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Wed, 29 Apr 2020 01:38:15 +0000
Subject: [issue40344] Programming FAQ about "What is the most efficient way to
 concatenate many strings together?" -- Improving the example
In-Reply-To: <1587418050.72.0.944089786988.issue40344@roundup.psfhosted.org>
Message-ID: <1588124295.42.0.479975715837.issue40344@roundup.psfhosted.org>


Change by Batuhan Taskaya <batuhanosmantaskaya at gmail.com>:


----------
pull_requests:  -19105

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40344>
_______________________________________

From report at bugs.python.org  Tue Apr 28 21:38:32 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Wed, 29 Apr 2020 01:38:32 +0000
Subject: [issue40344] Programming FAQ about "What is the most efficient way to
 concatenate many strings together?" -- Improving the example
In-Reply-To: <1587418050.72.0.944089786988.issue40344@roundup.psfhosted.org>
Message-ID: <1588124312.66.0.420792859114.issue40344@roundup.psfhosted.org>


Change by Batuhan Taskaya <batuhanosmantaskaya at gmail.com>:


----------
keywords:  -patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40344>
_______________________________________

From report at bugs.python.org  Tue Apr 28 21:38:44 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Wed, 29 Apr 2020 01:38:44 +0000
Subject: [issue40344] Programming FAQ about "What is the most efficient way to
 concatenate many strings together?" -- Improving the example
In-Reply-To: <1587418050.72.0.944089786988.issue40344@roundup.psfhosted.org>
Message-ID: <1588124324.02.0.650240927713.issue40344@roundup.psfhosted.org>


Change by Batuhan Taskaya <batuhanosmantaskaya at gmail.com>:


----------
stage: patch review -> 

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40344>
_______________________________________

From report at bugs.python.org  Tue Apr 28 21:42:31 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 29 Apr 2020 01:42:31 +0000
Subject: [issue40334] PEP 617: new PEG-based parser
In-Reply-To: <1587327377.33.0.614039250584.issue40334@roundup.psfhosted.org>
Message-ID: <1588124551.0.0.80179454712.issue40334@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset 6d6508765514c7c10719478a0430f5e47c9a96ac by Lysandros Nikolaou in branch 'master':
bpo-40334: Disallow invalid single statements in the new parser (GH-19774)
https://github.com/python/cpython/commit/6d6508765514c7c10719478a0430f5e47c9a96ac


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40334>
_______________________________________

From report at bugs.python.org  Tue Apr 28 21:47:02 2020
From: report at bugs.python.org (Kyle Stanley)
Date: Wed, 29 Apr 2020 01:47:02 +0000
Subject: [issue40246] Different error messages for same error - invalid string
 prefixes
In-Reply-To: <1586541958.33.0.891000303304.issue40246@roundup.psfhosted.org>
Message-ID: <1588124822.67.0.373364738522.issue40246@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:

For addressing the backwards compatibility concern, I think we should just convert it to a SyntaxWarning for cases like the above to indicate that it's not really correct syntax, but not harmful enough to justify code breakage. I think it fits the documented description of SyntaxWarning well, which is to address "dubious syntax". 

Lysandros Nikolaou wrote:
> A possible solution would be to only emit a SyntaxError if the NAME directly preceding a STRING token contains one of the valid string prefixes (either one of 'f', 'r', 'u', 'b'). This would still output a nicer error message, but would not break code like the one of the example. What do you think about this?

That would certainly help to minimize the breakage, so I'd be in favor of that over a SyntaxError for all invalid prefixes. But, I'm not certain that it's additionally harmful if an invalid string prefix proceeds a valid one. Is there any additional harm, other than from a visual perspective?

----------
nosy: +aeros

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40246>
_______________________________________

From report at bugs.python.org  Tue Apr 28 22:06:05 2020
From: report at bugs.python.org (Zackery Spytz)
Date: Wed, 29 Apr 2020 02:06:05 +0000
Subject: [issue40428] [C API] Remove PyTuple_ClearFreeList() function (move it
 to the internal C API)
In-Reply-To: <1588107853.55.0.523053148553.issue40428@roundup.psfhosted.org>
Message-ID: <1588125965.66.0.612643345323.issue40428@roundup.psfhosted.org>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
nosy: +ZackerySpytz
nosy_count: 1.0 -> 2.0
pull_requests: +19106
pull_request: https://github.com/python/cpython/pull/19783

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40428>
_______________________________________

From report at bugs.python.org  Tue Apr 28 22:06:42 2020
From: report at bugs.python.org (Kyle Stanley)
Date: Wed, 29 Apr 2020 02:06:42 +0000
Subject: [issue40431] turtledemo/__main__.py: SyntaxError: invalid string
 prefix else"#fca"
In-Reply-To: <1588116558.63.0.121077562738.issue40431@roundup.psfhosted.org>
Message-ID: <1588126002.29.0.976755590065.issue40431@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:

Victor Stinner wrote:
> If you backport the change, please remove the NEWS entry, since it's not a SyntaxError in 3.7 and 3.8.

Good point. In that case, I'll do a manual backport of the PR just to 3.8 and skip the news entry. As mentioned above, I think most of the value in fixing it when the SyntaxError isn't present is mainly just for providing a good example in the latest stable version of the stdlib, so I don't think there would be much additional value in also backporting it to 3.7.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40431>
_______________________________________

From report at bugs.python.org  Tue Apr 28 22:07:55 2020
From: report at bugs.python.org (Kyle Stanley)
Date: Wed, 29 Apr 2020 02:07:55 +0000
Subject: [issue40431] turtledemo/__main__.py: SyntaxError: invalid string
 prefix else"#fca"
In-Reply-To: <1588116558.63.0.121077562738.issue40431@roundup.psfhosted.org>
Message-ID: <1588126075.77.0.407450655933.issue40431@roundup.psfhosted.org>


Change by Kyle Stanley <aeros167 at gmail.com>:


----------
versions:  -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40431>
_______________________________________

From report at bugs.python.org  Tue Apr 28 22:31:00 2020
From: report at bugs.python.org (Kyle Stanley)
Date: Wed, 29 Apr 2020 02:31:00 +0000
Subject: [issue40431] turtledemo/__main__.py: SyntaxError: invalid string
 prefix else"#fca"
In-Reply-To: <1588116558.63.0.121077562738.issue40431@roundup.psfhosted.org>
Message-ID: <1588127460.94.0.284819556919.issue40431@roundup.psfhosted.org>


Change by Kyle Stanley <aeros167 at gmail.com>:


----------
pull_requests: +19107
pull_request: https://github.com/python/cpython/pull/19784

_______________________________________
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: [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:38:28 2020
From: report at bugs.python.org (anthony shaw)
Date: Wed, 29 Apr 2020 02:38:28 +0000
Subject: [issue40432] Pegen regenerate project for Windows not working
In-Reply-To: <1588127830.15.0.595745305392.issue40432@roundup.psfhosted.org>
Message-ID: <1588127908.56.0.478318166422.issue40432@roundup.psfhosted.org>


Change by anthony shaw <anthonyshaw at apache.org>:


----------
keywords: +patch
pull_requests: +19108
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19785

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40432>
_______________________________________

From report at bugs.python.org  Tue Apr 28 22:39:57 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Wed, 29 Apr 2020 02:39:57 +0000
Subject: [issue39995] test_concurrent_futures:
 ProcessPoolSpawnExecutorDeadlockTest.test_crash() fails with OSError: [Errno
 9] Bad file descriptor
In-Reply-To: <1584464514.72.0.0566985296328.issue39995@roundup.psfhosted.org>
Message-ID: <1588127997.86.0.724520161745.issue39995@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
nosy: +corona10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39995>
_______________________________________

From report at bugs.python.org  Tue Apr 28 22:41:59 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Apr 2020 02:41:59 +0000
Subject: [issue40428] [C API] Remove PyTuple_ClearFreeList() function (move it
 to the internal C API)
In-Reply-To: <1588107853.55.0.523053148553.issue40428@roundup.psfhosted.org>
Message-ID: <1588128119.66.0.18666305408.issue40428@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset bb4a585d903e7fe0a46ded8c2ee3f47435ad6a66 by Zackery Spytz in branch 'master':
bpo-40428: Remove references to Py*_ClearFreeList in the docs (GH-19783)
https://github.com/python/cpython/commit/bb4a585d903e7fe0a46ded8c2ee3f47435ad6a66


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40428>
_______________________________________

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: [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  Tue Apr 28 23:00:37 2020
From: report at bugs.python.org (Kyle Stanley)
Date: Wed, 29 Apr 2020 03:00:37 +0000
Subject: [issue39995] test_concurrent_futures:
 ProcessPoolSpawnExecutorDeadlockTest.test_crash() fails with OSError: [Errno
 9] Bad file descriptor
In-Reply-To: <1584464514.72.0.0566985296328.issue39995@roundup.psfhosted.org>
Message-ID: <1588129237.59.0.319816602011.issue39995@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:

I am a bit concerned about the performance implication of accessing the thread wakeup through a lock in the call queue, but for now I think it's reasonable to address the buildbot failure with a locking solution while we try to find a better one.

I'm not certain if we'll be able to find one that correctly addresses the failures with zero additional locking, but I think we may be able to reduce the number of times we use the lock compared to the implementation in GH-19760. I'll spend some time exploring that as I find the time to, and report back with any significant findings.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39995>
_______________________________________

From report at bugs.python.org  Tue Apr 28 23:05:55 2020
From: report at bugs.python.org (Kyle Stanley)
Date: Wed, 29 Apr 2020 03:05:55 +0000
Subject: [issue39995] test_concurrent_futures:
 ProcessPoolSpawnExecutorDeadlockTest.test_crash() fails with OSError: [Errno
 9] Bad file descriptor
In-Reply-To: <1584464514.72.0.0566985296328.issue39995@roundup.psfhosted.org>
Message-ID: <1588129555.15.0.432880088175.issue39995@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:

Also, thanks to Victor for coming up with an interim solution, and for the feedback from Antoine and Thomas. GH-19760 is a significant improvement from my initial proposal in GH-19751.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39995>
_______________________________________

From report at bugs.python.org  Tue Apr 28 23:11:24 2020
From: report at bugs.python.org (Kyle Stanley)
Date: Wed, 29 Apr 2020 03:11:24 +0000
Subject: [issue40431] turtledemo/__main__.py: SyntaxError: invalid string
 prefix else"#fca"
In-Reply-To: <1588116558.63.0.121077562738.issue40431@roundup.psfhosted.org>
Message-ID: <1588129884.9.0.657813897282.issue40431@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:


New changeset cc011b5190b63f0be561ddec38fc4cd9e60cbf6a by Kyle Stanley in branch '3.8':
[3.8] bpo-40431: Fix syntax typo in turtledemo (GH-19777) (#19784)
https://github.com/python/cpython/commit/cc011b5190b63f0be561ddec38fc4cd9e60cbf6a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40431>
_______________________________________

From report at bugs.python.org  Tue Apr 28 23:15:51 2020
From: report at bugs.python.org (Kyle Stanley)
Date: Wed, 29 Apr 2020 03:15:51 +0000
Subject: [issue40431] turtledemo/__main__.py: SyntaxError: invalid string
 prefix else"#fca"
In-Reply-To: <1588116558.63.0.121077562738.issue40431@roundup.psfhosted.org>
Message-ID: <1588130151.85.0.196091745967.issue40431@roundup.psfhosted.org>


Change by Kyle Stanley <aeros167 at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40431>
_______________________________________

From report at bugs.python.org  Tue Apr 28 23:37:05 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 29 Apr 2020 03:37:05 +0000
Subject: [issue40317] inspect.getsource() examines incorrect target
In-Reply-To: <1587210637.54.0.0432450975105.issue40317@roundup.psfhosted.org>
Message-ID: <1588131425.73.0.603383631752.issue40317@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

yes, thanks Ammar. Thanks Grzegorz for the report.

----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> inspect.getsource returns incorrect source for classes when class definition is part of multiline strings
versions: +Python 3.9 -Python 2.7, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40317>
_______________________________________

From report at bugs.python.org  Tue Apr 28 23:59:29 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 29 Apr 2020 03:59:29 +0000
Subject: [issue35113] inspect.getsource returns incorrect source for classes
 when class definition is part of multiline strings
In-Reply-To: <1540902777.26.0.788709270274.issue35113@psf.upfronthosting.co.za>
Message-ID: <1588132769.43.0.326879117981.issue35113@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Closing this as fixed with the enhancement to show decorator for classes too for 3.9. Thank you all for the help on this.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.9 -Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35113>
_______________________________________

From report at bugs.python.org  Tue Apr 28 23:59:48 2020
From: report at bugs.python.org (Kyle Stanley)
Date: Wed, 29 Apr 2020 03:59:48 +0000
Subject: [issue40405] asyncio.as_completed documentation misleading
In-Reply-To: <1587986090.72.0.850288416668.issue40405@roundup.psfhosted.org>
Message-ID: <1588132788.35.0.123489634142.issue40405@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:

Yury Selivanov wrote:
> I'd suggest to change to: "Return an iterator of coroutines.  Each coroutine allows to wait for the earliest next result from the set of the remaining awaitables."

The first sentence looks good to me, but I'm not certain about the second sentence, particularly "allows to wait". Instead, I'm thinking something like this might read better:

"Each coroutine represents the earliest next result from the set of the remaining awaitables, based upon the order of completion."

Thoughts?

----------
nosy: +aeros

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40405>
_______________________________________

From report at bugs.python.org  Wed Apr 29 00:11:31 2020
From: report at bugs.python.org (Kyle Stanley)
Date: Wed, 29 Apr 2020 04:11:31 +0000
Subject: [issue40405] asyncio.as_completed documentation misleading
In-Reply-To: <1587986090.72.0.850288416668.issue40405@roundup.psfhosted.org>
Message-ID: <1588133491.23.0.264346625129.issue40405@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:

> based upon the order of completion

I forgot to explain this in the above message. I think something that mentions "order of completion" should be included. Although it's implied in the name `as_completed`, to me it seems worthwhile to be fully explicit with what exactly is meant by "earliest".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40405>
_______________________________________

From report at bugs.python.org  Wed Apr 29 00:16:28 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 29 Apr 2020 04:16:28 +0000
Subject: [issue25597] unittest.mock does not wrap dunder methods (__getitem__
 etc)
In-Reply-To: <1447174958.96.0.448093662654.issue25597@psf.upfronthosting.co.za>
Message-ID: <1588133788.69.0.05624750954.issue25597@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

The change has been reverted as per issue39966. I am reopening this for further discussion.

----------
resolution: fixed -> 
stage: resolved -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25597>
_______________________________________

From report at bugs.python.org  Wed Apr 29 00:18:01 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 29 Apr 2020 04:18:01 +0000
Subject: [issue39966] mock 3.9 bug: Wrapped objects without __bool__ raise
 exception
In-Reply-To: <1584254384.28.0.0187140133308.issue39966@roundup.psfhosted.org>
Message-ID: <1588133881.27.0.478107857818.issue39966@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Thanks Avram for the report. I have reopened issue25597. Closing this as the regression change has been reverted for 3.9.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39966>
_______________________________________

From report at bugs.python.org  Wed Apr 29 00:20:47 2020
From: report at bugs.python.org (Kyle Stanley)
Date: Wed, 29 Apr 2020 04:20:47 +0000
Subject: [issue40405] asyncio.as_completed documentation misleading
In-Reply-To: <1587986090.72.0.850288416668.issue40405@roundup.psfhosted.org>
Message-ID: <1588134047.8.0.250668440902.issue40405@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:

Alternatively, I think "can wait for" would also read better than "allows to wait for", if that is preferred over my above suggestion.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40405>
_______________________________________

From report at bugs.python.org  Wed Apr 29 00:58:05 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 29 Apr 2020 04:58:05 +0000
Subject: [issue40405] asyncio.as_completed documentation misleading
In-Reply-To: <1587986090.72.0.850288416668.issue40405@roundup.psfhosted.org>
Message-ID: <1588136285.07.0.113727981676.issue40405@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

Please work this out in the PR between the two of you, Kyle and Bar.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40405>
_______________________________________

From report at bugs.python.org  Wed Apr 29 01:17:21 2020
From: report at bugs.python.org (hai shi)
Date: Wed, 29 Apr 2020 05:17:21 +0000
Subject: [issue39837] Remove Azure Pipelines from GitHub PRs
In-Reply-To: <1583255119.77.0.277327127951.issue39837@roundup.psfhosted.org>
Message-ID: <1588137441.71.0.231952335115.issue39837@roundup.psfhosted.org>


hai shi <shihai1991 at 126.com> added the comment:

> Sadly (again), closing/reopening a PR re-runs all CIs. At the first run, GH Action macOS job passed. At the second run, the "Tests" step of GH Action macOS job, but I'm clueless with its logs: (...)

Oh, I encountered the same trouble twice :(
https://github.com/python/cpython/runs/628458496

----------
nosy: +shihai1991

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39837>
_______________________________________

From report at bugs.python.org  Wed Apr 29 02:50:26 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 29 Apr 2020 06:50:26 +0000
Subject: [issue40246] Different error messages for same error - invalid string
 prefixes
In-Reply-To: <1586541958.33.0.891000303304.issue40246@roundup.psfhosted.org>
Message-ID: <1588143026.33.0.131407604819.issue40246@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

> It's no different from other edge cases where for some reason the space seems optional, like `1and 2`.

The parser is not consistent here. `0or[]` is an error, while `0and[]` and `1or[]` are valid. See https://mail.python.org/archives/list/python-dev at python.org/message/D2WPCITHG2LBQAP7DBTC6CY26WQUBAKP/

> A possible solution would be to only emit a SyntaxError if the NAME directly preceding a STRING token contains one of the valid string prefixes (either one of 'f', 'r', 'u', 'b').

This would not help for `if'a'<=x<='z'`. And we will get more breakage when add more string prefixes.

We should either require a whitespace between an identifier and a string literal (with SyntaxWarning in meantime) or allow to omit it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40246>
_______________________________________

From report at bugs.python.org  Wed Apr 29 03:22:35 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 29 Apr 2020 07:22:35 +0000
Subject: [issue40334] PEP 617: new PEG-based parser
In-Reply-To: <1587327377.33.0.614039250584.issue40334@roundup.psfhosted.org>
Message-ID: <1588144955.04.0.876637586512.issue40334@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +19109
pull_request: https://github.com/python/cpython/pull/19786

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40334>
_______________________________________

From report at bugs.python.org  Wed Apr 29 03:36:26 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 29 Apr 2020 07:36:26 +0000
Subject: [issue40275] test.support has way too many imports
In-Reply-To: <1586816691.28.0.874442798421.issue40275@roundup.psfhosted.org>
Message-ID: <1588145786.67.0.91018444248.issue40275@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset bfb1cf44658934cbcd9707fb717d6770c78fbeb3 by Serhiy Storchaka in branch 'master':
bpo-40275: Move transient_internet from test.support to socket_helper (GH-19711)
https://github.com/python/cpython/commit/bfb1cf44658934cbcd9707fb717d6770c78fbeb3


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40275>
_______________________________________

From report at bugs.python.org  Wed Apr 29 03:48:15 2020
From: report at bugs.python.org (Bar Harel)
Date: Wed, 29 Apr 2020 07:48:15 +0000
Subject: [issue40405] asyncio.as_completed documentation misleading
In-Reply-To: <1587986090.72.0.850288416668.issue40405@roundup.psfhosted.org>
Message-ID: <1588146495.37.0.401949489014.issue40405@roundup.psfhosted.org>


Bar Harel <bzvi7919 at gmail.com> added the comment:

@Kyle, looks good to me. Maybe this will work better? Together with the current example which shows the "earliest_result" variable of course.

"Each coroutine returns the next result from the set of the remaining awaitables, based upon the order of completion."

Represents -> Returns (less obscure, and coroutines are awaited on to get the result)
Earliest -> removed, "order  of completion" looks great.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40405>
_______________________________________

From report at bugs.python.org  Wed Apr 29 04:02:04 2020
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 29 Apr 2020 08:02:04 +0000
Subject: [issue39995] test_concurrent_futures:
 ProcessPoolSpawnExecutorDeadlockTest.test_crash() fails with OSError: [Errno
 9] Bad file descriptor
In-Reply-To: <1584464514.72.0.0566985296328.issue39995@roundup.psfhosted.org>
Message-ID: <1588147324.28.0.700669341588.issue39995@roundup.psfhosted.org>


Antoine Pitrou <solipsis at pitrou.net> added the comment:

I looked at the change and it seemed ok to me. Perhaps Thomas can give it a look too.

----------
assignee: aeros -> vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39995>
_______________________________________

From report at bugs.python.org  Wed Apr 29 04:20:15 2020
From: report at bugs.python.org (Thomas Moreau)
Date: Wed, 29 Apr 2020 08:20:15 +0000
Subject: [issue39995] test_concurrent_futures:
 ProcessPoolSpawnExecutorDeadlockTest.test_crash() fails with OSError: [Errno
 9] Bad file descriptor
In-Reply-To: <1584464514.72.0.0566985296328.issue39995@roundup.psfhosted.org>
Message-ID: <1588148415.2.0.903732704632.issue39995@roundup.psfhosted.org>


Thomas Moreau <thomas.moreau.2010 at gmail.com> added the comment:

I think this is a reasonable way to move on.Some of the locks can probably be removed but this needs careful investigation and in the mean time, it hinders everyone. Thanks victor for the fast fix up! 

To me, an interesting observation is that the failure seems to only happen when the executor is in broken state. If we can find a way to adapt the behavior to be more conservative on these states (which are not impacting perf) that would be nice.

I will try to look at it today and see if I can remove some of the locks while still not failing with Victor's patch. We can probably remove the lock on `clear` safely. For the others, it might be more complex.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39995>
_______________________________________

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: [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 04:32:18 2020
From: report at bugs.python.org (Ama Aje My Fren)
Date: Wed, 29 Apr 2020 08:32:18 +0000
Subject: [issue40434] Update of reasoning why there is no case statement
In-Reply-To: <1588148867.59.0.249886730635.issue40434@roundup.psfhosted.org>
Message-ID: <1588149138.6.0.985796639359.issue40434@roundup.psfhosted.org>


Change by Ama Aje My Fren <amaajemyfren at gmail.com>:


----------
keywords: +patch
pull_requests: +19110
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19787

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40434>
_______________________________________

From report at bugs.python.org  Wed Apr 29 04:33:46 2020
From: report at bugs.python.org (Ama Aje My Fren)
Date: Wed, 29 Apr 2020 08:33:46 +0000
Subject: [issue40434] Update of reasoning why there is no case statement
In-Reply-To: <1588148867.59.0.249886730635.issue40434@roundup.psfhosted.org>
Message-ID: <1588149226.7.0.687405346297.issue40434@roundup.psfhosted.org>


Change by Ama Aje My Fren <amaajemyfren at gmail.com>:


----------
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40434>
_______________________________________

From report at bugs.python.org  Wed Apr 29 05:09:25 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 29 Apr 2020 09:09:25 +0000
Subject: [issue40432] Pegen regenerate project for Windows not working
In-Reply-To: <1588127830.15.0.595745305392.issue40432@roundup.psfhosted.org>
Message-ID: <1588151365.57.0.343471201862.issue40432@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset 9b64ef3ac7b434065dbff0048b9103999e4b491a by Anthony Shaw in branch 'master':
bpo-40432 Fix MSBuild project for Pegen grammars (#GH-9785)
https://github.com/python/cpython/commit/9b64ef3ac7b434065dbff0048b9103999e4b491a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40432>
_______________________________________

From report at bugs.python.org  Wed Apr 29 05:20:04 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 29 Apr 2020 09:20:04 +0000
Subject: [issue40432] Pegen regenerate project for Windows not working
In-Reply-To: <1588127830.15.0.595745305392.issue40432@roundup.psfhosted.org>
Message-ID: <1588152004.27.0.85484177578.issue40432@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40432>
_______________________________________

From report at bugs.python.org  Wed Apr 29 05:23:39 2020
From: report at bugs.python.org (Thomas Moreau)
Date: Wed, 29 Apr 2020 09:23:39 +0000
Subject: [issue39995] test_concurrent_futures:
 ProcessPoolSpawnExecutorDeadlockTest.test_crash() fails with OSError: [Errno
 9] Bad file descriptor
In-Reply-To: <1584464514.72.0.0566985296328.issue39995@roundup.psfhosted.org>
Message-ID: <1588152219.13.0.00343184717493.issue39995@roundup.psfhosted.org>


Change by Thomas Moreau <thomas.moreau.2010 at gmail.com>:


----------
pull_requests: +19111
pull_request: https://github.com/python/cpython/pull/19788

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39995>
_______________________________________

From report at bugs.python.org  Wed Apr 29 05:24:33 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 29 Apr 2020 09:24:33 +0000
Subject: [issue40431] turtledemo/__main__.py: SyntaxError: invalid string
 prefix else"#fca"
In-Reply-To: <1588116558.63.0.121077562738.issue40431@roundup.psfhosted.org>
Message-ID: <1588152273.6.0.867243480338.issue40431@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
nosy: +miss-islington
nosy_count: 4.0 -> 5.0
pull_requests: +19112
pull_request: https://github.com/python/cpython/pull/19789

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40431>
_______________________________________

From report at bugs.python.org  Wed Apr 29 05:27:53 2020
From: report at bugs.python.org (Thomas Moreau)
Date: Wed, 29 Apr 2020 09:27:53 +0000
Subject: [issue39995] test_concurrent_futures:
 ProcessPoolSpawnExecutorDeadlockTest.test_crash() fails with OSError: [Errno
 9] Bad file descriptor
In-Reply-To: <1584464514.72.0.0566985296328.issue39995@roundup.psfhosted.org>
Message-ID: <1588152473.34.0.910131496927.issue39995@roundup.psfhosted.org>


Thomas Moreau <thomas.moreau.2010 at gmail.com> added the comment:

I did GH 19788 with a few modifications. There is only one lock that seems to mater for the perf, and I actually added one other (the one in _python_exit, which necessitate another bug fix for fork context).

I did not benchmark to see if it was worth it in term of perf.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39995>
_______________________________________

From report at bugs.python.org  Wed Apr 29 05:39:14 2020
From: report at bugs.python.org (Petr Viktorin)
Date: Wed, 29 Apr 2020 09:39:14 +0000
Subject: [issue38787] PEP 573: Module State Access from C Extension Methods
In-Reply-To: <1573655440.57.0.563143759574.issue38787@roundup.psfhosted.org>
Message-ID: <1588153154.39.0.23866428339.issue38787@roundup.psfhosted.org>


Petr Viktorin <encukou at gmail.com> added the comment:

I'm working on the implementation as my time allows, here: https://github.com/encukou/cpython/pull/3 .

Would it help to create a proper PR for CPython now? That would mean I could no longer do rebases/force-pushes, so the commits would be less readable. But happy to do it if it would help you.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38787>
_______________________________________

From report at bugs.python.org  Wed Apr 29 05:42:31 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 29 Apr 2020 09:42:31 +0000
Subject: [issue40334] PEP 617: new PEG-based parser
In-Reply-To: <1587327377.33.0.614039250584.issue40334@roundup.psfhosted.org>
Message-ID: <1588153351.28.0.815272789718.issue40334@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset 4db245ee9ddbe6c53d375de59a35ff59dea2a8e0 by Pablo Galindo in branch 'master':
bpo-40334: refactor and cleanup for the PEG generators (GH-19775)
https://github.com/python/cpython/commit/4db245ee9ddbe6c53d375de59a35ff59dea2a8e0


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40334>
_______________________________________

From report at bugs.python.org  Wed Apr 29 05:42:31 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 29 Apr 2020 09:42:31 +0000
Subject: [issue40431] turtledemo/__main__.py: SyntaxError: invalid string
 prefix else"#fca"
In-Reply-To: <1588116558.63.0.121077562738.issue40431@roundup.psfhosted.org>
Message-ID: <1588153351.42.0.211943256312.issue40431@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset adb1f853482e75e81ae0ae7307318a1051ca46b5 by Miss Islington (bot) in branch '3.7':
[3.8] bpo-40431: Fix syntax typo in turtledemo (GH-19777) (GH-19784)
https://github.com/python/cpython/commit/adb1f853482e75e81ae0ae7307318a1051ca46b5


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40431>
_______________________________________

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: [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 06:27:09 2020
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Wed, 29 Apr 2020 10:27:09 +0000
Subject: [issue40402] Race condition in multiprocessing/connection.py: broken
 handle
In-Reply-To: <1587954709.44.0.390905431083.issue40402@roundup.psfhosted.org>
Message-ID: <1588156029.09.0.311784564117.issue40402@roundup.psfhosted.org>


Change by R?mi Lapeyre <remi.lapeyre at henki.fr>:


----------
keywords: +patch
pull_requests: +19113
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/19790

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40402>
_______________________________________

From report at bugs.python.org  Wed Apr 29 07:12:49 2020
From: report at bugs.python.org (Danya Alexeyevsky)
Date: Wed, 29 Apr 2020 11:12:49 +0000
Subject: [issue33428] pathlib.Path.glob does not follow symlinks
In-Reply-To: <1525501380.69.0.682650639539.issue33428@psf.upfronthosting.co.za>
Message-ID: <1588158769.42.0.164383179637.issue33428@roundup.psfhosted.org>


Danya Alexeyevsky <me.dendik at gmail.com> added the comment:

I can reproduce the bug with Linux and python 3.7.5:

```
Python 3.7.5 (default, Apr 19 2020, 20:18:17) 
[GCC 9.2.1 20191008] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from pathlib import Path
>>> Path('a/b').mkdir(parents=True)
>>> Path('c/d').mkdir(parents=True)
>>> Path('a/c').symlink_to('../c')
>>> Path('e').symlink_to('c')
>>> list(Path('.').rglob('*'))
[PosixPath('e'), PosixPath('c'), PosixPath('a'), PosixPath('c/d'), PosixPath('a/c'), PosixPath('a/b')]
```

Expected result:

```
[PosixPath('e'), PosixPath('e/d'), PosixPath('c'), PosixPath('a'), PosixPath('c/d'), PosixPath('a/c'), PosixPath('a/c/d'), PosixPath('a/b')]
```

----------
nosy: +Danya.Alexeyevsky

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33428>
_______________________________________

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: [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 07:47:35 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 29 Apr 2020 11:47:35 +0000
Subject: [issue40435] Failed to launch IDLE in a UTF-8 code page terminal
 environment
In-Reply-To: <1588154736.32.0.92562314697.issue40435@roundup.psfhosted.org>
Message-ID: <1588160855.88.0.909445353613.issue40435@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

The uploaded .png has the traceback.  (Pasting it into the post would have been fine and a bit easier for all of us.)  The error occurred when IDLE's config tried to load the user config files, ~/.idlerc/config-xyz.cfg. (~ is usually C:/Users/yourname.)  configparser.read opens the files with the default 'encoding=None', which uses the current system default. This failed with the error given.  Either there is a byte error in one of the files or you customized IDLE with a non-ascii character before switching to utf-8, if indeed you switched.

In either case, the reading error does not appear to be an IDLE bug.  However, IDLE should catch UnicodeDecodeError, tell the user which file could not be read and how it failed, and move on as if it were not there.

Serhiy: Codec CP_UTF8 is not listed in https://docs.python.org/3.7/library/codecs.html#standard-encodings.  Should it be? Any other comments?

??: On my American machine, I can open Control Panel, select Clock and Region, Region, Administrative tab, and there is a button for 'Change system local...'.  It pops up a box with a checkbox "[] Beta: Use Unicode UTF8 for worldwide language support."  Is this what you meant, and/or what you did?

If the user config files were only written by IDLE, they could always be uft-8 encoded.  However, users were once told to edit by hand, and there are still cased when they do, and for some things like loading custom keysets, it is quite appropriate.

----------
stage:  -> test needed
type: crash -> behavior
versions: +Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40435>
_______________________________________

From report at bugs.python.org  Wed Apr 29 07:58:05 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 29 Apr 2020 11:58:05 +0000
Subject: [issue40435] IDLE should catch user config file UnicodeDecodeError
In-Reply-To: <1588154736.32.0.92562314697.issue40435@roundup.psfhosted.org>
Message-ID: <1588161485.7.0.672520420983.issue40435@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
title: Failed to launch IDLE in a UTF-8 code page terminal environment -> IDLE should catch user config file UnicodeDecodeError

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40435>
_______________________________________

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: [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 08:53:29 2020
From: report at bugs.python.org (=?utf-8?b?5bem6L+f?=)
Date: Wed, 29 Apr 2020 12:53:29 +0000
Subject: [issue40435] IDLE should catch user config file UnicodeDecodeError
In-Reply-To: <1588154736.32.0.92562314697.issue40435@roundup.psfhosted.org>
Message-ID: <1588164809.84.0.0560351310156.issue40435@roundup.psfhosted.org>


?? <luckychizuo at gmail.com> added the comment:

Hi!
Thanks for your useful comment. And I'm sorry for uploading the image but not pasting it in the comment.
When I append "encoding=utf-8" to ~/.idlerc/config-main.cfg, the idle turns to be good and works well.
Yes, the "[] Beta: Use Unicode UTF8 for worldwide language support" is what I mean.
The reason why I raise this issue is there is no searching results for this error messgae.
In fact, my OS language is Chinese. And I tick the beta UTF8 option manually. It seems like that causes the IDLE crash.
Really thanks for your help!
Best Regards, Chi.

----------
resolution:  -> not a bug
stage: test needed -> resolved
status: open -> closed
versions:  -Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40435>
_______________________________________

From report at bugs.python.org  Wed Apr 29 09:56:05 2020
From: report at bugs.python.org (kuzja)
Date: Wed, 29 Apr 2020 13:56:05 +0000
Subject: [issue40395] Scripts folder is Empty in python 3.8.2 for Windows 7.
In-Reply-To: <1587910690.73.0.0218819691356.issue40395@roundup.psfhosted.org>
Message-ID: <1588168565.56.0.631545676253.issue40395@roundup.psfhosted.org>


kuzja <kuzja at atlas.cz> added the comment:

Here the same problem occurred when installing Python in Win7 Pro. Both standard and custom (with pip checked) installations lead to the same result (i.e. the empty Scripts folder).
It seems that the problem originates somewhere between Python 3.6 and 3.7, as 3.7 suffers from the same problem too, while 3.6 installed correctly.

----------
nosy: +kuzja

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40395>
_______________________________________

From report at bugs.python.org  Wed Apr 29 10:07:57 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Apr 2020 14:07:57 +0000
Subject: [issue40436] pythoninfo collect_gdb() blows up when gdb fails to run
In-Reply-To: <1588160205.58.0.824942554925.issue40436@roundup.psfhosted.org>
Message-ID: <1588169277.15.0.701129344236.issue40436@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
keywords: +patch
pull_requests: +19114
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19792

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40436>
_______________________________________

From report at bugs.python.org  Wed Apr 29 10:08:17 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 29 Apr 2020 14:08:17 +0000
Subject: [issue40437] add string.snake function
In-Reply-To: <1588164532.34.0.674721156435.issue40437@roundup.psfhosted.org>
Message-ID: <1588169297.62.0.655411352086.issue40437@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

What would be the full specification of this? If you want to use it for column names, what happens if the string starts with a $, or some character that can't be used by your particular database?

I'm skeptical that this could be general purpose enough to be used in a wide range of situations, without having a dozen or so parameters to it.

I'm thinking of things like:
- ascii-only?
- result must be a valid python identifier
- certain special characters not allowed anywhere
- certain other special characters not allowed at the start of the string

etc.

We'd need a full specification before deciding to accept this.

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40437>
_______________________________________

From report at bugs.python.org  Wed Apr 29 10:09:28 2020
From: report at bugs.python.org (=?utf-8?q?Miro_Hron=C4=8Dok?=)
Date: Wed, 29 Apr 2020 14:09:28 +0000
Subject: [issue40436] pythoninfo collect_gdb() blows up when gdb fails to run
In-Reply-To: <1588160205.58.0.824942554925.issue40436@roundup.psfhosted.org>
Message-ID: <1588169368.25.0.19845291665.issue40436@roundup.psfhosted.org>


Miro Hron?ok <miro at hroncok.cz> added the comment:

BTW The test gdb also crashes in the same way:

test test_gdb crashed -- Traceback (most recent call last):
  File "/builddir/build/BUILD/Python-3.9.0a6/Lib/test/libregrtest/runtest.py", line 270, in _runtest_inner
    refleak = _runtest_inner2(ns, test_name)
  File "/builddir/build/BUILD/Python-3.9.0a6/Lib/test/libregrtest/runtest.py", line 221, in _runtest_inner2
    the_module = importlib.import_module(abstest)
  File "/builddir/build/BUILD/Python-3.9.0a6/Lib/importlib/__init__.py", line 127, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "<frozen importlib._bootstrap>", line 1030, in _gcd_import
  File "<frozen importlib._bootstrap>", line 1007, in _find_and_load
  File "<frozen importlib._bootstrap>", line 986, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 680, in _load_unlocked
  File "<frozen importlib._bootstrap_external>", line 790, in exec_module
  File "<frozen importlib._bootstrap>", line 228, in _call_with_frames_removed
  File "/builddir/build/BUILD/Python-3.9.0a6/Lib/test/test_gdb.py", line 41, in <module>
    gdb_version, gdb_major_version, gdb_minor_version = get_gdb_version()
  File "/builddir/build/BUILD/Python-3.9.0a6/Lib/test/test_gdb.py", line 38, in get_gdb_version
    raise Exception("unable to parse GDB version: %r" % version)
Exception: unable to parse GDB version: ''

1 test failed again:
    test_gdb

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40436>
_______________________________________

From report at bugs.python.org  Wed Apr 29 10:21:03 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Apr 2020 14:21:03 +0000
Subject: [issue40428] [C API] Remove PyTuple_ClearFreeList() function (move it
 to the internal C API)
In-Reply-To: <1588107853.55.0.523053148553.issue40428@roundup.psfhosted.org>
Message-ID: <1588170063.12.0.993227733252.issue40428@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +19115
pull_request: https://github.com/python/cpython/pull/19793

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40428>
_______________________________________

From report at bugs.python.org  Wed Apr 29 10:37:55 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Apr 2020 14:37:55 +0000
Subject: [issue40431] turtledemo/__main__.py: SyntaxError: invalid string
 prefix else"#fca"
In-Reply-To: <1588116558.63.0.121077562738.issue40431@roundup.psfhosted.org>
Message-ID: <1588171075.04.0.342420307355.issue40431@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Ok, the typo is now fixed in 3.7, 3.8 and master branches ;-) Thanks Miro for the bug reportand Kyle for the backport.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40431>
_______________________________________

From report at bugs.python.org  Wed Apr 29 10:52:34 2020
From: report at bugs.python.org (Petr Viktorin)
Date: Wed, 29 Apr 2020 14:52:34 +0000
Subject: [issue40246] Different error messages for same error - invalid string
 prefixes
In-Reply-To: <1586541958.33.0.891000303304.issue40246@roundup.psfhosted.org>
Message-ID: <1588171954.65.0.315040066624.issue40246@roundup.psfhosted.org>


Petr Viktorin <encukou at gmail.com> added the comment:

reportlab reported failures on code like:

norm=lambda m: m+(m and(m[-1]!='\n'and'\n'or'')or'\n')

Note that `or` has a `r` in it.

----------
nosy: +petr.viktorin

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40246>
_______________________________________

From report at bugs.python.org  Wed Apr 29 10:56:34 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Apr 2020 14:56:34 +0000
Subject: [issue40428] [C API] Remove PyTuple_ClearFreeList() function (move it
 to the internal C API)
In-Reply-To: <1588107853.55.0.523053148553.issue40428@roundup.psfhosted.org>
Message-ID: <1588172194.23.0.370120119485.issue40428@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 9a8c1315c3041fdb85d091bb8dc92f0d9dcb1529 by Victor Stinner in branch 'master':
bpo-40428: Cleanup free list part of C API Changes doc (GH-19793)
https://github.com/python/cpython/commit/9a8c1315c3041fdb85d091bb8dc92f0d9dcb1529


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40428>
_______________________________________

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: [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:05:44 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Wed, 29 Apr 2020 15:05:44 +0000
Subject: [issue40438] Python 3.9 eval on list comprehension sometimes returns
 coroutines
In-Reply-To: <1588172525.03.0.278979936503.issue40438@roundup.psfhosted.org>
Message-ID: <1588172744.29.0.517691160382.issue40438@roundup.psfhosted.org>


Change by Batuhan Taskaya <batuhanosmantaskaya at gmail.com>:


----------
nosy: +BTaskaya

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40438>
_______________________________________

From report at bugs.python.org  Wed Apr 29 11:11:26 2020
From: report at bugs.python.org (Jonathan Crall)
Date: Wed, 29 Apr 2020 15:11:26 +0000
Subject: [issue40438] Python 3.9 eval on list comprehension sometimes returns
 coroutines
In-Reply-To: <1588172525.03.0.278979936503.issue40438@roundup.psfhosted.org>
Message-ID: <1588173086.19.0.68465358403.issue40438@roundup.psfhosted.org>


Jonathan Crall <erotemic at gmail.com> added the comment:

Ah, sorry. I neglected all the important information. 

I tested this using: 

Python 3.9.0a5 (default, Apr 23 2020, 14:11:34) 
[GCC 8.3.0]


Specifically, I ran in a docker container: 

DOCKER_IMAGE=circleci/python:3.9-rc
docker pull $DOCKER_IMAGE
docker run --rm -it $DOCKER_IMAGE bash

And then in the bash shell in the docker image I ran:

python -c "print(eval(compile('[i for i in range(3)]', mode='eval', filename='foo', flags=221184)))"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40438>
_______________________________________

From report at bugs.python.org  Wed Apr 29 11:11:51 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Apr 2020 15:11:51 +0000
Subject: [issue40436] pythoninfo collect_gdb() blows up when gdb fails to run
In-Reply-To: <1588160205.58.0.824942554925.issue40436@roundup.psfhosted.org>
Message-ID: <1588173111.84.0.549103745393.issue40436@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset ec9bea4a3766bd815148a27f61eb24e7dd459ac7 by Victor Stinner in branch 'master':
bpo-40436: Fix code parsing gdb version (GH-19792)
https://github.com/python/cpython/commit/ec9bea4a3766bd815148a27f61eb24e7dd459ac7


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40436>
_______________________________________

From report at bugs.python.org  Wed Apr 29 11:12:21 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 29 Apr 2020 15:12:21 +0000
Subject: [issue40436] pythoninfo collect_gdb() blows up when gdb fails to run
In-Reply-To: <1588160205.58.0.824942554925.issue40436@roundup.psfhosted.org>
Message-ID: <1588173141.7.0.67281781677.issue40436@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
nosy: +miss-islington
nosy_count: 2.0 -> 3.0
pull_requests: +19116
pull_request: https://github.com/python/cpython/pull/19795

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40436>
_______________________________________

From report at bugs.python.org  Wed Apr 29 11:12:36 2020
From: report at bugs.python.org (John Hagen)
Date: Wed, 29 Apr 2020 15:12:36 +0000
Subject: [issue25521] optparse module does not emit DeprecationWarning
In-Reply-To: <1446247354.16.0.386152814173.issue25521@psf.upfronthosting.co.za>
Message-ID: <1588173156.85.0.339467699369.issue25521@roundup.psfhosted.org>


John Hagen <johnthagen at gmail.com> added the comment:

With PEP 594 (https://www.python.org/dev/peps/pep-0594/) in the pipeline, is it time that optparse correctly emits DeprecationWarnings?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25521>
_______________________________________

From report at bugs.python.org  Wed Apr 29 11:12:56 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Apr 2020 15:12:56 +0000
Subject: [issue40438] Python 3.9 eval on list comprehension sometimes returns
 coroutines
In-Reply-To: <1588172525.03.0.278979936503.issue40438@roundup.psfhosted.org>
Message-ID: <1588173176.51.0.807690033862.issue40438@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I close the issue: it's already fixed in 3.9.0a6. If it's not the case, feel free to reopen the issue ;-)

----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40438>
_______________________________________

From report at bugs.python.org  Wed Apr 29 11:13:48 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 29 Apr 2020 15:13:48 +0000
Subject: [issue40436] pythoninfo collect_gdb() blows up when gdb fails to run
In-Reply-To: <1588160205.58.0.824942554925.issue40436@roundup.psfhosted.org>
Message-ID: <1588173228.64.0.55935976854.issue40436@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +19117
pull_request: https://github.com/python/cpython/pull/19796

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40436>
_______________________________________

From report at bugs.python.org  Wed Apr 29 11:04:27 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Apr 2020 15:04:27 +0000
Subject: [issue40438] Python 3.9 eval on list comprehension sometimes returns
 coroutines
In-Reply-To: <1588172525.03.0.278979936503.issue40438@roundup.psfhosted.org>
Message-ID: <1588172667.39.0.907651450427.issue40438@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> I first noticed this when testing xdoctest on Python 3.9, and then again when using IPython.

What is your Python 3.9 exact version number?

I cannot reproduce your issue with Python 3.9.0a6:

vstinner at apu$ ./python -c "print(eval(compile('[i for i in range(3)]', mode='eval', filename='foo', flags=221184)))"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ValueError: compile(): unrecognised flags

vstinner at apu$ ./python -VV
Python 3.9.0a6+ (heads/master:9a8c1315c3, Apr 29 2020, 17:03:41) 
[GCC 9.3.1 20200408 (Red Hat 9.3.1-2)]

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40438>
_______________________________________

From report at bugs.python.org  Wed Apr 29 11:16:02 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Apr 2020 15:16:02 +0000
Subject: [issue40436] pythoninfo collect_gdb() blows up when gdb fails to run
In-Reply-To: <1588160205.58.0.824942554925.issue40436@roundup.psfhosted.org>
Message-ID: <1588173362.56.0.0219267796601.issue40436@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I fixed test.pythoninfo to ignore gdb output if the command failed. I also enhanced test_gdb error message: display stdout, stderr and the exit code. Backport to 3.8 and 3.7 will be merged as soon as the CI pass.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40436>
_______________________________________

From report at bugs.python.org  Wed Apr 29 11:20:57 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 29 Apr 2020 15:20:57 +0000
Subject: [issue40246] Different error messages for same error - invalid string
 prefixes
In-Reply-To: <1586541958.33.0.891000303304.issue40246@roundup.psfhosted.org>
Message-ID: <1588173657.76.0.113836954491.issue40246@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

>From earlier in this issue: https://bugs.python.org/msg366164

> So a slightly shorter example uses ru''. This is an error because you can't combine the r prefix and the u prefix (in fact you can't combine anything with the r prefix).

That's not true: 'rf' is a valid prefix: rf'{1}'. And so are all of the wacky combinations rF, Rf, RF, fr, fR, Fr, FR.

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40246>
_______________________________________

From report at bugs.python.org  Wed Apr 29 11:21:25 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Apr 2020 15:21:25 +0000
Subject: [issue39837] Remove Azure Pipelines from GitHub PRs
In-Reply-To: <1583255119.77.0.277327127951.issue39837@roundup.psfhosted.org>
Message-ID: <1588173685.44.0.863219456651.issue39837@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Another issue: I still see "Azure Pipelines PR Expected ? Waiting for status to be reported" 15 min after I created my PR :-/ Technically, I created the PR and then pushed a second commit to the PR. The only option is to close/reopen the PR to re-trigger *all* CIs :-/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39837>
_______________________________________

From report at bugs.python.org  Wed Apr 29 11:21:39 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Apr 2020 15:21:39 +0000
Subject: [issue39837] Make Azure Pipelines optional on GitHub PRs
In-Reply-To: <1583255119.77.0.277327127951.issue39837@roundup.psfhosted.org>
Message-ID: <1588173699.66.0.369186794828.issue39837@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
title: Remove Azure Pipelines from GitHub PRs -> Make Azure Pipelines optional on GitHub PRs

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39837>
_______________________________________

From report at bugs.python.org  Wed Apr 29 11:25:55 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 29 Apr 2020 15:25:55 +0000
Subject: [issue40246] Different error messages for same error - invalid string
 prefixes
In-Reply-To: <1586541958.33.0.891000303304.issue40246@roundup.psfhosted.org>
Message-ID: <1588173955.22.0.314897425741.issue40246@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I think it was a typo. You cannot combine anything with the u prefix.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40246>
_______________________________________

From report at bugs.python.org  Wed Apr 29 11:30:09 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 29 Apr 2020 15:30:09 +0000
Subject: [issue40436] pythoninfo collect_gdb() blows up when gdb fails to run
In-Reply-To: <1588160205.58.0.824942554925.issue40436@roundup.psfhosted.org>
Message-ID: <1588174209.51.0.90914981285.issue40436@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset d9e904919197a22b95946f11ba5f24b796088c06 by Miss Islington (bot) in branch '3.8':
bpo-40436: Fix code parsing gdb version (GH-19792)
https://github.com/python/cpython/commit/d9e904919197a22b95946f11ba5f24b796088c06


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40436>
_______________________________________

From report at bugs.python.org  Wed Apr 29 11:30:57 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 29 Apr 2020 15:30:57 +0000
Subject: [issue40436] pythoninfo collect_gdb() blows up when gdb fails to run
In-Reply-To: <1588160205.58.0.824942554925.issue40436@roundup.psfhosted.org>
Message-ID: <1588174257.93.0.411094692372.issue40436@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset beba1a808000d5fc445cb28eab96bdb4cdb7c959 by Miss Islington (bot) in branch '3.7':
bpo-40436: Fix code parsing gdb version (GH-19792)
https://github.com/python/cpython/commit/beba1a808000d5fc445cb28eab96bdb4cdb7c959


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40436>
_______________________________________

From report at bugs.python.org  Wed Apr 29 11:32:54 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Apr 2020 15:32:54 +0000
Subject: [issue40436] pythoninfo collect_gdb() blows up when gdb fails to run
In-Reply-To: <1588160205.58.0.824942554925.issue40436@roundup.psfhosted.org>
Message-ID: <1588174374.66.0.681620528196.issue40436@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Thanks Miro for the bug report, it's now fixed ;-)

In PR 19792, Miro proposed to skip test_gdb is gdb is available but exit with non-zero exit code. I chose to raise a hard exception instead, to notify CI owners that something is wrong. I prefer to not make gdb error "silent". Otherwise, we may miss that python-gdb.py is no longer tested on a CI.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40436>
_______________________________________

From report at bugs.python.org  Wed Apr 29 11:37:23 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 29 Apr 2020 15:37:23 +0000
Subject: [issue40246] Different error messages for same error - invalid string
 prefixes
In-Reply-To: <1586541958.33.0.891000303304.issue40246@roundup.psfhosted.org>
Message-ID: <1588174643.81.0.878186294397.issue40246@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

I think you're right, since rb obviously works, too. I just wanted to make sure we're covering all the bases. There's some code in either the stdlib or the test suite where I generate all of the valid prefixes (it's something like 80 prefixes). I can dig it up if anyone needs it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40246>
_______________________________________

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: [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 11:49:49 2020
From: report at bugs.python.org (Mark Shannon)
Date: Wed, 29 Apr 2020 15:49:49 +0000
Subject: [issue40228] Make setting line number in frame more robust.
In-Reply-To: <1586360855.72.0.434652598832.issue40228@roundup.psfhosted.org>
Message-ID: <1588175389.38.0.0485096444016.issue40228@roundup.psfhosted.org>


Mark Shannon <mark at hotpy.org> added the comment:


New changeset 57697245e1deafdedf68e5f21ad8890be591efc0 by Mark Shannon in branch 'master':
bpo-40228: More robust frame.setlineno. (GH-19437)
https://github.com/python/cpython/commit/57697245e1deafdedf68e5f21ad8890be591efc0


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40228>
_______________________________________

From report at bugs.python.org  Wed Apr 29 11:56:50 2020
From: report at bugs.python.org (jeffolsi10)
Date: Wed, 29 Apr 2020 15:56:50 +0000
Subject: [issue40437] add string.snake function
In-Reply-To: <1588164532.34.0.674721156435.issue40437@roundup.psfhosted.org>
Message-ID: <1588175810.35.0.480470422318.issue40437@roundup.psfhosted.org>


jeffolsi10 <yirage2897 at coalamails.com> added the comment:

snake case has very specific definition :
https://en.wikipedia.org/wiki/Snake_case
I expect the function to implement the definition and not something that I or someone else desire.

As for your question about '$' char I could ask the same thing for lower()
The snake case convert only letters and space. It doesn't handle spacial chars. it ignores them.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40437>
_______________________________________

From report at bugs.python.org  Wed Apr 29 12:03:55 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Apr 2020 16:03:55 +0000
Subject: [issue40286] Add randbytes() method to random.Random
In-Reply-To: <1586903418.02.0.530735802731.issue40286@roundup.psfhosted.org>
Message-ID: <1588176235.08.0.303490200609.issue40286@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +19118
stage: resolved -> patch review
pull_request: https://github.com/python/cpython/pull/19797

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40286>
_______________________________________

From report at bugs.python.org  Wed Apr 29 12:04:26 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 29 Apr 2020 16:04:26 +0000
Subject: [issue9216] FIPS support for hashlib
In-Reply-To: <1278721335.16.0.522410247151.issue9216@psf.upfronthosting.co.za>
Message-ID: <1588176266.6.0.413352598632.issue9216@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset e3dfb9b967c560f4d094092dcae4a16fc9634681 by Victor Stinner in branch 'master':
bpo-9216: Expose OpenSSL FIPS_mode() as _hashlib.get_fips_mode() (GH-19703)
https://github.com/python/cpython/commit/e3dfb9b967c560f4d094092dcae4a16fc9634681


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue9216>
_______________________________________

From report at bugs.python.org  Wed Apr 29 12:06:31 2020
From: report at bugs.python.org (jeffolsi10)
Date: Wed, 29 Apr 2020 16:06:31 +0000
Subject: [issue40437] add string.snake function
In-Reply-To: <1588164532.34.0.674721156435.issue40437@roundup.psfhosted.org>
Message-ID: <1588176391.1.0.426094625892.issue40437@roundup.psfhosted.org>


jeffolsi10 <yirage2897 at coalamails.com> added the comment:

I'd like also to point that there are few other cases:
https://stackoverflow.com/questions/11273282/whats-the-name-for-hyphen-separated-case

This is PascalCase: SomeSymbol
This is camelCase: someSymbol
This is snake_case: some_symbol

So a possible function could be:

convert_case(string, input_format, output_format)
for example:

convert_case(someSymbol, input_format='camelCase', output_format='snake_case')
output: some_symbol

It should be noted that you can not convert something without knowing what it is.
so something like : convert('helloworld','camelCase') can not be done because you don't know where one first word start and when one ends.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40437>
_______________________________________

From report at bugs.python.org  Wed Apr 29 12:10:12 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 29 Apr 2020 16:10:12 +0000
Subject: [issue40437] add string.snake function
In-Reply-To: <1588164532.34.0.674721156435.issue40437@roundup.psfhosted.org>
Message-ID: <1588176612.26.0.0909608405899.issue40437@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

So then it appears the snake case function couldn't be used for database column names, without some additional processing. So, what is the use case for it?

I just don't see a lot of use for this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40437>
_______________________________________

From report at bugs.python.org  Wed Apr 29 12:10:34 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Apr 2020 16:10:34 +0000
Subject: [issue40346] Add random.BaseRandom to ease implementation of
 subclasses
In-Reply-To: <1587419589.68.0.186666450831.issue40346@roundup.psfhosted.org>
Message-ID: <1588176634.94.0.292940103866.issue40346@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I created this issue to propose PR 19631 (BaseRandom class) which looked like as a good idea to me: simple base class which fix different kind of problems.

But it seems like other people would prefer a complete rewrite from scratch and require a PEP.

I abandonned my BaseRandom PR #19631 and my PR 19700 since there is no clear consensus on these changes. I'm not interested to write a PEP to redesign the module random.

I also close this issue as rejected. If someone wants to enhance the random module, it seems like a PEP is needed: at least, please open a separated issue.

I wrote PR #19797 "Remove C implementation of Random.randbytes()" to address initial Raymond's concern on randbytes() implementation:
https://bugs.python.org/issue40286#msg366860

----------
resolution:  -> rejected
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40346>
_______________________________________

From report at bugs.python.org  Wed Apr 29 12:27:01 2020
From: report at bugs.python.org (Lysandros Nikolaou)
Date: Wed, 29 Apr 2020 16:27:01 +0000
Subject: [issue40246] Different error messages for same error - invalid string
 prefixes
In-Reply-To: <1586541958.33.0.891000303304.issue40246@roundup.psfhosted.org>
Message-ID: <1588177621.71.0.93121929988.issue40246@roundup.psfhosted.org>


Lysandros Nikolaou <lisandrosnik at gmail.com> added the comment:

What's also possible is to handle keywords at tokenizer level and return a different token type for each one of them (like with async and await), which is currently handled at parser level. This would enable us to allow reserved keywords right before a STRING token, thus covering all the possible broken code cases, but continue disallowing arbitrary NAMEs, which would mean better error-reporting in the case of invalid prefixes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40246>
_______________________________________

From report at bugs.python.org  Wed Apr 29 12:32:05 2020
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 29 Apr 2020 16:32:05 +0000
Subject: [issue39837] Make Azure Pipelines optional on GitHub PRs
In-Reply-To: <1583255119.77.0.277327127951.issue39837@roundup.psfhosted.org>
Message-ID: <1588177925.02.0.60658357961.issue39837@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

Best place to report workflow issues or to have discussions about it is https://github.com/python/core-workflow/. Otherwise there were so many posts I didn't find an explicit ask of what you wanted changed, Victor.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39837>
_______________________________________

From report at bugs.python.org  Wed Apr 29 12:37:49 2020
From: report at bugs.python.org (Delgan)
Date: Wed, 29 Apr 2020 16:37:49 +0000
Subject: [issue40399] IO streams locking can be broken after fork() with
 threads
In-Reply-To: <1587920302.07.0.276002968457.issue40399@roundup.psfhosted.org>
Message-ID: <1588178269.72.0.276416187738.issue40399@roundup.psfhosted.org>


Delgan <delgan.py at gmail.com> added the comment:

Yeah, I just wanted to illustrate the issue with a more realistic example. The thread is often abstracted away by a class or a library. Conclusion: do not abstract it away. :)

I've noticed that the mere fact of using "sys.stderr.write()", without even involving a queue, could cause the problem.

Out of curiosity: my understanding of "sys.stderr" being a "TextIOWrapper" implies it's not thread-safe. Therefore, do you have any idea of which lock is involved in this issue?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40399>
_______________________________________

From report at bugs.python.org  Wed Apr 29 12:43:20 2020
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 29 Apr 2020 16:43:20 +0000
Subject: [issue40399] IO streams locking can be broken after fork() with
 threads
In-Reply-To: <1587920302.07.0.276002968457.issue40399@roundup.psfhosted.org>
Message-ID: <1588178600.81.0.123022017488.issue40399@roundup.psfhosted.org>


Antoine Pitrou <solipsis at pitrou.net> added the comment:

The TextIOWrapper uses an underlying BufferedWriter, which is thread-safe (and therefore has an internal lock).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40399>
_______________________________________

From report at bugs.python.org  Wed Apr 29 12:45:27 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Wed, 29 Apr 2020 16:45:27 +0000
Subject: [issue1635741] Py_Finalize() doesn't clear all Python objects at exit
Message-ID: <1588178727.48.0.313652717951.issue1635741@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
pull_requests: +19119
pull_request: https://github.com/python/cpython/pull/19798

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1635741>
_______________________________________

From report at bugs.python.org  Wed Apr 29 12:49:04 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Apr 2020 16:49:04 +0000
Subject: [issue40286] Add randbytes() method to random.Random
In-Reply-To: <1586903418.02.0.530735802731.issue40286@roundup.psfhosted.org>
Message-ID: <1588178944.08.0.890711409636.issue40286@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 2d8757758d0d75882fef0fe0e3c74c4756b3e81e by Victor Stinner in branch 'master':
bpo-40286: Remove C implementation of Random.randbytes() (GH-19797)
https://github.com/python/cpython/commit/2d8757758d0d75882fef0fe0e3c74c4756b3e81e


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40286>
_______________________________________

From report at bugs.python.org  Wed Apr 29 12:51:01 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Apr 2020 16:51:01 +0000
Subject: [issue40286] Add randbytes() method to random.Random
In-Reply-To: <1586903418.02.0.530735802731.issue40286@roundup.psfhosted.org>
Message-ID: <1588179061.19.0.794172335649.issue40286@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

It removed the C implementation of randbytes(): it was the root issue which started discussions here and in bpo-40346. I rejected bpo-40346 (BaseRandom) and related PRs.

I close the issue.

----------
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40286>
_______________________________________

From report at bugs.python.org  Wed Apr 29 12:53:57 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Apr 2020 16:53:57 +0000
Subject: [issue39837] Make Azure Pipelines optional on GitHub PRs
In-Reply-To: <1583255119.77.0.277327127951.issue39837@roundup.psfhosted.org>
Message-ID: <1588179237.4.0.596760215557.issue39837@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> Otherwise there were so many posts I didn't find an explicit ask of what you wanted changed, Victor.

I would like to make Azure Pipelines optional on GitHub PRs.

I changed the issue title to make my request more explicit.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39837>
_______________________________________

From report at bugs.python.org  Wed Apr 29 13:13:16 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Apr 2020 17:13:16 +0000
Subject: [issue34990] year 2038 problem in compileall.py
In-Reply-To: <1539602536.3.0.788709270274.issue34990@psf.upfronthosting.co.za>
Message-ID: <1588180396.81.0.0782443578253.issue34990@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I would prefer to mimick importlib._bootstrap_external which uses:

def _pack_uint32(x):
    """Convert a 32-bit integer to little-endian."""
    return (int(x) & 0xFFFFFFFF).to_bytes(4, 'little')

Using 64-bit timestamp (PR 19651), treat timestamp as unsigned (PR 9892 and PR 19708) have drawback:

* 64-bit timestamp make .pyc files larger
* unsigned timestamp no longer support timestamp before 1969 which can cause practical issues

"& 0xFFFFFFFF" looks dead simple, uses a fixed size of 4 bytes and doesn't have any limitation of year 2038.

The timestamp doesn't have to be exact. In practice, it sounds very unlikely that two timestamps are equal when compared using (ts1 & 0xFFFFFFFF) == (ts2 & 0xFFFFFFFF). I expect file modification times to be close by a few days, not separated by 2**32 seconds (136 years).

Use hash based .pyc to avoid any issuse with file modification time: it should make Python more deterministic (more "reproducible").
https://docs.python.org/dev/reference/import.html#pyc-invalidation

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34990>
_______________________________________

From report at bugs.python.org  Wed Apr 29 13:25:58 2020
From: report at bugs.python.org (jeffolsi10)
Date: Wed, 29 Apr 2020 17:25:58 +0000
Subject: [issue40437] add string.snake function
In-Reply-To: <1588164532.34.0.674721156435.issue40437@roundup.psfhosted.org>
Message-ID: <1588181158.06.0.747064338472.issue40437@roundup.psfhosted.org>


jeffolsi10 <yirage2897 at coalamails.com> added the comment:

it can. This is why I'm asking this.
Consider APIs that return list of names in camelCase. You must convert the keys to snakeCase to create tables from it as it's bad practice to have capitalised letters in columns or table names.

Further more, consider someone who wants to create tests to make sure all developers used snakeCase for function names. There are many many use cases.

You can also see the examples in stackoverflow that I posted. 500 votes up and there are many more.

Again I think this is totally in the domain of capitalize, swapcase which we already have. I think that snakeCase has way more use cases than capitalize.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40437>
_______________________________________

From report at bugs.python.org  Wed Apr 29 13:26:02 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Apr 2020 17:26:02 +0000
Subject: [issue40217] The garbage collector doesn't take in account that
 objects of heap allocated types hold a strong reference to their type
In-Reply-To: <1586276621.78.0.843757244355.issue40217@roundup.psfhosted.org>
Message-ID: <1588181162.53.0.55084218909.issue40217@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> Please backport to 3.8, then it will become part of 3.8.3rc1 which I'll be releasing tomorrow.

I propose to *not* fix this bug in Python 3.8:

* Python 3.8 stdlib doesn't seem to be impacted by this bug
* The number of third party C extension modules impated by this bug is very low or even zero
* The bug severity is minor *in practice*
* A backport can cause a C extension to crash
* The implementation may still change before Python 3.9.0 final release

--

The worst thing which can happen with this bug is that a C extension module creates many types and these types are never deleted. Well, it's annoying, but it's unlikely to happen. Usually, types are created exactly once in C extensions.

--

I'm not 100% comfortable with backporting the fix. Python 3.8.0, 3.8.1 and 3.8.2 have been released with the bug, and this issue is the first report. But I only saw the bug because many C extension modules of the Python 3.9 stdlib were converted to PyModuleDef_Init() and PyType_FromSpec().

--

I'm not comfortable to change the GC behavior in a subtle way in a 3.8.x minor release.

If a C extension module was impacted by this bug and decided to explicitly visit the type in its traverse function, this fix will crash the C extension crash...

--

At April 23, Serhiy proposed an alternative fix. But then he didn't propose a PR.

--

The bug only impacts C extension modules which use PyModuleDef_Init() and PyType_FromSpec().

Python 3.8 only uses PyModuleDef_Init() in the following modules:

vstinner at apu$ grep -l PyModuleDef_Init Modules/*.c
Modules/arraymodule.c
Modules/atexitmodule.c
Modules/binascii.c
Modules/_testmultiphase.c
Modules/xxlimited.c
Modules/xxmodule.c
Modules/xxsubtype.c

Python 3.8 only uses PyType_FromSpec() in the following modules:

$ grep -l PyType_FromSpec Modules/*.c
Modules/_curses_panel.c
Modules/_ssl.c
Modules/_testcapimodule.c
Modules/_testmultiphase.c
Modules/_tkinter.c
Modules/xxlimited.c

Intersection of the two sets: _testmultiphase and xxlimited, which are modules only used by the Python test suite.

It means that Python 3.8 standard library is *not* impacted by this bug.

Only third party C extension modules which use PyModuleDef_Init() *and* PyType_FromSpec() are impacted. Most C extension modules use statically allocated types and so are not impacted.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40217>
_______________________________________

From report at bugs.python.org  Wed Apr 29 13:34:31 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Wed, 29 Apr 2020 17:34:31 +0000
Subject: [issue40328] Add tools for generating mappings_XX.h
In-Reply-To: <1587302039.42.0.928310034054.issue40328@roundup.psfhosted.org>
Message-ID: <1588181671.47.0.366008291669.issue40328@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:


New changeset 113feb3ec2b08948a381175d33b6ff308d24fceb by Dong-hee Na in branch 'master':
bpo-40328: Add tool for generating cjk mapping headers (GH-19602)
https://github.com/python/cpython/commit/113feb3ec2b08948a381175d33b6ff308d24fceb


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40328>
_______________________________________

From report at bugs.python.org  Wed Apr 29 13:35:43 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 29 Apr 2020 17:35:43 +0000
Subject: [issue40437] add string.snake function
In-Reply-To: <1588164532.34.0.674721156435.issue40437@roundup.psfhosted.org>
Message-ID: <1588181743.74.0.189059869919.issue40437@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

I remain unconvinced, but I'm only one person. You might want to bring this up on python-ideas to see if it can get some more support.

But be aware this is going to have much less support that the recent PEP 616 removeprefix/removesuffix discussion, which went on for weeks or months, and involved writing a PEP.

While the Wikipedia page you cite discusses how to convert a string of words into snake case, a PEP will require much more detail. Just a few off the top of my head: What happens to multiple space: does that become a single underscore, or multiple? Is all whitespace converted to underscores, including newlines and tabs?  Does it work if the string is already in CamelCase?

I also don't think swapcase or capitalize (plus some others) would be added today if they didn't already exist.

To me, this seems like something that belongs on PyPI (like https://pypi.org/project/stringcase/), and not in the standard library.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40437>
_______________________________________

From report at bugs.python.org  Wed Apr 29 13:44:35 2020
From: report at bugs.python.org (Jonathan Crall)
Date: Wed, 29 Apr 2020 17:44:35 +0000
Subject: [issue40438] Python 3.9 eval on list comprehension sometimes returns
 coroutines
In-Reply-To: <1588172525.03.0.278979936503.issue40438@roundup.psfhosted.org>
Message-ID: <1588182275.47.0.180423269367.issue40438@roundup.psfhosted.org>


Jonathan Crall <erotemic at gmail.com> added the comment:

This can be closed, but for completeness, the test you ran didn't verify that the bug was fixed. This is because the hard coded compile flags I gave in my example seem to have changed in Python 3.9 (is this documented?). 

In python3.8 the compile flags I specified correspond to division, print_function, unicode_literals, and absolute_import. 

python3.8 -c "import __future__; print(__future__.print_function.compiler_flag | __future__.division.compiler_flag | __future__.unicode_literals.compiler_flag | __future__.absolute_import.compiler_flag)"


Results in: 221184


In Python 3.9 the same code results in: 3538944


I can modify the MWE to accommodate these changes: 

./python -c "import __future__; print(eval(compile('[i for i in range(3)]', mode='eval', filename='fo', flags=__future__.print_function.compiler_flag | __future__.division.compiler_flag | __future__.unicode_literals.compiler_flag | __future__.absolute_import.compiler_flag)))"


Which does produce the correct output as expected. So, the issue can remain closed. I am curious what the bug in 3.9.0a5 was though if you have any speculations.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40438>
_______________________________________

From report at bugs.python.org  Wed Apr 29 13:56:14 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Wed, 29 Apr 2020 17:56:14 +0000
Subject: [issue40438] Python 3.9 eval on list comprehension sometimes returns
 coroutines
In-Reply-To: <1588172525.03.0.278979936503.issue40438@roundup.psfhosted.org>
Message-ID: <1588182974.45.0.598444981058.issue40438@roundup.psfhosted.org>


Batuhan Taskaya <batuhanosmantaskaya at gmail.com> added the comment:

> This can be closed, but for completeness, the test you ran didn't verify that the bug was fixed. This is because the hard coded compile flags I gave in my example seem to have changed in Python 3.9 (is this documented?). 

Yes, this is documented on What's New.

> Which does produce the correct output as expected. So, the issue can remain closed. I am curious what the bug in 3.9.0a5 was though if you have any speculations.

See issue 39562

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40438>
_______________________________________

From report at bugs.python.org  Wed Apr 29 14:20:34 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Wed, 29 Apr 2020 18:20:34 +0000
Subject: [issue1635741] Py_Finalize() doesn't clear all Python objects at exit
Message-ID: <1588184434.33.0.265686905269.issue1635741@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:


New changeset 84724dd239c30043616487812f6a710b1d70cd4b by Dong-hee Na in branch 'master':
bpo-1635741: Port _stat module to multiphase initialization (GH-19798)
https://github.com/python/cpython/commit/84724dd239c30043616487812f6a710b1d70cd4b


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1635741>
_______________________________________

From report at bugs.python.org  Wed Apr 29 14:23:20 2020
From: report at bugs.python.org (jeffolsi10)
Date: Wed, 29 Apr 2020 18:23:20 +0000
Subject: [issue40437] add string.snake function
In-Reply-To: <1588164532.34.0.674721156435.issue40437@roundup.psfhosted.org>
Message-ID: <1588184600.4.0.927792257211.issue40437@roundup.psfhosted.org>


jeffolsi10 <yirage2897 at coalamails.com> added the comment:

I feel this should be in core.
I still don't understand why capitalize is supported and others do not.
snake case is very well defined. Issues like tabs and spaces are not relevant. can you show example that you have that dilemma?

To be honest I don't feel very strongly about it. I thought it would be cool to have native support for it as this is a small feature which isn't subject to changes thus shouldn't be break and has a lot of usage. I see many people implement it themselves with regex and other methods. 

Feel free to close this if I didn't convince you it.
I opened this because I thought it can help others.. I can live without this being supported in Python native.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40437>
_______________________________________

From report at bugs.python.org  Wed Apr 29 14:33:15 2020
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 29 Apr 2020 18:33:15 +0000
Subject: [issue40234] Disallow daemon threads in subinterpreters optionally.
In-Reply-To: <1586387812.86.0.0296012569674.issue40234@roundup.psfhosted.org>
Message-ID: <1588185195.02.0.963065295098.issue40234@roundup.psfhosted.org>


Change by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
nosy: +jcea

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40234>
_______________________________________

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: [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 15:11:47 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 29 Apr 2020 19:11:47 +0000
Subject: [issue40246] Different error messages for same error - invalid string
 prefixes
In-Reply-To: <1586541958.33.0.891000303304.issue40246@roundup.psfhosted.org>
Message-ID: <1588187507.46.0.608923763039.issue40246@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

> What's also possible is to handle keywords at tokenizer level

Sadly, the tokenizer is unaware of keywords (maybe except async and await because their history as soft keywords) as that distinction usually is up to the parser as the parser is the one who knows about the grammar. Introducing keywords in the tokenizer would couple them too much IMHO apart from other possible problems.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40246>
_______________________________________

From report at bugs.python.org  Wed Apr 29 15:17:33 2020
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 29 Apr 2020 19:17:33 +0000
Subject: [issue40291] socket library support for CAN_J1939
In-Reply-To: <1586928559.09.0.469111314858.issue40291@roundup.psfhosted.org>
Message-ID: <1588187853.1.0.978149509727.issue40291@roundup.psfhosted.org>


Change by Senthil Kumaran <senthil at uthcode.com>:


----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40291>
_______________________________________

From report at bugs.python.org  Wed Apr 29 15:18:31 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 29 Apr 2020 19:18:31 +0000
Subject: [issue40246] Different error messages for same error - invalid string
 prefixes
In-Reply-To: <1588187507.46.0.608923763039.issue40246@roundup.psfhosted.org>
Message-ID: <CAP7+vJLfwXKxXhpK2EFie5o_O_FpphKJB6_tRSxPiK0+=Fv73w@mail.gmail.com>


Guido van Rossum <guido at python.org> added the comment:

If it's all handled by the tokenizer, how come it's different in the new
parser?

Anyway, it seems we really have to support what the old parser supported
here. I don't know exactly what rules it uses. Maybe only look for a string
quote following a name that can definitely be a string prefix?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40246>
_______________________________________

From report at bugs.python.org  Wed Apr 29 15:28:54 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 29 Apr 2020 19:28:54 +0000
Subject: [issue40246] Different error messages for same error - invalid string
 prefixes
In-Reply-To: <1586541958.33.0.891000303304.issue40246@roundup.psfhosted.org>
Message-ID: <1588188534.37.0.260796378598.issue40246@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

> If it's all handled by the tokenizer, how come it's different in the newparser?

Is not different in the new parser: both parsers have analogous behaviour now:

~/github/python/master master
? ./python
Python 3.9.0a6+ (heads/master:84724dd239, Apr 29 2020, 20:26:52)
[GCC 9.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> norm=lambda m: m+(m and(m[-1]!='\n'and'\n'or'')or'\n')
  File "<stdin>", line 1
    norm=lambda m: m+(m and(m[-1]!='\n'and'\n'or'')or'\n')
                                         ^
SyntaxError: invalid string prefix
>>>

~/github/python/master master
? ./python -X oldparser
Python 3.9.0a6+ (heads/master:84724dd239, Apr 29 2020, 20:26:52)
[GCC 9.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> norm=lambda m: m+(m and(m[-1]!='\n'and'\n'or'')or'\n')
  File "<stdin>", line 1
    norm=lambda m: m+(m and(m[-1]!='\n'and'\n'or'')or'\n')
                                       ^
SyntaxError: invalid string prefix


This issue is exclusively due to the changes in https://github.com/python/cpython/pull/19476 if I understand correctly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40246>
_______________________________________

From report at bugs.python.org  Wed Apr 29 15:30:05 2020
From: report at bugs.python.org (Ammar Askar)
Date: Wed, 29 Apr 2020 19:30:05 +0000
Subject: [issue40439] Error in an external reference
In-Reply-To: <1588175008.34.0.523121738721.issue40439@roundup.psfhosted.org>
Message-ID: <1588188605.03.0.245189586407.issue40439@roundup.psfhosted.org>


Ammar Askar <ammar at ammaraskar.com> added the comment:

Thank you for the report Patrick! 

For reference this is on the lexical analysis page: https://docs.python.org/3/reference/lexical_analysis.html

> A non-normative HTML file listing all valid identifier characters for Unicode 4.1 can be found at https://www.dcl.hpi.uni-potsdam.de/home/loewis/table-3131.html.


Looking at the page on https://web.archive.org/web/20200312045240/https://www.dcl.hpi.uni-potsdam.de/home/loewis/table-3131.html

it seems like it was just a giant table containing all the valid XID_START and XID_CONTINUE characters. We could just remove the link or point it to the section in the current unicode database we use https://www.unicode.org/Public/13.0.0/ucd/DerivedCoreProperties.txt
where it lists all the characters:

> # Derived Property: XID_Start

Would you like to make a pull request for this?

----------
keywords: +newcomer friendly
nosy: +ammar2, loewis

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40439>
_______________________________________

From report at bugs.python.org  Wed Apr 29 15:30:33 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 29 Apr 2020 19:30:33 +0000
Subject: [issue40246] Different error messages for same error - invalid string
 prefixes
In-Reply-To: <1586541958.33.0.891000303304.issue40246@roundup.psfhosted.org>
Message-ID: <1588188633.54.0.6637611108.issue40246@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Indeed, reverting commit 41d5b94af44e34ac05d4cd57460ed104ccf96628 makes it work with both parsers:

~/github/python/master master*
? ./python -X oldparser
Python 3.9.0a6+ (heads/master-dirty:84724dd239, Apr 29 2020, 20:29:53)
[GCC 9.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> norm=lambda m: m+(m and(m[-1]!='\n'and'\n'or'')or'\n')
>>>

~/github/python/master master*
? ./python
Python 3.9.0a6+ (heads/master-dirty:84724dd239, Apr 29 2020, 20:29:53)
[GCC 9.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> norm=lambda m: m+(m and(m[-1]!='\n'and'\n'or'')or'\n')
>>>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40246>
_______________________________________

From report at bugs.python.org  Wed Apr 29 15:37:39 2020
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Wed, 29 Apr 2020 19:37:39 +0000
Subject: [issue40437] add string.snake function
In-Reply-To: <1588164532.34.0.674721156435.issue40437@roundup.psfhosted.org>
Message-ID: <1588189059.8.0.456567037692.issue40437@roundup.psfhosted.org>


R?mi Lapeyre <remi.lapeyre at henki.fr> added the comment:

I don't understand the motivation, why would it be very useful when working with titles of columns that are to be used in databases columns?

Databases can handle columns with spaces in their name:

postgres=# create temporary table foo ("column with spaces" text);
CREATE TABLE
Time: 29,973 ms
postgres=# insert into foo values ('bar');
INSERT 0 1
Time: 0,746 ms
postgres=# select * from foo;
 column with spaces 
--------------------
 bar
(1 row)

Time: 3,452 ms


There is also various library available to do this on Pypi like https://github.com/okunishinishi/python-stringcase and https://github.com/jpvanhal/inflection. I'm pretty sure I used inflection at one company and it worked great.

Finally, the issue on the Pandas repository says how to do it: you can use Series.apply.

----------
nosy: +remi.lapeyre

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40437>
_______________________________________

From report at bugs.python.org  Wed Apr 29 16:00:04 2020
From: report at bugs.python.org (Ammar Askar)
Date: Wed, 29 Apr 2020 20:00:04 +0000
Subject: [issue35829] datetime: parse "Z" timezone suffix in fromisoformat()
In-Reply-To: <1548445007.56.0.14925163397.issue35829@roundup.psfhosted.org>
Message-ID: <1588190404.6.0.216316356885.issue35829@roundup.psfhosted.org>


Ammar Askar <ammar at ammaraskar.com> added the comment:

There's been some additional discussion on https://discuss.python.org/t/parse-z-timezone-suffix-in-datetime/2220

----------
nosy: +ammar2

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35829>
_______________________________________

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: [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:08:41 2020
From: report at bugs.python.org (Ammar Askar)
Date: Wed, 29 Apr 2020 20:08:41 +0000
Subject: [issue40358] pathlib's relative_to should behave like os.path.relpath
In-Reply-To: <1587513783.17.0.6950267733.issue40358@roundup.psfhosted.org>
Message-ID: <1588190921.09.0.460337771.issue40358@roundup.psfhosted.org>


Ammar Askar <ammar at ammaraskar.com> added the comment:

Thank you for your work on this Domenico. For reviewing the code, would you mind creating a Github pull request for it as described here https://devguide.python.org/pullrequest/

----------
nosy: +ammar2

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40358>
_______________________________________

From report at bugs.python.org  Wed Apr 29 16:14:05 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 29 Apr 2020 20:14:05 +0000
Subject: [issue40246] Different error messages for same error - invalid string
 prefixes
In-Reply-To: <1586541958.33.0.891000303304.issue40246@roundup.psfhosted.org>
Message-ID: <1588191245.66.0.850926425478.issue40246@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

The original issue was about different error messages in REPL and eval(). But it is not related to string prefixes. We have the same difference without involving strings:

>>> a b
  File "<stdin>", line 1
    a b
      ^
SyntaxError: invalid syntax
>>> eval("a b")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<string>", line 1
    a b
      ^
SyntaxError: unexpected EOF while parsing

I suggest to revert this change and close the issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40246>
_______________________________________

From report at bugs.python.org  Wed Apr 29 16:32:02 2020
From: report at bugs.python.org (jeffolsi10)
Date: Wed, 29 Apr 2020 20:32:02 +0000
Subject: [issue40437] add string.snake function
In-Reply-To: <1588164532.34.0.674721156435.issue40437@roundup.psfhosted.org>
Message-ID: <1588192322.44.0.0190081015257.issue40437@roundup.psfhosted.org>


jeffolsi10 <yirage2897 at coalamails.com> added the comment:

R?mi Lapeyre not all of them.
I can give list of many examples where snake case is needed.

But the question is: Are we discussing if snake case is even needed
or are we discussing if this should be in python core.

Those are two totally different things. 

1. The need is shown in many questions over the internat. Again see stackoverflow.

2. To my understanding core should provide infra for the common simple usages. One can also argue why python need to maintain str conversion at all if we have such good extensions in different libs.


Are you saying that in your opinion people won't find it useful so there is no need for it or are you saying that no matter how many people would like it the feature should not be in Python core.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40437>
_______________________________________

From report at bugs.python.org  Wed Apr 29 16:39:20 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 29 Apr 2020 20:39:20 +0000
Subject: [issue40437] add string.snake function
In-Reply-To: <1588164532.34.0.674721156435.issue40437@roundup.psfhosted.org>
Message-ID: <1588192760.72.0.263211723978.issue40437@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

> One can also argue why python need to maintain str conversion at all if we have such good extensions in different libs.

Back when we were starting python 3.x there was discussion or removing these from str and bytes, but it was decided that breaking existing code just wasn't worth it. You can imagine how rarely b"Some String".swapcase() is used.

As I said, if we were designing the language from scratch today I doubt we would include swapcase, title, and capitalize, at least. I don't think using their existence as an argument to add more methods like them is very convincing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40437>
_______________________________________

From report at bugs.python.org  Wed Apr 29 16:46:14 2020
From: report at bugs.python.org (Deomid Ryabkov)
Date: Wed, 29 Apr 2020 20:46:14 +0000
Subject: [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 16:46:27 2020
From: report at bugs.python.org (Deomid Ryabkov)
Date: Wed, 29 Apr 2020 20:46:27 +0000
Subject: [issue40442] Spurious warning emitted during fork() can deadlock a
 multi-threaded process
In-Reply-To: <1588193173.96.0.734255401294.issue40442@roundup.psfhosted.org>
Message-ID: <1588193187.51.0.462160978944.issue40442@roundup.psfhosted.org>


Change by Deomid Ryabkov <rojer at rojer.me>:


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40442>
_______________________________________

From report at bugs.python.org  Wed Apr 29 16:49:08 2020
From: report at bugs.python.org (Deomid Ryabkov)
Date: Wed, 29 Apr 2020 20:49:08 +0000
Subject: [issue6721] Locks in the standard library should be sanitized on fork
In-Reply-To: <1250550378.97.0.072881968798.issue6721@psf.upfronthosting.co.za>
Message-ID: <1588193348.52.0.759325716938.issue6721@roundup.psfhosted.org>


Deomid Ryabkov <rojer at rojer.me> added the comment:

https://bugs.python.org/issue40442 is a fresh instance of this, entirely self-inflicted.

----------
nosy: +rojer

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue6721>
_______________________________________

From report at bugs.python.org  Wed Apr 29 17:18:49 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 29 Apr 2020 21:18:49 +0000
Subject: [issue40435] IDLE should catch user config file UnicodeDecodeError
In-Reply-To: <1588154736.32.0.92562314697.issue40435@roundup.psfhosted.org>
Message-ID: <1588195129.48.0.0782212878962.issue40435@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I want this left open to fix IDLE exiting instead of continuing.  The original IDLE authors could not anticipate all the things that users around the world (and OS developers) might do, and we maintainers are still plugging holes as they are reported.

>From the original report, I am slightly surprised that your fix worked.  Please either upload your revised config-main.cfg or paste it into a reply.  Changing it should not, that I know of, affect the reading of other .cfg files, only the subsequent loading of .py files.  Even then, it would have to end with an "[EditorWindow]" section, so that "encoding=utf-8" would be in the proper section.

(I should also check the error messaging for un-readable .py files too)

----------
resolution: not a bug -> 
stage: resolved -> test needed
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40435>
_______________________________________

From report at bugs.python.org  Wed Apr 29 17:33:42 2020
From: report at bugs.python.org (Benjamin Keen)
Date: Wed, 29 Apr 2020 21:33:42 +0000
Subject: [issue40440] allow array.array construction from memoryview w/o copy
In-Reply-To: <1588186893.13.0.865332377255.issue40440@roundup.psfhosted.org>
Message-ID: <1588196022.16.0.39835058621.issue40440@roundup.psfhosted.org>


Change by Benjamin Keen <benjamin.keen at hpe.com>:


----------
keywords: +patch
pull_requests: +19121
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19800

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40440>
_______________________________________

From report at bugs.python.org  Wed Apr 29 17:42:04 2020
From: report at bugs.python.org (John Andersen)
Date: Wed, 29 Apr 2020 21:42:04 +0000
Subject: [issue40427] importlib of module results in different id than when
 imported with import keyword
In-Reply-To: <1588100454.16.0.607696168199.issue40427@roundup.psfhosted.org>
Message-ID: <1588196524.39.0.995193663055.issue40427@roundup.psfhosted.org>


John Andersen <johnandersenpdx at gmail.com> added the comment:

Thank you! :) I must have missed that somehow

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40427>
_______________________________________

From report at bugs.python.org  Wed Apr 29 17:47:01 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Apr 2020 21:47:01 +0000
Subject: [issue40442] Spurious warning emitted during fork() can deadlock a
 multi-threaded process
In-Reply-To: <1588193173.96.0.734255401294.issue40442@roundup.psfhosted.org>
Message-ID: <1588196821.32.0.756639295343.issue40442@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40442>
_______________________________________

From report at bugs.python.org  Wed Apr 29 17:56:05 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 29 Apr 2020 21:56:05 +0000
Subject: [issue40440] allow array.array construction from memoryview w/o copy
In-Reply-To: <1588186893.13.0.865332377255.issue40440@roundup.psfhosted.org>
Message-ID: <1588197365.33.0.324301526414.issue40440@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

array.array should copy the content, to be able to modify it. It implements both the storage for data and the view of that storage.

What you want is already implemented as the memoryview object.

>>> import array
>>> x = array.array('b', [1,2,3,4])
>>> x
array('b', [1, 2, 3, 4])
>>> z = memoryview(x).cast('h')
>>> z
<memory at 0x7f31e79d2c80>
>>> list(z)
[513, 1027]
>>> z[0] = 42
>>> x
array('b', [42, 0, 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

----------
nosy: +serhiy.storchaka, skrah

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40440>
_______________________________________

From report at bugs.python.org  Wed Apr 29 17:57:47 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Apr 2020 21:57:47 +0000
Subject: [issue40402] Race condition in multiprocessing/connection.py: broken
 handle
In-Reply-To: <1587954709.44.0.390905431083.issue40402@roundup.psfhosted.org>
Message-ID: <1588197467.5.0.817046487511.issue40402@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

See also bpo-39995: race condition in concurrent.futures. More specific to _ThreadWakeup class, but with similar symptoms.

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40402>
_______________________________________

From report at bugs.python.org  Wed Apr 29 18:20:20 2020
From: report at bugs.python.org (Joannah Nanjekye)
Date: Wed, 29 Apr 2020 22:20:20 +0000
Subject: [issue40441] Plural typo in Design and History FAQ
In-Reply-To: <1588190531.44.0.663545958427.issue40441@roundup.psfhosted.org>
Message-ID: <1588198820.77.0.507319517342.issue40441@roundup.psfhosted.org>


Joannah Nanjekye <nanjekyejoannah at gmail.com> added the comment:

After merging the associated PR, I believe this is resolved. Thanks Alex for reporting and solving this

----------
nosy: +nanjekyejoannah
stage:  -> resolved

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40441>
_______________________________________

From report at bugs.python.org  Wed Apr 29 18:23:56 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 29 Apr 2020 22:23:56 +0000
Subject: [issue40254] pyspecific directives are not translatable
In-Reply-To: <1586595169.2.0.635960834529.issue40254@roundup.psfhosted.org>
Message-ID: <1588199036.48.0.20102731067.issue40254@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions:  -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40254>
_______________________________________

From report at bugs.python.org  Wed Apr 29 18:31:27 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 29 Apr 2020 22:31:27 +0000
Subject: [issue40291] socket library support for CAN_J1939
In-Reply-To: <1586928559.09.0.469111314858.issue40291@roundup.psfhosted.org>
Message-ID: <1588199487.65.0.997591781584.issue40291@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 360371f79c48f15bbcee7aeecacf97a899913b25 by karl ding in branch 'master':
bpo-40291: Add support for CAN_J1939 sockets (GH-19538)
https://github.com/python/cpython/commit/360371f79c48f15bbcee7aeecacf97a899913b25


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40291>
_______________________________________

From report at bugs.python.org  Wed Apr 29 18:32:24 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 29 Apr 2020 22:32:24 +0000
Subject: [issue40291] socket library support for CAN_J1939
In-Reply-To: <1586928559.09.0.469111314858.issue40291@roundup.psfhosted.org>
Message-ID: <1588199544.53.0.866828730341.issue40291@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

Thanks, good luck using this!

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40291>
_______________________________________

From report at bugs.python.org  Wed Apr 29 18:33:04 2020
From: report at bugs.python.org (Joannah Nanjekye)
Date: Wed, 29 Apr 2020 22:33:04 +0000
Subject: [issue40434] Update of reasoning why there is no case statement
In-Reply-To: <1588148867.59.0.249886730635.issue40434@roundup.psfhosted.org>
Message-ID: <1588199584.98.0.827796613793.issue40434@roundup.psfhosted.org>


Joannah Nanjekye <nanjekyejoannah at gmail.com> added the comment:

What is your reasoning on referencing just  one of the PEPs and not both of them?

----------
nosy: +nanjekyejoannah

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40434>
_______________________________________

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: [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:51:51 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Apr 2020 22:51:51 +0000
Subject: [issue40443] Remove unused imports in the stdlib (April 2020 edition)
In-Reply-To: <1588200148.3.0.742578477052.issue40443@roundup.psfhosted.org>
Message-ID: <1588200711.14.0.437593863613.issue40443@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
keywords: +patch
pull_requests: +19122
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19801

_______________________________________
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: [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 18:53:36 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 29 Apr 2020 22:53:36 +0000
Subject: [issue40334] PEP 617: new PEG-based parser
In-Reply-To: <1587327377.33.0.614039250584.issue40334@roundup.psfhosted.org>
Message-ID: <1588200816.93.0.276824719421.issue40334@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset 69e802ed812e38cb68a4ab74af64b4f719b6cc78 by Lysandros Nikolaou in branch 'master':
bpo-40334: Fix test_peg_parser to actually use the old parser (GH-19778)
https://github.com/python/cpython/commit/69e802ed812e38cb68a4ab74af64b4f719b6cc78


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40334>
_______________________________________

From report at bugs.python.org  Wed Apr 29 18:55:20 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Apr 2020 22:55:20 +0000
Subject: [issue40443] Remove unused imports in the stdlib (April 2020 edition)
In-Reply-To: <1588200148.3.0.742578477052.issue40443@roundup.psfhosted.org>
Message-ID: <1588200920.95.0.249248122262.issue40443@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +19123
pull_request: https://github.com/python/cpython/pull/19802

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40443>
_______________________________________

From report at bugs.python.org  Wed Apr 29 19:05:58 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Apr 2020 23:05:58 +0000
Subject: [issue40443] Remove unused imports in the stdlib (April 2020 edition)
In-Reply-To: <1588200148.3.0.742578477052.issue40443@roundup.psfhosted.org>
Message-ID: <1588201558.1.0.367954447321.issue40443@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +19124
pull_request: https://github.com/python/cpython/pull/19803

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40443>
_______________________________________

From report at bugs.python.org  Wed Apr 29 19:13:26 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Apr 2020 23:13:26 +0000
Subject: [issue40443] Remove unused imports in the stdlib (April 2020 edition)
In-Reply-To: <1588200148.3.0.742578477052.issue40443@roundup.psfhosted.org>
Message-ID: <1588202006.19.0.230193129493.issue40443@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +19125
pull_request: https://github.com/python/cpython/pull/19804

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40443>
_______________________________________

From report at bugs.python.org  Wed Apr 29 19:15:39 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Apr 2020 23:15:39 +0000
Subject: [issue40443] Remove unused imports in the stdlib (April 2020 edition)
In-Reply-To: <1588200148.3.0.742578477052.issue40443@roundup.psfhosted.org>
Message-ID: <1588202139.06.0.276973033077.issue40443@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +19126
pull_request: https://github.com/python/cpython/pull/19805

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40443>
_______________________________________

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: [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  Wed Apr 29 19:46:16 2020
From: report at bugs.python.org (Shantanu)
Date: Wed, 29 Apr 2020 23:46:16 +0000
Subject: [issue40445] compileall.compile_dir docs aren't updated for bpo-38112
In-Reply-To: <1588203472.21.0.62841448361.issue40445@roundup.psfhosted.org>
Message-ID: <1588203976.94.0.384230299044.issue40445@roundup.psfhosted.org>


Change by Shantanu <hauntsaninja at gmail.com>:


----------
keywords: +patch
pull_requests: +19127
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19806

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40445>
_______________________________________

From report at bugs.python.org  Wed Apr 29 19:48:46 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Apr 2020 23:48:46 +0000
Subject: [issue40443] Remove unused imports in the stdlib (April 2020 edition)
In-Reply-To: <1588200148.3.0.742578477052.issue40443@roundup.psfhosted.org>
Message-ID: <1588204126.53.0.552120908276.issue40443@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 57572b103ebd8732ac21922f0051a7f140d0e405 by Victor Stinner in branch 'master':
bpo-40443: Remove unused imports in tests (GH-19805)
https://github.com/python/cpython/commit/57572b103ebd8732ac21922f0051a7f140d0e405


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40443>
_______________________________________

From report at bugs.python.org  Wed Apr 29 19:51:42 2020
From: report at bugs.python.org (Peter Ludemann)
Date: Wed, 29 Apr 2020 23:51:42 +0000
Subject: [issue40360] Deprecate lib2to3 (and 2to3) for future removal
In-Reply-To: <1587530454.25.0.44181585934.issue40360@roundup.psfhosted.org>
Message-ID: <1588204302.58.0.383151263888.issue40360@roundup.psfhosted.org>


Peter Ludemann <peter.ludemann at gmail.com> added the comment:

The documentation change gives two possible successors:

https://libcst.readthedocs.io/ (https://github.com/Instagram/LibCST)
https://parso.readthedocs.io/

And I've also seen this mentioned: https://github.com/pyga/awpa

Is it possible to settle on one of these as the successor to the lib2to3 parser? It would be nice to avoid a 2nd deprecation in the future ...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40360>
_______________________________________

From report at bugs.python.org  Wed Apr 29 19:52:51 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 29 Apr 2020 23:52:51 +0000
Subject: [issue40256] Python 3.8 Not Launching on Bootcamp Windows 10.
In-Reply-To: <1586628271.16.0.0390251857061.issue40256@roundup.psfhosted.org>
Message-ID: <1588204371.93.0.84844046938.issue40256@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I presume you mean the Mac Bootcamp program that allows one to run Windows on Macs.  I don't know if it runs *all* Windows programs or whether we specifically support running Windows python under Bootcamp.  I imagine that there might be problems with some GUI and graphics programs.

IDLE depends on multiple stdlibs, in particular tkinter, which depends on tcl/tk.  To test if the Windows versions work under Bootcamp, run "python -m tkinter" in Command Prompt.  You should see a tk window with text and a click-me button.  If that works, try "python -m turtle".  It should draw and erase a couple of patterns.  If both work, "python -m test".  Then try "python -m idlelib" and report any error messages that appear.

----------
components: +macOS
nosy: +ned.deily, ronaldoussoren, terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40256>
_______________________________________

From report at bugs.python.org  Wed Apr 29 19:59:12 2020
From: report at bugs.python.org (Tim Peters)
Date: Wed, 29 Apr 2020 23:59:12 +0000
Subject: [issue40444] multiprocessing.Pool deadlocks with only print statements
In-Reply-To: <1588200729.96.0.263407738291.issue40444@roundup.psfhosted.org>
Message-ID: <1588204752.18.0.0989906155298.issue40444@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

Just noting that the program runs to completion without issues under 3.8.1, but on Win10.  Of course Windows doesn't support fork().

----------
nosy: +tim.peters

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40444>
_______________________________________

From report at bugs.python.org  Wed Apr 29 20:02:37 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 30 Apr 2020 00:02:37 +0000
Subject: [issue40262] SSL recv_into requires the object to implement __len__
 unlike socket one
In-Reply-To: <1586712498.2.0.649122705148.issue40262@roundup.psfhosted.org>
Message-ID: <1588204957.36.0.760151314085.issue40262@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions:  -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40262>
_______________________________________

From report at bugs.python.org  Wed Apr 29 20:03:25 2020
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 30 Apr 2020 00:03:25 +0000
Subject: [issue40358] pathlib's relative_to should behave like os.path.relpath
In-Reply-To: <1587513783.17.0.6950267733.issue40358@roundup.psfhosted.org>
Message-ID: <1588205005.08.0.134314544688.issue40358@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
nosy: +python-dev
nosy_count: 5.0 -> 6.0
pull_requests: +19128
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19807

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40358>
_______________________________________

From report at bugs.python.org  Wed Apr 29 20:17:33 2020
From: report at bugs.python.org (Darin Tay)
Date: Thu, 30 Apr 2020 00:17:33 +0000
Subject: [issue40444] multiprocessing.Pool deadlocks with only print statements
In-Reply-To: <1588200729.96.0.263407738291.issue40444@roundup.psfhosted.org>
Message-ID: <1588205853.63.0.418952162996.issue40444@roundup.psfhosted.org>


Darin Tay <darin.tay at gmail.com> added the comment:

Ah yes, I should have mentioned this is on Linux!  I also got around to testing on 3.8.2 (linux), where it still reproduces.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40444>
_______________________________________

From report at bugs.python.org  Wed Apr 29 20:21:36 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 30 Apr 2020 00:21:36 +0000
Subject: [issue40443] Remove unused imports in the stdlib (April 2020 edition)
In-Reply-To: <1588200148.3.0.742578477052.issue40443@roundup.psfhosted.org>
Message-ID: <1588206096.88.0.449432459985.issue40443@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset b1e11c31c523dc082985e9de779ceeb47224e536 by Victor Stinner in branch 'master':
bpo-40443: Remove unused imports in tests (GH-19804)
https://github.com/python/cpython/commit/b1e11c31c523dc082985e9de779ceeb47224e536


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40443>
_______________________________________

From report at bugs.python.org  Wed Apr 29 20:22:26 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 30 Apr 2020 00:22:26 +0000
Subject: [issue40269] Inconsistent complex behavior with (-1j)
In-Reply-To: <1586736208.71.0.129112794549.issue40269@roundup.psfhosted.org>
Message-ID: <1588206146.17.0.795347504968.issue40269@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

After reading through the comments, I don't think we should change repr(complex) unless there is computational issue, such as eval(repr(z) != z.  Raymond, I agree with your overlooked doc tweek.  If you submit a PR, you can ask me to review.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40269>
_______________________________________

From report at bugs.python.org  Wed Apr 29 20:39:59 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 30 Apr 2020 00:39:59 +0000
Subject: [issue40283] Documentation of turtle.circle()
In-Reply-To: <1586883280.42.0.803600338852.issue40283@roundup.psfhosted.org>
Message-ID: <1588207199.66.0.838149632736.issue40283@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

It would be bizarre if the current doc were correct, but have you verified by experiment that the change is correct?

The patch itself would be trivial, hence the keyword addition.  PR author can request that I review.

----------
keywords: +easy, newcomer friendly
nosy: +terry.reedy
stage:  -> needs patch
type: resource usage -> behavior
versions: +Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40283>
_______________________________________

From report at bugs.python.org  Wed Apr 29 20:49:29 2020
From: report at bugs.python.org (Domenico Ragusa)
Date: Thu, 30 Apr 2020 00:49:29 +0000
Subject: [issue40358] pathlib's relative_to should behave like os.path.relpath
In-Reply-To: <1588205005.1.0.277597690011.issue40358@roundup.psfhosted.org>
Message-ID: <CAHsu_9WPRCqX-uL+6yOQDJnz6rSiro4Wyf2xFoWGVPPzJtUCMg@mail.gmail.com>


Domenico Ragusa <domenicoragusa at gmail.com> added the comment:

I may have forgotten to use the proper format for the title of each
commit, should I delete the pull request and make a new one or can it
be fixed when (or if) it's pulled?

On Thu, Apr 30, 2020 at 2:03 AM Roundup Robot <report at bugs.python.org> wrote:
>
>
> Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:
>
>
> ----------
> nosy: +python-dev
> nosy_count: 5.0 -> 6.0
> pull_requests: +19128
> stage:  -> patch review
> pull_request: https://github.com/python/cpython/pull/19807
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue40358>
> _______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40358>
_______________________________________

From report at bugs.python.org  Wed Apr 29 21:06:43 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 30 Apr 2020 01:06:43 +0000
Subject: [issue40389] No straightforward way to get repr of Optional
In-Reply-To: <1587837782.6.0.0357631726958.issue40389@roundup.psfhosted.org>
Message-ID: <1588208803.05.0.0248726686697.issue40389@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:


New changeset 138a9b9c2a394f30f222c23391f9515a7df9d809 by Vlad Serebrennikov in branch 'master':
bpo-40389: Improve repr of typing.Optional (#19714)
https://github.com/python/cpython/commit/138a9b9c2a394f30f222c23391f9515a7df9d809


----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40389>
_______________________________________

From report at bugs.python.org  Wed Apr 29 21:07:41 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 30 Apr 2020 01:07:41 +0000
Subject: [issue40389] No straightforward way to get repr of Optional
In-Reply-To: <1587837782.6.0.0357631726958.issue40389@roundup.psfhosted.org>
Message-ID: <1588208861.79.0.171709103869.issue40389@roundup.psfhosted.org>


Change by Guido van Rossum <guido at python.org>:


----------
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40389>
_______________________________________

From report at bugs.python.org  Wed Apr 29 21:28:58 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 30 Apr 2020 01:28:58 +0000
Subject: [issue40443] Remove unused imports in the stdlib (April 2020 edition)
In-Reply-To: <1588200148.3.0.742578477052.issue40443@roundup.psfhosted.org>
Message-ID: <1588210138.46.0.231383140462.issue40443@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:


New changeset 6900f16d2207ca4fc252fa9d778ca0b13a3c95e0 by Victor Stinner in branch 'master':
bpo-40443: Remove unused imports in idlelib (GH-19801)
https://github.com/python/cpython/commit/6900f16d2207ca4fc252fa9d778ca0b13a3c95e0


----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40443>
_______________________________________

From report at bugs.python.org  Wed Apr 29 21:29:26 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 30 Apr 2020 01:29:26 +0000
Subject: [issue40443] Remove unused imports in the stdlib (April 2020 edition)
In-Reply-To: <1588200148.3.0.742578477052.issue40443@roundup.psfhosted.org>
Message-ID: <1588210166.15.0.632332709285.issue40443@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
nosy: +miss-islington
nosy_count: 2.0 -> 3.0
pull_requests: +19129
pull_request: https://github.com/python/cpython/pull/19808

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40443>
_______________________________________

From report at bugs.python.org  Wed Apr 29 21:29:33 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 30 Apr 2020 01:29:33 +0000
Subject: [issue40443] Remove unused imports in the stdlib (April 2020 edition)
In-Reply-To: <1588200148.3.0.742578477052.issue40443@roundup.psfhosted.org>
Message-ID: <1588210173.45.0.455049366778.issue40443@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +19130
pull_request: https://github.com/python/cpython/pull/19809

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40443>
_______________________________________

From report at bugs.python.org  Wed Apr 29 21:39:50 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 30 Apr 2020 01:39:50 +0000
Subject: [issue40360] Deprecate lib2to3 (and 2to3) for future removal
In-Reply-To: <1587530454.25.0.44181585934.issue40360@roundup.psfhosted.org>
Message-ID: <1588210790.95.0.945572559814.issue40360@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

It's typically not up to the core devs to pick a winning third party library; we tend to recommend libraries that are already essentially category winners, like requests. In a sense pointing to LibCST *and* parso is redundant because LibCST builds on parso. Comparing stars on GitHub:
- LibCST: 423
- parso: 296
- awpa: 10

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40360>
_______________________________________

From report at bugs.python.org  Wed Apr 29 21:46:01 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 30 Apr 2020 01:46:01 +0000
Subject: [issue40443] Remove unused imports in the stdlib (April 2020 edition)
In-Reply-To: <1588200148.3.0.742578477052.issue40443@roundup.psfhosted.org>
Message-ID: <1588211161.02.0.877760913346.issue40443@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 48ef06b62682c19b7860dcf5d9d610e589a49840 by Miss Islington (bot) in branch '3.7':
bpo-40443: Remove unused imports in idlelib (GH-19801)
https://github.com/python/cpython/commit/48ef06b62682c19b7860dcf5d9d610e589a49840


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40443>
_______________________________________

From report at bugs.python.org  Wed Apr 29 21:47:54 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 30 Apr 2020 01:47:54 +0000
Subject: [issue40443] Remove unused imports in the stdlib (April 2020 edition)
In-Reply-To: <1588200148.3.0.742578477052.issue40443@roundup.psfhosted.org>
Message-ID: <1588211274.21.0.328452380181.issue40443@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 95e208dce505c542b8e4f8f42c57e6d4793b6895 by Miss Islington (bot) in branch '3.8':
bpo-40443: Remove unused imports in idlelib (GH-19801)
https://github.com/python/cpython/commit/95e208dce505c542b8e4f8f42c57e6d4793b6895


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40443>
_______________________________________

From report at bugs.python.org  Wed Apr 29 21:48:09 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 30 Apr 2020 01:48:09 +0000
Subject: [issue40316] Add zero function to time, datetime,
 which acts as the use case of replace to limit resolution
In-Reply-To: <1587202635.96.0.0810977655343.issue40316@roundup.psfhosted.org>
Message-ID: <1588211289.35.0.514278751141.issue40316@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I recommend posting this to python-ideas for discussion.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40316>
_______________________________________

From report at bugs.python.org  Wed Apr 29 22:20:50 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 30 Apr 2020 02:20:50 +0000
Subject: [issue40377] APPDATA location in Microsoft Store version
In-Reply-To: <1587734754.85.0.727792315124.issue40377@roundup.psfhosted.org>
Message-ID: <1588213250.05.0.525900999395.issue40377@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
resolution:  -> third party

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40377>
_______________________________________

From report at bugs.python.org  Wed Apr 29 22:53:37 2020
From: report at bugs.python.org (Ammar Askar)
Date: Thu, 30 Apr 2020 02:53:37 +0000
Subject: [issue40441] Plural typo in Design and History FAQ
In-Reply-To: <1588190531.44.0.663545958427.issue40441@roundup.psfhosted.org>
Message-ID: <1588215217.86.0.425479222355.issue40441@roundup.psfhosted.org>


Change by Ammar Askar <ammar at ammaraskar.com>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40441>
_______________________________________

From report at bugs.python.org  Wed Apr 29 23:14:18 2020
From: report at bugs.python.org (Carl Meyer)
Date: Thu, 30 Apr 2020 03:14:18 +0000
Subject: [issue40360] Deprecate lib2to3 (and 2to3) for future removal
In-Reply-To: <1587530454.25.0.44181585934.issue40360@roundup.psfhosted.org>
Message-ID: <1588216458.8.0.841444663406.issue40360@roundup.psfhosted.org>


Carl Meyer <carl at oddbird.net> added the comment:

Right, although I think it still makes sense to link both LibCST and parso since they provide different levels of abstraction that would be suitable for different types of tools (e.g. I would rather write an auto-formatter on top of parso, because LibCST's careful parsing and assignment of whitespace would mostly just get in the way, but I'd rather write any kind of refactoring tooling on top of LibCST.)

Another tool that escaped my mind when writing the PR that should probably be linked also is Baron/RedBaron (https://github.com/PyCQA/redbaron); 457 stars makes it slightly more popular than LibCST (but it's also been around a lot longer.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40360>
_______________________________________

From report at bugs.python.org  Wed Apr 29 23:42:51 2020
From: report at bugs.python.org (Tim Peters)
Date: Thu, 30 Apr 2020 03:42:51 +0000
Subject: [issue40394] difflib.SequenceMatcher.find_longest_match default
 arguments
In-Reply-To: <1587910558.56.0.865649390619.issue40394@roundup.psfhosted.org>
Message-ID: <1588218171.96.0.803582262749.issue40394@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:


New changeset 3209cbd99b6d65aa18b3beb124fac9c792b8993d by lrjball in branch 'master':
bpo-40394 - difflib.SequenceMatched.find_longest_match default args (GH-19742)
https://github.com/python/cpython/commit/3209cbd99b6d65aa18b3beb124fac9c792b8993d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40394>
_______________________________________

From report at bugs.python.org  Wed Apr 29 23:45:43 2020
From: report at bugs.python.org (Tim Peters)
Date: Thu, 30 Apr 2020 03:45:43 +0000
Subject: [issue40394] difflib.SequenceMatcher.find_longest_match default
 arguments
In-Reply-To: <1587910558.56.0.865649390619.issue40394@roundup.psfhosted.org>
Message-ID: <1588218343.9.0.940304376548.issue40394@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

All done.  Thank you, Lewis!  You're now an official Python contributor, and are entitled to all the fame, fortune, and power that follows.  Use your new powers only for good :-)

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40394>
_______________________________________

From report at bugs.python.org  Thu Apr 30 00:01:01 2020
From: report at bugs.python.org (Kyle Stanley)
Date: Thu, 30 Apr 2020 04:01:01 +0000
Subject: [issue40405] asyncio.as_completed documentation misleading
In-Reply-To: <1587986090.72.0.850288416668.issue40405@roundup.psfhosted.org>
Message-ID: <1588219260.99.0.608108688153.issue40405@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:

@Bar as requested by Guido, let's continue the discussion in the PR: https://github.com/python/cpython/pull/19753#pullrequestreview-403185142.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40405>
_______________________________________

From report at bugs.python.org  Thu Apr 30 00:52:17 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 30 Apr 2020 04:52:17 +0000
Subject: [issue39562] Asynchronous comprehensions don't work in asyncio REPL
In-Reply-To: <1580923705.71.0.29233909242.issue39562@roundup.psfhosted.org>
Message-ID: <1588222337.45.0.36261857877.issue39562@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

I think we should backport the fix 4454057269b995341b04d13f0bf97f96080f27d0 (change constants) to 3.8 given that the likelihood of users using the actual hardcoded value of the constants instead of the constants themselves is very low. Also, given the collision, it would be fixing a bug present still in 3.8. 

If we revert 9052f7a41b90f2d34011c8da68f9a4facebc8a97 we would have two bugs in 3.8: collision of constants and asyncio repr not working properly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39562>
_______________________________________

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: [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 01:16:25 2020
From: report at bugs.python.org (Basic ICT Repairs)
Date: Thu, 30 Apr 2020 05:16:25 +0000
Subject: [issue40446] pow(a, b,
 p) where b=int((p-1)/2) spits out gibbrish for big p
In-Reply-To: <1588223600.07.0.719223766764.issue40446@roundup.psfhosted.org>
Message-ID: <1588223785.65.0.318875851427.issue40446@roundup.psfhosted.org>


Basic ICT Repairs <basic.ict.repairs at gmail.com> added the comment:

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

----------
type:  -> behavior
versions: +Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40446>
_______________________________________

From report at bugs.python.org  Thu Apr 30 01:34:53 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Thu, 30 Apr 2020 05:34:53 +0000
Subject: [issue40446] pow(a, b,
 p) where b=int((p-1)/2) spits out gibbrish for big p
In-Reply-To: <1588223600.07.0.719223766764.issue40446@roundup.psfhosted.org>
Message-ID: <20200430053041.GA26597@ando.pearwood.info>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

Hi,

The behaviour you are calling "gibbrish" is correct, as the expression 
`(p-1)/2` calculates a 64-bit floating point number, which may lose 
precision even for small values of p, but will definitely lose precision 
for large p.

Calling `int()` on that float will not recover the lost precision.

So there is no bug here, this is expected behaviour with floats. Please 
remember that floats are not mathematically exact Real numbers like we 
learn about in school, they have limited precision.

To avoid the float conversion, use the floor-division operator 
`(p-1)//2` as you mention. If `p` is an int, the result will be exact.

----------
nosy: +steven.daprano
title: pow(a,b,p) where b=int((p-1)/2) spits out gibbrish for big p -> 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 01:41:37 2020
From: report at bugs.python.org (Ammar Askar)
Date: Thu, 30 Apr 2020 05:41:37 +0000
Subject: [issue40446] pow(a, b,
 p) where b=int((p-1)/2) spits out gibbrish for big p
In-Reply-To: <1588223600.07.0.719223766764.issue40446@roundup.psfhosted.org>
Message-ID: <1588225297.25.0.0940699922714.issue40446@roundup.psfhosted.org>


Ammar Askar <ammar at ammaraskar.com> added the comment:

And just to add on, the reason this gives you the correct result in Python 2 is that `/` performs integer division whereas in Python 3 the `/` operator provides a float as a result.

See https://docs.python.org/3/howto/pyporting.html#division for more details.

----------
nosy: +ammar2
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40446>
_______________________________________

From report at bugs.python.org  Thu Apr 30 01:42:24 2020
From: report at bugs.python.org (Tim Peters)
Date: Thu, 30 Apr 2020 05:42:24 +0000
Subject: [issue40446] pow(a, b,
 p) where b=int((p-1)/2) spits out gibbrish for big p
In-Reply-To: <1588223600.07.0.719223766764.issue40446@roundup.psfhosted.org>
Message-ID: <1588225344.01.0.750978560231.issue40446@roundup.psfhosted.org>


Change by Tim Peters <tim at python.org>:


----------
resolution: fixed -> not a bug

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40446>
_______________________________________

From report at bugs.python.org  Thu Apr 30 01:53:53 2020
From: report at bugs.python.org (=?utf-8?b?5bem6L+f?=)
Date: Thu, 30 Apr 2020 05:53:53 +0000
Subject: [issue40435] IDLE should catch user config file UnicodeDecodeError
In-Reply-To: <1588154736.32.0.92562314697.issue40435@roundup.psfhosted.org>
Message-ID: <1588226033.97.0.0922312887747.issue40435@roundup.psfhosted.org>


?? <luckychizuo at gmail.com> added the comment:

Well, I have uploaded my ~/.idlerc/config-main.cfg. And apeeding "encodin=utf-8" is my first time to edit config-main.cfg file manually.
The content of config-main.cfg is below:
  1 [EditorWindow]
  2 font-size = 16
  3 font-bold = False
  4 encoding = utf-8
  5 font = courier new
  6
Just let me know if I could help you.

----------
Added file: https://bugs.python.org/file49101/config-main.cfg

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40435>
_______________________________________

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: [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 02:23:58 2020
From: report at bugs.python.org (Shantanu)
Date: Thu, 30 Apr 2020 06:23:58 +0000
Subject: [issue40447] compile_file's stripdir does not accept pathlib.Path
In-Reply-To: <1588227495.91.0.144745322662.issue40447@roundup.psfhosted.org>
Message-ID: <1588227838.31.0.198363728313.issue40447@roundup.psfhosted.org>


Shantanu <hauntsaninja at gmail.com> added the comment:

If it helps triage, this is the BPO for where the changes to compileall were made: https://bugs.python.org/issue38112

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40447>
_______________________________________

From report at bugs.python.org  Thu Apr 30 02:32:44 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 30 Apr 2020 06:32:44 +0000
Subject: [issue40447] compile_file's stripdir does not accept pathlib.Path
In-Reply-To: <1588227495.91.0.144745322662.issue40447@roundup.psfhosted.org>
Message-ID: <1588228364.55.0.788625716998.issue40447@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40447>
_______________________________________

From report at bugs.python.org  Thu Apr 30 02:48:40 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 30 Apr 2020 06:48:40 +0000
Subject: [issue40262] SSL recv_into requires the object to implement __len__
 unlike socket one
In-Reply-To: <1586712498.2.0.649122705148.issue40262@roundup.psfhosted.org>
Message-ID: <1588229320.08.0.282804252216.issue40262@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Yes, it is a bug. __len__ can return a value different from the amount of bytes (in array.array, memoryview).

len(buffer) can be replaced with memoryview(buffer).nbytes, but maybe we could keep None and let the lower level to handle it.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40262>
_______________________________________

From report at bugs.python.org  Thu Apr 30 03:18:52 2020
From: report at bugs.python.org (=?utf-8?q?Ionel_Cristian_M=C4=83rie=C8=99?=)
Date: Thu, 30 Apr 2020 07:18:52 +0000
Subject: [issue40442] Spurious warning emitted during fork() can deadlock a
 multi-threaded process
In-Reply-To: <1588193173.96.0.734255401294.issue40442@roundup.psfhosted.org>
Message-ID: <1588231132.62.0.521587970501.issue40442@roundup.psfhosted.org>


Change by Ionel Cristian M?rie? <contact at ionelmc.ro>:


----------
nosy: +ionelmc

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40442>
_______________________________________

From report at bugs.python.org  Thu Apr 30 03:27:56 2020
From: report at bugs.python.org (=?utf-8?q?Miro_Hron=C4=8Dok?=)
Date: Thu, 30 Apr 2020 07:27:56 +0000
Subject: [issue40360] Deprecate lib2to3 (and 2to3) for future removal
In-Reply-To: <1587530454.25.0.44181585934.issue40360@roundup.psfhosted.org>
Message-ID: <1588231676.47.0.0371009073937.issue40360@roundup.psfhosted.org>


Miro Hron?ok <miro at hroncok.cz> added the comment:

Coul you please add a what's new entry for this change?

----------
nosy: +hroncok

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40360>
_______________________________________

From report at bugs.python.org  Thu Apr 30 03:35:50 2020
From: report at bugs.python.org (=?utf-8?q?Miro_Hron=C4=8Dok?=)
Date: Thu, 30 Apr 2020 07:35:50 +0000
Subject: [issue40360] Deprecate lib2to3 (and 2to3) for future removal
In-Reply-To: <1587530454.25.0.44181585934.issue40360@roundup.psfhosted.org>
Message-ID: <1588232150.59.0.556630601171.issue40360@roundup.psfhosted.org>


Miro Hron?ok <miro at hroncok.cz> added the comment:

I don't understand why there is a PendingDeprecationWarning and not a DeprecationWarning.


See https://discuss.python.org/t/pendingdeprecationwarning-is-really-useful/1038/4 and issue36404

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40360>
_______________________________________

From report at bugs.python.org  Thu Apr 30 04:19:02 2020
From: report at bugs.python.org (jeffolsi10)
Date: Thu, 30 Apr 2020 08:19:02 +0000
Subject: [issue40437] add string.snake function
In-Reply-To: <1588164532.34.0.674721156435.issue40437@roundup.psfhosted.org>
Message-ID: <1588234742.41.0.025831293773.issue40437@roundup.psfhosted.org>


jeffolsi10 <yirage2897 at coalamails.com> added the comment:

I can respect that.
So you may close this request.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40437>
_______________________________________

From report at bugs.python.org  Thu Apr 30 04:26:55 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Thu, 30 Apr 2020 08:26:55 +0000
Subject: [issue40437] add string.snake function
In-Reply-To: <1588164532.34.0.674721156435.issue40437@roundup.psfhosted.org>
Message-ID: <1588235215.02.0.745361454147.issue40437@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

Thanks for the suggestion and the discussion. I'll close the issue.

----------
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40437>
_______________________________________

From report at bugs.python.org  Thu Apr 30 04:48:51 2020
From: report at bugs.python.org (Chris Jerdonek)
Date: Thu, 30 Apr 2020 08:48:51 +0000
Subject: [issue29587] Generator/coroutine 'throw' discards exc_info state,
 which is bad
In-Reply-To: <1487329309.81.0.182915384821.issue29587@psf.upfronthosting.co.za>
Message-ID: <1588236531.3.0.513581456388.issue29587@roundup.psfhosted.org>


Change by Chris Jerdonek <chris.jerdonek at gmail.com>:


----------
keywords: +patch
pull_requests: +19131
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19811

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29587>
_______________________________________

From report at bugs.python.org  Thu Apr 30 05:20:36 2020
From: report at bugs.python.org (Chris Jerdonek)
Date: Thu, 30 Apr 2020 09:20:36 +0000
Subject: [issue29587] Generator/coroutine 'throw' discards exc_info state,
 which is bad
In-Reply-To: <1487329309.81.0.182915384821.issue29587@psf.upfronthosting.co.za>
Message-ID: <1588238436.51.0.601618900974.issue29587@roundup.psfhosted.org>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

I made a naive attempt at addressing this issue here:
https://github.com/python/cpython/pull/19811

The code has diverged significantly since Nathaniel first linked to a specific line above. However, what I came up with is simple, and seems to work. But I could very well be missing some things.

It would be great if this could be fixed in some way.

----------
versions: +Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29587>
_______________________________________

From report at bugs.python.org  Thu Apr 30 05:26:40 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 30 Apr 2020 09:26:40 +0000
Subject: [issue40443] Remove unused imports in the stdlib (April 2020 edition)
In-Reply-To: <1588200148.3.0.742578477052.issue40443@roundup.psfhosted.org>
Message-ID: <1588238800.77.0.0717965018104.issue40443@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 90549676e063c2c818cfc14213d3adb7edcc2bd5 by Victor Stinner in branch 'master':
bpo-40443: Remove unused imports in the stdlib (GH-19803)
https://github.com/python/cpython/commit/90549676e063c2c818cfc14213d3adb7edcc2bd5


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40443>
_______________________________________

From report at bugs.python.org  Thu Apr 30 05:28:13 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 30 Apr 2020 09:28:13 +0000
Subject: [issue40443] Remove unused imports in the stdlib (April 2020 edition)
In-Reply-To: <1588200148.3.0.742578477052.issue40443@roundup.psfhosted.org>
Message-ID: <1588238893.55.0.0631362559039.issue40443@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset e488e300f5c01289c10906c2e53a8e43d6de32d8 by Victor Stinner in branch 'master':
bpo-40443: Remove unused imports in distutils (GH-19802)
https://github.com/python/cpython/commit/e488e300f5c01289c10906c2e53a8e43d6de32d8


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40443>
_______________________________________

From report at bugs.python.org  Thu Apr 30 05:33:25 2020
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 30 Apr 2020 09:33:25 +0000
Subject: [issue40256] Python 3.8 Not Launching on Bootcamp Windows 10.
In-Reply-To: <1586628271.16.0.0390251857061.issue40256@roundup.psfhosted.org>
Message-ID: <1588239205.95.0.977989853031.issue40256@roundup.psfhosted.org>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

AFAIK Windows 10 in Bootcamp is just the regular Windows 10. Bootcamp (or technically "Bootcamp Assistent") creates a partition for the installation of W10 and adds some drivers for Apple hardware.

See als: https://support.apple.com/en-us/HT201468

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40256>
_______________________________________

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: [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 05:49:17 2020
From: report at bugs.python.org (Krzysztof Konopko)
Date: Thu, 30 Apr 2020 09:49:17 +0000
Subject: [issue40448] ensurepip uses cache directory
In-Reply-To: <1588239551.95.0.236818491517.issue40448@roundup.psfhosted.org>
Message-ID: <1588240157.92.0.668027508812.issue40448@roundup.psfhosted.org>


Change by Krzysztof Konopko <kris at konagma.com>:


----------
keywords: +patch
pull_requests: +19132
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19812

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40448>
_______________________________________

From report at bugs.python.org  Thu Apr 30 06:17:31 2020
From: report at bugs.python.org (Yusuf Mumtaz)
Date: Thu, 30 Apr 2020 10:17:31 +0000
Subject: [issue40256] Python 3.8 Not Launching on Bootcamp Windows 10.
In-Reply-To: <1586628271.16.0.0390251857061.issue40256@roundup.psfhosted.org>
Message-ID: <1588241851.36.0.291393813509.issue40256@roundup.psfhosted.org>


Yusuf Mumtaz <ymumtaz22 at gmail.com> added the comment:

Hello, so when I type in python -m tkinter, nothing appears.

----------
resolution:  -> wont fix

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40256>
_______________________________________

From report at bugs.python.org  Thu Apr 30 06:30:01 2020
From: report at bugs.python.org (Domenico Ragusa)
Date: Thu, 30 Apr 2020 10:30:01 +0000
Subject: [issue40358] pathlib's relative_to should behave like os.path.relpath
In-Reply-To: <1587513783.17.0.6950267733.issue40358@roundup.psfhosted.org>
Message-ID: <1588242601.31.0.667426928184.issue40358@roundup.psfhosted.org>


Change by Domenico Ragusa <domenicoragusa at gmail.com>:


----------
pull_requests: +19133
pull_request: https://github.com/python/cpython/pull/19813

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40358>
_______________________________________

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: [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 06:54:35 2020
From: report at bugs.python.org (Sanyam Khurana)
Date: Thu, 30 Apr 2020 10:54:35 +0000
Subject: [issue40358] pathlib's relative_to should behave like os.path.relpath
In-Reply-To: <1587513783.17.0.6950267733.issue40358@roundup.psfhosted.org>
Message-ID: <1588244075.58.0.462037587543.issue40358@roundup.psfhosted.org>


Change by Sanyam Khurana <sanyam.khurana01 at gmail.com>:


----------
nosy: +CuriousLearner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40358>
_______________________________________

From report at bugs.python.org  Thu Apr 30 07:50:19 2020
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 30 Apr 2020 11:50:19 +0000
Subject: [issue40256] Python 3.8 Not Launching on Bootcamp Windows 10.
In-Reply-To: <1586628271.16.0.0390251857061.issue40256@roundup.psfhosted.org>
Message-ID: <1588247419.02.0.417895314285.issue40256@roundup.psfhosted.org>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

How did you install Python? 

Does "python" work as a command (should give you an interactive shell)?

Does "python -m test" work? This runs the testsuite.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40256>
_______________________________________

From report at bugs.python.org  Thu Apr 30 07:53:11 2020
From: report at bugs.python.org (Yusuf Mumtaz)
Date: Thu, 30 Apr 2020 11:53:11 +0000
Subject: [issue40256] Python 3.8 Not Launching on Bootcamp Windows 10.
In-Reply-To: <1586628271.16.0.0390251857061.issue40256@roundup.psfhosted.org>
Message-ID: <1588247591.85.0.538305717321.issue40256@roundup.psfhosted.org>


Yusuf Mumtaz <ymumtaz22 at gmail.com> added the comment:

Hello, I installed python of their own website. No interactive command shell appears and python -m test also does not work.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40256>
_______________________________________

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: [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 09:02:47 2020
From: report at bugs.python.org (wei gu)
Date: Thu, 30 Apr 2020 13:02:47 +0000
Subject: =?utf-8?b?W2lzc3VlNDA0NTBdIGE9WzEsMiwzXSBhPWEuZXh0ZW5kKFs0XSkgYWZ0ZXIg?=
 =?utf-8?q?running_these_two_lines_of_code_a_is_None=EF=BC=8Cbut_it_show_b?=
 =?utf-8?b?ZSBbMSwyLDMsNF0=?=
Message-ID: <1588251767.1.0.355791513877.issue40450@roundup.psfhosted.org>


Change by wei gu <guwei0802 at gmail.com>:


----------
components: +Interpreter Core
resolution:  -> wont fix
title: wrong -> a=[1,2,3] a=a.extend([4]) after running these two lines of code a is None?but it show be [1,2,3,4]
type:  -> behavior
versions: +Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9
Added file: https://bugs.python.org/file49102/error.png

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40450>
_______________________________________

From report at bugs.python.org  Thu Apr 30 09:03:38 2020
From: report at bugs.python.org (wei gu)
Date: Thu, 30 Apr 2020 13:03:38 +0000
Subject: =?utf-8?b?W2lzc3VlNDA0NTBdIGE9WzEsMiwzXSBhPWEuZXh0ZW5kKFs0XSkgYWZ0ZXIg?=
 =?utf-8?q?running_these_two_lines_of_code_a_is_None=EF=BC=8Cbut_it_should?=
 =?utf-8?b?IGJlIFsxLDIsMyw0XQ==?=
Message-ID: <1588251818.54.0.102260359241.issue40450@roundup.psfhosted.org>


Change by wei gu <guwei0802 at gmail.com>:


----------
title: a=[1,2,3] a=a.extend([4]) after running these two lines of code a is None?but it show be [1,2,3,4] -> a=[1,2,3] a=a.extend([4]) after running these two lines of code a is None?but it should be [1,2,3,4]

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40450>
_______________________________________

From report at bugs.python.org  Thu Apr 30 09:06:49 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Thu, 30 Apr 2020 13:06:49 +0000
Subject: =?utf-8?b?W2lzc3VlNDA0NTBdIGE9WzEsMiwzXSBhPWEuZXh0ZW5kKFs0XSkgYWZ0ZXIg?=
 =?utf-8?q?running_these_two_lines_of_code_a_is_None=EF=BC=8Cbut_it_should?=
 =?utf-8?b?IGJlIFsxLDIsMyw0XQ==?=
Message-ID: <1588252009.06.0.934838434377.issue40450@roundup.psfhosted.org>


New submission from Eric V. Smith <eric at trueblade.com>:

list.extend modifies the list in place. Like most mutating methods in python, it does not return the thing being modified.

Everything is working correctly, and it's documented this way.

----------
nosy: +eric.smith
resolution: wont fix -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40450>
_______________________________________

From report at bugs.python.org  Thu Apr 30 09:30:26 2020
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 30 Apr 2020 13:30:26 +0000
Subject: [issue40256] Python 3.8 Not Launching on Bootcamp Windows 10.
In-Reply-To: <1586628271.16.0.0390251857061.issue40256@roundup.psfhosted.org>
Message-ID: <1588253426.24.0.136127650548.issue40256@roundup.psfhosted.org>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Do you get an error message when you start a command shell and type "python"?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40256>
_______________________________________

From report at bugs.python.org  Thu Apr 30 09:32:19 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Thu, 30 Apr 2020 13:32:19 +0000
Subject: [issue32494] interface to gdbm_count
In-Reply-To: <1515102093.85.0.467229070634.issue32494@psf.upfronthosting.co.za>
Message-ID: <1588253539.37.0.676442069659.issue32494@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
nosy: +corona10
nosy_count: 2.0 -> 3.0
pull_requests: +19134
pull_request: https://github.com/python/cpython/pull/19814

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32494>
_______________________________________

From report at bugs.python.org  Thu Apr 30 09:58:46 2020
From: report at bugs.python.org (Yusuf Mumtaz)
Date: Thu, 30 Apr 2020 13:58:46 +0000
Subject: [issue40256] Python 3.8 Not Launching on Bootcamp Windows 10.
In-Reply-To: <1586628271.16.0.0390251857061.issue40256@roundup.psfhosted.org>
Message-ID: <1588255126.61.0.440105687255.issue40256@roundup.psfhosted.org>


Yusuf Mumtaz <ymumtaz22 at gmail.com> added the comment:

Nope, no error message just no response from the system.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40256>
_______________________________________

From report at bugs.python.org  Thu Apr 30 10:09:35 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Thu, 30 Apr 2020 14:09:35 +0000
Subject: [issue32494] Use gdbm_count if possible
In-Reply-To: <1515102093.85.0.467229070634.issue32494@psf.upfronthosting.co.za>
Message-ID: <1588255775.09.0.099948247187.issue32494@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32494>
_______________________________________

From report at bugs.python.org  Thu Apr 30 10:27:34 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 30 Apr 2020 14:27:34 +0000
Subject: [issue40443] Remove unused imports in the stdlib (April 2020 edition)
In-Reply-To: <1588200148.3.0.742578477052.issue40443@roundup.psfhosted.org>
Message-ID: <1588256854.83.0.450076205554.issue40443@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +19135
pull_request: https://github.com/python/cpython/pull/19815

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40443>
_______________________________________

From report at bugs.python.org  Thu Apr 30 10:59:48 2020
From: report at bugs.python.org (E. Paine)
Date: Thu, 30 Apr 2020 14:59:48 +0000
Subject: [issue23937] IDLE: revise window size, placement startup options
In-Reply-To: <1428955532.11.0.740629698052.issue23937@psf.upfronthosting.co.za>
Message-ID: <1588258788.59.0.903410389471.issue23937@roundup.psfhosted.org>


Change by E. Paine <paineelisha at gmail.com>:


----------
keywords: +patch
nosy: +epaine
nosy_count: 4.0 -> 5.0
pull_requests: +19136
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19816

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23937>
_______________________________________

From report at bugs.python.org  Thu Apr 30 11:00:32 2020
From: report at bugs.python.org (E. Paine)
Date: Thu, 30 Apr 2020 15:00:32 +0000
Subject: [issue23937] IDLE: revise window size, placement startup options
In-Reply-To: <1428955532.11.0.740629698052.issue23937@psf.upfronthosting.co.za>
Message-ID: <1588258832.74.0.422876719168.issue23937@roundup.psfhosted.org>


E. Paine <paineelisha at gmail.com> added the comment:

I have made a few simple changes to the configdialog.py, config-main.def & editor.py which adds a "Maximised" checkbutton to the general page (just above the existing entries). The default is for this to be false (based on the previous comments in this PEP), but it is there for those of us that feel it would be a very nice feature.
Three questions:
1: Is changing the anchor on the label correct (visually) or is it better to leave it so that it centres?
2: Are we happy that the default should be for this to be disabled?
3: Is the description "max" sufficient for the configs

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23937>
_______________________________________

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: [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 11:24:45 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Thu, 30 Apr 2020 15:24:45 +0000
Subject: [issue39305] Merge nntplib._NNTPBase and nntplib.NNTP
In-Reply-To: <1578757948.77.0.383613154988.issue39305@roundup.psfhosted.org>
Message-ID: <1588260285.11.0.206022347964.issue39305@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
pull_requests: +19137
pull_request: https://github.com/python/cpython/pull/19817

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39305>
_______________________________________

From report at bugs.python.org  Thu Apr 30 11:25:59 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Thu, 30 Apr 2020 15:25:59 +0000
Subject: [issue40451] Unexpected sys.getrefcount(foo) output
In-Reply-To: <1588259890.93.0.389588994308.issue40451@roundup.psfhosted.org>
Message-ID: <1588260359.91.0.610130388449.issue40451@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

aux is equal to 1. You're seeing the refcount of the number 1.

----------
nosy: +eric.smith
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40451>
_______________________________________

From report at bugs.python.org  Thu Apr 30 11:31:22 2020
From: report at bugs.python.org (Tim Peters)
Date: Thu, 30 Apr 2020 15:31:22 +0000
Subject: [issue40451] Unexpected sys.getrefcount(foo) output
In-Reply-To: <1588259890.93.0.389588994308.issue40451@roundup.psfhosted.org>
Message-ID: <1588260682.24.0.782046912181.issue40451@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

"The 'aux' object" is simply the integer 1.  The dict is irrelevant to the outcome, except that the dict owns one reference to 1.  Do

sys.getrefcount(1)

all by itself and you'll see much the same.

This isn't a bug, but neither is it a feature:  it's undocumented, implementation-defined behavior.  It so happens that CPython treats a number of small integers as singletons, creating only one object for each, shared by all contexts that use the integer.

Here's from a fresh Python interactive session:

>>> from sys import getrefcount as r
>>> r(1)
94
>>> r(2)
76
>>> r(3)
27
>>> r(4)
49
>>> r(5)
23
>>> r(6)
11
>>> r(7)
13
>>> r(8)
35
>>> r(9)
13

Nothing about that is a bug, nor is anything about that defined behavior.  It just reflects how many times these small integers happen to be referenced by all the under-the-covers stuff that happened to get imported by the time the interactive prompt was displayed.

----------
nosy: +tim.peters

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40451>
_______________________________________

From report at bugs.python.org  Thu Apr 30 11:40:31 2020
From: report at bugs.python.org (E. Paine)
Date: Thu, 30 Apr 2020 15:40:31 +0000
Subject: [issue23937] IDLE: revise window size, placement startup options
In-Reply-To: <1428955532.11.0.740629698052.issue23937@psf.upfronthosting.co.za>
Message-ID: <1588261231.05.0.808953306052.issue23937@roundup.psfhosted.org>


E. Paine <paineelisha at gmail.com> added the comment:

Sorry, two more things:
1: Can someone please check this behaves properly on MacOS (I have checked on Windows and Linux)
2: Is setting the checkbutton side to "TOP" correct, or is there a better way of achieving the same layout?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23937>
_______________________________________

From report at bugs.python.org  Thu Apr 30 11:48:10 2020
From: report at bugs.python.org (Cristian Martinez de Morentin)
Date: Thu, 30 Apr 2020 15:48:10 +0000
Subject: [issue40451] Unexpected sys.getrefcount(foo) output
In-Reply-To: <1588259890.93.0.389588994308.issue40451@roundup.psfhosted.org>
Message-ID: <1588261690.63.0.313908642766.issue40451@roundup.psfhosted.org>


Cristian Martinez de Morentin <cmartinez at das-nano.com> added the comment:

OK, understood.

Thank you for your support!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40451>
_______________________________________

From report at bugs.python.org  Thu Apr 30 13:23:04 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 30 Apr 2020 17:23:04 +0000
Subject: [issue40334] PEP 617: new PEG-based parser
In-Reply-To: <1587327377.33.0.614039250584.issue40334@roundup.psfhosted.org>
Message-ID: <1588267384.03.0.245414626556.issue40334@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
pull_requests: +19138
pull_request: https://github.com/python/cpython/pull/19818

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40334>
_______________________________________

From report at bugs.python.org  Thu Apr 30 13:30:13 2020
From: report at bugs.python.org (Bowie Chen)
Date: Thu, 30 Apr 2020 17:30:13 +0000
Subject: [issue40442] Spurious warning emitted during fork() can deadlock a
 multi-threaded process
In-Reply-To: <1588193173.96.0.734255401294.issue40442@roundup.psfhosted.org>
Message-ID: <1588267813.71.0.796518341382.issue40442@roundup.psfhosted.org>


Change by Bowie Chen <bowiechen.github at gmail.com>:


----------
nosy: +bowiechen

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40442>
_______________________________________

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: [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 13:36:42 2020
From: report at bugs.python.org (E. Paine)
Date: Thu, 30 Apr 2020 17:36:42 +0000
Subject: [issue40452] IDLE preserve clipboard on closure (Windows)
In-Reply-To: <1588268147.56.0.852233274654.issue40452@roundup.psfhosted.org>
Message-ID: <1588268202.73.0.619585898684.issue40452@roundup.psfhosted.org>


Change by E. Paine <paineelisha at gmail.com>:


----------
keywords: +patch
pull_requests: +19139
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19819

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40452>
_______________________________________

From report at bugs.python.org  Thu Apr 30 13:59:53 2020
From: report at bugs.python.org (Carl Meyer)
Date: Thu, 30 Apr 2020 17:59:53 +0000
Subject: [issue40360] Deprecate lib2to3 (and 2to3) for future removal
In-Reply-To: <1587530454.25.0.44181585934.issue40360@roundup.psfhosted.org>
Message-ID: <1588269593.79.0.0616822720589.issue40360@roundup.psfhosted.org>


Carl Meyer <carl at oddbird.net> added the comment:

> Coul you please add a what's new entry for this change?

The committed change already included an entry in NEWS. Is a "What's New" entry something different?

> I don't understand why there is a PendingDeprecationWarning and not a DeprecationWarning.

Purely because I was following gps' recommendation in the first comment on this issue. Getting rid of PendingDeprecationWarning seems like an orthogonal decision; if it happens, this can trivially be upgraded to DeprecationWarning as part of a removal sweep.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40360>
_______________________________________

From report at bugs.python.org  Thu Apr 30 14:31:34 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 30 Apr 2020 18:31:34 +0000
Subject: [issue40360] Deprecate lib2to3 (and 2to3) for future removal
In-Reply-To: <1587530454.25.0.44181585934.issue40360@roundup.psfhosted.org>
Message-ID: <1588271494.46.0.333118336069.issue40360@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

A "What's New" entry would go into Doc/whatsnew/3.9.rst and is much more visible to users looking for exciting bits in the new release (the NEWS file is very large, see e.g. https://docs.python.org/3/whatsnew/changelog.html#changelog.

The What's New doc typically has a section collecting all the deprecations, e.g. https://docs.python.org/3/whatsnew/3.8.html#deprecated.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40360>
_______________________________________

From report at bugs.python.org  Thu Apr 30 14:31:46 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 30 Apr 2020 18:31:46 +0000
Subject: [issue40256] Python 3.8 Not Launching on Bootcamp Windows 10.
In-Reply-To: <1586628271.16.0.0390251857061.issue40256@roundup.psfhosted.org>
Message-ID: <1588271506.54.0.469824829146.issue40256@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

'their website' == Apple's website? Homebrew's? Microsoft's? What about the Windows installer from python.org?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40256>
_______________________________________

From report at bugs.python.org  Thu Apr 30 14:36:36 2020
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 30 Apr 2020 18:36:36 +0000
Subject: [issue39837] Make Azure Pipelines optional on GitHub PRs
In-Reply-To: <1583255119.77.0.277327127951.issue39837@roundup.psfhosted.org>
Message-ID: <1588271796.11.0.532223564756.issue39837@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

Done. You will need to check that miss-islington doesn't solely rely on required checks passing but instead all CI checks passing, otherwise this just turned off gating for PRs when auto-merging.

And I'm going to say future requests for this sort of stuff should happen on either on the core-workflow issue tracker or on discuss.python.org for better visibility.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39837>
_______________________________________

From report at bugs.python.org  Thu Apr 30 14:44:30 2020
From: report at bugs.python.org (=?utf-8?q?Miro_Hron=C4=8Dok?=)
Date: Thu, 30 Apr 2020 18:44:30 +0000
Subject: [issue40360] Deprecate lib2to3 (and 2to3) for future removal
In-Reply-To: <1587530454.25.0.44181585934.issue40360@roundup.psfhosted.org>
Message-ID: <1588272270.71.0.958652491549.issue40360@roundup.psfhosted.org>


Miro Hron?ok <miro at hroncok.cz> added the comment:

> Getting rid of PendingDeprecationWarning seems like an orthogonal decision; if it happens, this can trivially be upgraded to DeprecationWarning as part of a removal sweep.

My thought was that the decision was already made to do so. Hence adding new PendingDeprecationWarnings goes against that decision.

But maybe I misunderstand and that decision was not made.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40360>
_______________________________________

From report at bugs.python.org  Thu Apr 30 15:00:12 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 30 Apr 2020 19:00:12 +0000
Subject: [issue40408] GenericAlias does not support nested type variables
In-Reply-To: <1588003077.18.0.979842098769.issue40408@roundup.psfhosted.org>
Message-ID: <1588273212.39.0.270166942467.issue40408@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
assignee:  -> serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40408>
_______________________________________

From report at bugs.python.org  Thu Apr 30 15:08:37 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 30 Apr 2020 19:08:37 +0000
Subject: [issue40360] Deprecate lib2to3 (and 2to3) for future removal
In-Reply-To: <1587530454.25.0.44181585934.issue40360@roundup.psfhosted.org>
Message-ID: <1588273717.54.0.790912360841.issue40360@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

IIRC PendingDeprecationError does not mean that the decision hasn't been made yet. It just means it's less urgent for folks to worry about. I believe we tend to change PendingDeprecationError to DeprecationError in the last release before something is removed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40360>
_______________________________________

From report at bugs.python.org  Thu Apr 30 15:12:32 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 30 Apr 2020 19:12:32 +0000
Subject: [issue40334] PEP 617: new PEG-based parser
In-Reply-To: <1587327377.33.0.614039250584.issue40334@roundup.psfhosted.org>
Message-ID: <1588273952.8.0.283664070037.issue40334@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:


New changeset c001c09e9059ba04bc088349cd87a1374dc0754f by Guido van Rossum in branch 'master':
bpo-40334: Support type comments (GH-19780)
https://github.com/python/cpython/commit/c001c09e9059ba04bc088349cd87a1374dc0754f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40334>
_______________________________________

From report at bugs.python.org  Thu Apr 30 15:18:13 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 30 Apr 2020 19:18:13 +0000
Subject: [issue29587] Generator/coroutine 'throw' discards exc_info state,
 which is bad
In-Reply-To: <1487329309.81.0.182915384821.issue29587@psf.upfronthosting.co.za>
Message-ID: <1588274293.88.0.58906158451.issue29587@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:


New changeset 2514a632fb7d37be24c2059d0e286d35600f9795 by Chris Jerdonek in branch 'master':
bpo-29587: Enable implicit exception chaining with gen.throw() (GH-19811)
https://github.com/python/cpython/commit/2514a632fb7d37be24c2059d0e286d35600f9795


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29587>
_______________________________________

From report at bugs.python.org  Thu Apr 30 15:19:18 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 30 Apr 2020 19:19:18 +0000
Subject: [issue29587] Generator/coroutine 'throw' discards exc_info state,
 which is bad
In-Reply-To: <1487329309.81.0.182915384821.issue29587@psf.upfronthosting.co.za>
Message-ID: <1588274358.33.0.152325995389.issue29587@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

Example 1 is now fixed too by Chris Jerdonek's PR 19811. Thanks Chris!

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29587>
_______________________________________

From report at bugs.python.org  Thu Apr 30 15:24:24 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 30 Apr 2020 19:24:24 +0000
Subject: [issue23937] IDLE: revise window size, placement startup options
In-Reply-To: <1428955532.11.0.740629698052.issue23937@psf.upfronthosting.co.za>
Message-ID: <1588274664.44.0.285398815424.issue23937@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I think we are at the point where the General tab needs to be split into 2 tabs, or else widened.  On my Macbook, the bottom buttons are not visible.

One of the constraints of any change is that .idlerc/config-main.cfg remain compatible with older releases.

----------
versions: +Python 3.7, Python 3.8, Python 3.9 -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23937>
_______________________________________

From report at bugs.python.org  Thu Apr 30 15:34:16 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 30 Apr 2020 19:34:16 +0000
Subject: [issue29587] Generator/coroutine 'throw' discards exc_info state,
 which is bad
In-Reply-To: <1487329309.81.0.182915384821.issue29587@psf.upfronthosting.co.za>
Message-ID: <1588275256.94.0.192307502509.issue29587@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

Oh, no! Buildbot failures. Help?!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29587>
_______________________________________

From report at bugs.python.org  Thu Apr 30 15:37:44 2020
From: report at bugs.python.org (E. Paine)
Date: Thu, 30 Apr 2020 19:37:44 +0000
Subject: [issue23937] IDLE: revise window size, placement startup options
In-Reply-To: <1428955532.11.0.740629698052.issue23937@psf.upfronthosting.co.za>
Message-ID: <1588275464.74.0.492623987424.issue23937@roundup.psfhosted.org>


E. Paine <paineelisha at gmail.com> added the comment:

> I think we are at the point where the General tab needs to be split into 2 tabs, or else widened

I definitely agree (possibly split into "Window" and "Editor/Shell"), but that would be a separate PEP wouldn't it (possibly one that needs to be pulled before this one can proceed)?

> .idlerc/config-main.cfg [must] remain compatible with older releases

Would an new (unknown) option, therefore cause issues? I am just creating a new field, not changing/re-purposing an old one, which (correct me if I'm wrong) would just be ignored by old versions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23937>
_______________________________________

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: [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: [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:06:10 2020
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 30 Apr 2020 20:06:10 +0000
Subject: [issue37873] unittest: execute tests in parallel
In-Reply-To: <1565964928.02.0.804836557192.issue37873@roundup.psfhosted.org>
Message-ID: <1588277170.4.0.698132609584.issue37873@roundup.psfhosted.org>


Change by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
nosy: +giampaolo.rodola

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37873>
_______________________________________

From report at bugs.python.org  Thu Apr 30 16:07:59 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 30 Apr 2020 20:07:59 +0000
Subject: [issue40453] Add PyConfig._isolated_interpreter: isolated
 subinterpreters
In-Reply-To: <1588276857.13.0.360538290387.issue40453@roundup.psfhosted.org>
Message-ID: <1588277279.67.0.793376729615.issue40453@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
keywords: +patch
pull_requests: +19140
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19820

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40453>
_______________________________________

From report at bugs.python.org  Thu Apr 30 16:19:33 2020
From: report at bugs.python.org (Yusuf Mumtaz)
Date: Thu, 30 Apr 2020 20:19:33 +0000
Subject: [issue40256] Python 3.8 Not Launching on Bootcamp Windows 10.
In-Reply-To: <1586628271.16.0.0390251857061.issue40256@roundup.psfhosted.org>
Message-ID: <1588277973.39.0.0182757876864.issue40256@roundup.psfhosted.org>


Yusuf Mumtaz <ymumtaz22 at gmail.com> added the comment:

Sorry , the python windows installer from python.org

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40256>
_______________________________________

From report at bugs.python.org  Thu Apr 30 16:26:38 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 30 Apr 2020 20:26:38 +0000
Subject: [issue39837] Make Azure Pipelines optional on GitHub PRs
In-Reply-To: <1583255119.77.0.277327127951.issue39837@roundup.psfhosted.org>
Message-ID: <1588278398.72.0.573332315165.issue39837@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> Done.

Thanks.

> You will need to check that miss-islington doesn't solely rely on required checks passing but instead all CI checks passing, otherwise this just turned off gating for PRs when auto-merging.

I have no idea how miss-islington check CIs.

> And I'm going to say future requests for this sort of stuff should happen on either on the core-workflow issue tracker or on discuss.python.org for better visibility.

I'm used to report buildbot failures on bugs.python.org. Almost all issues are Python bugs, rather than issues specific to buidbot themselves.

I'm fine with reporting Azure Pipeline issues at core-workflow.

I created https://github.com/python/core-workflow/issues/365 " Make Travis CI (and Windows x64 ?) mandatory" :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39837>
_______________________________________

From report at bugs.python.org  Thu Apr 30 16:29:39 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 30 Apr 2020 20:29:39 +0000
Subject: [issue39321] AMD64 FreeBSD Non-Debug 3.x: out of swap space (test
 process killed by signal 9)
In-Reply-To: <1578925087.43.0.642221025557.issue39321@roundup.psfhosted.org>
Message-ID: <1588278579.29.0.418106897791.issue39321@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

The worker still has the same issue:
https://buildbot.python.org/all/#/builders/214/builds/674
0:19:08 load avg: 3.11 running: test_multiprocessing_forkserver (1 min 38 sec)
*** Signal 9

Any update on this issue Koobs?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39321>
_______________________________________

From report at bugs.python.org  Thu Apr 30 16:42:18 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 30 Apr 2020 20:42:18 +0000
Subject: [issue29587] Generator/coroutine 'throw' discards exc_info state,
 which is bad
In-Reply-To: <1487329309.81.0.182915384821.issue29587@psf.upfronthosting.co.za>
Message-ID: <1588279338.05.0.329909692756.issue29587@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy: +vstinner
nosy_count: 6.0 -> 7.0
pull_requests: +19141
pull_request: https://github.com/python/cpython/pull/19821

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29587>
_______________________________________

From report at bugs.python.org  Thu Apr 30 16:44:27 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 30 Apr 2020 20:44:27 +0000
Subject: [issue29587] Generator/coroutine 'throw' discards exc_info state,
 which is bad
In-Reply-To: <1487329309.81.0.182915384821.issue29587@psf.upfronthosting.co.za>
Message-ID: <1588279467.69.0.923673345805.issue29587@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 3c7f9db85095952821f9d106dd874f75662ce7ec by Victor Stinner in branch 'master':
Revert "bpo-29587: Enable implicit exception chaining with gen.throw() (GH-19811)" (#19821)
https://github.com/python/cpython/commit/3c7f9db85095952821f9d106dd874f75662ce7ec


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29587>
_______________________________________

From report at bugs.python.org  Thu Apr 30 16:46:52 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 30 Apr 2020 20:46:52 +0000
Subject: [issue29587] Generator/coroutine 'throw' discards exc_info state,
 which is bad
In-Reply-To: <1487329309.81.0.182915384821.issue29587@psf.upfronthosting.co.za>
Message-ID: <1588279612.67.0.757620417131.issue29587@roundup.psfhosted.org>


Change by Guido van Rossum <guido at python.org>:


----------
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29587>
_______________________________________

From report at bugs.python.org  Thu Apr 30 16:47:40 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 30 Apr 2020 20:47:40 +0000
Subject: [issue29587] Generator/coroutine 'throw' discards exc_info state,
 which is bad
In-Reply-To: <1487329309.81.0.182915384821.issue29587@psf.upfronthosting.co.za>
Message-ID: <1588279660.62.0.845970230008.issue29587@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> bpo-29587: Enable implicit exception chaining with gen.throw() (GH-19811)
> https://github.com/python/cpython/commit/2514a632fb7d37be24c2059d0e286d35600f9795

Sorry, I had to revert this change since it broke like 41+ buildbots:
https://pythondev.readthedocs.io/ci.html#revert-on-fail

Almost all CIs passed on the PR (except of the Ubuntu job of Azure Pipelines). That's unusual. No idea why the bug occurs only on some platforms and why it wasn't seen before.

The revert is an opportunity to get more time to investigate the issue, without having the pressure to have to fix the CI "ASAP".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29587>
_______________________________________

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: [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 17:01:40 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 30 Apr 2020 21:01:40 +0000
Subject: [issue1635741] Py_Finalize() doesn't clear all Python objects at exit
Message-ID: <1588280500.54.0.0909436264079.issue1635741@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +19142
pull_request: https://github.com/python/cpython/pull/19822

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1635741>
_______________________________________

From report at bugs.python.org  Thu Apr 30 17:02:46 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 30 Apr 2020 21:02:46 +0000
Subject: [issue29587] Generator/coroutine 'throw' discards exc_info state,
 which is bad
In-Reply-To: <1487329309.81.0.182915384821.issue29587@psf.upfronthosting.co.za>
Message-ID: <1588280566.44.0.193759074785.issue29587@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> Sorry, I had to revert this change since it broke like 41+ buildbots: (...)

If someone wants to investigate, you can find examples of failed buildbot builds at:
https://github.com/python/cpython/pull/19811

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29587>
_______________________________________

From report at bugs.python.org  Thu Apr 30 17:21:46 2020
From: report at bugs.python.org (Chris Jerdonek)
Date: Thu, 30 Apr 2020 21:21:46 +0000
Subject: [issue29587] Generator/coroutine 'throw' discards exc_info state,
 which is bad
In-Reply-To: <1487329309.81.0.182915384821.issue29587@psf.upfronthosting.co.za>
Message-ID: <1588281706.82.0.214002386722.issue29587@roundup.psfhosted.org>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

> Oh, no! Buildbot failures. Help?!

Yes, I'm sorry. There's something not so simple going on that I haven't yet reproduced locally. Will reply on the tracker.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29587>
_______________________________________

From report at bugs.python.org  Thu Apr 30 17:43:47 2020
From: report at bugs.python.org (Chris Jerdonek)
Date: Thu, 30 Apr 2020 21:43:47 +0000
Subject: [issue29587] Generator/coroutine 'throw' discards exc_info state,
 which is bad
In-Reply-To: <1487329309.81.0.182915384821.issue29587@psf.upfronthosting.co.za>
Message-ID: <1588283027.14.0.409627480421.issue29587@roundup.psfhosted.org>


Change by Chris Jerdonek <chris.jerdonek at gmail.com>:


----------
pull_requests: +19143
stage: resolved -> patch review
pull_request: https://github.com/python/cpython/pull/19823

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29587>
_______________________________________

From report at bugs.python.org  Thu Apr 30 18:09:25 2020
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 30 Apr 2020 22:09:25 +0000
Subject: [issue40453] Add PyConfig._isolated_interpreter: isolated
 subinterpreters
In-Reply-To: <1588276857.13.0.360538290387.issue40453@roundup.psfhosted.org>
Message-ID: <1588284565.99.0.709990194765.issue40453@roundup.psfhosted.org>


Change by Barry A. Warsaw <barry at python.org>:


----------
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40453>
_______________________________________

From report at bugs.python.org  Thu Apr 30 18:11:51 2020
From: report at bugs.python.org (Andy Lester)
Date: Thu, 30 Apr 2020 22:11:51 +0000
Subject: [issue40455] GCC 10 compiler warnings
In-Reply-To: <1588279868.77.0.13865368461.issue40455@roundup.psfhosted.org>
Message-ID: <1588284711.42.0.0493059508058.issue40455@roundup.psfhosted.org>


Change by Andy Lester <andy at petdance.com>:


----------
nosy: +petdance

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40455>
_______________________________________

From report at bugs.python.org  Thu Apr 30 18:15:09 2020
From: report at bugs.python.org (Ned Deily)
Date: Thu, 30 Apr 2020 22:15:09 +0000
Subject: [issue29587] Generator/coroutine 'throw' discards exc_info state,
 which is bad
In-Reply-To: <1487329309.81.0.182915384821.issue29587@psf.upfronthosting.co.za>
Message-ID: <1588284909.82.0.796664367758.issue29587@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

Whatever the resolution of this is, it seems to me that this sort of behavior change should not be introduced at this stage of 3.7.x's life.  Whether it should go into 3.8.x should be ?ukasz's call once the final change is in master and has stabilized.

----------
nosy: +ned.deily
versions:  -Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29587>
_______________________________________

From report at bugs.python.org  Thu Apr 30 18:24:59 2020
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 30 Apr 2020 22:24:59 +0000
Subject: [issue29587] Generator/coroutine 'throw' discards exc_info state,
 which is bad
In-Reply-To: <1487329309.81.0.182915384821.issue29587@psf.upfronthosting.co.za>
Message-ID: <1588285499.12.0.369906290289.issue29587@roundup.psfhosted.org>


Yury Selivanov <yselivanov at gmail.com> added the comment:

IMO this is a 3.9 fix.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29587>
_______________________________________

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: [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:26:22 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 30 Apr 2020 22:26:22 +0000
Subject: [issue22640] Add silent mode for py_compile
In-Reply-To: <1413361400.01.0.34334853586.issue22640@psf.upfronthosting.co.za>
Message-ID: <1588285582.9.0.0418329702472.issue22640@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

It seems like this change introduced a regression in main(): see https://bugs.python.org/issue40456

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22640>
_______________________________________

From report at bugs.python.org  Thu Apr 30 18:30:00 2020
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 30 Apr 2020 22:30:00 +0000
Subject: [issue40456] Complete adding silent mode for py_compile
In-Reply-To: <1588285530.29.0.122281949999.issue40456@roundup.psfhosted.org>
Message-ID: <1588285800.3.0.59104661515.issue40456@roundup.psfhosted.org>


Change by ?ric Araujo <merwok at netwok.org>:


----------
stage:  -> patch review
title: py_compile.main(): undefined name 'quiet' -> Complete adding silent mode for py_compile
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40456>
_______________________________________

From report at bugs.python.org  Thu Apr 30 18:30:28 2020
From: report at bugs.python.org (Gregory Shevchenko)
Date: Thu, 30 Apr 2020 22:30:28 +0000
Subject: [issue40456] Complete adding silent mode for py_compile
In-Reply-To: <1588285530.29.0.122281949999.issue40456@roundup.psfhosted.org>
Message-ID: <1588285828.23.0.722848700413.issue40456@roundup.psfhosted.org>


Change by Gregory Shevchenko <gvsheva at gmail.com>:


----------
keywords: +patch
nosy: +Gregory Shevchenko
nosy_count: 2.0 -> 3.0
pull_requests: +19144
pull_request: https://github.com/python/cpython/pull/17134

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40456>
_______________________________________

From report at bugs.python.org  Thu Apr 30 18:38:15 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 30 Apr 2020 22:38:15 +0000
Subject: [issue29587] Generator/coroutine 'throw' discards exc_info state,
 which is bad
In-Reply-To: <1487329309.81.0.182915384821.issue29587@psf.upfronthosting.co.za>
Message-ID: <1588286295.95.0.107907121455.issue29587@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

Could it be running out of memory due to excessive chaining of tracebacks?

(And yes, it's 3.9 only.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29587>
_______________________________________

From report at bugs.python.org  Thu Apr 30 18:40:05 2020
From: report at bugs.python.org (Ned Deily)
Date: Thu, 30 Apr 2020 22:40:05 +0000
Subject: [issue40448] ensurepip uses cache directory
In-Reply-To: <1588239551.95.0.236818491517.issue40448@roundup.psfhosted.org>
Message-ID: <1588286405.56.0.770794070922.issue40448@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


----------
nosy: +dstufft, ncoghlan, pradyunsg

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40448>
_______________________________________

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: [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 18:42:02 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 30 Apr 2020 22:42:02 +0000
Subject: [issue40188] Azure Pipelines jobs failing randomly with: Unable to
 connect to azure.archive.ubuntu.com
In-Reply-To: <1586038783.25.0.595016433162.issue40188@roundup.psfhosted.org>
Message-ID: <1588286522.4.0.833762897119.issue40188@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I didn't see the issue recently. Moreover, Brett asked me to report Azure issues to https://github.com/python/core-workflow/ instead. So I close this issue.

----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40188>
_______________________________________

From report at bugs.python.org  Thu Apr 30 18:42:29 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 30 Apr 2020 22:42:29 +0000
Subject: [issue39072] Azure Pipelines: git clone failed with: OpenSSL
 SSL_read: Connection was reset
In-Reply-To: <1576572752.23.0.326503724405.issue39072@roundup.psfhosted.org>
Message-ID: <1588286549.69.0.255854042814.issue39072@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I didn't see the issue recently. Moreover, Brett asked me to report Azure issues to https://github.com/python/core-workflow/ instead. So I close this issue.

----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39072>
_______________________________________

From report at bugs.python.org  Thu Apr 30 18:44:06 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 30 Apr 2020 22:44:06 +0000
Subject: [issue1635741] Py_Finalize() doesn't clear all Python objects at exit
Message-ID: <1588286646.94.0.698591813612.issue1635741@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset b66c0ff8af0c1a4adc6908897b2d05afc78cc27e by Victor Stinner in branch 'master':
bpo-1635741: Fix compiler warning in _stat.c (GH-19822)
https://github.com/python/cpython/commit/b66c0ff8af0c1a4adc6908897b2d05afc78cc27e


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1635741>
_______________________________________

From report at bugs.python.org  Thu Apr 30 18:44:49 2020
From: report at bugs.python.org (Mitch Lindgren)
Date: Thu, 30 Apr 2020 22:44:49 +0000
Subject: [issue40457] Python fails to compile/load _ssl module if OpenSSL is
 compiled with no-tls1-method
In-Reply-To: <1588286494.27.0.412005858691.issue40457@roundup.psfhosted.org>
Message-ID: <1588286689.77.0.114174844073.issue40457@roundup.psfhosted.org>


Mitch Lindgren <lindgren.mitch at gmail.com> added the comment:

I'd be happy to work on a patch for this. I think the simplest approach would be to change this block starting on line 3087:

    if (proto_version == PY_SSL_VERSION_TLS1)
        ctx = SSL_CTX_new(TLSv1_method());
#if HAVE_TLSv1_2
    else if (proto_version == PY_SSL_VERSION_TLS1_1)
        ctx = SSL_CTX_new(TLSv1_1_method());
    else if (proto_version == PY_SSL_VERSION_TLS1_2)
        ctx = SSL_CTX_new(TLSv1_2_method());
#endif
#ifndef OPENSSL_NO_SSL3
    else if (proto_version == PY_SSL_VERSION_SSL3)
        ctx = SSL_CTX_new(SSLv3_method());
#endif
#ifndef OPENSSL_NO_SSL2
    else if (proto_version == PY_SSL_VERSION_SSL2)
        ctx = SSL_CTX_new(SSLv2_method());
#endif
    else if (proto_version == PY_SSL_VERSION_TLS) /* SSLv23 */
        ctx = SSL_CTX_new(TLS_method());
    else if (proto_version == PY_SSL_VERSION_TLS_CLIENT)
        ctx = SSL_CTX_new(TLS_client_method());
    else if (proto_version == PY_SSL_VERSION_TLS_SERVER)
        ctx = SSL_CTX_new(TLS_server_method());
    else
        proto_version = -1;

into a switch and add additional #if !defined(OPENSSL_NO_XXX) macros to exclude version-specific methods. Please let me know if this sounds okay.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40457>
_______________________________________

From report at bugs.python.org  Thu Apr 30 18:45:06 2020
From: report at bugs.python.org (Ned Deily)
Date: Thu, 30 Apr 2020 22:45:06 +0000
Subject: [issue40444] multiprocessing.Pool deadlocks with only print statements
In-Reply-To: <1588200729.96.0.263407738291.issue40444@roundup.psfhosted.org>
Message-ID: <1588286706.37.0.570797996774.issue40444@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


----------
nosy: +davin, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40444>
_______________________________________

From report at bugs.python.org  Thu Apr 30 18:49:55 2020
From: report at bugs.python.org (Steve Dower)
Date: Thu, 30 Apr 2020 22:49:55 +0000
Subject: [issue39837] Make Azure Pipelines optional on GitHub PRs
In-Reply-To: <1583255119.77.0.277327127951.issue39837@roundup.psfhosted.org>
Message-ID: <1588286995.52.0.658240160823.issue39837@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Bugs in Python should continue to be reported here.

Requests to change the workflow should be discussed on one of the core-workflow groups (I think Discourse is the primary one now, right?). Once an action is agreed upon, it gets tracked on the core-workflow tracker. That's how we decided to turn Travis off and Azure Pipelines on in the first place.

Let's just hope that Travis has stabilised compared to when we switched away from it, and maybe they have enough capacity now to handle our busy periods.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39837>
_______________________________________

From report at bugs.python.org  Thu Apr 30 18:50:14 2020
From: report at bugs.python.org (Ned Deily)
Date: Thu, 30 Apr 2020 22:50:14 +0000
Subject: [issue40445] compileall.compile_dir docs aren't updated for bpo-38112
In-Reply-To: <1588203472.21.0.62841448361.issue40445@roundup.psfhosted.org>
Message-ID: <1588287014.32.0.171531227651.issue40445@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


----------
nosy: +petr.viktorin

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40445>
_______________________________________

From report at bugs.python.org  Thu Apr 30 18:51:20 2020
From: report at bugs.python.org (Steve Dower)
Date: Thu, 30 Apr 2020 22:51:20 +0000
Subject: [issue39837] Make Azure Pipelines optional on GitHub PRs
In-Reply-To: <1583255119.77.0.277327127951.issue39837@roundup.psfhosted.org>
Message-ID: <1588287080.56.0.541816680686.issue39837@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Oh, and Victor, you should probably email python-dev to let everyone know you requested this change and it's been made. Otherwise people may be surprised that it changed without any discussion or notification.

This is especially important if we have to disable all platforms other than Linux to avoid blocking PRs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39837>
_______________________________________

From report at bugs.python.org  Thu Apr 30 18:55:04 2020
From: report at bugs.python.org (Ned Deily)
Date: Thu, 30 Apr 2020 22:55:04 +0000
Subject: [issue40254] pyspecific directives are not translatable
In-Reply-To: <1586595169.2.0.635960834529.issue40254@roundup.psfhosted.org>
Message-ID: <1588287304.46.0.811843424042.issue40254@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


----------
nosy: +eric.araujo, ezio.melotti, mdk, willingc

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40254>
_______________________________________

From report at bugs.python.org  Thu Apr 30 18:59:15 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 30 Apr 2020 22:59:15 +0000
Subject: [issue39837] Make Azure Pipelines optional on GitHub PRs
In-Reply-To: <1583255119.77.0.277327127951.issue39837@roundup.psfhosted.org>
Message-ID: <1588287555.14.0.504648926437.issue39837@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> Let's just hope that Travis has stabilised compared to when we switched away from it, and maybe they have enough capacity now to handle our busy periods.

Can't we be more flexible depending on the stability on CIs over the last weeks? I mean making a CI optional if it becomes flaky, but also try to make a CI mandatory when it becomes stable.

In my experience, no CI is reliable and the stability varies a lot over time.

In the past, the macOS job was very reliable. I have no idea why it became so flaky, but I don't have the bandwidth to investigate, moreover it seems like some issues are internal to Azure Pipelines / GH Actions, and I don't have access to these.

I'm trying to do the best with my limited time.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39837>
_______________________________________

From report at bugs.python.org  Thu Apr 30 19:03:16 2020
From: report at bugs.python.org (Ned Deily)
Date: Thu, 30 Apr 2020 23:03:16 +0000
Subject: [issue39837] Make Azure Pipelines optional on GitHub PRs
In-Reply-To: <1583255119.77.0.277327127951.issue39837@roundup.psfhosted.org>
Message-ID: <1588287796.68.0.66068793118.issue39837@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

> In the past, the macOS job was very reliable. I have no idea why it became so flaky, but I don't have the bandwidth to investigate, moreover it seems like some issues are internal to Azure Pipelines / GH Actions, and I don't have access to these.

FWIW, I took a quick look at it and, with nothing to go on in the way of visible messages, the best guess I could come up with is that the test run step is hitting a time out and that, in that case, no status is shown. Anyone know if that is a reasonable guess?  The next question would be why are the tests taking that long on that macOS instance.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39837>
_______________________________________

From report at bugs.python.org  Thu Apr 30 19:05:57 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 30 Apr 2020 23:05:57 +0000
Subject: [issue39837] Make Azure Pipelines optional on GitHub PRs
In-Reply-To: <1583255119.77.0.277327127951.issue39837@roundup.psfhosted.org>
Message-ID: <1588287957.04.0.323447827994.issue39837@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Steve:
> Requests to change the workflow should be discussed on one of the core-workflow groups (I think Discourse is the primary one now, right?). Once an action is agreed upon, it gets tracked on the core-workflow tracker. That's how we decided to turn Travis off and Azure Pipelines on in the first place.

Ok.


> Oh, and Victor, you should probably email python-dev to let everyone know you requested this change and it's been made. Otherwise people may be surprised that it changed without any discussion or notification.

I'm not sure of what you mean by "no discussion", this issue has many comments.


> This is especially important if we have to disable all platforms other than Linux to avoid blocking PRs.

I would be more confident if we could make at least one Windows job mandatory.

I have no opinion on msg363405, so I'm fine with Brett choice ("we have to just rely on people paying attention to failures").

I don't know how to modify the Windows job to do nothing if it's a documentation change only.

macOS was already non-voting (optional), no?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39837>
_______________________________________

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: [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:12:40 2020
From: report at bugs.python.org (Steve Dower)
Date: Thu, 30 Apr 2020 23:12:40 +0000
Subject: [issue39837] Make Azure Pipelines optional on GitHub PRs
In-Reply-To: <1583255119.77.0.277327127951.issue39837@roundup.psfhosted.org>
Message-ID: <1588288360.52.0.71921008008.issue39837@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

> FWIW, I took a quick look at it and, with nothing to go on in the way of visible messages, the best guess I could come up with is that the test run step is hitting a time out and that, in that case, no status is shown. Anyone know if that is a reasonable guess?

I think it depends on the timeout. Some of my Ubuntu builds occasionally get hard-stuck on tkinter tests, so apparently it's possible for that to spoil CI. But I believe Pipelines is going to try and terminate the process "nicely" first.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39837>
_______________________________________

From report at bugs.python.org  Thu Apr 30 19:16:05 2020
From: report at bugs.python.org (Steve Dower)
Date: Thu, 30 Apr 2020 23:16:05 +0000
Subject: [issue39837] Make Azure Pipelines optional on GitHub PRs
In-Reply-To: <1583255119.77.0.277327127951.issue39837@roundup.psfhosted.org>
Message-ID: <1588288565.87.0.118703676101.issue39837@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

> I'm not sure of what you mean by "no discussion", this issue has many comments.

Let's say, no consensus. There were three votes cast in this discussion - yours (+1), mine (-1) and Brett's (I'll assume +0 because he made the change, despite saying he didn't want to ;) ).

Meanwhile, *everyone* is impacted, some people very negatively. The rest of the dev team need to know that it was a deliberate change.

> I would be more confident if we could make at least one Windows job mandatory.

Yes, so would I :)

> I don't know how to modify the Windows job to do nothing if it's a documentation change only.

I can do it when I get time, but it's not very high on my list. I suggest looking at the Azure Pipelines definition, kind of like how I looked at the Travis definition to figure it out.

> macOS was already non-voting (optional), no?

Only because you complained about it here :) That was PR 18818

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39837>
_______________________________________

From report at bugs.python.org  Thu Apr 30 19:35:20 2020
From: report at bugs.python.org (Shantanu)
Date: Thu, 30 Apr 2020 23:35:20 +0000
Subject: [issue39691] Allow passing Pathlike objects to io.open_code
In-Reply-To: <1582153350.45.0.111444771925.issue39691@roundup.psfhosted.org>
Message-ID: <1588289720.58.0.170991119784.issue39691@roundup.psfhosted.org>


Change by Shantanu <hauntsaninja at gmail.com>:


----------
keywords: +patch
nosy: +hauntsaninja
nosy_count: 3.0 -> 4.0
pull_requests: +19145
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19824

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39691>
_______________________________________

From report at bugs.python.org  Thu Apr 30 19:35:56 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 30 Apr 2020 23:35:56 +0000
Subject: [issue39837] Make Azure Pipelines optional on GitHub PRs
In-Reply-To: <1583255119.77.0.277327127951.issue39837@roundup.psfhosted.org>
Message-ID: <1588289756.31.0.957871917646.issue39837@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I understood that such issue should be discussed in the Core Workflow category of Discourse, so I created:

"Make one Windows CI job mandatory"
https://discuss.python.org/t/make-one-windows-ci-job-mandatory/4047

I suggest to continue the discussion there.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39837>
_______________________________________

From report at bugs.python.org  Thu Apr 30 19:41:59 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 30 Apr 2020 23:41:59 +0000
Subject: [issue39837] Make Azure Pipelines optional on GitHub PRs
In-Reply-To: <1583255119.77.0.277327127951.issue39837@roundup.psfhosted.org>
Message-ID: <1588290119.12.0.745811927889.issue39837@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Me:
> macOS was already non-voting (optional), no?

Steve:
> Only because you complained about it here :) That was PR 18818

Alright, I forgot about the whole history. Well, it's not my fault if macOS decided to fail :-)

I did my part, I fixed os.getgrouplist() which started (!?) to fail on the macOS job of Azure (in fact, it was an old issue which wasn't noticed previously): https://bugs.python.org/issue40014

I'm not sure what to do with macOS job which never starts or fail with empty logs. I don't see what we can do on the Python side. It *seems* to be more on the Azure side which is a blackbox to me. Maybe Steve you may ask around you at Microsoft? If you feel that you can do something to unblock the situation, please open an issue.

Note: I would also prefer to have a voting macOS job, but it's not like I can fix the macOS job myself, so I let others handle this one ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39837>
_______________________________________

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: [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:46:09 2020
From: report at bugs.python.org (Andy Lester)
Date: Thu, 30 Apr 2020 23:46:09 +0000
Subject: [issue40455] GCC 10 compiler warnings
In-Reply-To: <1588279868.77.0.13865368461.issue40455@roundup.psfhosted.org>
Message-ID: <1588290369.11.0.451419703148.issue40455@roundup.psfhosted.org>


Andy Lester <andy at petdance.com> added the comment:

Did you add any options to the ./configure call for cpython?  What were they?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40455>
_______________________________________

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: [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: [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: [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>
_______________________________________

From report at bugs.python.org  Thu Apr 30 19:53:15 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 30 Apr 2020 23:53:15 +0000
Subject: [issue40462] [easy] undefined name in Lib/test/mock_socket.py
In-Reply-To: <1588290630.2.0.182306583677.issue40462@roundup.psfhosted.org>
Message-ID: <1588290795.52.0.87654141913.issue40462@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Another one:

Lib/test/test_frame.py:53:17 undefined name 'inner'

I guess that self.inner() should be used instead of inner(). In practice, it's dead code, but fixing it would make pyflakes happier :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40462>
_______________________________________

From report at bugs.python.org  Thu Apr 30 19:59:30 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 30 Apr 2020 23:59:30 +0000
Subject: [issue40462] [easy] undefined name in Lib/test/mock_socket.py
In-Reply-To: <1588290630.2.0.182306583677.issue40462@roundup.psfhosted.org>
Message-ID: <1588291170.81.0.897098341137.issue40462@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Another one:

Lib/test/test_json/test_recursion.py:55:24 undefined name 'pyjson'

Code:

    def test_defaultrecursion(self):
        class RecursiveJSONEncoder(self.json.JSONEncoder):
            recurse = False
            def default(self, o):
                if o is JSONTestObject:
                    if self.recurse:
                        return [JSONTestObject]
                    else:
                        return 'JSONTestObject'
                return pyjson.JSONEncoder.default(o)

Here I'm not sure. *Maybe* pyjson.JSONEncoder should be replaced with self.json.JSONEncoder?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40462>
_______________________________________

From report at bugs.python.org  Thu Apr 30 20:00:42 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 01 May 2020 00:00:42 +0000
Subject: [issue40334] PEP 617: new PEG-based parser
In-Reply-To: <1587327377.33.0.614039250584.issue40334@roundup.psfhosted.org>
Message-ID: <1588291242.43.0.721365766276.issue40334@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Warnings found by pyflakes:

Lib/test/test_tools/test_c_analyzer/test_parser/test_declarations.py:115:31 undefined name 'lines'
Lib/test/test_tools/test_c_analyzer/test_parser/test_declarations.py:116:25 undefined name 'lines'
Lib/test/test_tools/test_c_analyzer/test_parser/test_declarations.py:527:42 undefined name 'stmt'
Lib/test/test_tools/test_c_analyzer/test_parser/test_declarations.py:527:48 undefined name 'blocks'

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40334>
_______________________________________

From report at bugs.python.org  Thu Apr 30 20:04:31 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 01 May 2020 00:04:31 +0000
Subject: [issue40462] [easy] undefined name in Lib/test/mock_socket.py
In-Reply-To: <1588290630.2.0.182306583677.issue40462@roundup.psfhosted.org>
Message-ID: <1588291471.11.0.895984809651.issue40462@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Another one:

Lib/unittest/test/test_program.py:191:40 undefined name 'hasInstallHandler'

Code:

    def testBufferCatchFailfast(self):
        program = self.program
        for arg, attr in (('buffer', 'buffer'), ('failfast', 'failfast'),
                      ('catch', 'catchbreak')):
            if attr == 'catch' and not hasInstallHandler:
                continue
            ...

attr is never equal to 'catch' and so it's just dead code which can be removed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40462>
_______________________________________

From report at bugs.python.org  Thu Apr 30 20:08:17 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 01 May 2020 00:08:17 +0000
Subject: [issue40275] test.support has way too many imports
In-Reply-To: <1586816691.28.0.874442798421.issue40275@roundup.psfhosted.org>
Message-ID: <1588291697.23.0.636592392396.issue40275@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +19146
pull_request: https://github.com/python/cpython/pull/19825

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40275>
_______________________________________

From report at bugs.python.org  Thu Apr 30 20:14:32 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 01 May 2020 00:14:32 +0000
Subject: [issue40455] GCC 10 compiler warnings
In-Reply-To: <1588279868.77.0.13865368461.issue40455@roundup.psfhosted.org>
Message-ID: <1588292072.53.0.477809001438.issue40455@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Andy Lester:
> Did you add any options to the ./configure call for cpython?  What were they?

I reported warnings that I saw on a buildbot build.

Extract of https://buildbot.python.org/all/#/builders/351/builds/406.

configure step:

    ./configure --prefix '$(PWD)/target' --with-lto

test.pythoninfo of the build says:

CC.version: gcc (GCC) 10.0.1 20200420 (Red Hat 10.0.1-0.12)

sysconfig[CCSHARED]: -fPIC
sysconfig[CC]: gcc -pthread
sysconfig[CFLAGS]: -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall
sysconfig[CONFIG_ARGS]: '--prefix' '/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-ppc64le.lto/build/target' '--with-lto'
sysconfig[OPT]: -DNDEBUG -g -fwrapv -O3 -Wall
sysconfig[PY_CFLAGS]: -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall
sysconfig[PY_CFLAGS_NODIST]: -flto -fuse-linker-plugin -ffat-lto-objects -flto-partition=none -g -std=c99 -Wextra -Wno-unused-result -Wno-unused-parameter -Wno-missing-field-initializers -Werror=implicit-function-declaration -fvisibility=hidden -I./Include/internal
sysconfig[PY_CORE_LDFLAGS]: -flto -fuse-linker-plugin -ffat-lto-objects -flto-partition=none -g
sysconfig[PY_LDFLAGS_NODIST]: -flto -fuse-linker-plugin -ffat-lto-objects -flto-partition=none -g
sysconfig[PY_STDMODULE_CFLAGS]: -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -flto -fuse-linker-plugin -ffat-lto-objects -flto-partition=none -g -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

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40455>
_______________________________________

From report at bugs.python.org  Thu Apr 30 20:33:08 2020
From: report at bugs.python.org (Lysandros Nikolaou)
Date: Fri, 01 May 2020 00:33:08 +0000
Subject: [issue40334] PEP 617: new PEG-based parser
In-Reply-To: <1587327377.33.0.614039250584.issue40334@roundup.psfhosted.org>
Message-ID: <1588293188.01.0.552648272461.issue40334@roundup.psfhosted.org>


Change by Lysandros Nikolaou <lisandrosnik at gmail.com>:


----------
pull_requests: +19147
pull_request: https://github.com/python/cpython/pull/19827

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40334>
_______________________________________

From report at bugs.python.org  Thu Apr 30 20:35:28 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 01 May 2020 00:35:28 +0000
Subject: [issue40275] test.support has way too many imports
In-Reply-To: <1586816691.28.0.874442798421.issue40275@roundup.psfhosted.org>
Message-ID: <1588293328.07.0.980906753143.issue40275@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 2935e65c36fab1989bbda19db72c035ea22b044b by Victor Stinner in branch 'master':
bpo-40275: Fix name error in support.socket_helper (GH-19825)
https://github.com/python/cpython/commit/2935e65c36fab1989bbda19db72c035ea22b044b


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40275>
_______________________________________

From report at bugs.python.org  Thu Apr 30 20:38:04 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 01 May 2020 00:38:04 +0000
Subject: [issue40443] Remove unused imports in the stdlib (April 2020 edition)
In-Reply-To: <1588200148.3.0.742578477052.issue40443@roundup.psfhosted.org>
Message-ID: <1588293484.29.0.364180163097.issue40443@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset eb0d359b4b0e14552998e7af771a088b4fd01745 by Victor Stinner in branch 'master':
bpo-40443: Remove unused imports in stdlib (GH-19815)
https://github.com/python/cpython/commit/eb0d359b4b0e14552998e7af771a088b4fd01745


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40443>
_______________________________________

From report at bugs.python.org  Thu Apr 30 20:38:25 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 01 May 2020 00:38:25 +0000
Subject: [issue40443] Remove unused imports in the stdlib (April 2020 edition)
In-Reply-To: <1588200148.3.0.742578477052.issue40443@roundup.psfhosted.org>
Message-ID: <1588293505.03.0.66355905063.issue40443@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Thanks for reviews!

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40443>
_______________________________________

From report at bugs.python.org  Thu Apr 30 22:42:47 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 01 May 2020 02:42:47 +0000
Subject: [issue40334] PEP 617: new PEG-based parser
In-Reply-To: <1587327377.33.0.614039250584.issue40334@roundup.psfhosted.org>
Message-ID: <1588300967.9.0.30530254184.issue40334@roundup.psfhosted.org>


Change by Guido van Rossum <guido at python.org>:


----------
pull_requests: +19148
pull_request: https://github.com/python/cpython/pull/19828

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40334>
_______________________________________

From report at bugs.python.org  Thu Apr 30 22:45:19 2020
From: report at bugs.python.org (Kubilay Kocak)
Date: Fri, 01 May 2020 02:45:19 +0000
Subject: [issue39321] AMD64 FreeBSD Non-Debug 3.x: out of swap space (test
 process killed by signal 9)
In-Reply-To: <1578925087.43.0.642221025557.issue39321@roundup.psfhosted.org>
Message-ID: <1588301119.71.0.0891928513095.issue39321@roundup.psfhosted.org>


Kubilay Kocak <koobs.freebsd at gmail.com> added the comment:

Provisioning new/additional swap to both of FreeBSD BB workers in the next few days. Apologies for the delay

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39321>
_______________________________________

From report at bugs.python.org  Thu Apr 30 22:55:31 2020
From: report at bugs.python.org (Eric Snow)
Date: Fri, 01 May 2020 02:55:31 +0000
Subject: [issue32604] Expose the subinterpreters C-API in Python for testing
 use.
In-Reply-To: <1516413482.13.0.467229070634.issue32604@psf.upfronthosting.co.za>
Message-ID: <1588301731.19.0.0809111578597.issue32604@roundup.psfhosted.org>


Change by Eric Snow <ericsnowcurrently at gmail.com>:


----------
pull_requests: +19149
pull_request: https://github.com/python/cpython/pull/19829

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32604>
_______________________________________

From report at bugs.python.org  Thu Apr 30 22:57:51 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 01 May 2020 02:57:51 +0000
Subject: [issue40334] PEP 617: new PEG-based parser
In-Reply-To: <1587327377.33.0.614039250584.issue40334@roundup.psfhosted.org>
Message-ID: <1588301871.22.0.782701769491.issue40334@roundup.psfhosted.org>


Change by Guido van Rossum <guido at python.org>:


----------
pull_requests: +19150
pull_request: https://github.com/python/cpython/pull/19830

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40334>
_______________________________________

From report at bugs.python.org  Thu Apr 30 23:27:59 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 01 May 2020 03:27:59 +0000
Subject: [issue40334] PEP 617: new PEG-based parser
In-Reply-To: <1587327377.33.0.614039250584.issue40334@roundup.psfhosted.org>
Message-ID: <1588303679.92.0.17386592764.issue40334@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:


New changeset 3e0a6f37dfdd595be737baae00ec0e036a912615 by Lysandros Nikolaou in branch 'master':
bpo-40334: Add support for feature_version in new PEG parser (GH-19827)
https://github.com/python/cpython/commit/3e0a6f37dfdd595be737baae00ec0e036a912615


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40334>
_______________________________________