(Version 2.1)

Given .NET class:

publicclassA{publicA(){a=1.0;}publicA(doubleax){a=ax;}publicdoublea;}

then in python:

fromXxximportAa1=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 wecould 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'