Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

>Python has multiple inheritance; JS doesn't

I don't think multiple inheritance is a performance issue. A class's resolution order is resolved when it's defined (using C3: https://en.wikipedia.org/wiki/C3_linearization), and after that it's only a matter of following it, like Javascript's prototype chain.



No, basically everything is dynamic in Python. Both objects and types are mutable after definition:

https://github.com/oilshell/blog-code/blob/master/python-is-...

    m1 Sub
    m2 C
    ---
    Changed type of object:
    m1 C
    m2 C
    ---
    m1 Sub
    m2 C
    ---
    Changed superclass of type:
    m1 Sub
    m2 unrelated


Objects and types are mutable after definition, but that's no more severe than what you can do in Javascript. Assigning to .__class__ is like assigning to .__proto__, and assigning to a class's .__bases__ is more or less like assigning to a prototype's .__proto__.

The resolution order is calculated when it's defined. It's calculated again whenever you assign to __bases__ (or a superclass's __bases__). But it's not calculated every time it's used, which means there's no significant performance penalty to multiple inheritance unless you're changing a class's bases very often.

Metaclasses can override the MRO calculation, which we can abuse to track when it's recalculated: https://pastebin.com/NdiA12Ce

  Defining Baz
  ! Computing MRO
  Instantiating Baz
  Accessing attribute
  Changing Baz's bases
  ! Computing MRO
  Accessing attribute
Doing ordinary things with the class or its instances doesn't trigger any calculation related to multiple inheritance. You only pay for that during definition or redefinition. So there's no performance problem there compared to Javascript.

I do agree that basically everything is dynamic in Python. But some things are more dynamic than others.


Hm yeah I see what you mean. I don't know the details of how v8 deals with __proto__, but I can see in theory they are similar.

Though I think the general point that Python is a very large language does have a lot to do with its speed / optimizability. v8 is just a really huge codebase relative to the size of the language, and doing the same for Python would be a correspondingly larger amount of effort.

I don't know the details but v8 looks like it has several interpreters and compilers within it, and is around 1M lines of non-test code by my count!

v8 was written in the ES3 era. And I knew ES3 pretty well and Python 2.5-2.7 very well, which was contemporary. I'd guess at a minimum Python back then was a 2x bigger language, could be even 4x or more.


I agree, I was just nitpicking one detail. I made a similar comment: https://news.ycombinator.com/item?id=20953496




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: