On Sun, Mar 25, 2018 at 5:23 AM Nick Coghlan <ncogh...@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
_______________________________________________ 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
