naming consistency/clarity within src/rail/estimation #31
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Change Description
This PR (and other concurrent PRs in the other repos) include renamings of modules and stages within
src/rail/estimation
for consistency and transparency to users as outlined in LSSTDESC/rail#37. (Expect a few more PRs to address the smaller set of necessary consistency/clarity changes outsidesrc/rail/estimation
using the same branch.)I request that multiple reviewers please do not hesitate to suggest changes as needed! The goals are consistency, clarity, and longevity, so if something looks unclear, inconsistent, or insufficiently flexible to accommodate future development, now is the time to make adjustments.
Solution Description
The following changes were made across all the rail repos, along with updates to the contributing documentation (which should be propagated to the rail python project template so prompts regarding naming are included in future PR checklists).
Code Quality
Bug Fix Checklist
Given that we are still pre-v1, I have not explicitly included backward compatibility, but a block of
import X as Y
can be constructed from the above list of changes.Other Change Checklist
I fixed some instances of outdated descriptions in the demo notebooks, but others require more substantial editing, e.g. when they describe code that has long since been removed from the demo in question or aspects of the API that have significantly changed since the descriptions were written. The demos require a thorough review before v1 that's out of scope for this series of PRs.