<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">El lun., 1 abr. 2019 a las 7:28, Antoine Pietri (<<a href="mailto:antoine.pietri1@gmail.com">antoine.pietri1@gmail.com</a>>) escribió:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);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></blockquote><div>More broadly, one of the best changes in Python 3 was the sanitization of the string/unicode logic: in Python 2 str and unicode were mostly-but-not-always interchangeable, but not always, and that led to a lot of hard to debug errors. Python 3 fixed this by separating the two more cleanly. Python 4 has the opportunity to do something similar to separate out another pair of easily confused types: int and float.</div><div><br></div><div>Broadly speaking, we should use float for human-understandable numbers, and int for things that map directly to memory offsets in the computer, and we should avoid mixing them. This suggests the following changes:</div><div>- int + float (and generally any mixed operation between ints and floats) should throw a TypeError</div><div>- len() should return a float</div><div>- list.__getitem__ should only accepts ints, not floats</div><div>- integer overflow should use two's complement wraparound instead of infinite precision</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
- 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>
<br>
-- <br>
Antoine Pietri<br>
_______________________________________________<br>
Python-ideas mailing list<br>
<a href="mailto:Python-ideas@python.org" target="_blank">Python-ideas@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-ideas" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/python-ideas</a><br>
Code of Conduct: <a href="http://python.org/psf/codeofconduct/" rel="noreferrer" target="_blank">http://python.org/psf/codeofconduct/</a><br>
</blockquote></div></div>