On Mon, Apr 1, 2019, 10:28 Antoine Pietri <antoine.pietri1@gmail.com> wrote:
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,
We should probably just get rid of floats entirely and use decimals internally. Floats just have too much unexpected behavior. Anyone wanting real IEEE floats can still use numpy float scalars. Another thing is that a lot of people in numeric computing are used to open-ended indices starting at 1. I would like to see the starting index and whether an index is open-ended or closed-ended configurable on a per-module basis and/or with a context manager. Currently there is no empty set literal. This is a hold-over from when there were no sets. Now would be a good opportunity to add one. I suggest {} become an empty set and {:} be an empty dict.