Function annotations for uses other than types are not deprecated, just discouraged if they don't have an appropriate decorator: https://docs.python.org/3/library/typing.html#typing.no_type_check . There is even a decorator for decorators since most uses previous to type hints utilized some form of a decorator: https://docs.python.org/3/library/typing.html#typing.no_type_check_decorator . And as a last resort you simply don't use your Python code with anything that assumes type hints.
On Mon, 5 Oct 2015 at 12:57 Ryan Gonzalez <rym...@gmail.com> wrote: > There is one reason I would be really freaking mad if they deprecated > other uses of annotations: > > https://pypi.python.org/pypi/plac > > On October 5, 2015 1:55:37 PM CDT, Steve Wedig <stevewe...@gmail.com> > wrote: > >Congratulations on the release of 3.5 and Pep 484. I've used Python > >professionally for 10 years and I believe type hints will make it > >easier to > >work with large codebases evolving over time. My only concern about Pep > >484 > >is the discussion of whether or not to deprecate arbitrary function > >annotations. > >https://www.python.org/dev/peps/pep-0484/ > > > >I would like to request that arbitrary function annotations are not > >deprecated for three reasons: > >1. Backwards Compatibility > >2. Type Experimentation > >3. Embedded Languages > > > >1. Backwards Compatibility > >After reading Pep 3107 my team has made significant use of non-standard > >annotations. It would be a serious burden to be forced to port our > >annotations back to decorators. This would also make our codebase > >considerably less readable because function annotations are much more > >readable than input/output annotations relegated to decorators. > >https://www.python.org/dev/peps/pep-3107/ > > > >2. Type Experimentation > >Arbitrary function annotations allow developers to experiment with > >potential type system improvements in real projects. Ideas can be > >validated > >before officially adding them to the language. This seems like an > >advantage > >that should be preserved. After all, Pep 484 says it was strongly > >inspired > >by MyPy, an existing project. > >http://mypy-lang.org/ > > > >3. Embedded Languages > >Python's flexibility makes it an amazing language to embed other > >languages > >in. In this regard, Python 3's addition of arbitrary function > >annotations > >and class decorators complements Python 2's dynamic typing, function > >decorators, reflection, metaclasses, properties, magic methods, > >generators, > >and keyword arguments. Arbitrary function annotations are a crucial > >part of > >this toolkit, and this feature is not available in most other > >languages. > >For anyone interested in the utility and mechanics of embedded > >languages, > >I'd recommend Martin Fowler's book: Domain Specific Languages. > > > http://www.amazon.com/Domain-Specific-Languages-Addison-Wesley-Signature-Series/dp/0321712943 > > > >So I agree with the course of action mentioned in Pep 484 that avoids > >runtime deprecation of arbitrary function annotation: "Another possible > >outcome would be that type hints will eventually become the default > >meaning > >for annotations, but that there will always remain an option to disable > >them." I would only add that there should be a way to disable type > >checking > >for an entire directory (recursively). This would be useful for > >codebases > >that have not been ported to standard annotations yet, and for > >codebases > >that will not be ported for the reasons listed above. > > > >Thanks for your consideration. > > > >Best, > >Steve > > > > > >------------------------------------------------------------------------ > > > >_______________________________________________ > >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/rymg19%40gmail.com > > -- > Sent from my Nexus 5 with K-9 Mail. Please excuse my brevity. > _______________________________________________ > 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/brett%40python.org >
_______________________________________________ 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