[Numpy-discussion] Deprecating old names

Ed Schofield schofield at ftw.at
Sun Apr 2 13:05:02 EDT 2006


Tim Hochberg wrote, in a different thread:
>     >>> len(dir(numpy))
>    476
>
> Does anyone know what all of that does? I certainly don't. And I doubt
> anyone uses more than a fraction of that interface. I wouldn't be the
> least bit suprised if there are old moldy parts of that are
> essentially used. And, unused code is buggy code in my experience.
>
>    "Perfection is achieved, not when there is nothing more to add, but
>    when there is nothing left to take away." -- Antoine de Saint-Exupery

I'd like to revise a proposal I made last week.  Then I proposed that we
reduce namespace clutter by not importing the contents of the oldnumeric
namespace by default.  But Travis didn't want to deprecate the
functional interfaces (sum(), take(), etc), so I now propose instead
that we split up the contents of oldnumeric.py into interfaces we want
to keep around indefinitely and interfaces we don't.  The ones we want
to keep could go into another file, e.g. fromnumeric.py, whose contents
are imported into the numpy namespace by default.  The deprecated ones
could stay in oldnumeric.py, and could be accessible through 'from
oldnumeric import *' at the top of source files, but not imported by
default.  Strong candidates for deprecation are the capitalised type
names, like Int8, Complex64, UnsignedInt.  I'd also argue for
deprecating NewAxis, UFuncType, ArrayType, arraytype, and anything else
that duplicates functionality available under NumPy under a different name.

Two of the Python design principles (from
http://www.python.org/dev/culture/) are:
 - There should be one -- and preferably only one -- obvious way to do it.
 - Namespaces are one honking great idea -- let's do more of those!

Let's clean up the cruft!

-- Ed





More information about the NumPy-Discussion mailing list