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

[Andreu A. A. <aa...@ar...>]

> De: pyt...@li... 
> [mailto:pyt...@li...] En nombre 
> de Ivan Vilata i Balaguer
> Enviado el: viernes, 21 de enero de 2005 10:10
> __getattr__ vs. __getitem__ (Natural naming)]
> 
> On Thu, Jan 20, 2005 at 09:07:16PM +0100, Andreu Alted Abad wrote:
> [...]
> > And finally I would like to mention an example that was used many 
> > times along this thread:
> > 
> > mygroup.mynode= 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.
> [...]
> 
> I don't see much technical difficulty in this change: 
> File.create* methods basically do not do anything beyond 
> getting the destination group, creating the object and 
> assigning it using setattr.  With the new model, some very 
> simple checking should be added to leafs and groups to check 
> if they are bound before doing some operations (including 
> assigning them into a Group, which is already done by using a 
> mutual call pattern).

And the result of this checking what will be...?
a=Array([1,2])
a.read()
1) Exception: "read is not supported in unbound nodes"
2) None

The problem is why to maintain the concept of unbound nodes:

Unbound nodes are not supported in pytables, but is supported the creation
of unbound nodes.
The following sequence of instructions results in a exception:

a=Array([1,2])
a.read()

Or any other methods you call.
There is a mechanism to convert unbound nodes in bound nodes:

mygroup.mynode=a

And after that no errors will be produced, yes. 
But, why to keep the concept of unbound nodes?
I am thinking in very useful applications to unbound nodes like in-memory
nodes that could be rebound to the file, allowing a personalized
data-in-memory cache for the user, or simply use them to work with volatile
data.
The problem is that this is not implemented.
So, the only utility for unbound nodes is be bounded to a file. 
And, why not create them directly bounded? And avoid: 1)A concept that is
not supported, 2)Errors derived from that.


>     Although having unbound nodes might seem incorrect, using 
> create* methods forces some knowledge into the File (it would 
> also on Group) objects which I think they need not have.  

mmm I don't know what is better for remember, methods on Group nodes or the
parameters required in each node constructor.
File.create* methods are supported and are actually the standard,
Group.create* will be nearly identical and simplest.
And we could invent a NodeCreator interface that File and Group implements
(or they are descendants of a Creator class), so only NodeCreator methods
might be remembered.

> However, if create* methods were to be used anyway, I prefer 
> them to belong in Group objects rather than File, to avoid 
> walking the whole tree structure as you mentioned.

File.create* must be supported for compatibility. 
For best easy-to-use usage the best placement for create* methods are Group
objects. But, in the implementation view File should keep all the logic of
this methods, because File is the real container (groups are containers of
other groups, but following the recursion the container of the root Group is
a File instance).
So implementing Group.create* would be very simple:

class Group:
	def createArray(self, name, data):
		return self._v_file.createArray(self, name, data)

I prefer File as the instance who contains all the logic because there will
be many instances of a Group, and the code will be more maintenable in a
File instance. Besides, in the concept-problem point of view and not in the
easy-to-use point of view, File should be the class that was in charge of
this task.

So, I think File.create* methods should exist forever, but could be
contemplated, in a future, if they should be private if Group.create*
methods are implemented.