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