[SciPy-dev] -Qnew option breaks scipy

Eric Nodwell nodwell at physics.ubc.ca
Sun Apr 30 17:17:44 CDT 2006

OK, I'll accept that it's not really a bug (yet).  But I disagree that
it's something one doesn't need to care about until python 3.x, and I
disagree even moreso that it's not even possible to deal with this
until 3.x.  My understanding is that PEP238 has been accepted and is
final, and the change to division is fully implemented as of 2.2, with
no further changes to division occuring except the gradual phase-in
for backwards compatibility.  From the PEP:

The -Q command line option takes a string argument that can take
    four values: "old", "warn", "warnall", or "new".  The default is
    "old" in Python 2.2 but will change to "warn" in later 2.x

I guess I just generated a slightly premature warning.

$ /sw/bin/python -Qwarn
Python 2.4.2 (#1, Mar  5 2006, 22:35:36)
[GCC 4.0.1 (Apple Computer, Inc. build 5247)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import scipy
DeprecationWarning: classic int division
  bytes = bits / 8
DeprecationWarning: classic int division
  na_name = '%s%d' % (base.capitalize(), bit/2)
DeprecationWarning: classic int division
  nbytes[obj] = val[2] / 8
DeprecationWarning: classic int division

(Oh, and I did just try PYTHONSTARTUP and of course it does get
exec'ed, which is just peachy.   I thought I'd tried it once long ago
and couldn't get "from __future__ import division" that way. 
Obviously that must have been something else that I tried.  Thanks for
pointing that out.)


On 4/30/06, Robert Kern <robert.kern at gmail.com> wrote:
> Eric Nodwell wrote:
> > If a command line switch exists, it will be used.
> Sure. And those users need to take responsibility for doing weird things, not
> library authors.
> > According to http://www.python.org/dev/peps/pep-0238, this project:
> > http://www.vpython.org, has a need for running everything with -Qnew .
> >  I can't say whether they truely need it or not, I only point it out
> > as an example of the above axiom.
> And they were wrong to do so.
> > This is something which will have to be done eventually anyways, since
> > some day -Qnew will become the default.  Maybe not in the 2.x series
> > as you point out.
> Definitely not in the 2.x series. From the PEP:
> """
>     - Classic division will remain the default in the Python 2.x
>       series; true division will be standard in Python 3.0.
> """
> Python 3.0 is the backwards-compatibility-breaking release. Scipy will have to
> go through much larger changes then than division. Python 3.0 does not exist
> yet, and it is impossible to write 3.0-compatible code. We'll have to deal with
> those changes later. That's the perfect time to deal with the change in division
> behavior.
> > OK, I admit I'm not submitting a patch myself,
> > merely pointing it out in the hope that someone will say, hey I can
> > fix that in 5 minutes.  For all I know however a fix would require a
> > major rewrite of scipy.
> It's not a 5-minute fix.
> > I was using -Qnew because I often use python as an interactive
> > calculator and I was getting tired of typing "from __future__ import
> > division" so I aliased python -Qnew.  Too bad if this is something one
> > ought not to do, because it makes the best calculator that I know of.
> > It does no good to put the future statement in a module listed in
> > PYTHONSTARTUP, because then, as you point out, the effect is limited
> > to that module.
> Have you tried it? The file in PYTHONSTARTUP gets exec'ed, not imported.
> from __future__ import division
> try:
>     import readline
> except ImportError:
>     print "Module readline not available."
> else:
>     import rlcompleter
>     readline.parse_and_bind("tab: complete")
> [~]$ python
> Python 2.4.1 (#2, Mar 31 2005, 00:05:10)
> [GCC 3.3 20030304 (Apple Computer, Inc. build 1666)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
> >>> 3/2
> 1.5
> >>>
> --
> Robert Kern
> robert.kern at gmail.com
> "I have come to believe that the whole world is an enigma, a harmless enigma
>  that is made terrible by our own mad attempt to interpret it as though it had
>  an underlying truth."
>   -- Umberto Eco
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.net
> http://www.scipy.net/mailman/listinfo/scipy-dev

More information about the Scipy-dev mailing list