On Mon, Dec 7, 2009 at 5:48 PM, Steven D'Aprano <st...@remove-this-cybersource.com.au> wrote: > On Mon, 07 Dec 2009 17:23:24 -0500, geremy condra wrote: > > >>> * Graph.__iter__ could be mapped to an iterator using >>> the fastest traversal method for the graph nodes (ie. order does not >>> matter, it's only important that all nodes are found as fast as >>> possible) >> >> Again, it seems ambiguous as to whether nodes or edges are the intended >> target here, and while the API can obviously dictate that, it seems a >> bit like a case of "in the face of ambiguity, refuse the temptation to >> guess" to me. > > Consider dicts. They have methods that iterates over keys, values, and > (key, value) pairs, but if you just iterate over the dict itself, you get > the keys. This was a deliberate design decision. > > It's not a matter of guessing in the face of ambiguity, but giving an > easy way to get the most common case. Assuming that iteration over nodes > is more common than iteration over edges, then iter(graph) should yield > nodes in some unspecified order. If you need the nodes in a particular > order, then you will call some method that guarantees the order, and if > you want the edges, you call a method that gives edges. > > If you're not sure whether wanting nodes or edges will be more common, > then you should wait until you, or the community, has more real-world > experience with the module. Python had dicts for something approaching a > decade before they became directly iterable.
I don't have a problem with adding this if there's a strong desire for it, but at the moment I'm leaning towards a wait-and-see approach, for all the reasons you described. Geremy Condra -- http://mail.python.org/mailman/listinfo/python-list