[Ns-developers] Status of Python bindings

[Gustavo Carneiro]

2008/5/7 Gustavo Carneiro <gjcarneiro at gmail.com>:

>
> 2008/5/6 Mathieu Lacage <mathieu.lacage at sophia.inria.fr>:
>
[...]

>
> So,
> > maybe the simple solution to my complaints would be to find a better
> > name for that class such as 'Binding' and use it as follows:
> >
> > binding = Binding ('TopLevelModuleName')
> > binding.add_ (...)
>
>
> This is pending more discussion.
>
> I am not sure I understand the concept of this Binding...  In C++ we have
> a tree of namespaces, each containing functions and types.  This is a C++
> model centric view.  Earlier you were proposing a source header file centric
> view, where you modeled the API based on which header file it is contained.
> Can you help me understand this Binding class?  I don't quite understand
> what it tries to model...
>

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.

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?

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