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
>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4