# PropertySet does not support values of None

XMLWordPrintable

#### Details

• Type: Story
• Status: Done
• Resolution: Done
• Fix Version/s: None
• Component/s:
• Labels:
None
• Story Points:
3
• Sprint:
Arch 2019-04-01
• Team:
Architecture

#### Description

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.

#### Activity

Hide
Tim Jenness added a comment -

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

Show
Tim Jenness added a comment - 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).
Hide
John Swinbank added a comment -

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.

Show
John Swinbank added a comment - 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.
Hide
Kian-Tat Lim added a comment - - edited

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

Show
Kian-Tat Lim added a comment - - edited 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.)
Hide
Tim Jenness added a comment -

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

Show
Tim Jenness added a comment - 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).
Hide
Tim Jenness added a comment -

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.

Show
Tim Jenness added a comment - 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.
Hide
Tim Jenness added a comment -

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

Show
Tim Jenness added a comment - Colin Slater do you know what I need to reverse from DM-5466 to test that None now works?
Hide
Colin Slater added a comment -

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.

Show
Colin Slater added a comment - 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.
Hide
Tim Jenness added a comment -

Jim Bosch thanks for agreeing to look at this.

Show
Tim Jenness added a comment - Jim Bosch thanks for agreeing to look at this.
Hide
Jim Bosch added a comment -

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

Show
Jim Bosch added a comment - I think the changes for me to look at were on DM-18864 , right?  Or should I look at the ones here, too?
Hide
Tim Jenness added a comment -

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.

Show
Tim Jenness added a comment - 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.

#### People

Assignee:
Tim Jenness
Reporter:
Colin Slater
Reviewers:
Jim Bosch, Kian-Tat Lim
Watchers:
Colin Slater, Jim Bosch, John Swinbank, Kian-Tat Lim, Meredith Rawls, Simon Krughoff, Tim Jenness