Codecov Report

Merging #1240 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #1240   +/-   ##
=======================================
  Coverage   86.25%   86.25%           
=======================================
  Files           1        1           
  Lines         291      291           
=======================================
  Hits          251      251           
  Misses         40       40           

Flags with carried forward coverage won't be shown. Click here to find out more.

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update d44f1da...c46ab75. Read the comment docs.

I also found that I have failed to handle array subscription. If a method returns a ISomething[] , then the individual elements will not be wrapped in the interface when you access them (e.g. arr[0]).

I've addressed the issue with returning arrays of interface objects.

What remains is the ability to "downcast"/unwrap objects, as @lostmsu mentioned. As far as I have been able to see, there is no way of doing that today. One could add a property as @lostmsu suggests - the question then becomes how to name that so that the risk of colliding with one of the interface members is minimized. Perhaps there is a subset of names that would be valid in Python, but not in .NET so one can avoid collisions completely?

Another approach would be to provide a service class that can be used for downcasting/unwrapping. A simple implementation of that today is:

namespace Python.Test {
    public class Cast
    {
        public static object Downcast(object input) // note the return type!
        {
            return input;
        }
    }
}

Which you then can use like this:

from Python.Test import Cast
ob = Cast.Downcast(iface_obj)

The reason I bring this to attention is that it highlights the incompleteness of my approach in this PR. I have tried to make sure that whenever a .NET method returns an interface, the interface is all that Python sees (proper implementation hiding). However, I have done nothing about the corresponding case for classes. If a method is declared to return a value of type ParentClass and returns a ChildClass, Python-land is free to access any member of ChildClass. Having different behavior for classes and interfaces does not seem like a good idea.

Either we should apply implementation hiding everywhere (like done for interfaces in this PR), or nowhere (which is the case today). The former is more in line with what you would get in C#. The latter is perhaps what users of Python.NET wants (?), since that is the behavior that is currently there.

I'd be happy to hear your thoughts on what is the right way forward.

@danabr completeness is not necessary. If there's a bug around C# new methods (not) hiding base class methods with the same name, let us track it separately.

The problem with no hiding is that it makes calling certain overloads potentially impossible due to name conflicts.

@filmor do you know if we have anything like Downcast methods already available?

If not, I suggest InterfaceObject to expose __implementation__ property pointing to the unwrapped instance (with converters applied) and __raw_implementation__ without any conversions.

I've added the requested properties __implementation__ and __raw_implementation__. Alas, I failed to come up with a good way to test the latter (namely that no conversions are applied). I was hoping I could make some clever use of custom encoders to test it.

What remains now is properly documenting that the properties are available. Should that be done somewhere in this repo, or on the wiki, or on pythonnet.github.io?

I also need to make a note of the changes in the CHANGELOG, and make it clear that this is a breaking change.

@danabr to test __raw_implementation__ you can do IComparable with Int32, and ensure, that type of the raw object is actually System.Int32. Currently Python.NET conversions always turn primitive .NET int types to Python's int.

pythonnet.github.io seems to have only basic example, so you might want to create a new wiki page for the interface objects.

Yeah, a note in CHANGELOG would be helpful.

to test raw_implementation you can do IComparable with Int32, and ensure, that type of the raw object is actually System.Int32.

Great idea! I used that to add a test. I've also updated the CHANGELOG. I'll have a look at updating the Wiki if this gets merged.

Thanks for all the help and guidance, @lostmsu!

@danabr seems like a few tests are failing because the InterfaceObject has no tp_iter.

Argh, I wonder how come I did not notice before. I do run the tests locally. But now I can reproduce it. I'll look into it.

It was an unexpected interaction with the work in one of my other PRs. I must have forgotten to run the tests after rebasing on master. Now all tests pass locally. Hopefully they will pass in CI as well.