Hi,
by bad chance i experienced a strange and buggy treatening of .Net-Enums in
Python, that causes headache:
(i use Python 2.3, so if this is fixed in 2.4, please just tell me)
In Python .Net-enums lose their typeinformation and get simple ints, so when
used in overloaded
functions they work by chance depending on the order of the c#-functions in the
source-file.
An example is the constructor of the font class, where 4 3-argument-overloads
exist, of which 2 are of interest:
Font(string,float,FontStyle) and
Font(string,float,GraphicsUnit)
where both FontStyle and GraphicsUnit are enums, which are treated by Python as
simple ints. So which of thoose constructors is choosen depends on some
circumstances during the compilation of System.Drawing.dll.
It startet with a simple construction of a Font:
...
Assembly.LoadWithPartialName("System.Drawing")
from CLR.System.Drawing import Font, FontStyle
...
myFont=Font("Arial",8,FontStyle.Bold)
That code used to work a long time and looks very innocent... But then by
chance it throw an exception on one computer: "no constructor matches given
argument"
(but on every other computer it worked, ...)
Later i realized, that on that computer besides the current framework 1.1 the
beta of .Net 2.0 was installed, and
LoadWithPartialName took the latest System.Drawing.dll. And maybe they changed
some order of constructors in their files...
somehow with 2.0 it didn't work.
My Diagnostic tool for locating the error was a small c#-class with the same
3-argument-overloads, the font-class has, and one more with all arguments as
object. It does nothing but prints out, which constructor is called:
public class MyFont{
//...
public MyFont(string familyName,float size, FontStyle style)
{Console.WriteLine("string,float,FontStyle");}
//...
}
Then i invoked my testclass with the arguments above:
myTestFont=MyFont("Arial",8,FontStyle.Bold)
It occurs that depending of the order of the 2 constructors of interest in my
c#-source-file one time
the MyFont(string,float,GraphicsUnit) and another time the correct constructor
MyFont(string,float,FontStyle) is
choosen (it seemed to be the constructor later in the file .. but i'm not sure
if this depends more on random compilation issues)
What worries about that fact is not the issue with Font, which behavior may
change when it comes to .Net2.0. I'm concerned more about which other functions
i might implicitely call without knowing it, because of an ambiguity that does
not exist in c# because of strong typed enums.
Does someone know, if this problem is solved with 2.4, or maybe there is another
python-term, that helps strong type enums?
thanks for your help
Steffen Guhlemann