Re: [Pytables-users] RFC: Natural naming proposal for PyTables 2.

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

What is wrong about checking whether a node is bound and say
"manipulations to unbound nodes not yet implemented" if people to
anything to them before they are assigned to a on-disk group?

Even if unbound nodes are still a far way off, there is nothing wrong
about following the design idea now. I think the idea of unbound nodes
is something very clear to understand for the user, even if - for the
time being - these nodes are seriously limited until they are actually
written to disk.

Of course, checking whether a node is bound costs a tiny bit of
performance, but that certainly can be minimized.

Greetings,
Norbert


Francesc Altet wrote:

>A Dijous 13 Octubre 2005 00:46, Norbert Nemec va escriure:
>  
>
>>OK, this opens a different topic: unbound nodes. Personally, I think
>>that creating a node like
>>
>>    h5file.root.somenode = Array(somedata)
>>
>>is the most natural way to do the job. It is always said that unbound
>>nodes should be avoided. I believe, however, that this is a move in the
>>wrong direction.
>>    
>>
>
>I also do like *very much* this way of creating nodes. However, as you
>already said on a previous message, the problem is what it is supposed
>that the user is going to do with such an unbound node other than
>bounding it to a node on a file. If we could force something like:
>
>     h5file.root.somenode = Array(somedata)
>
>as the only thing that is allowed to the user, then I'd gladly vote
>for this. However, I'm afraid that we can't prevent the user doing
>things like:
>
>node = EArray(somedata)
>node.append(someotherdata)
><lot of bad message errors appearing....>
>  
>
>So, at least until nodes in-memory would be supported, I don't think
>this is going to be a good idea. You can still use it, if you want,
>but documenting it and stimulating its use for every kind of user
>could be an unnecessary source of confusion, IMO.
>
>Cheers,
>
>  
>