[Python-Dev] Type hints -- a mediocre programmer's reaction (original) (raw)

Ian Cordasco graffatcolmingov at gmail.com
Tue Apr 21 00:02:00 CEST 2015

On Mon, Apr 20, 2015 at 4:00 PM, Harry Percival <harry.percival at gmail.com> wrote:

@Lukasz:

Of course you're right, ugly is a matter of perspective, and I'm sure I could grow to love them, and they might evolve into a more polished direction > "they start to read more transparently after a while." But I'm still worried about beginners, and I'm even worried about me. I like to be able to scan through some code and see the essence of it. I learned Java at school, and I got it figured out, but i'm glad I left it behind. Every so often I read a TDD book and the examples are all in java and it just feels like obfuscation -- public void static private String[] class blabla... so many keywords and types getting in the way of *what the code is actually doing*. That's what's so appealing about Python, it strips it down to just the basics. And, to me, type hints are always going to be some unnecessary chaff that gets in the way of my understanding -- not useless, not that they don't have a purpose or that we should remove them completely. But if there was a way of just hiding them, so that I don't have to think about them, as a beginner, or as a normal programmer, most of the time, in the 90% of cases where I don't need to see them, I shouldn't have to... that's why i'm so keen on this stub files idea. One thing I don't understand is this "local variable inference" thing -- can that not be made to work in stub files?

On 20 April 2015 at 21:50, Harry Percival <harry.percival at gmail.com> wrote: > stub files are only used to type-check users of a module. If you want a module itself to be type-checked you have to use inline type hints is this a fundamental limitation, or just the current state of tooling? On 20 April 2015 at 21:48, Harry Percival <harry.percival at gmail.com> wrote:

> "I hate stub files. [...] in my opinion, [it] just about guarantees a maintenance burden that will fall by the side of the road.

I'm not so pessimistic. It's not like documentation or docstrings or comments -- the whole point is that it should be very easy to have an automated check for whether your stubs are in sync with your source, because both are in code. Unlike docs or comments which can easily become out of date, because there's no automated process to tell you they need updating... I'm thinking of it as a thing your editor will warn you of. Like pyflakes warnings about unused variables & co, I'm never happy until I've silenced them all in a file, and similarly, your editor will keep bugging you until you've got your stubs inline with your code...

On 20 April 2015 at 20:37, Isaac Morland <ijmorlan at uwaterloo.ca> wrote: On Mon, 20 Apr 2015, Paul Moore wrote: On 20 April 2015 at 19:41, Barry Warsaw <barry at python.org> wrote:

tldr; type hints in python source are scary. Would reserving them for stub files be better?

I think so. I think PEP 8 should require stub files for stdlib modules and strongly encourage them for 3rd party code. Agreed. I have many of the same concerns as Harry, but I wouldn't have expressed them quite as well. I'm not too worried about actually removing annotations from the core language, but I agree that we should create a strong culture of "type hints go in stub files" to keep source files readable and clean. On that note, I'm not sure "stub" files is a particularly good name. Maybe "type files" would be better? Something that emphasises that they are the correct place to put type hints, not a workaround. How about "header" files? (ducks...) Isaac Morland CSCF Web Guru DC 2619, x36650 WWW Software Specialist

Python-Dev mailing list Python-Dev at python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/hjwp2%40cantab.net

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.

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.

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.

Cheers, Ian

[1]: I am a maintainer of flake8, requests, chardet, github3.py uritemplate.py, rfc3986, sqlobject, the requests toolbelt, a bunch of the requests auth plugins, and I'm a core developer on a small number of openstack projects. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20150420/dfc6a7ad/attachment.html>

More information about the Python-Dev mailing list