Sets in Python

[Magnus Lie Hetland]

"Alex Martelli" <aleaxit at yahoo.com> wrote in message
news:956s6k013u0 at news2.newsguy.com...
> "Magnus Lie Hetland" <mlh at idi.ntnu.no> wrote in message
> news:956hcd$qef$1 at tyfon.itea.ntnu.no...
> >
[...]
> >
> > Isn't there a better (more beautiful) way of doing this?
>
> Hi Magnus!  It's been a while...

Indeed :-)

And it's getting really crowded in this once-so-small-and-cozy
newsgroup. Oh, well. I guess that's a good thing ;-)

>
> In Python 2.1, you'll be able to use
>     if x in dict
> as a synonym for
>     if dict.has_key(x)

Yes... I realised that after I posted... (Stupid of me ;-)

> [and *maybe* the for-loop equivalent, too -- I'm still unclear
> about that one, and it doesn't seem to be in the first alpha].
>

Hm... Interesting.

Anyway -- I have already written a wrapper that supports both
the in-test, iteration and addition, subtraction, in-place
addition/subtraction etc. With a little polishing, it might
be useful. (I'm still thinking a bout union etc. -- not all
that effective... Or perhaps with dict.update(...)? Hm.)

> This would seem to point to using dictionaries as sets.
>

Yes. In a way. You still have to do set[element] = arbitrary_dummy_key,
which seems a bit... Well... Arbitrary. <wink>

> Time machine at work again -- you CAN 'override it' in the
> current Python (2.0; unsure if that was in 1.6 too).

Yes. I found that too. <blush>

Worked it into my wrapper.

> Thus, it would seem that (without having to wait for 2.1)
> implementing sets as class instances would not be too
> bad, either (tiny overhead wrt using native dicts directly,
> and you get to control the syntax sugar:-).

Yes. That's my current strategy. I just don't like importing
my own modules in small scripts... Because then I can't
distribute them separately etc. (That's why I love the plethora
of standard modules that come with Python... I only wish there
were more ... Where one could contain a standard Set class <wink>)

> Supporting
> 'for x in myset' will require some (modest) trickery in
> __getitem__ (caching a [sorted?] copy of the keys of the
> dictionary attribute one uses for implementation, else
> the overhead might become a tad too big, I suspect).

I just did this:

def __getitem__(self, key):
    return data.keys()[key]

The sorting sort of reduces the usefulness of the hash table
in terms of running time... And anyway -- a set has no
intrinsic order, so who cares about the sorting :-)

> That
> gets into murky territory in order to support semi-sensibly
> such behavior as altering the set whose contents one is
> looping on,

Well, in this case that would behave like altering the list
one is iterating over, so that's really not much of a problem,
I think.

> considering the possibility that the for loop
> may be prematurely terminated with a break (so one can't
> know for sure when to throw away said cache), etc.  But, it
> seems to me, nothing _too_ horrible.

Indeed. Not so terrible. I just wish I could see it as something
magical that was included with the Python distribution.

Oh, well. I guess I'll post the little snippet of a class
when I make it a bit more presentable (if I remember <wink>)

Perhaps it could be included in the snippet page?
(Don't remember the URL... It *has* been a while. <wink>)

>
> Alex

--

  Magnus Lie Hetland      (magnus at hetland dot org)

 "Reality is what refuses to disappear when you stop
  believing in it"                 -- Philip K. Dick