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

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

In the very interesting thread "__getattr__ vs. __getitem__ (Natural
naming)". The following improvements were suggested:

>>>To sum up:
>>> * __dict__ should contain only the immediate children. It is not clear
yet, 
>>>whether it should only contain the pythonic names or all names.

and,

>>>whether it should only contain the pythonic names or all names.

I also think that __dict__ should allow non-pythonic names for the children
names (if __getitem__ is added to Group). If someone wants to use
non-pythonic names he must assume that he might find problems related to
accessing nodes with group.__getattr__ or problems with the key-completion,
but IMO should be allowed. 

Often names used to identify or classify things in a computer is becoming
closest to human language. So I think is a good idea to support
non-programming-language identifiers.

>>>* __getitem__ and __getattr__ might well allow additional keys that are
not 
>>>advertised in __dict__: these will not show up for key-completion but
they 
>>> will work nontheless.

>>>* it might make sense to do "/" parsing in __getitem__, such that
>>>  something["abc/djk"]
>>>is internally read equivalently to
>>>  something["abc"]["djk"]
>>> or
>>>  something.abc.djk
>>>Of course, "abc/djk" should not appear in __dict__

I agree with you and I do think this would be really useful, since allowing
a pathname in __getitem__ will allow direct access to the desired node
without walking through the hierarchy. Besides, this would improve
performance even in the case of a cached object tree [I'm thinking from a
client-server point of view, i.e. CSTables]. Of course, pathnames used in
__getitem__ should be relative to the group in wich __getitem__ is used. For
absolute paths we can use file.root (that will be relative to root too).

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.

So I suggested the following (that is not currently implemented):

a=mygroup.createArray('mynode', [1,2])

That is pretty simple and clear and will return a correct bound array.

Another option for using the constructor with bound objects is:

a=Array(file.root, '/group/myarray',[1,2])

or

a=Array(file.root.group, 'myarray', [1,2])

which results in a bound and actually correct node.

Any suggestions about these alternatives?