Astropy: Name of uncertainties: StdDevUncertainty vs. VarianceUncertainty vs. InverseVariance

[MSeifert04]

There is a bit of inconsistency between the names. The first (StdDevUncertainty) is somewhat abbreviated and has the "Uncertainty" suffix, the second (VarianceUncertainty) uses the full name and the suffix, while the last one (InverseVariance) uses the full name without suffix.

Since they shouldn't be "offically released" yet we still could make the names more consistent with StdDevUncertainty (the already released one)? Maybe VarUncertainty and IVarUncertainty (or InvVarUncertainty)?

Not sure if this is actually necessary, I just noticed and wanted to ask if someone else is bothered about the naming. 😅

[bsipocz]

Would be nice to sort this out before the release ;)

[MSeifert04]

Fyi: @mwcraig

[mwcraig]

I thought about this for a while when picking the new names. What I would really like to do is go with longer names, ideally without Uncertainty in them at all. So my ideal would be StandardDeviation, Variance, and InverseVariance. These are all camera and explicit, and presumably one doesn’t need the reminder that one is using an Uncertainty if you know to use one.

I think I went with the names actually in the PR to avoid deprecating StdDevUncertainty (and it avoid annoying people who use it with a deprecation warning), added Uncertainty to Variance to be consistent with StdDevUncertainty but didn’t put Uncertainty on InverseVariance because it was too long.

What do you think about going the route of my preferred names? I can do the change later today or on Friday.

If we do change the name of StdDevUncertainty I’m inclined to leave the old name in without a deprecation warning to avoid another overwrite/clobber debate.

Thoughts?

[MSeifert04]

Good points.

to avoid another overwrite/clobber debate.

Yeah, we don't need one of these again 😄

Personally I would prefer not changing or aliasing the StdDevUncertainty class and just naming the new classes similarly, it's consistent and doesn't require anyone to change their code (even if it's just following the "approach we recommend").
But it's just a question about how consistent we want to be - it's just slightly bugging me...

[pllim]

C'mone, overwrite/clobber debate is so 2016. Moffat alpha/beta/gamma is all the rage now. :wink:

[MSeifert04]

alpha/beta/gamma

so we should provide the uncertainty (or should I say delta)?

[mwcraig]

I'm inclined to punt on this one until the coordination meeting...

[MSeifert04]

Okay. Sounds good to me.

[bsipocz]

Was there any decision about this at the coordination meeting? If yes, 3.2 could be a good time to get the changes in as deprecations and finalize them in 4.0.

[mwcraig]

Not that I recall.... @crawfordsm do you remember?

[bsipocz]

Removing milestone, though I would hash out that 4.0 is the best time to rename things.

[saimn]

Probably too late to rename things now isn't it ? Should we close ?

[bsipocz]

Yes, it feels like this ship might have sailed. Next convenient renaming is in 1.5 years with the new LTS release.

I leave the closing of the issue to the subpackage maintainers, as they yet to comment on it.

cc @eteq @mhvk @astrofrog

[pllim]

I trust the bot more. 😏 🤖

[astrofrog]

Well we can still rename if we want, preserving compatibility for the old names without deprecation for now.

[astropy-bot[bot]]

Hi humans :wave: - this issue was labeled as Close? approximately 7 days ago. If you think this issue should not be closed, a maintainer should remove the Close? label - otherwise, I will close this issue in a month.

If you believe I commented on this issue incorrectly, please report this here

[astropy-bot[bot]]

I'm going to close this issue as per my previous message, but if you feel that this issue should stay open, then feel free to re-open and remove the Close? label.

If this is the first time I am commenting on this issue, or if you believe I closed this issue incorrectly, please report this here