[Python-Dev] Type hints -- a mediocre programmer's reaction

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>