[Python-Dev] PEP520 and absence of definition_order (original) (raw)

Nick Coghlan ncoghlan at gmail.com
Sat Sep 10 13:57:35 EDT 2016

On 11 September 2016 at 03:08, Guido van Rossum <guido at 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 | ncoghlan at gmail.com | Brisbane, Australia

More information about the Python-Dev mailing list