IronPython calls FallbackInvoke on binder

May 24, 2010 at 2:28 AM

I have C# code that looks like this:

dynamic dynObj = GetObjectFromPython();

CallSiteBinder binder = new MyInvokeMemberBinder("foo", false, new CallInfo(0));

CallSite<...> site = CallSite<...>.Create(binder);
object result = site.Target(site, dynObj);

MyInvokeMemberBinder is derived from InovkeMemberBinder. And method foo is defined in the Python class of which dynObj is an instance.

When I run the code, I see that IronPython calls the FallbackInvoke method of MyInvokeMemberBinder. I traced the code but couldn't figure out why IronPython calls the binder when it tries to bind the method 'foo' on the dynObj object. The call stack is like this:

MyInvokeMemberBinder.FallbackInvoke
MetaUserObject.InvokeBinder.Invoke
MetaUserObject.MetaGetBinderHelper.MakeDictionaryAccess
MetaUserObject.GetOrInvokeBinderHelper.Bind
MetaUserObject.BindInvokeMember
...

My understanding is dynObj is a MO that knows how to do its late binding. Why does the late binding process need to fall back to the binder? And what should the binder do in this case? Thanks!

Coordinator
May 24, 2010 at 4:07 PM

Python doesn't directly implement InvokeMember.  It fetches the member and then falls back to the language to perform the invocation.  The convention in the DLR is that you fallback to the language because it is the language that wants to control implicit conversions on arguments, how to handle rest args, or other wonky calling conventions.  Because the binder embodies the language that owns the "line of code", Python is falling back to your binder as if you were the controlling language.

Bill

From: rovers [mailto:notifications@codeplex.com]
Sent: Sunday, May 23, 2010 7:29 PM
To: Bill Chiles
Subject: IronPython calls FallbackInvoke on binder [dlr:213590]

From: rovers

I have C# code that looks like this:

dynamic dynObj = GetObjectFromPython();
 
CallSiteBinder binder = new MyInvokeMemberBinder("foo", false, new CallInfo(0));
 
CallSite<...> site = CallSite<...>.Create(binder);
object result = site.Target(site, dynObj);

MyInvokeMemberBinder is derived from InovkeMemberBinder. And method foo is defined in the Python class of which dynObj is an instance.

When I run the code, I see that IronPython calls the FallbackInvoke method of MyInvokeMemberBinder. I traced the code but couldn't figure out why IronPython calls the binder when it tries to bind the method 'foo' on the dynObj object. The call stack is like this:

MyInvokeMemberBinder.FallbackInvoke
MetaUserObject.InvokeBinder.Invoke
MetaUserObject.MetaGetBinderHelper.MakeDictionaryAccess
MetaUserObject.GetOrInvokeBinderHelper.Bind
MetaUserObject.BindInvokeMember
...

My understanding is dynObj is a MO that knows how to do its late binding. Why does the late binding process need to fall back to the binder? And what should the binder do in this case? Thanks!

Read the full discussion online.

To add a post to this discussion, reply to this email (dlr@discussions.codeplex.com)

To start a new discussion for this project, email dlr@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com