[acqq]

The development of V8 was paid for by Google, and at that point they wanted to achieve market dominance against other big players.

It seems nobody is willing to put big enough money behind making Python much faster. My view is that the limitations are almost purely financial (as in, paying heavily somebody as skillful as e.g. Mike Pall or Lars Bak(1) and his team), not technical.

If Guido would not accept the "faster" Python, the fork would still be more popular if it would be compatible enough. And there are the technical aspects: it's not enough to make Python interpreter alone faster, whoever would take that challenge would have to adapt various important external libraries to be really accepted. Which is AFAIK also doable.

1) https://en.wikipedia.org/wiki/Lars_Bak_(computer_programmer)

[sametmax]

It's exactly that.

The Python ecosystem in general is severely underfunded despite all big players using it extensively, which makes it really unfair if you compare it to the money poured into JS because of its monopoly on the web.

Remember Unladen shallow ? "Google" attempt to JIT Python ? It was just one guy during his internship (http://qinsb.blogspot.fr/2011/03/unladen-swallow-retrospecti...).

And look at the budget the PSF had in 2011 to help the community: http://pyfound.blogspot.fr/2012/01/psf-grants-over-37000-to-.... I mean, even today they have to go though so many shenanigans for barely 20k (https://www.python.org/psf/donations/2018-q2-drive/).

But at the same time you hear people complaining they yet can't migrate to Python 3 because they have millions of lines of Python. You hear of them when they want to extend the support for free, but never to support the community.

It's ridiculous.

Python needs a sugar daddy. It's used in Mac and Linux. It's used at Microsoft, Google, Facebook, Nasa and so many more.

[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.

[ris]

> My view is that the limitations are almost purely financial

Your view is wrong. Implementing highly optimized versions of different languages (which may from the layman's point of view look quite similar) is not completely comparable. Python is a much more dynamic language than javascript - huge amounts of the language are overridable object by object, even down to attribute access. Hell, even down to isinstance() behaviour. And these are all things that need e.g. deoptimization barriers added in the code fast path to check if xyz mechanism happens to have been overridden. Javascript doesn't even have operator overloading.

The PyPy team have put a lot of work into building a performant python implementation (there's your "fork" for you...) having to, from what I can tell, work through a lot of these issues with a good deal of ingenuity along the way.

Throwing money and/or "rockstar programmers" at projects isn't as wise as it always seems. Particularly when they don't seem to have significantly investigated the work of a team that's been working on the "fast python" problem for the last 15 years.

[acqq]

> Particularly when they don't seem to have significantly investigated the work of a team that's been working on the "fast python" problem for the last 15 years.

If you mean PyPy, PyPy was from the start intentionally "meta": it was never made to be simply a Python with a faster interpreter(s) and fast JIT(s) working in sync, like the modern Javascript engines work. It was intentionally a reimplementation of Python interpreter and all possible code in Python (that's where the name PyPy comes from), and then what's "optimized" is everything together: the new interpreter and the new Python implementation written in Python, all while generating a real C source. Which is then compiled as a normal C.

It's obviously too "meta" goal compared to the approaches used by fast Javascript engines, even if they also use some Javascript implementations for some library functions. When your starting goal is to "do everything in Python" you have already blocked yourself from being able to take the really best possible approach on every level of the engine. And even being meta enough, they still write:

"in code like this with a string-valued foo() function:"

   for x in mylist:
       s += foo(x)

"the JIT cannot optimize out intermediate copies. This code is actually quadratic in the total size of the mylist strings due to repeated string copies of ever-larger prefix segments."

So yes, there's definitely a room to make a faster usable implementation compared to the current PyPy. But it is a hard work, and needs a very focused and knowable leader(s), willing to take the "harder" approaches on every level, when needed. "Harder" than "we'll do everything in Python and only then optimize the whole thing together."

[MR4D]

I’m afraid that you might be right. I’d love to see Instagram step up to the challenge here, as they obviously have deeper pockets than most.

Who knows, maybe releasing their experimental code would prompt some really good discussion and get things moving in a direction of speedy run times.