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.)
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
