On Tue, Jul 9, 2019 at 1:14 PM Antoine Pitrou <anto...@python.org> wrote: > > > Le 08/07/2019 à 23:17, Wes McKinney a écrit : > > > > I'm concerned about continuing to maintain the Column class as it's > > spilling complexity into computational libraries and bindings alike. > > > > The Python Column class for example mostly forwards method calls to > > the underlying ChunkedArray > > > > https://github.com/apache/arrow/blob/master/python/pyarrow/table.pxi#L355 > > > > If the developer wants to construct a Table or insert a new "column", > > Column objects must generally be constructed, leading to boilerplate > > without clear benefit. > > We could simply add the desired ChunkedArray-based convenience methods > without removing the Column-based APIs. > > I don't know if it's really cumbersome to maintain the Column class. > It's generally a very stable part of the API, and the Column class is > just a thin wrapper over a ChunkedArray + a field. >
The indirection that it produces in public APIs I have found to be a nuisance, though (for example, doing things with the result of table[i] in Python). I'm about halfway through a patch to remove it, I'll let people review the work to assess the before-and-after. > Regards > > Antoine.
