
Hello, On Sat, 6 Feb 2021 23:05:19 -0800 Guido van Rossum <guido@python.org> wrote:
That’s incorrect. __future__ is used when something new and *incompatible* is being introduced (and the old way is being deprecated at the same time). For experimental modules we use the term provisional. There’s no official term for experimental syntax (since we’ve never had any), but we could call that provisional as well.
Thanks, I'm aware. Thus the nature of my proposal is: redefine (extend) cases when __future__ is used, e.g. when a PEP itself says something like "There're many more could be done, but good things come in pieces, and wise men know when to stand back and relax before continuing. So, see ya next time!" My argument that such usage of __future__ would correspond more to the expectations of the Python end users ("feature is not fully developed yet, and there could be small incompatible changes going forward").
On Sat, Feb 6, 2021 at 22:44 Paul Sokolovsky <pmiscml@gmail.com> wrote:
Hello,
On Sun, 7 Feb 2021 01:17:31 +0000 Paul Bryan <pbryan@anode.ca> wrote:
On Sat, 2021-02-06 at 22:00 -0300, Luciano Ramalho wrote:
A __future__ import would make clear to all that the feature is experimental, and maybe there could be __future__ imports for different parts of the proposal.
That's not my understanding. My understanding is __future__ is meant for features that potentially break existing code, and allows code to opt-in in a release earlier than when it will behave that way by default. From what I can tell with this PEP, existing code can continue working the way it always has.
And that's not understanding of the majority of Python users. For majority of "mere" users, __future__ is a marker that something new (and thus experimental, for these categories are again equivalent for most users) is being used in the current module.
So, "from __future__ import with_statement" didn't mean to people "you can't use variable named 'with' in this module" (because majority of people never used such a variable name, so didn't care), but instead meant "this module uses the new 'with' statement, keep your ear sharp".
And the current excuses go along the lines of "now that we've got a parser with exponential memory usage, we can use __future__ like... umm, never".
Don't do that, keep using __future__ like it always was - to mark experimental features.
Paul
-- Best regards, Paul mailto:pmiscml@gmail.com _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@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/2O3ZSLNO... Code of Conduct: http://python.org/psf/codeofconduct/
-- --Guido (mobile)
-- Best regards, Paul mailto:pmiscml@gmail.com