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.bar...@noaa.gov
_______________________________________________ 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
