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

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

Am Montag 31 Januar 2005 11:16 schrieb Francesc Altet:
> > * the parameter names modifyRows(rows=...) and modifyColumns(columns=...)
> > 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.

Also, 'data' should probably be the first parameter and have no default. Since 
the method is renamed anyway, compatibility should not be an issue.

> > * 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.

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=None, stop=None, step=1, rows=None, columns=None
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 only address 
whole rows.

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.

> > 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=
>
> 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....

Neither I nor anyone else will blame you for features that are 'not 
implemented'. It is tremendous what you did already!

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 mentioning the 
difficulties and inviting people to help out.

> 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...

Ciao,
Nobbi

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