On Friday, January 23, 2015 at 6:45:39 AM UTC+5:30, 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
>
1. Allow in same file
2. Chage syntax slightly to
type greeting : str -> str
[type is the keyword equivalent to your other typehint file ]
and you have essentially the Haskell solution.
The catch I expect is that haskell is strongly committed to simultaneous
definitions:
x = 1
y = x+2
is the same as
y = x+2
x = 1
and so definitions can generally be permuted around
Python is committed to the opposite extreme:
even def and class are not declarative but imperative
--
https://mail.python.org/mailman/listinfo/python-list
