Python Sanity Proposal: Type Hinting Solution
Rick Johnson
rantingrickjohnson at gmail.com
Sat Jan 24 11:41:55 EST 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