[Python-Dev] PEP520 and absence of __definition_order__
Per Victor's advice I'm posting this here. PEP 520 has been accepted, but without the __definition_order__ attribute. The accompanying comment: "Note: Since compact dict has landed in 3.6, __definition_order__ has been removed. cls.__dict__ now mostly accomplishes the same thing instead." The "mostly" is what concerns me. Much like having a custom __dir__ lets a class fine-tune what is of interest, a custom __definition_order__ allows a class to present a unified view of the class creation process. This could be important to classes that employ __getattr__ (or __getattribute__) to provide virtual attributes, such as Enum or proxy classes. With __definition_order__ Enum can display the actual creation order of enum members and methods, while relying on Enum.__dict__.keys() presents a jumbled mess with many attributes the user never wrote, the enum members either appearing /after/ all the methods (even if actually written before), or entirely absent. For example, this class: class PassBy(Enum): ... value = 1 ... reference = 2 ... name = 3 ... object = name ... def used_by_python(self): ... return self.name == 'name' ... shows this: PassBy.__dict__.keys() dict_keys([ '_generate_next_value_', '__module__', 'used_by_python', '__doc__', '_member_names_', '_member_map_', '_member_type_', '_value2member_map_', 'reference', 'object', '__new__', ]) Notice that two of the members are missing, and all are after the method. If __definition_order__ existed it would be this: PassBy.__definition_order__ ['value', 'reference', 'name', 'object', 'used_by_python'] Which is a much more accurate picture of the user's class. -- ~Ethan~ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] sys.path file feature
Hi, tracking the commit log I have noticed for Windows there was added a new feature which is very interesting and can also be useful for other platforms. If I read it right it supports adding a sys.path text file near the executable to specify the Python sys.path variable and overwriting the default behavior. https://hg.python.org/cpython/rev/03517dd54977 This change is only for Windows (if I read right). But I think it is thus valuable to add this in common as general rule. This also simplifies and unifies virtual environment creating and standalone redistribution. Also I have one remaining question, is the "*.pth" file handling then disabled by this feature? If yes, can this be a problem in a virtual environment if a package uses a pth file installed in the virtual environment site-packages directory? Overall I think this is a great addition and the start to unify sys.path handling. And a good feature for redistribution of a Python interpreter without an installation. (Embedding, virtual environments, fat virtual environments, ...) Regards, Wolfgang ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP520 and absence of __definition_order__
On 10 September 2016 at 17:49, Ethan Furman wrote: > Per Victor's advice I'm posting this here. > > PEP 520 has been accepted, but without the __definition_order__ attribute. > The accompanying comment: > >> "Note: Since compact dict has landed in 3.6, __definition_order__ has >> been removed. cls.__dict__ now mostly accomplishes the same thing >> instead." > > > The "mostly" is what concerns me. Much like having a custom __dir__ lets > a class fine-tune what is of interest, a custom __definition_order__ allows > a class to present a unified view of the class creation process. This could > be important to classes that employ __getattr__ (or __getattribute__) to > provide virtual attributes, such as Enum or proxy classes. +1 The reasoning for modifying the PEP post-acceptance is faulty - __definition_order__ wasn't just there as a CPython implementation detail, it was there as a way to allow class and metaclass developers to hide their *own* irrelevant implementation details. Since __definition_order__ was already accepted, and the rationale for removing it is incorrect, could we please have it back for beta 1? Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] sys.path file feature
On 10 September 2016 at 18:37, Wolfgang wrote: > Hi, > > tracking the commit log I have noticed for Windows there was added a new > feature which is very interesting and can also be useful for other > platforms. > > If I read it right it supports adding a sys.path text file near the > executable to specify the Python sys.path variable and overwriting the > default behavior. > > https://hg.python.org/cpython/rev/03517dd54977 While I'm all for adding ways to simplify CPython sys.path configuration, they shouldn't be added as implicit side effects of other changes without at least some discussion of the chosen approach. If there isn't time for that, and it's needed to solve a particular problem, then the underscore-prefix naming convention indicating "this is not a standardised and supported interface" works just as well for config files as it does for module and attribute names. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP520 and absence of __definition_order__
On 9/10/2016 5:27 AM, Nick Coghlan wrote: On 10 September 2016 at 17:49, Ethan Furman wrote: Per Victor's advice I'm posting this here. PEP 520 has been accepted, but without the __definition_order__ attribute. The accompanying comment: "Note: Since compact dict has landed in 3.6, __definition_order__ has been removed. cls.__dict__ now mostly accomplishes the same thing instead." The "mostly" is what concerns me. Much like having a custom __dir__ lets a class fine-tune what is of interest, a custom __definition_order__ allows a class to present a unified view of the class creation process. This could be important to classes that employ __getattr__ (or __getattribute__) to provide virtual attributes, such as Enum or proxy classes. +1 The reasoning for modifying the PEP post-acceptance is faulty - __definition_order__ wasn't just there as a CPython implementation detail, it was there as a way to allow class and metaclass developers to hide their *own* irrelevant implementation details. Since __definition_order__ was already accepted, and the rationale for removing it is incorrect, could we please have it back for beta 1? Someone (Ethan?) should ask that this be a release blocker on some issue. -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 467: last round (?)
On 01.09.16 22:36, Ethan Furman wrote: * Add ``bytes.iterbytes`` and ``bytearray.iterbytes`` alternative iterators Could you please add a mention of alternative: seqtools.chunks()? seqtools.chunks(bytes, 1) and seqtools.chunks(bytearray, 1) should be equivalent to bytes.iterbytes() and bytearray.iterbytes() (but this function is applicable to arbitrary sequences, including memoryview and array). Is there a need of a PEP for new seqtools module (currently two classes are planned), or just providing sample implementation on the bugtracker would be enough? ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP520 and absence of __definition_order__
On 10 September 2016 at 19:27, Nick Coghlan wrote: > On 10 September 2016 at 17:49, Ethan Furman wrote: >> The "mostly" is what concerns me. Much like having a custom __dir__ lets >> a class fine-tune what is of interest, a custom __definition_order__ allows >> a class to present a unified view of the class creation process. This could >> be important to classes that employ __getattr__ (or __getattribute__) to >> provide virtual attributes, such as Enum or proxy classes. > > +1 > > The reasoning for modifying the PEP post-acceptance is faulty - > __definition_order__ wasn't just there as a CPython implementation > detail, it was there as a way to allow class and metaclass developers > to hide their *own* irrelevant implementation details. > > Since __definition_order__ was already accepted, and the rationale for > removing it is incorrect, could we please have it back for beta 1? After posting this, I realised I should give a bit more detail on why I see PEP 520 without __definition_order__ as potentially problematic. Specifically, it relates to these two sections in the PEP about having __definition_order__ be writable and about whether or not to set it for classes that aren't created via the class syntax: * https://www.python.org/dev/peps/pep-0520/#why-not-a-read-only-attribute * https://www.python.org/dev/peps/pep-0520/#support-for-c-api-types >From the first section: "Also, note that a writeable __definition_order__ allows dynamically created classes (e.g. by Cython) to still have __definition_order__ properly set. That could certainly be handled through specific class- creation tools, such as type() or the C-API, without the need to lose the semantics of a read-only attribute. However, with a writeable attribute it's a moot point. " >From the second: "However, since __definition_order__ can be set at any time through normal attribute assignment, it does not need any special treatment in the C-API." Unlike the __definition_order__ tuple, making "list(cls.__dict__)" the official way of accessing the definition order exposes an implementation detail that's somewhat specific to the way Python class statements work, rather than being universal across all the different techniques that exist for putting together Python class objects. As Terry suggested, I've reopened and elevated the priority of http://bugs.python.org/issue24254, but only to deferred blocker - while I do think we need to reconsider the decision to remove __definition_order__ based on a proper update to the PEP that accounts for all the points that came up in the original discussions, I also don't see any major problem with leaving it out in beta 1, and then restoring it in beta 2. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] sys.path file feature
The underscore is an appropriate rename here, but calling the file sys.path was too juicy :) It's intended only for embedding on Windows and does not exist on Linux/Mac yet (more precisely, implementation is only in PC/getpathp.c). I chatted with some people about spreading it and there wasn't really enough interest yet - theoretical uses but not actual ones, whereas on Windows there are actual uses. If you have actual uses we can look more seriously at it, but right now it's more of a secret registry key that disables the registry. As it is totally outside the language and very specific to a particular installation, support can easily be added at any time. Find my various write-ups on the embeddable distro for details on the use cases, but none of them affect regular Python developers. Cheers, Steve Top-posted from my Windows Phone -Original Message- From: "Nick Coghlan" Sent: 9/10/2016 2:43 To: "Wolfgang" Cc: "Python Dev" Subject: Re: [Python-Dev] sys.path file feature On 10 September 2016 at 18:37, Wolfgang wrote: > Hi, > > tracking the commit log I have noticed for Windows there was added a new > feature which is very interesting and can also be useful for other > platforms. > > If I read it right it supports adding a sys.path text file near the > executable to specify the Python sys.path variable and overwriting the > default behavior. > > https://hg.python.org/cpython/rev/03517dd54977 While I'm all for adding ways to simplify CPython sys.path configuration, they shouldn't be added as implicit side effects of other changes without at least some discussion of the chosen approach. If there isn't time for that, and it's needed to solve a particular problem, then the underscore-prefix naming convention indicating "this is not a standardised and supported interface" works just as well for config files as it does for module and attribute names. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/steve.dower%40python.org ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Let's make the SSL module sane
Hi, (CC TLS gurus) For 3.6 I like to make the SSL more sane and more secure by default. Yes, I'm a bit late but all my proposals are implemented, documented, partly tested and existing tests are passing. I'm going to write more tests and documentation after beta1. First I like to deprecated some old APIs and favor of SSLCotext. We have multiple ways to create a SSL socket or to configure libraries like urllib. The general idea is to make SSLContext the central object for TLS/SSL configuration. My patch deprecates ssl.wrap_socket() and SSLSocket constructor in favor of SSLContext.wrap_socket(). The patch also deprecates certfile, keyfile an similar arguments in network protocol libraries. I also considered to make cert validation enabled by default for all protocol in 3.6, Victor has rising some concerns. How about we change the behavior in 3.7 and just add a warning to 3.6? http://bugs.python.org/issue28022 https://github.com/tiran/cpython/commits/feature/feature/ssl_deprecation Next up SSLContext default configuration. A bare SSLContext comes with insecure default settings. I'd like to make SSLContext(PROTOCOL_SSLv23) secure bu default. Changelog: The context is created with more secure default values. The options OP_NO_COMPRESSION, OP_CIPHER_SERVER_PREFERENCE, OP_SINGLE_DH_USE, OP_SINGLE_ECDH_USE, OP_NO_SSLv2 (except for PROTOCOL_SSLv2), and OP_NO_SSLv3 (except for PROTOCOL_SSLv3) are set by default. The initial cipher suite list contains only HIGH ciphers, no NULL ciphers and MD5 ciphers (except for PROTOCOL_SSLv2). http://bugs.python.org/issue28043 https://github.com/tiran/cpython/commits/feature/ssl_sane_defaults Finally (and this is the biggest) I like to change how the protocols work. OpenSSL 1.1.0 has deprecated all version specific protocols. Soon OpenSSL will only support auto-negotiation (formerly known as PROTOCOL_SSLv23). My patch #26470 added PROTOCOL_TLS as alias for PROTOCOL_SSLv23. If the last idea is accepted I will remove PROTOCOL_TLS again. It hasn't been released yet. Instead I'm going to add PROTOCOL_TLS_CLIENT and PROTOCOL_TLS_SERVER (see https://www.openssl.org/docs/manmaster/ssl/SSL_CTX_new.html TLS_server_method(), TLS_client_method()). PROTOCOL_TLS_CLIENT is like PROTOCOL_SSLv23 but only supports client-side sockets and PROTOCOL_TLS_SERVER just server-side sockets. In my experience we can't have a SSLContext with sensible and secure settings for client and server at the same time. Hostname checking and cert validation is only sensible for client-side sockets. Starting in 3.8 (or 3.7?) there will be only PROTOCOL_TLS_CLIENT and PROTOCOL_TLS_SERVER. I haven't created a ticket yet, code is at https://github.com/tiran/cpython/commits/feature/openssl_client_server How will my proposals change TLS/SSL code? Application must create a SSLContext object. Applications are recommended to keep the context around to benefit from session reusage and reduce overload of cert parsing. Client side, ctx = ssl.SSLContext(ssl.PROTOCOL_TLS_CLIENT): * works with TLSv1.0, TLSv1.1, TLSv1.2 and new protocols * Options OP_NO_SSLv2, OP_NO_SSLv3, OP_NO_COMPRESSION are set * Only HIGH cipher suites are enabled, MD5 and NULL are disabled * all other ciphers are still enabled, MD5 for SSLv2 * cert_required = CERT_REQUIRED * check_hostname = True * ctx.wrap_socket() creates a client-side socket * ctx.wrap_socket(server_side=True) will not work * root certs are *not* loaded I don't load any certs because it is not possible to remove a cert or X509 lookup once it is loaded. create_default_context() just have to load the certs and set more secure ciper suites. Server side, ctx = ssl.SSLContext(ssl.PROTOCOL_TLS_PROTOCOL): * works with TLSv1.0, TLSv1.1, TLSv1.2 and new protocols * Options OP_NO_SSLv2, OP_NO_SSLv3, OP_NO_COMPRESSION are set * OP_CIPHER_SERVER_PREFERENCE, OP_SINGLE_DH_USE, OP_SINGLE_ECDH_USE are set * Only HIGH cipher suites are enabled, MD5 and NULL are disabled * all other ciphers are still enabled, MD5 for SSLv2 * cert_required = CERT_NONE (no client cert validation) * check_hostname = False * no root CA certs are loaded * only ctx.wrap_socket(server_side=True) works I hope this mail makes sense. Christian ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Let's make the SSL module sane
On 11 September 2016 at 00:22, Christian Heimes wrote: > First I like to deprecated some old APIs and favor of SSLCotext. We have > multiple ways to create a SSL socket or to configure libraries like > urllib. The general idea is to make SSLContext the central object for > TLS/SSL configuration. My patch deprecates ssl.wrap_socket() I'll bring over my question from the tracker issue to here: there's a subset of ssl.wrap_socket() arguments which actually make sense as arguments to ssl.get_default_context().wrap_socket(). Accordingly, we can pick a subset of code (e.g. SSL/TLS clients) that we bless with not needing to change, leaving only code using deprecated parameters or creating server sockets that needs to be updated. As with past network security changes, a major factor we need to account for is that no matter how valuable a particular goal is from a broader industry perspective, people don't tend to react to API breaks by fixing their code - they react by not upgrading at all. Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Webmaster] A broken link!
Hi Karen, Thanks for your note. I just checked the source of the document in question, and it appears that link has been changed to reference https://www.mercurial-scm.org/guide, so it appears that we may be publishing an out-of-date document there. I'm copying this reply to the python-dev list, and the release manager may or may not choose to update the published version. regards Steve Steve Holden On Fri, Sep 9, 2016 at 3:37 PM, Karen Little < karen.lit...@whoishostingthismail.com> wrote: > Hi, > > Just wanted to let you know about a link that seems to be broken on this > page https://docs.python.org/3.2/whatsnew/3.2.html. > > It is this link http://mercurial.selenic.com/guide/, but the page doesn’t > seem to be active any more. I thought you might want to update. > > If you are looking for an alternative please check out > http://wiht.link/Mercurial-intro, it may make a suitable replacement. > > Kind Regards, > Karen > > > > Don't want emails from us anymore? Reply to this email with the word > "UNSUBSCRIBE" in the subject line. > WhoIsHostingThis, BM Box 3667, Old Gloucester Street London, WC1N 3XX, > United Kingdom > ___ > Webmaster mailing list > webmas...@python.org > https://mail.python.org/mailman/listinfo/webmaster > > ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Let's make the SSL module sane
> On Sep 10, 2016, at 10:22 AM, Christian Heimes wrote: > > I don't load any certs because it is not possible to remove a cert or > X509 lookup once it is loaded. create_default_context() just have to > load the certs and set more secure ciper suites. This part is the most concerning to me, though I understand why it’s the case. Perhaps we can do something a little tricky to allow both things to happen? IOW do sort of a late binding of a call to loading the default certificates if no other certificates has been loaded when the call to SSLContext().wrap_socket() has been made. So we’d do something like: class SSLContext: def __init__(self, …): self._loaded_certificates = False … # Do Other Stuff def load_default_certs(self, …): self._loaded_certificates = True … # Do Other Stuff def load_verify_locations(self, …): self._loaded_certificates = True … # Do Other Stuff def wrap_socket(self, …): if not self._loaded_certificates: self.load_default_certs() … # Do Other Stuff That way if someone does something like: ctx = ssl.SSLContext(ssl.PROTOCOL_TLS_CLIENT) ctx.load_verify_locations(cafile=“…”) ctx.wrap_socket(…) Then they don’t get any default certificates added, HOWEVER if they do: ctx = ssl.SSLContext(ssl.PROTOCOL_TLS_CLIENT) ctx.wrap_socket(…) Then they do. The main draw back I can see with this is that you can’t wrap a socket and then add certificates after the fact… but I don’t even know if that makes sense to do? — Donald Stufft ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Webmaster] A broken link!
On 11 September 2016 at 01:27, Steve Holden wrote: > Hi Karen, > > Thanks for your note. I just checked the source of the document in question, > and it appears that link has been changed to reference > https://www.mercurial-scm.org/guide, so it appears that we may be publishing > an out-of-date document there. > > I'm copying this reply to the python-dev list, and the release manager may > or may not choose to update the published version. There's a problem with the way we're publishing our docs, but it's probably more that we're not emitting canonical URL tags that tell search engines to drop the major version qualifier from the links they present in search results: https://bugs.python.org/issue26355 This means that even folks using newer versions of Python may land on older versions of the docs if that's what a search engine happens to present for their particular query. I haven't personally found the time to follow up on that idea with an actual implementation, but it would presumably be a matter of tinkering with the Sphinx theme and/or conf.py file (even for the no longer supported versions of the docs). Cheers, Nick. P.S. Although in this case, it may have just been a direct link to the 3.2 version of the 3.2 What's New - there isn't a lot we can do about that, as when a branch goes unsupported, we usually stop updating the docs as well (even when external links break) -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP520 and absence of __definition_order__
Thanks for bringing this up. I think it's definitely possible to argue either way. I think what happened before was that I approved __definition_order__ because I wasn't expecting dict to be ordered by default. Now that Inada Naoki's patch has landed things have changed. Here's my reason for agreeing with (or convincing?) Eric to drop __definition_order__, as I remember it from the (lively) discussion at the sprint. - There are only a few use cases for definition order. Without trying to be complete, the use cases I am aware of are all similar to the django Forms interface (https://docs.djangoproject.com/en/1.10/ref/forms/api/#module-django.forms) where the order in which fields are defined determines the order in which they are rendered. Possibly the traits or traitlets libraries also have similar functionality; I know I added it to a database API I wrote at Google as well. I have another idea for a use case where you can define a named tuple with typed fields using PEP 526 syntax. - I like sparsity of interfaces. A class already has dunder attributes for bases, mro, docstring, name, qualified name, module, and probably a few others that I've forgotten. Cruft inevitably accumulates, but I still feel I have to fight it. If we can get the functionality needed for those use cases without a new dunder attribute, so much the better. - The Forms trait[let]s use cases and named tuples can clearly be dealt with by using list(cls.__dict__), since they all involve a user-defined class. - If we had had ordered dicts from the start, those use cases would have been built upon that happily. What would Cython do? I don't know, but I imagine they'd come up with it -- they certainly ought to be able with a way to construct the class __dict__ in the desired order. Is there even a situation where Cython would need to support the construction of forms, trait[let]s, or named tuples using Cython code in a way that the order is discoverable afterwards? (I imagine that Cython would love the named tuple idea, but they'd know the field definition order at compile time, so why would they also need it at runtime?) So I'm happy to continue thinking about this, but I expect this is not such a big deal as you fear. Anyway, let's see if someone comes up with a more convincing argument by beta 2! --Guido On Sat, Sep 10, 2016 at 4:19 AM, Nick Coghlan wrote: > On 10 September 2016 at 19:27, Nick Coghlan wrote: >> On 10 September 2016 at 17:49, Ethan Furman wrote: >>> The "mostly" is what concerns me. Much like having a custom __dir__ lets >>> a class fine-tune what is of interest, a custom __definition_order__ allows >>> a class to present a unified view of the class creation process. This could >>> be important to classes that employ __getattr__ (or __getattribute__) to >>> provide virtual attributes, such as Enum or proxy classes. >> >> +1 >> >> The reasoning for modifying the PEP post-acceptance is faulty - >> __definition_order__ wasn't just there as a CPython implementation >> detail, it was there as a way to allow class and metaclass developers >> to hide their *own* irrelevant implementation details. >> >> Since __definition_order__ was already accepted, and the rationale for >> removing it is incorrect, could we please have it back for beta 1? > > After posting this, I realised I should give a bit more detail on why > I see PEP 520 without __definition_order__ as potentially problematic. > Specifically, it relates to these two sections in the PEP about having > __definition_order__ be writable and about whether or not to set it > for classes that aren't created via the class syntax: > > * https://www.python.org/dev/peps/pep-0520/#why-not-a-read-only-attribute > * https://www.python.org/dev/peps/pep-0520/#support-for-c-api-types > > From the first section: "Also, note that a writeable > __definition_order__ allows dynamically created classes (e.g. by > Cython) to still have __definition_order__ properly set. That could > certainly be handled through specific class- creation tools, such as > type() or the C-API, without the need to lose the semantics of a > read-only attribute. However, with a writeable attribute it's a moot > point. " > > From the second: "However, since __definition_order__ can be set at > any time through normal attribute assignment, it does not need any > special treatment in the C-API." > > Unlike the __definition_order__ tuple, making "list(cls.__dict__)" the > official way of accessing the definition order exposes an > implementation detail that's somewhat specific to the way Python class > statements work, rather than being universal across all the different > techniques that exist for putting together Python class objects. > > As Terry suggested, I've reopened and elevated the priority of > http://bugs.python.org/issue24254, but only to deferred blocker - > while I do think we need to reconsider the decision to remove > __definition_order__ based on a proper update to the PEP that accounts > fo
Re: [Python-Dev] PEP520 and absence of __definition_order__
On 11 September 2016 at 03:08, Guido van Rossum wrote: > So I'm happy to continue thinking about this, but I expect this is not > such a big deal as you fear. Anyway, let's see if someone comes up > with a more convincing argument by beta 2! For CPython specifically, I don't have anything more convincing than Ethan's Enum example (where the way the metaclass works means most of the interesting attributes don't live directly in the class dict, they live in private data structures stored in the class dict, making "list(MyEnum.__dict__)" inherently uninteresting, regardless of whether it's ordered or not). The proxy use cases I'm aware of (wrapt, weakref.proxy) tend to be used to wrap normal instances rather than class objects themselves, so they shouldn't be affected. With ordered-by-default class namespaces, both heap types and non-heap types should also mostly be populated in the "logical order" (i.e. the order names appear in the relevant C arrays), but that would formally be an implementation detail at this point, rather than something we commit to providing. The only other argument that occurs to me is one that didn't come up in the earlier PEP 520 discussions: how a not-quite-Python implementation (or a Python 3.5 compatible implementation that doesn't offer order-preserving behaviour the way PyPy does) can make sure that code that relies on ordered class namespaces *fails* in an informative way when run on that implementation. With __definition_order__, that's straightforward - the code that needs it will fail with AttributeError, and searching for the attribute named in the exception will lead affected users directly to PEP 520 and the Python 3.6 What's New guide. With implicitly ordered class namespaces, you don't get an exception if the namespace isn't actually order preserving - you get attributes in an arbitrary order instead. Interpreters can't detect that the user specifically wanted order preserving behaviour, and library and application authors can't readily detect whether or not the runtime offers order preserving behaviour (since they may just get lucky on that particular run). Even if we added a new flag to sys.implementation that indicated the use of order preserving class namespaces, there'd still be plenty of scope for subtle bugs where libraries and frameworks weren't checking that flag before relying on the new behaviour. Cheers, Nick. P.S. I'd actually love it if we could skip __definition_order__ - there really is a whole lot of runtime clutter on class objects, and we're adding __annotations__ as well. Unfortunately, I also think we made the right call the first time around in thinking it would still be necessary even if class namespaces became order preserving :) -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Let's make the SSL module sane
On 2016-09-10 18:24, Donald Stufft wrote: > >> On Sep 10, 2016, at 10:22 AM, Christian Heimes wrote: >> >> I don't load any certs because it is not possible to remove a cert or >> X509 lookup once it is loaded. create_default_context() just have to >> load the certs and set more secure ciper suites. > > > This part is the most concerning to me, though I understand why it’s the > case. Perhaps we can do something a little tricky to allow both things to > happen? IOW do sort of a late binding of a call to loading the default > certificates if no other certificates has been loaded when the call to > SSLContext().wrap_socket() has been made. > > So we’d do something like: > > > class SSLContext: > def __init__(self, …): > self._loaded_certificates = False > … # Do Other Stuff > > def load_default_certs(self, …): > self._loaded_certificates = True > … # Do Other Stuff > > def load_verify_locations(self, …): > self._loaded_certificates = True > … # Do Other Stuff > > def wrap_socket(self, …): > if not self._loaded_certificates: > self.load_default_certs() > > … # Do Other Stuff > > > That way if someone does something like: > > ctx = ssl.SSLContext(ssl.PROTOCOL_TLS_CLIENT) > ctx.load_verify_locations(cafile=“…”) > ctx.wrap_socket(…) > > Then they don’t get any default certificates added, HOWEVER if they do: > > ctx = ssl.SSLContext(ssl.PROTOCOL_TLS_CLIENT) > ctx.wrap_socket(…) > > Then they do. > > The main draw back I can see with this is that you can’t wrap a socket and > then add certificates after the fact… but I don’t even know if that makes > sense to do? It's a bit too clever and tricky for my taste. I prefer 'explicit is better than implicit' for trust anchors. My main concern are secure default settings. A SSLContext should be secure w/o further settings in order to prevent developers to shoot themselves in the knee. Missing root certs are not a direct security issue with CERT_REQUIRED. The connection will simply fail. I'd rather improve the error message than to auto-load certs. Christian ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP520 and absence of __definition_order__
On Sep 10, 2016 11:00, "Nick Coghlan" wrote: > > On 11 September 2016 at 03:08, Guido van Rossum wrote: > > So I'm happy to continue thinking about this, but I expect this is not > > such a big deal as you fear. Anyway, let's see if someone comes up > > with a more convincing argument by beta 2! , > Nick. > > P.S. I'd actually love it if we could skip __definition_order__ - > there really is a whole lot of runtime clutter on class objects, and > we're adding __annotations__ as well. Unfortunately, I also think we > made the right call the first time around in thinking it would still > be necessary even if class namespaces became order preserving :) > > -- > Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/ericsnowcurrently%40gmail.com -eric (phone) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP520 and absence of __definition_order__
On Sep 10, 2016 10:11, "Guido van Rossum" wrote: > > Thanks for bringing this up. I think it's definitely possible to argue > either way. I think what happened before was that I approved > __definition_order__ because I wasn't expecting dict to be ordered by > default. Now that Inada Naoki's patch has landed things have changed. > > Here's my reason for agreeing with (or convincing?) Eric to drop > __definition_order__, as I remember it from the (lively) discussion at > the sprint. > FWIW, my position was to leave __definition_order__ in place. However, once it became *mostly* redundant, I didn't consider the remaining benefits to be sufficient justification for the extra complexity in the code to the point that it was worth debating. So I didn't object very strenuously when Benjamin suggested removing it. Regardless, I'm still in favor of keeping __definition_order__. :) -eric (phone) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Let's make the SSL module sane
On 2016-09-10 17:24, Nick Coghlan wrote: > On 11 September 2016 at 00:22, Christian Heimes wrote: >> First I like to deprecated some old APIs and favor of SSLCotext. We have >> multiple ways to create a SSL socket or to configure libraries like >> urllib. The general idea is to make SSLContext the central object for >> TLS/SSL configuration. My patch deprecates ssl.wrap_socket() > > I'll bring over my question from the tracker issue to here: there's a > subset of ssl.wrap_socket() arguments which actually make sense as > arguments to ssl.get_default_context().wrap_socket(). > > Accordingly, we can pick a subset of code (e.g. SSL/TLS clients) that > we bless with not needing to change, leaving only code using > deprecated parameters or creating server sockets that needs to be > updated. Do you consider ssl.wrap_socket() relevant for so many projects? The function hurts performance and is no longer best practice. The deprecation of ssl.wrap_socket() is a friendly nudge. I don't mind to keep it around for another four or six years. There is one other use case not covered by SSLContext.wrap_socket() but by SSLSocket.__init__(). The SSLSocket constructor takes a fileno argument. But it's an undocumented feature and it's broken since at least 3.3. https://bugs.python.org/issue27629 > As with past network security changes, a major factor we need to > account for is that no matter how valuable a particular goal is from a > broader industry perspective, people don't tend to react to API breaks > by fixing their code - they react by not upgrading at all. I totally agree and have been verify careful to keep backwards compatibility. My third patch breaks just one scenario: ssl.create_default_context(purpose=Purpose.SERVER_AUTH) no longer supports server-side connections and CLIENT_AUTH no longer client-side connections. It's the good kind of incompatibility because it reveals API misuse. Application should never have used SERVER_AUTH context to create server sockets. Christian ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP520 and absence of __definition_order__
On Sat, Sep 10, 2016 at 10:57 AM, Nick Coghlan wrote: > On 11 September 2016 at 03:08, Guido van Rossum wrote: >> So I'm happy to continue thinking about this, but I expect this is not >> such a big deal as you fear. Anyway, let's see if someone comes up >> with a more convincing argument by beta 2! > > For CPython specifically, I don't have anything more convincing than > Ethan's Enum example (where the way the metaclass works means most of > the interesting attributes don't live directly in the class dict, they > live in private data structures stored in the class dict, making > "list(MyEnum.__dict__)" inherently uninteresting, regardless of > whether it's ordered or not). But that would only matter if we also defined a helper utility that used __definition_order__. I expect that the implementation of Enum could be simplified somewhat in Python 3.6 since it can trust that the namespace passed into __new__ is ordered (so it doesn't have to switch it to an OrderedDict in __prepare__, perhaps). In any case the most likely way to use __definition_order__ in general was always to filter its contents through some other condition (e.g. "isn't a method and doesn't start with underscore") -- you can do the same with keys(). Classes that want to provide a custom list of "interesting" attributes can provide that using whatever class method or attribute they want -- it's just easier to keep those attributes ordered because the namespace is always ordered. > The proxy use cases I'm aware of (wrapt, weakref.proxy) tend to be > used to wrap normal instances rather than class objects themselves, so > they shouldn't be affected. > > With ordered-by-default class namespaces, both heap types and non-heap > types should also mostly be populated in the "logical order" (i.e. the > order names appear in the relevant C arrays), but that would formally > be an implementation detail at this point, rather than something we > commit to providing. > > The only other argument that occurs to me is one that didn't come up > in the earlier PEP 520 discussions: how a not-quite-Python > implementation (or a Python 3.5 compatible implementation that doesn't > offer order-preserving behaviour the way PyPy does) can make sure that > code that relies on ordered class namespaces *fails* in an informative > way when run on that implementation. Is that a real use case? It sounds like you're just constructing an artificial example that would be less convenient without __definition_order__. > With __definition_order__, that's straightforward - the code that > needs it will fail with AttributeError, and searching for the > attribute named in the exception will lead affected users directly to > PEP 520 and the Python 3.6 What's New guide. But that code would have to be written to use __definition_order__. It could just as easily be written to assert that sys.version_info() >= (3, 6). > With implicitly ordered class namespaces, you don't get an exception > if the namespace isn't actually order preserving - you get attributes > in an arbitrary order instead. Interpreters can't detect that the user > specifically wanted order preserving behaviour, and library and > application authors can't readily detect whether or not the runtime > offers order preserving behaviour (since they may just get lucky on > that particular run). That sounds very philosophical. You still can't check whether *dict* is order-preserving -- all you can do is checking whether a *class* preserves its order. Since PEP 520 is accepted only for Python 3.6, checking for the presence of __definition_order__ is no different than checking the version. > Even if we added a new flag to sys.implementation that indicated the > use of order preserving class namespaces, there'd still be plenty of > scope for subtle bugs where libraries and frameworks weren't checking > that flag before relying on the new behaviour. OK, I'm beginning to see the argument here. You want all code that relies on the order to be explicitly declaring that it does so by using a new API. Unfortunately the mere presence of __definition_order__ doesn't really help here -- since all dicts are order-preserving, there's still nothing (apart from documentation) to stop apps from relying on the ordering of the class __dict__ directly. > Cheers, > Nick. > > P.S. I'd actually love it if we could skip __definition_order__ - > there really is a whole lot of runtime clutter on class objects, and > we're adding __annotations__ as well. Unfortunately, I also think we > made the right call the first time around in thinking it would still > be necessary even if class namespaces became order preserving :) Note that __annotations__ is only added when there are annotations, so its presence could be used as a flag of sorts. (However you shouldn't use it directly -- each class in the MRO has its own __annotations__, and you should use typing.get_type_hints(cls) to coalesce all of them.) -- --Guido van Rossum (python.org/~g
Re: [Python-Dev] Python 3.6 dict becomes compact and gets a private version; and keywords become ordered
On Fri, Sep 9, 2016 at 11:39 AM, Barry Warsaw wrote: > On Sep 09, 2016, at 01:08 PM, Elvis Pranskevichus wrote: > >>Are there any downsides to explicitly specifying that all dicts are ordered? >>People will inevitably start relying on this behaviour, and this will >>essentially become the *de-facto* spec, so alternative Python implementations >>will have to follow suit anyway. > > It *might* make sense to revisit this once 3.5 is no longer maintained at all, > but I think Guido's exactly right in his analysis. If people start relying on > all dicts being ordered now, their code won't be compatible with both 3.5 and > 3.6, and I think it's important to emphasize this to developers. I feel like I'm missing something here... by this reasoning, we should *never* change the language spec when new features are added. E.g. if people use async/await in 3.5 then their code won't be compatible with 3.4, but async/await are still part of the language spec. And in any case, the distinction between "CPython feature" and "Python language-spec-guaranteed feature" is *extremely* arcane and inside-basebally -- it seems really unlikely that most users will even understand what this distinction means, never mind let it stop them from writing CPython-and-PyPy-specific code. Emphasizing that this is a new feature that only exists in 3.6+ of course makes sense, I just don't understand why that affects the language spec bit. (OTOH it doesn't matter that much anyway... the language spec is definitely a useful thing, but it's largely aspirational in practice -- other implementations target CPython compatibility more than they target language spec compatibility.) -n -- Nathaniel J. Smith -- https://vorpus.org ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Installation Error
Good evening! I tried downloading Python yesterday and was met with some success. I have been searching for solutions but can not seem to find one. Each time I try to run python an error occurs saying; python.exe - System Error The program can't start because api-ms-win-crt-runtime-l1-1-0.dll is missing from your computer. Try reinstalling the program to fix this problem. My friend and I tried at our school and was met no success in obtaining the program. I am attempting to run python on a CQ60-615DX Notebook. Any help would be appreciated. Thanks! -- Emails and other correspondence to and from Paradise Valley School District are subject to public disclosure, upon request, according to Arizona Public Records Law (A.R.S. §39-121, et seq.) and corresponding State records retention requirements, unless the content is specifically exempt from disclosure by a state or federal law. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Installation Error
On 2016-09-11 00:44, Trevon Bizzle wrote: Good evening! I tried downloading Python yesterday and was met with some success. I have been searching for solutions but can not seem to find one. Each time I try to run python an error occurs saying; python.exe - System Error The program can't start because api-ms-win-crt-runtime-l1-1-0.dll is missing from your computer. Try reinstalling the program to fix this problem. My friend and I tried at our school and was met no success in obtaining the program. I am attempting to run python on a CQ60-615DX Notebook. Any help would be appreciated. Thanks! You computer needs the Universal C Runtime. An up-to-date system should already have it. Read here: Update for Universal C Runtime in Windows https://support.microsoft.com/en-us/kb/2999226 By the way, this list is for the development *of* the Python language. The list you should really be using is python-l...@python.org. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Let's make the SSL module sane
On 11 September 2016 at 05:20, Christian Heimes wrote: > On 2016-09-10 17:24, Nick Coghlan wrote: >> On 11 September 2016 at 00:22, Christian Heimes wrote: >>> First I like to deprecated some old APIs and favor of SSLCotext. We have >>> multiple ways to create a SSL socket or to configure libraries like >>> urllib. The general idea is to make SSLContext the central object for >>> TLS/SSL configuration. My patch deprecates ssl.wrap_socket() >> >> I'll bring over my question from the tracker issue to here: there's a >> subset of ssl.wrap_socket() arguments which actually make sense as >> arguments to ssl.get_default_context().wrap_socket(). >> >> Accordingly, we can pick a subset of code (e.g. SSL/TLS clients) that >> we bless with not needing to change, leaving only code using >> deprecated parameters or creating server sockets that needs to be >> updated. > > Do you consider ssl.wrap_socket() relevant for so many projects? The > function hurts performance and is no longer best practice. The > deprecation of ssl.wrap_socket() is a friendly nudge. I don't mind to > keep it around for another four or six years. I have no problem with ripping out and replacing the internals of ssl.wrap_socket(), and doing whatever is needed to improve its performance. What I'm mainly looking for is a decision tree in the overall API design that minimises the amount of fresh information a developer needs to supply, and that makes the purpose of their code relatively self-evident to someone that is reading low(ish) level Python SSL/TLS code for the first time. For example, I think this would be a desirably simple design from a usage perspective: # Client sockets as default, settings may change in maintenance releases my_context = ssl.get_default_context() my_tls_socket = ssl.wrap_socket(my_uncovered_socket) # Server sockets by request, settings may change in maintenance releases my_context = ssl.get_default_server_context() my_tls_socket = ssl.wrap_server_socket(my_uncovered_socket) # More control with more responsibility, defaults only change in feature releases my_context = ssl.SSLContext() my_context = ssl.SSLContext(ssl.PROTOCOL_TLS_SERVER) With that approach, an API user only has to make two forced decisions: - am I securing a client connection or a server connection? - do I want to implicitly pick up modernised defaults in maintenance releases? And we can make the second one a non-decision in most cases by presenting the higher level convenience API as the preferred approach. There would be a third hidden decision implied by the convenience APIs (using the default system certificate store rather than loading a custom one), but most users wouldn't need to worry about that. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP520 and absence of __definition_order__
On 11 September 2016 at 07:26, Guido van Rossum wrote: > On Sat, Sep 10, 2016 at 10:57 AM, Nick Coghlan wrote: >> On 11 September 2016 at 03:08, Guido van Rossum wrote: >>> So I'm happy to continue thinking about this, but I expect this is not >>> such a big deal as you fear. Anyway, let's see if someone comes up >>> with a more convincing argument by beta 2! >> >> For CPython specifically, I don't have anything more convincing than >> Ethan's Enum example (where the way the metaclass works means most of >> the interesting attributes don't live directly in the class dict, they >> live in private data structures stored in the class dict, making >> "list(MyEnum.__dict__)" inherently uninteresting, regardless of >> whether it's ordered or not). > > But that would only matter if we also defined a helper utility that > used __definition_order__. I expect that the implementation of Enum > could be simplified somewhat in Python 3.6 since it can trust that the > namespace passed into __new__ is ordered (so it doesn't have to switch > it to an OrderedDict in __prepare__, perhaps). > > In any case the most likely way to use __definition_order__ in general > was always to filter its contents through some other condition (e.g. > "isn't a method and doesn't start with underscore") -- you can do the > same with keys(). Classes that want to provide a custom list of > "interesting" attributes can provide that using whatever class method > or attribute they want -- it's just easier to keep those attributes > ordered because the namespace is always ordered. For example,it's already possible to expose order information via __dir__, consumers of the information just have to bypass the implicit sorting applied by the dir() builtin: >>> class Example: ... def __dir__(self): ... return "first second third fourth".split() ... >>> dir(Example()) ['first', 'fourth', 'second', 'third'] >>> Example().__dir__() ['first', 'second', 'third', 'fourth'] You've persuaded me that omitting __definition_order__ is the right thing to do for now, so the last thing I'm going to do is to explicitly double check with the creators of a few interesting alternate implementations (MicroPython, VOC for JVM environments, Batavia for JavaScript environments) to see if this may cause them problems in officially implementing 3.6 (we know PyPy will be OK, since they did it first). VOC & Batavia *should* be OK (worst case, they return collections.OrderedDict from __prepare__ and also use it for __dict__ attributes), but I'm less certain about MicroPython (since I don't know enough about how its current dict implementation works to know whether or not they'll be able to make the same change PyPy and CPython did) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3.6 dict becomes compact and gets a private version; and keywords become ordered
On 11 September 2016 at 09:41, Nathaniel Smith wrote: > On Fri, Sep 9, 2016 at 11:39 AM, Barry Warsaw wrote: >> On Sep 09, 2016, at 01:08 PM, Elvis Pranskevichus wrote: >> >>>Are there any downsides to explicitly specifying that all dicts are ordered? >>>People will inevitably start relying on this behaviour, and this will >>>essentially become the *de-facto* spec, so alternative Python implementations >>>will have to follow suit anyway. >> >> It *might* make sense to revisit this once 3.5 is no longer maintained at >> all, >> but I think Guido's exactly right in his analysis. If people start relying >> on >> all dicts being ordered now, their code won't be compatible with both 3.5 and >> 3.6, and I think it's important to emphasize this to developers. > > I feel like I'm missing something here... by this reasoning, we should > *never* change the language spec when new features are added. E.g. if > people use async/await in 3.5 then their code won't be compatible with > 3.4, but async/await are still part of the language spec. And in any > case, the distinction between "CPython feature" and "Python > language-spec-guaranteed feature" is *extremely* arcane and > inside-basebally -- it seems really unlikely that most users will even > understand what this distinction means, never mind let it stop them > from writing CPython-and-PyPy-specific code. Emphasizing that this is > a new feature that only exists in 3.6+ of course makes sense, I just > don't understand why that affects the language spec bit. To conform with the updated language spec, implementations just need to use collections.OrderedDict in 3 places: - default return value of __prepare__ - underlying storage type for __dict__ attributes - storage type for passing kwargs to functions They don't *necessarily* have to change their builtin dict type to be order-preserving, as we're not deprecating collections.OrderedDict, and we're not adding the additional methods offered by OrderedDict to the base type. So for normal development, the guidance is still "use collections.OrderedDict explicitly if you need to preserve insertion order", as being more explicit gives compatibility with CPython < 3.6, and with any alternate implementations that take the path of using collections.OrderedDict selectively rather than changing the behaviour of their dict builtin (which was the original plan for CPython). > (OTOH it doesn't matter that much anyway... the language spec is > definitely a useful thing, but it's largely aspirational in practice > -- other implementations target CPython compatibility more than they > target language spec compatibility.) The distinction is that there are cases where we *do* convince library and framework authors to change their code for cross-version and cross-implementation compatibility - the popularity of explicit context management being one of the most significant examples of that, as it's far more necessary on implementations that don't use automatic reference counting the way CPython does. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP520 and absence of __definition_order__
On Sun, Sep 11, 2016 at 11:05 AM, Nick Coghlan wrote: > On 11 September 2016 at 07:26, Guido van Rossum wrote: > > On Sat, Sep 10, 2016 at 10:57 AM, Nick Coghlan > wrote: > >> On 11 September 2016 at 03:08, Guido van Rossum > wrote: > >>> So I'm happy to continue thinking about this, but I expect this is not > >>> such a big deal as you fear. Anyway, let's see if someone comes up > >>> with a more convincing argument by beta 2! > >> > >> For CPython specifically, I don't have anything more convincing than > >> Ethan's Enum example (where the way the metaclass works means most of > >> the interesting attributes don't live directly in the class dict, they > >> live in private data structures stored in the class dict, making > >> "list(MyEnum.__dict__)" inherently uninteresting, regardless of > >> whether it's ordered or not). > > > > But that would only matter if we also defined a helper utility that > > used __definition_order__. I expect that the implementation of Enum > > could be simplified somewhat in Python 3.6 since it can trust that the > > namespace passed into __new__ is ordered (so it doesn't have to switch > > it to an OrderedDict in __prepare__, perhaps). > > > > In any case the most likely way to use __definition_order__ in general > > was always to filter its contents through some other condition (e.g. > > "isn't a method and doesn't start with underscore") -- you can do the > > same with keys(). Classes that want to provide a custom list of > > "interesting" attributes can provide that using whatever class method > > or attribute they want -- it's just easier to keep those attributes > > ordered because the namespace is always ordered. > > For example,it's already possible to expose order information via > __dir__, consumers of the information just have to bypass the implicit > sorting applied by the dir() builtin: > > >>> class Example: > ... def __dir__(self): > ... return "first second third fourth".split() > ... > >>> dir(Example()) > ['first', 'fourth', 'second', 'third'] > >>> Example().__dir__() > ['first', 'second', 'third', 'fourth'] > > You've persuaded me that omitting __definition_order__ is the right > thing to do for now, so the last thing I'm going to do is to > explicitly double check with the creators of a few interesting > alternate implementations (MicroPython, VOC for JVM environments, > Batavia for JavaScript environments) to see if this may cause them > problems in officially implementing 3.6 (we know PyPy will be OK, > since they did it first). > > VOC & Batavia *should* be OK (worst case, they return > collections.OrderedDict from __prepare__ and also use it for __dict__ > attributes), but I'm less certain about MicroPython (since I don't > know enough about how its current dict implementation works to know > whether or not they'll be able to make the same change PyPy and > CPython did) > >From the perspective of VOC and Batavia: As Nick notes, there may be some changes needed to use OrderDict (or a native analog) in a couple of places, but other than that, it doesn’t strike me as a change that will pose any significant difficulty. Yours, Russ Magee %-) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
