Title: IronPython.Objects.List doesn't support GetHashCode()
Is there any special reason why this is the case? The code currently reads:
public override int GetHashCode() {
throw Ops.TypeError("list object is unhashable");
}
So it’s obviously intentional… howev
ovide the correct
semantics from the IronPython side.
Lots to think about - Jim
____
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Anderson
Sent: Thursday, May 12, 2005 9:40 AM
To: users-ironpython.com@lists.ironpython.com
Subject: R
The problem with this model is that it requires you to subclass and use a special type. My goal is to enable simple usage in binding scenarios:
_list.ItemsSource = range(5)
This means that every list/dictionary/touple needs to support ICustomTypeDescriptor and GetHashCode/SyncRoot... The ICD r
On 5/12/05, Chris Anderson <[EMAIL PROTECTED]> wrote:
> I believe that simply returning "1" from GetHashCode() would work just fine
> - however it would mean that hashtables would effectively become linked
> lists or linear arrays (depending on their implementation). From that model,
> returning th
I'll be the first to admit that I'm not the master of language design or hashtables...
My understanding was that the hash of an object needed to be consistent over the life of the object (therefore providing a way for a hashtable to find the bucket for it) and relatively unique (basically, that
On 5/12/05, Chris Anderson <[EMAIL PROTECTED]> wrote:
> Is there any special reason why this is the case? The code currently reads:
>
>public override int GetHashCode() {
>throw Ops.TypeError("list object is unhashable");
>}
>
> So it's obviously intentional… however,
Is there any special reason why this is the case? The code currently reads:
public override int GetHashCode() {
throw Ops.TypeError("list object is unhashable");
}
So it's obviously intentional… however, I'm trying to use a native
Python list as a data source for UI bi
