(original) (raw)
On Tue, Apr 21, 2015 at 9:47 AM, Antoine Pitrou <solipsis@pitrou.net> wrote:
On Tue, 21 Apr 2015 09:28:45 -0700
Guido van Rossum <guido@python.org> wrote:
> On Tue, Apr 21, 2015 at 12:49 AM, Antoine Pitrou <solipsis@pitrou.net>
\> wrote:
\>
\> > On Mon, 20 Apr 2015 20:43:38 -0400
\> > "R. David Murray" <rdmurray@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).
I was thinking of potential stub files. Or are you also putting a ban
on those for existing stdlib code? Sorry if that has already been
answered...
No ban, but for now the plan is to collect and manage those separately as part of typeshed. I imagine the typical failure case is where the stubs are more restrictive than the implementation -- after all if the implementation becomes \*more\* restrictive it's breaking backward compatibility. I think it's okay for the stubs to lag behind like that, so I don't expect pressure on stdlib contributors. If anything the pressure will be on typeshed.