Am I being fooled ? I guess yes That’s the worst idea I ever heard. Python is supposed to be easy to use, don’t change it into Rust !
On Mon 1 Apr 2019 at 22:06, Jelle Zijlstra <[email protected]> wrote: > > > El lun., 1 abr. 2019 a las 7:28, Antoine Pietri (< > [email protected]>) escribió: > >> 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. >> > 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. > > 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: > - int + float (and generally any mixed operation between ints and floats) > should throw a TypeError > - len() should return a float > - list.__getitem__ should only accepts ints, not floats > - integer overflow should use two's complement wraparound instead of > infinite precision > > >> - 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 >> _______________________________________________ >> Python-ideas mailing list >> [email protected] >> https://mail.python.org/mailman/listinfo/python-ideas >> Code of Conduct: http://python.org/psf/codeofconduct/ >> > _______________________________________________ > Python-ideas mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ >
_______________________________________________ Python-ideas mailing list [email protected] https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
