Re: [Pytables-users] clean up Table addressing?

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

A Dijous 27 Gener 2005 19:42, Norbert Nemec va escriure:
> just been working with tables a bit. The methods of the Table class and t=
he
> parameters they take (especially the naming) utterly confuse me. Some
> examples:
>
> * as I understand it, modifyRows and modifyColumns do nearly the same
> thing, except that the latter variant gives the additional flexibility of
> modifying only certain rows. Why not drop the first variant and rename the
> latter to .modify(...) ?

Yes, it seems like you are right. What happened is that I started
implementing modify() for complete rows. Then, I realized that
some method for modifying specific columns would be nice as well, so I
ended implementing modifyColumns(), and renaming modify() to
modifyRows().

But now, it seems like modifyColumns embeds all the functionality
under modifyRows, so I'll take your advise and try to make modifyRows
to disappear.

> * the parameter names modifyRows(rows=3D...) and modifyColumns(columns=3D=
=2E..)
> are badly confusing. The name 'data' for this parameter would be much more
> intuitive

Yeah, specially with modifyColumns, where the columns parameter can
play the role of columns or rows, depending on the object passed (a
list of columns or a RecArray). 'data' can be a good name, yes.

> * why is the parameter of read() called 'field' - I think we are talking =
of
> columns.

Agreed. This was a reminiscence of pytables 0.1 or so, when columns
were called 'fields'. This has to change.

> * If modifyColumns() allows to select an arbitrary number of columns, why
> is read() restricted to all or one? Hopefully, the parameters
> read(field=3D...) and modifyColumns(names=3D...) should be unified and gi=
ven
> the same semantics.

Good suggestion as well! I'll try to do that, but that would require
some work before being able to provide that.

> * why does one single routine 'read' support both start,stop,step and
> coords, while iterrators do need two different names for that?

You mean itersequence() that has a parameter named as "sequence"?.
Well, the truth is that coords was meant for internal use only,
specially for indexing-related issues. However, I've made the error of
documenting it in read (but just the in-line docs).

But this is a good point. The truth is that I don't know which name
would represent better its meaning. Which do you prefer, 'coords' or
'sequence'?. 'indexes' would also be a possibility, but that may
interfere with indexing capabilities.

> * all the routines addressing rows take some (seemingly) arbitrary subset
> of {start, stop, step, coords, sequence, condition}. Intuitively, I would
> expect a set of routines to read, modify, remove and iterate that take the
> same uniform addressing with the same semantics.

Agreed again!.

> It is really irritating if
> you first think you could use some addressing and then realize that, for
> some unknown reason, 'remove' does not support step=3D

Well, that maybe irritating for you, but the sad truth under this is
that all this extended slicing support has been provided after a *very
hard work* on my part. If there are bits that does not support a
"step" parameter in 'remove' yet, it's not due to my lack of
willingness, but because it is very difficult to implement. However,
if you want to address this and provide a patch I'll include it.

> I could probably go on like this, but I think I'll better stop here. There
> certainly are good reasons for some of the points I mentioned, but I gues=
s,
> other newbies would wonder about exactly the same points, so it might yet
> be worth reconsidering them.

Yes. I agree that all of this needs a general, careful, overhauling.
I'll try myself to address this issues. Moreover, if you want to
provide patches for any of that, they will be more than welcome!

Thanks for providing this feedback anyway. This will hopefully
contribute to make a more consistent API before releasing PyTables
1.0.

Cheers,

=2D-=20
>qo<   Francesc Altet =A0 =A0 http://www.carabos.com/
V =A0V   C=E1rabos Coop. V. =A0=A0Enjoy Data
 ""