On 22 April 2015 at 04:28, Guido van Rossum <gu...@python.org> wrote: > On Tue, Apr 21, 2015 at 12:49 AM, Antoine Pitrou <solip...@pitrou.net> > wrote: >> >> On Mon, 20 Apr 2015 20:43:38 -0400 >> "R. David Murray" <rdmur...@bitdance.com> wrote: >> > +1 to this from me too. I'm afraid that means I'm -1 on the PEP. >> > >> > I didn't write this in my earlier email because I wasn't sure about it, >> > but my gut reaction after reading Harry's email was "if type annotations >> > are used in the stdlib, I'll probably stop contributing". That doesn't >> > mean that's *true*, but that's the first time I've ever had that >> > thought, so it is probably worth sharing. >> >> I think it would be nice to know what the PEP means for daily stdlib >> development. If patches have to carry typing information each time they >> add/enhance an API that's an addition burden. If typing is done >> separately by interested people then it sounds like it wouldn't have >> much of an impact on everyone else's workflow. > > > This point will be moot until new code appears in the stdlib whose author > likes type hints. As I said, we won't be converting existing code to add > type hints (I'm actively against that for the stdlib, for reasons I've > explained already). > > *If* type hints prove useful, I expect that adding type hints **to code that > deserves them** is treated no different in the workflow than adding tests or > docs. I.e. something that is the right thing to do because it has obvious > benefits for users and/or future maintainers. If at some point running a > type checker over the stdlib as part of continuous integration become > routine, type hints can also replace certain silly tests. > > Until some point in a possible but distant future when we're all thinking > back fondly about the argument we're currently having, it will be the choice > of the author of new (and *only* new) stdlib modules whether and how to use > type hints. Such a hypothetical author would also be reviewing updates to > "their" module and point out lack of type hints just like you might point > out an incomplete docstring, an outdated comment, or a missing test. (The > type checker would be responsible for pointing out bugs. :-P )
What about major changes to existing modules? I have a backlog of intended feature uplifts from testtools into unittest - if the type hints thing works out I am likely to put them into testtools. Whats your view on type hints to such *new code* in existing modules? -Rob -- Robert Collins <rbtcoll...@hp.com> Distinguished Technologist HP Converged Cloud _______________________________________________ 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
