cosmo: make public io submodule#14982
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 |
2cdf9e9 to
2a2ad35
Compare
f65c78b to
8b79cdd
Compare
8b79cdd to
b44e240
Compare
|
ping @mhvk, @eerovaher. If you have time to review this. I'm trying to consolidate and clean up the I/O structure. Most of this is very straightforward, just moving files around and adding |
|
See #15169 for discussion of how one should indicate what is private. |
|
@mhvk, I think this PR can proceed as all the content currently lives in |
b44e240 to
aa857b4
Compare
9d4c2a8 to
b9025ae
Compare
24af642 to
5ebc11d
Compare
|
Thanks @eerovaher for the review. |
5ebc11d to
42e1183
Compare
8072a97 to
2adb55b
Compare
69b2198 to
93317c6
Compare
|
@mhvk @eerovaher @WilliamJamieson, I think this PR can proceed as all the content currently lives in _io which is already private and nothing changes on this front in the move to io/_builtin. A resolution to #15159 and astropy/astropy-APEs#85 might require a new PR to rename _builtin to builtin but also to the current incarnation _io -> io. |
0594a0a to
a7ccc4f
Compare
| >>> cosmo | ||
| FlatLambdaCDM(name="Planck18", H0=67.66 km / (Mpc s), Om0=0.30966, | ||
| Tcmb0=2.7255 K, Neff=3.046, m_nu=[0. 0. 0.06] eV, Ob0=0.04897) | ||
| FlatLambdaCDM(name='Planck18', H0=<Quantity 67.66 km / (Mpc s)>, Om0=0.30966, | ||
| Tcmb0=<Quantity 2.7255 K>, Neff=3.046, | ||
| m_nu=<Quantity [0. , 0. , 0.06] eV>, Ob0=0.04897) |
There was a problem hiding this comment.
Renaming modules should not cause FlatLambdaCDM.__repr__() to produce different output, and it looks like pytest agrees with me. This is a large pull request, I'd rather not review it until it has been cleaned up.
There was a problem hiding this comment.
I don't think these doctests were being tested! Trying to find the exact change that made them start being tested.
There was a problem hiding this comment.
I'm trying to identify the change that caused all these docstrings to start being tested. But regardless of the cause, I can confirm that the old docstrings are wrong, the new ones are correct, and that the docstrings are now being tested.
There was a problem hiding this comment.
The output here depends on the Python version, see
Lines 204 to 207 in dde34be
There's no need to update the docstrings in this pull request.
There was a problem hiding this comment.
Ah. And since _io is now io...
I can separate this into 2 PRs, first for the re-org. Then for fixing the docstrings.
There was a problem hiding this comment.
Docstring difference looks like repr vs str on the quantities. Not sure repr is better here.
There was a problem hiding this comment.
'>>>' calls repr. We would have to do print for everything.
Maybe Quantity's repr should be updated to call repr on its contents and enable eval(repr(q))
There was a problem hiding this comment.
I don't like that eval(repr(q)) doesn't work, but admittedly for arrays this is always going to be a problem (at least large ones). And ndarray doesn't produce a repr that can be evaluated either... This is why I was wondering if it really made sense to use repr(q) in cosmology.
There was a problem hiding this comment.
And ndarray doesn't produce a repr that can be evaluated either...
But other array types can! Maybe Quantity 2.0 is a good opportunity to enable the repr behavior, to support all the other array types.
There was a problem hiding this comment.
@eerovaher, done! removed the doc edits to mapping, row, and table.
a7ccc4f to
322df98
Compare
eerovaher
left a comment
There was a problem hiding this comment.
I have a few remarks, but I might have a few more when I've had a look at the rendered docs.
| :mod:`~astropy.cosmology.connect` module. It is intended that more public I/O | ||
| functionality will be added to the :mod:`~astropy.cosmology.io` module in the future. |
There was a problem hiding this comment.
Not sure if it's a good idea to make such public promises.
There was a problem hiding this comment.
I want to make much of the contents of _builtin that are related to converting between formats publicly accessible. I don't think there's a good way to type hint to(from)_format and I also want to both support a more functional approach to I/O. Also I would love to enable entry points so 3rd party packages can better register I/O formats. All it takes is copious free time to do...
|
Hi humans 👋 - this pull request hasn't had any new commits for approximately 4 months. I plan to close this in 30 days if the pull request doesn't have any new commits by then. In lieu of a stalled pull request, please consider closing this and open an issue instead if a reminder is needed to revisit in the future. Maintainers may also choose to add keep-open label to keep this PR open but it is discouraged unless absolutely necessary. If this PR still needs to be reviewed, as an author, you can rebase it to reset the clock. If you believe I commented on this pull request incorrectly, please report this here. |
11f6067 to
8cf4f4c
Compare
Signed-off-by: Nathaniel Starkman <[email protected]> Signed-off-by: nstarman <[email protected]>
Co-authored-by: Eero Vaher <[email protected]> Signed-off-by: nstarman <[email protected]> Update docs/whatsnew/7.0.rst Co-authored-by: Eero Vaher <[email protected]>
Signed-off-by: nstarman <[email protected]>
8cf4f4c to
1d444ac
Compare
In a previous PR (#14842) I made the private io module actually private.
This PR:
iomodule , which is much more carefully managed._iotoio/_builtin.connect.pyfile toioas a private module, but publicly importing it's classes and attributes.connect.pymodule for later removal.TODO: