Re: giving set.add a return value
Sorry, this got lost in the shuffle without being sent, and the conversation seems to have died down. but since I wrote it ... On Sat, Jul 4, 2020 at 8:25 AM Stephen J. Turnbull < turnbull.stephen.fw@u.tsukuba.ac.jp> wrote:
I meant in the context of putting things in, or testing whether they are in, sets. Not in any other context. There are languages where there is no numeric tower, just numbers, and
Sure, but putting them in sets, or using them as a key in a dict is not one of them. set.intern does yield the same result regardless of what's passed in:
whichever is in the set. That's *why* I can call it "intern".[1]
Fair enough. You can of course propose any functionality you want. I’m suggesting that my understanding of what you are proposing doesn’t match well with the rest of how sets work. But to see if I understand correctly, you couldn’t quite use a set to intern objects: once 2.0 was in there you could not put 2 in as well. You could know that 2.0 was already in there when you tried to add 2, but it would still never be added. It seems if you really want to intern objects, you’d need something kind of like, but not quite, a set(). Note: this all is only an issue for object that are of a different type, but can compare equal and have the same hash - maybe the numeric types are the only ones in the stdlib for which this is the case. Nevertheless, they are commonly used :-) Nope: turns out NamedTuples and Tuple are the "same" as far as sets are concerned as well. In [66]: s = {p} In [67]: s Out[67]: {Point(x=2, y=3)} In [68]: s.add((2,3)) In [69]: s Out[69]: {Point(x=2, y=3)} In [70]: s = {(2,3)} In [71]: s.add(p) In [72]: s Out[72]: {(2, 3)} So if you want something that treats different types with the same value as different, you really will need a different storage mechanism than a set. -CHB
Christopher Barker writes:
I meant in the context of putting things in, or testing whether they are in, sets. Not in any other context.
OK, but restricting context that way is asking for eventual trouble, because there's one more thing you can do with sets: get stuff out of them (by iterating).
Good point. You could delete one and replace it with the other, but not have both. That does kind of defeat the whole idea of the "intern" nomenclature. Steve
On Tue, Jul 7, 2020 at 12:53 PM Stephen J. Turnbull <turnbull.stephen.fw@u.tsukuba.ac.jp> wrote:
"Interning" is usually only done with strings. To get a similar effect, you could put (type(x), x) into the tuple, which would allow you to have both the int 2 and the float 2.0 in the interning set. Or have separate sets for different types. ChrisA
Christopher Barker writes:
I meant in the context of putting things in, or testing whether they are in, sets. Not in any other context.
OK, but restricting context that way is asking for eventual trouble, because there's one more thing you can do with sets: get stuff out of them (by iterating).
Good point. You could delete one and replace it with the other, but not have both. That does kind of defeat the whole idea of the "intern" nomenclature. Steve
On Tue, Jul 7, 2020 at 12:53 PM Stephen J. Turnbull <turnbull.stephen.fw@u.tsukuba.ac.jp> wrote:
"Interning" is usually only done with strings. To get a similar effect, you could put (type(x), x) into the tuple, which would allow you to have both the int 2 and the float 2.0 in the interning set. Or have separate sets for different types. ChrisA
participants (3)
-
Chris Angelico -
Christopher Barker -
Stephen J. Turnbull