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 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(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 > 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
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.:-) -- Greg
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.:-) > > -- > Greg 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. josh
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 href="http://code.activestate.com/recipes/576968/">Recipe 576968: Flipdict -- python dict that also maintains a one-to-one inverse mapping</a> -- F. Carr |