On Wed, Jun 13, 2018 at 2:15 AM, Greg Ewing <greg.ew...@canterbury.ac.nz> wrote:
> Mikhail V wrote:
>>
> My feeling is that inserting is not a frequent enough operation
> to warrant having its own operator, especially not when there
> is already a syntax that does the same thing.
Depends on what you count as 'insert' - append is one case of insert ;)
(logically seen)
Sorry for repeating myself, the idea was that the default meaning is append(),
i.e. normal operator usage on list:
L1 = L2 ^ item - would be same as
L1 = L2.append(item)
But hope you get the point - if an operator for append was added, then it
would be a bit sad that it cannot be used for inserting by slicing,
namely these two forms:
L ^= item #append(item)
L[i:j] ^= item #insert(i, item) instead of i:j items
would be IMO nice to have and it 'd cover both insert and append.
But if you say that special-casing of [i:j] here would be hard to implement,
then maybe insert() idea should be dropped.
> That
> would raise the question of why ^= is getting this
> special treatment but not any of the other augmented
> assignments, and why not "in-place operation with
> attribute" as well
As said, I don't insist on ^ operator.
I would find ">>" or "<<" or "|" ok as well:
L <<= "foo"
L1 = L2 << "foo"
L |= "foo"
L1 = L2 | "foo"
But it would raise same questions.
As for relation 'by sense', that may be too opinion based.
Vertical bar "|" may be somewhat related - IIRC in some contexts it is
used as element separator.
Just hope the judgement is not like "the symbol looks strange - therefore the
feature is not needed".
M
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
