@rickardraysearch, thanks! @vmuriart, @tonyroberts, @tiran, @ArvidJB and @brianlloyd, please review this.

Codecov Report

Merging #503 into master will increase coverage by 0.79%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master     #503      +/-   ##
==========================================
+ Coverage   76.41%   77.21%   +0.79%     
==========================================
  Files          64       64              
  Lines        5572     5534      -38     
  Branches      895      887       -8     
==========================================
+ Hits         4258     4273      +15     
+ Misses       1020      975      -45     
+ Partials      294      286       -8

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 c8ae358...db5f43e. Read the comment docs.

Could you explain how and why this works?

/edit: Never mind, got it :)
@tonyroberts Do you know why the explicit (additional) call to __init__ was put into InvokeCtor in the first place?

I believe that what's happening is that MetaType.tp_call is calling __init__ on the class, just as PyType_Type does in type_call. It has access to all of the passed arguments, including those not available in the CLR constructor.

Since the class' __init__ is called from there, there is no need to call it from ClassDerived.InvokeCtor.

When constructing python objects from e.g. C#, the __init__ method would need to be called separately, since the CLR constructor only creates the object. If that should change, I believe we should have a look at actually calling __new__ for python types with __namespace__ and make those arguments match whatever is generated for the CLR constructors.

From the commit history, it looks as if the call was added to invoke __init__ when instantiating python classes from managed code. The tests that @tonyroberts added then still work though, so hopefully this PR isn't breaking any existing major use cases by removing the call to __init__ when constructing python objects from managed code.

By the way, there are two tests in test_subclass.py that are currently skipped with the comment FIXME: test randomly pass/fails. I have run them a couple of hundred times, both on macos and windows, with python 2.7 and 3.6, and not seen a single fail. Can I try reenabling them? They are both relevant to this PR.

/edit: I reenabled them, and they worked on both Travis and Appveyor, at least this time.

Thank you very much for your contribution. We'll have to see, whether this breaks compatibility for anyone, we probably should put a note into the changelog, documenting this change of behaviour.

Yes, it definitely makes sense to put a good explanation in the changelog. Also, could we have a discussion on how to bring back that functionality and exposing additional arguments to the managed constructors? Maybe a new issue is the best place for that.

Many thanks for merging this, by the way! It really makes a big difference for my chances of getting us to use pythonnet here.

Feel free to open one :)