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").

> 
> On Sat, Feb 6, 2021 at 22:44 Paul Sokolovsky <pmis...@gmail.com>
> wrote:
> 
> > Hello,
> >
> > On Sun, 7 Feb 2021 01:17:31 +0000
> > Paul Bryan <pbr...@anode.ca> wrote:
> >  
> > > On Sat, 2021-02-06 at 22:00 -0300, Luciano Ramalho wrote:
> > >  
> > > > A __future__ import would make clear to all that the feature is
> > > > experimental, and maybe there could be __future__ imports for
> > > > different parts of the proposal.  
> > >
> > > That's not my understanding. My understanding is __future__ is
> > > meant for  features that potentially break existing code, and
> > > allows code to opt-in in a release earlier than when it will
> > > behave that way by default. From what I can tell with this PEP,
> > > existing code can continue working the way it always has.  
> >
> > And that's not understanding of the majority of Python users. For
> > majority of "mere" users, __future__ is a marker that something new
> > (and thus experimental, for these categories are again equivalent
> > for most users) is being used in the current module.
> >
> > So, "from __future__ import with_statement" didn't mean to people
> > "you can't use variable named 'with' in this module" (because
> > majority of people never used such a variable name, so didn't
> > care), but instead meant "this module uses the new 'with'
> > statement, keep your ear sharp".
> >
> > And the current excuses go along the lines of "now that we've got a
> > parser with exponential memory usage, we can use __future__ like...
> > umm, never".
> >
> > Don't do that, keep using __future__ like it always was - to mark
> > experimental features.
> >
> >  
> > >
> > > Paul
> > >  
> >
> >
> > --
> > 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/2O3ZSLNOKZABQD4FIX7KAGM6JSF7JFYC/
> > Code of Conduct: http://python.org/psf/codeofconduct/
> >  
> -- 
> --Guido (mobile)



-- 
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/BBXIQE6LKQQQOTWR3SO5K5OLJIOIQ33E/
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to