Wrapping Python - A function wrapping template

[Kirk McDonald]

Tom S wrote:
> Daniel Keep wrote:
> 
>> Indeed it does.  It's somewhat hard to tell that Python's even involved
>> anymore :)  The only other two things I can think of are:
>>
>> 1. Being able to use def!(foo), then just parse out foo's original name
>> would be cool :)
>>
>> 2. I wonder if you can somehow pinch the current module's name for the
>> module_init() call.
>>
>> Not criticisms by any stretch of the imagination; just curious if it'd
>> be possible.  Can't wait to get my grubby mits on your code :)
> 
> 
> I think this stuff might help now: 
> http://dsource.org/projects/ddl/browser/trunk/meta
> 

Wow! That nameof module is quite something. I can quite easily do number 
(1) above (while still providing the ability to explicitly enter the 
name, of course!), but (2) is harder. The module_init function is 
naturally in a different module than then call to module_init. In this 
example case, it is easy enough to pull the module name out of foo's 
fully qualified name, but of course foo might be in a different module 
than the call to module_init, also! (And, similarly, a project of any 
size would likely have functions across more than one module; which one 
would you use?) Any other approaches would probably impose more of a 
burden on the user than simply entering the module's name.

Of course, I could always say "if you don't provide a name to 
module_init, the name of the module in which the first function in the 
list is found will be used." But that could easily lead to oddity; I'd 
rather have it be explicit. On the other hand, it might be enough for 
small projects like the example.

In other news, I am currently refactoring my object wrapper into a 
single class, rather than a hierarchy of classes. This is how 
Boost.Python does it, and it turns out it actually is a better way than 
the way I was doing it. Not only is it easier to work with, but the code 
ends up being easier to understand, too.

-Kirk McDonald