[Pytables-users] Heaven and earth interface [Was: Special __call__ method...]

[Ivan V. i B. <iv...@ca...>]

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/ @