Hello, On Sun, 7 Feb 2021 20:02:48 +1100 Chris Angelico <rosuav@gmail.com> wrote:
On Sun, Feb 7, 2021 at 7:54 PM Paul Sokolovsky <pmiscml@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:pmiscml@gmail.com