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

[Nick Coghlan]

On 22 April 2015 at 03:03, Carol Willing <willingc at willingconsulting.com> wrote:
> 2. Clearly, great thought has been put into this PEP. If anyone has a good
> analysis of the potential impact on Python 3 adoption, please do pass along.
> I would be interested in reading the information.

I don't have hard data, but I do get to see quite a few of the
challenges that dynamically typed languages (including Python) have
scaling to large development teams. When you look at the way folks
actually *use* languages like Java and C# in practice, you find that
they're almost universally "tool mavens" (in Oliver Steele's sense:
http://blog.osteele.com/posts/2004/11/ides/) where automated tools are
taking care of most of the boilerplate for them. Find me a C#
developer, and I'll bet you they're a Visual Studio user, find me a
Java developer, and I'll bet you they're an Eclipse or IntelliJ user.
This approach actually offers a lot of benefits in putting a "skill
floor" under a development team - while you can't make people think,
you can at least automatically rule out broad categories of mundane
errors, and focus on the business logic of the problem you're aiming
to solve.

As a result, my main reaction to PEP 484 in a Python 3 adoption
context is that "Python 3 offers all the agility and flexibility of
Python 2, with all the structural assurances of Java or C#" is
actually a huge selling point for anyone in an institutional context
attempting to persuade their management chain to back a migration
effort from Python 2 to Python 3.

Another factor to consider here is that my understanding is that one
of the *reasons* folks want better structural analysis (by annotating
the Python 2 stdlib and key third part libraries in typeshed) is to
help automate Python 2 -> Python 3 conversions in the absence of
comprehensive test coverage. While to some degree this works against
the previous point, there's a difference between having this as an
addon vs having it as a standard feature (and unlike the network
security changes and bundling pip, this is one where I'm entirely
happy leaving it as the kind of carrot that can take pride of place in
a corporate business case).

The legitimate concerns that arise are around what happens to
*community* code bases, including the standard library itself, as well
as what folks are likely to see if they run "inspect.getsource()" on
standard library components. For that, I think there's a lot of value
in continuing to have explicit type hints be the exception rather than
the rule in the upstream community, so the idea of the typeshed
project is enormously appealing to me. If anyone doesn't want to deal
with type hints themselves, but has a contributor that really wants to
annotate their library, then "take it to typeshed" will hopefully
become a recurring refrain :)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia