Python Sanity Proposal: Type Hinting Solution

Rick Johnson rantingrickjohnson at gmail.com
Sat Jan 24 17:41:55 CET 2015


On Saturday, January 24, 2015 at 7:30:02 AM UTC-6, Steven D'Aprano wrote:
> [...] 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):
> 
> 
> and be annoyed or perplexed by the syntax error.
> 
> Some syntax will be a bug magnet. This is one.

Your argument is weak here. If the interpreter cannot
distinguish between "@typehint ..." and "@ ..." then those
who defined the logic need to go back to CS-101. Secondly,
why set *ANY* rules as to the order of typehints -vs-
decorators? Who cares about the "syntactical order", when
they can be parsed and then applied in *ANY* order.
Syntactical order need not *ALWAYS* be significant. In fact,
in this case, syntactic ordering rules are superfluously 
onerous on the human.

And that is how you kill two birds with one stone.





More information about the Python-list mailing list