Fix Version/s: None
DM-5466, we needed to pass the results from ParseTask.getInfo() to the butler as a dataId. This is normally valid, since both are dictionaries, and even though getInfo() often contains extraneous entries that aren't relevant, the butler will usually ignore them. However, when parsing calibration files this dictionary contains some values that are set to None, since they will be filled in later. These extraneous keys are then placed in ButlerLocation.additionalData (butlerLocation.py:221), which throws an exception as it is a PropertySet and does not support python None as a value. DM-5466 has a work-around that strips these None values from the dictionary, but this is inelegant. The main driver for excluding None from PropertySet seems to compatibility with FITS headers. This seems like an unwarranted mixing of data model and persistence formats. Unless there is some advantage to not being able to store None in our dictionary-like objects, it seems preferable to shift the burden of accommodating FITS's peculiarities onto the persistence layer rather than PropertySet.
- is duplicated by
DM-8101 Add support for missing values to PropertyList
- is triggered by
RFC-239 PropertyList should support missing values and possibly units
- is triggering
DM-18864 Update afw to support undefined values in FITS headers
- relates to
DM-8100 Determine what astropy.io.fits does with FITS header cards for missing data
I think the changes for me to look at were on
DM-18864, right? Or should I look at the ones here, too?
I can't locate anything that looks like it would have been the culprit for filing this ticket;
DM-5466 went through a few permutations so the final code that was merged might not have had the same problem we saw originally.
Colin Slater do you know what I need to reverse from
DM-5466 to test that None now works?
The changes were to look at this one. I referred you to
DM-18864because of my recent addition there to work around the problem here based on the Slack discussion this morning.