python bijection

[Joshua Bronson]

Hey Raymond,

Thanks for your thoughtful reply! I think your idea for a class-
generation approach in the spirit of namedtuple is brilliant; looking
forward to coding this up and seeing how it feels to use it.

(By the way, it occurred to me that "bijection" is perhaps the wrong
term to use for this data structure; really it's just an injective
mapping, as it has no idea whether the function whose mappings it
contains is also surjective. (Unless we take the domain, codomain, and
range of the function being modeled to be exactly defined by the state
of the mapping at any given time. But it feels more correct to me to
interpret the mapping as a sampling of some underlying function, where
the sampling can change but the function stays the same.) So I'm
thinking of renaming the class injectivedict or idict instead of
bijection. Is that crazy?)

More responses inline:

On Nov 21, 9:22 pm, Raymond Hettinger <python at rcn.com> wrote:
> * The idea of using __call__ for looking-up inverse values was
> inspired.  That is useable, clean, and easy to remember; however, as
> discussed below, there are issues though with its actual use in real
> code.

Totally agree the call syntax has issues. Did you happen to see
Terry's suggestion to use slice syntax instead? Now *that* was
inspired. It's also much better because it works for setitem and
delitem too. I replaced the call syntax with the slice syntax on
Friday night -- would be interested to hear whether you think it's an
improvement.


> * Am not excited by the inverse iterators.  With just a regular
> mapping you can write:
>
>         for a, b in m.items() ...   # consider either a or b be the
> key and the other to be the value
>
>   That meets all of the needs that would have been served by
> iter_inverse_keys() or iter_inverse_values() or whatnot.  The mirrored
> API doesn't really provide much in the way of value added.

Hm, the one value I see the latest version of ``inverted`` adding (may
not have been in the version you saw) is that you can pass it either a
mapping, an iterable, or any object implementing an __inverted__
method. So in one case it's just syntax sugar for writing [(v, k) for
(k, v) in d.items()], but in other cases it's providing some
abstraction.

<snip much good feedback and ideas />

> Hope these ideas help.  The ultimate success of the Bijection code
> will depend on its clarity, simplicity, and speed.  Experiment with
> various approaches to find-out which looks the best in real code.  It
> cannot be error-prone or it is doomed.  Also, it should not introduce
> much overhead processing or else people will avoid it.  The API should
> be trivially simple so that people remember how to use it months after
> seeing it for the first time.

Thank you for the sage advice.

Best,
Josh