[Python-Dev] Replacing self.dict in init (original) (raw)

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(newattrs) 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