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.