Build failing, Ok, I have to fix the build, reverse changes to .sln and .proj files I guess.

Yes, please.

Also, your test is failing for Python 2.7 as thesuper() syntax (without arguments) is Python 3. Usesuper(PySubclass, self).__init__ ... (https://github.com/pythonnet/pythonnet/pull/239/files#diff-cce6857ae7057bf6caf15818e1ad16e0R60).

@denfromufa Regarding the approach, I'm fine with doing conversionsint-type -> float-type. This feels much more natural coming from Python where you'd do the constructor exactly like this (at least in Py3 whereint andfloat behave very similar).

Struggling a bit with build on arch-linux, mono 4.4.0.40, (before I apply my patch, using master..)
it fail on Target RGieseckeDllExport:
: error : Error initializing task DllExportAppDomainIsolatedTask: Could not load file or assembly 'Microsoft.Build.Utilities, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies.

Is this a know error/solution, or should I just try to build on a Ubuntu platform?

Struggling a bit with build on arch-linux, mono 4.4.0.40, (before I apply my patch, using master..)
it fail on Target RGieseckeDllExport:
: error : Error initializing task DllExportAppDomainIsolatedTask: Could not load file or assembly 'Microsoft.Build.Utilities, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies.

Is this a know error/solution, or should I just try to build on a Ubuntu platform?

For MonoRGieseckeDllExport cannot be used, since this is Windows-specific feature of reverse pinvoke. Instead the configuration for Mono should be selected, which uses C-API of Mono and Python to bind each other.

Thanks for the hint, but when using setup.py (as in .travis.yml build),

( Configuration: Release Mono Platform: x64) is printed out during the build
or installing monodevelop, (Ubuntu 15.10 this time, with clang, python-dev etc.)

selecting mono debug/release x64, then build the solution, the clrmodule is the only one failing,
on ubuntu it fail with 'no accesss to the given key' indicating there is some more security related issues .

It also seems that the travis now fail on the RGiesecke related stuff, the build tools 2.0.0.0 not found etc.

Appveyor seems to be happy after 2.7 fixups

Ok, now all .sln, csproj files are back to original, hopefully that solve the build issues.

I finally did succeed building the mono 4.4.1 version, Ubuntu, python 3.4, python3-dev, libglib2.0-dev added, plus all the mono stuff from standard packages on ubuntu, using virtualenv to setup python part.

But running the tests fail, when Load clr hook executes, "Error: No managed allocator , but we need one for AOT. Are you using non-standard GC options ?"

Sorry to bother you all with this, but maybe someone knows a fix (otherwise, I will just clean, rebuild, select packages specific to the travis.setup etc.., and retry.)

I finally did succeed building the mono 4.4.1 version, Ubuntu, python 3.4, python3-dev, libglib2.0-dev added, plus all the mono stuff from standard packages on ubuntu, using virtualenv to setup python part.

But running the tests fail, when Load clr hook executes, "Error: No managed allocator , but we need one for AOT. Are you using non-standard GC options ?"

This exception in Mono seems to be common lately starting ~4.4.1:

tjanczuk/edge#449

CC42169 in Bugzilla for the managed alloc bug. More info there andhere for WSL.

Ok, now the py 2.6 is the only one that need som attention. I will fix that soon, so at least the build is straighten up, then we can see if we can improve this PR to a level where it can be accepted.

Downgrading mono etc. to do local builds work is Ok for now.

Ok, now it even builds and run on arch-linux, py 3.4, mono 4.4.0.40, that is before the ~4.4.1, so now I can verify the mono version more easily as well. It was my vs2015, changing the .sln and the build that caused the mono build problems, sorry for the mess. Now that I got both win and mono up running it's easier to avoid.

Is there anything more I can contribute with so that this PR can be merged ?

@sigbjorn the problem I have is with cases when multiple types meet the auto-conversion. Without handling such behavior this PR seems incomplete to me, but resolving this is a lot more effort and will open us to a lot of potential corner cases. Why not just throw exception if exact match is not found? The user should be smart enough to provide the exact type after the error is reported.

Yes, as mentioned previously, this PR was not originally created to solve all problems related to this issue.

and yes:

A simple fix would be to throw exception if not perfect match when calling a constructor.
But unfortunately, thatsimple fix will also break the existing sub-class a .NET class feature, that rely on this flexible behaviour. ( My guess is that you would then say NO to this PR, or maybe I am wrong ?)

This problem could be resolved:
If we from the context of calling the constructor, could know that we are in a chain of super().. call-chain, we could make a fix that is aware of the context,
and then: in the context of super().. , allow anything (like it is now)
and in the other contexts (direct call to constructor), enforce exact match.

So if you/or anybody could point me in any direction that allow us to figure out if we are in a super()-call-chain, this is easy to fix. I have briefly checked the code, and found no such info in the call-chain from python to the method-binder in question dealing with constructors.

other alternatives:
Making the constructor-matching more selective, choosing the closest matching constructor can be done, - but requires a lot more changes. -And unfortunately, it does not provide exceptions for non-matching cases.

So my intention was to first provide something that I think resolves a lot of 'practical cases'.

Then, if we could get some more knowledge about the object creation (especially super/sub-class and argument passing). With that knowledge in place, fix selective matching and proper super/sub-classing in addition to throwing exception when there are no matches.

ok, the simple solution right now could be to raise a warning instead of
exception when going the route of ignoring the arguments?

I like the idea to find if we are in the super() chain! Have not figure out
yet.

On Thu, Jul 7, 2016 at 4:11 PM, sigbjornnotifications@github.com wrote:

Yes, as mentioned previously, this PR was not originally created to solve
all problems related to this issue.

and yes:

A simple fix would be to throw exception if not perfect match when calling
a constructor.
But unfortunately, thatsimple fix will also break the existing
sub-class a .NET class feature, that rely on this flexible behaviour. ( My
guess is that you would then say NO to this PR, or maybe I am wrong ?)

This problem could be resolved:
If we from the context of calling the constructor, could know that we are
in a chain of super().. call-chain, we could make a fix that is aware of
the context,
and then: in the context of super().. , allow anything (like it is now)
and in the other contexts (direct call to constructor), enforce exact
match.

So if you/or anybody could point me in any direction that allow us to
figure out if we are in a super()-call-chain, this is easy to fix. I have
briefly checked the code, and found no such info in the call-chain from
python to the method-binder in question dealing with constructors.

other alternatives:
Making the constructor-matching more selective, choosing the closest
matching constructor can be done, - but requires a lot more changes. -And
unfortunately, it does not provide exceptions for non-matching cases.

So my intention was to first provide something that I think resolves a lot
of 'practical cases'.

Then, if we could get some more knowledge about the object creation
(especially super/sub-class and argument passing). With that knowledge in
place, fix selective matching and proper super/sub-classing in addition to
throwing exception when there are no matches.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#239 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AHgZ5UdBicMXeEZATL0GQ79chMkVFHxLks5qTWudgaJpZM4JD9kR
.

Downgrading mono etc. to do local builds work is Ok for now.

Update: It should be safe to use Mono embedding again when 4.6.0 is released (or build from git if the tag updates atmono/mono).

Ok, - the moment we properly detect and figure out the super() call-chain (for all versions of python), its quite straight forward.
It requires a dive into the python type system and mechanism in play during construction of object.
This will require some more effort, - I could have a look into it next week.

@sigbjorn If you rebase and squash the PR, I'm okay with merging this.@vmuriart @denfromufa, what's your opinion?

I'm ok with auto-conversion only when a single match is found. This likely
means the number of arguments has to be one and also requires additional
logic to iterate over all possible arguments to set this "single match is
found" flag.

On Thursday, July 28, 2016, Benedikt Reinartznotifications@github.com
wrote:

@sigbjornhttps://github.com/sigbjorn If you rebase and squash the PR,
I'm okay with merging this.@vmuriarthttps://github.com/vmuriart
@denfromufahttps://github.com/denfromufa, what's your opinion?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#239 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AHgZ5Zx6UF_A8jA5W7fy529dmKZmF8w1ks5qaFwZgaJpZM4JD9kR
.

I'll run some tests tomorrow against my applications and check for no surprises :)

I could have a look if it's possible to transform the existing ct looping/matching (seems ad-hoc to me), into something that find the closest match.
If I where to invest more hours into this, I think figuring out how to separate sub-class/class initialization and raise exception if no match found would pay off most.

good from my side. The only thing I would change is the formatting of the tests, but i can take care of that later.

Sorry for the delay, I will try to find some time this weekend to dive into class/subclass, and/or also align call to constructor with the 'usual/standard' argument-matching.

@sigbjorn to override .NET constructor we may need to use__new__(), not__init__() method.

@tonyroberts do you recall why you hooked up constructor to__init__(), not__new__() intest_class.py?

The problem with initializer is that it already receives an instance of the class, while new is actually the constructor of the class.

This may be a breaking change, but would enable subclassing immutable types also:

http://stackoverflow.com/a/674369/2230844

@sigbjorn do you agree to MIT license for your contribution once we transition to it?

@sigbjorn Feel free to reopen when you find the time to address the comments (in particular agreement to the MIT license).