Re: [Python-Dev] Issues with PEP 526 Variable Notation at the class level
Hello, I'm one of the attrs contributors, and the person who initially wrote the slots functionality there. We've given up on returning a new class always since this can conflict with certain metaclasses (have you noticed you can't make a slots attrs class inheriting from Generic[T]?) and with PEP 487. I think with PEP 487 it's becoming especially evident class creation is not necessarily an idempotent operation. I'm currently brainstorming alternative APIs for slots. The best solution would be for Python to actually offer a way to add slotness to a class after it's been defined, and Guido has expressed approval ( https://github.com/ericvsmith/dataclasses/issues/60#issuecomment-348719029). Personally I really like slot classes, both for their memory characteristics and the fact the attributes need to be enumerated beforehand and typos get turned into errors, so I'd welcome any development on this front. :) Date: Sat, 9 Dec 2017 08:52:15 -0500
From: "Eric V. Smith" <eric@trueblade.com> To: Nathaniel Smith <njs@pobox.com> Cc: Python Dev <python-dev@python.org> Subject: Re: [Python-Dev] Issues with PEP 526 Variable Notation at the class level Message-ID: <f76fa8aa-36f6-9ac7-5789-68e3c0c61e0b@trueblade.com> Content-Type: text/plain; charset=utf-8; format=flowed
On 12/8/2017 9:14 PM, Nathaniel Smith wrote:
On Dec 7, 2017 12:49, "Eric V. Smith" <eric@trueblade.com <mailto:eric@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:
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. -
Hi, On Sun, 10 Dec 2017 19:17:25 +0000 Tin Tvrtković <tinchester@gmail.com> wrote:
Hello,
I'm one of the attrs contributors, and the person who initially wrote the slots functionality there.
We've given up on returning a new class always since this can conflict with certain metaclasses (have you noticed you can't make a slots attrs class inheriting from Generic[T]?) and with PEP 487. I think with PEP 487 it's becoming especially evident class creation is not necessarily an idempotent operation.
Hmm... I understand you may be restricted by backwards compatibility here. But dataclasses don't have that issue, so we could decide we're incompatible with certain dataclasses from day 1.
I'm currently brainstorming alternative APIs for slots. The best solution would be for Python to actually offer a way to add slotness to a class after it's been defined, and Guido has expressed approval ( https://github.com/ericvsmith/dataclasses/issues/60#issuecomment-348719029).
The problem is less the API but the implementation. As Guido pointed out, this means the instance layout may now change after class definition. One possibility would be to allow changing the layout before the first instance (or even subclass) is instantiated, after which it would raise an error. Regards Antoine.
On Sun, 10 Dec 2017 20:47:45 +0100 Antoine Pitrou <solipsis@pitrou.net> wrote:
Hi,
On Sun, 10 Dec 2017 19:17:25 +0000 Tin Tvrtković <tinchester@gmail.com> wrote:
Hello,
I'm one of the attrs contributors, and the person who initially wrote the slots functionality there.
We've given up on returning a new class always since this can conflict with certain metaclasses (have you noticed you can't make a slots attrs class inheriting from Generic[T]?) and with PEP 487. I think with PEP 487 it's becoming especially evident class creation is not necessarily an idempotent operation.
Hmm... I understand you may be restricted by backwards compatibility here. But dataclasses don't have that issue, so we could decide we're incompatible with certain dataclasses from day 1.
Sorry... make that "incompatible with certain metaclasses" ;-) Regards Antoine.
OTOH daytaclass is a decorator for *better* metaclass compatibility. On Dec 10, 2017 13:17, "Antoine Pitrou" <solipsis@pitrou.net> wrote:
On Sun, 10 Dec 2017 20:47:45 +0100 Antoine Pitrou <solipsis@pitrou.net> wrote:
Hi,
Hello,
I'm one of the attrs contributors, and the person who initially wrote
On Sun, 10 Dec 2017 19:17:25 +0000 Tin Tvrtković <tinchester@gmail.com> wrote: the
slots functionality there.
We've given up on returning a new class always since this can conflict with certain metaclasses (have you noticed you can't make a slots attrs class inheriting from Generic[T]?) and with PEP 487. I think with PEP 487 it's becoming especially evident class creation is not necessarily an idempotent operation.
Hmm... I understand you may be restricted by backwards compatibility here. But dataclasses don't have that issue, so we could decide we're incompatible with certain dataclasses from day 1.
Sorry... make that "incompatible with certain metaclasses" ;-)
Regards
Antoine.
_______________________________________________ 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/ guido%40python.org
participants (3)
-
Antoine Pitrou -
Guido van Rossum -
Tin Tvrtković