All CLA requirements met.

Codecov Report

Merging#1233 intomaster willnot change coverage.
The diff coverage isn/a.

@@           Coverage Diff           @@##           master    #1233   +/-   ##=======================================  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 update451fae6...080d0c1. Read thecomment docs.

I am not convinced this should be the expected behavior. Technically explicit interface implementations are private methods, and Python.NET does not expose them by design.

Is there a scenario, where you can not cast your instance to the desired interface? Or do you just want duck typing for some reason?

Ah, that explains it. I ran into this when trying to switch out IronPython in a project. Since it worked there I got the impression that it would work with Python.NET also. I did not know that external interface implementations are private. Thanks for the explanation! I'll see if there is a way I can do the casting automatically in our module loader, so that end users don't have to worry about it.

@lostmsu Can you link some docs regarding the privacy of explicit interface implementations? I thought they were mainly used to get around name and signature conflicts, I wasn't aware of a semantic significance.

@lostmsu : There's still an issue when a method returns an interface. If the returned object implements its interface explicitly, its methods becomes invisible to Python:

publicinterfaceISayHello1{stringSayHello();}publicclassInterfaceTest2:ISayHello1{publicISayHello1GetISayHello1(){returnthis;}stringISayHello1.SayHello(){return"ISayHello1";}}

deftest_interface_object_returned_through_method():"""Test explicitly implemented methods are visible"""fromPython.TestimportInterfaceTest2ob=InterfaceTest2()hello1=ob.GetISayHello1()asserthello1.SayHello()=='ISayHello1'

This test fails with:

>       assert hello1.SayHello() == 'ISayHello1'E       AttributeError: 'InterfaceTest2' object has no attribute 'SayHello'

The caller of GetISayHello1 shouldn't really need to cast the returned object toISayHello1. The method is already declared to return that type! It also adds to the confusion that casting is only sometimes necessary (namely when the interface has been explicitly implemented, something the caller should not need to know about).

I'd be happy for advise on how to handle this.

@danabr this actually seems a legitimate reason for a change. When method explicitly returns an interface type, Python should see the object as an instance of that interface with all its methods available.@filmor thoughts?

As said, I'm not aware of any semantic difference between the "usual" and explicit implementation of an interface, so IMO this change makes sense.

The C# documentation ([1]) does say that:

It's possible to implement an interface member explicitly—creating a class member that is only called through the interface, and is specific to that interface.
[...]
The class member IControl.Paint is only available through the IControl interface, and ISurface.Paint is only available through ISurface. Both method implementations are separate, and neither are available directly on the class.

So behaving differently in Python.NET might not be a good idea, although perhaps never a problem in practice. Could the issue with returning an interface from a method be solved some other way? e.g. by doing the same thing that we do when casting to the interface in Python when we convert the return value of a method to a Python value?

[1]https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/interfaces/explicit-interface-implementation

@danabr you would need to postprocess after this line:

and maybe in some other places.

@lostmsu ,@filmor : An approach "casting" the object to the interface type before returning it has been implemented in#1240. It comes with its own sets of things to consider. I'd be happy to hear your thoughts on that approach.