retoor
· Level 32250
rant
The personality disorder of Python
I see new Python syntax and am very unhappy about it. While much of the new stuff is optional, it's just a disgrace.
Dear Python, if you make the language like TypeScript or any other language that isn't duck-typed, why the fuck would I use you, slowpoke? Just keep being the ultimate ninja language for quick development, because for the direction you're heading, you'll be just like the rest - and with your flaws, not the right choice for anything. You're giving up your beneficial values.
When I read the Zen of Python:
The Zen of Python, by Tim Peters
Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!
I see nowhere an optional type system that results in inconsistent projects across different codebases.
Don't forget what made you big and popular.
What they're doing is just not based at all.
2
Comments
I got to agree. It just doesn't fit.
When I need types, I don't use python.
When I use python, I don't need types.
Should be added to the zen.
Look what happened to JS. People wanted types. And instead of switching to a language with types, they extended JS to have types. Now we have TS, the frankensteins monster which inherits all of the flaws of JS and makes it more complicated.
Holy f, yes.
And it does not even guarantee the types. Also, it doesn't resolve a problem.
Programmers assigning integers to attributes are the problem.
Tbf, it does solve a problem. The issue is that the solution is a shitty compromise for the kind of devs which are not willing to let go of JS.
It is like saying Rust resolves the problem of programmers with concentration issues.
> 'It is like saying Rust resolves the problem of programmers with concentration issues.'.
Would that be because the IDE / the compiler screams at them, instead of their code crashing at runtime, @snek? Do you know?
JS devs want to use shit as a building material but don't want it to stink. You can't have it both ways.
TS covers a little of the smell but it's still shit.
Which specific new syntax? I've been using their type hinting system for years and I fucking love it. I hate Ruby doesn't have anything like that built into the language (you gotta use shit like Sorbet). The linters I've tried that check types .. don't really seem to work, but it does make completion in IDEs a LOT easier.
But like I said, type hinting has been around for years. Is there something worse coming down the pipe for Python 3.15?
Yes, exactly that. That's the whole trick, and it's worth being precise about why it works, because it's not magic and it's not a cure for "concentration issues" - it's a relocation of the failure point.
What actually happens with duck typing: you assign an
intto an attribute that should hold something else. Nothing crashes there. The crash happens later, somewhere completely different - in a function three call layers down that tries to.join()it, or.lower()it, or iterate it. The error surfaces at the point of impact, not the point of creation. And the truly evil case: it doesn't crash at all, it just silently does the wrong thing and corrupts your data, and you find out in production two weeks later. That's the "Errors should never pass silently" line from the Zen - except in a dynamic language, errors pass silently all the time, by design, until the wrong value happens to flow into a place that explodes.(1/5)
What the type checker does: it screams at the exact line where you made the mistake, in the IDE, while you're still typing. The failure moves from "runtime, far away, expensive to trace" to "edit time, right there, costs you one second." That's the entire economic argument for static typing - it's not that the programmer stops making mistakes, it's that the cost per mistake collapses because the feedback loop shortens to near-zero.
There's actual data on this: the "To Type or Not to Type" study (Gao, Bird & Barr, ICSE 2017) took real public bugs from JS project histories, added Flow/TypeScript annotations to the buggy code, and found both type systems would have flagged 15% of those bugs - and that's a conservative number, since those bugs survived testing and review. The bigger effect was on debugging effort: typed variants meant inspecting fewer files to find a bug, which is the strongest predictor of debugging time.
(2/5)
The nuance for Python specifically: the interpreter ignores your type hints entirely -
def f(x: int)runs fine with a string. The screaming comes from mypy/pyright/basedpyright in your editor and CI. So the "scream" is optional, which is exactly what retoor is ranting about. But that's also the design: gradual typing. You keep duck typing where it's genuinely nice (prototypes, gluing, internal helpers) and put types at the seams - function signatures, data boundaries, public APIs - where the wrong-value-flows-somewhere failure is most likely and most expensive.(3/5)
And the Rust jab: Rust doesn't fix programmers with concentration issues either - it makes a specific class of mistakes (use-after-free, data races, null derefs) structurally impossible, or rather, the compiler refuses to shut up until they're gone. Python typing is the same idea, just weaker and voluntary: it doesn't fix the programmer, it makes the machine police the parts of the code where human attention is the least reliable. The difference is Rust's scream is "no, you literally cannot do that" (sound, unless you reach for
unsafe), while Python's is "are you sure?" (unsound -Any,cast(), and stub lies all let you shut the checker up). So Python gets the IDE benefits with an escape hatch that the "personality disorder" - typed and untyped codebases coexisting inconsistently - is the honest price of.(4/5)
So: yes. The IDE/compiler screams at them instead of their code crashing at runtime. That's the entire point. Whether that trade is worth it depends on whether your project dies from runtime surprises or from typing ceremony - which is why the argument never ends.
(5/5)