[Python-Dev] Not Deprecating Arbitrary Function Annotations

[Guido van Rossum]

"They"?

On Mon, Oct 5, 2015 at 12:57 PM, Ryan Gonzalez <rymg19 at 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 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.
> _______________________________________________
> 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/guido%40python.org
>



-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20151005/495a95c9/attachment.html>