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

[Norbert N. <Nor...@gm...>]

Am Dienstag, 25. Januar 2005 17:39 schrieb Francesc Altet:
> We have given to this quite a deal of consideration. While we agree that
> allowing:
>
> mygroup.mynode= Node(...) #this can be done now, but not a good practice
> IMO!
>
> or
>
> mygroup['mynode'] = 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.

I don't follow that opinion at all. One point to consider, is that this kind 
of node creation is the only one that allows the use of natural naming at the 
point of creation. I simply find it ugly having to switch between using a 
string for naming a node and naming it by natural naming.

Comparing the two snippets:

---------------------
 mygroup.somenode = Table(...)
 row = mygroup.somenode.row
 ...
--------------------
 mygroup._f_createTable('somenode',...)
 row = mygroup.somenode.row
 ...
-------------------

The first one is just a lot more intuitive to read. Furthermore: class 
constructors are a very pythonic concept. Using factories means that users 
have to remember yet another name of a function.

Adding 'where' to the constructor does not seem like a very good idea to me:

The usual behavior of object in python is, that the constructor creates an 
object, but does not link any handle to it, so if you don't preserve the 
reference that the constructor returns, the object is dead immediately.

> 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 = Table() notation. However, this would imply quite a lot of
> work, and this is not a priority for us right now.

Why do you need this as justification for the mygroup.mynode = Table() 
notation? It is clear that "unbound nodes" are an intuitive concept. Even if 
you cannot save and data in them (yet), it should not be hard to grasp what 
it is.

-- 
_________________________________________Norbert Nemec
         Bernhardstr. 2 ... D-93053 Regensburg
     Tel: 0941 - 2009638 ... Mobil: 0179 - 7475199
           eMail: <No...@Ne...>