Path: csiph.com!usenet.pasdenom.info!goblin3!goblin2!goblin.stu.neva.ru!newsfeed.xs4all.nl!newsfeed1a.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
Date: Fri, 23 Jan 2015 03:22:14 +0000
From: MRAB <python@mrabarnett.plus.com>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: python-list@python.org
Subject: Re: Python Sanity Proposal: Type Hinting Solution
References: <6da1eb58-a0bb-4d37-8293-0a8cafe6a89c@googlegroups.com>
In-Reply-To: <6da1eb58-a0bb-4d37-8293-0a8cafe6a89c@googlegroups.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.18011.1421983338.18130.python-list@python.org>
Lines: 110
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:84303

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!