Growing pains for typing in Python [LWN.net]

Growing pains for typing in Python

Posted Jan 19, 2024 9:10 UTC (Fri) by ringerc (subscriber, #3071)
In reply to: Growing pains for typing in Python by aigarius
Parent article: Growing pains for typing in Python

Where I find that this falls down is when you go to change things.

Test coverage is great and all. But it's amazing how many bugs can be present in a code base with 100 line based coverage. Even if you check coverage of branch permutations in functions (hardly anybody does), it's basically impossible to do it deeper than function scope, and only in small functions.

Type systems make it much easier to say "doing this shouldn't work" or "the meaning of this has changed and you need to check everywhere that consumes the old thing to make sure it will understand the new thing".

Yes, it's tedious, harder to design well, and can be lots of pointless-seeming labour. They are IMO overused unnecessarily. But for interfaces between large complex systems they're fantastic, and in languages without type systems people end up inventing their own inconsistent homebrew for this sort of job.

to post comments

Growing pains for typing in Python

Posted Jan 20, 2024 10:06 UTC (Sat) by anton (subscriber, #25547) [Link] (1 responses)

Where I find that this falls down is when you go to change things.

My experience is that run-time type checking works surprisingly well in the face of changes. The case I have in mind is a game with a Lua API that has seen hundreds of add-ons written over the last 15 years, probably far beyond what the designers of the API imagined. The API has seen occasional updates (including downgrades, to prevent botting) of the API, and the add-ons interact with one another, and receive new versions separately, and are updated by the users separately. Yes, occasionally there are things that do not work because of some incompatibility of an add-on with the upgrade of a different one, but then that is usually solved by an upgrade of one of the involved add-ons.

Type systems make it much easier to say "doing this shouldn't work" or "the meaning of this has changed and you need to check everywhere that consumes the old thing to make sure it will understand the new thing".

Exactly. So what would have happened if the game designers had used Java with its static type checking rather than Lua for the API? The add-on authors would have gotten "doing this shouldn't work" for many of the things they did that were outside what the API designers had in mind. And when the API authors wanted to downgrade the API, if they wanted to maintain "doing this shouldn't work", they would have produced a new API, and the earlier add-ons would have stopped working, because they would have been incomatible with the new API. Likewise if one add-on B extended another one A, and A was upgraded. Yes, the benefit you describe above would be there, but the cost is that there would not have been such a thriving add-on ecosystem; that cost far exceeds the benefit in this case; and I think there are many others.

Growing pains for typing in Python

Posted Jan 20, 2024 12:20 UTC (Sat) by pizza (subscriber, #46) [Link]

> So what would have happened if the game designers had used Java with its static type checking rather than Lua for the API?

Nothing, if the API was designed properly to use Java's Interfaces.