Repository navigation
pythonnet overloads difference between v2.5.2 and v3.0.1 #2197
Description
Environment
- Pythonnet version: 3.0.1
- Python version: 3.9
- Operating System: Win10
- .NET Runtime: 4.0.30319.42000
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):
new_font = Font(font_type, font_size, int(font_style))
System.ArgumentException: Ungültiger Parameter.
bei System.Drawing.Font.CreateNativeFont()
bei System.Drawing.Font.Initialize(FontFamily family, Single emSize, FontStyle style, GraphicsUnit unit, Byte gdiCharSet, Boolean gdiVerticalFont)
bei System.Drawing.Font..ctor(String familyName, Single emSize, GraphicsUnit unit)
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.
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'>)
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
import clr
clr.AddReference("System")
clr.AddReference("System.Drawing")
from System.Drawing import Font
from System.Drawing import FontStyle
from System import String
from System import Single
font_type = "Arial"
font_size = 12.0
font_style = FontStyle.Regular | FontStyle.Bold
# fails with pythonnet 3.0.1; works with pythonnet 2.5.2
new_font = Font.Overloads[String, Single, FontStyle](font_type, font_size, font_style)
# works with pythonnet 3.0.1, but fails with pythonnet 2.5.2
new_font = Font(font_type, font_size, font_style)
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)
Activity
lostmsu commentedon Jul 20, 2023
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.
stranger0612 commentedon Jul 21, 2023
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?
lostmsu commentedon Jul 21, 2023
@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.stranger0612 commentedon Jul 21, 2023
@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?
lostmsu commentedon Jul 21, 2023
@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.
stranger0612 commentedon Jul 21, 2023
@lostmsu Ok, I tried some combination and it seems that its always the first parameter that gets ignored?
Results in
Also this example fails
Results in
But Overloading methods seems to work?
filmor commentedon Jul 21, 2023
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.stranger0612 commentedon Jul 21, 2023
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.
filmor commentedon Jul 21, 2023
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.
stranger0612 commentedon Jul 21, 2023
@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.