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

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

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= 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 necessary data to create a 
physical node in a file once it is assigned to a group member.

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.

The nice thing about the above syntax is, that it allows natural naming 
throughout the lifetime of an item. Having to switch between 'stringified' 
naming and natural naming for the same item just looks ugly in my eyes.

The above syntax makes clear that the created object has just one name: 
 mygroup.mynode
used for creating handling and deletion. Any aliases made for this name are 
explicit and easy to understand.

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