Codecov Report

Merging#1240 intomaster willnot change coverage.
The diff coverage isn/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 byCodecov. Last updated44f1da...c46ab75. Read thecomment docs.

I also found that I have failed to handle array subscription. If a method returns aISomething[] , 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:

namespacePython.Test{publicclassCast{publicstaticobjectDowncast(objectinput)// note the return type!{returninput;}}}

Which you then can use like this:

fromPython.TestimportCastob=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 typeParentClass and returns aChildClass, Python-land is free to access any member ofChildClass. 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 likeDowncast methods already available?

If not, I suggestInterfaceObject 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 doIComparable withInt32, and ensure, that type of the raw object is actuallySystem.Int32. Currently Python.NET conversions always turn primitive .NET int types to Python'sint.

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 testraw_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 theInterfaceObject has notp_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.