[Python-Dev] typeshed for 3rd party packages (original) (raw)

Ian Cordasco graffatcolmingov at gmail.com
Wed Apr 22 18:26:14 CEST 2015

On Wed, Apr 22, 2015 at 11:12 AM, Skip Montanaro <skip.montanaro at gmail.com> wrote:

On Wed, Apr 22, 2015 at 10:43 AM, Guido van Rossum <guido at python.org> wrote:

For Requests, it looks like it may be better not to have stubs at all. Can you expand on this? Why would Requests be any different than any other module/package? On a separate thread Cory provided an example of what the hints would look like for part of one function in the requests public functional API. While our API is outwardly simple, the values we accept in certain cases are actually non-trivially represented. Getting the hints exactly correct would be extraordinarily difficult.

As for versioning, I think stub files would absolutely have to declare the appropriate version(s) to which they apply (probably via embedded directives), so type checkers can ignore them when necessary. That also means that type checkers must be able to figure out the version of the package used by the application being analyzed.

Not sure I'm being too clear, so I will provide an example. I have app "myapp" which imports module "yourmod" v 1.2.7. The yourmod author hasn't yet provided type annotations, so someone else contributed a stub to the typeshed. Time passes and a new version of "yourmod" comes out, v 2.0.0. (Semantic versioning tells us the API has changed in an incompatible way because of the major version bump.) I decide I need some of its new features and update "myapp". There is no new stub file in the typeshed yet. When I run my fancy type checker (someone suggested I will shortly have 50 to choose from!), it needs to recognize that the stub no longer matches the version of "yourmod" I am using, and must ignore it. Which of course also assumes that the author of that library is even using Semantic Versioning (which is not a universal release strategy, even in the Ruby community). I understand where you're coming from, but I think this is a reason as to why typeshed as a catch-all for third party type-hints may not be feasible.

Does that suggest the typeshed needs some sort of structure which allows all versions of stubs for the same package to be gathered together? My apologies if I'm following along way behind the curve.

No need to apologize. =)

As the other maintainer of requests, I think having hints might help some developers, but looking at what Cory generated (which looks to be valid), I'm wondering about something else with Type Hints.

I've heard several people say "Just create an aliased type for the hint so it's shorter!" but doesn't that mean we then have to document that alias for our users? I mean if the IDE suggests that the developer use XYZ for this parameter and there's no explanation for XYZ actually is (in the IDE), doesn't this just add a lot more maintenance to adding hints? Maintainers now have to:

Don't get me wrong. I really like the idea of moving towards Type Hints. I'm not even particularly against adding type hints for Requests to typeshed. I'm just hesitant that it will be easy to make them entirely accurate.

Cheers, Ian -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20150422/35657f29/attachment.html>

More information about the Python-Dev mailing list