On Thu, Dec 21, 2017 at 7:55 PM, Terry Reedy <tjre...@udel.edu> wrote:
> On 12/21/2017 9:23 AM, Eric V. Smith wrote: > >> >> >> On 12/21/17 6:25 AM, Sven R. Kunze wrote: >> >>> On 21.12.2017 11:22, Terry Reedy wrote: >>> >>>> >>>> @dataclass >>>>>> class C: >>>>>> a: int # integer field with no default >>>>>> b: float = 0.0 # float field with a default >>>>>> >>>>>> And the types will be recognized by type checkers such as mypy. >>>>>> >>>>>> And I think the non-typed examples should go first in the docs. >>>>>> >>>>> >>>> >>> I still don't understand why "I don't care" can be defined by "leaving >>> out" >>> >>> @dataclass >>> class C: >>> b = 0.0 # float field with a default >>> >> >> Because you can't know the order that x and y are defined in this example: >> >> class C: >> x: int >> y = 0 >> >> 'x' is not in C.__dict__, and 'y' is not in C.__annotations__. >> > > Solely because, annotations being optional, the interpreter is not allowed to infer from its presence that an annotated name should be allocated an entry in __dict__, and clearly the value associated with it would be problematical. I think the understanding problem with this feature arises from two > factors: using annotations to define possibly un-initialized slots is > non-obvious; a new use of annotations for something other than static > typing is a bit of a reversal of the recent pronouncement 'annotations > should only be used for static typing'. Therefore, getting the permanent > doc 'right' is important. > Indeed. So annotations are optional, except where they aren't? > The following naively plausible alternative does not work and cannot > sensibly be made to work because the bare 'x' in the class scope, as > opposed to a similar error within a method, causes NameError before the > class is created. > > @dataclass > class C: > x > y = 0 > > Quite. Could this be handled the same way not-yet initilialised slots are? (Pardon my ignornace). > I think the doc should explicitly say that uninitialized fields require > annotation with something (anything, not necessarily a type) simply to > avoid NameError during class creation. It may not be obvious to some > readers why x:'anything' does not also raise NameError, but that was a > different PEP, and the dataclass doc could here link to wherever > name:annotation in bodies is explained. > > This contortion is why I feel a better solution would be desirable. Alas I do not have one to hand. regards Steve
_______________________________________________ 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/archive%40mail-archive.com