python bijection
in [Python]
|
Prev: Python/HTML integration: phileas v0.3 released
Next: scanning under windows WIA with custom settings (dpi / etc )
From: geremy condra on 5 Dec 2009 19:49 On Sat, Dec 5, 2009 at 7:18 PM, Raymond Hettinger <python(a)rcn.com> wrote: > On Dec 5, 3:22 pm, geremy condra <debat...(a)gmail.com> wrote: >> On Sat, Dec 5, 2009 at 4:39 PM, Raymond Hettinger <pyt...(a)rcn.com> wrote: >> > [geremy condra] >> >> I actually considered using dependencies as an example on the >> >> "graphine for pythonistas"[1] article, but decided to do the maze >> >> run instead. In any event, the uses of graphs in general computing >> >> are well enough established that I don't really think that's where >> >> the majority of the difficulty in coming up with something for the >> >> standard library will be- deciding how it should look and behave, >> >> especially in terms of scope and target audience, that's going to >> >> be the difficult part. >> >> > Right you are :-) >> >> >> [1]:http://gitorious.org/graphine/pages/GraphineForPythonistas >> >> > Do you have many users? >> >> I literally have no idea, but I suspect not, seeing as how its a >> pure python3 project. > > Google's code search can provide a clue. > It is also helpful because it let you see > typically use cases and whether the API fits well > or whether it is awkward to express common use cases. > All of those observations will help you tweak the API. Unfortunately, judging from the queries I get most of the people interested in the package are using it to study graphs, rather than to write applications using them. That's one of the reasons why I haven't pushed the idea to date- graphine was developed to be useful to other developers, but seems to be mainly used by academics, while networkx seems to be targeted primarily at academics, and is somewhat widely used. I think the ideal situation would be to take projects like graphine and python-graph and develop a hybrid system specifically for the standard library that borrows the strengths of each, but that would involve a lot of developer time for people already heavily invested in their own projects. Having said that, if enough people from the python community got behind it, I think it would happen. > Also, it's useful to make similar studies of competing > packages either written in Python or in some other langauge. I couldn't agree more. Geremy Condra
From: M.-A. Lemburg on 7 Dec 2009 07:51 Terry Reedy wrote: > 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. I don't think you are speaking for Python developers in general. The usual approach is to develop a prototype in Python and then rewrite it in C. Since the prototype is already there, what remains is the rewrite to get better performance. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 07 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/
From: M.-A. Lemburg on 7 Dec 2009 08:07 Carl Banks wrote: > On Dec 4, 4:42 pm, Lie Ryan <lie.1...(a)gmail.com> wrote: >> On 12/5/2009 9:41 AM, Carl Banks wrote: >> >> >> >> >> >>> On Dec 4, 12:46 pm, geremy condra<debat...(a)gmail.com> wrote: >>> 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. >> >>> I'd have to agree with Lie, yes a tree is a graph, but it's simply not >>> an argument that Python community is grasping for graph structures. >>> It's like arguing that the Python community could benefit from a >>> quaternion type, because quaternions are actually heavily used in >>> Python, because a scalar number is a quarternion. >> >>> Carl Banks >> >>> (Would be +1 on a good graph implementation... just not because of >>> ElementTree.) >> >> I think this could be an interpretation of the Zen: >> >> Simple is better than complex. >> Complex is better than complicated. >> >> can be read as: >> List is better than Tree >> Tree is better than Graph >> >> not having Tree and Graph package in the standard library force most >> people to find List-based solution. And people that know they need >> graphs will find them in 3rd party modules. I have needed Trees a few >> times in python, but very rarely a Graph (except for playing around). >> YMDWV (your mileage definitely will vary). Trees are only a subset of general graphs and graphs often provide a more intuitive approach to problem representation than trying to squash all information into a tree or list. For certain problems, like e.g. dependency checking or routing, you can easily run into cycles which cannot be represented by trees (*). Furthermore, the property of being cycle-free (acyclic) is often one of the things you want to find out when dealing with graph data sets. (*) Note that Python does allow creating lists with cyclic references, but such usage is not really encouraged and will lead to delays in garbage collection: >>> l = [1,2,3] >>> l[2] = l >>> l [1, 2, [...]] -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 07 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/
From: geremy condra on 7 Dec 2009 11:46 On Mon, Dec 7, 2009 at 7:51 AM, M.-A. Lemburg <mal(a)egenix.com> wrote: > Terry Reedy wrote: >> 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. > > I don't think you are speaking for Python developers in general. I believe he's referring to the core developers. Geremy Condra
From: M.-A. Lemburg on 7 Dec 2009 12:05
geremy condra wrote: > On Mon, Dec 7, 2009 at 7:51 AM, M.-A. Lemburg <mal(a)egenix.com> wrote: >> Terry Reedy wrote: >>> 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. >> >> I don't think you are speaking for Python developers in general. > > I believe he's referring to the core developers. I was as well, being one of them :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 07 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/ |