[fijal]

The barriers are nearly purely social - the unwillingness to drop C API (or to have a phase out plan) and to declare certain kinds of behaviors as "implementation dependent" make it very hard for any meaningful competition to emerge.

It is harder to make a fast python than to make a fast JS, but it's not that much harder.

[olskool]

> unwillingness to drop the C API

Is a feature not a bug. It makes things like NumPy, SciPy and Pandas possible.

[eesmith]

Aren't things like NumPy, etc. also possible through a FFI?

That is, I can understand that there's such a big installed based that people are loath to get rid of the Python/C extension API, but I think that's different than saying those projects are impossible without that extension API.

[quotemstr]

> the unwillingness to drop C API

What are you talking about? The article is about the Python core dev group rejecting speedups that preserve C module compatibility for the sake of, uh, readability or something?

[MR4D]

I’m probably going to get crucified for this, but what the heck - open discussion on this topic is needed...

I like what you’re saying, but wonder if we made small incompatible changes over time, would that solve the problem? For example (and please forgive me on this), but there are so many similarities between Python and different languages. Objects are obviously everywhere - C++, Java, .Net, etc; and syntax’s are similar at a cursory glance to things like Fortran. All of the above are much faster.

We took a decade to go from Python 2 to 3, but that had some pretty big changes. Going from 3 to 4 and getting a 50% speedup while making some (hopefully small) incompatible changes would probably be a good motivator for people to migrate faster.

There are obviously pros and cons to this discussion, but i really believe that stagnation is the worst choice. (Ok, Perl made a worse choice, but I’m presuming we learned that the level of change from 2-3 is as far as we can go in a generational update (x.0) ).

[acqq]

> Going from 3 to 4 and getting a 50% speedup

That's way too low goal to even matter.

See this:

https://news.ycombinator.com/item?id=17007867

A simple loop in loop is 50 times faster in Javascript in the Firefox than the same loop in loop in Python. When you say "50% speedup" I understand you expect a speedup of 2 in "10 years". Before V8 the Javascript in Firefox was even slower than Python is now. And now it's 50 times faster than Python for "simple" things (which are actually the most important ones to be made faster). PyPy also proves that some code can be JIT-ed. One of the PyPy's problems is the "compatibility with libraries" part.

And yes, that kind of speedup like in Javascript is achievable in Python too. It's just a question of the right people being paid to do that. I've personally made some JIT compilers and I'm sure that Python can also have really useful faster interpreter and JIT. The approach of V8 for speeding up the "objects" as they are typically used and the calls can surely be applied to Python:

From the article: "The instrumented interpreter found that 70% of objects have all of their attributes set in the object's __init__() method."

As far as I know, V8 approach shines for such objects.

Also note that modern Javascript engines don't do only JIT or only interpretation, they adapt in runtime.