dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Wed, Dec 03, 2008 at 01:57:21PM +0100, Martin Sandve Alnæs wrote:
> 2008/12/3 Anders Logg <logg@xxxxxxxxx>:
> > On Wed, Dec 03, 2008 at 01:48:49PM +0100, Martin Sandve Alnæs wrote:
> >> 2008/12/3 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.
> >>
> >> cpp is good.
> >
> > Good, anyone knows how to implement it?
> >
> 
> Simply replace "import dolfin" with "import dolfin as cpp" and replace
> "dolfin" with "cpp" in all pydolfin code.

Yes, that's one option. I was more thinking of letting SWIG generate a
module named "cpp" instead of "dolfin", but maybe your suggestion is
better (and easier).

-- 
Anders

Attachment: signature.asc
Description: Digital signature