[IronPython] RPyC and IronPython

Ronnie Maor ronnie.maor at gmail.com
Thu May 22 21:44:53 CEST 2008


if you want to use RPyC, the fix for iter and len is to change the method
handle_getattr in Connection.py to the following:

def handle_getattr(self, oid, name):
        obj = self.box[oid]
        if name in ['__iter__','__len__']:
            def f(): return getattr(__builtins__,name[2:-2])(obj) # call
iter(obj), len(obj), etc.
            return f
        return getattr(obj, name)

I haven't received a response from tomer filiba yet (RPyC's author), but
seems to work. I'm now happily iterating over remote lists :-)

On Thu, May 22, 2008 at 5:55 PM, Dino Viehland <dinov at exchange.microsoft.com>
wrote:

> 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
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20080522/91e5fdaf/attachment.html>


More information about the Ironpython-users mailing list