4 things I want to see in Python 4.0

CPython 3.6 is out, 3.7 branches are all setup and CPython is now on GitHub. Exciting times for the Python community.

Python 2.7 was the last release of the 2.x series, so by Sir Bedevere logic, Python 4.0 will be the next major release after 3.7.

‘All wood burns,’ states Sir Bedevere. ‘Therefore,’ he concludes, ‘all that burns is wood.’

OK, so that is totally illogical, but if 4.0 were to come out soon- which features would you want to see?

Before we start the list, it’s important to remind ourselves what is in the CPython project. Python is 3 things, a language, a standard library and an execution engine. Compare that with JavaScript, which is just a language. It has no standard library, and the Google v8 engine does the execution, along with many other options.

Here’s my laundry list, it consists of mainly changes to the execution engine component of CPython, (aka the “runtime”). I believe that the standard library is feature packed and anything not found in the standard library is readily found on PyPi. The language doesn’t need any new operators or yet-another-way-of-formatting-strings, IMHO.

1. JIT as a first class feature

JIT or Just-In-Time compilation, is a method of compiling the byte-codes as they happen, instead of all at once. It can lead to better performance, depending on the scenario.

PyPy is an implementation of Python with its own JIT, Pyston is an implementation of Python using LLVM as a JIT compiler. Each of these compromises on functionality (or correctness of the language) over speed.

Having a first-class JIT plugin architecture for CPython would bridge the performance and compatibility needs together and efforts spent on PyPy, Numba etc could be directed into the main CPython ecosystem.

The good news? This is already accepted as PEP-523, thanks to core developer Brett Cannon and his Microsoft colleague Dino Viehland. The API was added in 3.6, but we’re yet to see an implementation out there of the API. The Pyjion project still needs updates.

2. A stable .0 release

Python 3 release history

Python 3.0 — December 3, 2008

• Python 3.1 — June 27, 2009
• Python 3.2 — February 20, 2011
• Python 3.3 — September 29, 2012
• Python 3.4 — March 16, 2014
• Python 3.5 — September 13, 2015
• Python 3.6 — December 23, 2016

Python 3 has been out for 9 years, but for the first 2 versions (3.0, 3.1) there were a number of serious bugs and security issues. Python 3.3 was the first release of the 3.x series to include fast decimal types, virtualenv as a core function and namespace package support.

Today, most major packages on PyPi that support “Python 3”, like requests support >3.3. The early adopters that tried Python 3 between 2008 and 2012, may have walked away with the perception that it isn’t ready. It’s not possible to set first impressions twice.

My biggest ask for 4, is that 4.0 is a major functioning release, not an experimental release.

3. Static type hinting

Anyone following the Mypy project will have seen the BDFL’s involvement and endorsement, but Mypy is a optional static type hinter for Python.

Mypy aims to combine the benefits of dynamic (or “duck”) typing and static typing.

def fib(n: int) -> Iterator[int]:a, b = 0, 1while a < n:yield aa, b = b, a+b

I would like to see this in Python 4.0, because with more and more data being consumed from REST-ful services in JSON, libraries like schema can be hugely useful in type-checking inputs.

4. A GPU story for multiprocessing

Using PyOpenCL and the multiprocessing library in 3.6 (and below) you can leverage the power of GPU processing for highly parallel computation. For Python to cement its position as the data science, machine learning King, native support for GPU parallel processing would be awesome.

Check out NumbaPro, which uses a seperate JIT engine for compilation to parallel-native threading but it’s specific to NumPy. Along with the PEP523 (JIT) support, a native compilation module could use CPython to have parallel execution in GPUs, of of the box.

5. More community contributions

Ok, I said 4 but this isn’t really a feature. In 4.x I would love to see more and broader ranging support and contributions from the community. With CPython now being on GitHub, that can mean 1 of 2 things, the community argues about features on the issue tracker (see other core language projects) or, it means that more people raise pull-requests, fix bugs and improve Python platform support.

Is that it?

I think every major/language project has a “change hump”, .NET was 1.1 to 2. PHP was 5 to 7, Perl was 5 to 6.

AngularJS 2?

Once they get over this change hump, the community can settle down, accept minor losses in backward compatibility in the name of innovation and plan for change. If the community diverges, it typically tolls the end of the project until something better comes along.

Python 4 doesn’t have to have the same huge number of breaking changes that 3 did, but those changes were needed to take Python forward into the future and now we can talk about fun things in 4 instead of still discussing string types.

What about?

Ternary operators? Like ?? in C# 6.0. Python has x if y else z as per PEP-308, not likely to have a specific operator.

Like my post? Please click the 💚 below. Also, feel free to comment with your own ideas.