Repository navigation
pythonnet overloads difference between v2.5.2 and v3.0.1 #2197
Description
Activity
new_font = Font.Overloads[String, Single, FontStyle]( font_type, font_size, font_style) TypeError: No method matches given arguments for Font..ctor: (<class 'float'>, <class 'System.Drawing.FontStyle'>)Based on this example, I believe it is a bug in 3.0.1 overload resolution, probably restricted to constructors. You are clearly passing 3 arguments, but the "no matches" message only lists 2.
Ok thanks for your response.
I think I try my port without the overloading and hope the best. As stated above, the overload is not needed anymore?
@stranger0612 please ensure the parameters are actually passed. The message hints that somehow the first one might be omitted at least in the case with
.Overloads.@lostmsu Sorry to ask, but how can I ensure this? I thought as soon as I pass the parameters to a method/function, they were passed and will be used?
@stranger0612 that would be the case if there were no bugs. It seems like the first parameter is being ignored in the above error message. Try varying it and see if it has effect.
@lostmsu Ok, I tried some combination and it seems that its always the first parameter that gets ignored?
# other font overload tmp_font = Font(font_type, font_size, font_style) new_font = Font.Overloads[Font, FontStyle](tmp_font, font_style)Results in
new_font = Font.Overloads[Font, FontStyle](tmp_font, font_style) TypeError: No method matches given arguments for Font..ctor: (<class 'System.Drawing.FontStyle'>)Also this example fails
# fails font_family = FontFamily.Overloads[String]("Arial")Results in
font_family = FontFamily.Overloads[String]("Arial") TypeError: No method matches given arguments for FontFamily..ctor: ()But Overloading methods seems to work?
# that works box = MessageBox() box.Show.Overloads[String, String]("Test", "Test")Apparently we don't test constructor overloading :/
My guess would be that we only need to detect during binding whether the "method" is actually a constructor and prepend a
nullto the bind parameters. We probably do that for normal constructor calls.So is there any workaround for this issue? Otherwise, as mentioned, it seems that explicit overloading is no longer needed in my case creating an instance of the Font class.
I don't know of a workaround right now, this is a bug that has to be fixed. Overload resolution has gotten a lot better, that's probably why no one(?) seems to have stumbled over this before.
@filmor No Problem :)
So my conclusion for this issue:
There is a bug for explicit overloading. But if no overload is made, it works due better overload resolution? If explicit overloading is required, one has to wait due a future bug fix.
Environment
Details
Currently i am porting a module that uses pythonnet 2.5.2 with python 3.8. One part of that module creates a new font, for .net objects, such as Labels...
In my past approach (pythonnet 2.5.2; python 3.8) i had to use the following overload to perform this action
new_font = Font.Overloads[String, Single, FontStyle](font_type, font_size, font_style)The overload was needed, because in some combinations of the font_style, i got the following exception (for a combination that will trigger this exception, see the example at the end of the question):
So far so good. If i use the same overload approach with pythonnet 3.0.1 and python 3.9, it wont work due the following exception.
But if i skip the overload, it seems to work now? So my questions is, which approach is the "right one" to implement a robust font setter with the current pythonnet version?
For better understanding, here a minimal example to reproduce my issue
I also created a question here in stackoverflow https://stackoverflow.com/questions/76668946/pythonnet-overloads-difference-between-v2-5-2-and-v3-0-1 (actually I copied my question and added it here)