dolfin team mailing list archive

[Ola Skavhaug <skavhaug@xxxxxxxxx>]

Garth N. Wells skrev den 29/03-2008 følgende:
> 
> 
> Johan Hake wrote:
> > On Saturday 29 March 2008 15:56:29 Anders Logg wrote:
> >> On Sat, Mar 29, 2008 at 02:42:24PM +0100, Joachim B Haga wrote:
> >>> I'm just starting finding my way around dolfin, and I think it would be
> >>> easier (more discoverable in ipython or your-ide-of-choice) if the dolfin
> >>> namespace weren't so cluttered.
> >>>
> >>> At the moment there are 546 attributes in the dolfin namespace (with only
> >>> ublas). I don't know dolfin well enough to say which are pointless, but I
> >>> can make some educated guesses:
> >>>
> >>> - 113 of the functions in the main namespace are called *_swigregister,
> >>> and are probably not meant to be called by the user.
> >>>
> >>> - A number of functions seem to be "leaked" from c++. Examples: ios,
> >>> ios_base, ios_base_sync_with_stdio, ios_base_xalloc, iostream, istream,
> >>> istringstream, endl_cb_ptr, ends, ends_cb_ptr.
> >>>
> >>> - Some utility functions which are not dolfin-specific. Example:
> >>> is_empty, tokens(?)
> >>>
> >>> - Functions that duplicate native python functions or numpy/math
> >>>   functions. Examples: ipow, sqr, rand, DOLFIN_PI, Identity
> >>>
> >>> - Some all-uppercase attributes are constants, other are classes. Are the
> >>>   constants used? If so, maybe use a submodule (namespace) for constants?
> >>>   Examples: LINE, TRIANGLE vs. ODE, LU.
> >>>
> >>> - 20 other 1-2 character attributes. I know some of them are end-user
> >>>   relevant. Are all? D, a, b, cg, dS, ds, dx, f, i, j, k, l, m, n, t0,
> >>> t1, v, v0, v1, v2
> >>>   (Side note: the demos use "from dolfin import *". The common pattern of
> >>> "for i in N:" will rebind the variable "i" outside the loop, so this is
> >>> rather fragile in practice. The fully qualified variant "dolfin.i" is of
> >>> course immune to this problem.)
> >>>
> >>> - 11 cpp_* functions. Are they meant to be called by the user?
> >>>
> >>> - A few leaks from other modules. Examples: Set (sets.Set), array
> >>> (numpy.array)
> >>>
> >>> - Variables that are probably used internally in the library.
> >>>   vecs = [array([ 2.,  0.,  0.]), array([ 0.,  2.,  0.])]
> >>>   a = (-1.0, -1.0, -1.0)
> >>>   b = (1.0, -1.0, -1.0)
> >>>   cg = 0
> >>>   alpha = 0.0
> >>>
> >>> - Class methods that are also exposed directly. Examples:
> >>>   MatrixFactory_computeConvectionMatrix (MatrixFactory.computeConv...)
> >>>   MatrixFactory_computeLoadVector (MatrixFactory.computeLoad...)
> >>>   MatrixFactory_computeMassMatrix (MatrixFactory.computeMass...)
> >>>   MatrixFactory_computeStiffnessMatrix (MatrixFactory.computeStiff...)
> >>>   GraphPartition_*
> >>>
> >>> - Some non-obvious names. Examples: dolfin_{add,get,set} which could
> >>> perhaps be called {add,get,set}_parameter. I was actually looking for
> >>> this functionality but didn't find it before compiling this list :)
> >> Good suggestion.
> >>
> >>> - The 23 methods called ublas_* or uBlas* are an obvious candidate for a
> >>>   submodule, or are they supposed to be used directly instead of through
> >>>   GenericMatrix etc? I don't have petsc, but that's probably another
> >>> candidate.
> >>>
> >>>
> >>> I could make a patch myself, but I don't know enough about this stuff to
> >>> feel comfortable making these decisions (especially since some of the
> >>> choices are probably made for c++/python equivalence, and I don't plan to
> >>> use the c++ part).
> >>>
> >>> -j.
> >> You are right, there are too many things being imported. This is
> >> because we've been lazy and done import * in many places.
> >>
> >> If you want to make a patch (hg export) or bundle, that would be
> >> excellent. Remove as much as you can, as long as it's possible to
> >> run the demos.
> > 
> > I agree with Joachim and Anders that the namespace is too cluttered. Some are 
> > probably easy to remove, eg. all swig_ names and the polutions from other 
> > packages that is internally used. 
> > 
> > But some of the pointed out names are imported from FFC, should we eg. place 
> > this in dolfin.ffc? In a demo or program you could then from dolfin.ffc 
> > import *. I would also suggest to modularize the actuall dolfin namespace 
> > too, a la the c++ modules, eg. put all mesh related things in dolfin.mesh 
> > aso.
> > 
> > How close is the python interface ment to be to the c++ interface? 
> 
> I would like to keep them similar.
> 
> I have a
> > feeling that modularization of namespaces is good practice in python. Doing 
> > this in a more extensive manner would ofcourse diverge the two interfaces 
> > with regard to namespaces.
> > 
> 
> If we refine the C++ namespace, how hard would it be to reflect this in 
> the Python code (i.e. can Swig deal with it automatically)? It would be 
> nice to have dolfin::mesh and dolfin.mesh, dolfin::la and dolfin.la, etc.

We're in the lucky situation where the dolfin.py and _dolfin.so files are not
imported directly, but through the __init__.py file in site-packages/dolfin.
Hence, we can make the modularization exactly the way we want. The question is
how we want it.

Ola
 
> Garth
> 
> > Johan
> > _______________________________________________
> > DOLFIN-dev mailing list
> > DOLFIN-dev@xxxxxxxxxx
> > http://www.fenics.org/mailman/listinfo/dolfin-dev
> 
> 
> _______________________________________________
> DOLFIN-dev mailing list
> DOLFIN-dev@xxxxxxxxxx
> http://www.fenics.org/mailman/listinfo/dolfin-dev