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.
> 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.
> 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".
--
Steve
_______________________________________________
Python-ideas mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
