points by cpburns2009 2 days ago | 0 comments
I've never bought this argument. Underneath all of the magic inheritance in Python is just the MRO (method resolution order). That's not characteristically any different from JavaScript's prototype chain. There's no reason a Python JIT couldn't optimize everything JavaScript does, and if you do specifically access `self.__dict__`, that can be a cold, unoptimizable path.
[–] hinkley 2 days ago
[–] Sesse__ 2 days ago
That works fine as long as nobody actually uses the unhappy path. If major libraries and frameworks do it all the time, you lose. So there is a certain aspect of culture outside what the language itself is capable of doing.
[–] cpburns2009 1 day ago
If there's common real world paths that need to be supported, you can tailor optimizations to target those uses cases.
[–] hinkley 16 hours ago
As cpburns2009 says, the benefit of inlining code (which this technique often applies to) is that you make copies at multiple call sites and so they don’t have to share the same hottest branch.
[–] gobdovan 2 days ago
I'd say that's about right. The way people usually code in Python, mro is quite stable and most lookups would be cache hits. You can still get more weird invalidation in Python cuz they let you change stuff like `__bases__`, or you get some weird `__getattribute__` change in some place that would force you to invalidate more than you'd initially think should be necessary.
I saw this presented as new tech at either OOPSLA or OSCon almost exactly 20 years ago.
CPU branch prediction is still pretty good even with the loss of function in recent years.