Python Sanity Proposal: Type Hinting Solution

[Rick Johnson]

On Friday, January 23, 2015 at 4:42:51 PM UTC-6, Mario Figueiredo wrote:
> I'd rather it'd be a docstring parameter.
>
> - Decorators are transformation tools. Which type hints
> are not.

Valid point.

> - keywords should be few and used only for language
> features. Static analysis isn't and should never be a
> language feature. It's an extension, perhaps.

Indeed. I've always been fond of Python's relatively small
set of keywords, and avoiding additions is a noble goal. It
seems like we've entered an era of increasing feature creep.

> - Same with built-in functions... although a case could be
> made for a static analysis package, hmmm.
>
> So I'd rather see:
>
>      def myfunction(arg1, arg2):
>      """
>      Normal docstring.
>      """
>      "@typehint: (str, int) -> bool"
>          return True
>

I think extending the doc-string syntax is good idea since
there is nothing going on in there anyway. It's sort of like
a treasure just waiting to be plundered. Plus, I find i can
easily ignore doc-strings, whereas, adding a new syntax is
going to be a syntactical distraction no matter how "clean"
it may be. Heck, even after years of reading Python source,
function decorators still jump out at me like lions from
behind a bush!

And although i think one could make a good argument that
decorators *ought-to-be* obvious because of the resulting
unavoidable implications of them, i don't believe the same
argument applies to a feature which simply serves as an
"optional hook" for static analysis tools -- for which the
implications are entirely dependent on purposeful actions by
a programmer -- any other time it's just dead code.

> Alternatively, because dangling strings are always
> considered documentation and completely ignored by the
> interpreter (PEP 258), one could also do:
>
>      "@typehint: (str, int) -> bool"
>      def myfunction(arg1, arg2):
>      """
>      Normal docstring.
>      """
>          return True
>

Ha, well one of the more wonderful aspects of being an
"opposer" (as opposed to a "proposer") is that you can omit
yourself from the headaches of the implementation details
O:-). I say: they wanted type hints, fine, let them suffer
the headaches of hacking the interpreter.

My only goal (at this point) is ensuring that their little
intellectual "problem child" does not walk on my wonderfully
lush and finely manicured lawn.

    KEEP OFF MY GRASS!!!