I don't know. I cheated and tested it out, but I couldn't see any difference in the resulting set a. Is one faster or something?
-Tyler S.
spizzy
on Jul 10, 2008
As someone who doesn't know Python all that well, what is the difference?
I tried on the command line and seemed to to get the same result.
egometry
on Jul 10, 2008
Do they use different internal methods to get their results?
sufianrhazi
on Jul 11, 2008
ior
vs
or
The former is done in place, fancy that.
aegisknight
on Jul 11, 2008
Ding ding ding. (This bit me as I had a recursive loading dependencies, detecting cycles with a set. I assumed |= would expand out to s = s | t, like the += operator with integers*. Oops.)
(* More trivia: i += 1 is not an atomic operation in CPython, but list.append is!)
enno
on Jul 11, 2008
I immeidately guessed it, though probably would have fallen for it myself:
[HTML_REMOVED]
a = set([1])
b = a
a = a | set([2])
b
set([1])
a
set([1, 2])
c = b
c |= set([3])
c
set([1, 3])
b
set([1, 3])
[HTML_REMOVED]
enno
on Jul 11, 2008
By the way, this is exactly why I still like good old C above all the other languages I write in. Every allocation made is one that I intended.
thespeedbump
on Jul 13, 2008
Funny corner cases like this make me think that set() should perhaps not overload operators quite so liberally.
The implementations of < and > are also counterintuitive:
assert not set([1]) > set([2])
assert not set([1]) < set([2])
timothyfitz
on Jul 14, 2008
Is this really surprising? (Or have I been drinking the kool-aid so long that I forget what plain water is?)
Immutable types implement a += b as a = a + b, while mutable types make the operation in-place.
follow on Mastodon
follow with Feedly
RSS for the rest
I don't know. I cheated and tested it out, but I couldn't see any difference in the resulting set a. Is one faster or something?
-Tyler S.
As someone who doesn't know Python all that well, what is the difference?
I tried on the command line and seemed to to get the same result.
Do they use different internal methods to get their results?
ior vs or
The former is done in place, fancy that.
Ding ding ding. (This bit me as I had a recursive loading dependencies, detecting cycles with a set. I assumed |= would expand out to s = s | t, like the += operator with integers*. Oops.)
(* More trivia: i += 1 is not an atomic operation in CPython, but list.append is!)
I immeidately guessed it, though probably would have fallen for it myself: [HTML_REMOVED]
By the way, this is exactly why I still like good old C above all the other languages I write in. Every allocation made is one that I intended.
Funny corner cases like this make me think that set() should perhaps not overload operators quite so liberally.
The implementations of < and > are also counterintuitive: assert not set([1]) > set([2]) assert not set([1]) < set([2])
Is this really surprising? (Or have I been drinking the kool-aid so long that I forget what plain water is?)
Immutable types implement a += b as a = a + b, while mutable types make the operation in-place.
In place: a = range(5) a += [6]
New instance: a = "five" a += "six"