Raymond Hettinger wrote:
Hrvoje Niksic wrote:
I've stumbled upon an oddity using sets. It's trivial to test if a
value is in the set, but it appears to be impossible to retrieve a
stored value,
See: http://code.activestate.com/recipes/499299/
Thanks, this is *really* good, the kind of
2009/4/3 Hrvoje Niksic hrvoje.nik...@avl.com:
I've stumbled upon an oddity using sets. It's trivial to test if a value is
in the set, but it appears to be impossible to retrieve a stored value,
other than by iterating over the whole set. Let me describe a concrete use
case.
Imagine a set
Hrvoje Niksic wrote:
I've stumbled upon an oddity using sets. It's trivial to test if a
value is in the set, but it appears to be impossible to retrieve a
stored value,
Set elements, by definition, do not have keys or position by which to
grab. When they do, use a dict or list.
other
On Fri, 3 Apr 2009 11:22:02 pm Paul Moore wrote:
I'd say that you're abusing __eq__ here. If you can say x in s
and then can't use x as if it were the actual item inserted into
s, then are they really equal?
That's hardly unusual in Python.
alist = [0, 1, 2, 3, 4]
3.0 in alist
True
On Sat, 4 Apr 2009 02:07:28 am Antoine Pitrou wrote:
Your example is wrong:
Of course it is. The perils of posting at 2am, sorry.
Nevertheless, the principle still holds. There's nothing in Python that
prohibits two objects from being equal, but without them being
interchangeable. As poorly
I've stumbled upon an oddity using sets. It's trivial to test if a
value is in the set, but it appears to be impossible to retrieve a
stored value, other than by iterating over the whole set.
Of course it is. That's why it is called a set: it's an unordered
collection of objects, keyed by
2009/4/3 Steven D'Aprano st...@pearwood.info:
Python does not promise that if x == y, you can use y anywhere you can
use x. Nor should it. Paul's declaration of abuse of __eq__ is
unfounded.
Sorry, I was trying to simplify what I was saying, and simplified it
to the point where it didn't make
On Fri, 3 Apr 2009 at 17:57, Paul Moore wrote:
In fact, Python seems to be doing something I don't understand:
class Element(object):
...def __init__(self, key, id):
...self.key = key
...self.id = id
...def __eq__(self, other):
...print Calling __eq__ for %s %
2009/4/3 R. David Murray rdmur...@bitdance.com:
a == b
So, python calls a.__eq__(b)
Now, that function does:
a.key == b
Since b is an object with an __eq__ method, python calls
b.__eq__(a.key).
That's the bit I can't actually find documented anywhere.
Ah, looking again I see that I
On Fri, Apr 3, 2009 at 8:07 AM, Hrvoje Niksic hrvoje.nik...@avl.com wrote:
But I can't seem to find a way to retrieve the element corresponding to
'foo', at least not without iterating over the entire set. Is this an
oversight or an intentional feature? Or am I just missing an obvious way to
Paul Moore wrote:
2009/4/3 R. David Murray rdmur...@bitdance.com:
a == b
So, python calls a.__eq__(b)
Now, that function does:
a.key == b
Since b is an object with an __eq__ method, python calls
b.__eq__(a.key).
That's the bit I can't actually find documented anywhere.
It doesn't
[Nick Coghlan]
It doesn't quite work the way RDM desribed it - he missed a step.
Thanks for the clarification. We ought to write-out the process somewhere in a
FAQ.
It may also be instructive to step through the recipe that answers the OP's
original request,
12 matches
Mail list logo
