Tim Peters <[email protected]> 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
S1 += S2
did _not_ mutate in place. But that spelling for lists already does.
Beyond that, is it actually safe for set operations? Those need to compare
elements, so can call into Python code via custom __eq__ implementations, which
in turn can do anything, including boosting the number of ways to reach the
original inputs (i.e., increase their refcounts). For that reason I believe it
can be visible if, e.g.,
Set1 = Set1 & Set2
mutates the original set bound to Set1. The binding via name `Set1` may be the
only way to reach the original set before that statement executes, but the
process of computing the RHS _may_ create additional references to the original
set object.
Even if it doesn't, when element __eq__s are running other threads may run too,
and pick up ever-changing values for the set object `Set1` refers to if it's
mutated in place.
None of those were potential issues for hacking string catenation (which never
calls back into Python code - and holds the GIL - for the duration).
----------
nosy: +tim.peters
_______________________________________
Python tracker <[email protected]>
<https://bugs.python.org/issue36229>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
