of course it's the hashing... in my defense it's past my bed time, so not thinking very clearly :-)
we've changed the way we interact with NHibernate recently, and keep bumping into this issue now. The NHibernate domain objects are C# (NHibernate can't work with python objects), and we now cache them in some places by their Int64 IDs, so this happens a lot. We can work around it by casting to long, but it's very error prone, since we need to do it in several places. In short, would be very happy if you could unify the hashing for 2.0 thanks On Tue, Aug 12, 2008 at 11:34 PM, Dino Viehland < [EMAIL PROTECTED]> wrote: > I don't think it's a known issue – but it's because we don't have code > that unifies the Int64's hashing w/ long's hashing though. We should > probably add that for a smoother .NET interop story. > > > > I've filed this as CodePlex bug #17799 ( > http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=17799). > Thanks for the report. > > > > *From:* [EMAIL PROTECTED] [mailto: > [EMAIL PROTECTED] *On Behalf Of *Ronnie Maor > *Sent:* Tuesday, August 12, 2008 1:10 PM > *To:* Discussion of IronPython > *Subject:* [IronPython] int64/long incompatibility in dictionary lookup > > > > Hi all, > > is the following a known issue? > > >>> x = System.Int64(8591464408876390743) > >>> y = long(x) > >>> x == y > True > >>> d = {x:3} > >>> d[x] > 3 > >>> d[y] > Traceback (most recent call last): > File "<stdin>", line 1, in <module> > KeyError: 8591464408876390743 > > happens in both IPy 1.1.2 and 2.0b4 > > thanks > Ronnie > > ------------------------------ > Sample disclaimer text > > _______________________________________________ > Users mailing list > [email protected] > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > >
_______________________________________________ Users mailing list [email protected] http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
