[Python.NET] subclassing managed types in python

Discussion:

Tony Roberts

2013-10-09 09:27:42 UTC

Hi,

am I right in thinking that currently when managed types are subclassed in
python the python methods can't override the base class methods when called
from .net?

It would be useful to be able to do this for something I'm working on at
the moment, and before I started looking at it I wondered if anyone has
done any work on this before?

I think it should be possible to achieve by creating new managed types
using System.Reflection.Emit.TypeBuilder and replace any virtual methods
with ones that first look for a method on the python object with the same
name before falling back to the base class method - the same way SWIG
wrappers work for C++ classes basically but done dynamically. In the case
where there are multiple methods with the same name but different
signatures the python method would override them all and have to check what
it had been passed to do the right thing.

Any thoughts?

thanks,
Tony

Tony Roberts

2013-10-17 09:42:08 UTC

Permalink

Hi,

I went ahead and implemented this as I didn't get any response from my last
mail. The code is in my github repo if anyone wants it (would be great if
this feature could be integrated back into the main project??)
https://github.com/tonyroberts/pythonnet

The tests in test_subclass.py (see also subclasstest.cs) show how you can
now subclass a managed type in python, instantiate that type both in python
and in managed code and then call the virtual methods overridden in the
subclass from managed code (as well as from python) and it will call back
out to the python code.

It works by constructing new managed types on the fly using
System.Reflection.Emit (see new file classderived.cs).

There are a couple of issues which aren't that important to me right now,
but do cause a couple of the unit tests to fail:
-- subclass constructors can no longer take extra arguments (as the
__init__ method is called from the managed subclass ctor)
-- __init__ gets called twice when instantiating sub classes from python
(related to the above, it's because __init__ needs to be called when the
object is instantiated from managed code); doesn't cause a test to fail but
thought I'd mention it.
-- sub-classing of array types isn't working anymore

I'll probably get round to fixing these, but for now for my purposes I'm
not worried about them for now. If this is useful for anyone else and
someone comes up with some fixes please feel free to send me a pull request
:)

One other thing that's not working is using super to call the base class
method from the subclass. I've got a fix so that the base class method can
be called directly (eg SubClass.x(self), where self is an instance of
DerivedClass) but I've not checked that in as I'd really prefer to get
super() working. If anyone has any ideas about how to get that working
please let me know...

cheers,
Tony

Post by Tony Roberts
Hi,
am I right in thinking that currently when managed types are subclassed in
python the python methods can't override the base class methods when called
from .net?
It would be useful to be able to do this for something I'm working on at
the moment, and before I started looking at it I wondered if anyone has
done any work on this before?
I think it should be possible to achieve by creating new managed types
using System.Reflection.Emit.TypeBuilder and replace any virtual methods
with ones that first look for a method on the python object with the same
name before falling back to the base class method - the same way SWIG
wrappers work for C++ classes basically but done dynamically. In the case
where there are multiple methods with the same name but different
signatures the python method would override them all and have to check what
it had been passed to do the right thing.
Any thoughts?
thanks,
Tony

Kyle Rocha

2013-10-17 17:15:11 UTC

Permalink

I was also looking into implementing the monodevelop document and project
interfaces in python in order to provide better .Net project development in
sublime.

Didn't get too far unfortunately.