Gerard Flanagan wrote:
>> py> # the following is probably the trickiest, should it return a Table
>> py> # should it be illegal?
>> py> # should t['Last'] be the way to take the "slice" and get the col?
>> py> t[None, 'Last'] # 1d slice returns list (2nd dim. explicit)
>> ['Barker', 'Burnet', 'Danson', 'Cooper']
>
> I can imagine manipulating columns at the Table creation stage -
> insert, append, delete column - but after that I think you would be
> dealing with rows more often. Personally, if I needed columns I would
> be happier with a list comprehension:
> [ (row['Last'], row['Age']) for row in t ]
> etc.
To make a table from list comprehension in this way seems like it would
require some redundancy because a list comprehension only gets you a
list (of rows or lists). It seems if you wanted to work with your 2d
selection of data, then you would want to get a table back:
data = [ (row['Last'], row['Age']) for row in t ]
t2 = Table(('Last','Age'), data)
This seems, to me, to separates selection in the 2 dimensions and makes
it "backwards":
data = [ (row['Last'], row['Age']) for row in t[1:3]]
t2 = Table(('Last','Age'), data)
So a function would be needed to group the selection in a way that
reflects the organization of the table:
t2 = t.subtable((1,3), ('Last','Age'))
But then, since the latter seems a natural consequence of using list
comprehension for selection, how might one distinguish a range of
columns if not by a verbose function name?
t2 = t.subtable_with_column_range((1,3), ('Last','Age'))
The concept of slicing seems to take care of this. Maybe
t2 = t.subtable(slice(1,3), slice('Last','Age'))
But this begins to seem awkward and verbose to boot. Any suggestions on
adapting your idea of list comprehension to generate subtables?
> eg. like:
>
> http://buzhug.sourceforge.net/
>
>> py> t2 = t[1:3, ('First', 'Age')] # 2d slice returns a new Table
>> py> t3 = t[1:3,'First':'Age'] # shorthand to take a swath of columns
>> py> t3 = t[1:3, 0:2] # if we know what column numbers we want instead
>
> t[1:3][0:2] and so on would be more intuitive to me, possibly
> t[1:3]['First':'Age']
This looks better than my slicing, and to argue with it I'd have to
break my own rules and point out that it would require making an
intermediate table in the implementation. I am emulating numarray
slicing closely, which itself is probably focused on implementation and
speed.
James
--
http://mail.python.org/mailman/listinfo/python-list
