Issue/288/standardize naming #391
Conversation
Codecov ReportPatch coverage:
Additional details and impacted files@@ Coverage Diff @@
## main LSSTDESC/RAIL#391 +/- ##
==========================================
Coverage 100.00% 100.00%
==========================================
Files 40 38 -2
Lines 2876 2763 -113
==========================================
- Hits 2876 2763 -113
Flags with carried forward coverage won't be shown. Click here to find out more.
☔ View full report in Codecov by Sentry. |
|
@yanzastro @sschmidt23 While propagating naming consistency through the demos I noticed that there are two seemingly slightly different versions of the somoclu demo. Can you confirm which I should remove (or update the markdown text to indicate the big picture differences I failed to find)? EDIT: Related question for @sschmidt23 : Since both SimpleSOM and somocluSOM contained the same |
This is a draft PR for LSSTDESC/rail_base#1 so I can check that I'm not breaking the tests (because fitsio isn't behaving on my local machine today). The scope of changes is to standardize naming of classes (and hopefully their config parameters, although I'm not sure I understand them all well enough to do that alone) that are going to be isolated into standalone repos in LSSTDESC/RAIL#384, to be accompanied by PRs in the existing standalone repos as necessary. To prevent myself from getting distracted from the task at hand, I'm also adding
TODOnotes to give concrete starting points for LSSTDESC/rail#22.EDIT: Overall, the changes here pertain solely to consistency in class and module naming; apologies if this was unclear to anyone! The purpose is so we don't inadvertently ask users to guess at the syntax for a given stage with respect to the module it's in (occasionally risking namespace issues if they import common packages with the same as a RAIL module) and with respect to other stages that do similar things with other underlying algorithms, across
creationandevaluationas well as withinestimation(leaving open the possibility to distinguish algorithms that can be used for both estimation and summarization). It also addresses a common source of confusion among users trying to understand the idea of stages in general, due to naming standards we established before switching to ceci as a back-end: rather than being a function or method, if a stage is an object that takes an extra line of code to run, why are they sometimes named as actions or underlying algorithms (without indication of whether it's an estimator or summarizer)?In any case, this PR affects formatting only, not content/meaning of any of the classes in question, so my hope is that the disruption is entirely degenerate with that anticipated for LSSTDESC/RAIL#384, if they happen at the same time. The changes include the following (just in rail.estimation for now):
I can put together a block of
import X as Yfor backwards compatibility in case anyone finds the changes too hard to propagate through pipelines you've already written.Note that the base classes are unaffected (though they will be in LSSTDESC/rail_base#14, at least there aren't any Evaluators outside base RAIL), so stages that are not updated for consistency won't be broken. Propagation of consistent naming to the already standalone repos will be completed in subsequent PRs in those repos. However, I'd like to take advantage of the opportunity posed by the isolation-refactoring disruption to make similar changes to some of the degraders, on a separate issue/branch/PR akin to LSSTDESC/rail_base#14.