On Mon, Apr 1, 2019, 10:28 Antoine Pietri <antoine.piet...@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.
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
