← Back to team overview

kicad-developers team mailing list archive

Re: Python binding of enums


On 08/09/2012 09:18 AM, Miguel Angel Ajo Pelayo wrote:
> >From what I saw yesterday on my investigation, we're doing that correctly, 
> we fetch the .h, and as the .h has the enum, swig implement that enum values in python,
> but if you look at them carefully (under the swig code), you will see that it internally
> uses "int" 
> for that.
> So where you are saying obj.SetLayer(LAYER_15)
> one could say obj.SetLayer(15)
> and no typecheck will show up,
> anyway, the problem could appear if an intrepid user does:
> obj.SetLayer(45)
> That will under the hood in our C++, because swig will accept it (int is the internal
> representation used for enums values),
> and if somebody does layer[n] somehow with n> elementsOf(layer) , we will have trouble.

Yes, I understood all this already.

C++ has type checking, this is something that the project originators came to rely on. 
Jean-Pierre, et. al.  It was considered when adopting the language.

Throwing exceptions from C++ for bad arguments is visual noise that the C++ adopter did
not bargain for when he chose the language.

It was also not bargained for when accepting SWIG to tag along.

It is a cost and an imposition to throwing these exceptions, visually, and in
maintenance.  C++ type checking an enums were designed to prevent the need for this.

I think as you move away from enums into ints as parameters, then C++ has no inherent
compile time protections, so this is not so black and white there.

But throwing "bad argument exceptions" from every C++ function callable from python was
not part of the original bargain.

I do not see a similar support infrastructure within wxWidgets, yet wxPython seems to work
adequately.  Keep thinking.

Follow ups