[Python-Dev] Should we move to replace re with regex?

[Steven D'Aprano]

Dan Stromberg wrote:
> On Sat, Aug 27, 2011 at 9:53 AM, Brian Curtin <brian.curtin at gmail.com>wrote:
> 
>> On Sat, Aug 27, 2011 at 11:48, Dan Stromberg <drsalists at gmail.com> wrote:
>>> No, this was not the intent of __future__. The intent is that a
>>>> feature is desirable but also backwards incompatible (e.g. introduces
>>>> a new keyword) so that for 1 (sometimes more) releases we require the
>>>> users to use the __future__ import.
>>>>
>>>> There was never any intent to use __future__ for experimental
>>>> features. If we want that maybe we could have from __experimental__
>>>> import <whatever>.
>>>>
>>>> OK.  So what -is- the purpose of from __future__ import?
>> It's in the first paragraph.
>>
> 
> I disagree.  The first paragraph says this has something to do with new
> keywords.  It doesn't appear to say what we expect users to -do- with it.
> Both are important.

Have you read the PEP? I found it very helpful.

http://www.python.org/dev/peps/pep-0236/

The motivation given in the first paragraph is pretty clear to me: 
__future__ is machinery added to Python to aid the transition when a 
backwards incompatible change is made.

Perhaps it needs a note stating explicitly that it is not for trying out 
new features which may or may not be added at a later date. That may 
help prevent confusion in the, er, future.


[...]
> And if people do complain, what are python-dev's options?

The PEP includes a question very similar to that:


   Q: Going back to the nested_scopes example, what if release 2.2
      comes along and I still haven't changed my code?  How can I keep
      the 2.1 behavior then?

   A: By continuing to use 2.1, and not moving to 2.2 until you do
      change your code.  The purpose of future_statement is to make
      life easier for people who keep current with the latest release
      in a timely fashion.  We don't hate you if you don't, but your
      problems are much harder to solve, and somebody with those
      problems will need to write a PEP addressing them.
      future_statement is aimed at a different audience.


To me, it's quite clear: once a feature change hits __future__, it is 
already part of the language. It may be an optional part for at least 
one release, but removing it again will require the same deprecation 
process as removing any other language feature (see PEP 5 for more details).



-- 
Steven