# Scan the QR code to sign up for the source creation #
When making backward incompatible changes python-ideas Now and then, the novice will come up with “Python 4000” The concept of , These changes do not give the current legal Python3 The code provides a clear migration path . After all , We allow Python 3.0 Make this change , So why don't we allow it to be used for Python 4.0 Well ？
I've heard so many questions now （ Including more focused wording “ You've made a big backward compatibility breakthrough , How do I know you won't do it again ？”）, I think I'll record my answers here , So I can bring people back in the future .
Right now Python 4.0 What's your prediction ？
My prediction now is Python 4.0 nothing but “Python 3.9 Later version ”. this is it . There is no significant change in language , There is no major backward compatibility breakthrough —— from Python 3.9 To 4.0 It should be like from Python 3.3 To 3.4（ Or from 2.6 To 2.7）. I even predict stable application binary interfaces （Application Binary Interface）（ stay PEP 384 It's the same as the first definition in ） Will be preserved on this transitional boundary .
According to the speed of the current language features （ About every 18 Months ）, It means that we may be in 2023 Some time in the year I saw Python 4.0, Instead of seeing Python 3.10.
that Python How will it continue to develop ？
First ,Python There is no change in the enhancement proposal process —— Backward compatible changes are still proposed , New modules have been added （ Such as asyncio） And language functions （ Such as yield from） To enhance Python Functions available to applications . as time goes on ,Python 3 Continue to be ahead of... In terms of functionality provided by default Python 2, Even if Python 2 Users can use the third-party module or Python 3 Back end access to the same functionality .
The competition will continue to explore enhancements in interpreter implementation and extension Python In different ways , Include PyPy Yes JIT Compiler generation and software transaction storage , And making the most of modern technology in the scientific and data analysis community CPU and GPU The exploration of array oriented programming with vectorization computing capability provided . And other virtual machine runtimes （ Such as JVM and CLR） The integration of is also expected to improve over time , Especially when Python Progress in education may make it more popular as an embedded scripting language in the runtime environment of more applications .
For backward incompatible changes ,PEP 387 Provided in Python 2 A reasonable overview of the methods used for many years in the series , And it still applies today ： If a function is identified as too problematic , Then it may be discarded and eventually removed .
However , Many other changes have been made to the development and release process , This makes it possible to Python 3 These discards are unlikely to be needed in the series .
just as CPython Core development team and Python Packaging Authority Collaboration between , And will be pip The installation program and Python 3.4+ What is revealed by the binding of , The more attention is paid to Python Package Index, Before they are stable enough to adapt to relatively slow language update cycles , Reduces the pressure to add modules to the standard library .
“ temporary API” Concept （ stay PEP 411 Introduction in ） Before the standard backward compatibility guarantee is provided , For libraries and API application “ Stable ” period .
A lot of accumulated legacy behavior is really Python 3 The transition was cleared , and Python Compared with the new function requirements of standard library Python 1.x and Python 2.x The period is much more strict .
“ Single source ”Python 2/3 Extensive development of libraries and frameworks is strongly encouraged in Python 3 Use in “ Document discard ”, Even if the function is updated , The preferred alternative is to replace . In these cases , Discard notification will be placed in the document , Suggest the preferred method for new code , But don't add programming discard warning . This allows existing code to （ Including support Python 2 and Python 3 Code for ） remain unchanged （ At the expense of new users , You may need to learn a little bit about the task of maintaining an existing code base ）.
from （ Most of them are ） English to all written languages
It is also worth noting that ,Python 3 It's not expected to be as destructive as it used to be . stay Python 3 Of all the backward incompatible changes associated with , Many serious migration barriers can be placed in PEP 3100 On a small basis of ：
PEP 3100 yes Python 3 The base of change , It is considered uncontroversial , A separate PEP There is no need to . The reason this particular change is considered undisputed is because we use Python 2 Experience shows that Web and GUI The author of the framework is right ： Deal with it intelligently as an application developer Unicode It means ensuring that all text data is converted from binary to as close to the system boundary as possible , Follow the text processing , And then back to binary for output purposes .
Unfortunately ,Python 2 Developers are not encouraged to write in this way - It greatly blurs the line between binary and text data , And make it difficult for developers to separate the two , Not to mention in the code . therefore ,Web and GUI Frame writers have to tell them Python 2 user “ Always use a Unicode Rich text . If you don't do that , You may be dealing with Unicode It's hard to deal with the obscure input bug”.
Python 3 Is different ： It's in “ Binary fields ” and “ Text domain ” There's more isolation between them , Make it easier to write normal application code , At the same time, it makes it more difficult to write code in systems with unclear binary and text boundaries . I've covered it in more detail elsewhere Python 2 and Python 3 Actual changes between text models .
Python Yes Unicode The revolution supported is in the context of a larger migration of computational text operations , From English only ASCII（1963 It's officially defined in ）, To “ binary data + Code statement ” Model of （ Include C/POSIX locale And in 20 It was introduced in the late 1980s Windows Code page system ） And from the beginning 16 position Unicode Standard Version （1991 Released in ） To a relatively comprehensive modern Unicode Code point system （1996 The definition of , Every few years a release containing new major updates ）.
Why mention this ？ Because this switch to “ By default Unicode” It's right Python3 The most destructive of backward incompatibilities in , Unlike other changes （ They are more relevant to the language itself ）, It's a small part of the broader change in the way text data is represented and manipulated in a larger industry . With Python 3 Transformation clears up language specific problems , And Python Compared to earlier versions , The entry threshold of new language functions is much higher , And what's going on from “ Binary data with encoding ” Switch to... For text modeling Unicode They're all bigger than any other industry , I don't see any need Python 3 Changes to style backward compatibility interrupt and parallel support .
contrary , I hope we can adapt to any future language evolution in the normal change management process , Any proposal that cannot be dealt with in this way will be rejected , Because it will bring unacceptably high cost to the community and the core development team .
Nick Coghlan - Nick yes CPython The core developers , It's also Python Software Foundation Members of the board of directors of . He's a few recognized Python The author or co-author of the enhancement proposal （ Include PEP 343, It's in Python 2.5 Added in with Statement and context manager ,PEP 453 I see the relationship with you Python 3.4 Tied together pip Erection sequence ）, And accepted some Guido van Rossum representative BDFL Representative PEP.