On Thursday, January 22, 2015 at 4:25:37 PM UTC-6, Mario Figueiredo wrote:
> 1. Annotations where created exactly for this purpose. So
> there's some preassure to put them to work on what they
> were always meant to be used for.
>
> 2. Docstrings are meant as source of code documentation
> and to fill the object's __doc__ attribute, as per PEP
> 257. As such they aren't good consistent candidates for
> type hinting for purposes of static analysis tools.
>
> 3. Decorators are meant as function transformation tools,
> as per PEP 318 and, as such, are them too not suitable to
> include type annotations for the purpose of static
> analysis.
>
> 4. There is no other formal annotation mechanism, other
> than these potential three.
>
> Arguably, you can make a case against 1. And that's my own
> issue with type hinting as it is being proposed on PEP
> 484. The real problem is annotations as they were defined
> are a really bad idea. To couple type annotations so
> tightly with code, just results in plain ugly and hard to
> read code.
Yes, i whole heartily agree!
> Personally I would love to see the present annotations
> just go away and a new docstring-like structure to emerge
> in their place. But that's probably not going to happen.
>
> What I agree can't be done though, is to use docstrings or
> decorators as a source for type annotations.
I have a completely different idea.
============================================================
Python Sanity Proposal: "Type Hinting Sanity"
============================================================
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.
--
My suggestion is the only way to implement type hints
without destroying Python! I just hope that GvR will give it
serious objective consideration.
--
https://mail.python.org/mailman/listinfo/python-list
