I've fixed the 2.0 bug and I've also created a bug for 1.1.2: http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=16735
There's no reason why we should be doing that. At one point long ago I believe IronPython internally flowed from int32->int64->BigInt but that's long gone so id should be a native data type. The protocol methods is something we've gotten a whole lot better about in 2.0 and is probably a sufficiently large change that wouldn't make it back to 1.x. We used to have fast-paths for everything which were based upon .NET types and interfaces. We now do most (there's still some lingering "fast paths") of our dispatch through the Python protocol methods and as of beta 2 we have a much cleaner solution for projecting them onto .NET types. And currently in 2.0 anything which implements IEnumerable will get an __iter__ method. Thanks for the reports! -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sanghyeon Seo Sent: Thursday, May 22, 2008 2:56 AM To: Discussion of IronPython Subject: Re: [IronPython] RPyC and IronPython 2008/5/22 Ronnie Maor <[EMAIL PROTECTED]>: > 2) id(obj) in IPy returns System.Int64, which unfortunately doesn't pickle > out of the box, since it's not a python native type. This is clearly a bug. Actually, there already is a CodePlex issue, but it is mistitled. http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=16000 1. Can people on the list please vote for this? 2. Can IronPython people please retitle this to something like "id shoud not return Int64"? -- Seo Sanghyeon _______________________________________________ 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
