If you see only print, you are missing the point.

But good news, there are many projects working to improve the perfs and/or bypass the GIL this year.

The top thing, sometimes the only thing, that makes my scripts written for 2 not work in 3 is the change to print. Adding a print function is fine, I'm all on board with that; removing the statement though seems like pain for no reason. Bringing that up is not missing the point, it's hitting the nail right on the head.

Guido could do that if he decided that Python 4 would be based on PyPy (AFAIK, many people thought Python 3 would be based on PyPy too). Compatibility isn't 100% but if it was the main platform I'm sure it'd improve even faster.

AFAIK, many people thought Python 3 would be based on PyPy too

Don't think so. Some people hoped that Python 3 might be based on Unladen Swallow, which was a different Python JIT that Guido was working on while at Google, but that project never really got off the ground and Google seemed to lose interest in it.

With the proviso that a lot can change in two years, here's a relevant comment from the Dropbox Pyston announcement [1]:

"Guido's advice has been extremely helpful, but so far we haven't been able to get any code from him"

[1]: https://blogs.dropbox.com/tech/2014/04/introducing-pyston-an...

This might turn out to be quite difficult for non-trivial Python applications.

STM is exciting but I think it's important to keep in mind that it's an experiment that while promising might still fail in practice.

What difference does that make. STM will still enable the removal of the GIL. If an applications is coded that doesn't work with PyPy, that's a separate matter.

I remain skeptical that STM is a good fit for this problem, as I was when I first heard about this, and after their work, alas, I have to say I see little evidence to make me change my mind on that. STM is something that probably needs to be baked in from day one, possibly all the way into the language itself, not put on the side of a complicated secondary implementation of Python.

From the page... "THIS PAGE IS OLD, THE REST IS ABOUT STMGC-C7 WHEREAS THE CURRENT DEVELOPMENT WORK IS DONE ON STMGC-C8"

This page is probably a better starting point for the current PyPy STM work:

http://pypy.org/tmdonate2.html

Part of the problem is that they're trying to wedge into a really tight window; for all its flaws, the GIL is not all that expensive (relative to how slow Python in general is, anyhow), and trying to do it on PyPy makes their window even smaller. It's a really hard thing to hit, and I'll believe it when I see it. I'm not saying it's impossible. Just, I'll believe it when I see it, and I don't recommend a high degree of confidence that it will occur. Nor do I recommend that you use it as part of your advocacy... it's nowhere near solid enough to be making promises about it to people outside the community.

You may be interested in this...

"Leysin Winter Sprint (20-27th February 2016)"

"STM (Software Transaction Memory), notably: try to come up with benchmarks, and measure them carefully in order to test and improve the conflict reporting tools, and more generally to figure out how practical it is in large projects to avoid conflicts"

http://morepypy.blogspot.co.uk/2016/01/leysin-winter-sprint-...

> "Nor do I recommend that you use it as part of your advocacy."

I'm an advocate for F#, but I'll encourage the progress of any open source language, strong competition is good for the field as a whole. The question isn't 'Why can't Python be fast?' but rather 'How fast can Python be?', the difference is a difference in attitude.

Python 4 will just be the next release after Python 3.9.

The problem isn't just breaking compatibility, it's performance. There have been a number of experiments with removing the GIL going back (I think) to python 1.4. However every attempt has led to significant performance degradation in some part of the language.

That's a bold statement. Can you elaborate on what those reasons are?

1. The Python language itself doesn't lend itself to being JIT compiled - it's too dynamic.

2. cPython is the reference implementation. It's source should be as simple as possible.

3. Only a subset of Python programs would benefit, and the rest would be slower/more memory hungry

and finally,

4. If you want/need a JIT then use PyPy, in all it's glory with all its upsides and downsides.

PyPy is a big project with a lot of very very very smart people working on it. They've done an excellent job at JITting Python (and creating an impressive interpreter framework) but even they couldn't make a JIT that is anywhere near suitable for inclusion in cPython. A bunch of cPython hackers on python-dev have no chance.

tldr: Want a JIT? Use PyPy.

1. This was also said about JS before people just went ahead and wrote JITs for it. Are you sure what they're saying isn't "we can't make a JIT for python" rather than "nobody can make one"? Because that's how it turned out with JS.

2. If given the choice, do you think the community would turn down a JIT to avoid making the reference implementation more complex? To whose benefit is that requirement? I've never heard people complain about other languages that they didn't have an easy-to-read reference implementation.

3. I've not heard this reported as a problem in practice for languages that have a JIT. It's usually toy programs where the JIT overhead is significant and they're so small and short-running that neither slowdown or extra memory is usually an issue.

4. Not everything that runs on cPython runs on PyPy so that's not a choice I'm necessarily able to make.

I'm not saying there aren't reasons to not have a JIT in cPython. But it's a choice not a natural law. And it's not ridiculous to suggest that they could make a different choice if they wanted, as JS eventually did.

Remove the "maintaining compatibility for C-based extensions" requirement, and you get, well, PyPy. And you also get a community split that makes 2/3 look trivial. Vast swathes of core Python code and libraries are really not "Python", but Python C-based bindings to custom code or C libraries.

2. It would make the reference implementation insanely more complex, to the point where it is no longer a reference implementation but a JIT implementation of Python. That's not cPython's role. For whos benefit is the requirement of a JIT? My apps run fine without them, and I don't need the memory bloat or startup cost associated with a JIT. If the community really wants another JIT they could fork cPython, find a room full of JIT experts and re-do all of the work PyPy has done, with all of the tradeoffs and problems they encountered. Nice idea.

3. "so small and short-running that neither slowdown or extra memory is usually an issue." - this is exactly the situation where a JIT adds a lot of overhead and becomes an issue.

4. So you want the best of both worlds, with no clear idea as to what magical person can make this happen (or even how) and you won't be happy until you can have your cake and eat it?

It's not that the Python developers preventing discussion, it's just this discussion is always fruitless, has been had many times before and the people invoking the discussion often blame the cPython developers for their response. Nobody wins, it's a waste of time.

or spend some time helping with Pyjion to add a C API to CPython for plugging in a JIT of your choice

- https://github.com/Microsoft/Pyjion

Really? Why even change the major version then, when there are no breaking changes?

Given that many Python programmers seem to be traumatized by the last major version switch, why even bother?

Or is this just for setting up Python 5 can have breaking changes if the switch to 4 is painless?

Python releases don't follow semver. If Linus can bump the kernel to 4.0 because he felt like it so can Python.

"Can" is not "should": I mean, Python can go from 3.x to Python 2020, go with year numbers for a while, then have Python XP, then go Python 7, Python 8, Python 8.1, and then skip to Python 10. But there's no good reason to do that.

We'll see what it does to Python's popularity.