[Python-Dev] Should we move to replace re with regex? (original) (raw)

Steven D'Aprano steve at pearwood.info
Sat Aug 27 21:55:52 CEST 2011

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

More information about the Python-Dev mailing list