From: Francesc A. <fa...@ca...> - 2004-12-14 13:23:34
|
A Dimarts 14 Desembre 2004 13:01, vareu escriure: > In my case, for example, I produce one .h5 file containing several groups. > The core distinction between them is just one floating point parameter, = say > E, that runs over several values, say {0.0, 1.5, 2.3}. Most natural woul= d be > to call the groups "E=3D0.0", "E=3D1.5" and "E=3D2.3". Every other name = I could > give is artifical and meaningless. (Currently, I'm creating names like > "data1", "data2" and "data3".) Natural naming is not an option anyway, s= ince > I'm looping over the groups all the time and even create them with a loo= p. >=20 > Considering all of this, I would suggest that any kind of name should be > allowed for nodes (are there any limitations given by HDF5?) Even reserved > prefixes need not necessarily be prohibited. Everyone has to understand t= hat > they cannot be accessed by natural naming, but if you don't use that, why > should you be unnecessarily restricted? Good observation. And no, HDF5 does not put any limitations (that I'm aware of) on node names. Mmmm... on the other hand, I really find natural naming to be *really* useful specially in interactive mode. However, I agree that this should be a decision on the user. What about replacing the NameError exception with an UserWarning? The other possibility is allowing any string as node or attribute name, even if they cannot be used by natural naming, without any warning at all. What do you think is best? Other people would chime in? > I think this should be cleared first, since it might mean that we don't n= eed > any Exceptions for that case at all. Agreed. =2D-=20 =46rancesc Altet Who's your data daddy? =A0PyTables |