[IronPython] Using a C# class in IronPython

David DiCato ddicato at microsoft.com
Fri Feb 19 21:30:58 CET 2010

Hi Justin, this is definitely a valid bug; thanks for reporting it. We’re supposed to ignore any methods named GetMember/SetMember/DeleteMember unless they define the [SpecialName] attribute, but we fail to account for cases where there could be overloads. This is because the default binder calls type.GetMethod("SetMember") which throws when there are multiple matches. We should instead get all methods named SetMember and filter out the non-special ones.

I already have a preliminary fix for this, and it should make it onto CodePlex within a few days.

From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Justin Hartman
Sent: Friday, February 19, 2010 11:09 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Using a C# class in IronPython

Thanks, Mark. That's all really good stuff, and essentially we are already doing the same things in our app.

Where the problem comes in for me (I've narrowed it down a little bit) is that the IronPython binding code looks for a method called "SetMember" when I attempt to set an attribute. My class happens to have multiple overridden SetMember methods (which have nothing to do with Python, but make sense in my application domain), which causes Type.GetMethod() to throw an exception.

I logged an issue in CodePlex (Item #26277: CLR class with overridden SetMember method causes "Ambiguous match found"<http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=26277>); you can take a look if you want to see the whole issue and how to repro.
On Wed, Feb 17, 2010 at 9:58 AM, Mark Grice <markjoel60 at gmail.com<mailto:markjoel60 at gmail.com>> wrote:
I'm not sure if this helps, but I use a C# class in my IronPython, and it works fine.

Class is defined using the shorthand get; set;


public class ScreenTags
        public String appWindowName { get; set; }
        public String fieldName { get; set; }
        public bool isDataField { get; set; }
        public bool isManual { get; set; }
        public String screenLabel { get; set; }
        public String description { get; set; }

(In actuality, it is a lot more than this, consisting of other classes, methods, etc...)

Now, it may be bad practice, but I then simply use an object reference in Python, and assume it was instantiated. In other words, as far as Python is concerned, there is an instantiated object of ScreenTags called "screen".

Python simply calls this whenever it wants to do something:

ie. screen. appWindowName  = "ThisName"

I create the screen object in my C# code, and then add it as a reference to the python scope before I call the IronPython engine. So, on the C# side I:

                scptEngine = Python.CreateEngine();
                scptRuntime = scptEngine.Runtime;
                scptScope = scptEngine.CreateScope();
                AddAssemblies(scptRuntime);       // call if you need to add other libraries, such as my class

And before I actually call the Engine, I set the class in the Python scope -- still in C#:

                ScreenTags SOA_screen = new ScreenTags();
                scptScope.SetVariable("screen", SOA_screen);
                scptSource = scptEngine.CreateScriptSourceFromFile(scriptFile);  // scriptFile is Python code

This is working fine. The class is actually really a loaded class, and it has all kind of goodies in it (ie pop up Windows forms, calls out to unmanaged code... all sorts of stuff). I never have a problem with any of it.

I don't know if this helps (or even if it is good practice!) but it is working here.

Users mailing list
Users at lists.ironpython.com<mailto:Users at lists.ironpython.com>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20100219/623ab80b/attachment.html>

More information about the Ironpython-users mailing list