[Python-ideas] Proposal: Use mypy syntax for function annotations

[Gregory P. Smith]

On Thu, Aug 14, 2014 at 9:01 AM, Brett Cannon <brett at python.org> wrote:

>
> On Thu Aug 14 2014 at 10:53:37 AM Petr Viktorin <encukou at gmail.com> wrote:
>
>> It seems to me that rather than adding a module which is only used by
>> one project so far to the standard library is a bit premature.
>>
>> I support optional typing, but why push this to stdlib now? Wouldn't
>> it be better to wait until most IDEs/linters all agree on this syntax,
>> until freezing it in stdlib? So far typing seems to be a part of mypy,
>> shouldn't it spend some time on PyPI first?
>>
>
> Because as you have noticed in this thread there are already a ton of
> competing solutions and no consensus has been reached. Sometimes Guido
> and/or python-dev have to step in and simply say "there is obvious need and
> the community is not reaching consensus, so we will make the decision
> ourselves".
>

My overarching concern with the entire proposal is that adding this would
just be yet more syntax added to the language with not much use that
doesn't go far enough.

We'd ultimately need pytd or something else regardless when it comes to
full scale Python static analysis.

But that *isn't necessarily* a bad thing. Specifying an actual basic
annotation syntax that can do some subset of what you want to annotate in
the language should in theory still be useful to a real code analysis tool.
If it isn't, it will simply ignore it. If it is, it can use it and build on
it even though it needs the ability to specify on the side.

If you do add a module for this, at least consider hiding it behind a "from
__future__ import some_module_full_of_annotation_related_things" instead of
making it a new no-op top level module.

-gps


>
>
>>
>> I'm also sure about there not being other uses of annotations -- clize
>> aside, there are not many widely used Python3-only 3rd party
>> libraries, so it's no surprise that nothing big is built around Python
>> 3 features.
>>
>> Maybe the way from PEP 3107's "here's a feature, use it for whatever
>> you like" to "annotations are for typing declarations, using
>> mypy/typing syntax" should include a step of "if you use annotations
>> for typing, use mypy/typing syntax for it". (And perhaps it should end
>> there.)
>>
>
> That's a possibility. Another thing to support this approach is that if
> something like List[str] is used over `[str]`  then the returned object can
> subclass some common superclass which can be typechecked for to know that
> the annotation is from typing.py and not clize/scription and continue to
> function. That way you can avoid any decorators adding some attribute on
> functions to know that types have been specified while allowing function
> annotations to be used for anything. Otherwise a @typing.ignore decorator
> could also exist for alternative formats to use (since typing has been the
> most common use case and decorating your single main() function with
> @typing.ignore is not exactly heavy-handed).
>
> _______________________________________________
> 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/20140814/6b8d471e/attachment.html>