Re: [Python-Dev] 3.4.4rc1, when?
On 10/4/2015 11:44 PM, Larry Hastings wrote: On 10/04/2015 06:26 PM, Terry Reedy wrote: When might 3.5.1 candidate be? No announcements yet! May I assume that you will give at least two weeks notice and that 3.5.1c1 will be at least 3 or 4 weeks off? -- Terry Jan Reedy ___ 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
[Python-Dev] Not Deprecating Arbitrary Function Annotations
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/archive%40mail-archive.com
Re: [Python-Dev] 3.4.4rc1, when?
On 10/05/2015 11:42 AM, Terry Reedy wrote: On 10/4/2015 11:44 PM, Larry Hastings wrote: On 10/04/2015 06:26 PM, Terry Reedy wrote: When might 3.5.1 candidate be? No announcements yet! May I assume that you will give at least two weeks notice and that 3.5.1c1 will be at least 3 or 4 weeks off? Yes. To be specific: I'd want to give at least two weeks notice before 3.5.1rc1, and 3.5.1 final would be at least a week after that (though perhaps no more than that). Cheers, //arry/ ___ 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
Re: [Python-Dev] Not Deprecating Arbitrary Function Annotations
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 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/archive%40mail-archive.com
Re: [Python-Dev] Not Deprecating Arbitrary Function Annotations
"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 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 > -- --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
Re: [Python-Dev] Not Deprecating Arbitrary Function Annotations
Function annotations for uses other than types are not deprecated, just discouraged if they don't have an appropriate decorator: https://docs.python.org/3/library/typing.html#typing.no_type_check . There is even a decorator for decorators since most uses previous to type hints utilized some form of a decorator: https://docs.python.org/3/library/typing.html#typing.no_type_check_decorator . And as a last resort you simply don't use your Python code with anything that assumes type hints. On Mon, 5 Oct 2015 at 12:57 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 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/brett%40python.org > ___ 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
Re: [Python-Dev] Not Deprecating Arbitrary Function Annotations
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 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 >> > > > >-- >--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
Re: [Python-Dev] Not Deprecating Arbitrary Function Annotations
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 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/ma
Re: [Python-Dev] Not Deprecating Arbitrary Function Annotations
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 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 t
Re: [Python-Dev] Not Deprecating Arbitrary Function Annotations
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 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 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 >>> >>> >>>
Re: [Python-Dev] Not Deprecating Arbitrary Function Annotations
Not really being affected by the "python annotation movement", I supply some non-constructive comment: I would not prefer any of these outcomes but would always allow all possible meanings that people wish to encode in the annotations. My $0.02 and I am out. On 05.10.2015 22:46, Steve Wedig wrote: 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 :) ___ 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
Re: [Python-Dev] Not Deprecating Arbitrary Function Annotations
On Mon, 5 Oct 2015 at 13:55 Steve Wedig wrote: > 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 :) > Fair enough, but since Python 3.5 is so new we have yet to gather any feedback on the entire concept of type hints, let alone whether their use is so broad and liked that we will consider dropping the decorators in `typing` which mark alternative uses and define "function annotations" as "type annotations" for everything. So consider your view noted, but realize that the discussion of the uptake of type hints has not started yet as it's premature to do so. If you want to make sure to participate if/when the discussion of dropping support for alternative uses of function annocations then consider staying subscribed to python-dev to notice when that happens (but I suspect it will be a while). -Brett > > > > > 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 > >in
