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 <rym...@gmail.com> wrote: > PSF. Nothing personal, of course... > > > On October 5, 2015 3:01:11 PM CDT, Guido van Rossum <gu...@python.org> > wrote: >> >> "They"? >> >> On Mon, Oct 5, 2015 at 12:57 PM, Ryan Gonzalez <rym...@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 <stevewe...@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@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@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)
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
