[IPython-dev] Where should __future__ statements affect the interactive environment.

Fernando Perez fperez.net at gmail.com
Mon Apr 23 00:20:49 EDT 2012

Hi Thomas,

thanks for bringing this up...  I just haven't been able to keep up :)

On Wed, Apr 11, 2012 at 7:48 AM, Thomas Kluyver <takowl at gmail.com> wrote:
> Pierre Haessig has spotted inconsistencies in the effect of a
> statement like 'from __future__ import division'. If it's in a startup
> file with a .py extension, it's local to that file; if the same file
> has a .ipy extension, it affects the interactive environment. It
> occurs to me that we haven't given this proper consideration. There
> are a lot of places that we execute external code:
> * At startup: `exec_lines`, `exec_files`, startup files. There are .py
> and .ipy files, and they should definitely behave the same way with
> future statements.
> * `%run` (and `%run -i`), `%rerun`, `%edit`, macros, `%loadpy`
> * Extensions
> * Code loaded by the autoreload extension
> My gut feeling is that of those, `exec_lines`, `%loadpy`, macros and
> maybe `%run -i` should 'leak' future statements to the interactive
> environment. Everything else should keep future statements to itself
> (except by using `run_cell()` to run them through IPython). But I'm
> asking here to get other opinions.

- loadpy doesn't really do anything special regarding execution, it
only *reads* the data.  Once loaded, the cell will be executed just as
if it had been typed interactively.  So loadpy doesn't belong in this

- run: yes, if a __future__ is imported in a file that was %run, then
it should become active interactively.  The reason is to keep the
semantics of operating with things defined in that script consistent.
Say a script had `z=x/y` in it, you want to be able to later type at
the command-line `x/y` and get the same division semantics that were
set inside the script.

- the fact that .ipy files behave different from .py ones is a bug in
my view.  Those should be executed like modules, without leaking
__future__ imports.

- if users want a __future__ import  active in their startup sequence,
they should put it in `exec_lines` (or they can achieve the same
result by manually duing get_ipython().run_cell('from
__future__...')`.  I think it's OK that this is a special case, b/c
__future__ imports behave specially in Python itself.

In summary, it seems to me that we have:

- one small bug: the mismatch between .ipy and .py behavior.

- one small enahcement request: for %run to be executed in a way that
propagates any __future__ statements back to the interactive
environment. I'd note that if actually doing this complicates run in
any major way, we should simply drop the idea and document the
behavior in a special note.

- a visible note in the config section of the docs explaining that the
right way to set __future__ imports is via the `exec_lines` variable.

How does this sound?


More information about the IPython-dev mailing list