[Python-Dev] Issues with PEP 526 Variable Notation at the class level

[Nick Coghlan]

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