[Ns-developers] Status of Python bindings

[Mathieu Lacage]

On Thu, 2008-05-08 at 11:50 +0100, Gustavo Carneiro wrote:

> OK, from IRC discussions and thinking about this some more, I think I
> understand what you mean.
> 
> But first, a question of terminology.  Normally, when you are talking
> about language bindings, there is this concept of
> translation/adaptation of a single function or method from one
> language (e.g. Python) to another one (e.g. C++).  We usually call his
> a "language binding".  Notice the singular.  A package like pygtk
> contains a set of Python bindings (notice the plural) that map each C
> function in the Gtk+ library into an equivalent Python function or
> method.
> 
> That is why I think your Binding object does not make sense for those
> in the field of language bindings.  But if you were to rename that as,
> for instance, BindingGroup, then it would start to make some sense to
> me.

I think that the goal is not to make sense to those in the field of
language bindings: the goal is to make sense to a simple unsophisticated
user who just wants to generate a python binding for his c++ code.

> 
> Now, on to the matter of associating a BindingGroup to a module or
> namespace.
> 
> As I said, in Python we have a tree of modules and submodules.  In C++
> we have a tree of namespaces and nested namespaces.  Will the
> BindingGroup be attached to a C++ namespace or to a submodule?
> 
> If we want to make BindingGroup a little more generic than C++, we
> could say that it maps either to a (sub)module or to a C++ namespace.
> 
> bindings = BindingGroup(module_path="ns3.Config")
> 
> or
> 
> bindings = BindingGroup(cpp_namespace="ns3::Config")
> 
> The difference is, if BindingGroup is associatged with a C++
> namespace, we can make it so that a (sub)Module is created on demand
> for each unique C++ namespace that is referenced.  These automatically
> created modules become associated with the respective C++ namespaces
> and classes added to it can wrap classes in that namespace.
> 
> OTOH, if BindingGroup is associated with a module path, either modules
> cannot be created on demand, or if they are they will not know their
> own namespace.  Thus, wrapped classes added to it will not belong to
> any namespace, or at least PBG will not know it and cannot wrap the
> classes if they belong in some namespace.  But I guess this concept is
> still useful for simple grouping of related bindings in C modules.
> 
> So I propose just the above dual interface:
> 
> class BindingGroup:
>     def __init__(self, cpp_namespace=None, module_path=None)
> 
> Thus both these would work:
>    bindings = BindingGroup(cpp_namespace="ns3::Config")
>    bindings = BindingGroup(module_path="ns3.Config")
> 
> Comments?

I have to confess that after our discussion on irc, I think that I do
understand better the way the current API works: I am still somewhat
unsatisfied with it but the above proposal does not strike me as vastly
better to warrant a change.

Mathieu