[Numpy-discussion] Moving lib.recfunctions?

[Skipper Seabold]

On Fri, Jul 1, 2011 at 2:32 PM, Skipper Seabold <jsseabold at gmail.com> wrote:
> On Fri, Jul 1, 2011 at 2:22 PM,  <josef.pktd at gmail.com> wrote:
>> On Fri, Jul 1, 2011 at 1:59 PM, Skipper Seabold <jsseabold at gmail.com> wrote:
>>> lib.recfunctions has never been fully advertised. The two bugs I just
>>> discovered lead me to believe that it's not that well vetted, but it
>>> is useful. I can't be the only one using these?
>>>
>>> What do people think of either deprecating lib.recfunctions or at
>>> least importing them into the numpy.rec namespace?
>>>
>>> I'm sure this has come up before, but gmane search isn't working for me.
>>
>> about once a year
>>
>> http://old.nabble.com/Emulate-left-outer-join--td27522655.html#a27522655
>>
>> my guess is not much has changed since then
>>
>
> Ah, yes. I recall now.
>
> I agree that they're more general than rec, but also don't have a
> first best solution for this. So I think we should move them (in a
> correct way) to numpy.rec and add (some of?) them as methods to
> recarrays. The best we can do beyond that is put some docs on the
> structured array page and notes in the docstrings that they also work
> for ndarrays with structured dtype.
>
> I'll submit a pull request soon and maybe that'll generate some interest.
>

Had a brief look at what getting lib.recfunctions into rec/core.rec
namespace would entail. It's not as simple as it could be, because
there are circular imports between core.records and recfunctions (and
its imports). It seems that it is possible to work around the circular
imports in some of the code except for the degree to which
recfunctions is wrapped up with the masked array code.

The path of least resistance is to just import lib.recfunctions.* into
the (already crowded) main numpy namespace and be done with it.
Another option, though it's more work, is to remove all the internal
masked array support and let the user decide what do with the
record/structured arrays after they're returned (I invariably have to
set usemask=False anyway). The functions can then be wrapped by
higher-level ones in np.ma if the old usemask behavior is still
desirable for people. This should probably wait until the new masked
array changes are in and settled a bit though.

Skipper