
On Sun, Feb 7, 2021 at 8:14 AM Luciano Ramalho <luciano@ramalho.org> wrote:
On Sat, Feb 6, 2021 at 6:04 PM Steve Holden <steve@holdenweb.com> wrote:
My suggestion that it be introduced via __future__ due to its contentious nature met immediate resistance. No point going down that road.
This is really unfortunate.
I agree this is a huge language change and it should only be approved with some mechanism requiring explicit opt-in (such as __future__ import)
How will a __future__ import help here? Are there syntactic or behavioural changes that would be worth applying to some modules and not others? The entire point of a __future__ import is to maintain backward compatibility by, for instance, not introducing a keyword, unless it is explicitly requested. What advantage would there be here?
AND it should be documented as provisional for several releases, like asyncio was (and remember: the asyncio API had lots of breaking changes and prompted the addition of the async/await keywords, a great improvement that forced the renaming of the very fundamental async function from the original API).
Documenting as "provisional" means that its behaviour can change. Again, how will that make things easier here? ChrisA