set of sets

[Matteo Dell'Amico]

I thought rewriting __hash__ should be enough to avoid mutables problem
but:

class H(set):
def __hash__(self)
return id(self)

s=H()

f=set()

f.add(s)
f.remove(s)

the add succeeds
the remove fails eventually not calling hash(s).

Why don't you just use "frozenset"?

 

[Paolino]

I thought rewriting __hash__ should be enough to avoid mutables problem but:

class H(set):
def __hash__(self)
return id(self)

s=H()

f=set()

f.add(s)
f.remove(s)

the add succeeds
the remove fails eventually not calling hash(s).


Thanks for help

Paolino





___________________________________
Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB
http://mail.yahoo.it

 

[Paolino]

Why don't you just use "frozenset"?

This is what I'm doing, but the problem remains IMO.
Anyway with frozenset I have to override __new__ instead of __init__ to
make the initialization which is an operation not described in the
frozenset docs, which makes subclassing frozenset a different operation.

Thanks Paolino


___________________________________
Yahoo! Messenger: chiamate gratuite in tutto il mondo
http://it.beta.messenger.yahoo.com

 

[Robert Kern]

Matteo Dell'Amico wrote:

This is what I'm doing, but the problem remains IMO.
Anyway with frozenset I have to override __new__ instead of __init__ to
make the initialization which is an operation not described in the
frozenset docs, which makes subclassing frozenset a different operation.

Don't subclass.

In [1]: s = frozenset()

In [2]: f = set()

In [3]: f.add(s)

In [4]: f
Out[4]: set([frozenset([])])

In [5]: f.remove(s)

In [6]: f
Out[6]: set([])

--
Robert Kern
(e-mail address removed)

"In the fields of hell where the grass grows high
Are the graves of dreams allowed to die."
-- Richard Harter

 

[Matteo Dell'Amico]

And mostly with sets remove operation expense should be sublinear or am
I wrong?
Is this fast as with lists?

It's faster then with lists... in sets, as with dicts, remove is on
average O(1).

Obviously if I use the ids as hash value nothing is guaranted about the
objects contents to be unique but I don't care.
My work is a self organizing net,in which the nodes keep a structure to
link other nodes.As the nature of the net,the links are moved frequently
so remove and add operations and contains query should be optimized.
Why objects need to be hashable for this? Isn't __hash__ there to solve
the problem?

The idea of a set of mutable sets looks a bit odd to me...
I don't get why the outer container should be a set, since you don't
care about uniqueness... if you are representing a graph (which seems
the case to me), I'd use an identifier for each node, and a dictionary
mapping node-ids to its adjacency set for each node. For instance,

0 <-- 1 --> 2 --> 3
| |
v v
4 --> 5

would be represented as

{0: set([]), 1: set([0, 2]), 2: set([2,4]), 3: set([5]), 4: set([5]),
5: set([])}

If node ids are consecutive integers, you could also of course use a
list as the outer structure.

PS: we could also discuss this in italian in it.comp.lang.python

 

[Paolo Veronelli]

Why don't you just use "frozenset"?

And mostly with sets remove operation expense should be sublinear or am
I wrong?
Is this fast as with lists?
Obviously if I use the ids as hash value nothing is guaranted about the
objects contents to be unique but I don't care.
My work is a self organizing net,in which the nodes keep a structure to
link other nodes.As the nature of the net,the links are moved frequently
so remove and add operations and contains query should be optimized.
Why objects need to be hashable for this? Isn't __hash__ there to solve
the problem?
PS Looks like the problem is not present in class sets.Set






___________________________________
Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB
http://mail.yahoo.it