[issue36229] Linear-time list, set, and bytearray ops.

Brandt Bucher added the comment: I apologize - I should have been clearer about what this accomplishes. I'll use list addition as an example, but this works for any binary operation on these containers. If the left operand has a refcount of exactly one, it will simply mutate in-place rather

[issue36229] Linear-time list, set, and bytearray ops.

Serhiy Storchaka added the comment: It could aimed at list1 + list2 + list3. Or foo() + list2, where foo() returns a new list. Or other examples when the left operand is a new object. But it is not correct to say that it is a problem that currently these operations has quadratic complexity.

[issue36229] Linear-time list, set, and bytearray ops.

Tim Peters added the comment: Brandt, it's quite possible I have no real idea what this patch is aimed at. I didn't reverse-engineer the code, the title is extremely broad, and there are no Python examples I can find for what it _is_ aimed at. If, e.g., it's impossible that this patch has

[issue36229] Linear-time list, set, and bytearray ops.

Brandt Bucher added the comment: > ...in a subsequent "+" operation... Sorry, I meant "&|-" here. -- ___ Python tracker ___ ___ Py

[issue36229] Linear-time list, set, and bytearray ops.

Brandt Bucher added the comment: I'm sorry, Raymond. I didn't mean to imply that this is a problem that needs fixing. I just saw an opportunity for a cheap, effective performance boost for a potentially expensive operation. Thanks for clarifying. And on users "expecting" copies: many advance

[issue36229] Linear-time list, set, and bytearray ops.

Tim Peters added the comment: I'm at best -0 on this, and on the edge of -1. We already supply mutate-in-place operations for when this is wanted, and, e.g., for lists, it's as dead easy to spell as L1 += L2 Half the point of the hack for string catenation was that the similar-looking

[issue36229] Linear-time list, set, and bytearray ops.

Raymond Hettinger added the comment: > Binary operations on collections are, in general, of quadratic complexity. BTW, this seems like drastic mischaracterization, making it seem like something is wrong with the containers. It is more accurate to say that an uncommon user pattern of repeate

[issue36229] Linear-time list, set, and bytearray ops.

Raymond Hettinger added the comment: I intend to make a python-dev post about this so we can decide whether to move forward or not. For now, here are a few thoughts: * Something like this was implemented for strings as an effort to mitigate the harm from a common mistake of using chained a

[issue36229] Linear-time list, set, and bytearray ops.

Brandt Bucher added the comment: Thank for the input, Serhiy. On point (1): It's a valid concern... but I don't think it's necessarily a good enough reason to withhold a simple, yet *significant* performance increase for a common use case. This reminds me of past CPython implementation deta

[issue36229] Linear-time list, set, and bytearray ops.

Serhiy Storchaka added the comment: This is an interesting idea. But I have two concerns. 1. It is hard to implement refcount-based optimization on Python implementations which do not use reference counting (i.e. PyPy). If the effect of this optimization will be significant, people will beco

[issue36229] Linear-time list, set, and bytearray ops.

Change by Pablo Galindo Salgado : -- nosy: +pablogsal ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https:/

[issue36229] Linear-time list, set, and bytearray ops.

Change by Brandt Bucher : -- title: Linear-time ops for some mutable collections. -> Linear-time list, set, and bytearray ops. ___ Python tracker ___ _