On Fri, Dec 4, 2009 at 7:42 PM, Lie Ryan <lie.1...@gmail.com> wrote: > On 12/5/2009 9:41 AM, Carl Banks wrote: >> >> On Dec 4, 12:46 pm, geremy condra<debat...@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).
Where a list will do, use a list- duh. But when you need a graph, you shouldn't have to homebrew an implementation any more than you should have to homebrew an odict or named tuple, both of which are substantially easier to get right than a graph is. Geremy Condra -- http://mail.python.org/mailman/listinfo/python-list
