[Python-ideas] The non-obvious nature of str.join (was Re: sum(...) limitation)

[Wolfgang Maier]

On 08/12/2014 08:29 AM, Stephen J. Turnbull wrote:
> Ethan Furman writes:
>
>   > His remark was pointed at the fact that your output is missing the
>   > final "foo".  Remove the 'r' from __radd__, though, and you would
>   > have what you were trying to demonstrate.
>
> Believe someone when he says he copy-pasted. ;-)  Unless you've
> actually run the code and got a different result, and even then you
> should probably include version information etc.
>
> The presence of __radd__ (or __add__, for that matter, although it's
> reasonably difficult to create a str derivative without it) is
> irrelevant to why "".join works when Nasty is derived from str.
> You're confusing the actual semantics of str.join (repeated copying at
> appropriate offsets into a sufficiently large buffer) with the naive
> implementation of sum (an iterated application of '+').
>

Exactly. So my point was that when you don't subclass str, but instead 
use a wrapper around it, you can give it a as str-like interface as you 
want so the thing looks and feels like a string to users, it will still 
not work as part of an iterable passed to .join (because .join is C code 
moving around arrays of chars and is completely ignorant of all the nice 
methods you added to your object). Sum on the other hand knows how to 
use .__add__ and .__radd__ .
Not that I think this is an argument against str.join() - it is a 
specialized method to join strings efficiently and it's good at that (in 
fact, I think, that's why it makes complete sense to have it implemented 
as a str method because this and nothing else is the data type it can 
handle). I just found Ethan's Nasty() example interesting.

Wolfgang