From: Ivan V. i B. <iv...@ca...> - 2004-09-27 10:29:56
|
On Thu, Sep 16, 2004 at 01:14:12PM -0400, st...@st... wrote: > Removing the __call__() methods would make me happier. > In code I (should) always write the long version anyway, > because it is easier to read. And interactively, the > call methods save steps only at a normal python prompt, > they are an inconvenience in ipython.=20 I absolutely agree with removing those methods, since they quite obscure the source. In fact I am writing this mail to discuss a new interface I have devised for navigation in PyTables. Of course it is not my intention for it to go into the next version, but I'd appreciate your opinion. I call this the =E2=80=9Cheaven and earth=E2=80=9D interface, but I r= ecognise the name is quite arbitrary. Given the following hierarcy: (root) at1-. / \ .-at1 at2--(g1) [t2]--at2 / \ [t1] [a1] This hierarchy has two parallel =E2=80=9Cnatures=E2=80=9D, one that c= an be accessed by string paths (such as '/g1/a1') using the getNode() method, and one that can be accessed by natural naming. Given a node in the hierarchy, one can =E2=80=9Cwarp=E2=80=9D from one nature to the other. = We will call the first nature the =E2=80=9Cheaven=E2=80=9C nature, and the second one = the =E2=80=9Cearth=E2=80=9D nature. In the heaven nature, node and attribute identifiers are never used as Python identifiers, but strings, which would allow them to have any form (as long as they have no slashes). As said, nodes are accessed via the getNode() method, so any other method name can be used with no risk of clashing. Attribute sets are accessed via a node's getAttributes() method (alternatives: an attributes() method or an =E2=80=9Cattrs=E2=80= =9D attribute). Attributes in an attribute set may be accessed using some method, which could easily be __getitem__() (i.e. attrs['attrname']). In the earth nature, node and attribute identifiers are used as Python identifiers, so their form is restricted. Method names and special node attributes *always* start with =E2=80=9C_=E2=80=9D. Since the earth nature is aimed to interactive usage, the set of methods supported by a node or attribute set might be quite reduced, maybe only covering read-only access methods. The reason for this is avoiding redundance between heaven and earth classes. However, if the whole functionality is desired in both class types, coding the heaven methods in terms of the earth ones would simply be a matter of warping, calling the earth method and possibly warping back the result. root =3D h5file.getNode('/') g1 =3D h5file.getNode('/g1') g1 =3D root.getNode('g1') # Non-leaf nodes have a getNode() method ... t1 =3D g1.getNode('t1') # ... but only relative paths are allowed. a1 =3D root.getNode('g1/a1') t2 =3D h5file.getNode('/t2') # Absolute paths are only allowed on File ob= jects. # What if '.', '..', and absolute paths were allowed (using weakrefs) # on any (not only non-leaf) object? # t1 =3D g1.getNode('/g1/t1') # t1 =3D g1.getNode('./t1') # a1 =3D t1.getNode('../a1') # Getting a node's attribute in heaven. g1_at1 =3D root.getNode('g1').getAttributes()['at1'] # g1_at1 =3D root.getNode('g1').attributes()['at1'] # g1_at1 =3D root.getNode('g1').attrs['at1'] # Warping to earth. e_root =3D root.warp() e_g1 =3D e_root.g1 e_a1 =3D e_g1.a1 # Getting a node's attribute in earth. e_g1_at1 =3D e_g1._attrs.at1 e_g1_at2 =3D e_g1._attrs._warp()['at2'] e_t2_at2 =3D e_root.t2._attrs.t2 # Warping back to heaven. t1 =3D e_g1._warp().getNode('t1') # Example of earth node methods. def _someMethodReturningANode(self, args): return self._warp().someMethodReturningANode(args).warp() def _someMethodNotReturningANode(self, args): return self._warp().someMethodNotReturningANode(args) What do you think of this proposal? Does it look more or less intuitive? Do you guess more or less immediate problems (apart of interface incompatibility, of course)? Regards, Ivan --=20 Ivan Vilata i Balaguer @ FIGHT AGAINST SOFTWARE PATENTS! @ http://www.selidor.net/ @ http://EuropeSwPatentFree.hispalinux.es/ @ |