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.
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
DEPR: emit a FutureWarning
when mutating Time.location
post-initialization
#16063
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -2883,3 +2883,16 @@ def test_timedelta_empty_quantity(): | |
|
||
with pytest.raises(ValueError, match="only quantities with time units"): | ||
TimeDelta([] * u.m) | ||
|
||
|
||
@pytest.mark.parametrize( | ||
"kwargs", [{}, dict(location=None), dict(location=EarthLocation(0, 0, 0))] | ||
) | ||
def test_immutable_location(kwargs): | ||
# see https://github.com/astropy/astropy/issues/16061 | ||
loc = EarthLocation(0, 0, 0) | ||
t = Time("2024-02-19", **kwargs) | ||
|
||
with pytest.warns(FutureWarning): | ||
# in the future, this should be an AttributeError | ||
t.location = loc | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Can you also add a test where the time is initialized with a There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I've parametrised the test to this effect ! |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1 @@ | ||
A ``FutureWarning`` is now emitted when mutating ``Time.location`` post-initialization. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could define
_location = None
on theTime
classThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This works, but I have a personal (slight) aversion for using class attributes as defaults for instance attributes, because I've been bitten by some nasty bugs that would have been easier to figure out if things were kept simpler.
I don't think this matters too much here, so let @taldcroft be the judge, and I'll go with whichever version he prefers :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@neutrinoceros - I suggested something different below, but in general I like class attribute as defaults since they more explicitly highlight the attributes of an object. This is pretty much the entire basis for dataclasses, which I've started using in new code. By using only the defined class attributes the code feels more robust. The days of tossing new attributes onto an object anywhere along the way are gone. 😄
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like dataclasses but they feel entirely different to me (small and self-contained VS large classes + inheritance trees). In general, the issue (to me) is in figuring out where attributes come from. Anyway, we digress ! I like your suggestion best, so let's try that !