Mailman 3 December 2019 - Python-Dev

PEP 611 - saturating reference counts
by Random832 12 Dec '19

12 Dec '19

as an aside in the portion of PEP 611 proposing a limit to the number of classes, the proposal also mentioned reducing the size of the reference count field to achieve part of its object size savings. one of the mechanisms proposed was to implement a "saturating" reference count, though it would be different from conventional saturating arithmetic in that any object that reaches the maximum refcount would become immortal, since we could not trust decref from there to account for all references. something that may be worth considering or testing is: what would the cost, both in performance and interpreter code size, of implementing this logic on every single incref and decref?

1 0

PEP proposal to limit various aspects of a Python program to one million.
by Mark Shannon 12 Dec '19

12 Dec '19

Hi Everyone, I am proposing a new PEP, still in draft form, to impose a limit of one million on various aspects of Python programs, such as the lines of code per module. Any thoughts or feedback? The PEP: https://github.com/markshannon/peps/blob/one-million/pep-1000000.rst Cheers, Mark. Full text ********* PEP: 1000000 Title: The one million limit Author: Mark Shannon <mark(a)hotpy.org> Status: Active Type: Enhancement Content-Type: text/x-rst Created: 03-Dec-2019 Post-History: Abstract ======== This PR proposes a limit of one million (1 000 000) for various aspects of Python code and its implementation. The Python language does not specify limits for many of its features. Not having any limit to these values seems to enhance programmer freedom, at least superficially, but in practice the CPython VM and other Python virtual machines have implicit limits or are forced to assume that the limits are astronomical, which is expensive. This PR lists a number of features which are to have a limit of one million. If a language feature is not listed but appears unlimited and must be finite, for physical reasons if no other, then a limit of one million should be assumed. Motivation ========== There are many values that need to be represented in a virtual machine. If no limit is specified for these values, then the representation must either be inefficient or vulnerable to overflow. The CPython virtual machine represents values like line numbers, stack offsets and instruction offsets by 32 bit values. This is inefficient, and potentially unsafe. It is inefficient as actual values rarely need more than a dozen or so bits to represent them. It is unsafe as malicious or poorly generated code could cause values to exceed 2\ :sup:`32`. For example, line numbers are represented by 32 bit values internally. This is inefficient, given that modules almost never exceed a few thousand lines. Despite being inefficent, is is still vulnerable to overflow as it is easy for an attacker to created a module with billions of newline characters. Memory access is usually a limiting factor in the performance of modern CPUs. Better packing of data structures enhances locality and reduces memory bandwith, at a modest increase in ALU usage (for shifting and masking). Being able to safely store important values in 20 bits would allow memory savings in several data structures including, but not limited to: * Frame objects * Object headers * Code objects There is also the potential for a more efficient instruction format, speeding up interpreter dispatch. Rationale ========= Imposing a limit on values such as lines of code in a module, and the number of local variables, has significant advantages for ease of implementation and efficiency of virtual machines. If the limit is sufficiently large, there is no adverse effect on users of the language. By selecting a fixed but large limit for these values, it is possible to have both safety and efficiency whilst causing no inconvience to human programmers and only very rare problems for code generators. One million ----------- The Java Virtual Machine (JVM) [1]_ specifies a limit of 2\ :sup:`16`-1 (65535) for many program elements similar to those covered here. This limit enables limited values to fit in 16 bits, which is a very efficient machine representation. However, this limit is quite easily exceeded in practice by code generators and the author is aware of existing Python code that already exceeds 2\ :sup:`16` lines of code. A limit of one million fits into 20 bits which, although not as convenient for machine representation, is still reasonably compact. Three signed valuses in the range -1000_000 to +1000_000 can fit into a 64 bit word. A limit of one million is small enough for efficiency advantages (only 20 bits), but large enough not to impact users (no one has ever written a module of one million lines). The value "one million" is very easy to remember. Isn't this "640K ought to be enough for anybody" again? ------------------------------------------------------- The infamous 640K memory limit was a limit on machine usable resources. The proposed one million limit is a limit on human generated code. While it is possible that generated code could exceed the limit, it is easy for a code generator to modify its output to conform. The author has hit the 64K limit in the JVM on at least two occasions when generating Java code. The workarounds were relatively straightforward and probably wouldn't have been necessary with a limit of one million bytecodes or lines of code. Specification ============= This PR proposes that the following language features and runtime values be limited to one million. * The number of source code lines in a module * The number of bytecode instructions in a code object. * The sum of local variables and stack usage for a code object. * The number of distinct names in a code object * The number of constants in a code object. * The number of classes in a running interpreter. * The number of live coroutines in a running interpreter. The advantages for CPython of imposing these limits: ---------------------------------------------------- Line of code in a module and code object restrictions. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ When compiling source code to bytecode or modifying bytecode for profiling or debugging, an intermediate form is required. The limiting line numbers and operands to 20 bits, instructions can be represented in a compact 64 bit form allowing very fast passes over the instruction sequence. Having 20 bit operands (21 bits for relative branches) allows instructions to fit into 32 bits without needing additional ``EXTENDED_ARG`` instructions. This improves dispatch, as the operand is strictly local to the instruction. Using super-instructions would make that the 32 bit format almost as compact as the 16 bit format, and significantly faster. Total number of classes in a running interpreter ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This limit has to the potential to reduce the size of object headers considerably. Currently objects have a two word header, for objects without references (int, float, str, etc.) or a four word header for objects with references. By reducing the maximum number of classes, the space for the class reference can be reduced from 64 bits to fewer than 32 bits allowing a much more compact header. For example, a super-compact header format might look like this: .. code-block:: struct header { uint32_t gc_flags:6; /* Needs finalisation, might be part of a cycle, etc. */ uint32_t class_id:26; /* Can be efficiently mapped to address by ensuring suitable alignment of classes */ uint32_t refcount; /* Limited memory or saturating */ } This format would reduce the size of a Python object without slots, on a 64 bit machine, from 40 to 16 bytes. Note that there are two ways to use a 32 bit refcount on a 64 bit machine. One is to limit each sub-interpreter to 32Gb of memory. The other is to use a saturating reference count, which would be a little bit slower, but allow unlimited memory allocation. Backwards Compatibility ======================= It is hypothetically possible that some machine generated code exceeds one or more of the above limits. The author believes that to be highly unlikely and easily fixed by modifying the output stage of the code generator. Security Implications ===================== Minimal. This reduces the attack surface of any Python virtual machine by a small amount. Reference Implementation ======================== None, as yet. This will be implemented in CPython, once the PEP has been accepted. Rejected Ideas ============== None, as yet. Open Issues =========== None, as yet. References ========== .. [1] The Java Virtual Machine specification https://docs.oracle.com/javase/specs/jvms/se8/jvms8.pdf Copyright ========= This document is placed in the public domain or under the CC0-1.0-Universal license, whichever is more permissive. .. Local Variables: mode: indented-text indent-tabs-mode: nil sentence-end-double-space: t fill-column: 70 coding: utf-8 End:

25 44

[RELEASE] Python 3.8.1rc1 is now available for testing
by Łukasz Langa 12 Dec '19

12 Dec '19

Python 3.8.1rc1 is the release candidate of the first maintenance release of Python 3.8. The Python 3.8 series is the newest feature release of the Python language, and it contains many new features and optimizations. You can find Python 3.8.1rc1 here: https://www.python.org/downloads/release/python-381rc1/ <https://www.python.org/downloads/release/python-381rc1/> Assuming no critical problems are found prior to 2019-12-16, the scheduled release date for 3.8.1 as well as Ned Deily's birthday, no code changes are planned between this release candidate and the final release. That being said, please keep in mind that this is a pre-release of 3.8.1 and as such its main purpose is testing. See the “What’s New in Python 3.8 <https://docs.python.org/3.8/whatsnew/3.8.html>” document for more information about features included in the 3.8 series. Detailed information about all changes made in 3.8.0 can be found in its change log. Maintenance releases for the 3.8 series will continue at regular bi-monthly intervals, with 3.8.2 planned for February 2020. We hope you enjoy Python 3.8! Thanks to all of the many volunteers who help make Python Development and these releases possible! Please consider supporting our efforts by volunteering yourself or through organization contributions to the Python Software Foundation. https://www.python.org/psf/ <https://www.python.org/psf/>

6 11

More feedback on PEP 611, please
by Mark Shannon 12 Dec '19

12 Dec '19

Hi everyone, Thanks for all your feedback so far. Previously I asked for "more precise" feedback, which has been interpreted as evidence backed feedback. That's not what I meant. My fault for not being clearer. Your opinions without any justifications are welcome, but I need precision. For example, saying "I don't want any limits ever for anything" is precise, but saying "A limit of 1 million is OK provided the performance improvements justify it" is not. "A limit of 1 million is OK provided a speed up of 50% can be shown" is precise, if a bit of a challenge :) To start this off, here are my opinion of the tradeoff: Almost any performance gain, even 0.1% is worth the, IMO, slight inconvenience of 1 million limits. The reason I believe this is that a 0.1% speedup benefits all Python applications and libraries everywhere and forever, whereas the inconvenience will be felt by a handful of developers, very rarely. Another thing I would like feedback on this: My justification for a single limit of one million across the board is to ease memorization and learning. Is that sufficient justification, or would differing limits be better? Thanks once again, Mark. P.S. On the subject of tradeoffs, here's a bonus question: What, in your opinion, increase in memory consumption is acceptable for a 1% improvement in speed, or vice versa?

8 8

Dropping coroutines from PEP 611.
by Mark Shannon 11 Dec '19

11 Dec '19

Hi all, Thanks again for all your feedback on PEP 611. So far the biggest pushback on limits has been for the number of classes, line count and coroutines. Of those, I have been convinced that a limit on the number of coroutines would the hardest to workaround. In addition the justification for limiting coroutines is probably the weakest. Consequently, I'm dropping the limit on the number of coroutines from the PEP. Cheers, Mark.

2 1

Rejecting PEP 606 and 608
by Barry Warsaw 08 Dec '19

08 Dec '19

At the Steering Council’s November 12th meeting, we unanimously agreed to reject PEPs 606 and 608: * 606 - Python Compatibility Version * 608 - Coordinated Python Release It was our opinion that neither PEP will effectively improve compatibility as proposed. Additionally, PEP 606 had the problem of using global state to request compatibility, and PEP 608 puts external projects in the critical path for Python releases. We want to thank Victor Stinner and Miro Hrončok for their contributions and authorship of these PEPs. I apologize for being remiss in not sending this email before now. I will shortly be submitting and merging a PR to official reject both PEPs. -Barry, on behalf of the Python Steering Council

7 8

Re: Deprecating the "u" string literal prefix
by Anders Munch 08 Dec '19

08 Dec '19

Victor Stinner [mailto:vstinner@python.org] wrote: > You may want to have a look at the deferred PEP 501 -- General purpose string interpolation: > https://www.python.org/dev/peps/pep-0501/ I'm struggling to see what i-strings would do for i18n that str.format doesn't do better. regards, Anders

5 4

Should we require all deprecations to have a removal version that we follow through on?
by Brett Cannon 07 Dec '19

07 Dec '19

What do people think of the idea of requiring all deprecations specifying a version that the feature will be removed in (which under our annual release cadence would be at least the third release from the start of the deprecation, hence the deprecation being public for 2 years)? And that we also follow through with that removal? Now I'm not suggesting it **must** be in three feature releases. A deprecation could be set to Python 4 if people truly feel keeping the code is as easy it gets in terms of maintenance and there's enough usage to warrant such a potential indefinite deprecation/maintenance while keeping the code and docs alive (basically "there are better ways to do this, but this works fine, too, if you were already using it"). But what I am trying to avoid is the semi-regular discussion we seem to have of what is or is not reasonable to deprecate and leave versus deprecate and eventually remove because we didn't specify what the eventual plan was for a deprecation. Also feel like it would help users to know specifically what the plan is with a deprecation rather than wondering if something will get removed in the next feature release or not because we left off a specific removal version. If people are amenable to this idea I will update PEP 387 (which I plan to start a discussion about post-SC election) and I would also plan to add a warnings._deprecate() which I roughly outlined once at https://discuss.python.org/t/pendingdeprecationwarning-is-really-useful/103….

8 10

Fun with Python 3.8 and Qt
by Kacvinsky, Tom 07 Dec '19

07 Dec '19

Today I discovered the this struct typedef struct{ const char* name; int basicsize; int itemsize; unsigned int flags; PyType_Slot *slots; /* terminated by slot==0. */ } PyType_Spec; with "PyTypeSlot *slots" being on line 190 of object.h causes a problem when compiled with code that brings in Qt. Qt has macro definitions of slots. With a cursory preprocessing of the file I was working with, using the handy gcc options -dM -E, I found that slots was defined to nothing #define slots and hence caused problems when object.h was brought into the mix. I will try to make a simple reproducer tomorrow. I know this probably could be solved by header file inclusion re-ordering, or in some cases #undef'ing slots before including Python.h, but I also thought the Python dev team would like to know about this issue. Tom

3 2

Summary of Python tracker Issues
by Python tracker 06 Dec '19

06 Dec '19

ACTIVITY SUMMARY (2019-11-29 - 2019-12-06) Python tracker at https://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open 7180 (+10) closed 43559 (+37) total 50739 (+47) Open issues with patches: 2832 Issues opened (32) ================== #38942: Possible assertion failures in csv.Dialect() https://bugs.python.org/issue38942 opened by ZackerySpytz #38943: Idle autocomplete window doesn't show up https://bugs.python.org/issue38943 opened by JohnnyNajera #38944: Idle autocomplete window doesn't close on Escape key https://bugs.python.org/issue38944 opened by JohnnyNajera #38945: Remove newline characters from uu encoding methods https://bugs.python.org/issue38945 opened by stealthcopter #38946: IDLE on macOS 10.15 Catalina does not open double-clicked file https://bugs.python.org/issue38946 opened by RM #38947: dataclass defaults behave inconsistently for init=True/init=Fa https://bugs.python.org/issue38947 opened by Kevin Shweh #38948: os.path.ismount() returns False for current working drive https://bugs.python.org/issue38948 opened by jainankur #38949: incorrect prefix, exec_prefix in distutils.command.install https://bugs.python.org/issue38949 opened by xdegaye #38952: asyncio cannot handle Python3 IPv4Address https://bugs.python.org/issue38952 opened by Max Coplan #38953: Untokenize and retokenize does not round-trip https://bugs.python.org/issue38953 opened by Zac Hatfield-Dodds #38955: Non indemnpotent behavior of asyncio.get_event_loop and asynci https://bugs.python.org/issue38955 opened by mbussonn #38956: argparse.BooleanOptionalAction should not add the default valu https://bugs.python.org/issue38956 opened by Antony.Lee #38958: asyncio REPL swallows KeyboardInterrupt while editing https://bugs.python.org/issue38958 opened by iomintz #38959: Parboil -- OpenMP CUTCP performance regression when upgrade fr https://bugs.python.org/issue38959 opened by jiebinsu #38960: DTrace FreeBSD build fix https://bugs.python.org/issue38960 opened by David Carlier #38961: Flaky detection of compiler vendor https://bugs.python.org/issue38961 opened by jmaargh #38963: multiprocessing processes seem to "bleed" user information (GI https://bugs.python.org/issue38963 opened by romanofski #38964: Output of syntax error in f-string contains wrong filename https://bugs.python.org/issue38964 opened by Erik Cederstrand #38967: Improve error message in enum for member name surrounded by un https://bugs.python.org/issue38967 opened by Rubén Jesús García Hernández #38970: [PDB] NameError in list comprehension in PDB https://bugs.python.org/issue38970 opened by castix #38971: codecs.open leaks file descriptor when invalid encoding is pas https://bugs.python.org/issue38971 opened by Brock Mendel #38972: Link to instructions to change PowerShell execution policy for https://bugs.python.org/issue38972 opened by brett.cannon #38973: Shared Memory List Returns 0 Length https://bugs.python.org/issue38973 opened by Derek Frombach #38974: using tkinter.filedialog.askopenfilename() freezes python 3.8 https://bugs.python.org/issue38974 opened by Daniel Preston #38975: Add direct anchors to regex syntax documentation https://bugs.python.org/issue38975 opened by bmispelon #38976: Add support for HTTP Only flag in MozillaCookieJar https://bugs.python.org/issue38976 opened by Jacob Taylor #38978: Implement __class_getitem__ for Future, Task, Queue https://bugs.python.org/issue38978 opened by asvetlov #38979: ContextVar[str] should return ContextVar class, not None https://bugs.python.org/issue38979 opened by asvetlov #38980: Compile libpython with -fno-semantic-interposition https://bugs.python.org/issue38980 opened by vstinner #38986: Suppport TaskWakeupMethWrapper.__self__ to conform asyncio _fo https://bugs.python.org/issue38986 opened by asvetlov #38987: 3.8.0 on GNU/Linux fails to find shared library https://bugs.python.org/issue38987 opened by buchs #38988: Killing asyncio subprocesses on timeout? https://bugs.python.org/issue38988 opened by dontbugme Most recent 15 issues with no replies (15) ========================================== #38988: Killing asyncio subprocesses on timeout? https://bugs.python.org/issue38988 #38987: 3.8.0 on GNU/Linux fails to find shared library https://bugs.python.org/issue38987 #38976: Add support for HTTP Only flag in MozillaCookieJar https://bugs.python.org/issue38976 #38975: Add direct anchors to regex syntax documentation https://bugs.python.org/issue38975 #38963: multiprocessing processes seem to "bleed" user information (GI https://bugs.python.org/issue38963 #38961: Flaky detection of compiler vendor https://bugs.python.org/issue38961 #38960: DTrace FreeBSD build fix https://bugs.python.org/issue38960 #38958: asyncio REPL swallows KeyboardInterrupt while editing https://bugs.python.org/issue38958 #38953: Untokenize and retokenize does not round-trip https://bugs.python.org/issue38953 #38949: incorrect prefix, exec_prefix in distutils.command.install https://bugs.python.org/issue38949 #38947: dataclass defaults behave inconsistently for init=True/init=Fa https://bugs.python.org/issue38947 #38944: Idle autocomplete window doesn't close on Escape key https://bugs.python.org/issue38944 #38942: Possible assertion failures in csv.Dialect() https://bugs.python.org/issue38942 #38926: MacOS: 'Install certificates.command' has no effect https://bugs.python.org/issue38926 #38912: test_asyncio altered the execution environment https://bugs.python.org/issue38912 Most recent 15 issues waiting for review (15) ============================================= #38986: Suppport TaskWakeupMethWrapper.__self__ to conform asyncio _fo https://bugs.python.org/issue38986 #38976: Add support for HTTP Only flag in MozillaCookieJar https://bugs.python.org/issue38976 #38975: Add direct anchors to regex syntax documentation https://bugs.python.org/issue38975 #38960: DTrace FreeBSD build fix https://bugs.python.org/issue38960 #38956: argparse.BooleanOptionalAction should not add the default valu https://bugs.python.org/issue38956 #38952: asyncio cannot handle Python3 IPv4Address https://bugs.python.org/issue38952 #38945: Remove newline characters from uu encoding methods https://bugs.python.org/issue38945 #38944: Idle autocomplete window doesn't close on Escape key https://bugs.python.org/issue38944 #38943: Idle autocomplete window doesn't show up https://bugs.python.org/issue38943 #38942: Possible assertion failures in csv.Dialect() https://bugs.python.org/issue38942 #38938: Possible performance improvement for heaqq.merge() https://bugs.python.org/issue38938 #38937: NameError in list comprehension within .pth file https://bugs.python.org/issue38937 #38932: unittest.mock.Mock.reset_mocks does not pass all arguments to https://bugs.python.org/issue38932 #38918: Add __module__ entry for function type in inspect docs table. https://bugs.python.org/issue38918 #38916: Remove array.fromstring https://bugs.python.org/issue38916 Top 10 most discussed issues (10) ================================= #38815: test_ssl: test_min_max_version() fails on FreeBSD and Fedora https://bugs.python.org/issue38815 13 msgs #38974: using tkinter.filedialog.askopenfilename() freezes python 3.8 https://bugs.python.org/issue38974 10 msgs #38980: Compile libpython with -fno-semantic-interposition https://bugs.python.org/issue38980 10 msgs #38941: xml.etree.ElementTree.Element inconsistent warning for bool https://bugs.python.org/issue38941 6 msgs #38945: Remove newline characters from uu encoding methods https://bugs.python.org/issue38945 6 msgs #38964: Output of syntax error in f-string contains wrong filename https://bugs.python.org/issue38964 6 msgs #38971: codecs.open leaks file descriptor when invalid encoding is pas https://bugs.python.org/issue38971 6 msgs #38978: Implement __class_getitem__ for Future, Task, Queue https://bugs.python.org/issue38978 6 msgs #38948: os.path.ismount() returns False for current working drive https://bugs.python.org/issue38948 5 msgs #27873: multiprocessing.pool.Pool.map should take more than one iterab https://bugs.python.org/issue27873 3 msgs Issues closed (35) ================== #17068: peephole optimization for constant string interpolation https://bugs.python.org/issue17068 closed by terry.reedy #19541: ast.dump(indent=True) prettyprinting https://bugs.python.org/issue19541 closed by serhiy.storchaka #21992: New AST node Else() should be introduced https://bugs.python.org/issue21992 closed by serhiy.storchaka #26628: Undefined behavior calling C functions with ctypes.Union argum https://bugs.python.org/issue26628 closed by vinay.sajip #27413: Add an option to json.tool to bypass non-ASCII characters. https://bugs.python.org/issue27413 closed by inada.naoki #29636: Specifying indent in the json.tool command https://bugs.python.org/issue29636 closed by inada.naoki #33684: parse failed for mutibytes characters, encode will show in \xx https://bugs.python.org/issue33684 closed by inada.naoki #34344: Fix the docstring for AbstractEventLoopPolicy.get_event_loop https://bugs.python.org/issue34344 closed by xtreak #35003: Provide an option to venv to put files in a bin/ directory on https://bugs.python.org/issue35003 closed by brett.cannon #36820: Captured exceptions are keeping user objects alive unnecessari https://bugs.python.org/issue36820 closed by pablogsal #37523: zipfile: Raise ValueError for i/o operations on closed zipfile https://bugs.python.org/issue37523 closed by serhiy.storchaka #37883: threading.Lock.locked is not documented https://bugs.python.org/issue37883 closed by taleinat #38608: Undocumented behavior that IsolatedAsyncioTestCase would enabl https://bugs.python.org/issue38608 closed by asvetlov #38634: Symbol resolution conflict when embeding python in an applicat https://bugs.python.org/issue38634 closed by vstinner #38702: Adding new types to parser/unparse.py https://bugs.python.org/issue38702 closed by serhiy.storchaka #38846: async: Return context manager from open(_unix)_connection https://bugs.python.org/issue38846 closed by asvetlov #38858: new_interpreter() should reuse more Py_InitializeFromConfig() https://bugs.python.org/issue38858 closed by vstinner #38868: Shutil cannot delete a folder that contains an .ini file https://bugs.python.org/issue38868 closed by QueenSvetlana #38920: Audit events for unhandled exceptions https://bugs.python.org/issue38920 closed by steve.dower #38924: pathlib paths .normalize() https://bugs.python.org/issue38924 closed by brett.cannon #38950: argparse uses "optional arguments" for "keyword arguments" https://bugs.python.org/issue38950 closed by rhettinger #38951: Use threading.main_thread() check in asyncio https://bugs.python.org/issue38951 closed by asvetlov #38954: test_ssl fails in all Fedora buildbots https://bugs.python.org/issue38954 closed by vstinner #38957: Cannot compile with libffi from source on Windows https://bugs.python.org/issue38957 closed by AWhetter #38962: Reference leaks in subinterpreters https://bugs.python.org/issue38962 closed by vstinner #38965: test_stack_overflow (test.test_faulthandler.FaultHandlerTests) https://bugs.python.org/issue38965 closed by vstinner #38966: List similarity relationship https://bugs.python.org/issue38966 closed by terry.reedy #38968: int method works improperly https://bugs.python.org/issue38968 closed by steven.daprano #38969: The "int" method doesn't work correctly for long numbers with https://bugs.python.org/issue38969 closed by serhiy.storchaka #38977: python3.8 and namedlist1.7 is Incompatible https://bugs.python.org/issue38977 closed by xtreak #38981: better name for re.error Exception class. https://bugs.python.org/issue38981 closed by serhiy.storchaka #38982: test_asyncio: SubprocessPidfdWatcherTests..test_close_dont_kil https://bugs.python.org/issue38982 closed by vstinner #38983: test_venv: test_overwrite_existing() failed on AMD64 Windows7 https://bugs.python.org/issue38983 closed by vstinner #38984: Value add to the wrong key in a dictionary https://bugs.python.org/issue38984 closed by christian.heimes #38985: `compile` returns the first line of file on termination https://bugs.python.org/issue38985 closed by serhiy.storchaka

1 0