Repository navigation
Pythonnet 2.1 not identifying System.Object type #203
Description
I'm not sure how the tests wouldn't have caught this bug.
I have a .net class that has the function AddQuery with the following method signatures.
AddQuery
Void AddQuery(api.QueryType)...
Void AddQuery(System.Object)...
where QueryType is another custom object type.
On 2.0 and 2.1dev1 the function works as expected.
- I can pass a
QueryTypeobject toAddQueryand it would call the first method. - Calling
AddQuerywith astringorintwould use the second method and process them.
On 2.1.0 and the earliest archived copy in appveyor this behavior changed.
- Passing
QueryTypeobject toAddQuerystill works. - Passing
stringtype toAddQueryerrors withNo method matches given arguments
I've tested on Python 2.7, Python 3.5 both x64.
Looks like Pythonnet is no longer identifying string int and other types to be of type System.Object as well.
Activity
vmuriart commentedon Apr 17, 2016
Possibly related to #187
Tested on windows 7 and 8.1
vmuriart commentedon Apr 17, 2016
Tried build before and after #176, both still have this bug present.
den-run-ai commentedon Apr 17, 2016
@vmuriart
try passing
System.Object("your_python_string")orSystem.Object(123)forstringorinttypes respectively.this breaking change is because implicit casting can be dangerous:
#131
vmuriart commentedon Apr 17, 2016
@denfromufa just tried your suggestion and it semi-works. It passes through
pythonnetand passes theObject-type stringto the library I'm using, and breaks there. The underlying function is expecting aString-type stringand fails to identify theObject-type stringas such.den-run-ai commentedon Apr 17, 2016
did you try
System.String()andSystem.Int32()? or maybe evenSystem.Object(System.String())...vmuriart commentedon Apr 17, 2016
I did. those to work, but have to explicitly cast each type before sending it.
I'm taking a look at the src; I think there might be a better solution for the original bug #131 that would both fix the bug and not break legacy code. Might even try to fix #90 finally 😄
den-run-ai commentedon Apr 17, 2016
@vmuriart I'm thinking of context manager that would allow you to specify "unsafe" casting operations like before for overloaded methods, see discussion here (my 4th comment):
#174
den-run-ai commentedon Apr 17, 2016
@vmuriart I think for your case, the overloading resolution in pythonnet could be improved by checking isinstance("string",System.Object) which corresponds to
isoperator in c#, but this is still dangerous - what if both types are present in 2 different overloaded methods?vmuriart commentedon Apr 17, 2016
I see your point. I'm not familiar enough with the source code in relation to how pythonnet decides which method to call.
The way I was thinking of it is that each Python type has an underlying c-type associated to it which should give an indication how to properly cast it into its equivalent
.netcounterpart. That may or may not work as a solution here thoughden-run-ai commentedon Apr 17, 2016
@vmuriart python and .net types cannot be directly mapped to c-types due to much more complicated type system. all conversions are manually taken care for basic types in pythonnet:
https://github.com/pythonnet/pythonnet/blob/master/src/runtime/converter.cs
vmuriart commentedon Apr 18, 2016
The problem that I am having with it at the moment is that quite a few of the libraries have broken with
2.1release. Not sure if in this case the benefit outweighs the loss of backward compatibility.@tonyroberts it seems pr #151 has introduced a few incompatibilities in the attempt to solve #131. Can #151 be reverted until a better fix is in place?
den-run-ai commentedon Apr 18, 2016
Can we just look at all types of incompatibilities that you experience with
new method overloading?
Then we should really think whether the wrong results from
method overloading are less important than possible exceptions
with incompatible types? It would be very hard to spot the former and very
easy to fix or workaround the latter.
On Sunday, April 17, 2016, Vik [email protected] wrote:
tonyroberts commentedon Apr 18, 2016
@vmuriart @denfromufa my preference would be to attempt to fix 2.1 to fix the backward compatibilities, rather than just roll back. If it's just adding a case so that System.Object matches everything then hopefully that wouldn't be a big change, would it? Or are there more problems than that?
tonyroberts commentedon Apr 18, 2016
@vmuriart would it be easy for you to add a few unit tests to check what's currently breaking? I think it's better to show the build currently as broken, if the only reason it's not showing as broken now is just lack of test coverage! :)
den-run-ai commentedon Apr 18, 2016
@tonyroberts so match even python
objectonSystem.Object?16 remaining items
matthid commentedon Dec 4, 2016
Just an idea: Maybe Roslyn can help with issues like these. If we can re-use their (or parts of their) overload resolution logic we don't need to reimplement the spec.
On the other hand: Going a different route is valid as well. In F# you actually need to mark implicit casts with an operator (while this case would still work as everything is an object)
den-run-ai commentedon Dec 4, 2016
@matthid i was thinking about re-using roslyn as well, but then we have a lot of python-specific logic.
what do you mean by "On the other hand: Going a different route is valid as well"?
matthid commentedon Dec 4, 2016
What I meant was that pythonnet doesn't need to mirror C# overload resolution logic. Instead it is completely fine to define its own (possibly simpler) logic. For this issue I'd say that most people expect this to work. But IMHO it could be closed as "wontfix" as well (and say that "by-design" types need to match exactly).
It depends on what spec/design guideline this project follows. As you are trying to mirror ironpython(?) this is most likely a bug :)
adding object type to methodbind
adding object type to methodbind
adding object type to methodbind
adding object type to methodbind
adding object type to methodbind
adding object type to methodbind
adding object type to methodbind
adding object type to methodbind
den-run-ai commentedon Feb 15, 2017
it appears that precedence of types is simplified version of Jython, found by @vmuriart 👍
https://github.com/pythonnet/pythonnet/blob/master/src/runtime/methodbinder.cs#L170
I'm not sure how this compares to IronPython, but likely very similar due to the same author:
https://en.wikipedia.org/wiki/Jim_Hugunin
vmuriart commentedon Feb 15, 2017
Fun fact on the history of Jim and IronPython.