Why " ".some_string is often used ?

[Terry Reedy]

"John Roth" <newsgroups at jhrothjr.com> wrote in message
news:vvqghojub1dl07 at news.supernews.com...
> And I agree, it's not entirely obvious why it's a string
> method rather than a list method,

Because, as I and others have posted several times in previous threads, and
explicated with several examples, <str,unicode>.join is NOT, NOT, NOT a
list method, anymore than it is a tuple, dict, array, generator-iterator,
or any other iteratable method.  Taking 'string' genericly (as either type
str or unicode), .join  joins a sequence (iterable) of strings with a
string.

>since it operates on a list, not on a string.

Huh?  It operates on a sequence of strings.  It has nothing to do with
lists in particular.  The builtinness and mutability of lists is irrelevant
to this generic read-only operation.

>>> help(str.join) # or ''.join or unicode.join or u''.join
join(...)
    S.join(sequence) -> string
    Return a string which is the concatenation of the strings in the
    sequence.  The separator between elements is S.

Notice the absence of 'list'.  Please do not confuse newbies with
misinformation.

> The only explanation that makes
> sense is that, as a list method, it would fail if the list
> contained something other than a string.

This is true for any iterable that contains or yields something other than
a string.
Again, this function/method has nothing in particular to do with lists
other than the fact that lists are one of several types of iterables.  That
is why join cannot be a list method and certain not just a list method.

If 'iterable' were a concrete type/class/interface that all iterables had
to inherit from in order to be recognized as an iterable, rather that an
abstract protocol to be implemented, then one might suggest that join be an
iterable method.  But the statement above, with 'list' replaced by
'iterable', would still be true.  Given that only a small finite subset of
the unbounded set of iterable functions could be designated as basic by
being made a method, one could easily argue that such designation should be
restricted to functions potentially applicable to any iterable.  Count,
filter, map, reduce, iterate (apply for-loop body), and others in itertools
would be such candidates.

If there were an iterable-of-basestrings object subbing the hypothetical
iterable object, then join might an appropriate method for that.  But that
is not the Python universe we have.  Not do I necessarily wish it.  The
beauty of the abstract iterable/iterator interfaces, to me, is that they
are so simple, clean, and genericly useful, without having to privilege
anyone's idea of which sequence functions are 'basic'.

Terry J. Reedy