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

Eric V. Smith eric at trueblade.com
Sat Dec 9 08:52:15 EST 2017


On 12/8/2017 9:14 PM, Nathaniel Smith wrote:
> On Dec 7, 2017 12:49, "Eric V. Smith" <eric at trueblade.com 
> <mailto:eric at trueblade.com>> wrote:
> 
>     The reason I didn't include it (as @dataclass(slots=True)) is
>     because it has to return a new class, and the rest of the dataclass
>     features just modifies the given class in place. I wanted to
>     maintain that conceptual simplicity. But this might be a reason to
>     abandon that. For what it's worth, attrs does have an
>     @attr.s(slots=True) that returns a new class with __slots__ set.
> 
> 
> They actually switched to always returning a new class, regardless of 
> whether slots is set:
> 
> https://github.com/python-attrs/attrs/pull/260

In the end, it looks like that PR ended up just refactoring things, and 
the decision to always return a new class was deferred. I still haven't 
finished evaluating exactly what the refactoring does, though.

Eric.

> 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__.

They have a bunch of test cases that I'll have to review, too.

Eric.



More information about the Python-Dev mailing list