In 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.