On 11 September 2016 at 03:08, Guido van Rossum <gu...@python.org> 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
