Pinging @eerovaher @eteq @StuartLittlefair @Cadair @ayshih @taldcroft as other "stakeholders" who may want to take a look at this and review!

Yes, yes and a thousand times yes.

The devil will be in the implementation details but this is a thoroughly good idea.

Does anyone else have thoughts before we ask the @astropy/coordinators to review this? cc @eteq @Cadair @ayshih @taldcroft!

I have been traveling the last several weeks and haven't had a chance to review this in detail, but I will try to do so this week. I am fairly sure I will have Opinions ™️ (but hopefully positive ones?)

@eteq OK cool. It'd be good to get your feedback ASAP, because @jeffjennings is starting to work through some of the changes we discuss here (in draft stages, but still, it is somewhat in progress).

I have two main thoughts about some effects from this change, I think they can both be managed, but probably worth having a think about.

1. The asdf serialisation is going to substantially different from now, managing that transition could be complex. - @braingram
2. Many SunPy frames have an observer attribute which is a realised frame holding the position of the observer. This could obviously become a SkyCoord, but I worry that adds some more complexity, and will for a start make the repr even more obnoxious than it is currently.

1. The asdf serialisation is going to substantially different from now, managing that transition could be complex. - @braingram

Thanks for pinging me about this change. If I'm following the end result will be that coordinate frames will no longer have data.

Reading old files with data when coordinate frames no longer support data

At that point when a user opens an ASDF file with a serialized coordinate frame (which might contain data) the converter that handles the deserialization could see that the file contains data and generate a SkyCoord instead (possibly with a warning that the file should be updated).

Writing files when coordinate frames no longer support data

This should be fine. Technically we could keep the same schema and just never write data (it's not required) but it might be a good opportunity to include some other schema cleanup (at the expense of some schema churn since many schemas reference the base coordinate frame schema).

Implementation details

The details about how this is implemented may impact ASDF serialization. Specifically the first item under implementation:

1. Splitting the frame classes into two hierarchies: ones with and without data.

The converter(s) would need to be updated to support these new classes. This isn't a problem but is work that wouldn't be needed if instead the existing classes were updated (deprecating and then removing the data feature).

1. Deprecating the legacy with-data frame classes.

At this point asdf-astropy could be updated to not use the legacy classes.

Hi @ayshih and @Cadair, we're starting to finalize this APE and are wondering if you anticipate any major concerns with respect to SunPy (as well as any suggestions you have, e.g. for addressing Stuart's point 2 above). The first phase of the APE wouldn't introduce any breaking changes, the second phase (timeline flexible) would add deprecation warnings, and the final phase (several major astropy versions away) would require changes to SunPy. Thanks!

and return when that is ready and can be demoed

In the light of this development, CoCo will hold off on further reviews for now. Thank you.

Possible updates from Astropy Coordination Meeting 2025:

• ICRS(ra, dec) returns a frame now; proposal is to keep it around but returning a SkyCoord in the future (on the same deprecation timescale) cc @keflavich
• Clarify more explicitly that your planned deprecation is at least 2 years, not just 1 year.

Possible updates from Astropy Coordination Meeting 2025:

* `ICRS(ra, dec)` returns a frame now; proposal is to keep it around but returning a `SkyCoord` in the future (on the same deprecation timescale) cc @keflavich

Our proposed deprecation stages for ICRS and all other frames are:

• keep current API, but internally call the new data-less equivalent class (e.g., ICRSFrame for ICRS), while emitting a deprecation warning when instantiated.
• still warn, but return a Coordinate, not an instance of its class type (by overriding __new__)
• remove the legacy frame classes after a suitable deprecation period

Keeping ICRS would unfortunately generate much user confusion during and after the full deprecation cycle, as there would now be ICRS and ICRSFrame. The docstrings and docs would have to explain the difference, and even then there would be confusion. An extensive deprecation cycle for these changes (comment quoted immediately below) has already been proposed, and a search-replace for ICRS to SkyCoord in downstream code would not be prohibitive.

* Clarify more explicitly that your planned deprecation is at least 2 years, not just 1 year.

Hi all, we now have a prototype and demo available for review. Please provide any comments within 2 weeks, by November 14.

We recommend reading through the demo notebook and then taking a look at the prototype implementation as needed (see the APE's "Implementation" section for links). Note that the implementation is not exhaustive, e.g., SkyCoord is not fully populated - there's just enough to demonstrate the new framework.

Signed,
APE 26 authors (@adrn, @jeffjennings, @mhvk, @nstarman)

With the acceptance of the revisions to APE 1, we're going to start following the new APE proposal process. While all of the APE editors (for now exactly the same as the CoCo) will contribute to the process, one of the APE editors will be the point-person (chief APE editor) shepherding your team through the process.

Your chief APE editor is Kyle Westfall (@kbwestfall).

You can review the next steps in the APE process here, but just to briefly summarize them here:

• Please finalize the draft of your APE and then ping @astropy/ape-editor-team. This will prompt the APE Editorial team to read the proposed APE and provide any basic editing comments (led by your chief editor).
• Following APE 1, this editing process will take no more than a month, but we actually expect this to go much faster for this APE.
• Once the basic editing is finished, APE 1 provides a detailed list of the next steps. The main thing to be aware of is that the APE status will be set to Discussion, the PR will be merged, and the APE editor will send an e-mail to astropy-dev to start the discussion period. All discussion should happen on the astropy-dev list.
• Throughout the discussion period, it is up to the APE authors to track the discussion and make updates to the APE. These changes can be committed in a series of new PRs or kept in a branch that only leads to a single PR after the discussion has reached consensus. Please keep your APE editor contact updated on your preferred approach.
• There is no set timeframe for the discussion period, but it should be at least 2 weeks.
• After this minimum discussion period but otherwise at their discretion, the APE authors must then notify the CoCo that the APE proposal is ready for a final decision.
• There is no set period for the CoCo review, but we expect it will take no more than 2-3 weeks.
• The CoCo will decide to accept, reject, or request more discussion on specific items in the proposal, which will restart the process from the start of the discussion period.

Please let us (either your chief APE editor or the full CoCo) know if you have any questions!

1. If the Coordinate class is inherently a good idea then it shouldn't need the backing of an APE to get it implemented. If it exists mostly as a replacement for BaseCoordinateFrame instances with data then I'm not fully convinced it is required at all. Either way, it seems to me the existence of Coordinate should not be dictated by the APE. If there is some good reason to include it in the APE then the APE should justify it better.

Thanks for your comments Eero. The purpose of the APE has been to propose a fairly large set of changes to the approach and implementation of a core part of astropy.coordinates, motivating why the changes diverge from parts of APE 5. And we wanted to discuss whether there's support for these changes. The scope of explaining and justifying Coordinate seems more suited to an APE than just a set of PRs in my opinion. The discussion of Coordinate in the APE of course does not require that Coordinate cannot in the future be changed or replaced. But I think the APE clearly motivates why Coordiante is useful in addition to SkyCoord and why it makes sense to effectively replace the existing BaseCoordinateFrame. Nathaniel's comment summarizes some of this very well.

2. The design proposed here is the second option from the APE 5 "Alternatives" section. APE 5 seems to reject that option because of a claim that it is impossible to implement the "high-level" classes as generics (although APE 5 does not use the term "[generics](https://typing.python.org/en/latest/reference/generics.html)"). To me it is obvious that the claim is false, which is why it is surprising to me that no-one seems to have called it out when APE 5 was discussed. Nonetheless, because APE 5 does make that claim then this APE should have a paragraph that comments on that. Additionally, the demonstration notebook should contain examples of both spherical representations that do not use RA and Dec, and also non-spherical representations, because that is what APE 5 claims will be difficult to implement.

Great, I've added a note on your APE 5 point to this APE, and added examples with cylindrical coordinates to the demo.

With the acceptance of the revisions to APE 1, we're going to start following the new APE proposal process. While all of the APE editors (for now exactly the same as the CoCo) will contribute to the process, one of the APE editors will be the point-person (chief APE editor) shepherding your team through the process.

Your chief APE editor is Kyle Westfall (@kbwestfall).

You can review the next steps in the APE process here, but just to briefly summarize them here:

* Please finalize the draft of your APE and then ping @astropy/ape-editor-team.  This will prompt the APE Editorial team to read the proposed APE and provide any basic editing comments (led by your chief editor).

* Following APE 1, this editing process will take no more than a month, but we actually expect this to go much faster for this APE.

* Once the basic editing is finished, APE 1 provides a detailed list of the next steps.  The main thing to be aware of is that the APE status will be set to Discussion, the PR will be merged, and the APE editor will send an e-mail to astropy-dev to start the discussion period.  **All discussion should happen on the astropy-dev list**.

* Throughout the discussion period, it is up to the APE authors to track the discussion and make updates to the APE.  These changes can be committed in a series of new PRs or kept in a branch that only leads to a single PR after the discussion has reached consensus.  Please keep your APE editor contact updated on your preferred approach.

We prefer implementing any such changes in a single PR.

* There is no set timeframe for the discussion period, but it should be at least 2 weeks.

We anticipate 2 weeks will be sufficient.

* After this minimum discussion period but otherwise at their discretion, the APE authors must then notify the CoCo that the APE proposal is ready for a final decision.

* There is no set period for the CoCo review, but we expect it will take no more than 2-3 weeks.

* The CoCo will decide to accept, reject, or request more discussion on specific items in the proposal, which will restart the process from the start of the discussion period.

Please let us (either your chief APE editor or the full CoCo) know if you have any questions!

Hi @astropy/ape-editor-team and @kbwestfall, thank you for all of this. I've just finalized the APE draft and left a few comments. So we're ready to move forward.

Here's my editorial review, which includes mostly minor wording recommendations. Thanks!

Thank you for such a fast review! I've incorporated all of your suggestions, but of course let me know if I can do anything else before the next step.