parsing tree from excel sheet
Peter Otten
__peter__ at web.de
Sun Feb 1 05:11:31 EST 2015
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...
More information about the Python-list
mailing list