`~/.pythonrc' `from __future__ import'

[François Pinard]

[Tim Peters]

> > How should I proceed to activate this [future division] ]option once
> > and for all for interactive applications?

> You can write an alias to start interactive sessions by passing -Qnew to
> Python.

I've heard about this undocumented feature indeed, and hoped to go without
resorting to it.  Moreover, this option only works for division, it does
not apparently activate generators, for instance.  I would rather have
all future features available all the time when I write interactively,
yet I guess why some people would prefer not.

> The PYTHONSTARTUP file acts as if executed via the execfile() function.
> That implies it can leave behind visible bindings in the caller's
> globals, and have other non-local side effects (such as importing other
> modules), but like all exec and eval gimmicks, it executes in a code
> block distinct from its caller's.  It's a separately compiled unit,
> and a future statement's useful effects are limited to the compilation
> unit in which it appears.  In effect, that means it only "works" for
> the code in the startup file itself.

I understand and, Tim, I thank you for your patient explanations, However,
it wonder if this is all fully right.  The actual documentation and the
PEP say that one could `import __future__' explicitly, so to check at
run time what features are currently available in the running Python.
Besides its compile-time effect, `from __future__ import division' (say)
dynamically defines `division' at run-time in the global space, at least
when done from the startup file, but this is no strong clue about if the
feature has been activated or not (at least when the Python version lies
between the introduction version and, excluded, the mandatory version).

Would it mean that one has no other choice than "benchmark" the feature at
run-time, the ugly way, to know whether it is active or not?  The current
intent is to let an `from __future__ import FEATURE' generate an error if
the FEATURE is wanted in a module, but not available in the current Python.

Suppose, for example, that I write a module in which some function makes
good use of some future feature (it could be the `yield, statement),
but I want to provide an alternate implementation of that function which
is less interesting (because it gets much complex and slower) in case the
feature is not available.  Since I cannot except out of the `from __future__
import' statement, for reasons I understand, I do not see how I take good
advantage of available future features, in a program meant to be portable
between versions.  Maybe the future statement is rougher than I expected?

-- 
François Pinard   http://www.iro.umontreal.ca/~pinard