What to Expect from Python 4.0? Insights from a CPython Core Developer

Python 4.0: What Are the Expectations?

Despite many developers hoping their favorite language stays on top, recent search‑engine data shows Python surpassing both Java and PHP combined. The author shares an article by Nick Coghlan, a CPython core developer, to discuss what Python 4.0 might bring.

The expectation is that Python 4.0 will be merely “the version after Python 3.9,” with no deep language redesign or breaking backward‑compatibility issues. It should behave like the transition from Python 3.3 to 3.4, and the binary interface introduced by PEP 384 is hoped to remain stable.

Given the current release cadence of roughly every 18 months, a Python 4.0 could appear around 2023, potentially skipping a separate 3.10 release.

How Python Will Continue to Evolve

The PEP process will stay unchanged, continuing to propose backward‑compatible changes and adding new modules (e.g., asyncio) and language features (e.g., yield from) to expand what Python applications can do.

Python 3 will keep outpacing Python 2 in functionality; even Python 2 users can obtain comparable features via third‑party packages or back‑ports, though they will never fully match Python 3’s capabilities.

Competing implementations such as PyPy (with JIT compilation and software transactional memory) and the scientific‑data community’s work on array‑oriented programming will keep pushing Python’s performance on modern CPUs and GPUs.

Integration with other runtimes like the JVM and CLR is expected to improve, especially in educational contexts, making Python an increasingly popular embedded scripting language.

For changes that cannot remain backward compatible, PEP 387 provides a deprecation path that has been used successfully in the Python 2 series and remains applicable today.

The Python package repository, a joint effort of the CPython core team and the Python Packaging Authority, now bundles pip with Python 3.4+, simplifying module installation.

The “temporary API” concept introduced by PEP 411 allows a transition period before a stable API is guaranteed.

Many legacy behaviors have been resolved during the Python 3 transition, and new language and standard‑library features now have stricter requirements.

Single‑source Python 2/3 libraries are widely adopted, encouraging the use of deprecation documentation so existing code can continue to work without warnings.

Unicode and Backward Compatibility

Python 3’s shift to Unicode strings and a distinct bytes type was the most disruptive, non‑compatible change, but it greatly simplified text handling across platforms.

The article traces the evolution of Unicode support from early ASCII to modern Unicode code points, highlighting why the default‑Unicode approach was necessary for robust text processing.

The author believes future language changes will avoid the level of breakage seen in the Python 3 transition, relying on disciplined change‑management processes to reject proposals that would impose unacceptable costs on the community and core developers.

Original article: https://opensource.com/life/14/9/why-python-4-wont-be-python-3