[Python-Dev] Is static typing still optional?

Eric V. Smith eric at trueblade.com
Tue Dec 19 02:49:05 EST 2017


On 12/18/2017 9:41 PM, Chris Barker wrote:
> I'm really surprised no one seems to get my point here.
> 
> TL;DR:
> My point is that having type annotation syntax required for something in 
> the stdlib is a significant step toward "normalizing" type hinting in 
> Python. Whether that's a good idea or not is a judgement call, but it IS 
> a big step.

I get your point, I'm just not concerned about it.

I also don't think it's surprising that you can put misleading 
information (including non-types) in type annotations. All of the 
documentation and discussions are quite clear that type information is 
ignored at runtime.

It _is_ true that @dataclass does actually inspect the type at runtime, 
but those uses are very rare. And if you do need them, the actual type T 
used by ClassVar[T] and InitVar[T] are still ignored.

Data Classes is also not the first use of type annotations in the stdlib:
https://docs.python.org/3/library/typing.html#typing.NamedTuple

When I say that "typing is optional", I mean importing the typing 
module, not that annotations are optional.

Eric.

> @Chris
> 
>     People are still allowed not to use dataclasses if they really don't
>     like type hints :-)
>     Seriously however, annotations are just syntax. In this sense PEP
>     526 is more like PEP 3107,
>     and less like PEP 484. People are still free to write:
> 
>     @dataclass
>     class C:
>          x: "first coordinate"
>          y: "second coordinate"
>          plus: "I don't like types"
> 
> 
> Well, yes, of course, but this is not like PEP 3107, as it introduces a 
> requirement for annotations (maybe not *type* annotations per se) in the 
> std lib. Again, that may be the best way to go -- but it should be done 
> deliberately.
> 
> @dataclass
> 
>     class C:
>          x: ...
>          y: ...
> 
> 
> Ah! I had no idea you could use ellipses to indicate no type. That 
> actually helps a lot. We really should have that prominent in the docs. 
> And in the dataclass docs, not just the type hinting docs -- again, 
> people will want to use these that may not have any interest in nor 
> prior knowledge of type hints.
> 
>     I don't see so big difference between hypothesis (testing lib) using
>     annotations for their purposes
>     from the situation with dataclasses.
> 
> 
> The big difference is that hypothesis is not in the standard library. 
> Also, I didn't know about hypothesis until just now, but their very 
> first example in the quick start does not use annotation syntax, so it's 
> not as baked in as it is with dataclasses.
> 
>     If you have ideas about how to improve the dataclass docs, this can
>     be discussed in the issue https://bugs.python.org/issue32216
>     <https://bugs.python.org/issue32216>
> 
> 
> I'll try to find time to contribute there -- though maybe better to have 
> the doc draft in gitHub?
> 
>      > ... the type will in fact be completely ignored by the
>     implementation.
>     > Newbies are going to be confused by this -- they really are.
> 
>     This is not different from
> 
>     def f(x: int):
>          pass
> 
>     f("What")  # OK
> 
>     that exists starting from Python 3.0. Although I agree this is
>     confusing, the way forward could be just explaining this better in
>     the docs.
> 
> 
> Again the difference is that EVERY introduction to defining python 
> functions doesn't use the type hint. And even more to the point, you CAN 
> define a function without any annotations.
> 
> But frankly, I think as type hinting becomes more common, we're going to 
> see a lot of confusion :-(
> 
>     If you want my personal opinion about the current situation about
>     type hints _in general_, then I can say that
>     I have seen many cases where people use type hints where they are
>     not needed
>     (for example in 10 line scripts or in highly polymorphic functions),
>     so I agree that some community
>     style guidance (like PEP 8) may be helpful. 
> 
> 
> It's going to get worse before it gets better :-(
> 
>     @dataclass
>     class C:
>           x = field()
> 
> 
> that does require that `field` be imported, so not as nice. I kinda like 
> the ellipses better.
> 
> but good to have a way.
> 
> -Chris
> 
> 
> -- 
> 
> Christopher Barker, Ph.D.
> Oceanographer
> 
> Emergency Response Division
> NOAA/NOS/OR&R            (206) 526-6959   voice
> 7600 Sand Point Way NE   (206) 526-6329   fax
> Seattle, WA  98115       (206) 526-6317   main reception
> 
> Chris.Barker at noaa.gov <mailto:Chris.Barker at noaa.gov>
> 
> 
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/eric%2Ba-python-dev%40trueblade.com
> 



More information about the Python-Dev mailing list