FWIW, I found the Column class to be confusing in Python. It felt redundant / unneeded to actually create Tables.
On Tue, Jul 9, 2019 at 11:19 AM Wes McKinney <wesmck...@gmail.com> wrote: > 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. >
