While the switch to Python 3 did an excellent job in removing some of the old inconsistencies we had in the language, pretty much everyone agrees that some other backwards-incompatible changes could be made to remove some old warts and bring even more consistency to Python. Since Python 4 is getting closer and closer, I think it’s time to finally discuss some of the most obvious changes we should do for Python 4. Here is the list I compiled: - The / operator returns floats, which loses information when both of the operands are integer. In Python 4, “1 / 2” should return a decimal.Decimal. To ease the transition, we propose to add a new “from __future__ import decimal_division” in Python 3.9 to enable this behavior. - As most of the Python ecosystem is moving towards async, some of the old I/O-blocking APIs should be progressively migrated to an async by default model. The most obvious candidate to start this transition is the print function, which blocks on the I/O of flushes. We propose to make “print” an async coroutine. In Python 3.9, this feature could be optionally enabled with “from __future__ import print_coroutine”. - To ease compatibility with the Windows API, the PyUnicode* objects should be internally represented as an array of uint16_t, as it would avoid the conversion overhead from UCS. CPython migration details are left as an exercise for the developer. We think more changes are obviously warranted (e.g adding a new string formatting module, changing the semantic of the import system, using := in with statements...), but these changes will need specific threads of their own. So, can you think of other backward-incompatible changes that should be done in Python 4? Don't hesitate to add your own ideas :-) Thanks, -- Antoine Pietri