alb wrote: >> But wait, "".join() only accepts strings so let's change >> >>yield [node] >> >> to >>yield [node.name] # str(node) would also work > > Again my question, why not simply yield node.name?
I've been conditioned to build a string from many substrings like so >>> parts = ["foo", "bar", "baz"] >>> text = "".join(parts) >>> text 'foobarbaz' instead of >>> text = "" >>> for part in parts: ... text += part ... >>> text 'foobarbaz' mostly because ""join(...) was initially advertised as being faster than +=. For nested generators or functions this translates into >>> def outer_list(): ... return ["foo"] + inner_list() ... >>> def inner_list(): ... return ["bar"] ... >>> "".join(outer_list()) 'foobar' instead of the obvious >>> def outer(): ... return "foo" + inner() ... >>> def inner(): ... return "bar" ... >>> outer() 'foobar' Here the list-based approach may build many intermediate throwaway-lists, so it's most likely less efficient than direct string concatenation. In return it gives you flexibility: >>> "/".join(outer_list()) 'foo/bar' >>> "-->".join(outer_list()) 'foo-->bar' You'd have to pass the separator as an argument to outer/inner() to achieve this with the seemingly simpler approach. But there's more: You can reverse the order, >>> ":".join(reversed(outer_list())) 'bar:foo' treat the innermost string differently, translate each part into a different language, clip common levels, etc. Your options are unlimited. I never understood why the file system API operates on a single string... -- https://mail.python.org/mailman/listinfo/python-list
