Hello,
On Sun, 7 Feb 2021 19:09:14 +1100
Chris Angelico <ros...@gmail.com> wrote:
> On Sun, Feb 7, 2021 at 6:25 PM Paul Sokolovsky <pmis...@gmail.com>
> wrote:
> >
> > Hello,
> >
> > On Sat, 6 Feb 2021 23:05:19 -0800
> > Guido van Rossum <gu...@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:pmis...@gmail.com
_______________________________________________
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/UCCTGZJ6TCICLX77YXPY7XIIK6PC3STR/
Code of Conduct: http://python.org/psf/codeofconduct/
