[Python-Dev] Type hints -- a mediocre programmer's reaction

Wolfgang Langner tds333+pydev at gmail.com
Thu Apr 23 10:43:52 CEST 2015


Hi,

having a lot experience with Python beginners and people programming
Java/Python I have also an opinion about this. ;-)

First reaction was, oh good. Then I read every thread and comment about it,
looked at a lot internal code give all some time
and the result is:

I found a lot of code written like Java with assert and isinstance for type
checks. Not very Pythonic but someone from Java thinks this is good.
Because Python has no type checks. A lot of people think types help in the
IDE and for tools to do automatic checks, find some errors earlier.

My conclusion:

1. typing.py is good to make a standard how to specify type hints. Can also
be used by tools and IDE's

2. Using it in the language as part of the function signature, my first
thought was oh good, then I changed my mind
   to: oh it can be very ugly and unreadable, it is the wrong place.
   Now I am against it, best is, if I have to specify type signatures, do
it in one place, keep them up to date.
   Most of the time this is the documentation. Why not use the docstring
with a standard type specifier for this.
   Suggested here:
http://pydev.blogspot.de/2015/04/type-hinting-on-python.html

3. Stub files are good if someone needs this feature, it is complete
separate and if someone don't want to write them
    it is no problem. But it is good to have a way to name them and a place
to find them and know this.

IDE's parse the docstring already, it is optional to have one and every
Editor has folding support to disable it if it is to much
of information. Checkers like mypy can use the type info from there to do
checks. If there is a standard way to specify types in docstrings.
It is also possible to specify a type hint for a variable, this is good for
documentations and can also be used for type checks.

For stub files the same can be used. So no different syntax. Also If
someone wants it and a module has no documentation it can be added from
there.

For nearly every function I have written, there is a docstring and most of
the time also a type specified.
But if I must provide all this in a second place it is not the right way to
go. Over time normally one place misses some changes and is wrong.

I am convinced something like:

def myfunction(a, b):
  """
  My special function.

  :param a: ...
  :type a: int
  :param b: second value
  :type b: int
  :rtype: None
  """

or shorter form also possible in Sphinx if only one type for parameter is
specified:

def myfunction(a, b):
  """
  My special function.

  :param int a: ...
  :param int b: second value
  :rtype: None
  """

Is easier to maintain good to read, changes not the world how to write
Python functions and is useful for IDE's and checkers.
And the best, most editors and IDE's support folding of docstrings and if
someone don't want to see them it can be done now.
The docstring is a good place for type specification, because as stated
Python never will do type checks on execution. So no need
to make it part of the language syntax.

All this can also be applied over time to the standard library. If it makes
sense so specify a type it is good to have it in the documentation.
And sphinx is the standard documentation tool for Python now.

Also ask why no one used type specifier, they are possible since Python 3.0
?
Because it is the wrong way for Python.


Regards,

Wolfgang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150423/23aa14b7/attachment.html>


More information about the Python-Dev mailing list