[Python-Dev] Issues with PEP 526 Variable Notation at the class level (original) (raw)

Nick Coghlan ncoghlan at gmail.com
Sat Dec 9 22:25:58 EST 2017

On 9 December 2017 at 12:14, Nathaniel Smith <njs at 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 | ncoghlan at gmail.com | Brisbane, Australia

More information about the Python-Dev mailing list