[Python-Dev] Not Deprecating Arbitrary Function Annotations

[Guido van Rossum]

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>