parsing tree from excel sheet

[Peter Otten]

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...