
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. 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. 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. ChrisA