dolfin team mailing list archive

["Martin Sandve Alnæs" <martinal@xxxxxxxxx>]

2008/12/3 Johan Hake <hake@xxxxxxxxx>:
> On Wednesday 03 December 2008 13:57:21 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?
>> >
>> > --
>> > Anders
>>
>> Simply replace "import dolfin" with "import dolfin as cpp" and replace
>> "dolfin" with "cpp" in all pydolfin cod
>
> Won't dolfin.dolfin still excist? As that file resides in
> your-python-installation/site-packages/dolfin/

Right.

> A more robust way would be to change the %module statement in dolfin.i from
> dolfin to cpp, producing a module named cpp.py instead of dolfin.py.
>
> Then we should be able to also define the package the compiled module will
> reside in by saying:
>
> %module(package="dolfin",directors=1) cpp
>
> in dolfin.i.
>
> I think this also will solve some of the funny things we have encountered in
> pycc when we have imported the dolfin swig wrapper file by %import dolfin, as
> the package hiarchy follows the one stated in the dolfin.i file, which is not
> the case today.
>
> Johan

Good!

--
Martin