[Numpy-discussion] Moving lib.recfunctions?

[Dave Hirschfeld]

Pierre GM <pgmdevlist <at> gmail.com> writes:

>
> 
> Hello,
> The idea behin having a lib.recfunctions and not a rec.recfunctions or
whatever was to illustrate that the
> functions of this package are more generic than they appear. They work with
regular structured ndarrays
> and don't need recarrays. Methinks we gonna lose this aspect if you try to
rename it, but hey, your call.

I've never really thought there's much distinction between the two - AFAICT a
recarray is just a structured array with attribute access? If a function only
accepts a recarray (are there any?) isn't it just a simple call to
.view(np.recarray) to get it to work with structured arrays? Because of this
view I've always thought functions which worked on either should be grouped
together.

> As to as why they were never really advertised ? Because I never received any
feedback when I started
> developing them (developing is a big word here, I just took a lot of code that
John D Hunter had developed in
> matplotlib and make it more consistent). I advertised them once or twice on
the list, wrote the basic
> docstrings, but waited for other people to start using them. 
> Anyhow.
> So, yes, there might be some weird import to polish. Note that if you decided
to just rename the package and
> leave it where it was, it would probably be easier.
> 
> > The path of least resistance is to just import lib.recfunctions.* into
> > the (already crowded) main numpy namespace and be done with it.
> 
> Why ? Why can't you leave it available through numpy.lib ? Once again, if it's
only a matter of PRing, you
> could start writing an entry page in the doc describing the functions, that
would improve the visibility.
> 

I do recall them being advertised a while ago, but when I came to look for them
I couldn't find them - IMHO np.rec is a much more intuitive (and nicer/shorter)
namespace than np.lib.recfunctions. I think having similar functionality in two
completely different namespaces is confusing & hard to remember.

It also doesn't help that np.lib.recfunctions isn't discoverable by t
ab-completion:

In [2]: np.lib.rec
np.lib.recfromcsv np.lib.recfromtxt

...of course you could probably find it with np.lookfor but it's one more
barrier to their use.

FWIW I'd be happy if the np.lib.recfunctions fuctions were made available in the
np.rec namespace (and possibly deprecate np.lib.recfunctions to avoid 
confusion?)

I'm conscious that as a user (not a developer) talk is cheap and I'm happy with
whatever the consensus is. I just thought I'd pipe up since it was only through
this thread that I re-discovered np.lib.recfunctions!

HTH,
Dave