[Python-Dev] Is static typing still optional?

[Chris Barker]

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.


@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
>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20171218/ee83f06e/attachment-0001.html>