I just picked up a problem posted over on the numpy list. I noticed that
from pylab import * is importing the oldnumeric-wrapper versions of
zeros(), ones() and empty(), and presumably other things too, into the
interactive namespace. Shouldn't it be picking up the versions from
numpy's main namespace for interactive use?
I picked this up because I use "ipython -pylab" and noticed that zeros()
etc. was generating integers instead of floats by default.
In ipython:
Welcome to pylab, a matplotlib-based Python environment.
For more information, type 'help(pylab)'.
In [1]: zeros?
Type: function
Base Class: <type 'function'>
String Form: <function zeros at 0x010CA3F0>
Namespace: Interactive
File: c:\python24\lib\site-packages\numpy\oldnumeric\functions.py
Definition: zeros(shape, typecode='l', savespace=0, dtype=None)
Docstring:
zeros(shape, dtype=int) returns an array of the given
dimensions which is initialized to all zeros
In [2]: import numpy as n
In [3]: n.zeros?
Type: builtin_function_or_method
Base Class: <type 'builtin_function_or_method'>
String Form: <built-in function zeros>
Namespace: Interactive
Docstring:
zeros((d1,...,dn),dtype=float,order='C')
Return a new array of shape (d1,...,dn) and type typecode with all
it's entries initialized to zero.
···
--
Gary R.
Gary Ruben wrote:
I just picked up a problem posted over on the numpy list. I noticed that
from pylab import * is importing the oldnumeric-wrapper versions of
zeros(), ones() and empty(), and presumably other things too, into the
interactive namespace. Shouldn't it be picking up the versions from
numpy's main namespace for interactive use?
My understanding is that pylab (and Numerix) is maintaining backward compatibility with itself, so the oldnumeric form is the right one.
Another reason NOT to EVER use "import *"
Before too long, hopefully we'll only have to deal with numpy.
-Chris
···
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chris.Barker@...259...
Christopher Barker wrote:
> Gary Ruben wrote:
>> I just picked up a problem posted over on the numpy list. I noticed that
>> from pylab import * is importing the oldnumeric-wrapper versions of
>> zeros(), ones() and empty(), and presumably other things too, into the
>> interactive namespace. Shouldn't it be picking up the versions from
>> numpy's main namespace for interactive use?
>
> My understanding is that pylab (and Numerix) is maintaining backward
> compatibility with itself, so the oldnumeric form is the right one.
>
> Another reason NOT to EVER use "import *"
The way I tripped over this was using "ipython -pylab", which is doing this under the hood, so it's a little uglier in this case. What would be the effect on pylab using the newer numpy interactive namespace instead? I wonder whether matplotlib could check whether it has been imported by ipython interactively and import the newer namespace in this case, or whether there's a good argument for just dropping this little backward compatibility wart?
> Before too long, hopefully we'll only have to deal with numpy.
>
> -Chris
I'll just cross-post Fernando (ipython) Perez's solution from the numpy list to aid anyone else who falls into this trap:
···
--
Until mpl drops support for the compatibility layers, you may want to
set up a simple pylab profile. In ~/.ipython make a file called
'ipythonrc-pylab' consisting of:
#######
# Load default config
include ipythonrc
# Add single-line python statements here
execute from numpy import *
########
Since pylab does a 'from .num?. import *' this will ensure that the
top-level visible functions are the current numpy ones, not the
compatibility layer ones. You then start things with:
ipython -pylab -p pylab
and you'll get:
In [1]: zeros?
Type: builtin_function_or_method
Base Class: <type 'builtin_function_or_method'>
Namespace: Interactive
Docstring:
zeros((d1,...,dn),dtype=float,order='C')
Return a new array of shape (d1,...,dn) and type typecode with all
it's entries initialized to zero.
Not ideal, but it's a little hack that will work in practice until we
finish crossing the muddy river of backwards compatibility.
Cheers,
f
--
Gary