[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