Brandt Bucher <brandtbuc...@gmail.com> 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 advanced Python programmers I know still recently thought that "a < b < c" was evaluated as "(a < b) < c". It's nice to be pleasantly surprised with "better" behavior... especially when this pretty solidly falls under the category of "implementation detail", since it's not outwardly visible. And speaking of visibility: > Beyond that, is it actually safe for set operations? I'm not sure how it wouldn't be. None of the sets in your example should be able to be mutated, since the operation you described doesn't hit the new branch at all. I've also spent parts of yesterday and today trying to craft malicious objects/threads that do what you described, and haven't been able to. I've found main roadblock to doing so is the fact that the named references still aren't mutated, and the first (and only) intermediate copy is invisible to everything except PyNumberAdd. I also haven't been able to get a handle to the left-hand set in a subsequent "+" operation from a contained object. Maybe I misunderstood you, though. However, both of you are much better engineers than I am, so I'll defer to your judgement here. If the set portion of the PR seems vulnerable, I'm eager to modify or remove it. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue36229> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
