On Sun, Feb 7, 2021 at 8:14 AM Luciano Ramalho <luci...@ramalho.org> wrote: > > On Sat, Feb 6, 2021 at 6:04 PM Steve Holden <st...@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 _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/VC3IV5XDTMKYZME75WQAHAEAWGOYTOBI/ Code of Conduct: http://python.org/psf/codeofconduct/
