New PEP: The directive statement

[Tim Peters]

[Martin von Loewis]
> ...
> I have my problems with that part of PEP 236 also. While it is
> certainly possible to provide the release when a feature was first
> released, it is not possible to give an accurate answer to the
> question when it will become mandatory. The intent to make it
> mandatory in the future should go into the documentation, IMO.

If the mandatory release is greater than the release you're running under,
it's certain that the feature in question is not yet "the rule".

If the mandatory release is less than or equal to the release you're running
under, it's certain that the feature in question *is* "the rule".

Those are the only two interesting questions at runtime, and they're answered
precisely.  It doesn't matter if the first prediction is wrong, because
__future__.py ships *with* the compiler.  This gives the pair of them a
consistent view of what the truth is for that version of the compiler; if the
prediction is wrong, no problem, it's updated in the next release and then
*that* gets a self-consistent view of the world too.  The two questions above
are always answered correctly for the version you're running under.

Of course the docs for a release should explain the state of features too,
but info in the docs isn't accessible to programs.

> Furthermore, what is the use of that information to a program?

Primarily, it's what makes it possible to write a simple tool that nukes
obsolete future statements.  The tool can't know whether a future_statement
is obsolete wrt the release it's being run under unless it has a repository
of release info shipped with that release, and in program-accessible form
(see above).  __future__.py makes that not just possible, but *easy*.

In another vein, in my own code I don't hesitate to use new features, and
couldn't care less if rare incompatible changes require me to rewrite some
code.  So I'll likely use future_statements much more than most people.  I
already have code that does

    from __future__ import nested_scopes
    import sys
    assert nested_scopes.getMandatoryRelease() > sys.version_info

This will assert-fail as soon as I run it under a release where nested_scopes
is the rule, and at that point I'll simply delete the future_statement and
move on.

Code like this also works fine:

import __future__
if __future__.nested_scopes.getMandatoryRelease() > sys.version_info:
    import old_version_of_module as amodule
else:
    import amodule

I don't know that I'll have an acute need for that wrt nested_scopes
specifically (neither do I know that I won't), but there is an endless
sequence of proposals for, e.g., changing Python in incompatible ways that
would (supposedly) allow it to run faster.  In that case I may very well have
an acute need to ship one version of my source that exploits the new
semantics but falls back to an older & slower module if the compiler it's
running under can't play along.

Etc.  Introspective features *always* find good uses.  I'm sure the Python
community will think of others that haven't even dimly occurred to me yet.
That's why it's there:  not because someone already thought far enough ahead
to ask for it, but because it's thoroughly predictable that somebody *will*.

when-you-don't-have-a-hammer-everything-looks-like-a-brick-wall-ly y'rs
    - tim