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>
