kicad-developers team mailing list archive
-
kicad-developers team
-
Mailing list archive
-
Message #08769
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
References