Programming Language that is Spreadsheet/Table Based

James Stroud jstroud at
Sat Nov 4 06:59:44 CET 2006

Omar wrote:
> I'm looking for a programming language or module that sorta looks and
> feels like MS Excel (I love and think in tables), yet has the power and
> open-endedness of python or javascript.  I'm still pretty new to
> python.
> any ideas?  i've been having some fun with VBA in excel, but I want
> something I can save as en exe and call my own creation, y'know?

More than the implementation, I would be curious about the API you (or 
anyone else) might envision. I have spent a lot of time making a "Table" 
class over about the last year and a half, but I'm not sure what might 
be an intuitive interface for most people. First, I think it should work 
like a "sorted" dictionary of lists, but, at the same time, a list of 
sorted dictionaries. I also want *shorthand* for selection.

For example, does the output below look like an intuitive interface? Or, 
more likely, how many people get squeamish when they see this interface? 
Do these squeamish people have any better ideas? This is a taste of how 
my Table class currently behaves:

py> print t     # dependent on its property t.format
     Last      First      Age
     Barker    Bob        204
     Burnet    Carol      64
     Danson    Ted        54
     Cooper    Alice      78
py> t.headings()
("Last", "First", "Age")
py> t.get_row(1)   # approximately equal clarity with 1d slice
['Burnet', 'Carol', 64]
py> t[1]     # implicit selection of "first" dimension
['Burnet', 'Carol', 64]
py> t.get_column('Last')  # probably clearer than taking a 1d slice
['Barker', 'Burnet', 'Danson', 'Cooper']
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']
py> t2 = t[1:3, ('First', 'Age')]  # 2d slice returns a new Table
py> t2
<__main__.Table instance at 0x404f676c>
py> t2.format
Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
AttributeError: 't2' object has no attribute 'format'
py> t2.format = "%10s   %4d"
py> print t2
      First    Age
      Carol     64
        Ted     54
py> t3 = t[1:3,'First':'Age']  # shorthand to take a swath of columns
py> t3.format = "%10s   %4d"
py> print t3
      First    Age
      Carol     64
        Ted     54
py> t3 = t[1:3, 0:2]  # if we know what column numbers we want instead
py> t3.format = "%10s%10s"
py> print t3
       Last     First
     Burnet     Carol
     Danson       Ted

These latter selections might turn some heads, especially for those who 
think a a little too deeply about dictionaries. But, unlike a 
dictionary, a Table is ordered. If you disagree with the assumption that 
tables are ordered, make a table in excel, save it, close it, open it 
again and see that the columns are still in the same order. Do this 1000 
times to convince yourself. The table will be in the same order every 
time! Amazing!

The idea is that tables are not dictionaries--please resist drawing 
paralells. If we strangle ourselves with operating under the dictionary 
paradigm, we will never get a Table. Trust me, I've thought about it 
more than most. (If you want a Table to act like a dictionary, I can 
make a RandomTable class just for you.)

Notice also that slicing can be done with a tuple or a list, so type 
checking is done in the implementation--but lets forget about our 
notions of impementation and how type checking is "bad". I want to get 
feedback on the API here without regard to how it might be implemented.

In a Table, the first dimension is row and the second is column (i.e. 
the data is organized by rows). My Table class has a lot of additional 
functionality. But, I'm curious about how people see such a beast 
working, though. Please don't criticize unless you have a better idea 
about the API of a Table. I want to hear genuine and concrete ideas and 
not abstruse pontification about programming or design! Statements of "I 
wouldn't do this thing here" should be immediately followed by 
"--rather, I would do this other thing for which I've created a concrete 
example below."

If you think this interface is genius, well my ego wants to hear about 
that as well, but its not terribly necessary.


James Stroud
UCLA-DOE Institute for Genomics and Proteomics
Box 951570
Los Angeles, CA 90095

More information about the Python-list mailing list