[issue36129] io documentation unclear about flush() and close() semantics for wrapped streams

Change by Daniel Holth : -- nosy: +dholth ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue40233] Awkward to set compression on writeable ZipFile.open()

Daniel Holth added the comment: My mistake. It honors ZipInfo if passed. -- stage: -> resolved status: open -> closed ___ Python tracker ___

[issue39943] Meta: Clean up various issues in C internals

Change by Andy Lester : -- pull_requests: +18800 pull_request: https://github.com/python/cpython/pull/19445 ___ Python tracker ___

[issue40230] Itertools.product() Out of Memory Errors

Tim Peters 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.

[issue40235] confusing documentation for IOBase.__exit__

New submission from Daniel Holth : 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:

[issue38501] multiprocessing.Pool hangs atexit (and garbage collection sometimes)

Change by Andrew Nelson : -- nosy: +Andrew Nelson ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue40230] Itertools.product() Out of Memory Errors

Change by Dennis Sweeney : -- versions: +Python 3.9 -Python 3.7 ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue40230] Itertools.product() Out of Memory Errors

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

[issue39010] ProactorEventLoop raises unhandled ConnectionResetError

Change by Peter Lovett : -- nosy: +PeterL777 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue37266] Daemon threads must be forbidden in subinterpreters

Eric Snow added the comment: I've opened bpo-40234 to address backward incompatibility from this change (e.g. affecting mod-wsgi). -- ___ Python tracker ___

[issue40234] Disallow daemon threads in subinterpreters optionally.

New submission from Eric Snow : 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

[issue40233] Awkward to set compression on writeable ZipFile.open()

New submission from Daniel Holth : 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

[issue33608] Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed.

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

[issue39891] [difflib] Improve get_close_matches() to better match when casing of words are different

brian.gallagher 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

[issue40112] AIX: xlc - default path changed and no longer recognized

Change by STINNER Victor : -- pull_requests: +18798 pull_request: https://github.com/python/cpython/pull/19444 ___ Python tracker ___

[issue40077] Convert static types to PyType_FromSpec()

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

[issue40204] Docs build error with Sphinx 3.0 due to invalid C declaration

Change by STINNER Victor : -- pull_requests: +18797 pull_request: https://github.com/python/cpython/pull/19443 ___ Python tracker ___

[issue40204] Docs build error with Sphinx 3.0 due to invalid C declaration

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

[issue22598] Add mUTF-7 codec (UTF-7 modified for IMAP)

Change by STINNER Victor : -- nosy: -vstinner ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue40204] Docs build error with Sphinx 3.0 due to invalid C declaration

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

[issue40204] Docs build error with Sphinx 3.0 due to invalid C declaration

Change by STINNER Victor : -- pull_requests: +18796 pull_request: https://github.com/python/cpython/pull/19442 ___ Python tracker ___

[issue40204] Docs build error with Sphinx 3.0 due to invalid C declaration

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

[issue40216] Support --runstatedir in configure

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

[issue33608] Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed.

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

[issue39984] Move pending calls from _PyRuntime to PyInterpreterState

STINNER Victor 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 ___

[issue33608] Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed.

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

[issue33608] Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed.

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

[issue40232] PyOS_AfterFork_Child() should use _PyThread_at_fork_reinit()

New submission from STINNER Victor : 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 =

[issue40231] Fix pending calls in subinterpreters

STINNER Victor 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)

[issue33608] Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed.

STINNER Victor added the comment: I created bpo-40231: Fix pending calls in subinterpreters. -- ___ Python tracker ___ ___

[issue40082] trip_signal() gets NULL tstate on Windows on CTRL+C

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

[issue40082] trip_signal() gets NULL tstate on Windows on CTRL+C

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

[issue40231] Fix pending calls in subinterpreters

New submission from STINNER Victor : 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

[issue33608] Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed.

Change by David Bolen : -- nosy: -db3l ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue37127] Handling pending calls during runtime finalization may cause problems.

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

[issue33608] Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed.

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

[issue37127] Handling pending calls during runtime finalization may cause problems.

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

[issue40082] trip_signal() gets NULL tstate on Windows on CTRL+C

Change by STINNER Victor : -- keywords: +patch pull_requests: +18795 stage: -> patch review pull_request: https://github.com/python/cpython/pull/19441 ___ Python tracker ___

[issue40216] Support --runstatedir in configure

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

[issue40230] Itertools.product() Out of Memory Errors

Change by Zachary Ware : -- components: +Library (Lib) -Distutils nosy: +rhettinger -dstufft, eric.araujo stage: -> test needed ___ Python tracker ___

[issue40230] Itertools.product() Out of Memory Errors

New submission from Henry Carscadden : 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

[issue37127] Handling pending calls during runtime finalization may cause problems.

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

[issue40214] test_ctypes.test_load_dll_with_flags Windows failure

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

[issue39010] ProactorEventLoop raises unhandled ConnectionResetError

Rustam S. 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

[issue35455] Solaris thread_time doesn't work with current implementation

Jakub Kulik 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 ;). --

[issue35455] Solaris thread_time doesn't work with current implementation

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

[issue40214] test_ctypes.test_load_dll_with_flags Windows failure

Steve Dower 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:

[issue40229] tty unblocking setraw and save-restore features

Change by Roundup Robot : -- 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

[issue39984] Move pending calls from _PyRuntime to PyInterpreterState

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

[issue40229] tty unblocking setraw and save-restore features

New submission from Steven Lu : 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

[issue37127] Handling pending calls during runtime finalization may cause problems.

STINNER Victor added the comment: See also bpo-40082: trip_signal() gets NULL tstate on Windows on CTRL+C. -- ___ Python tracker ___

[issue40082] Assertion failure in trip_signal

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

[issue40082] trip_signal() gets NULL tstate on Windows on CTRL+C

Change by STINNER Victor : -- title: Assertion failure in trip_signal -> trip_signal() gets NULL tstate on Windows on CTRL+C ___ Python tracker ___

[issue40154] embedded null byte when connecting to sqlite database using a bytes object

SilentGhost 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

[issue37127] Handling pending calls during runtime finalization may cause problems.

Change by STINNER Victor : -- pull_requests: +18793 pull_request: https://github.com/python/cpython/pull/19439 ___ Python tracker ___

[issue40077] Convert static types to PyType_FromSpec()

Change by hai shi : -- pull_requests: +18792 pull_request: https://github.com/python/cpython/pull/19438 ___ Python tracker ___ ___

[issue40214] test_ctypes.test_load_dll_with_flags Windows failure

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

[issue40228] Make setting line number in frame more robust.

Change by Serhiy Storchaka : -- nosy: +serhiy.storchaka ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue40228] Make setting line number in frame more robust.

Change by Mark Shannon : -- keywords: +patch pull_requests: +18791 stage: -> patch review pull_request: https://github.com/python/cpython/pull/19437 ___ Python tracker ___

[issue40226] Leak in tstate->interp->ceval.pending

STINNER Victor added the comment: Fixed, thanks for the bug report Stefan ;-) -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker

[issue40226] Leak in tstate->interp->ceval.pending

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

[issue40228] Make setting line number in frame more robust.

New submission from Mark Shannon : 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

[issue40226] Leak in tstate->interp->ceval.pending

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

[issue40226] Leak in tstate->interp->ceval.pending

Change by STINNER Victor : -- keywords: +patch pull_requests: +18790 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/19436 ___ Python tracker

[issue39851] tarfile: Exception ignored in (... stdout ...) BrokenPipeError

Change by Dong-hee Na : -- keywords: +patch Added file: https://bugs.python.org/file49046/bpo-39851.patch ___ Python tracker ___

[issue40227] SSLError is not passed to the client during handshake

New submission from Ivan Ivanyuk : 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

[issue36287] Make ast.dump() not output optional default fields

Batuhan Taskaya added the comment: Adding issue 39981 as a dependency. -- dependencies: +Default values for AST Nodes ___ Python tracker ___

[issue40154] embedded null byte when connecting to sqlite database using a bytes object

Change by Fernando : -- components: +Extension Modules -IO ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue39851] tarfile: Exception ignored in (... stdout ...) BrokenPipeError

Dong-hee Na 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.

[issue40154] embedded null byte when connecting to sqlite database using a bytes object

Fernando added the comment: bump? -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue40225] generator exhaustion for builtin functions in nested call is O(depth)

Change by brendon zhang : -- title: generator exhaustion for builtin functions in recursion is O(depth) -> generator exhaustion for builtin functions in nested call is O(depth) ___ Python tracker

[issue40225] generator exhaustion for builtin functions in recursion is O(depth)

Change by brendon zhang : -- title: max() performance regression (quadratic time) -> generator exhaustion for builtin functions in recursion is O(depth) ___ Python tracker

[issue40225] max() performance regression (quadratic time)

brendon zhang added the comment: this affects ALL builtin functions (eg all(), any(), sum(), sorted(), etc...) that accept generator as input and exhaust it. -- ___ Python tracker

[issue40225] max() performance regression (quadratic time)

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

[issue34033] distutils is not reproducible

Change by Jeffery To : -- nosy: +jefferyto ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue29708] support reproducible Python builds

Change by Jeffery To : -- nosy: +jefferyto ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue37596] Reproducible pyc: frozenset is not serialized in a deterministic order

Change by Jeffery To : -- nosy: +jefferyto ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue39481] Implement PEP 585 (Type Hinting Generics In Standard Collections)

Change by Batuhan Taskaya : -- pull_requests: +18789 pull_request: https://github.com/python/cpython/pull/19435 ___ Python tracker ___

[issue40224] delete_me

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

[issue40225] max() performance regression (quadratic time)

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

[issue40226] Leak in tstate->interp->ceval.pending

New submission from Stefan Krah : 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

[issue40225] max() performance regression (quadratic time)

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

[issue39481] Implement PEP 585 (Type Hinting Generics In Standard Collections)

Change by Batuhan Taskaya : -- pull_requests: +18788 pull_request: https://github.com/python/cpython/pull/19434 ___ Python tracker ___

[issue40225] max() performance regression (quadratic time)

New submission from brendon zhang : 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:

[issue40224] delete_me

Change by keyboardAnt : -- components: -macOS title: Execute a @staticmethod (Python 3.8.2) -> delete_me versions: -Python 3.8 ___ Python tracker ___

[issue40224] Execute a @staticmethod (Python 3.8.2)

Change by keyboardAnt : Removed file: https://bugs.python.org/file49042/example.py ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue40224] Execute a @staticmethod (Python 3.8.2)

New submission from keyboardAnt : 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

[issue40223] Add -fwrapv for new icc versions

New submission from Stefan Krah : 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

[issue40222] "Zero cost" exception handling

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

[issue40222] "Zero cost" exception handling

New submission from Mark Shannon : 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

[issue40187] Refactor typing.TypedDict

Change by Serhiy Storchaka : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue40185] Refactor typing.NamedTuple

Change by Serhiy Storchaka : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue40187] Refactor typing.TypedDict

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

[issue40185] Refactor typing.NamedTuple

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