[Python-Dev] Preserving the definition order of class namespaces. (original) (raw)

Jim J. Jewett jimjjewett at gmail.com
Tue May 26 17:13:18 CEST 2015

On Sun May 24 12:06:40 CEST 2015, Nick Coghlan wrote:

On 24 May 2015 at 19:44, Mark Shannon wrote:

On 24/05/15 10:35, Nick Coghlan wrote:

If we leave definitionorder out for the time being then, for the vast majority of code, the fact that the ephemeral namespace used to evaluate the class body switched from being a basic dictionary to an ordered one would be a hidden implementation detail, rather than making all type objects a little bigger.

and a little slower.

The runtime namespace used to store the class attributes is remaining a plain dict object regardless,

Lookup isn't any slower in the ordereddict.

Inserts are slower -- and those would happen in the ordereddict, as the type object is being defined.

Note that since we're talking about the type objects, rather than the instances, most* long-running code won't care, but it will hurt startup time.

*code which creates lots of throwaway classes is obviously an exception.

FWIW, much of the extra per-insert cost is driven by either the need to keep deletion O(1) or the desire to keep the C layout binary compatible.

A different layout (with its own lookdict) could optimize for the insert-each-value-once case, or even for small dicts (e.g., keyword dicts). I could imagine this producing a speedup, with the ordering being just a side benefit. It is too late to use such a new layout by default in 3.5, but we should be careful not to close it off. (That said, I don't think definition_order would actually close it off, though it might start to look like a wart.)

-jJ

--

If there are still threading problems with my replies, please email me with details, so that I can try to resolve them. -jJ

More information about the Python-Dev mailing list