[Python-Dev] PEP 557: Data Classes

[Guido van Rossum]

On Mon, Sep 11, 2017 at 6:51 AM, Eric V. Smith <eric at trueblade.com> wrote:

> On 9/11/17 9:43 AM, tds333 at mailbox.org wrote:
>
>> Hi Eric,
>>
>> I have on question not addressed yet.
>> The implementation is based on "__annotations__" where the type is
>> specified.
>> But "__annotations__" is not always filled. An interpreter version with
>> special optimization
>> could remove all __annotations__ for performance reasons. (Discussed in
>> other threads)
>>
>> In this case the dataclass does not work or will there be a fallback?
>>
>> I know it is a little bit hypothetical because an interpreter with this
>> optimization is
>> not there yet. I am looking only in the future a bit.
>> Asking this because type annotations are stated as completely optional
>> for Python.
>> And this use case will break this assumption.
>>
>
> Yes, if there are no __annotations__, then Data Classes would break.
> typing.NamedTuple has the same issue. We discussed it a little bit last
> week, but I don't think we came to any conclusions.
>
> Since @dataclass ignores the value of the annotation (except for
> typing.ClassVar), it would continue to work if the type was present, buy
> maybe mapped to None or similar.
>

Let's not worry about a future where there's no __annotations__. Type
annotations will gradually become more mainstream. You won't have to use
them, but some newer features of the language will be inaccessible if you
don't. This has already started with the pattern based on inheriting from
typing.NamedTuple and using field annotations. Dataclasses are simply
another example.

(That said, I strongly oppose *runtime type checking* based on annotations.
It's by and large a mistaken idea. But this has nothing to do with that.)

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