blog/type-hinting-get-the-hint

[utterances-bot]

Get the Hint - Type Hinting is Common Python | The When of Python Blog

How we handle type hinting will define the future of Python for good or bad. Type hinting is useful as glorified commenting and as such should be part of everyone's Everyday Python. It should be part of Common Python. Type hinting is likely to be widely used in the code people encounter so we all need to be comfortable reading simple type hinting. Some enterprise and library codebases will benefit from a more strict and enforced form of type

https://when-of-python.github.io/blog/type-hinting-get-the-hint.html

[iokiwi]

Adapted from my similar comment on the NZPUG Mailing List

--
I've started using type hinting as much as possible for new projects / code written in conjunction with 'mypy' for some checking and enforcement.

Personally I find it helps readability of code and also helps reinforce a clarity of thinking particularly around return types from functions and return types under conditions that aren't the happy path. It often makes me ask "Can I sensibly return that type or should I throw an exception?"

It pays dividends when reading otherwise unfamiliar code or a new library and when onboarding new team members and junior devs.

For existing/older projects it can be a bit of a headache to integrate if the code base has...how do I say it...taken full advantage of python's dynamic typing.... You may find that trying to add type hinting retrospectively unveils issues with mixed types being passed or returned. It's down to you/your team to decide how much effort to put into fixing that. In my opinion it's worth taking a crack as exercise anyways. It will either be a breeze or you'll identify inconsistent typing you may not have been aware of.

The two catalyzing factors that got me motivated for really embracing were.

• Working on Openstack source code where, even for things that should be relatively trivial such as client libraries, there were like 6 different data representations of an object (from different SDK's or different layers of abstraction of the same SDK) and so it was very tedious, time consuming and frustrating trying to figure out which one was actually expected. The function asks for an 'image' but is a dict, a Munch, an object? what kind of image object? From the glance-client? from the openstack sdk?

• Doing a code interview with Canva where they provided some function definitions with empty bodies and type hints in the function signature. I could understand the program and data types and flow of the entire program completely before having written a single line of code. It also made extending those functions a breeze because there were already strong type contracts. If the rest of their code base looks like that, then it would be a very pleasant code base indeed.

I'd be interested to hear how other are using pythons type hinting to their advantage.

Final point, and call this an argument of popularity, but there appears to be consensus forming around the usefulness of static type checking.

• In the JavaScript community there has been a monumental shift towards typescript for the power and additional assurance type checking gives them.
• Newer languages such as Rust, Go, etc. all do static types

--

Having now read your blog post properly, I would also add some following observations

• While adding type hinting (and enforcing type checking) add subtleties and complexities not previously obstacles to python programming - I can't see how these aren't subtleties and complexities created by - and solved - in any other statically typed language.

• Some of these hurdles are necessary and lead to better code structure of which the flexibility of python lets us get away without.

• Type hinting/checking should be encouraged but the flexibility to write python without static type checking is still a good option for educating total beginners and for professionals writing small, quick and dirty scripts to get stuff done.

[grantps]

Here is Robert Collins's comment from the NZPUG mailing list, included with his permission:

Interesting post, I don't agree with the presumption that function definitions that fully specify their input and output types are bad.

For an entire program under oh 40 lines of code, whatever goes.

Beyond that, there are many benefits from static analysis. You refer to 'just another static language', but static languages are not all equal. The experience of writing code in C, where nothing is inferred is very different to that of writing in Rust, where everything is inferred except for function signatures.

And that is functions specifically. Lambdas /closures/code blocks infer there as well.

Some of the rationale for that is language mechanics, but part of it is one that makes sense for python too, limitations in mypy aside. Which is that functions are our reusable units of code, and being clear about what we wrote them to do helps us decide when they are appropriate to use.

A good function signature with type information also reduces function documentation needs, since the types are documented directly. Only the content needs to be documented

Tl;dr: just as you should document what exceptions to expect, what parameters are used for, what is returned, and what a function does, you should also document the types of the input and output... And type hints are a way of doing that that is less likely to skew as the code base evolves.

[ncoghlan]

I like this summary of the topic, but one note on parameters with default values: the reason annotating "param=False" is unnecessary is that it being a "bool" parameter is inferred from the default value being a bool. Ditto for any other parameter with a meaningful default value.

Explicit annotations are only helpful when they add info:

• no default value
• default value is None
• inferred type would be too narrow (e.g. default is a tuple, but any iterable is acceptable)
• inferred type would be underspecified (e.g. default is an empty tuple, but specifically a tuple of ints is expected)
• type of default value is not obvious to a human reader (i.e. it's a variable rather than a literal, and the name doesn't make the type self-evident)

One sign that type hints may be a good addition is when an existing docstring already provides the information in prose form.

[reedwade]

Where I'm working right now (started a year ago) we've got a very large python code base with a lot of moving parts.

There's a number of services and tools and we're turning into a large company (500 people now) with dev work happening in all the time zones.

For all that, it's unusually well organised and coherent.

We use type hinting as much as possible and we'd have serious problems if we didn't.

I have mixed feelings coming from a lot of Go prior to this. With Go, the typing is clear. You know it, your IDE knows it. Refactoring is safe and easy. Python type hinting feels and acts very bolted on and inconsistent to me in comparison. It feels like a lot of the time you need to specify the type but then still you have to be as careful as you used need to be anyway.

I really get cranky about how it seems to be difficult (for me) to work with type conversions when I need a thing to just be a string. I've spent a lot of hours angrily fighting the scheme in order to get work done -- knowing all the while that it's not even checked at run time.

But, when it does what it does best, it's great. Friday, it caught an important flaw I'd made in argument passing which would have caused us a lot of trouble and was otherwise hard to test for.

I'm learning to appreciate it.

I have started to use the notation for tiny scripts as it helps explain what I'm doing to myself.

Does it make sense for Everyday Python?

I've got strong yes and strong no feelings on that. I think moderate use could make sense and improve the experience for beginners.