Why Python 4.0 Won’t Be a Radical Overhaul: Insights from a Core Developer

Python 4.0 Expectations

I expect Python 4.0 to be merely “the version after Python 3.9” with no deep language changes or major backward‑compatibility breaks; it should transition as smoothly as Python 3.3 to 3.4 or Python 2.6 to 2.7. Ideally, the binary interface introduced by PEP 384 will remain stable.

Given the current release cadence of roughly every 18 months, we may see Python 4.0 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 with third‑party ports, Python 2 users cannot match Python 3’s capabilities.

Competing interpreter implementations and extensions will keep exploring enhancements, such as PyPy’s JIT compiler, software transactional memory, and array‑oriented programming in scientific and data‑analysis communities that leverage modern CPU/GPU vectorization.

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

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

Several other changes are unlikely to be deprecated in the Python 3 series, including:

Improvements to the Python package repository, driven by the CPython core team and the Python Packaging Authority, with pip bundled since Python 3.4, simplifying module installation.

The “temporary API” concept introduced by PEP 411, allowing a transition period before full backward‑compatible guarantees are provided.

Resolution of legacy behaviors accumulated during the Python 3 migration, leading to stricter requirements for new language and standard‑library features.

Broad adoption of “single‑source” Python 2/3 libraries and frameworks, encouraging the use of deprecation documentation that guides developers toward newer APIs without generating runtime warnings.

From English to All Languages

Python 3’s most disruptive, non‑backward‑compatible change was making all strings Unicode with a separate bytes() type, renaming the new string type to str. This shift, summarized in PEP 3100, was essential for cleanly separating binary data from text, simplifying application development despite blurring the line between binary and text handling.

The evolution from ASCII‑only text to a comprehensive Unicode model reflects decades of development, from the original 7‑bit ASCII (1963) to modern Unicode code points (first defined in 1996 and regularly updated).

Because this Unicode transition was the most breaking change in Python 3, future language changes are unlikely to cause similar compatibility issues; any proposal that would break compatibility will likely be rejected due to the high cost to the community and core developers.

Original source: https://opensource.com/life/14/9/why-python-4-wont-be-python-3 Author: Nick Coghlan, core developer of CPython and board member of the Python Software Foundation, author of several PEPs including PEP 343 (with‑statement) and PEP 453 (pip bundled with Python 3.4). Translator: Wan Yue, editor: Hu Weiwei