Other situations like this (was RE: [Python-Dev] Nested scopes resolution -- you can breathe again!)

[Tim Peters]

>> Ditto for
>>
>> python -i some_script.py

[Samuele Pedroni]
> This make sense but I guess people will ask for a way to disable
> the feature after a while in the session, even trickier.

The purpose is to let interested people use new features "early", not to let
people jerk off.  That is, they can ask all they want <wink>.

>> [Tim sez exec and execfile should inherit the module's setting]

> I disagree, although this reduces the number of places where one
> has to delete from __future__ import  when _future_ is here,

That isn't the intent.  The intent is that a module containing

    from __future__ import f

is announcing it *wants* future semantics for f.  Therefore the module
should act, in *all* respects (incl. exec and execfile), as if the release
were already the future one in which f is no longer optional.  If exec, eval
or execfile continue to act like the older release, the module isn't getting
the semantics it specifically asked for, and the user isn't getting a
correct test of future functionality.

> for some uses of execfile the original program has just little
> control over what is in the executed file I guess,

Then they may have deeper problems than this gimmick can address, but
they're not going to find out whether the files they're execfile'ing *will*
have a problem in the future unless the module asking for future semantics
gets future semantics.

> better having people being explicit there about what they want.

They already are being explicit:  they get future semantics when and only
when they include a from__future__ thingie.

> And this way we don't have to invent a way for forcing disabling
> the feature (at least not because of the inherited
> default problems).

There is *no* intent here that a single module be able to pick and choose
different behaviors in different contexts.  The purpose is to allow early
testing and development of code to ensure it will work correctly in a future
release.  That's all.

> ...
> Or we need an even more complicated mechanismus? like your
> proposed import not.

I doubt core Python will ever support "moving back in time" (a heavily
conditionalized code base is much harder to maintain -- ask Jeremy how much
fun he's having trying to make this optional *now*).  May (or may not) be an
interesting idea for repackagers to consider, though.