(original) (raw)
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 <rymg19@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 <stevewedig@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