[Jeremy]
> If a script has
> from __future__ import nested_scopes
> and is run by Python 2.2, should the interpreter complain?
No:
Else MandatoryRelease records when the feature became part of the
language; in releases at or after that, modules no longer need
from __future__ import FeatureName
to use the feature in question, but may continue to use such imports.
[David Ascher]
> Although there could be a warning (off by default) in 2.3 or whenever
> to let users know that the code is no longer needed. People tend to
> cut & paste and reuse code from others, without always knowing why.
> Noops should be culled from code as a general rule =).
The syntax of future statments was designed so that a trival sed script can
find them reliably. Heck, even ActivePerl could find them <wink>. They
have to begin in the first column, and have to start with "from __future__".
I expect that many people will *want* to keep obsolete future stmts in
forever, as a protection against trying to run code under earlier versions
of the interpreter -- the semantics were designed so that such back-porting
always complains (if to a pre-future version of Python, because the "from
__future__ import ..." stmt raises a runtime ImportError due to the absence
of module __future__.py (which has a reserved name); or if to a post-future
pre-feature version, a compile-time error).
People insanely <wink> concerned about this can query the MandatoryRelease
fields of the future-features they import, raising an exception of their
choosing if the MandatoryRelease is <= sys.version_info; e.g.,
from __future__ import division
assert division.getMandatoryRelease() > sys.version_info
That will complain the first time they run it under a Python where new
division is "the rule".
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4