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 <luk...@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 <m...@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@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@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)
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
