100% agree on everything you said. However it's easy to judge Python's mistakes through the lens of where we are right now - nobody even considered tracing JITs

100% agree on everything you said. However it's easy to judge Python's mistakes through the lens of where we are right now - nobody even considered tracing JITs for dynamic languages before V8 showed up, and without this perspective, subclassing int could look like the more ergonomic choice. Python could have had ADTs as a core language feature 20+ years ago (rather than sloppily grafting them on in a recent release), just like it could have had unicode strings as the default text type since before 2.x (1.6 was 2000; unicode was early 1990s). But it also had a much smaller community back then, and who knows how making these choices back then would've impacted its development? Maybe it'd end up being as relatively obscure as say Tcl. Also I think you could still achieve reasonable optimisations even if you do go that route; Go has type aliases (including on primitive types) that you can define custom methods on: type Weekday int const ( Monday = Weekday(1) ... ) func (w Weekday) Name() string { switch w { case Weekday(1): return "Monday" ... default: panic("?") } } If your compiler could prove nothing crazier than that is happening with your int subclass, I don't see why similarly written Python code should have a lower performance ceiling; but yes, that's more work for the compiler.