[Python-Dev] Not Deprecating Arbitrary Function Annotations

Ryan Gonzalez rymg19 at gmail.com
Mon Oct 5 15:57:07 EDT 2015

There is one reason I would be really freaking mad if they deprecated other uses of annotations:


On October 5, 2015 1:55:37 PM CDT, Steve Wedig <stevewedig at 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
>is the discussion of whether or not to deprecate arbitrary function
>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.
>2. Type Experimentation
>Arbitrary function annotations allow developers to experiment with
>potential type system improvements in real projects. Ideas can be
>before officially adding them to the language. This seems like an
>that should be preserved. After all, Pep 484 says it was strongly
>by MyPy, an existing project.
>3. Embedded Languages
>Python's flexibility makes it an amazing language to embed other
>in. In this regard, Python 3's addition of arbitrary function
>and class decorators complements Python 2's dynamic typing, function
>decorators, reflection, metaclasses, properties, magic methods,
>and keyword arguments. Arbitrary function annotations are a crucial
>part of
>this toolkit, and this feature is not available in most other
>For anyone interested in the utility and mechanics of embedded
>I'd recommend Martin Fowler's book: Domain Specific Languages.
>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
>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
>for an entire directory (recursively). This would be useful for
>that have not been ported to standard annotations yet, and for
>that will not be ported for the reasons listed above.
>Thanks for your consideration.
>Python-Dev mailing list
>Python-Dev at python.org

Sent from my Nexus 5 with K-9 Mail. Please excuse my brevity.

More information about the Python-Dev mailing list