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
--
https://mail.python.org/mailman/listinfo/python-list
