python bijection
in [Python]
|
Prev: Python/HTML integration: phileas v0.3 released
Next: scanning under windows WIA with custom settings (dpi / etc )
From: MRAB on 4 Dec 2009 11:17 M.-A. Lemburg wrote: > geremy condra wrote: >> On Thu, Dec 3, 2009 at 12:57 PM, M.-A. Lemburg <mal(a)egenix.com> wrote: >>> geremy condra wrote: >>>> On Thu, Dec 3, 2009 at 7:04 AM, M.-A. Lemburg <mal(a)egenix.com> wrote: >>>>> 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). >>>> If you're in the market for a Python graph library, you may want >>>> to check out Graphine- I'm obviously biased (I wrote most of it) >>>> but it has a few more bells and whistles than kjbuckets, and is >>>> pretty darned easy to use. It also supports undirected and >>>> bridge graphs. >>> Thanks for the hint :-) >>> >>> The lib looks nice and would probably serve as a good prototype >>> for writing a new built-in type for Python. >> I suspect that it would have a better chance at getting into >> collections than becoming a builtin, but who knows. I'd just >> like to have something like it in the standard library. > > Integrating an easy-to-use graph library into the collections > module (and it's C companion) is good idea. > >>> This would have to be written in C, though, >> That's currently in the works, along with database backing. >> We'd welcome any help though... hint, hint... >> >>> and come under a Python compatible license. >> I'm willing to dual license under the Python license if >> there were a substantial interest in doing so, and I'm >> confident that the other authors and maintainers >> would feel the same way. > > Great ! > >> The question in my mind is whether such an interest exists. > > Since Python is being used more and more in CS classes, > such an addition would complete the tool-set and make Python > even more attractive for undergrad CS courses. > > Finding out how much interest exists in advance is always > a bit difficult with new data-structures. People have to > get a feeling of how they can be put to good use first, > so it's a chicken-and-egg problem. > > We've seen the same thing happen with sets. They were first > made available via a separate module and then became built-ins > after people realized how useful they are in practice. > I'd like to add that people (myself included) were already using dicts for sets before the module was written, so there was already a clear demand for them. > With graphs, it's probably going to take a little longer > before people realize their usefulness - graph theory is > certainly a lot more complicated than set theory :-) > >>> With the built-in feature moratorium >>> currently in place, there's about 1.5-2 years time to get this >>> done; perhaps a good GSoC project for next year :-) >> I'd love to have Graphine be a GSoC project, although >> if the target were to get it into collections the >> moratorium wouldn't change the timeline AFAICS. > > True. >
From: geremy condra on 4 Dec 2009 14:53 On Fri, Dec 4, 2009 at 2:52 PM, geremy condra <debatem1(a)gmail.com> wrote: > On Fri, Dec 4, 2009 at 11:17 AM, MRAB <python(a)mrabarnett.plus.com> wrote: >> M.-A. Lemburg wrote: >>> >>> geremy condra wrote: >>>> >>>> On Thu, Dec 3, 2009 at 12:57 PM, M.-A. Lemburg <mal(a)egenix.com> wrote: >>>>> >>>>> geremy condra wrote: >>>>>> >>>>>> On Thu, Dec 3, 2009 at 7:04 AM, M.-A. Lemburg <mal(a)egenix.com> wrote: >>>>>>> >>>>>>> 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). >>>>>> >>>>>> If you're in the market for a Python graph library, you may want >>>>>> to check out Graphine- I'm obviously biased (I wrote most of it) >>>>>> but it has a few more bells and whistles than kjbuckets, and is >>>>>> pretty darned easy to use. It also supports undirected and >>>>>> bridge graphs. >>>>> >>>>> Thanks for the hint :-) >>>>> >>>>> The lib looks nice and would probably serve as a good prototype >>>>> for writing a new built-in type for Python. >>>> >>>> I suspect that it would have a better chance at getting into >>>> collections than becoming a builtin, but who knows. I'd just >>>> like to have something like it in the standard library. >>> >>> Integrating an easy-to-use graph library into the collections >>> module (and it's C companion) is good idea. >>> >>>>> This would have to be written in C, though, >>>> >>>> That's currently in the works, along with database backing. >>>> We'd welcome any help though... hint, hint... >>>> >>>>> and come under a Python compatible license. >>>> >>>> I'm willing to dual license under the Python license if >>>> there were a substantial interest in doing so, and I'm >>>> confident that the other authors and maintainers >>>> would feel the same way. >>> >>> Great ! >>> >>>> The question in my mind is whether such an interest exists. >>> >>> Since Python is being used more and more in CS classes, >>> such an addition would complete the tool-set and make Python >>> even more attractive for undergrad CS courses. >>> >>> Finding out how much interest exists in advance is always >>> a bit difficult with new data-structures. People have to >>> get a feeling of how they can be put to good use first, >>> so it's a chicken-and-egg problem. >>> >>> We've seen the same thing happen with sets. They were first >>> made available via a separate module and then became built-ins >>> after people realized how useful they are in practice. >>> >> I'd like to add that people (myself included) were already using dicts >> for sets before the module was written, so there was already a clear >> demand for them. >> To be fair, I don't think you'd have to look very far to find places where a graph representation is approximated using some combination of dicts, sets, and lists. ElementTree comes to mind immediately, and the dict-of-dicts idea for logging recently discussed on python-dev explicitly states that it uses that structure to represent object graphs. To me that says that there is at least some demand. Geremy Condra
From: Lie Ryan on 4 Dec 2009 15:10 On 12/5/2009 6:53 AM, geremy condra wrote: > To be fair, I don't think you'd have to look very far to find places > where a graph representation is approximated using some > combination of dicts, sets, and lists. ElementTree comes to mind > immediately, and the dict-of-dicts idea for logging recently > discussed on python-dev explicitly states that it uses that > structure to represent object graphs. To me that says that there > is at least some demand. Though I've never used ElementTree extensively before, I thought it was supposed to use a Tree structure (though it is a subset of graph, the need for tree is much more common than full-blown graph package).
From: geremy condra on 4 Dec 2009 15:46 On Fri, Dec 4, 2009 at 3:10 PM, Lie Ryan <lie.1296(a)gmail.com> wrote: > On 12/5/2009 6:53 AM, geremy condra wrote: >> >> To be fair, I don't think you'd have to look very far to find places >> where a graph representation is approximated using some >> combination of dicts, sets, and lists. ElementTree comes to mind >> immediately, and the dict-of-dicts idea for logging recently >> discussed on python-dev explicitly states that it uses that >> structure to represent object graphs. To me that says that there >> is at least some demand. > > Though I've never used ElementTree extensively before, I thought it was > supposed to use a Tree structure (though it is a subset of graph, the need > for tree is much more common than full-blown graph package). Sure, its a tree, which is also a graph. In this case it looks to me more like a directed acyclic graph than anything, but its pretty much just semantics since the interface is functionally equivalent. Geremy Condra
From: Terry Reedy on 4 Dec 2009 16:43
M.-A. Lemburg wrote: > Integrating an easy-to-use graph library into the collections > module (and it's C companion) is good idea. > >>> This would have to be written in C, though, >> That's currently in the works, along with database backing. >> We'd welcome any help though... hint, hint... The current thinking among deveopers is that new modules should be written and maintained in Python, which all implementations can use, with speed-critical parts written in C for speed and imported by the Python code. You can write a PEP offering Graphine. To be accepted, there would need to be some evidence that is the best Python graph module avaible and has some community support. I would probably use it more that 90% of the stdlib. Terry Jan Reedy |