[Python-Dev] Replacing self.__dict__ in __init__

Tin Tvrtković tinchester at gmail.com
Sun Mar 25 11:38:58 EDT 2018


On Sun, Mar 25, 2018 at 5:23 AM Nick Coghlan <ncoghlan at gmail.com> wrote:

> That depends on what you mean by "safe" :)
>
> It won't crash, but it will lose any existing entries that a metaclass,
> subclass, or __new__ method implementation might have added to the instance
> dictionary before calling the __init__ method. That can be OK in a tightly
> controlled application specific class hierarchy, but it would be
> questionable in a general purpose utility library that may be combined with
> arbitrary other types.
>
> As Kirill suggests, `self.__dict__.update(new_attrs)` is likely to be
> faster than repeated assignment statements, without the potentially odd
> interactions with other instance initialisation code.
>
> It should also be explicitly safe to do in the case of "type(self) is
> __class__ and not self.__dict__", which would let you speed up the common
> case of direct instantiation, while falling back to the update based
> approach when combined with other classes at runtime.
>
>
Hm, food for thought, thank you.

The entire point of the exercise is to shave nanoseconds off of __init__.
Using Victor Stinner's excellent pyperf tool and CPython 3.6.3 on Linux, I
see the dict replacement approach always beating the series of assignments
approach, and the update approach always losing to the series of
assignments. For example, for a simple class with 9 attributes:

Series of assignments: Mean +- std dev: 1.31 us +- 0.06 us
Dict replacement: Mean +- std dev: 1.04 us +- 0.04 us
Dict update: Mean +- std dev: 1.67 us +- 0.06 us
Nick's guard: 1.34 us +- 0.03 us

Based on these numbers, I don't think the update approach and the guard
approach are worth doing. The dict replacement approach is 30% faster
though, so it's hard to ignore.

The attrs generated __init__ was always a little special, for example it
never calls super().__init__. Now we just need to figure out how common are
the special cases you called out, and whether to make this vroom-vroom init
opt-in or opt-out.

Kind regards,
Tin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20180325/ddb74141/attachment.html>


More information about the Python-Dev mailing list