Hello, On Sun, 7 Feb 2021 13:21:08 +1100 Steven D'Aprano <st...@pearwood.info> wrote:
> On Sat, Feb 06, 2021 at 10:00:16PM -0300, Luciano Ramalho wrote: > > On Sat, Feb 6, 2021 at 6:23 PM Chris Angelico <ros...@gmail.com> > > wrote: > > > How will a __future__ import help here? Are there syntactic or > > > behavioural changes that would be worth applying to some modules > > > and not others? The entire point of a __future__ import is to > > > maintain backward compatibility by, for instance, not introducing > > > a keyword, unless it is explicitly requested. What advantage > > > would there be here? > > > > The fact that a __future__ import only affects a single module is > > precisely the point: we may not want the feature in our code > > initially, but maybe we don't mind using third-party libraries that > > use it. > > It's not compulsory to use syntactic features if your code doesn't > need them. I have many scripts and modules that don't use while > loops, or try...except blocks, or with statements. > > A feature doesn't need to be a `__future__` import for you to just > not use it. Right, and the talk is about the opposite - early adopters of PEP634-style pattern matching should mark the modules in which they *use* PEP-634-style pattern matching, so it will be easy in the future to spot such modules, if we get updated pattern matching style. > > A __future__ import would make clear to all that the feature is > > experimental, > > It certainly would not. There is nothing experimental about > `__future__` imports. I cannot think of a single example of an > experimental feature added via the future mechanism: > > https://docs.python.org/3/library/__future__.html All features added via __future__ were new, and thus experimental. For example, they contained long trail of bugs and issues, which were haunting their users for a long time, but at least the users knew what to expect, seeing the __future__ import. Sadly, the converse is not true - not all new and experimental features were added using it, which caused users additional frustration in dealing with them. The proposal is to mend that sad practice, and consistently use __future__ imports for experimental things (e.g. those which are "good enough to go in, but definitely not fully ready, from the perspective of 5-year timeframe of the language evolution"). A complimentary proposal is for "CPython core developers" to redefine in their minds what __future__ import means, to look at it from PoV of the end users, not from PoV of a Python language lawyer, throwing links to formal docs which miss updates to correspond to the actual programming language/software project reality. -- 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/NYWURNPR7YPWZIRNP4CBWNFQ2HPSHCW5/ Code of Conduct: http://python.org/psf/codeofconduct/
