Repository navigation
Add setters for WCS._naxis1/_naxis2 - #5454
Conversation
astropy#5411 replaced the _naxis1/_naxis2 attributes with properties but without adding setters. This break existing code that set these values (even if there are private, there is no other way to use the shape information from a WCS object).
pllim
added
Affects-dev
|
All our code is broken too. Should we merge these while still talking about a better solution in 1.3? |
|
A new and better solution would include new public attributes and/or new classes so it would be milestoned for 1.3 (or later), right? |
|
@MSeifert04 Yes, that's right. I was simply suggesting to merge this as a temporary "restore the previous state" solution in which case it probably does not need a milestone, in any case not 1.0.11. |
|
@nden I don't exactly know how milestones are handled. I guess this needs to be backported on top of the wrongdoer, also known as #5411, which is milestoned for 1.0.11. But I just wanted to know if any better solution could be backported instead of creating setters for private attributes. These setters probably will be annoying if we make these two attributes public ( |
It would be great to restore the previous behavior first (and allow to run our unit tests again Astropy's master), while waiting for a better solution. |
|
OK, merging this and will open a separate issue to be resolved for 1.3 release. |
Add setters for WCS._naxis1/_naxis2
Add setters for WCS._naxis1/_naxis2
4 participants
Following #5411 which replaced the _naxis1/_naxis2 attributes with properties but without adding setters. This break existing code that set these values (even if there are private, there is no other way to use the shape
information from a WCS object). See discussion in #5411