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

[Ron Adam]

On 08/10/2014 07:33 AM, Nick Coghlan wrote:
> FWIW, I don't consider str.join *or* sum with an empty string as the
> starting point to be particularly intuitive ways of joining iterables of
> strings.
>
> str.join was invented before we had keyword-only arguments as a common
> construct, and before print became an ordinary function that accepted a
> "sep" keyword-only argument.
>
> I'd be interested in seeing a concrete proposal for a "concat" builtin that
> accepted a "sep" keyword only argument. Even if such a PEP ends up being
> rejected, it would hopefully help cut short the *next* potentially
> interminable thread on the topic by gathering the arguments for and against
> in a more readily accessible place.

I think the contrast between the built in function "sum", and the string 
method "join", is very interesting from a language design point of view, 
but I'm finding it hard to describe just why in only a few words.  Others 
have pointed out some of the more detailed aspects of these issues, so here 
are some of the more general wider views I think come into play.


* Generality / Speciality

Their are advantages to both ends of this scale.  A more general function 
is very convenient, while a more specialised function can offer a greater 
degree of control.

* Complexity / Quantity

A function with a more complex signature can be equivalent to several 
functions with simpler signatures.  But as they become more complex, they 
also become more difficult to use.


It's not obvious how the "sum" function fits into these scales, and I 
believe that may be why it tends to come up as something that needs to be 
fixed frequently.  (how depends on the viewpoint of the fixer)  If "sum" 
was a method on numbers, it would clearly be more specialised, or if it was 
defined to call a method of what ever objects it was given, it would 
clearly be more general.

It is what it is, and I don't think there was any conscious consideration 
of these concepts when it was created.  Probably practicality over purity 
was more of a factor at the time.

I believe these concepts are more likely to be intuitively considered as 
the developers experiences increase instead of being consciously 
considered.  So they aren't formally defined in any documentation.



How a "concat" built in would relate to these concepts. Would "concat" be 
very general and delegate it's work to methods so it works on a variety of 
objects, or would it be limited to just strings?


I'm also concerned we may add a new function just to compliment the "sum" 
function, so that both of them look better.  I think any new function needs 
to fit into the language as a whole on it's own grounds with a clear 
propose and design.


Food for thought,
   Ron