It is a good question.
Right now I am doing some of each. If a function was defined in mlab.py
and it has a replacement in numpy I am issuing a deprecation warning
and passing the arguments to the numpy function. If a function was not
defined in mlab but was imported from numerix, then, with a couple of
exceptions, I am simply not leaving it in the mlab namespace.
This is in the present (old) mlab.py:
from numerix import array, asarray, arange, divide, exp, arctan2, \
multiply, transpose, ravel, repeat, resize, reshape, floor, ceil,\
absolute, matrixmultiply, power, take, where, Float, Int, asum,\
dot, convolve, pi, Complex, ones, zeros, diagonal, Matrix, nonzero, \
log, searchsorted, concatenate, sort, ArrayType, clip, size, indices,\
conjugate, typecode, iscontiguous
For compatibility, access to some or all of these things may need to
remain in the *pylab* namespace for a while, but I don't think it should
stay in the *mlab* namespace as well. I really don't want to add
wrappers with warnings for all these functions.
Michael Droettboom wrote:
> Eric Firing wrote:
>> Similarly, after dealing with mlab, I would like to simplify pylab.
>> Right now, we have a horrible tangle of namespaces in pylab. Cleaning
>> this up will potentially break user code; if a numpy function formerly
>> could be referenced with three different names and we knock that down
>> to one, code using the other two will not work. My guess is that in
>> practice the amount of breakage will be *very* small and easy for
>> users to deal with.
> Speaking off the top of my head, without looking at the specifics --
> would it be useful to generate deprecation warnings for these functions
> before we ultimately remove them? The deprecated functions could just
> be decorated versions of the "correct" functions that raise a warning
> and then delegate to the correct version.
> May be overkill if these functions really are in low usage, as you suspect.