[IPython-user] from __future__ import division

[Fernando Perez]

Harri Pasanen wrote:
> Strange.  Being curious, I tried setting in my ~/.ipython/ipythonrc
> 
> execute exec __IP.compile('from __future__ import
> division','<input>','single') in __IP.shell.user_ns
> 
> also on another machine, Mandrake 10.2, python 2.4, ipython 0.6.12
> 
> In [1]: 3/4
> Out[1]: 0
> 
> So it does not work for me, and I frankly puzzled how it could work
> for you, but obviously it does.

OK, this annoyed me, so I decided to get to the bottom of it.  Against my 
initial expectation, it is ipython version-dependend behavior.  See below, 
this is on a system with the above 'execute' line active:

###### Configure my system to run ipython 0.6.15:

planck[decimal]> ip
Python 2.3.4 (#1, Feb  2 2005, 12:11:53)
Type "copyright", "credits" or "license" for more information.

IPython 0.6.15 -- An enhanced Interactive Python.
?       -> Introduction to IPython's features.
%magic  -> Information about IPython's 'magic' % functions.
help    -> Python's own help system.
object? -> Details about 'object'. ?object also works, ?? prints more.

In [1]: 4/3
Out[1]: 1


##### Here, switch my config to run current SVN:

planck[decimal]> ip
Python 2.3.4 (#1, Feb  2 2005, 12:11:53)
Type "copyright", "credits" or "license" for more information.

IPython 0.6.16.svn -- An enhanced Interactive Python.
?       -> Introduction to IPython's features.
%magic  -> Information about IPython's 'magic' % functions.
help    -> Python's own help system.
object? -> Details about 'object'. ?object also works, ?? prints more.

In [1]: 4/3
Out[1]: 1.3333333333333333


So it turns out that switching to ipython current (from SVN) _is_ necessary 
for this to work.  Frankly, I'm not sure right now what the relevant change 
is, and it certainly isn't something I made for this specific problem.  I have 
updated the internal namespace handling to deal with some bugs, so this was an 
unintended side effect of that work.

> Anyway, -Qnew works, also with standard Python prompt,  and has the
> advantage of being a global setting.

Good, at least it works for you, and does something that per-module __future__ 
imports can not achieve at all.

At least we sorted it out :)

Cheers,

f