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