Read namelist into Python object

[jacobwilliams]

I was wondering if a good feature might be to be able to read the namelist into a Python object, rather than a dictionary. So, for example, rather than accessing the variables like:

z = nml['x']['y']['z']

we could use:

z = nml.x.y.z 

That would be pretty slick, I think.

[marshallward]

I've thought about that as well, since typing out the dict syntax can be tedious, although there are people who consider it bad practice. It can lead to namespace collisions with existing properties, for example. It could go under nml.vars though.

(I think the netcdf4python project does something like this? I would need to check)

In any case, it could be doable with some @property trickery. I'll try to look into it.

[jacobwilliams]

FYI: just for fun, I hacked together something based on these posts:

• http://goodcode.io/articles/python-dict-object/
• http://stackoverflow.com/questions/2405590/how-do-i-override-getattr-in-python-without-breaking-the-default-behavior

By adding these methods to class NmlDict:

    def __getattr__(self, name):
        if name in self:
            return self[name]
        else:
         #default behavior:
         return OrderedDict.__getattr__(self, name)

    def __setattr__(self, name, value):
        if name in self:
            self[name] = value
        else:
         #default behavior:
          return OrderedDict.__setattr__(self, name, value)

Example run:

import f90nml

n = f90nml.read('test/comment_patch.nml')

n.comment_nml.v_cmt_in_str
Out[3]: 'This token ! is not a comment'

n.comment_nml.v_cmt_in_str = '2'

n.comment_nml.v_cmt_in_str
Out[5]: '2'

n['comment_nml']['v_cmt_in_str']
Out[6]: '2'

Seems to work for this one example (I haven't done any further testing). I have no idea if this is a good solution or not, or if there are some other side-effects that might crop up.

[marshallward]

Looks good, I am in favour of this.

But some way to prevent interference with the configuration flags (nml.colwidth, nml.indent, &c.) would need to be sorted out. And I would hate to tag them as reserved keywords.

The whole configuration method has not even been documented, so there is plenty of space to restructure it.

[jacobwilliams]

I might tinker with it some more. Maybe there is a way to get the n.vars.comment_nml.v_cmt_in_str syntax to work with this to avoid collisions.

[marshallward]

I have been playing around with this, and it's actually much safer than I had originally thought. I wonder if the vars thing is unnecessary.

It might still be good to introduce some sort of warning if there's a collision. It could get confusing if the types are the same.

Honestly the whole thing still strikes me as reckless, but I have to admit it is super convenient.