Skip to content

encourage astropy.table #676

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
womullan merged 3 commits into from
Jan 16, 2025
Merged

encourage astropy.table #676

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
18adb34
encourage astropy.table
womullan May 15, 2024
0855d6e
wording
womullan May 15, 2024
d68413a
KT comments
womullan Jan 16, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 6 additions & 2 deletions python/astropy.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -13,7 +13,7 @@ Integration of Astropy core into the LSST software stack is an ongoing process t
This document is not discussing Astropy affiliated packages, use of which must go through the standard :doc:`RFC </communications/rfc>` process.
Not all Astropy core packages can be used by default.

The following packages can be used internally in packages if they do not leak into public APIs:
The following packages can be used internally in packages:
Copy link
Contributor

@ktlim ktlim May 21, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think time and units are now accepted enough that they could even be in public APIs, not just internal. But I'm not sure we want the rest in APIs.


* :mod:`astropy.coordinates`
* :mod:`astropy.time`
Expand All @@ -27,17 +27,21 @@ For reading and writing files in FITS format, both :mod:`astropy.io.fits` and `f
These libraries differ in the features available and in performance (with the latter usually surpassing the former).
Developers must evaluate which works best for their use case and choose one accordingly.


.. _fitsio: https://github.com/esheldon/fitsio

.. warning::

``lsst.afw.fits`` must not be used in any new Python code, as it is not considered memory safe.

If not interacting with C++ classes the use of ``astropy.table`` is encouraged.
Copy link
Contributor

@ktlim ktlim May 21, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe add: "In particular, the Table class has beneficial properties over Pandas DataFrame." ?

In particular, the Table class has beneficial properties over Pandas DataFrame.
The interaction of Astropy with LSST C++ classes providing related functionality should be carefully monitored.
If the code is already using ``afw`` it is strongly preferred that ``afw`` equivalents be used until such time as specific ``afw`` interfaces are deprecated.
:mod:`astropy.table` views into ``afw.table`` tables can be used if required.

Changing public APIs to use the above Astropy packages requires prior permission and possibly an :doc:`RFC </communications/rfc>`.
Changing any public APIs requires an :doc:`RFC </communications/rfc>`.
Hence using Astropy in any public API must go through an RFC.

These items have functionality that is similar to that provided in LSST packages:

Expand Down
Loading