Prev: Python/HTML integration: phileas v0.3 released
Next: scanning under windows WIA with custom settings (dpi / etc )
From: Joshua Bronson on 24 Nov 2009 13:21
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(a)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
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
> * 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
<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.
From: Gregory Ewing on 24 Nov 2009 18:49
Joshua Bronson wrote:
> So I'm
> thinking of renaming the class injectivedict or idict instead of
> bijection. Is that crazy?)
I think you'd be better off calling it something more
down-to-earth such as bidict (bidirectional dictionary).
That way people without an advanced degree in mathematics
have a better shot at not being baffled by it.:-)
From: Joshua Bronson on 24 Nov 2009 22:28
On Nov 24, 6:49 pm, Gregory Ewing <greg.ewing(a)canterbury.ac.nz> wrote:
> Joshua Bronson wrote:
> > So I'm
> > thinking of renaming the class injectivedict or idict instead of
> > bijection. Is that crazy?)
> I think you'd be better off calling it something more
> down-to-earth such as bidict (bidirectional dictionary).
> That way people without an advanced degree in mathematics
> have a better shot at not being baffled by it.:-)
heh, duly noted:) bidict it is!
From: Joshua Bronson on 26 Nov 2009 14:45
On Nov 24, 10:28 pm, Joshua Bronson <jabron...(a)gmail.com> wrote:
> bidict it is!
now available at http://bitbucket.org/jab/toys/src/tip/bidict.py
and now featuring new shiny namedbidict goodness!
as always, feedback welcome.
From: Francis Carr on 27 Nov 2009 13:12
I was really inspired by this discussion thread! :-)
After much tinkering, I think I have a simpler solution. Just make
the inverse mapping accessible via an attribute, -AND- bind the
inverse of -THAT- mapping back to the original. The result is a
python dict with NO NEW METHODS except this inverse-mapping
attribute. I have posted it on code.activestate.com as <a
Flipdict -- python dict that also maintains a one-to-one inverse
-- F. Carr