[Python-Dev] Type hints -- a mediocre programmer's reaction

Robert Collins robertc at robertcollins.net
Tue Apr 21 22:18:43 CEST 2015


On 22 April 2015 at 04:28, Guido van Rossum <guido at python.org> wrote:
> On Tue, Apr 21, 2015 at 12:49 AM, Antoine Pitrou <solipsis at pitrou.net>
> wrote:
>>
>> On Mon, 20 Apr 2015 20:43:38 -0400
>> "R. David Murray" <rdmurray at 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 <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud


More information about the Python-Dev mailing list