Why " ".some_string is often used ?

[Dave Benjamin]

In article <WuqdnV9uUeebO2CiRVn-jw at comcast.com>, Terry Reedy wrote:
> 
> "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.

It's not a list method because it's not a list method or any other kind of
iterable method? That seems like circular reasoning.

Consider the following two pieces of data:

 1. 'the,quick,brown,fox'
 2. ['the', 'quick', 'brown', 'fox']
 
They are both lists of words. Perhaps the first is not a Python-list of
words, but it's a list of words nonetheless. #1 can be converted into #2 by
calling ".split(',')" on it. Doesn't it seem natural that #2 be converted to
#1 by calling ".join(',')"? It works this way in JavaScript and Ruby, at
least.

The argument is more of a technical issue. There are only two kinds of
strings. There are many kinds of "iterables". So, it's easier to define
"join" on the string, and force implementers of custom string types to
implement "join" as well (since this is more rare) than to define "join" on
an iterable and force implementers of the many kinds of iterables to define
"join" as well. Conceptually, I'm not sure that the case is so strong that
"join" is a string method.

In reality, "join" isn't really a string method any more than it's an
iterable method. It's a string-iterable<string> method; it operates on the
relationship between a string and an iterable of strings. If we had a
class that could represent that relationship, "join" would be a method of
that class, ie.:

seq = ['the', 'quick', 'brown', 'fox']
sep = ','

ssi = StringStringIterable(sep, seq)
result = ssi.join()

But this would be somewhat pointless because:

 1. This would be a pain to type.
 2. The class probably wouldn't pull its weight.
 3. The elegance Python has with text processing is lost.

Another solution might be to use a mixin class that provides StringIterable
methods, and have the built-in list include this mixin. Then, you could
always mix it into your own iterable classes if you wanted "join" to be
available. But then, you've still got issues trying to integrate it with
tuples and generators.

Sometimes, object-orientedness gets in the way, and I think this is one of
those cases. "str.join" is probably the winner here, but since it's really
just a string method being used "out of context", the delimeter is the first
argument, and this doesn't read well to me. I think that "string.join" makes
more sense; it says "join this sequence using this delimeter" instead of
str.join's "join using this delimeter this sequence".

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

Only because it is defined as such. Ruby and JavaScript define the "join"
method on built-in arrays. Newcomers to Python who have programmed in those
languages will naturally associate "join" with lists, even though
technically, in the Python world, it's really something associated with
the relationship between a string and an iterable of strings. Which is an
awful lot of semantics to digest when you just want to stick some commas
between words in a list.

-- 
.:[ dave benjamin (ramenboy) -:- www.ramenfest.com -:- www.3dex.com ]:.
: d r i n k i n g   l i f e   o u t   o f   t h e   c o n t a i n e r :