On Wed, Dec 03, 2008 at 01:57:21PM +0100, 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? > > > > 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
signature.asc
Description: Digital signature
_______________________________________________ DOLFIN-dev mailing list [email protected] http://www.fenics.org/mailman/listinfo/dolfin-dev
