Hello,
On Sun, 7 Feb 2021 20:02:48 +1100
Chris Angelico <ros...@gmail.com> wrote:
> On Sun, Feb 7, 2021 at 7:54 PM Paul Sokolovsky <pmis...@gmail.com>
> wrote:
> >
> > 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).
>
> No, I'm saying that the __future__ directive is not for the purpose of
> allowing subsequent changes. It is completely unrelated to any future
> changes, it is a matter of bringing the future *now*.
And nobody says that there will be *incompatible* changes to the
pattern matching, just that previous experience, and discussion of the
PEP622/PEP634 shows that there's a probability of that (higher than
usual).
In that regard, it may be due to warn users about what pattern matching
is - a novelty. And among mechanisms Python already has for that,
__future__ seems like the best fit (because users already treat it like
that, regardless of what format definition is).
> > 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).
>
> Uhh well, that's not quite right; everything is subject to change. But
> those changes are the domain of the subsequent proposals, not the
> __future__ directive. The statement in a Py2 program "from __future__
> import unicode_literals" was not for the purpose of permitting PEP 393
> or PEP 414, both of which changed Unicode strings in Python 3.
If everything is subject to change, then perhaps we can accept usage of
__future__ to introduce initial pattern matching implementation. But
its purpose is not to enable pattern matching per se, just to keep early
adopters in loop that it's a novel feature, subject to change.
> > 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? If there are changes to be made, then let a subsequent proposal
> make those changes.
Yes, and let's communicate the possibility that future proposals will
very likely be there (there're already, e.g. PEP642), and they may make
slight incompatible changes - by requiring early adopters to use "from
__future__ import ...".
> > 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.
>
> Maybe that would be useful, if the match statement were deemed to be
> an experimental feature. That's not the current proposal. Are you
> proposing that this be done, and if so, why?
Me - not. Someone else proposed to use __future__. I jumped on that
idea because I think it's a good compromise with both people who
say "patmatching misses some things, like merge it with them already"
and who say "there's seem to be discord, let's not merge until it's
cleared". Needless to say, user who like/want patmatching, shouldn't
feel upset about __future__ either. And it's a responsible act overall
to warn early adopters, again.
So, now let me ask you - I guess you're not against patmatching, but
seem to be concerned with __future__. Why, beyond pure
language-lawyering matters ("there's a county bill of 1873 which says
__future__ isn't used like that").
> > > 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.
> >
>
> Yes. If that's not what you want, then what IS it you want? Do you
> need a comment saying "# this code uses the match statement" or "#
> this code uses str.removeprefix" or "# this code uses positional-only
> parameters"? What is gained by such directives?
A more formal'ish "contract" between developers and users which says
"We ship you a new cool feature! But, there can be some changes going
forward yet." __future__ (among existing means) satisfies that, a
comment - no.
> I'm done arguing about this. Every time this PEP comes up, it gets yet
> another round of the same arguments and I keep getting suckered into
> answering them again. When will I learn...
Don't take that personally, the issue is developers vs endusers gap,
and the discussion happens again and again in the hope to reach minds
of the developers.
>
> 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/XE5XUGYCOHEOZAKOULR4Y47IVO2D242S/
Code of Conduct: http://python.org/psf/codeofconduct/
