As the maintainer of a huge (>150K LOC) #Python codebase like Platypush, whose development spans over more than a decade, I agree and disagree with the points made by the author.
I agree that Python’s very tolerant and flexible typing system makes it way too easy to shoot your leg.
And I also agree that meta-programming, albeit powerful, makes it hard to understand what you’re actually handling (and IDEs also get easily confused by it).
But I also think that using typing annotations whenever possible addresses these issues.
Sure, Python’s typing system doesn’t run at compile-time (there’s no compile-time anyway). So in theory it’s nothing more than nice guidelines that developers can happily ignore and still ship broken stuff to prod. But I also believe that it’s a civic duty to program in Python with editors that have Black or any other LINTer embedded, and treat any type warning that they raise as you would treat a compiler error in another language. And it’s also a good practice to add pre-commit hooks or LINT tests on your CI/CD that would prevent you from merging into main if there’s any issue.
If you set up your environment like this, and you use strong typing annotations in most of the cases, then it’s not very different from using Java or another other strongly typed language.
That being said, I still like to have the ability to do duck-typing or meta-programming sometimes.
After working on huge Python codebases for many years I’ve come to the conclusion that you don’t really need such dynamic typing cowboy styles that often. On average it’s probably going to be beneficial in <5% of your codebase. But having that flexibility of saying “hey, what I’m passing to this deserialize method can be nearly anything - bytes, strings, dicts, collections, already deserialized object etc. - just don’t fuss about it and give me back something already normalized”, rather than declaring 10 different overloaded methods with different signatures, is a big gain compared to, say, Java or C#.
I wish these languages had implemented something that resembles Python’s Union type - it’s a good trade-off between strictness and flexibility whenever you have some function that can accept a bunch of stuff, and you want to enumerate what all that stuff is.
https://dustri.org/b/friends-dont-let-friends-write-production-software-in-python.html
Fabio Manganiello /
npub13u…dpvgs
2025-03-27 11:12:24
Author Public Key
npub13uunvh7djw9ep54nswkuxlneyee7ehcpc7e53t68krykrdeg6j4qrdpvgsPublished at
2025-03-27 11:12:24Event JSON
{
"id": "1254a058139242e91224b20633a4ad40f5250171f5b0a51798c0b1c5299f9fad",
"pubkey": "8f39365fcd938b90d2b383adc37e792673ecdf01c7b348af47b0c961b728d4aa",
"created_at": 1743073944,
"kind": 1,
"tags": [
[
"t",
"python"
],
[
"proxy",
"https://manganiello.social/objects/29bf4170-8674-4daf-b94e-a7bdbe8d7487",
"activitypub"
]
],
"content": "As the maintainer of a huge (\u003e150K LOC) #Python codebase like Platypush, whose development spans over more than a decade, I agree and disagree with the points made by the author.\n\nI agree that Python’s very tolerant and flexible typing system makes it way too easy to shoot your leg.\n\nAnd I also agree that meta-programming, albeit powerful, makes it hard to understand what you’re actually handling (and IDEs also get easily confused by it).\n\nBut I also think that using typing annotations whenever possible addresses these issues.\n\nSure, Python’s typing system doesn’t run at compile-time (there’s no compile-time anyway). So in theory it’s nothing more than nice guidelines that developers can happily ignore and still ship broken stuff to prod. But I also believe that it’s a civic duty to program in Python with editors that have Black or any other LINTer embedded, and treat any type warning that they raise as you would treat a compiler error in another language. And it’s also a good practice to add pre-commit hooks or LINT tests on your CI/CD that would prevent you from merging into main if there’s any issue.\n\nIf you set up your environment like this, and you use strong typing annotations in most of the cases, then it’s not very different from using Java or another other strongly typed language.\n\nThat being said, I still like to have the ability to do duck-typing or meta-programming sometimes.\n\nAfter working on huge Python codebases for many years I’ve come to the conclusion that you don’t really need such dynamic typing cowboy styles that often. On average it’s probably going to be beneficial in \u003c5% of your codebase. But having that flexibility of saying “hey, what I’m passing to this deserialize method can be nearly anything - bytes, strings, dicts, collections, already deserialized object etc. - just don’t fuss about it and give me back something already normalized”, rather than declaring 10 different overloaded methods with different signatures, is a big gain compared to, say, Java or C#.\n\nI wish these languages had implemented something that resembles Python’s Union type - it’s a good trade-off between strictness and flexibility whenever you have some function that can accept a bunch of stuff, and you want to enumerate what all that stuff is.\n\nhttps://dustri.org/b/friends-dont-let-friends-write-production-software-in-python.html",
"sig": "2e7053fb875c122c72639bb4811b3507fee7adbc112325f8e0584fa6498ed1e8a9e4a1b123cea67f86dacdbde87e5a734ac7dfa5a30fdab94f7a8420715dfe01"
}