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 <gu...@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 <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)
--
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/archive%40mail-archive.com
