Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Attributes clashing with reserved words are impossible to write #26

Closed
dopplershift opened this issue Feb 26, 2014 · 5 comments
Closed

Comments

@dopplershift
Copy link
Member

From stephen...@gmail.com on October 09, 2009 09:36:50

This is more a feature request than a bug as it's a problem all
Python->NetCDF bindings suffer. Apologies if this isn't the correct forum.

Attributes clashing with netCDF4 object properties and methods are
unsettable and must be read with getattr (as far as I can see). This
makes writing generic code on top of netCDF4 difficult. I'm sure it's only
a matter of time before I am asked to set a global attribute of
"file_format", "parent", "groups" or the like. What steps will reproduce the problem? $ ncdump test2.nc
netcdf test2 {

// global attributes:
:file_format = "my_format" ;
}
$ python

from netCDF4 import Dataset
d = Dataset('test2.nc', 'a')

The attribute "file_format" is hidden from traditional attribute access

d.file_format
'NETCDF3_CLASSIC'

You can get at it with getattr

d.getattr('file_format')
'my_format'

but not set it

d.setattr('file_format', 'foo')
Traceback (most recent call last):
File "", line 1, in
File "netCDF4.pyx", line 1635, in netCDF4.Dataset.setattr
(netCDF4.c:8163)
AttributeError: 'file_format' is one of the reserved attributes ('_grpid',
'_grp', '_varid', 'groups', 'dimensions', 'variables', 'dtype',
'file_format', '_nunlimdim', 'path', 'parent', 'ndim', 'maskandscale',
'cmptypes', 'vltypes', '_isprimitive', '_isvlen', '_iscompound'), cannot rebind What version of the product are you using? On what operating system? Tested on v0.8.1, linux with netcdf-4.0.1-beta3. Please provide any additional information below. Mirroring NetCDF attributes as Python object attributes is clearly a big
win but I would request an unambiguous alternative method of
getting/setting attributes along the line of the Dataset.ncattrs() function
for listing attribute names. I can help with the coding if you wish.

Stephen.Pascoe at stfc ac uk

Original issue: http://code.google.com/p/netcdf4-python/issues/detail?id=26

@dopplershift
Copy link
Member Author

From whitaker.jeffrey@gmail.com on October 09, 2009 13:12:37

Stephen: Those are attributes used by the API itself, and not actually netcdf attributes written to the file. I don't
see any obvious way around the problem of not being able to have netcdf attributes with those same names.
Suggestions are welcome.

-Jeff

@dopplershift
Copy link
Member Author

From stephen...@gmail.com on October 09, 2009 13:43:54

I propose keeping Dataset/Variable attribute behavior as is but adding another
mechanism of setting/getting NetCDF attributes to allow careful code to get at any
attributes that clash. The most elegant solution would be to have dictionary-like
properties Dataset.attributes and Variable.attributes. In this case
Dataset.ncattrs() is equivalent to Dataset.attributes.keys(). E.g.

d.attributes
{'file_format': 'my_format'}
d.attributes['file_format'] = 'foo'
d.attributes
{'file_format': 'foo'}

I don't know how easy that would be in pyrex but I'll look into it.

Stephen.

@dopplershift
Copy link
Member Author

From whitaker.jeffrey@gmail.com on October 13, 2009 11:01:32

Stephen: OK, I think I've fixed this. In SVN I've added setncattr and getncattr
methods that bypass setattr and getattr. You can use them to set or get
netcdf attributes with the same names as the reserved python attributes. For
instance, you can do this

f.setncattr('dtype','double')
dtype = f.getncattr('dtype')

whereas

f.dtype = 'double'

would fail before

and

f.dtype would always return the numpy dtype, even if there was a netcdf attribute
with the same name.

Let me know if this works for you.

-Jeff

@dopplershift
Copy link
Member Author

From stephen...@gmail.com on October 16, 2009 08:25:18

Looks good to me. Many thanks for this quick resolution.

Stephen.

@dopplershift
Copy link
Member Author

From whitaker.jeffrey@gmail.com on October 16, 2009 09:55:26

Status: Fixed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant