On 21 April 2015 at 10:02, Ian Cordasco <graffatcolmin...@gmail.com> wrote: > >
> > So I've generally stayed out of this but I feel there is some context that > people are missing in general. > > First, allow me to provide some context: I maintain a /lot/ of Python > code[1] and nearly all of it is designed to be compatible with Pythons 2.6, > 2.7, 3.2, 3.3, 3.4 (and eventually 3.5) and sometimes 2.5 (depending on the > project). If I want to improve a developer's experience with some of that > code using Type Hints I will essentially have no way to do that unless I > write the code with the annotations and ship versions with annotations > stripped and other versions with annotations? That's a lot more overhead. If > I could provide the annotations in stubs that means that only the people who > care about using them will have to use them. 2.5? I'm so sorry :). Being in approximately the same boat, I definitely want to be able to improve the developer experience. That said, with one key exception (str/bytes/unicode) Python code generally has the same type on all versions. Sure it might be imported from somewhere else, and you're restricted to the common subset of APIs, but the types in use don't vary per-python. So - as long as your *developers* can run mypy on 3.2+, they can benefit from type checking. mypy itself requires 3.2+ to run, but programs with type annotations should be able to run on all those python versions you mention. Now, what is the minimum barrier for entry? Nothing :) - at the moment every file can be analysed, and mypy ships with a bunch of stubs that describe the stdlib. So - you'll get some benefit immediately, where bad use of stdlib routines is happening. Constraining the types of functions gets you better errors (because you are expressing intent rather than what-might-happen which the inference has to work from otherwise. In particular, constraining the type of *inputs* can let bad callers be detected, rather than the engine assuming they are valid-until-a-contradiction-occurs. You can do that with stub files: put them in repo A, and add them to the MYPYPATH when working on repo B which calls the code in repo A. You can also add those stubs to repo B, but I wouldn't do that because then they will skew vs repo A. A further step up would be to annotate A in its code, rather than using stubs. That way, developers of repo A will be warned about bad uses of other repo A code. But - if you have stubs *or* annotations in-line in repo A, *everyone* changing repo A needs to care. Because if the code mismatches the stub, the folk that do care will now be unable to use repo A correctly - their type checker will complain about valid uses, and fail to complain about more invalid uses. I'm particularly interested in mypy for OpenStack because for some repos > 10% of reported bugs are type mismatch errors which mypy may well have avoided. > Is it more overhead to manage twice the number of files? Yes. Do I feel it > would be worth it to not overly complicate how these packages are released? > Yes. > Further, there are far more reasons to make stubs the baseline (in my > opinion) the biggest reason of all is that people want to provide stubs for > popular yet unmaintained libraries as third party packages. Should everyone > using PIL be using Pillow? Of course. Does that mean they'll migrate or be > allowed to migrate? No. Should they be able to benefit from this? Yes the > should. The only way for PIL users to be able to do that is if stub files > can be packaged separately for PIL and distributed by someone else. stubs can certainly be packaged and distributed separately. That doesn't make the case that we should use stubs for projects that are opting in. > I think while the authors are currently seeing stubs as a necessary *evil* > they're missing points where they're a better backwards compatible solution > for people who want to give users with capable IDEs the ability to use stub > (or hint) files. -Rob -- Robert Collins <rbtcoll...@hp.com> Distinguished Technologist HP Converged Cloud _______________________________________________ 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
