Repository navigation
When should info be linked to a new object? #5047
Description
Mostly for @taldcroft - I noticed that in Quantity the way we have set up __array_finalize__, info is passed on not just for views (where it should be), but also for copies (implicitly in arithmetic operations, etc.). Which ones are reasonable? Just thinking about whether, e.g., info.name should be propagated, I'd think:
- Surely for
- views & reshapes:
q[...],q.squeeze, etc. - insertions:
q.insert(...)
- views & reshapes:
- Probably for
- selection of scalars:
q[0]or infor q1 in q:(for columns this returns a scalar withoutinfo) - copies:
q.copy()and equivalents - equivalent unit changes:
q.to(...),q.si,q.decompose(), etc.
- selection of scalars:
- Probably not for
- operations
q3 = q1 + q2 - real unit changes
q * unit(including in-place??;q /= u.m)
- operations
What do you think?
p.s. Currently, all of the above happen, in part because I use __array_finalize__ in Quantity._new_view, something which I don't think we had really considered when we made the change in __array_finalize__. But that also means that in principle it may not too hard to fairly finely define the behaviour.
Activity
taldcroft commentedon Jun 9, 2016
@mhvk - I basically agree with your assessment as being logical. I guess the only question is about having an easily stated rule for what happens. I wonder if we could make a rule (with a corresponding implementation) which is basically: "Any unary operation on a Quantity will preserve the
infoattribute if defined". So that would put your "real unit changes.." bullet into the "yes" category.mhvk commentedon Jun 9, 2016
That makes some sense, but I think I'd treat
q * unitas a binary operation still (even if it isn't quite implemented that way; I do think it would be confusing if there is a difference in behaviour between that andq * (1*unit)(note that the implementation already makes a copy ofq).Also, "unary" may be too broad: I don't think I'd want
np.sin(q)to keep theinfoattribute...taldcroft commentedon Jun 9, 2016
@mhvk - agreed. My main point is to strive to make the behavior predictable.