Python Sanity Proposal: Type Hinting Solution

[MRAB]

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!