Repository navigation
Conversation
| kwargs['mask'] = True | ||
|
|
||
| kwargs.update(**out_attrs) | ||
| cols.append(out.ColumnClass(**kwargs)) |
There was a problem hiding this comment.
@taldcroft - the key difference is here: instead of creating an empty array that becomes a column without attributes, I create an empty base column with all the attributes already set (this will be Column even for QTable, but is then converted to Quantity by addcolumns below).
|
p.s. There's an argument to be made to move |
|
fixes #4599 |
|
@mhvk - is there any way to make an isolated version that shows only the very minimal changes needed to accomplish the original goal? I am really surprised that it had to be so invasive. I had thought that the plan would be to make Quantity behave more Column-like so that it just drops in with minor changes to operations.py. This relates to other conversations about making Quantity more drop-in compliant with ndarray . I have not studied the changes here in detail, but as you said it is more like an ab-initio review at this point, which isn't so easy... |
|
It is not easy to make a more minimal version -- for But I did do this work in stages, so I think if you look just at the first three commits (in order), you'll get a very good sense of what and why it happened.... |
|
This was supercedde by #5841, so closing |
With this PR, table stacking/joining becomes possible also for
QTableinstances holdingQuantitycolumns, with units properly taken into account.@taldcroft - this required more of a rewrite of
operations.pythan I had hoped, mostly because in order to do this the output column attributes have to be determined before creating the column (as they need to be used in the creation). Once that worked, it seemed better to just clean up the code too (e.g., renamingarraystotableseverywhere, as the former were [I think] a left-over of the time that tables had structured arrays underneath). With that, it may be better to look atoperations.pyitself rather than at the diff...