Re: [Pytables-users] Unbound nodes. [was: ( __getattr__ vs. __getitem__ (Natural naming)]

[Francesc A. <fa...@ca...>]

Hi,

A Dissabte 22 Gener 2005 14:06, Norbert Nemec va escriure:
> Am Donnerstag, 20. Januar 2005 21:07 schrieb Andreu Alted Abad:
> > And finally I would like to mention an example that was used many times
> > along this thread:
> >
> > mygroup.mynode=3D Node(...)
> >
> > Some time ago I was discussing with Francesc about the correctness of
> > using node constructors in the client code. My perception was that this
> > notation only could bring problems since the instance created with the
> > constructor is not bounded to any pytables file, and more importantly, =
it
> > has no utility except be assigned to a group after his creation; any
> > other uses would end with an error.
>
> You call this thread "Unbound node" which already shows one possible
> solution: Make unbound nodes an offical part of PyTables. A node can be
> created, and is unbound at first, but it already contains all the necessa=
ry
> data to create a physical node in a file once it is assigned to a group
> member.

We have given to this quite a deal of consideration. While we agree that
allowing:

mygroup.mynode=3D Node(...) #this can be done now, but not a good practice =
IMO!

or

mygroup['mynode'] =3D Node(...)

can easy the work to the programmer (or at least, to some programmers), the
fact that a Node() in itself has not a real utility (or at least, not the
utility it was primarily designed for), may lead to innecessary confusions
for users. So, my opinion is that this should not be regarded (and hence,
not documented) as a feature.

We have even considered the possibility to add a new parameter to the node
constructor, for specifying the path of where the object should be created,
something like:

Table(where=3Dmygroup, name=3D'mynode', ...)

but, again, I find this a bit confusing (and would require some work both in
PyTables and CSTables). I very much prefer creating the node through the use
of factories than using class constructors. Maybe I'm biased because of my
habits, but this is how I feel like.

However, we plan to add a few methods to Group in order to easy the creation
of nodes. Most probably, we will implement: Group._f_createGroup,
Group._f_create*Array and Group._f_createTable that will do the similar
thing than their counterparts in File. Besides, we plan to add support for
Group.__getitem__('nodename') and Group.__delitem__('nodename'). With that,
we think that node creation and referencing would result somewhat improved.

> The simple option would then be that - as you say it - writing or reading
> unbound nodes is prohibited and raises an exception. Maybe, though, it
> would even prove useful to consider unbound nodes just like regular nodes
> that are simply located in memory and on disk. I don't know the
> implications of this, but maybe, temporary tables in memory even have some
> practical use - be it only to defer physical writing to some defined point
> in the future.

Temporary tables (or arrays) in memory would be nice, and of course, is an
option for the future. And their single existence would justify the
mygroup.mynode =3D Table() notation. However, this would imply quite a lot =
of
work, and this is not a priority for us right now.

Cheers,

=2D-=20
>qo<   Francesc Altet =A0 =A0 http://www.carabos.com/
V =A0V   C=E1rabos Coop. V. =A0=A0Enjoy Data
 ""