python bijection
in [Python]
|
Prev: Python/HTML integration: phileas v0.3 released
Next: scanning under windows WIA with custom settings (dpi / etc )
From: Joshua Bronson on 1 Dec 2009 16:19 On Dec 1, 2:11 pm, Raymond Hettinger <python(a)rcn.com> wrote: > [Joshua Bronson] > > > Raymond, do you think there might be any future in including a built- > > in bidict data structure in Python? > > I don't think so. There are several forces working against it: > > * the recipe is new, so it hasn't had a chance to mature > or to gain a fan club. > > * there are many approaches to the solving the problem and > there is no reason to assume this one is the best. > > * it extends the language with arcane syntax tricks instead of > using the language as designed by Guido. That makes it harder > to learn and remember. > > * we've already got one (actually two). The two dictionary approach > uses plain python, requires no new learning, and is more flexible. > Also, sqlite3 provides another way to use multiple lookups to a > single record. The database approach is much more general > (extending to trijections, allowing multiple sort orders, > providing persistence, etc). all good points. > * the semantics of a bijection aren't obvious: > > b['x'] = 'ex' # first record: ('x', 'ex') > b['y'] = 'why' # second record: ('y', 'why') > b[:'why'] = 'x' # do two records collapse into one? is there > an error? In my implementation the two records collapse into one, on the theory that if you say it you mean it, but you're right that the semantics aren't obvious, especially since in sql this would be an error. Thank you for pointing this out, it totally slipped my mind to document it! (Noted now.) If my bidict package ever has >1 user, and they prefer this to be an error, I'd totally change it. > * the proposed syntax doesn't address the issue covered in my previous > post. > Since bijections are symmetrical, they do not have an obvious > direction > (which is the primary key, the husband or the wife?). The syntax > needs to > allow user names to make it clear which is being accessed: > > marriages.h2w['john'] = 'amy' > marriages.w2h['amy'] = 'john' > > Contrast this with: > > marriages['jordan'] = 'taylor' # are you sure you got the > order correct? > marriages[:'taylor'] = 'jordan' # this is easy to get backwards The "namedbidict" class factory I wrote on your recommendation allows for the former. But it's still up to the user to choose names which indicate the direction of the mapping, whether she uses namedbidict or not: marriages.husbands['john'] = 'amy' # namedbidict, direction unclear h2w['john'] = 'amy' # regular bidict, but not unclear b/c name is 'h2w' (you can use >>> marriages.inv is marriages.husbands False to tell that husbands is the forward mapping, but that sucks -- better to have called it h2w or some such in the first place.) Thanks for the thoughtful reply. Josh
From: Aahz on 1 Dec 2009 20:17 In article <85100df7-a8b0-47e9-a854-ba8a8a2f3b98(a)r31g2000vbi.googlegroups.com>, Joshua Bronson <jabronson(a)gmail.com> wrote: > >I noticed the phonebook example in your ActiveState recipe and thought >you might consider changing it to something like husbands to wives, >since the names-to-phone-numbers relation is many-to-many. What makes you think husbands to wives is one-to-one? ;-) (Even assuming monogamy, you have husbands-to-husbands and wives-to-wives.) -- Aahz (aahz(a)pythoncraft.com) <*> http://www.pythoncraft.com/ The best way to get information on Usenet is not to ask a question, but to post the wrong information.
From: Joshua Bronson on 2 Dec 2009 18:21 On Dec 1, 8:17 pm, aahz(a)pythoncraft.com (Aahz) wrote: > In article <85100df7-a8b0-47e9-a854-ba8a8a2f3b98(a)r31g2000vbi.googlegroups..com>, > Joshua Bronson <jabronson(a)gmail.com> wrote: > >I noticed the phonebook example in your ActiveState recipe and thought > >you might consider changing it to something like husbands to wives, > >since the names-to-phone-numbers relation is many-to-many. > > What makes you think husbands to wives is one-to-one? ;-) (Even > assuming monogamy, you have husbands-to-husbands and wives-to-wives.) Hah! I knew this was coming and even put "assuming monogamy" in the source! http://bitbucket.org/jab/bidict/src/712da6e2dd26/bidict.py#cl-65 ;P As for husbands-to-husbands and wives-to-wives, those are just separate one-to-one mappings! Doesn't mean husbands-to-wives ain't one- to-one! At any rate, apologies to the community for my heteronormative example. It was merely pedagogical and reflects nothing about my personal views! If you have any further concerns, please send them to my lawyer, /dev/null.
From: Aahz on 2 Dec 2009 19:37 In article <9a6902a1-327e-435e-8c9a-b69028994758(a)u20g2000vbq.googlegroups.com>, Joshua Bronson <jabronson(a)gmail.com> wrote: > >At any rate, apologies to the community for my heteronormative >example. It was merely pedagogical and reflects nothing about my >personal views! If you have any further concerns, please send them to >my lawyer, /dev/null. Apology accepted. ;-) -- Aahz (aahz(a)pythoncraft.com) <*> http://www.pythoncraft.com/ The best way to get information on Usenet is not to ask a question, but to post the wrong information.
From: M.-A. Lemburg on 3 Dec 2009 07:04
Raymond Hettinger wrote: > [Joshua Bronson] >> Raymond, do you think there might be any future in including a built- >> in bidict data structure in Python? > > I don't think so. There are several forces working against it: > > * the recipe is new, so it hasn't had a chance to mature > or to gain a fan club. > > * there are many approaches to the solving the problem and > there is no reason to assume this one is the best. > > * it extends the language with arcane syntax tricks instead of > using the language as designed by Guido. That makes it harder > to learn and remember. > > * we've already got one (actually two). The two dictionary approach > uses plain python, requires no new learning, and is more flexible. > Also, sqlite3 provides another way to use multiple lookups to a > single record. The database approach is much more general > (extending to trijections, allowing multiple sort orders, > providing persistence, etc). > > * the semantics of a bijection aren't obvious: > > b['x'] = 'ex' # first record: ('x', 'ex') > b['y'] = 'why' # second record: ('y', 'why') > b[:'why'] = 'x' # do two records collapse into one? is there > an error? > > * the proposed syntax doesn't address the issue covered in my previous > post. > Since bijections are symmetrical, they do not have an obvious > direction > (which is the primary key, the husband or the wife?). The syntax > needs to > allow user names to make it clear which is being accessed: > > marriages.h2w['john'] = 'amy' > marriages.w2h['amy'] = 'john' > > Contrast this with: > > marriages['jordan'] = 'taylor' # are you sure you got the > order correct? > marriages[:'taylor'] = 'jordan' # this is easy to get backwards I think the only major CS data type missing from Python is some form of (fast) directed graph implementation � la kjGraph: http://gadfly.sourceforge.net/kjbuckets.html With these, you can easily build all sorts of relations between objects and apply fast operations on them. In fact, it should then be possible to build a complete relational database in Python (along the lines of Gadfly). -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 03 2009) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ |