Uh, I kind of knew that. Then I rushed the email and my brain momentarily left me. Sorry... On October 5, 2015 3:23:29 PM CDT, Guido van Rossum <guido at python.org> wrote: >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) -- 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/c73f90f9/attachment-0001.html>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4