[Python-Dev] Not Deprecating Arbitrary Function Annotations

[Ryan Gonzalez]

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 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
>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 at 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.