reverse dict lookup & Relation class

[Aaron Brady]

On Jan 14, 7:54 pm, MRAB <goo... at mrabarnett.plus.com> wrote:
> Aaron Brady wrote:
> > Hi, this is a continuation of something that comes up now and again
> > about reverse lookups on dictionaries, as well as a follow-up to my
> > pursuit of a Relation class from earlier.
>
> > For a reverse lookup, you just need two lookups.
> > name= {}
> > phone= {}
> > name[ '555-963' ]= 'Joan'
> > phone[ 'Joan' ]= '555-963'
>
> > Though maybe the keys in 'name' should be names, instead of the
> > values in it.  The variable name doesn't clarify that.  (What is more
> > natural to you in reading code?  Is one obviously wrong?)
>
> > phone[ '555-963' ]= 'Joan'
> > name[ 'Joan' ]= '555-963'
>
> Consider "str(x)". It isn't saying "x is a string", it's saying "x as a
> string". Similarly, "ord(x)" says "the ordinal value of x". So,
> "phone[x]" means "the phone number of x".

That's true.  However, I want to map individual fields of records to
the tuples (named tuples) containing the records themselves (unless I
just need a set of tuples).

I think what you are talking about is accessing the 'phone' field,
which was not what I was thinking.  (You see that in algorithm
pseudocode a bit.)  For that, you could use 'name[ tuple1 ]' to obtain
the name.  However, in relational data, there is no single key, of
which the rest of the fields are just accessories.  (Does that make
sense?)  I think I want to use the multiple mappings for different
ways to have access to the data.

> [snip]> What's the best way to construct this class?  Or, do you have an
> > argument that it could not be simpler than using a relational db?
> > Brainstorming, not flamestorming.
>
> You could imagine an object where you provide a field name and a value
> and it returns all those entries where that field contains that value.
> That, basically, is a database.

That's true.  The mapping objects wouldn't be particularly helpful if
I had patterns to match instead of exact values... as now I'm thinking
you usually would.  In other words, providing the mapping objects,
even grouped together in a provider object, would only handle a small
subset of possible queries, specifically exact equality.  For example,
the 'hourstocall' object is basically useless as specified.  Even
separating the fields wouldn't help in a hash.  The separate fields
would need to be stored in sorted lists, using 'bisect' to test
inequality.  (How does an SQL service implement inequality checks
anyway?)

However, it's interesting that my first thought was to start out with
a mapping object, instead of just a set of 'namedtuple's.