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 <pyt...@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 -- http://mail.python.org/mailman/listinfo/python-list
