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*. > 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. > 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. > 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? > > 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? 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... ChrisA _______________________________________________ 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/XJUTUE27XA5RH4EO2IYLJHUYVDNVKCGJ/ Code of Conduct: http://python.org/psf/codeofconduct/
