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

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

A Dilluns 31 Gener 2005 12:26, Norbert Nemec va escriure:
> Also, 'data' should probably be the first parameter and have no default.
> Since the method is renamed anyway, compatibility should not be an issue.

Agreed

> Basically, it should first be decided which ways should exist for
> addressing rows in general. I would vote for the option of greatest
> flexibility, even if certain methods of addressing might not be very
> efficient.
>
> The most complete set of parameters would be something like
>  start=3DNone, stop=3DNone, step=3D1, rows=3DNone, columns=3DNone
> where 'rows' does what 'sequence' and 'coords' to up to now. 'columns'
> might not exist for all routines (e.g. remove) that can - by principle on=
ly
> address whole rows.

That sounds reasonable. What about making rows --> rowlist and
columns --> columnlist?

> I would suggest dropping the automatic sorting of sequences. Documenting
> that unsorted lists kill the performance should be enough. I think it is
> better if a user who is unaware of the issue gets bad performance than
> wrong results.

I disagree in this point. Sorting an object in-memory is a relatively
fast operation, while retrieving an un-sorted sequence from disk can
be *killer*. The default should be the solution that less impact on
performance, and this is sorting my default. On optimization-consciuos
user can read the manual and try to disable sorting, if appropriate.

> > > 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
>
> Anyway, it just looks much better if the interface is clean and complete
> and simply documents which features are not implemented yet, giving an
> error message. You can even place a comment in the documentation mentioni=
ng
> the difficulties and inviting people to help out.

I disagree again: if a parameter is not implemented, I think it is
better to not allow it. If I were going to implement this feature in a
short term, that could be different. But the reality is that I don't
plan to address this for a long while, at least, the efficient version
(the reason is that the required effort would be much higher than the
benefits that this will report).

However, perhaps it could be useful to add 'step' for remove and
implement this in as a sequence of remove(start,stop) that fakes the
intended behaviour. It would not be very efficient, but...

> > 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!
>
> OK - I already considered it. As before I cannot really promise when I
> might to it. Should we find some way of coordinating this effort? I would
> like to avoid the confusion we had some time before...

Well, not me nor Ivan are going to address any of these issues for a
while (at least in a couple of weeks or so). So feel free to download
a recent snapshot (preferibly after this night, as I've fixed a couple
of things today in Table.py):

http://www.carabos.com/downloads/pytables/snapshots/

and work on that.

Cheers,

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