larry-discuss team mailing list archive

[Keith Goodman <kwgoodman@xxxxxxxxx>]

On Sun, Feb 7, 2010 at 7:11 PM,  <josef.pktd@xxxxxxxxx> wrote:

> If you want to go this way, you could have lixs :  lix with strings,
> and lixr : lix with repr , ... ?
> lix would be safe  because it uses the labels directly, the other ones
> are only recommended in restricted cases where the string (or other)
> representation makes sense.

Too confusing with two I think.

> if you want to allow slicing i.e. `:`  then I think lix would need to
> use its __getitem__ instead of __call__ or __init__
> lar1[1:4, lix['msft', google], lixs['2010-02-01':]   or lar1[1:4,
> lix[['msft', google]], lixs['2010-02-01':] ?

lar1[lix(date)]: will work. So will lar[lix(date1):lix(date2)]

Allowing slices slows things down because now we have to look instead
each slice object (slice.start, slice.stop) for lix object and if
found convert them.

> I don't know if lix should hold some code for conversion from label
> representation to indices, or be just an identifier for use in
> larry.__getitem__

Yeah, a method getindex that takes label as input, perhaps. larry's
getitem is already getting harry, so keeping the code in lix instead
of adding yet more code to getitem might be a good idea. Or make a
function in util.misc like a did for string indexing.

> Josef
>