[Python-ideas] PEP 484 (Type Hints) -- first draft round

[Yann Kaiser]

On Sun Jan 18 2015 at 3:16:47 PM Chris Angelico <rosuav at gmail.com> wrote:

> On Mon, Jan 19, 2015 at 12:37 AM, Cem Karan <cfkaran2 at gmail.com> wrote:
> > There may be other uses of annotations that programmers haven't yet
> thought of, simply because they don't know that annotations exist.  Locking
> out those uses would suck.
>
> I see a lot of vague "but what if there's something else", and not a
> lot of concrete "here's a use of annotations that would be locked
> out". Does anyone actually have another use case that would be
> seriously harmed by this kind of conflict?


I use annotations in clize, a CLI argument parser, to specify how functions
parameters should translate to CLI parameters. This can range from
specifying coercion functions/callables for the argument values(ie. int),
which could easily be mixed up with typing information as specified here,
to specifying aliases for named parameters, marking parameters as
undocumented, or simply overriding the translation process altogether for
that parameter.

Now I could simply instruct users to never use annotations and always use a
decorator instead (in fact, I recommend it when Python 2.x compatibility is
wished) and have that decorator dump this information elsewhere than in
f.__annotations__, but that begs the question of why it isn't as worthy of
benefiting from annotation syntax[1] as type-checking. If anything, this is
a use of annotations at run-time versus a use at dev-time in an offline
fashion.

I also find it a bit hasty to proclaim no one has found other viable uses
for annotations when Python 3 adoption and thus liberty to use annotations
still remains poor.


> Remember, you can simply
> not use type hints for the function(s) that use other annotations; the
> conflict is only if you're trying to use both on the same function.
>

If typing is to become the default interpretation of annotations, I fear
that this will really just turn into "WTF, your annotations aren't type
info, fix it", especially given the recursive nature of those checks.

Why can't it be explicit that a function's annotations are type info that
should be checked? "typing.check(func)", "@typing.check   def func(...):",
"import typing; typing.check_all()", "import typing" not followed by
"typing.nevermind()", anything?



[1] I guess I could write a decorator that moves annotations out of
__annotations__ into another dict, but I'm not sure that would be relevant
at all to a *static* analyzer which wouldn't have to care what dict things
end up in. Again, illustrates the weirdness of having this run-time feature
be reserved for static analysis.



> ChrisA
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150118/a02ae7fe/attachment.html>