Thanks for the feedback. I just posted a PR that removes the class in the C++ and Python libraries, hopefully this will help with the discussion. That I was able to do it in less than a day should be good evidence that the abstraction may be superfluous
https://github.com/apache/arrow/pull/4841 On Tue, Jul 9, 2019 at 4:26 PM Tim Swast <sw...@google.com.invalid> wrote: > > 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. > >
