[Python-ideas] Optional static typing -- the crossroads

[Yann Kaiser]

On 15 August 2014 23:18, Terry Reedy <tjreedy at udel.edu> wrote:
>
>
> I claim that the mere presence of a decorator in the *source* is not
> enough. The decorator for non-type markers should do something with
> .__annotations__ -- in particular, remove the non-type markers.  The
> presence of a decorator in the source does not necessarily leave a trace on
> the returned function object for runtime detection.
>
>
The way I understand it, mypy, which is what Guido's proposal sees its main
potential user, operates at a stage similar to compilation in CPython. At
which point anything after the colon in a parameter would be in its
equivalent of __annotation__, regardless of what decorators add or remove.
How would your other-annotation-removing decorator help mypy at all? By
having it examine the decorator source and infer what kind of operation the
decorator does? That doesn't sound very compile-stagey at all.



>
> To me, inspect.signature already assumes that annotations are about type,
> which means that this horse has already left barn. In 3.4.1:
>
> >>> from inspect import signature as sig
> >>> str(sig(nsqrt))
> "(n:(<class 'int'>, 'random non-type info')) -> (<class 'int'>, 'more
> non-type info')"
>
>
`inspect.signature` makes no such assumption, it only relays what it found
on the function's __annotation__ attribute. I don't know where this nsqrt
function comes from, but it is responsible for having set up those
annotations, which seem to be mere documentation if the "random non-type
info" is a string.


> "the rule could be to ignore string annotations. Decorators can always
> eval, or perhaps safe_eval, strings."
>
> In other words, if type annotations were to be classes, as proposed, then
> non-type annotations should not be classes, so that pre-compile annotation
> consumers could easily ignore them. In particular, I suggested literal
> strings, which are easily recognized in source, as well as in asts.
>
>
"Oh, everything that's not type-checking can be expressed in a string,
maybe to be eval'ed, say, with sys,_getframe(-1) locals."

No, and that's incredibly ugly and may not work on alternate
implementations of Python.

If a PEP is made to standardize typing attributes for annotations, perhaps
in the form of a typing type hierarchy or a type decorator(ie.
typing.Like(AClass)), or annotation namespacing of some sort(decorate the
function with "hey! please typecheck me!"?), then couldn't tools that rely
on those attributes pick out what's relevant to them on their own, thanks
to the standardization?

I find the whole idea of having so far equal uses of function annotations
be bullied aside for the good of a concept yet foreign to Python very
arrogant and unnecessary.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20140816/9e17bac2/attachment-0001.html>