[Python-Dev] Not Deprecating Arbitrary Function Annotations (original) (raw)

Ryan Gonzalez rymg19 at gmail.com
Mon Oct 5 16🔞36 EDT 2015

PSF. Nothing personal, of course...

On October 5, 2015 3:01:11 PM CDT, Guido van Rossum <guido at python.org> wrote:

"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)

-- Sent from my Nexus 5 with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20151005/01e0eb7e/attachment-0001.html>

More information about the Python-Dev mailing list