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

[Guido van Rossum]

On Fri, Dec 8, 2017 at 3:44 PM, Eric V. Smith <eric at trueblade.com> wrote:

> On 12/8/2017 1:28 PM, Raymond Hettinger wrote:
>
>>
>>
>> On Dec 7, 2017, at 12:47 PM, Eric V. Smith <eric at trueblade.com> wrote:
>>>
>>> On 12/7/17 3:27 PM, Raymond Hettinger wrote:
>>> ...
>>>
>>> I'm looking for guidance or workarounds for two issues that have arisen.
>>>>
>>>> First, the use of default values seems to completely preclude the use
>>>> of __slots__.  For example, this raises a ValueError:
>>>>
>>>>     class A:
>>>>         __slots__ = ['x', 'y']
>>>>         x: int = 10
>>>>         y: int = 20
>>>>
>>>
>>> Hmm, I wasn't aware of that. I'm not sure I understand why that's an
>>> error. Maybe it could be fixed?
>>>
>>
>> The way __slots__ works is that the type() metaclass automatically
>> assigns member-objects to the class variables 'x' and 'y'.  Member objects
>> are descriptors that do the actual lookup.
>>
>> So, I don't think the language limitation can be "fixed".  Essentially,
>> we're wanting to use the class variables 'x' and 'y' to hold both member
>> objects and a default value.
>>
>
> Thanks. I figured this out after doing some research. Here's a thread
> "__slots__ and default values" from 14+ years ago from some guy named
> Hettinger:
> https://mail.python.org/pipermail/python-dev/2003-May/035575.html
>
> As to whether we add slots=True to @dataclasses, I'll let Guido decide.
>
> The code already exists as a separate decorator here:
> https://github.com/ericvsmith/dataclasses/blob/master/datacl
> ass_tools.py#L3, if you want to play with it.
>
> Usage:
>
> >>> @add_slots
> ... @dataclass
> ... class A:
> ...     x: int = 10
> ...     y: int = 20
> ...
> >>> a = A()
> >>> a
> A(x=10, y=20)
> >>> a.x = 15
> >>> a
> A(x=15, y=20)
> >>> a.z = 30
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
> AttributeError: 'A' object has no attribute 'z'
>
> Folding it in to @dataclass is easy enough. On the other hand, since it
> just uses the dataclasses public API, it's not strictly required to be in
> @dataclass.
>

Let's do it. For most people the new class is an uninteresting
implementation detail; for the rest we can document clearly that it is
special.


> The second issue is that the different annotations give different
>>>> signatures than would produced for manually written classes.  It is unclear
>>>> what the best practice is for where to put the annotations and their
>>>> associated docstrings.
>>>>
>>>
>>> I don't have any suggestions here.
>>>
>>
>> I'm hoping the typing experts will chime in here.  The question is
>> straight-forward.  Where should we look for the signature and docstring for
>> constructing instances?  Should they be attached to the class, to
>> __init__(), or to __new__() when it used.
>>
>> It would be nice to have an official position on that before, it gets set
>> in stone through arbitrary choices made by pycharm, pydoc, mypy,
>> typing.NamedTuple, and dataclasses.dataclass.
>>
>
> I'm not sure I see why this would relate specifically to typing, since I
> don't think they'd inspect docstrings. But yes, it would be good to come to
> an agreement.
>

I don't recall in detail what all these tools and classes do with
docstrings. Maybe if someone summarizes the status quo and explains how PEP
557 changes that it will be simple to decide.

-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20171208/3e32249e/attachment.html>