I don't think FITS could be the justification here because FITS headers support undefined values.

HEADER  =         / an undefined value

Is the FITS standard scheme for storing an undefined value in a header (it has no derivable type). Historically, convincing header parses to handle this case has been tricky (the AST library does know how to do it though).

Kian-Tat Lim — is there an Architecture concern here? I am happy to accept this work onto the backlog for the DRP team to address as long as you don't think it needs further discussion first.

Adding None as a valid value for PropertySet entries will likely require adding an additional boolean to each entry as None has no type. Code will need to be added to handle the cases of creating a new entry with None value, setting a value of existing type to None, setting a value of None to a new value of some type, and likely preventing a value that has been set to one type from being set to a different type after having an intermediate None stored. Furthermore, handling of lists of values will have to be defined: Does None replace the entire list, or is it a list entry, further complicating type issues? I suggest the former matches the FITS expectation and is simpler.

We also have to consider whether None-supporting PropertySet s and PropertyList s will be backward-compatible with previously-persisted objects. (If I or someone else could finish the YAML persistence for DM-4927, which is partly complete at daf_persistence branch u/ktlim/yamlStorage, that might help as well.)

I think one of either this ticket or DM-8101 should be marked as a duplicate. They both want support for None as values in PropertyList/Set but they are coming at it from opposite ends (one wants it because of FITS and this one because of Python).

Kian-Tat Lim I think this is ready for at least an initial review. It turned out to be really simple: register nullptr_t as a type and pybind11 automatically converts that to None.

The handling of scalars works fine. Storing a None inside an array of ints (or hoping that getInt can return None) will I think require magic values inside the C++ layer that map to None in the python layer. I'm not sure it's worth it for now.

Colin Slater do you know what I need to reverse from DM-5466 to test that None now works?

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.

Jim Bosch thanks for agreeing to look at this.

I think the changes for me to look at were on DM-18864, right?  Or should I look at the ones here, too?

The changes were to look at this one. I referred you to DM-18864 because of my recent addition there to work around the problem here based on the Slack discussion this morning.