[Python-Dev] future and present

[Tim Peters]

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