[Python-ideas] Python 4: Concatenation

[Steven D'Aprano]

On Thu, Jun 29, 2017 at 11:14:46PM -0300, Soni L. wrote:

> astring cat alist is undefined for string (since strings are very 
> specific about types), so it would return a list.
> 
> alist cat atuple would return a list, because the list comes first.

This would be strongly unacceptable to me.

If iterating over the items was the *only* thing people ever did with 
sequences, that *might* be acceptable, but it isn't. We do lots of other 
things, depending on what the sequence is:

- we sort lists, append to them, slice them, etc;

- we convert strings to uppercase, search them, etc.

It is important to know that if you concatenate something to a string, 
it will either give a string, or noisily fail, rather than silently 
convert to a different type that doesn't support string operations.

Now admittedly that rule can be broken by third-party classes (since 
they can overload operators to do anything), but that's more of a 
problem in theory than in practice. Your suggestion would make it a 
problem for builtins as well as (badly-behaved?) third-party classes.

For when you don't care about the type, you just want it to be an 
iterator, that's where chaining is useful, and whether it is a chain 
function or a chain operator, it should accept any iterable and 
return an iterator.

Concatenation is not the same as general chaining, although they are 
related. Concatenation should return the same type as its operands. 
Chaining can just return an arbitrary iterator.


> (And don't say "performance" - CPython has a GIL, and Python makes 
> many convenience-over-performance tradeoffs like this.)

Are you aware that CPython doesn't just have a GIL because the core devs 
think it would be funny to slow the language down? The GIL actually 
makes CPython faster: so far, all attempts to remove the GIL have made 
CPython slower. So your "performance" tradeoff goes the other way: 
without the GIL, Python code would be slower.

(Perhaps the Gilectomy will change that in the future, but at the 
moment, it is fair to say that the GIL is an optimization that makes 
Python faster, not slower.)



> Since we'd have a concatenation operator, why not extend them to 
> integers? No reason not to, really.

That's the wrong question. Never ask "why not add this to the 
language?", the right question is "why should we add this?". We don't 
just add bloat and confusing, useless features to the language because 
nobody can think of a reason not to.

Features have a cost: they cost developer effort to program and 
maintain, they cost effort to maintain the tests and documentation and 
to fix bugs, they cost users effort to learn about them and deal with 
them. Every feature has to pay its own way: the benefits have to 
outweigh the costs.



-- 
Steve