Repository navigation
Give to_value methods to Column ~and TimeDelta~? #6148
Description
Inspired by #6137 (comment): now that Quantity gained a to_value method, which turned out to be quite valuable, should TimeDelta and Column acquire the same method, so they can duck-type for quantities in more situations. Probably, no reason not to.
EDIT: TimeDelta.to_value was done in #8762
Activity
eteq commentedon Jun 16, 2017
👍 for
TimeDelta... less sure aboutColumn, though: I wonder if instead we should tell everyone to useQTableif they want that functionality, rather than makingColumnmore franken-Quantity?taldcroft commentedon Jun 19, 2017
I agree completely with the comment by @eteq. I would even go so far as to consider deprecating
Column.toeventually and makingColumnless of a franken-Quantity. Definitely whenQuantitysupports masking and can do anything in a table whichColumncan do, then we should deprecate and finally removeColumn.to.mhvk commentedon Jun 19, 2017
I think I also agree, Column really is not meant to be like a Quantity, while TimeDelta in many ways is a Quantity with time units that just happens to have internal state and be much more precise. It has been very useful for me to be able to treat it as such, i.e., have
q / tdproduce a quantity. So, probably giving it ato_valueas well is fine.mhvk commentedon Jun 22, 2019
TimeDelta.to_valuenow exists (#8762);Column.to_valueremains to do...[-]Given to_value methods to Column and TimeDelta?[/-][+]Given to_value methods to Column ~and TimeDelta~?[/+][-]Given to_value methods to Column ~and TimeDelta~?[/-][+]Give to_value methods to Column ~and TimeDelta~?[/+]mhvk commentedon Jul 17, 2019
I'll close this issue as we've done
TimeDelta.to_value, which everyone agreed was a good idea, and there also seemed to be consensus that the remaining item,Column.to_value, was not a good idea,