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

Guido van Rossum guido at python.org
Mon Oct 5 16:23:29 EDT 2015

Maybe I should clarify how the process of changing the language works.

The PSF doesn't enter into it -- they manage the infrastructure (e.g. mailing lists, Hg repo, tracker, python.org) but they don't have anything to do with deciding how or when the language changes.

Language changes are done here by us all. Anyone can write a PEP and it will be discussed here (but first in python-ideas of course).

I'm sorry you don't feel more included, but I really don't like the idea of "us vs. them" in this list. We're all working together to make Python the best language it can be.

--Guido

On Mon, Oct 5, 2015 at 1:18 PM, Ryan Gonzalez <rymg19 at gmail.com> wrote:

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

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

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

More information about the Python-Dev mailing list