Mapping, with sequence as key, wildcard and subsequence matching

[Ben Finney]

Chris Angelico <rosuav at gmail.com> writes:

> I'm not sure you really need a mapping type per se.

My reasons include (but I can probably think of more) testing membership
via the ‘key in mapping’ syntax.

> with the "match any" concept, there's actually a potential for
> ambiguities, which means you need a sequential (strictest first)
> check. In any case, it's virtually impossible to hash a tuple of
> strings such that it can match multiple targets, based only on what
> the targets do.

I'm fine with not having the keys hashed, so long as I can use the
mapping API (membership test, item retrieval by key, rejecting keys that
already match one of the items, etc.).

In other words, I'm not limiting myself to Python's ‘dict’ type, which
is why I've only been talking about a type which can be classified as a
mapping type.

> Steven's suggestion to turn this into an honest linear search is
> probably what I'd do; ultimately, a dict that can't hash its keys
> properly is going to devolve to that anyway.

Fine by me. What is the mapping API that needs to be implemented though?

I can guess, but for code I intend to release, API design should not be
a matter of guessing. I'd rather have an already-worked example of a
custom mapping type that fully implements the API used by Python's
mapping type, without having to discover it all by trial and error. Once
this is out in the wild, I don't want to discover I made a bad API
design decision.

-- 
 \       “When a well-packaged web of lies has been sold to the masses |
  `\    over generations, the truth will seem utterly preposterous and |
_o__)                    its speaker a raving lunatic.” —Dresden James |
Ben Finney