[Python-Dev] Comments on PEP 563 (Postponed Evaluation of Annotations)

[Guido van Rossum]

OK, this is fine. It won't affect mypy (which will continue to treat string
literals the same as before) but it will require an update to typing.py --
hope you are working on that with Ivan.

On Mon, Nov 20, 2017 at 9:58 AM, Lukasz Langa <lukasz at langa.pl> wrote:

> I agree with you. The special handling of outermost strings vs. strings
> embedded inside annotations bugged me a lot. Now you convinced me that this
> functionality should be moved to `get_type_hints()` and the __future__
> import shouldn't try to special-case this one instance, while leaving
> others as is.
>
> I will be amending the PEP accordingly.
>
> - Ł
>
> > On Nov 19, 2017, at 10:56 AM, Mark Shannon <mark at hotpy.org> wrote:
> >
> > Hi,
> >
> > Overall I am strongly in favour of this PEP. It pretty much cures all
> the ongoing pain of using PEP 3017 annotations for type hints.
> >
> > There is one thing I don't like however, and that is treating strings as
> if the quotes weren't there.
> > While this seems like a superficial simplification to make transition
> easier, it introduces inconsistency and will ultimately make both
> implementing and using type hints harder.
> >
> > Having the treatment of strings depend on their depth in the AST seems
> confusing and unnecessary:
> > "List[int]" becomes 'List[int]' # quotes removed
> > but
> > List["int"] becomes 'List["int"]' # quoted retained
> >
> > Also,
> >
> > T = "My unparseable annotation"
> > def f()->T: pass
> >
> > would remain legal, but
> >
> > def f()->"My unparseable annotation"
> >
> > would become illegal.
> >
> > The change in behaviour between the above two code snippets is already
> confusing enough without making one of them a SyntaxError.
> >
> > Using annotations for purposes other than type hinting is legal and has
> been for quite a while.
> > Also, PEP 484 type-hints are not the only type system in the Python
> ecosystem. Cython has a long history of using static type hints.
> >
> > For tools other than MyPy, the inconsistent quoting is onerous and will
> require double-quoting to prevent a parse error.
> > For example
> >
> > def foo()->"unsigned int": ...
> >
> > will become illegal and require the cumbersome
> >
> > def foo()->'"unsigned int"': ...
> >
> > Cheers,
> > Mark.
> >
> > _______________________________________________
> > Python-Dev mailing list
> > Python-Dev at python.org
> > https://mail.python.org/mailman/listinfo/python-dev
> > Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> lukasz%40langa.pl
>
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> guido%40python.org
>
>


-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20171120/70ccf4f1/attachment.html>