2008/12/3 Johan Hake <[EMAIL PROTECTED]>: > On Wednesday 03 December 2008 13:57:21 Martin Sandve Alnæs wrote: >> 2008/12/3 Anders Logg <[EMAIL PROTECTED]>: >> > On Wed, Dec 03, 2008 at 01:48:49PM +0100, Martin Sandve Alnæs wrote: >> >> 2008/12/3 Anders Logg <[EMAIL PROTECTED]>: >> >> > 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 <[EMAIL PROTECTED]>: >> >> >> > > On Wed, Dec 03, 2008 at 12:24:38PM +0100, Martin Sandve Alnæs > wrote: >> >> >> > >> 2008/12/3 Anders Logg <[EMAIL PROTECTED]>: >> >> >> > >> > 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 _______________________________________________ DOLFIN-dev mailing list [email protected] http://www.fenics.org/mailman/listinfo/dolfin-dev
