dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Wed, Dec 03, 2008 at 01:08:51PM +0100, Johan Hake wrote:
> On Wednesday 03 December 2008 13:01:33 Martin Sandve Alnæs wrote:
> > 2008/12/3 Anders Logg <logg@xxxxxxxxx>:
> > > On Wed, Dec 03, 2008 at 12:24:38PM +0100, Martin Sandve Alnæs wrote:
> > >> 2008/12/3 Anders Logg <logg@xxxxxxxxx>:
> > >> > Another thing I've been wondering about is the renaming of
> > >> > dolfin::Function to dolfin.cpp_Function. Is this really necessary?
> > >> >
> > >> > If we just removed the renaming, I guess it would still work out. So
> > >> > we would create classes in function.py that inherit from ffc.Function
> > >> > and dolfin.Function (instead of dolfin.cpp_Function).
> > >>
> > >> How?
> > >
> > > By just writing dolfin.Function instead of dolfin.cpp_Function in
> > > function.py.
> > >
> > > In function.py, we import the SWIG-generated module "dolfin":
> > >
> > > import dolfin;
> > >
> > > This module may then contain a class named "Function" which is the
> > > SWIG-generated wrapper for dolfin::Function (currently named
> > > cpp_Function). We may then define a class named "Function" in the
> > > function.py module, and this is the class that we import in the
> > > top-level __init__.py (not the one from dolfin.dolfin).
> > >
> > > Does it make sense?
> >
> > So you mean
> >
> > dolfin.dolfin.Function == dolfin.cpp_Function
> > dolfin.Function is a subclass of dolfin.dolfin.Function
> >
> > ?
> >
> > How does this make anything clearer?
> > It only obfuscates what's being done,
> > creates another namespace issue, and
> > makes it even more difficult to talk about
> > functions in dolfin.
> 
> I have actually been thinking in the same lanes as Anders. But keeping a 
> distinction to the compiled dolfin module in the module name instead as 
> cpp_dolfin.
> 
> from dolfin import *
> 
> Then the compiled version of some classes would be:
> 
> cpp_dolfin.Function aso.
> 
> But I see that we can introduce namespace troubles if some one accidentally 
> imports from cpp_dolfin.
> 
> Johan

Yes, that's even better.

SWIG generates wrappers for the classes in the C++ interface. These
classes go into a module named "cpp_dolfin", or maybe just "cpp".

Then we define the Python interface in the top-level __init__.py where
we either import classes directly from cpp or define new classes
(maybe based on the cpp classes).

I suggest we name the module just cpp since it will be a submodule of
DOLFIN so the "dolfin"-context is clear.

This would make it possible to do things like

from dolfin.cpp import Function
from dolfin.cpp import Mesh

etc.

The Mesh in dolfin and dolfin.cpp happen to be the same, but not for
Function.

-- 
Anders

Attachment: signature.asc
Description: Digital signature