`~/.pythonrc' `from __future__ import'

Tim Peters tim.one at comcast.net
Sun Jul 7 21:43:31 EDT 2002


[François Pinard]
> Hello, people.  Here is a strange problem with `from __future__ import',
> maybe you can help me understand it.  This is with Python 2.2.1.
>
> Given `export PYTHONSTARTUP=/home/pinard/etc/pythonrc', and that
> `pythonrc'
> file starting with:
>
> ---------------------------------------------------------------------->
> from __future__ import division
> print 3/4
> ----------------------------------------------------------------------<
>
> then I interactively get:
>
> ---------------------------------------------------------------------->
> 18:01 0 pinard at titan:~ $ python
> Python 2.2.1 (#1, Apr 29 2002, 14:27:21)
> [GCC 2.95.3 20010315 (SuSE)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> 0.75
> >>> 3/4
> 0
> >>> from __future__ import division
> >>> 3/4
> 0.75
> ----------------------------------------------------------------------<
>
> I wonder why I have to re-execute `from __future__ import divsion'
> interactively before it works.

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.

Note that Python has no equivalent in this respect to what some shells call
a "source" command.

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

You can write an alias to start interactive sessions by passing -Qnew to
Python.  Then future division will be in effect globally (note:  that means
globally, including across all imported library modules, and some non-core
library modules may not yet work correctly when future division is in
effect; so -Qnew can't be recommended for general use, but is fine if
you're, umm, motivated <wink>).







More information about the Python-list mailing list