New PEP: The directive statement

[Martin von Loewis]

"Tim Peters" <tim.one at home.com> writes:

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

I'd question this use of the information. It has yet to be written,
but I hope it won't operate in automatic "nuke all" mode. E.g. when
case insensitivity is the default in Python 2.5, Python 2.3 will still
be around (say). So the author of some package may want to nuke the
nested_scope directives, since nobody uses Python 2.1 anymore, but
would leave the case_insensitive directives.

In short, I hope that the program would have a dry-run mode, where it
reports all directives it finds, and a nuking mode, where it is given
a list of directives that it will remove.

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

That sounds like a legitimite use, but I have my problems
understanding it. Are you relying on nested scopes in your code? If
so, why do put the assert statement there? Or does your code give a
warning and you want to shut it up using the future import? In that
case, wouldn't it be better to use the warning framework?

> 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

Why are you checking the mandatory release here? Doesn't amodule have
a future import in it?

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

People routinely use sys.*version* for that; I'm really curious
whether they'd prefer to investigate other variables instead.

Regards,
Martin