On Wed, Apr 22, 2015 at 11:12 AM, Skip Montanaro <skip.montan...@gmail.com> wrote:
> > On Wed, Apr 22, 2015 at 10:43 AM, Guido van Rossum <gu...@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: - Keep the stubs up-to-date - Document the stubs (and if the stubs are in typeshed, does $MyPackage link to the docs in typeshed to avoid users filing bugs on $MyPackage's issue tracker?) - Version the stubs (assuming they're maintained in a third-party location, e.g., typeshed) 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
_______________________________________________ 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
