On 2015-01-23 01:15, Rick Johnson wrote:
Note: This is the closest you're going to get to a PEP from me!
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".
============================================================
Summary
============================================================
(1) Agree on a file extension that python will recognize
as containing "type hint specs". Unfortunately we cannot
use ".pth", which would be the perfect acronym for "Python
Type Hints", so choose something else. :-(
(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.
============================================================
Simplistic Example Code utilizing two files:
============================================================
#
# scriptA.py
#
def greeting(name):
return 'Hello ' + name
#
# scriptA.typehints
#
greeting{name:str} -> str
============================================================
Benefits:
============================================================
(1) Removes the noisy syntax from the source file. Python
code will remain as clean tomorrow as it is today.
(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. You can think of
it as akin to "Java @string resources".
(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.
(4) Has the added benefit of aiding when debugging type hints.
You also need to handle methods.
A simple way would be to use indentation:
# scriptA.py
class Greeter:
def __init__(self, name):
self.name = name
def greet(self):
print('Hello,', self.name)
def greeting(name):
return 'Hello ' + name
# scriptA.typehints
Greeter:
__init__(self, name: str)
greeting{name: str} -> str
I'm not sure about the best format for functions within functions. This
repeats the function name:
# scriptB.py
def greet(name):
def make_message():
return 'Hello,' + name
print(make_message())
# scriptB.typehints
greet(name: str)
greet:
make_message() -> str
But a shorter version might not be clear:
# scriptB.typehints
greet(name: str):
make_message() -> str
especially when the outer function has a hint for its return type!
--
https://mail.python.org/mailman/listinfo/python-list
