PEP 526 (variable annotations) accepted provisionally

I'm accepting PEP 526 provisionally. I am personally confident that this PEP is adding a useful new feature to the language: annotations that can be used by a wide variety of tools, whether off-line type checkers or frameworks that add runtime checking (e.g. traits or traitlets). The provisional status reflects the understanding that minor details of the proposed syntax and its runtime effects may still have to change based on experience during the 3.6 life cycle. (For example, maybe we end up not liking ClassVar, or maybe we'll decide we'll want to support `x, y, z: T` after all.) There's been some quite contentious discussion about the PEP, on and off python-dev, regarding how the mere presence of annotation syntax in the language will change the way people will see the language. My own experience using mypy and PyCharm has been quite different: annotations are a valuable addition for large code bases, and it's worth the effort to add them to large legacy code bases (think millions of lines of Python 2.7 code that needs to move to Python 3 by 2020). The effect of this has been that engineers using Python are happier and more confident that their code works than before, have an easier time spelunking code they don't know, and are less afraid of big refactorings (where conversion to Python 3 can be seen as the ultimate refactoring). I should blog about our experience at Dropbox; I hope the Zulip open source folks (not at Dropbox) will also blog about their experience. In the meantime you can read Daniel F. Moisset's three-part blog about adding annotations to pycodestyle (formerly pep8) here: http://www.machinalis.com/blog/a-day-with-mypy-part-1/ If you want to see a large open source code base that's annotated for mypy (with 97% coverage), I recommend looking at Zulip: https://github.com/zulip/zulip Finally, some of us are starting a new (informational) PEP to set expectations for how type checkers should make use of the annotation syntax standardized by PEP 484 and PEP 526. This is going to take more time, and new collaborators are welcome here: https://github.com/ilevkivskyi/peps/blob/new-pep/pep-0555.txt. (Mark, I really hope you'll accept the invitation to participate. Your experience would be most welcome.) -- --Guido van Rossum (python.org/~guido)

Thank you Guido! :-) -- Ivan On 7 September 2016 at 20:18, Guido van Rossum <guido@python.org> wrote:
I'm accepting PEP 526 provisionally.
I am personally confident that this PEP is adding a useful new feature to the language: annotations that can be used by a wide variety of tools, whether off-line type checkers or frameworks that add runtime checking (e.g. traits or traitlets).
The provisional status reflects the understanding that minor details of the proposed syntax and its runtime effects may still have to change based on experience during the 3.6 life cycle. (For example, maybe we end up not liking ClassVar, or maybe we'll decide we'll want to support `x, y, z: T` after all.)
There's been some quite contentious discussion about the PEP, on and off python-dev, regarding how the mere presence of annotation syntax in the language will change the way people will see the language. My own experience using mypy and PyCharm has been quite different: annotations are a valuable addition for large code bases, and it's worth the effort to add them to large legacy code bases (think millions of lines of Python 2.7 code that needs to move to Python 3 by 2020). The effect of this has been that engineers using Python are happier and more confident that their code works than before, have an easier time spelunking code they don't know, and are less afraid of big refactorings (where conversion to Python 3 can be seen as the ultimate refactoring).
I should blog about our experience at Dropbox; I hope the Zulip open source folks (not at Dropbox) will also blog about their experience. In the meantime you can read Daniel F. Moisset's three-part blog about adding annotations to pycodestyle (formerly pep8) here:
http://www.machinalis.com/blog/a-day-with-mypy-part-1/
If you want to see a large open source code base that's annotated for mypy (with 97% coverage), I recommend looking at Zulip: https://github.com/zulip/zulip
Finally, some of us are starting a new (informational) PEP to set expectations for how type checkers should make use of the annotation syntax standardized by PEP 484 and PEP 526. This is going to take more time, and new collaborators are welcome here: https://github.com/ilevkivskyi/peps/blob/new-pep/pep-0555.txt. (Mark, I really hope you'll accept the invitation to participate. Your experience would be most welcome.)
-- --Guido van Rossum (python.org/~guido)

:D -- Ryan [ERROR]: Your autotools build scripts are 200 lines longer than your program. Something’s wrong. http://kirbyfan64.github.io/ On Sep 7, 2016 1:20 PM, "Guido van Rossum" <guido@python.org> wrote:
I'm accepting PEP 526 provisionally.
I am personally confident that this PEP is adding a useful new feature to the language: annotations that can be used by a wide variety of tools, whether off-line type checkers or frameworks that add runtime checking (e.g. traits or traitlets).
The provisional status reflects the understanding that minor details of the proposed syntax and its runtime effects may still have to change based on experience during the 3.6 life cycle. (For example, maybe we end up not liking ClassVar, or maybe we'll decide we'll want to support `x, y, z: T` after all.)
There's been some quite contentious discussion about the PEP, on and off python-dev, regarding how the mere presence of annotation syntax in the language will change the way people will see the language. My own experience using mypy and PyCharm has been quite different: annotations are a valuable addition for large code bases, and it's worth the effort to add them to large legacy code bases (think millions of lines of Python 2.7 code that needs to move to Python 3 by 2020). The effect of this has been that engineers using Python are happier and more confident that their code works than before, have an easier time spelunking code they don't know, and are less afraid of big refactorings (where conversion to Python 3 can be seen as the ultimate refactoring).
I should blog about our experience at Dropbox; I hope the Zulip open source folks (not at Dropbox) will also blog about their experience. In the meantime you can read Daniel F. Moisset's three-part blog about adding annotations to pycodestyle (formerly pep8) here:
http://www.machinalis.com/blog/a-day-with-mypy-part-1/
If you want to see a large open source code base that's annotated for mypy (with 97% coverage), I recommend looking at Zulip: https://github.com/zulip/zulip
Finally, some of us are starting a new (informational) PEP to set expectations for how type checkers should make use of the annotation syntax standardized by PEP 484 and PEP 526. This is going to take more time, and new collaborators are welcome here: https://github.com/ilevkivskyi/peps/blob/new-pep/pep-0555.txt. (Mark, I really hope you'll accept the invitation to participate. Your experience would be most welcome.)
-- --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/ rymg19%40gmail.com

On 8 September 2016 at 04:18, Guido van Rossum <guido@python.org> wrote:
There's been some quite contentious discussion about the PEP, on and off python-dev, regarding how the mere presence of annotation syntax in the language will change the way people will see the language. My own experience using mypy and PyCharm has been quite different: annotations are a valuable addition for large code bases, and it's worth the effort to add them to large legacy code bases (think millions of lines of Python 2.7 code that needs to move to Python 3 by 2020). The effect of this has been that engineers using Python are happier and more confident that their code works than before, have an easier time spelunking code they don't know, and are less afraid of big refactorings (where conversion to Python 3 can be seen as the ultimate refactoring).
I also don't think it hurts to make the language migration easier for folks coming from a C/C++/C#/Java background, and even if they initially use explicit hints more heavily than they need to given the inferencing engines in typecheckers, those same hints have the potential to enable more automated refactorings that simplify their code. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
participants (4)
-
Guido van Rossum
-
Ivan Levkivskyi
-
Nick Coghlan
-
Ryan Gonzalez