Python-Dev June 2016

python-dev@python.org

109 participants
66 discussions

PEP 520: Preserving Class Attribute Definition Order (round 5)

by Eric Snow

- a clearer motivation section - include "dunder" names - 2 open questions (__slots__? drop read-only requirement?) -eric ----------------------------------- PEP: 520 Title: Preserving Class Attribute Definition Order Version: $Revision$ Last-Modified: $Date$ Author: Eric Snow <ericsnowcurrently(a)gmail.com> Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 7-Jun-2016 Python-Version: 3.6 Post-History: 7-Jun-2016, 11-Jun-2016, 20-Jun-2016, 24-Jun-2016 Abstract ======== The class definition syntax is ordered by its very nature. Class attributes defined there are thus ordered. Aside from helping with readability, that ordering is sometimes significant. If it were automatically available outside the class definition then the attribute order could be used without the need for extra boilerplate (such as metaclasses or manually enumerating the attribute order). Given that this information already exists, access to the definition order of attributes is a reasonable expectation. However, currently Python does not preserve the attribute order from the class definition. This PEP changes that by preserving the order in which attributes are introduced in the class definition body. That order will now be preserved in the ``__definition_order__`` attribute of the class. This allows introspection of the original definition order, e.g. by class decorators. Additionally, this PEP changes the default class definition namespace to ``OrderedDict``. The long-lived class namespace (``__dict__``) will remain a ``dict``. Motivation ========== The attribute order from a class definition may be useful to tools that rely on name order. However, without the automatic availability of the definition order, those tools must impose extra requirements on users. For example, use of such a tool may require that your class use a particular metaclass. Such requirements are often enough to discourage use of the tool. Some tools that could make use of this PEP include: * documentation generators * testing frameworks * CLI frameworks * web frameworks * config generators * data serializers * enum factories (my original motivation) Background ========== When a class is defined using a ``class`` statement, the class body is executed within a namespace. Currently that namespace defaults to ``dict``. If the metaclass defines ``__prepare__()`` then the result of calling it is used for the class definition namespace. After the execution completes, the definition namespace namespace is copied into new ``dict``. Then the original definition namespace is discarded. The new copy is stored away as the class's namespace and is exposed as ``__dict__`` through a read-only proxy. The class attribute definition order is represented by the insertion order of names in the *definition* namespace. Thus, we can have access to the definition order by switching the definition namespace to an ordered mapping, such as ``collections.OrderedDict``. This is feasible using a metaclass and ``__prepare__``, as described above. In fact, exactly this is by far the most common use case for using ``__prepare__`` (see PEP 487). At that point, the only missing thing for later access to the definition order is storing it on the class before the definition namespace is thrown away. Again, this may be done using a metaclass. However, this means that the definition order is preserved only for classes that use such a metaclass. There are two practical problems with that: First, it requires the use of a metaclass. Metaclasses introduce an extra level of complexity to code and in some cases (e.g. conflicts) are a problem. So reducing the need for them is worth doing when the opportunity presents itself. PEP 422 and PEP 487 discuss this at length. Given that we now have a C implementation of ``OrderedDict`` and that ``OrderedDict`` is the common use case for ``__prepare__()``, we have such an opportunity by defaulting to ``OrderedDict``. Second, only classes that opt in to using the ``OrderedDict``-based metaclass will have access to the definition order. This is problematic for cases where universal access to the definition order is important. Specification ============= Part 1: * all classes have a ``__definition_order__`` attribute * ``__definition_order__`` is a ``tuple`` of identifiers (or ``None``) * ``__definition_order__`` is a read-only attribute * ``__definition_order__`` is always set: 1. during execution of the class body, the insertion order of names into the class *definition* namespace is stored in a tuple 2. if ``__definition_order__`` is defined in the class body then it must be a ``tuple`` of identifiers or ``None``; any other value will result in ``TypeError`` 3. classes that do not have a class definition (e.g. builtins) have their ``__definition_order__`` set to ``None`` 4. classes for which `__prepare__()`` returned something other than ``OrderedDict`` (or a subclass) have their ``__definition_order__`` set to ``None`` (except where #2 applies) Part 2: * the default class *definition* namespace is now ``OrderdDict`` The following code demonstrates roughly equivalent semantics for the default behavior:: class Meta(type): @classmethod def __prepare__(cls, *args, **kwargs): return OrderedDict() class Spam(metaclass=Meta): ham = None eggs = 5 __definition_order__ = tuple(locals()) Why a tuple? ------------ Use of a tuple reflects the fact that we are exposing the order in which attributes on the class were *defined*. Since the definition is already complete by the time ``__definition_order__`` is set, the content and order of the value won't be changing. Thus we use a type that communicates that state of immutability. Why a read-only attribute? -------------------------- As with the use of tuple, making ``__definition_order__`` a read-only attribute communicates the fact that the information it represents is complete. Since it represents the state of a particular one-time event (execution of the class definition body), allowing the value to be replaced would reduce confidence that the attribute corresponds to the original class body. If a use case for a writable (or mutable) ``__definition_order__`` arises, the restriction may be loosened later. Presently this seems unlikely and furthermore it is usually best to go immutable-by-default. Note that the ability to set ``__definition_order__`` manually allows a dynamically created class (e.g. Cython, ``type()``) to still have ``__definition_order__`` properly set. Why not "__attribute_order__"? ------------------------------ ``__definition_order__`` is centered on the class definition body. The use cases for dealing with the class namespace (``__dict__``) post-definition are a separate matter. ``__definition_order__`` would be a significantly misleading name for a feature focused on more than class definition. Why not ignore "dunder" names? ------------------------------ Names starting and ending with "__" are reserved for use by the interpreter. In practice they should not be relevant to the users of ``__definition_order__``. Instead, for nearly everyone they would only be clutter, causing the same extra work for everyone. However, dropping dunder names by default may inadvertantly cause problems for classes that use dunder names unconventionally. In this case it's better to play it safe and preserve *all* the names from the class definition. Note that a couple of dunder names (``__name__`` and ``__qualname__``) are injected by default by the compiler. So they will be included even though they are not strictly part of the class definition body. Why None instead of an empty tuple? ----------------------------------- A key objective of adding ``__definition_order__`` is to preserve information in class definitions which was lost prior to this PEP. One consequence is that ``__definition_order__`` implies an original class definition. Using ``None`` allows us to clearly distinquish classes that do not have a definition order. An empty tuple clearly indicates a class that came from a definition statement but did not define any attributes there. Why None instead of not setting the attribute? ---------------------------------------------- The absence of an attribute requires more complex handling than ``None`` does for consumers of ``__definition_order__``. Why constrain manually set values? ---------------------------------- If ``__definition_order__`` is manually set in the class body then it will be used. We require it to be a tuple of identifiers (or ``None``) so that consumers of ``__definition_order__`` may have a consistent expectation for the value. That helps maximize the feature's usefulness. We could also also allow an arbitrary iterable for a manually set ``__definition_order__`` and convert it into a tuple. However, not all iterables infer a definition order (e.g. ``set``). So we opt in favor of requiring a tuple. Why is __definition_order__ even necessary? ------------------------------------------- Since the definition order is not preserved in ``__dict__``, it is lost once class definition execution completes. Classes *could* explicitly set the attribute as the last thing in the body. However, then independent decorators could only make use of classes that had done so. Instead, ``__definition_order__`` preserves this one bit of info from the class body so that it is universally available. Support for C-API Types ======================= Arguably, most C-defined Python types (e.g. built-in, extension modules) have a roughly equivalent concept of a definition order. So conceivably ``__definition_order__`` could be set for such types automatically. This PEP does not introduce any such support. However, it does not prohibit it either. The specific cases: * builtin types * PyType_Ready * PyType_FromSpec Compatibility ============= This PEP does not break backward compatibility, except in the case that someone relies *strictly* on ``dict`` as the class definition namespace. This shouldn't be a problem since ``issubclass(OrderedDict, dict)`` is true. Changes ============= In addition to the class syntax, the following expose the new behavior: * builtins.__build_class__ * types.prepare_class * types.new_class Other Python Implementations ============================ Pending feedback, the impact on Python implementations is expected to be minimal. If a Python implementation cannot support switching to `OrderedDict``-by-default then it can always set ``__definition_order__`` to ``None``. Open Questions ============== * What about `__slots__`? * Drop the "read-only attribute" requirement? Per Guido: I don't see why it needs to be a read-only attribute. There are very few of those -- in general we let users play around with things unless we have a hard reason to restrict assignment (e.g. the interpreter's internal state could be compromised). I don't see such a hard reason here. Implementation ============== The implementation is found in the tracker. [impl_] Alternatives ============ An Order-preserving cls.__dict__ -------------------------------- Instead of storing the definition order in ``__definition_order__``, the now-ordered definition namespace could be copied into a new ``OrderedDict``. This would then be used as the mapping proxied as ``__dict__``. Doing so would mostly provide the same semantics. However, using ``OrderedDict`` for ``__dict__`` would obscure the relationship with the definition namespace, making it less useful. Additionally, (in the case of ``OrderedDict`` specifically) doing this would require significant changes to the semantics of the concrete ``dict`` C-API. There has been some discussion about moving to a compact dict implementation which would (mostly) preserve insertion order. However the lack of an explicit ``__definition_order__`` would still remain as a pain point. A "namespace" Keyword Arg for Class Definition ---------------------------------------------- PEP 422 introduced a new "namespace" keyword arg to class definitions that effectively replaces the need to ``__prepare__()``. [pep422_] However, the proposal was withdrawn in favor of the simpler PEP 487. A stdlib Metaclass that Implements __prepare__() with OrderedDict ----------------------------------------------------------------- This has all the same problems as writing your own metaclass. The only advantage is that you don't have to actually write this metaclass. So it doesn't offer any benefit in the context of this PEP. Set __definition_order__ at Compile-time ---------------------------------------- Each class's ``__qualname__`` is determined at compile-time. This same concept could be applied to ``__definition_order__``. The result of composing ``__definition_order__`` at compile-time would be nearly the same as doing so at run-time. Comparative implementation difficulty aside, the key difference would be that at compile-time it would not be practical to preserve definition order for attributes that are set dynamically in the class body (e.g. ``locals()[name] = value``). However, they should still be reflected in the definition order. One posible resolution would be to require class authors to manually set ``__definition_order__`` if they define any class attributes dynamically. Ultimately, the use of ``OrderedDict`` at run-time or compile-time discovery is almost entirely an implementation detail. References ========== .. [impl] issue #24254 (https://bugs.python.org/issue24254) .. [nick_concern] Nick's concerns about mutability (https://mail.python.org/pipermail/python-dev/2016-June/144883.html) .. [pep422] PEP 422 (https://www.python.org/dev/peps/pep-0422/#order-preserving-classes) .. [pep487] PEP 487 (https://www.python.org/dev/peps/pep-0487/#defining-arbitrary-namespaces) .. [orig] original discussion (https://mail.python.org/pipermail/python-ideas/2013-February/019690.html) .. [followup1] follow-up 1 (https://mail.python.org/pipermail/python-dev/2013-June/127103.html) .. [followup2] follow-up 2 (https://mail.python.org/pipermail/python-dev/2015-May/140137.html) Copyright =========== This document has been placed in the public domain.

4 years, 9 months

[RELEASE] Python 2.7.12

by Benjamin Peterson

It is my privilege to present you with another release in the Python 2.7 series, Python 2.7.12. Since the release candidate, there were two changes: - The Windows binaries have been changed to use OpenSSL 1.0.2h. - The "about" dialog in IDLE was fixed. Downloads, as always, are on python.org: https://www.python.org/downloads/release/python-2712/ The complete 2.7.12 changelog is available at https://hg.python.org/cpython/raw-file/v2.7.12/Misc/NEWS Yet another Python 2.7.x release is anticipated near the end of the year. Numerologists may wish to upgrade to Python 3 before we hit the unlucky 2.7.13. Servus, Benjamin 2.7 release manager

4 years, 9 months

When to use EOFError?

by Serhiy Storchaka

There is a design question. If you read file in some format or with some protocol, and the data is ended unexpectedly, when to use general EOFError exception and when to use format/protocol specific exception? For example when load truncated pickle data, an unpickler can raise EOFError, UnpicklingError, ValueError or AttributeError. It is possible to avoid ValueError or AttributeError, but what exception should be raised instead, EOFError or UnpicklingError? Maybe convert all EOFError to UnpicklingError? Or all UnpicklingError caused by unexpectedly ended input to EOFError? Or raise EOFError if the input is ended after completed opcode, and UnpicklingError if it contains truncated opcode? http://bugs.python.org/issue25761

4 years, 9 months

[RELEASED] Python 3.4.5 and Python 3.5.2 are now available

by Larry Hastings

On behalf of the Python development community and the Python 3.4 and Python 3.5 release teams, I'm thrilled to announce the availability of Python 3.4.5 and Python 3.5.2. Python 3.4 is now in "security fixes only" mode. This is the final stage of support for Python 3.4. All changes made to Python 3.4 since Python 3.4.4 should be security fixes only; conventional bug fixes are not accepted. Also, Python 3.4.5 and all future releases of Python 3.4 will only be released as source code--no official binary installers will be produced. Python 3.5 is still in active "bug fix" mode. Python 3.5.2 contains many incremental improvements and bug fixes over Python 3.5.1. You can find Python 3.4.5 here: https://www.python.org/downloads/release/python-345/ And you can find Python 3.5.2 here: https://www.python.org/downloads/release/python-352/ Releasing software from 30,000 feet, //arry /p.s. There appears to be a small oops with the Windows installers for 3.5.2--uploaded to the wrong directory or something. They'll be available soon, honest!

4 years, 9 months

Compact ordered dict is not ordered for split table. (was: PEP XXX: Compact ordered dict

by INADA Naoki

I'm sorry, but I hadn't realized which compact ordered dict is not ordered for split table. For example: >>> class A: ... ... ... >>> a = A() >>> b = A() >>> a.a = 1 >>> a.b = 2 >>> b.b = 3 >>> b.a = 4 >>> a.__dict__.items() dict_items([('a', 1), ('b', 2)]) >>> b.__dict__.items() dict_items([('a', 4), ('b', 3)]) This doesn't affects to **kwargs and class namespace. But if we change the language spec to dict preserves insertion order, this should be addressed. On Tue, Jun 21, 2016 at 2:02 PM, INADA Naoki <songofacandy(a)gmail.com> wrote: > On Tue, Jun 21, 2016 at 12:17 PM, Oleg Broytman <phd(a)phdru.name> wrote: >> Hi! >> >> On Tue, Jun 21, 2016 at 11:14:39AM +0900, INADA Naoki <songofacandy(a)gmail.com> wrote: >>> Here is my draft, but I haven't >>> posted it yet since >>> my English is much worse than C. >>> https://www.dropbox.com/s/s85n9b2309k03cq/pep-compact-dict.txt?dl=0 >> >> It's good enough for a start (if a PEP is needed at all). If you push >> it to Github I'm sure they will come with pull requests. >> >> Oleg. > > Thank you for reading my draft. > >> (if a PEP is needed at all) > > I don't think so. My PEP is not for changing Python Language, > just describe implementation detail. > > Python 3.5 has new OrderedDict implemented in C without PEP. > My patch is relatively small than it. And the idea has been well known. > > -- > INADA Naoki <songofacandy(a)gmail.com> -- INADA Naoki <songofacandy(a)gmail.com>

4 years, 9 months

PEP 520: Ordered Class Definition Namespace

by Eric Snow

I've grabbed a PEP # (520) and updated the PEP to clarify points that were brought up earlier today. Given positive feedback I got at PyCon and the reaction today, I'm hopeful the PEP isn't far off from pronouncement. :) -eric ========================================== PEP: 520 Title: Ordered Class Definition Namespace Version: $Revision$ Last-Modified: $Date$ Author: Eric Snow <ericsnowcurrently(a)gmail.com> Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 7-Jun-2016 Python-Version: 3.6 Post-History: 7-Jun-2016 Abstract ======== This PEP changes the default class definition namespace to ``OrderedDict``. Furthermore, the order in which the attributes are defined in each class body will now be preserved in ``type.__definition_order__``. This allows introspection of the original definition order, e.g. by class decorators. Note: just to be clear, this PEP is *not* about changing ``__dict__`` for classes to ``OrderedDict``. Motivation ========== Currently the namespace used during execution of a class body defaults to ``dict``. If the metaclass defines ``__prepare__()`` then the result of calling it is used. Thus, before this PEP, if you needed your class definition namespace to be ``OrderedDict`` you had to use a metaclass. Metaclasses introduce an extra level of complexity to code and in some cases (e.g. conflicts) are a problem. So reducing the need for them is worth doing when the opportunity presents itself. Given that we now have a C implementation of ``OrderedDict`` and that ``OrderedDict`` is the common use case for ``__prepare__()``, we have such an opportunity by defaulting to ``OrderedDict``. The usefulness of ``OrderedDict``-by-default is greatly increased if the definition order is directly introspectable on classes afterward, particularly by code that is independent of the original class definition. One of the original motivating use cases for this PEP is generic class decorators that make use of the definition order. Changing the default class definition namespace has been discussed a number of times, including on the mailing lists and in PEP 422 and PEP 487 (see the References section below). Specification ============= * the default class *definition* namespace is now ``OrderdDict`` * the order in which class attributes are defined is preserved in the new ``__definition_order__`` attribute on each class * "dunder" attributes (e.g. ``__init__``, ``__module__``) are ignored * ``__definition_order__`` is a tuple * ``__definition_order__`` is a read-only attribute * ``__definition_order__`` is always set: 1. if ``__definition_order__`` is defined in the class body then the value is used as-is, though the attribute will still be read-only 2. types that do not have a class definition (e.g. builtins) have their ``__definition_order__`` set to ``None`` 3. types for which `__prepare__()`` returned something other than ``OrderedDict`` (or a subclass) have their ``__definition_order__`` set to ``None`` (except where #1 applies) The following code demonstrates roughly equivalent semantics:: class Meta(type): def __prepare__(cls, *args, **kwargs): return OrderedDict() class Spam(metaclass=Meta): ham = None eggs = 5 __definition_order__ = tuple(k for k in locals() if (!k.startswith('__') or !k.endswith('__'))) Note that [pep487_] proposes a similar solution, albeit as part of a broader proposal. Why a tuple? ------------ Use of a tuple reflects the fact that we are exposing the order in which attributes on the class were *defined*. Since the definition is already complete by the time ``definition_order__`` is set, the content and order of the value won't be changing. Thus we use a type that communicates that state of immutability. Why a read-only attribute? -------------------------- As with the use of tuple, making ``__definition_order__`` a read-only attribute communicates the fact that the information it represents is complete. Since it represents the state of a particular one-time event (execution of the class definition body), allowing the value to be replaced would reduce confidence that the attribute corresponds to the original class body. If a use case for a writable (or mutable) ``__definition_order__`` arises, the restriction may be loosened later. Presently this seems unlikely and furthermore it is usually best to go immutable-by-default. Note that ``__definition_order__`` is centered on the class definition body. The use cases for dealing with the class namespace (``__dict__``) post-definition are a separate matter. ``__definition_order__`` would be a significantly misleading name for a supporting feature. See [nick_concern_] for more discussion. Why ignore "dunder" names? -------------------------- Names starting and ending with "__" are reserved for use by the interpreter. In practice they should not be relevant to the users of ``__definition_order__``. Instead, for early everyone they would only be clutter, causing the same extra work for everyone. Why is __definition_order__ even necessary? ------------------------------------------- Since the definition order is not preserved in ``__dict__``, it would be lost once class definition execution completes. Classes *could* explicitly set the attribute as the last thing in the body. However, then independent decorators could only make use of classes that had done so. Instead, ``__definition_order__`` preserves this one bit of info from the class body so that it is universally available. Compatibility ============= This PEP does not break backward compatibility, except in the case that someone relies *strictly* on ``dict`` as the class definition namespace. This shouldn't be a problem. Changes ============= In addition to the class syntax, the following expose the new behavior: * builtins.__build_class__ * types.prepare_class * types.new_class Other Python Implementations ============================ Pending feedback, the impact on Python implementations is expected to be minimal. If a Python implementation cannot support switching to `OrderedDict``-by-default then it can always set ``__definition_order__`` to ``None``. Implementation ============== The implementation is found in the tracker. [impl_] Alternatives ============ type.__dict__ as OrderedDict ---------------------------- Instead of storing the definition order in ``__definition_order__``, the now-ordered definition namespace could be copied into a new ``OrderedDict``. This would mostly provide the same semantics. However, using ``OrderedDict`` for ``type,__dict__`` would obscure the relationship with the definition namespace, making it less useful. Additionally, doing this would require significant changes to the semantics of the concrete ``dict`` C-API. A "namespace" Keyword Arg for Class Definition ---------------------------------------------- PEP 422 introduced a new "namespace" keyword arg to class definitions that effectively replaces the need to ``__prepare__()``. [pep422_] However, the proposal was withdrawn in favor of the simpler PEP 487. References ========== .. [impl] issue #24254 (https://bugs.python.org/issue24254) .. [nick_concern] Nick's concerns about mutability (https://mail.python.org/pipermail/python-dev/2016-June/144883.html) .. [pep422] PEP 422 (https://www.python.org/dev/peps/pep-0422/#order-preserving-classes) .. [pep487] PEP 487 (https://www.python.org/dev/peps/pep-0487/#defining-arbitrary-namespaces) .. [orig] original discussion (https://mail.python.org/pipermail/python-ideas/2013-February/019690.html) .. [followup1] follow-up 1 (https://mail.python.org/pipermail/python-dev/2013-June/127103.html) .. [followup2] follow-up 2 (https://mail.python.org/pipermail/python-dev/2015-May/140137.html) Copyright =========== This document has been placed in the public domain.

4 years, 9 months

unittest.TestResult lacks API to separate subtests

by Ilya Kazakevich

Hello, We're developing Python IDE and integrated it with unittest module using TestResult <https://docs.python.org/3.4/library/unittest.html#unittest.TestResult> inheritor to track test start, end etc. With Py3K, it supports addSubTest method, that is called after all subtests. But there is no method called before and after _each_ subtest (like it is done for regular tests). With out of it I can't fetch each subtest output and display it correctly. I suggest to add subTestStart / subTestEnd methods to help me with my issue and other people with similar issues. I can send patch if you think this is a good idea. Ilya Kazakevich JetBrains <http://www.jetbrains.com/> http://www.jetbrains.com The Drive to Develop

4 years, 9 months

Idea: more compact, interned string key only dict for namespace.

by INADA Naoki

As my last email, compact ordered dict can't preserve insertion order of key sharing dict (PEP 412). I'm thinking about deprecating key shared dict for now. Instead, my new idea is introducing more compact dict specialized for namespace. If BDFL (or BDFL delegate) likes this idea, I'll take another one week to implement this. Background ---------------- * Most keys of namespace dict are string. * Calculating hash of string is cheap (one memory access, thanks for cache). * And most keys are interned already. Design ---------- Instead of normal PyDictKeyEntry, use PyInternedKeyEntry like this. typedef struct { // no me_hash PyObject *me_key, *me_value; } PyInternedKeyEntry; insertdict() interns key if it's unicode, otherwise it converts dict to normal compact ordered dict. lookdict_interned() compares only pointer (doesn't call unicode_eq()) when searching key is interned. And add new internal API to create interned key only dict. PyDictObject* _PyDict_NewForNamespace(); Memory usage -------------------- on amd64 arch. key-sharing dict: * 96 bytes for ~3 items * 128 bytes for 4~5 items. compact dict: * 224 bytes for ~5 items. (232 bytes when keep supporting key-shared dict) interned key only dict: * 184 bytes for ~5 items Note ------ Interned key only dict is still larger than key-shared dict. But it can be used for more purpose. It can be used for interning string for example. It can be used to kwargs dict when all keys are interned already. If we provide _PyDict_NewForNamespace to extension modules, json decoder can have option to use this, too. -- INADA Naoki <songofacandy(a)gmail.com>

4 years, 9 months

Summary of Python tracker Issues

by Python tracker

ACTIVITY SUMMARY (2016-06-17 - 2016-06-24) Python tracker at http://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 5531 (-13) closed 33609 (+52) total 39140 (+39) Open issues with patches: 2419 Issues opened (27) ================== #21106: Updated Mac folder icon http://bugs.python.org/issue21106 reopened by r.david.murray #27196: Eliminate 'ThemeChanged' warning when running IDLE tests http://bugs.python.org/issue27196 reopened by ned.deily #27346: Implement os.readv() / os.writev() http://bugs.python.org/issue27346 opened by mmarkk #27348: Non-main thread exception handler drops exception message http://bugs.python.org/issue27348 opened by martin.panter #27350: Compact and ordered dict http://bugs.python.org/issue27350 opened by naoki #27351: Unexpected ConfigParser.read() behavior when passed fileobject http://bugs.python.org/issue27351 opened by Rich.Rauenzahn #27352: Bug in IMPORT_NAME http://bugs.python.org/issue27352 opened by serhiy.storchaka #27353: Add nroot function to math http://bugs.python.org/issue27353 opened by steven.daprano #27354: SSLContext.load_verify_locations cannot handle paths on Window http://bugs.python.org/issue27354 opened by Ilya.Kulakov #27355: Strip out the last lingering vestiges of Windows CE support http://bugs.python.org/issue27355 opened by larry #27357: Enhancing the Windows installer http://bugs.python.org/issue27357 opened by Sworddragon #27358: BUILD_MAP_UNPACK_WITH_CALL is slow http://bugs.python.org/issue27358 opened by Demur Rumed #27359: OrderedDict pseudo-literals (WIP) http://bugs.python.org/issue27359 opened by llllllllll #27363: Complex with negative zero imaginary part http://bugs.python.org/issue27363 opened by Vedran.Čačić #27364: Deprecate invalid unicode escape sequences http://bugs.python.org/issue27364 opened by ebarry #27365: Allow non-ascii chars in IDLE NEWS.txt (for contributor names) http://bugs.python.org/issue27365 opened by terry.reedy #27366: PEP487: Simpler customization of class creation http://bugs.python.org/issue27366 opened by Martin.Teichmann #27367: Windows buildbot: random timeout failure on test_threading http://bugs.python.org/issue27367 opened by haypo #27369: [PATCH] Tests break with --with-system-expat and Expat 2.2.0 http://bugs.python.org/issue27369 opened by sping #27372: Test_idle should stop changing locale http://bugs.python.org/issue27372 opened by terry.reedy #27373: logging.handlers.SysLogHandler with TCP not working on rsyslog http://bugs.python.org/issue27373 opened by 吴冉波 #27374: Cygwin: Makefile does not install DLL import library http://bugs.python.org/issue27374 opened by erik.bray #27376: Add mock_import method to mock module http://bugs.python.org/issue27376 opened by Eyal Posener #27377: Add smarter socket.fromfd() http://bugs.python.org/issue27377 opened by nascheme #27379: SocketType changed in Python 3 http://bugs.python.org/issue27379 opened by martin.panter #27380: IDLE: add base Query dialog with ttk widgets http://bugs.python.org/issue27380 opened by terry.reedy #27383: executuable in distutils triggering microsoft anti virus http://bugs.python.org/issue27383 opened by Rob Bairos Most recent 15 issues with no replies (15) ========================================== #27383: executuable in distutils triggering microsoft anti virus http://bugs.python.org/issue27383 #27380: IDLE: add base Query dialog with ttk widgets http://bugs.python.org/issue27380 #27379: SocketType changed in Python 3 http://bugs.python.org/issue27379 #27376: Add mock_import method to mock module http://bugs.python.org/issue27376 #27374: Cygwin: Makefile does not install DLL import library http://bugs.python.org/issue27374 #27372: Test_idle should stop changing locale http://bugs.python.org/issue27372 #27367: Windows buildbot: random timeout failure on test_threading http://bugs.python.org/issue27367 #27366: PEP487: Simpler customization of class creation http://bugs.python.org/issue27366 #27348: Non-main thread exception handler drops exception message http://bugs.python.org/issue27348 #27340: bytes-like objects with socket.sendall(), SSL, and http.client http://bugs.python.org/issue27340 #27332: Clinic: first parameter for module-level functions should be P http://bugs.python.org/issue27332 #27331: Add a policy argument to email.mime.MIMEBase http://bugs.python.org/issue27331 #27329: Document behavior when CDLL is called with None as an argumen http://bugs.python.org/issue27329 #27326: SIGSEV in test_window_funcs of test_curses http://bugs.python.org/issue27326 #27323: ncurses putwin() fails in test_module_funcs http://bugs.python.org/issue27323 Most recent 15 issues waiting for review (15) ============================================= #27380: IDLE: add base Query dialog with ttk widgets http://bugs.python.org/issue27380 #27377: Add smarter socket.fromfd() http://bugs.python.org/issue27377 #27376: Add mock_import method to mock module http://bugs.python.org/issue27376 #27374: Cygwin: Makefile does not install DLL import library http://bugs.python.org/issue27374 #27372: Test_idle should stop changing locale http://bugs.python.org/issue27372 #27369: [PATCH] Tests break with --with-system-expat and Expat 2.2.0 http://bugs.python.org/issue27369 #27366: PEP487: Simpler customization of class creation http://bugs.python.org/issue27366 #27365: Allow non-ascii chars in IDLE NEWS.txt (for contributor names) http://bugs.python.org/issue27365 #27364: Deprecate invalid unicode escape sequences http://bugs.python.org/issue27364 #27359: OrderedDict pseudo-literals (WIP) http://bugs.python.org/issue27359 #27358: BUILD_MAP_UNPACK_WITH_CALL is slow http://bugs.python.org/issue27358 #27355: Strip out the last lingering vestiges of Windows CE support http://bugs.python.org/issue27355 #27352: Bug in IMPORT_NAME http://bugs.python.org/issue27352 #27350: Compact and ordered dict http://bugs.python.org/issue27350 #27334: pysqlite3 context manager not performing rollback when a datab http://bugs.python.org/issue27334 Top 10 most discussed issues (10) ================================= #27365: Allow non-ascii chars in IDLE NEWS.txt (for contributor names) http://bugs.python.org/issue27365 19 msgs #27051: Create PIP gui http://bugs.python.org/issue27051 15 msgs #27350: Compact and ordered dict http://bugs.python.org/issue27350 9 msgs #27172: Undeprecate inspect.getfullargspec() http://bugs.python.org/issue27172 8 msgs #27344: zipfile *does* support utf-8 filenames http://bugs.python.org/issue27344 8 msgs #27309: Visual Styles support to tk/tkinter file and message dialogs http://bugs.python.org/issue27309 7 msgs #27353: Add nroot function to math http://bugs.python.org/issue27353 7 msgs #27359: OrderedDict pseudo-literals (WIP) http://bugs.python.org/issue27359 7 msgs #27364: Deprecate invalid unicode escape sequences http://bugs.python.org/issue27364 7 msgs #27363: Complex with negative zero imaginary part http://bugs.python.org/issue27363 6 msgs Issues closed (50) ================== #5225: OS X "Update Shell Profile" may not update $PATH if run more t http://bugs.python.org/issue5225 closed by willingc #8406: Make some setup.py paths exclude-able http://bugs.python.org/issue8406 closed by willingc #9156: socket._fileobject: read raises AttributeError when closed in http://bugs.python.org/issue9156 closed by martin.panter #11623: Distutils is reporting OSX 10.6 w/ XCode 4 as "universal" http://bugs.python.org/issue11623 closed by willingc #14354: Crash in _ctypes_alloc_callback http://bugs.python.org/issue14354 closed by willingc #16821: bundlebuilder broken in 2.7 http://bugs.python.org/issue16821 closed by willingc #18300: script_helper._assert_python should set TERM='' by default. http://bugs.python.org/issue18300 closed by berker.peksag #20256: Argument Clinic: compare signed and unsigned ints http://bugs.python.org/issue20256 closed by serhiy.storchaka #22463: Warnings when building on AIX http://bugs.python.org/issue22463 closed by martin.panter #22636: avoid using a shell in ctypes.util: replace os.popen with subp http://bugs.python.org/issue22636 closed by martin.panter #23641: Got rid of bad dunder names http://bugs.python.org/issue23641 closed by serhiy.storchaka #24137: Force not using _default_root in IDLE http://bugs.python.org/issue24137 closed by terry.reedy #24314: irrelevant cross-link in documentation of user-defined functio http://bugs.python.org/issue24314 closed by martin.panter #24419: In argparse action append_const doesn't work for positional ar http://bugs.python.org/issue24419 closed by paul.j3 #26290: fileinput and 'for line in sys.stdin' do strange mockery of in http://bugs.python.org/issue26290 closed by martin.panter #26536: Add the SIO_LOOPBACK_FAST_PATH option to socket.ioctl http://bugs.python.org/issue26536 closed by steve.dower #26547: Undocumented use of the term dictproxy in vars() documentation http://bugs.python.org/issue26547 closed by berker.peksag #26930: Upgrade installers to OpenSSL 1.0.2h http://bugs.python.org/issue26930 closed by steve.dower #26975: Decimal.from_float works incorrectly for non-binary floats http://bugs.python.org/issue26975 closed by skrah #27006: C implementation of Decimal.from_float() bypasses __new__ and http://bugs.python.org/issue27006 closed by skrah #27021: It is not documented that os.writev() suffer from SC_IOV_MAX http://bugs.python.org/issue27021 closed by orsenthil #27048: distutils._msvccompiler._get_vc_env() fails with UnicodeDecode http://bugs.python.org/issue27048 closed by steve.dower #27079: Bugs in curses.ascii predicates http://bugs.python.org/issue27079 closed by serhiy.storchaka #27177: re match.group should support __index__ http://bugs.python.org/issue27177 closed by serhiy.storchaka #27244: print(';;') fails in pdb with SyntaxError http://bugs.python.org/issue27244 closed by ned.deily #27287: SIGSEGV when calling os.forkpty() http://bugs.python.org/issue27287 closed by ned.deily #27294: Better repr for Tkinter event objects http://bugs.python.org/issue27294 closed by serhiy.storchaka #27297: Add support for /dev/random to "secrets" http://bugs.python.org/issue27297 closed by ncoghlan #27299: urllib does not splitport while putrequest realhost to HTTP he http://bugs.python.org/issue27299 closed by r.david.murray #27304: Create "Source Code" links in module sections, where relevant http://bugs.python.org/issue27304 closed by terry.reedy #27312: test_setupapp (idlelib.idle_test.test_macosx.SetupTest) fails http://bugs.python.org/issue27312 closed by ned.deily #27319: Multiple item arguments for selection operations http://bugs.python.org/issue27319 closed by serhiy.storchaka #27333: validate_step in rangeobject.c, incorrect code logic but right http://bugs.python.org/issue27333 closed by serhiy.storchaka #27337: 3.6.0a2 tarball has weird paths http://bugs.python.org/issue27337 closed by ned.deily #27342: Clean up some Py_XDECREFs in rangeobject.c and bltinmodule.c http://bugs.python.org/issue27342 closed by serhiy.storchaka #27343: Incorrect error message for conflicting initializers of ctypes http://bugs.python.org/issue27343 closed by serhiy.storchaka #27345: GzipFile's readinto() reads gzip data instead of file data. http://bugs.python.org/issue27345 closed by Ryan Birmingham #27347: Spam http://bugs.python.org/issue27347 closed by berker.peksag #27349: distutils.command.upload: typo "protcol_version" http://bugs.python.org/issue27349 closed by berker.peksag #27356: csv http://bugs.python.org/issue27356 closed by berker.peksag #27360: _deque and _islice are sometimes None http://bugs.python.org/issue27360 closed by SilentGhost #27361: ValueError on eval after 'from pandas import *' http://bugs.python.org/issue27361 closed by SilentGhost #27362: json.dumps to check for obj.__json__ before raising TypeError http://bugs.python.org/issue27362 closed by r.david.murray #27368: os.mkdir is not working for multiple level of directory creati http://bugs.python.org/issue27368 closed by SilentGhost #27370: Inconsistency in docs for list.extend http://bugs.python.org/issue27370 closed by martin.panter #27371: Runaway memory consumption using tkinter update() http://bugs.python.org/issue27371 closed by jeremyblow #27375: error in "make test", while trying to install python on linux http://bugs.python.org/issue27375 closed by skrah #27378: remove ref to Phil Schwartz's 'Kodos' in regex HOWTO http://bugs.python.org/issue27378 closed by berker.peksag #27381: Typo in zipfile documentation http://bugs.python.org/issue27381 closed by berker.peksag #27382: calendar module .isleap() probleam http://bugs.python.org/issue27382 closed by ebarry

4 years, 9 months

Here's what's going into 3.5.2 final and 3.4.5 final

by Larry Hastings

Heads up! This is a courtesy reminder from your friendly 3.4 and 3.5 release manager. Here's a list of all the changes since 3.5.2rc1 that are currently going into 3.5.2 final: * 155e665428c6 - Zachary: OpenSSL 1.0.2h build changes for Windows * cae0b7ffeb9f - Benjamin: fix % in Doc/whatsnew/3.5.rst that confuses latex * 783dfd77e4c1 - Terry Reed: allow non-ascii in idlelib/NEWS.txt * <new revision> - Matthias: fix for test_ssl test_options on Ubuntu 3.4.5 final only has one change from 3.4.5rc1: the test_ssl test_options fix from Matthias. If there's something else that needs to go into one of these releases, and it's not on the list above, speak up now. I may actually tag these late Friday as I'm traveling Saturday. So you have approximately, let's say 20 hours from when I post this. Thanks, //arry/

4 years, 9 months

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

Python-Dev June 2016