[IronPython] RPyC and IronPython

[Dino Viehland]

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: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] 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 <ronnie.maor at gmail.com>:
> 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
Users at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com