Repository navigation
Conversation
|
Thank you for your contribution to Astropy! 🌌 This checklist is meant to remind the package maintainers who will review this pull request of some common things to look for.
|
|
👋 Thank you for your draft pull request! Do you know that you can use |
|
|
||
|
|
||
| @replace.register | ||
| def _replace_quantity(obj: _QuantityT, /, **kwargs: Any) -> _QuantityT: |
There was a problem hiding this comment.
This handles Quantity subclasses, but we might want some more specific functions that better address nuances.
24caa2e to
1c873ab
Compare
Styled off of the dataclasses function. Signed-off-by: nstarman <[email protected]>
1c873ab to
6292069
Compare
|
Ping @ayshih (as a note, you're not in the any-can-join public Astropy Members group so I can't request a review) |
| unit = kwargs.pop("unit", obj.unit) | ||
| return type(obj)(value, unit=unit, **kwargs) |
There was a problem hiding this comment.
| unit = kwargs.pop("unit", obj.unit) | |
| return type(obj)(value, unit=unit, **kwargs) | |
| kwargs.setdefault("unit", obj.unit) | |
| return type(obj)(value, **kwargs) |
|
Re: group membership -- The automation that Matt Craig set up a while ago is currently broken. But I have manually invited ayshih to |
|
Re this PR: It's an interesting approach! I think the challenge would be to educate users that this function even exists, since I imagine that the natural inclination would continue to be to hunt for the appropriate class-specific method. It doesn't help that Re adding me to |
The docs would be the most natural place, I suppose. Most classes in Astropy don't have a class-specific method, so hunting will only turn up
Agreed. This is a larger problem we have. We need to better distinguish utils for users, utils for affiliate package developers, and internal utils. |
mhvk
left a comment
There was a problem hiding this comment.
I left a few in-line comments, but like @ayshih, I worry about visibility for these kinds of small "handy" functions. Indeed, it may not see that much use even in astropy (less than 10 true uses of .replicate, mostly in SpectralCoordinate and Time). Given those cases, I think there will be very little outside use (as far as I can tell from a quick check, I do not ever use .replicate myself). It seems to me it really mostly makes sense in a modeling situation (this including Cosmology), where it is meaningful to just replace one attribute.
Overall, maybe just try to make cosmology and modeling have a consistent interface?
| """ | ||
| # Currently ``replicate`` is not implemented for SkyCoord and returns a | ||
| # ``BaseCoordinateFrame``object. | ||
| return obj.__class__(obj.replicate(copy=copy, **kwargs)) |
There was a problem hiding this comment.
Realize this is still a draft just to see whether we want it at all, but this won't be quite right, since all non-frame attributes get lost.
| @@ -0,0 +1,46 @@ | |||
| """ | |||
| A simple class to manage a piece of global science state. See | |||
|
I guess this would be better handled as an external library. It's a generically useful solution to a common Python problem. |
TODO:
As came up in discussion in #15643, it would be very convenient to have a consistent means to copy an instance, replacing a certain set of attributes. In
Cosmologythere'sclone, inBaseCoordinateFramethere'sreplicate.This PR doesn't replace these methods (which should still be made consistent), rather introducing a new universal framework styled off of the
dataclassesfunctionreplace. Withreplaceany Astropy object can easily register an implementation for copy-and-modify!How does this work?
functools.singledispatchmeans one function (replace) is defined in the moduleastropy.utils.replace. Normally you would need a big if-else list to handle different data types. Or roll a custom registration system.functools.singledispatchtakes care of the registration for us and is well documented in core python, so this is an easy system to teach and is a very stable solution. All you need to do register support for a new type isfunctools.singledispatchintrospects the function for the annotations and handles everything.replace.registercan also accept arguments directly. Seefunctoolsfor details.P.S.
functools.singledispatchalso handles subclasses very well.P.P.S. I registered
dataclasses.replaceintoastropy.utils.replace, so ALL dataclasses are supported!Long-term note:
If this PR is adopted I actually think we should plan to spin it off into a micro-package that becomes a runtime dependency for Astropy. It's such a simple (and IMO elegant) solution to the copy-and-modify issue that I think this will be genuinely useful far outside of Astropy, at the very least in coordinated and affiliate packages. Since it's just a simple wrapper around a core-python future, this will be a very stable dependency. But we can discuss this plan after this PR.