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

[Francesc A. <fa...@ca...>]

A Dijous 09 Desembre 2004 19:55, Norbert Nemec va escriure:
> True. Maybe one could have an option to deactivate this security measure?=
 Just=20
> some library-wide option that you switch off if you want to take the risk=
y=20
> route.

It's a possibility...

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

I definitely like this approach better

> The question of dictionary vs. object has little to do with the question =
of=20
> overwriting elements. Currently, PyTables is built upon attributes. I thi=
nk=20
> changing this is out of question (compatibilty!)
>=20
> As long as you are dealing with attribute exceptions, only AttributeError=
=20
> should be used. (docs: "Raised when an attribute reference or assignment=
=20
> fails.") Neither NameError nor KeyError have anything to do with this iss=
ue.

Well, I think we should expand somewhat the meaning of "attribute" concept
here. To my eyes, an object like "fileh.root.table" is not an attribute, but
a Leaf (or more generally a "node"), which has a very different meaning from
an object like "fileh.root.table.attrs.attribute" which is closer to the
Python concept of "attribute". It just happens that "fileh.root.table" is
the way that PyTables has chosen to specifiy a node in the object tree (the
so-called "natural naming"). This is why I think there is an intrinsic
difference between a "node" and an "attribute", and why they should be
treated differently (even raise different exceptions).

Cheers,

=2D-=20
=46rancesc Altet
Who's your data daddy? =A0PyTables