> > ...sqlite3 provides another way... > > In many many cases, using a dB (even a lightweight such as sqlite3) is > swatting the fly with a sledgehammer :-)
I'm sure it seems that way, but look at the generic description of the problem: "I have a list of n-ary tuples with named fields and would like to be able to retrieve a tuple using any of m-fields as a lookup key (where 2 <= m <= n). Also, I would like to enforce the constraint that those m-fields are all unique keys." That pretty much sounds like a typical database problem featuring a single table with multiple indexes. One can wish-away the complexity of a database but you will end-up re-inventing an in-memory, one-table version of database. =============== phonelist =============== name idnumber ---- -------- ray 1234 josh 5423 carl 8674 tery 5409 greg 3402 mark 2108 tasks ----- list names list idnumbers find idnumber=2108 find name=greg del name=tery update idnumber=4321 where name=ray list sorted by name list sorted by idnumber reversed is name=john in phonelist Now, extend the table to make it a trijection (three unique keys), perhaps a social security number. Now, extend the table to add a field that isn't unique (not a key field), perhaps a person's favorite language. Oh wait, you can't do that with a bijection API. Now, forget the in-memory part and make it persistent on disk. Now, relate the entries to another dictionary of tuples (i.e. another table with foreign-key). Too bad a DB wasn't used to solve a DB problem. Raymond -- http://mail.python.org/mailman/listinfo/python-list
