Brett and Alexander,
I am concerned about deprecation of arbitrary function annotations because
Pep 484 suggests that two paths are under consideration. Here is the
relevant section:
"
We do hope that type hints will eventually become the sole use for
annotations, but this will require additional discussion and a deprecation
period after the initial roll-out of the typing module with Python 3.5. The
current PEP will have provisional status (see PEP 411 ) until Python 3.6 is
released. The fastest conceivable scheme would introduce silent deprecation
of non-type-hint annotations in 3.6, full deprecation in 3.7, and declare
type hints as the only allowed use of annotations in Python 3.8. This
should give authors of packages that use annotations plenty of time to
devise another approach, even if type hints become an overnight success.
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. For this purpose the current proposal defines a
decorator @no_type_check which disables the default interpretation of
annotations as type hints in a given class or function. It also defines a
meta-decorator @no_type_check_decorator which can be used to decorate a
decorator (!), causing annotations in any function or class decorated with
the latter to be ignored by the type checker.
"
I am advocating against paragraph 1 (a deprecation path) and for the course
of action stated in paragraph 2 :)
On Mon, Oct 5, 2015 at 1:23 PM, Guido van Rossum 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 wrote:
>
>> PSF. Nothing personal, of course...
>>
>>
>> On October 5, 2015 3:01:11 PM CDT, Guido van Rossum
>> wrote:
>>>
>>> "They"?
>>>
>>> On Mon, Oct 5, 2015 at 12:57 PM, Ryan Gonzalez 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
>>>> 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 Language
