[Ns-developers] Status of Python bindings

[Gustavo Carneiro]

2008/5/8 Mathieu Lacage <mathieu.lacage at sophia.inria.fr>:

>
> 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.


I think normal users not experienced with language bindings will not know
anything and will have to learn either the term Binding or Bindings, and it
makes no difference which one, so it might as well be the correct term...


> >
> > 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.


OK, great.  In any case I made some minor API changes (split Module into
ModuleBase, Module, and SubModule) and added documentation:
http://telecom.inescporto.pt/~gjc/pybindgen/doc/pybindgen-apidocs/pybindgen.module-module.html

I hope it helps.  Next I will will prototype the other API changes you
suggested, then work on applying it to the NS-3 case, and finally work on
splitting the generated script into several files, one per module.  This
might take a few weeks, so be patient... :P

-- 
Gustavo J. A. M. Carneiro
INESC Porto, Telecommunications and Multimedia Unit
"The universe is always one step beyond logic." -- Frank Herbert