Fwd: Re: [Pytables-users] Re: natural naming versus getitem/setitem

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

Ooops, I've recently made changes on my local MTA and set it up badly :(

I'm sending a couple of messages that were incorrectly sent.

Regards,

=2D---------  Missatge transm=E8s  ----------

Subject: Re: [Pytables-users] Re: natural naming versus getitem/setitem
Date: Dimarts 18 Gener 2005 08:57
=46rom: Francesc Altet <fa...@ca...>
To: pyt...@li...

A Dilluns 17 Gener 2005 09:09, Norbert Nemec va escriure:
> Am Montag, 17. Januar 2005 06:12 schrieb russ:
> > I would agree that the natural naming can easily get in the way.  For
> > example, I tried storing stock data into pytables using the ticker
> > symbol as the table name.  However, as it stands you can't use "def" as
> > a table name; the "checkNameValidity" function throws a NameError, since
> > "def" is a python reserved word.
>
> This problem should already be solved in the newest CVS version of pytabl=
es
> (just a little past 0.9.1, I think). A little while ago, it was the first

That's correct, Norbert. With the new version, if one uses a name that is n=
ot
compliant with the natural naming requirements, just a warning is issued:

warnings.warn(""""%s" is not a valid python identifier, so the associated
element cannot be accessed by natural naming. Check for special symbols ($,
%%, @, ...), spaces or reserved words, or be sure to access it later on by
using getattr().""" % (name), NaturalNameWarning)

so preventing the users that such a name will not be able to be used in
natural naming references.

> step to allow non-pythonic names in the first place. Now it would be the
> second step to make it more convenient to access such names.

Yeah, but I have to give to that a more complete thought before stepping
 ahead and implementing that. There are some issues with CSTables (the
 forthcoming client-server version of PyTables) that would have problems
 using:

group["name"] =3D Array()

or even

group.name =3D Array()

This last sentence is perfectly possible now, but may be deprecated in the
future.  However, as I said before, this needs more thought on our part.

Cheers,

=46rancesc

=2D------------------------------------------------------