I spent a little time last night looking at the coding requirements for creating native (C essentially) extensions to Python. This has come up previously in conversations as another way to make native code accessible functions available for scripting by folks who aren’t development engineers.
The facility appears similar in style to that provided for writing perl extensions or JNI. No surprise here. I’ll probably try playing with this a little bit sometime soon just to get a feel for the full series of steps. The process involved in getting the *.dll or *.so file into the right spot to be usable seems a little bit opaque, but perhaps it is just so automated that it isn’t much of an issue.
I’m not a huge fan of Python but it has a huge following and seems to be a useful intermediate step between shell scripting sorts of activity and full powered implementation languages (C++/C#/Java).
I wish python had not chosen such a poorly conserved item as white-space to represent block scoping (the tabs/spaces issues are not generally fixable without making the representation issues worse). They also seem to have created a permanent 2.x/3.x schism where quite a few years after the major version upgrade there is still a substantial amount of code on either side of the divide. Perl 5/6 had a similar issue, but perl 6 never seems to have taken off so the impact is much smaller.
Some links that seemed useful: