
Hello, On Sun, 7 Feb 2021 19:09:14 +1100 Chris Angelico <rosuav@gmail.com> wrote:
On Sun, Feb 7, 2021 at 6:25 PM Paul Sokolovsky <pmiscml@gmail.com> wrote:
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").
But future directives are not for things that aren't fully developed yet. What gives people this idea?
For example, Python 2 code can say "from __future__ import print_function" or "division". Was the print function in a provisional state, with incompatible changes coming? No.
So, you're saying that, by the benevolence of divine providence, most (can you truly vouch for "all" and provide evidence?) features so far added to __future__ never were changed (enough). From that, you derive the conclusion that only things that can never change can be added to __future__. (You can even point to a yellowish paper where something like that is written). But that vision doesn't much correspond to reality. The world is dynamic and ever-changing. It's good luck that simple print() function never changed beyond its original definition and "/" for ints wasn't cast back to return ints. But pattern matching is much more complex than that, and knowing that there were definitely bugfixes for both print() and "/", we can estimate that pattern matching will need only more, including some externally-visible fixes. So, for as long as there was (and is!) "from __future__ import with_statement", there can also be "from __future__ import match_statement".
Was the division operator redefined? No. The directives cause compilation changes (removing a keyword, using a different division operator) that were backward incompatible *at launch* but they haven't changed since. In fact, part of the promise of __future__ is that it WILL remain compatible - you can write "from __future__ import nested_scopes" in a modern Python script, and the behaviour will be exactly correct.
All that would point that we need something like "from __experimental__ import ...". But I don't go that far. I think that existing __future__ is good enough for the purpose.
If you want a directive to put at the top of a script that says that new features are being used, I'd suggest something like this:
#!/usr/bin/env python3.9
or whatever version you require.
That doesn't say that this particular module uses experimental pattern matching feature. It also has a side effect of pinning a script to a particular executable, which may not yet exist on some users' systems, or already not exists on other users' systems.
ChrisA
-- Best regards, Paul mailto:pmiscml@gmail.com