[Python-Dev] Preserving the definition order of class namespaces.
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 <mark at hotpy.org> wrote:
>> On 24/05/15 10:35, Nick Coghlan wrote:
>>> If we leave __definition_order__ 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
*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.)
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