I support this, even if we don't use FITS for internal data persistence (as I'm hoping will happen before too long): being able to attach comments and units to PropertySet values is a very useful documentation feature (I'm right this moment lamenting the ability to add docstrings to collection.namedtuple entries).

I'm strongly in favor of adding support for undefined values. Reading (and writing) units from comments would also be very useful. I'm a bit surprised that comments aren't handled. How is round-tripping done?

PropertyList does support comments. There are comment arguments to all modifier methods, a getComment() method is present, and comments are output after "// " in the toString() method.

Is it better to have unit support in PropertyList or is it better to store objects with units in a PropertyList? I was anticipating the latter.

Adding missing value and unit support seems likely to take PropertyList further from being a Python OrderedDict (and PropertySet further from being a dict).

While you're thinking about this, do we support reading a 'NaN' value in the header as a floating-point value?

Paul Price we do support writing and reading NaN to FITS headers (since PropertyList floats can be Nan), but it is not a FITS-compliant thing to do and FITS checkers complain about it. I'd rather not go down that route if we can avoid it.

Kian-Tat Lim I apologize for misrepresenting comment support in PropertyList. I don't know how I managed to forget that. I updated the title and description accordingly.

If we are going to support FITS properly I think support for missing fields is necessary. The trigger is VisitInfo which is often missing some values.

Paul Price are you talking about:

KEYWORD =       NaN / Floating point that came out wrong

or

KEYWORD =     'NaN' / not a number written out as a string

?

I think we want to be able to round-trip floating-point values, so we need to support NaN and +/- Inf. I don't think FITS supports these natively, so you have to write them as strings.

How does writing NAN/Inf as strings help? We would have to do some strange parsing internally, and they would break everything else externally. Plus, strings wouldn't even work for some keywords that must be a certain type.

I don't want to hijack this thread, so let's take the NaN issue offline.

This RFC is accepted as follows:

• PropertyList will be extended to support missing (unknown) values, in a way that is compatible with the FITS standard for header cards.
• PropertySet need not not gain same support, but if it can be added without doing violence to the class, then it would help keep the classes more closely aligned.
• Consider using None as the value for missing values in Python.
• How important this is, and whether we can safely rely on it, depends partly on how pyfits handles headers with missing values. We know pyfits cannot write such headers, but we don't know what happens when it tries to read them.
• Do not add support for units as part of this RFC. Feel free to make a new RFC for that.