Re: [Pytables-users] __setattr__/__delattr__ for existing/nonexistant group members

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

Am Donnerstag, 9. Dezember 2004 11:10 schrieb Francesc Altet:
> A Dissabte 04 Desembre 2004 12:01, Francesc Altet va escriure:
> > A Dissabte 04 Desembre 2004 11:44, Norbert Nemec va escriure:
> > > Now in pytables:
> > > -----------------
> > > from tables import *
> > > h5file = openFile("dummy.h5",'w')
> > > h5file.root.asdf = Group()
> > > h5file.root.asdf = Group()  # NameError: '/' group already has
> > >                             # a child named 'asdf' in file 'dummy.h5'
> >
> > Yes, I wanted to protect somewhat the attributes so that a user has to
> > delete it before being overwritten. But you are probably right in that we
> > PyTables should follow as carefully as possible the python behaviour.
>
> Mmm, I'm afraid that I was a bit out of context when I wrote this. I
> thought that we were talking about attributes of nodes, but in fact we are
> talking about *childs* of objects, and I do believe that PyTables should
> offer some protection against overwriting a node (or even a complete
> subtree), specially when used interactively (you don't want to loose lots
> of data because a typing mistake, would you?).

True. Maybe one could have an option to deactivate this security measure? Just 
some library-wide option that you switch off if you want to take the risky 
route.

On the other hand, overwriting elements like Arrays probably is not very 
efficient anyway, so it should be avoided. Making it necessary to delete an 
object before assigning it anew might be a way to let people think about that 
strategy again.

> I think we should regard the object tree more as a multi-level dictionary
> rather than an ordinary object with attributes. In that sense, I should
> change the NameError above by a KeyError. What do you think?

The question of dictionary vs. object has little to do with the question of 
overwriting elements. Currently, PyTables is built upon attributes. I think 
changing this is out of question (compatibilty!)

As long as you are dealing with attribute exceptions, only AttributeError 
should be used. (docs: "Raised when an attribute reference or assignment 
fails.") Neither NameError nor KeyError have anything to do with this issue.

> On another hand, I've changed the RuntimeError raised during overwriting
> read-only system atributes to AttributeError.
>
> > > del h5file.root.asdf
> > > del h5file.root.asdf   # this just does nothing
> >
> > Ops, this should raise AttributeError of course.
>
> For the same reason as stated before, it should raise a KeyError.

Again: no. This is dealing with attributes, not with keys of a dictionary.

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