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

Nick Coghlan ncoghlan at gmail.com
Sat Apr 25 07:24:49 CEST 2015

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

More information about the Python-Dev mailing list