On Mon, Jan 29, 2018 at 2:55 PM, Stefan van der Walt <stef...@berkeley.edu>
wrote:

> On Mon, 29 Jan 2018 14:10:56 -0500, josef.p...@gmail.com wrote:
>
>> Given that there is pandas, xarray, dask and more, numpy could as well
>> drop
>> any pretense of supporting dataframe_likes. Or, adjust the recfunctions so
>> we can still work dataframe_like with structured
>> dtypes/recarrays/recfunctions.
>>
>
> I haven't been following the duckarray discussion carefully, but could
> this be an opportunity for a dataframe protocol, so that we can have
> libraries ingest structured arrays, record arrays, pandas dataframes,
> etc. without too much specialized code?
>

AFAIU while not being in the data handling area, pandas defines the
interface and other libraries provide pandas compatible interfaces or
implementations.

statsmodels currently still has recarray support and usage. In some
interfaces we support pandas, recarrays and plain arrays, or anything where
asarray works correctly.

But recarrays became messy to support, one rewrite of some functions last
year converts recarrays to pandas, does the manipulation and then converts
back to recarrays.
Also we need to adjust our recarray usage with new numpy versions. But
there is no real benefit because I doubt that statsmodels still has any
recarray/structured dtype users. So, we only have to remove our own uses in
the datasets and unit tests.

Josef



>
> Stéfan
>
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Reply via email to