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