[Pytables-users] unbound nodes (again)

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

En/na Ivan Vilata i Balaguer ha escrit::

> Please also have a look at the syntax used in the HDF5 RFC at
> http://hdf.ncsa.uiuc.edu/RFC/linkEncodings/Character_Encoding.pdf::
>=20
>     dataset_id =3D H5Dcreate(dataspace, datatype, DCPL, DAPL, DXPL)
>     H5Lcreate("dataset name", dataset_id, LCPL)
>=20
> Dataset creation and link (name/directory entry) creation are separated=

> in the new interface, so maybe PyTables 2 would not have problems in
> *actually storing data* in unbound nodes.

The previous example would be translated to PyTables 2 like this::

>>> array =3D Array([1,2,3])
>>> group.myarray_ =3D  array  # interactive interface, or...
>>> group.link(array, 'myarray')  # programmatic if. (methods), or...
>>> group['myarray'] =3D array  # programmatic if. (dictionary)

(``link()`` could also be named ``addChild()`` or similar.)

But the HDF5 hierarchy is not properly a tree, but a graph.  Then, we
could follow with:

>>> group.samearray_ =3D array

With no problems on the HDF5 side.  That reminds us a truth in HDF5 and
Un*x filesystems: files in themselves *do not have a name, nor a path*.
 Paths and names are only a concatenation of links in groups.  Then,
moving and renaming operations should be provided by groups, not nodes,
i.e. no ``node.rename('newname')``, but ``group.rename('oldchildname',
'newchildname')``.

This opens a new range of chances and problems, but I think we should
not avoid them in order to not lag behind HDF5 functionality.

::

	Ivan Vilata i Balaguer   >qo<   http://www.carabos.com/
	       C=C3=A1rabos Coop. V.  V  V   Enjoy Data
	                          ""