[Python-Dev] typeshed for 3rd party packages

[Guido van Rossum]

I definitely think that we shouldn't jump the gun here and tread carefully.
Both Marc-André and Cory brought up good things to watch out for.

For closed-source software the only way to obtain stubs is presumably from
the author, if they care. As Gregory Smith said in another thread, the
tooling will have to prove itself to the point where library developers
*want* to use it.

For Requests, it looks like it may be better not to have stubs at all. You
can assign any and all tracker issues asking for stubs to me, I'll gladly
explain why in Requests' case it's better to live without stubs.

On Wed, Apr 22, 2015 at 4:22 AM, Cory Benfield <cory at lukasa.co.uk> wrote:

> On 22 April 2015 at 11:46, M.-A. Lemburg <mal at egenix.com> wrote:
> > Unlike with translations, where missing or poor ones don't have
> > much effect on the usefulness of the software, a type checker
> > would complain loudly and probably show lots of false positives
> > (if you read a type bug as "positive"), causing the usual complaints
> > by users to the software authors.
> >
> > I don't really think that users would instead complain to the type
> > checker authors or find the actual source of the problem which are
> > the broken stub files.
>
> This is my expectation as well.
>
> Requests receives bug reports for bugs that were introduced by
> downstream packagers, or for bugs that are outright in unrelated
> projects. I field IRC questions about 'requests bugs' that are
> actually bugs in the web application on the other end of the HTTP
> connection! I can *guarantee* that if a stub file is bad, I'll get
> told, not the author of the stub file.
>
>
> > OTOH, if the type checkers are written in a way where they can
> > detect authoritative stubs compared to non-authoritative ones
> > and point users to the possible type stub file problem, this
> > could be resolved, I guess.
> >
> > The stub files would then need an "authoritative" flag and
> > probably also be versioned to get this working.
>
> This would be great: +1.
>
> > As I've explained above, in my experience, people (*) often first go
> > to the authors of the software and not do research to find out
> > that the tool they were using has a problem (via the non-authoritative
> > stub files it's using).
> >
> > (*) More experienced users of pylint like tools will probably think
> > twice due to the many false positives these tools tend to generate.
> > I'm not sure whether people using type checkers would have the same
> > approach, though, esp. not if they are coming from the land of
> > statically typed languages.
>
> I can back this up, as can a search through Requests' past GitHub
> issues. pylint in particular has caused me pain due to at least one
> GitHub issue that was nothing more than a dump of pylint output when
> run over Requests', where *every single line* was a false positive.
>
> This ends up having negative network effects as well, because the next
> time someone opens a GitHub issue with the word 'pylint' in it I'm
> simply going to close it, rather than waste another 45 minutes
> visually confirming that every line is a false positive. I worry that
> stub files will have the same problems.
>



-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150422/3ae87afa/attachment-0001.html>