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 . Exciting times for the Python community. GitHub 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 , a and an . Compare that with , which is just a language. It has standard library, and the Google v8 engine does the along with many other options. language standard library execution engine JavaScript no execution, Here’s my laundry list, it consists of mainly changes to the 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. execution engine 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. is an implementation of Python with its own JIT, is an implementation of Python using as a JIT compiler. Each of these compromises on functionality (or correctness of the language) over speed. PyPy Pyston LLVM 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 3, 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. PEP-52 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 types, virtualenv as a core function and namespace package support. decimal Today, most major packages on PyPi that support “Python 3”, like 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 requests 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 static type hinter for Python. optional 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 can be hugely useful in type-checking inputs. schema 4. A GPU story for multiprocessing Using and the 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. PyOpenCL multiprocessing Check out , 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. NumbaPro 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 “ ”, .NET was 1.1 to 2. , . change hump 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 as per , not likely to have a specific operator. ?? x if y else z PEP-308 Like my post? Please click the 💚 below. Also, feel free to comment with your own ideas.