larry-discuss team mailing list archive

[Keith Goodman <kwgoodman@xxxxxxxxx>]

On Sun, Feb 7, 2010 at 7:23 PM, Keith Goodman <kwgoodman@xxxxxxxxx> wrote:
> 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
>>

Oh, one more thing. I might try

lix('aapl', 'goog', 'intc')

instead of

lix(['aapl', 'goog', 'intc'])

It is easier to type. And there is no confusion about whether I'm
trying to index three separate label elements or one element named
('aapl', 'goog', 'intc'). The only problem is that what if the labels
they want are already in a list? Then they'd have to do lix(*['aapl',
'goog', 'intc']). Hmm...