Re: [Pytables-users] RFC: Natural naming proposal for PyTables 2.

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

En/na Francesc Altet ha escrit::

> A Dissabte 15 Octubre 2005 15:25, Norbert Nemec va escriure:
>>
>>Even if unbound nodes are still a far way off, there is nothing wrong
>>about following the design idea now. I think the idea of unbound nodes
>>is something very clear to understand for the user, even if - for the
>>time being - these nodes are seriously limited until they are actually
>>written to disk.
>>
>>Of course, checking whether a node is bound costs a tiny bit of
>>performance, but that certainly can be minimized.
>=20
>=20
> One can always use an "assert" instructuction, and if maximum speed is
> needed, pass the -O option to python.
>=20
> What other people think? Implementing this would improve readability
> of the code? My opinion is starting to change and I think it does.

The following three threads may be interesting, because the same
problems are touched in them (but keep in mind we are now talking of an
entirely different release of PyTables):

*
https://sourceforge.net/mailarchive/forum.php?thread_id=3D6361641&forum_i=
d=3D13760
*
https://sourceforge.net/mailarchive/forum.php?thread_id=3D6391459&forum_i=
d=3D13760
*
https://sourceforge.net/mailarchive/forum.php?thread_id=3D6412440&forum_i=
d=3D13760

Please also have a look at the syntax used in the HDF5 RFC at
http://hdf.ncsa.uiuc.edu/RFC/linkEncodings/Character_Encoding.pdf::

    dataset_id =3D H5Dcreate(dataspace, datatype, DCPL, DAPL, DXPL)
    H5Lcreate("dataset name", dataset_id, LCPL)

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.

::

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