[Python-ideas] Python 4: Concatenation

[Soni L.]

On 2017-06-29 09:48 PM, Steven D'Aprano wrote:
> On Thu, Jun 29, 2017 at 08:33:12PM -0300, Soni L. wrote:
>
>> Step 1. get rid of + for strings, lists, etc. (string/list concatenation
>> is not addition)
> I agree that using + for concatenation is sub-optimal, & is a better
> choice, but we're stuck with it. And honestly it's not *that* big a deal
> that I would break backwards compatibility for this. Fixing the
> "problem" is more of a pain than just living with it.
>
>
>> Step 2. add concatenation operator for strings, lists, and basically
>> anything that can be iterated. effectively an overloadable
>> itertools.chain. (list cat list = new list, not iterator, but
>> effectively makes itertools.chain useless.)
> Chaining is not concatenation.
>
> Being able to concatenate two strings (or two tuples, two lists) and get an actual
> string rather than a chained iterator is a good thing.
>
>      word = (stem + suffix).upper()
>
> Being able to chain arbitrary iterables and get an iterator is also a
> good thing:
>
>      chain(astring, alist, atuple)
>
> If we had a chaining operator, it too would have to accept arbitrary
> iterables and return an iterator.

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 is *EFFECTIVELY* equivalent to chaining, since iterating the 
results of these concatenations produces the *exact* same results as 
iterating their chainings.

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

>
>
>> Step 3. add decimal concatenation operator for numbers: 2 cat 3 == 23,
> When would you need that? What use-case for concatenation of numbers is
> there, and why is it important enough to use an operator instead of a
> custom function?
>
> The second part is the most critical -- I'm sure there are uses for
> concatenating digits to get integers, although I can't think of any
> right now -- but ASCII operators are in short supply, why are we using
> one for such a specialised and rarely used function?
>
> Things would be different if we had a dedicated concatenation operator,
> then we could allow things like
>
>      1 & '1' returns '11'
>
> say but we don't and I don't expect that allowing this is important
> enough to force the backwards compatibility break.

Since we'd have a concatenation operator, why not extend them to 
integers? No reason not to, really. In practice tho, it would never be 
used. This was never about integers, even if I did mention them.

>
>
>> 22 cat 33 = 2233, etc. if you need bitwise concatenation, you're already
>> in bitwise "hack" land so do it yourself. (no idea why bitwise is
>> considered hacky as I use it all the time, but oh well)
>>
>> Step 4. make it into python 4, since it breaks backwards compatibility.
> Python 4 will not be a major backwards incompatible version like Python
> 3 was. It will be just a regular evolutionary (rather than
> revolutionary) upgrade from 3.9.
>
> When I want to talk about major backwards incompatibilities, I talk
> about "Python 5000", by analogy to "Python 3000".
>
>
>

This isn't a *major* backwards incompatibility. Unlike with 
unicode/strings, a dumb static analysis program can trivially replace + 
with the concatenation operator, whatever that may be. Technically, 
nothing forces us to remove + from strings and such and the itertools 
stuff - we could just make them deprecated in python 4, and remove them 
in python 5.

(PS: I don't propose using literally "cat" for concatenation. That was 
just a placeholder.)