The hash will only be equal if wx.Colour defines its __hash__ as a
function of its content. More likely is that __hash__ just isn't
defined, so the hash(color) is the same as id(color); which is the
default hash.
If you really want your colors to match up, don't use wx.Colour, use a
tuple (49,106,197). I believe that most places which would take a
wx.Colour would also take a 3-tuple instead, but I could be wrong (I
don't deal with colors much).
Right, and I was trying to say that hash(wx.Colour(...)) doesn't "work
right" likely because __hash__ isn't defined on wx.Colour, but that you
may be able to replace your wx.Colour instances with tuples.
- Josiah
···
Jeffrey Barish <jeff_barish@earthlink.net> wrote:
Matching colors is not a problem because == works. The problem is that I
wanted to index a dictionary using a color, something like:
>
> The hash will only be equal if wx.Colour defines its __hash__ as a
> function of its content. More likely is that __hash__ just isn't
> defined, so the hash(color) is the same as id(color); which is the
> default hash.
>
> If you really want your colors to match up, don't use wx.Colour, use a
> tuple (49,106,197). I believe that most places which would take a
> wx.Colour would also take a 3-tuple instead, but I could be wrong (I
> don't deal with colors much).
>
> - Josiah
--
Jeffrey Barish
---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-users-unsubscribe@lists.wxwidgets.org
For additional commands, e-mail: wxPython-users-help@lists.wxwidgets.org
Matching colors is not a problem because == works. The problem is
that I wanted to index a dictionary using a color,
You could use color.Get(), which will give you a tuple of the RGB values.
I've done exactly that, and it works just fine.
-CHB
Yes, it works fine for me too. It's a good workaround. However, I've been
wondering about this statement in Nutshell:
"When __hash__ is absent, but __cmp__ or __eq__ is present, hash(x) and
using x as a dictionary key raise an exception."
Clearly __hash__ is absent and I presume that __cmp__ or __eq__ is present
because == works. Yet using wx.Colour as a dictionary key does not raise
an exception.
Matching colors is not a problem because == works. The problem is
that I wanted to index a dictionary using a color,
You could use color.Get(), which will give you a tuple of the RGB values.
I've done exactly that, and it works just fine.
-CHB
Yes, it works fine for me too. It's a good workaround. However, I've been
wondering about this statement in Nutshell:
"When __hash__ is absent, but __cmp__ or __eq__ is present, hash(x) and
using x as a dictionary key raise an exception."
Clearly __hash__ is absent and I presume that __cmp__ or __eq__ is present
because == works. Yet using wx.Colour as a dictionary key does not raise
an exception.
No, __hash__ is not absent. It is implemented in the base class, object, and I think it does something like return the value of id(self).
>>> object.__hash__
<slot wrapper '__hash__' of 'object' objects>
>>> o = object()
>>> hash(o)
-1210235832
···
--
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!
Matching colors is not a problem because == works. The problem is
that I wanted to index a dictionary using a color,
You could use color.Get(), which will give you a tuple of the RGB
values.
I've done exactly that, and it works just fine.
-CHB
Yes, it works fine for me too. It's a good workaround. However, I've
been wondering about this statement in Nutshell:
"When __hash__ is absent, but __cmp__ or __eq__ is present, hash(x) and
using x as a dictionary key raise an exception."
Clearly __hash__ is absent and I presume that __cmp__ or __eq__ is
present
because == works. Yet using wx.Colour as a dictionary key does not raise
an exception.
No, __hash__ is not absent. It is implemented in the base class,
object, and I think it does something like return the value of id(self).
>>> object.__hash__
<slot wrapper '__hash__' of 'object' objects>
>>> o = object()
>>> hash(o)
-1210235832
I think that what Alex meant by "absent" is "no __hash__ that overrides the
default specified in object." Otherwise __hash__ would never be absent and
he wouldn't have needed to make a statement about what happens when it is
absent. Or, I could be missing something (again). I am interpreting
Alex's comment to imply that when the programmer provides __cmp__ or
__eq__, he is obligated either to provide __hash__ or to raise an exception
on an operation that requires __hash__.