Home Original page

[Python-Dev] Is static typing still optional?

Eric V. Smith eric at trueblade.com
Tue Dec 26 21:20:45 EST 2017 
On 12/21/2017 6:36 AM, Ivan Levkivskyi wrote:
> On 21 December 2017 at 11:22, Terry Reedy <tjreedy at udel.edu 
> <mailto:tjreedy at udel.edu>> wrote:
> 
>     On 12/21/2017 4:22 AM, Eric V. Smith wrote:
> 
>         On 12/21/2017 1:46 AM, Chris Barker wrote:
> 
> 
>             I suggest that it be clear in the docs, and ideally in the
>             PEP, that the dataclass decorator is using the *annotation"
>             syntax, and that the the only relevant part it uses is that
>             an annotation exists, but the value of the annotation is
>             essentially (completely?) ignored.
> 
> 
>         I think the PEP is very clear about this: "The dataclass
>         decorator examines the class to find fields. A field is defined
>         as any variable identified in __annotations__. That is, a
>         variable that has a type annotation. With two exceptions
>         described below, none of the Data Class machinery examines the
>         type specified in the annotation."
> 
> 
>     This seems clear enough.  It could come after describing what a
>     dataclass *is*.
> 
>         I agree the docs should also be clear about this.
> 
> 
> 
>             So we should have examples like:
> 
>             @dataclass
>             class C:
>                   a: ...  # field with no default
>                   b: ... = 0 # filed with a default value
> 
>             Then maybe:
> 
>             @dataclass
>             class C:
>                   a: "the a parameter" # field with no default
>                   b: "another, different parameter" = 0.0 # field with a
>             default
> 
>             Then the docs can go to say that if the user wants to
>             specify a type for use with a static type checking
>             pre-processor, they can do it like so:
> 
>             @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.
> 
> 
>     Module some bike-shedding, the above seems pretty good to me.
> 
> 
> For me, the three options for "don't care" have a bit different meaning:
> 
> * typing.Any: this class is supposed to be used with static type 
> checkers, but this field is too dynamic
> * ... (ellipsis): this class may or may not be used with static type 
> checkers, use the inferred type in the latter case
> * "field docstring": this class should not be used with static type checkers
> 
> Assuming this, the second option would be the "real" "don't care". If 
> this makes sense,
> then we can go the way proposed in 
> https://github.com/python/typing/issues/276 and make ellipsis semantics 
> "official" in PEP 484.
> (pending Guido's approval)

In 
https://github.com/ericvsmith/dataclasses/issues/2#issuecomment-353918024, 
Guido has suggested using `object`, which has the benefit of not needing 
an import. And to me, it communicates the "don't care" aspect well 
enough. I do understand the difference if you're using a type checker 
(see for example 
https://stackoverflow.com/questions/39817081/typing-any-vs-object), but 
if you care about that, use typing.Any.

Eric.
More information about the Python-Dev mailing list