(Version 2.1)

Given .NET class:

      public class A {

           public A() { a=1.0;}

           public A(double ax) { a=ax;}

           public double a;

     }

then in python:

from Xxx import A

a1 = A(2)   # surprise! default constructor is selected, silently, basically because 
            # there is no int->double type promotion in constructor binder
            # causing first bind to fail, then second bind with no args (that was a fix
            # to allow .NET objects to be super-classes (or be sub-classed) from
            # python succeeds..
a2 = A(2.0) # Ok, now we get the second constructor, because it's a perfect match.

I am fully aware that super-classes, argument-matching, (automatic) type-conversion,
and bridging the gap between python and .NET (C#) , is very complex.
And providing a full implementation that 'just do the thing we want' is not trivial.

It might be that some of the issues related to sub-classing, as well as argument matching/conversion is related, - but I hope the simple example above illustrates that
some minor improvement at this stage could be quite useful.

There is a few fixes, that could improve this slightly:

(a.) Make simple type-promotion/argument conversion happen during constructor argument matching
(b.) If construction of a .NET object is attempted, and argument match fail, then always raise Type error

I will provide a PR for (a.) since it's a simple fix to verify a simple type-promotion from int->double etc.

Fixing (b.), raise error if no .NET constructor matches the arguments is easy, but will then break the sub-class mechanism. If we knew, by the time we are calling the .NET constructor, that it's a super-class, then we could either have a relaxed matching (as is to day, default to the default-ct, if fail), and then insist on match for all other cases.

After all, providing something that fixes (b.), and at the same time supports, and possibly extends super()/sub-classing mechanism seems harder to me, since we need to know the context in which the .NET object is constructed.

If anyone see a easy solution to (b.) , - as in knowing how to get the context of the .NET class construction, that would be great.

We could then provide a fix where

' you succeed with your intention creating a new object with the supplied parameters, and get the expected result, or we raise Type-exception notifying about the problem'