[Python-Dev] Type hints -- a mediocre programmer's reaction (original) (raw)

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