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.bar...@noaa.gov <mailto: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/eric%2Ba-python-dev%40trueblade.com
_______________________________________________
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
