On 9 December 2017 at 12:14, Nathaniel Smith <n...@pobox.com> wrote: > You'd have to ask Hynek to get the full rationale, but I believe it was both > for consistency with slot classes, and for consistency with regular class > definition. For example, type.__new__ actually does different things > depending on whether it sees an __eq__ method, so adding a method after the > fact led to weird bugs with hashing. That class of bug goes away if you > always set up the autogenerated methods and then call type.__new__.
The main case I'm aware of where we do method inference in type.__new__ is setting "__hash__ = None" if "__eq__" is set. The main *problem* that arises with type replacement is that it currently interacts pretty badly with zero-argument super, since we don't make it easy to find and remap all the "__class__" references to the new class object. So right now, I think this trade-off tilts heavily in favour of "Keep the same class, but reimplement any required method inference logic when injecting methods". Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ 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
