[Python-ideas] Backward-incompatible changes for Python 4

[Adrien Ricocotam]

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 <jelle.zijlstra at gmail.com> wrote:

>
>
> El lun., 1 abr. 2019 a las 7:28, Antoine Pietri (<
> antoine.pietri1 at gmail.com>) 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
>> Python-ideas at python.org
>> https://mail.python.org/mailman/listinfo/python-ideas
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20190401/0cafeb05/attachment.html>