Dan Stromberg wrote:
On Sat, Aug 27, 2011 at 9:53 AM, Brian Curtin <brian.cur...@gmail.com>wrote:
On Sat, Aug 27, 2011 at 11:48, Dan Stromberg <drsali...@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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
