Python Sanity Proposal: Type Hinting Solution

Terry Reedy tjreedy at udel.edu
Thu Jan 22 22:22:15 EST 2015


On 1/22/2015 8:15 PM, Rick Johnson wrote:

> Okay, i have found a solution to the type hinting problem
> that will appease both sides. On one side we have those who
> are proposing type hinting annotations within function sigs,
> and on the other side, we have those who oppose the
> implementation of type hinting via this method because of
> the readability concerns. The solution is move the type
> hinting syntax completely out of the source file and into
> another file -- think of it as a "Python Type Hinting Header
> File".

This idea is so brilliant that it is already an option in mypy and is 
part of the new type-hint proposal.  The separate type-hint files are 
called 'stub files'.  I don't know what the extension is.  These will be 
used for the stdlib, which will not have annotations in the .py files

> (2) Define a spec for writing annotations that will map to
> funcs/methods of the same name. I would argue to keep the
> spec compact, but i really don't care about the spec at
> this point.

It will use the one  proposed, with whatever modification still to come.
I believe stub files can also be used for functions defined in C.

>   Simplistic Example Code utilizing two files:

>    # scriptA.py
>    def greeting(name):
>        return 'Hello ' + name

>    # scriptA.typehints
>    greeting{name:str} -> str

I believe stub files can also be used for functions defined in C.


>   Benefits:

> (1) Removes the noisy syntax from the source file. Python
> code will remain as clean tomorrow as it is today.

This will at least be an option.  You are and will be free to advocate 
that people always use stub files.

> (2) Puts the onerous on the author *NOT* on the reader.
> This system utilizes a concept known as "Level Of Detail"
> (or LOD). LOD means that i should not need to see a type
> hint unless i *WANT* to see a type hint.

One thing not discussed here (but was in the earlier python-ideas thread 
some months ago) is that some groups have standards for using some 
functions that is stricter than the function's full duck-typing 
generality.  A stub file allows a group to specify a restrictive use 
annotation for their static checker without putting lies into the code 
or doc of the function itself.

> (3) If i decide i don't want type hints in my code, all i
> have to do is delete or rename a file, which is much less
> error prone then editing source code.

If the annotations are in a separate file, deleting will hardly be 
necessary since the file will be ignored until one runs software that 
uses it.

> (4) Has the added benefit of aiding when debugging type hints.

I am not sure what you mean here.   It will be easier to temporarily 
comment out an incorrect annotation for a function, pending correction, 
when in a separate file.


-- 
Terry Jan Reedy




More information about the Python-list mailing list