> -----Original Message-----
> From: Python-list <python-list-bounces+d.strohl=f5....@python.org> On
> Behalf Of Schachner, Joseph
> Sent: Monday, June 18, 2018 7:58 AM
> To: Ed Kellett <e+python-l...@kellett.im>; python-list@python.org
> Subject: RE: syntax difference (type hints)
>
> EXTERNAL MAIL: python-list-bounces+d.strohl=f5....@python.org
>
> Assuming that we want Python to remain a dynamically typed (but strongly
> typed) language, I believe the proposed type hints are only necessary for
> function definitions, where the caller really needs to know the types of
> arguments to pass in. At the moment that purpose is (I think adequately)
> served by def strings, triple quoted strings immediately following the
> function
> declaration. When I do code reviews for Python developed here, if the
> argument names of a function do not hint at the type they should be and there
> is no def string then I insist that something be added. Often what gets added
> is a def string that says something about what the function does and explains
> what argument types are expected.
>
> -- Joseph S.
>
I like having the option to add type hints to various things, including
functions, but also classes, and the methods, and attributes of a class.
While I don't add them to every one of these every time, if I write a function
that I expect to be used by someone else, I will annotate it. Similarly, if I
write a class that I expect to be instantiated or sub-classed as part of a
library, I will annotate that as well, including any attributes that I expect
to be used or changed.
I haven't totally utilized the new type hinting yet, I am still often still
documenting in the triple quoted strings using epytext type hinting, but that
doesn't really handle things like "a list of strings", or even worse, " a
dictionary that looks like dict("key1":1, "key2":"foobar") in a "standard" way
(that I have found at least), or cases where an argument can be a string OR an
int, or a list. (I use the string/list option pretty regularly when I have
functions that can handle one object, or multiple ones, and I've already used
the * to break out something else). I'm looking forward to finding the time to
figure out how to best annotate those types of things.
And I have found that having these things well annotated does help my IDE
(PyCharm) to keep me from making simple mistakes.
In the end, I figure that I don't see any real downside to the new type
hinting, if I use it, great, if not, that's fine as well. I would certainly
not be supportive of making it required in order to compile though.
--
https://mail.python.org/mailman/listinfo/python-list
