M.-A. Lemburg wrote: > ncoghlan at iinet.net.au wrote: > >> pass (essentially, all of the work done so far is thrown away, and the >> Unicode >> join starts from scratch. If you know you have Unicode, you're better >> off using >> a Unicode separator to avoid this unnecessary work </tangent>). > > > It's just a simple length querying loop; there's no storage allocation > or anything expensive happening there, so the "throw-away" operation > is not expensive. Yes, my mistake. The tuple that string join creates when the argument is an iterable rather than a list or tuple isn't thrown away - it is given to PyUnicode_Join to work with (since the original iterator may not be able to be iterated a second time). The only work that is lost is that all of the type checks that have been done on prior elements will get repeated in the Unicode join code. So it's not as bad as I first thought - but it will still cost a few cycles. Regards, Nick.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4