Python Sanity Proposal: Type Hinting Solution

[Mario Figueiredo]

In article <54c39e48$0$12996$c3e8da3$5496439d at news.astraweb.com>, 
steve+comp.lang.python at pearwood.info says...
> 
> I'm not sure if you're making a general observation or one which is
> specific
> to Python. Plenty of languages have static analysis as a language feature.
> Are you arguing they are wrong to do so?
> 

No. I'm arguing static analysis should not consume a programming 
language keyword space. Static analysis is just a development tool.

> 
> def myfunction(arg1, arg2):
>     """
>     Normal docstring.
>     @typehint: (str, int) -> bool"""
>     return True
> 
> One of the problems with this is that it put the information about
> parameters far away from the parameter list itself.

Then move it to the first line of the docstring...


> > I removed the arguments names on purpose. They are only necessary on 
> > the
> > PEP because type hinting is a part of the function header there.
> > However, when using a documentation like pattern as above (or as in your
> > own example), they can be safely removed, with the added benefit of
> > making the syntax simpler.
> 
> Only at the cost of making it hard to read.

If you want the redundancy and a potential source of new bugs by having 
a type hint in a docstring include argument names... You see, there's 
always a downside to everything.

Meanwhile, object names have nothing to do with type analsys, which 
makes arguments names rather irrelevant in the context of static 
analysis. I'd rather promote types than names. Remove names and you 
will.

> > 
> >      "@typehint: (str, int) -> bool"
> >      def myfunction(arg1, arg2):
> 
> That's somewhat better, in that at least the hint is close to the function
> signature. But it has a lot of disadvantages: it is compile-time only, the
> type hints aren't available at runtime.

It's static analysis. You don't need runtime execution.

> It requires extra complexity to the
> parser, so that decorators may be separated from the function by a hint:
> 
> @decorate
> "@typehint: (str, int) -> bool"
> def myfunction(arg1, arg2):
> 
> No doubt some people will get them the wrong way around, and the type
> checker may silently ignore their hints:
> 
> "@typehint: (str, int) -> bool"
> @decorate
> def myfunction(arg1, arg2):
> 
> And others will write:
> 
> @decorate
> @typehint(str, int) -> bool
> def myfunction(arg1, arg2):
> 

That seems like you are fishing. What is exactly your point? That people 
will not be able to understand the rules of type hinting? And that 
somehow is going to be an universal problem?

> Some syntax will be a bug magnet. This is one.

You think?