[Python-Dev] Issues with PEP 526 Variable Notation at the class level (original) (raw)

Guido van Rossum guido at python.org
Fri Dec 8 18:56:17 EST 2017

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 asstools.py#L3, if you want to play with it. Usage: >>> @addslots ... @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 "", line 1, in 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>

More information about the Python-Dev mailing list