dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Fri, Aug 08, 2008 at 11:24:39AM +0200, Martin Sandve Alnæs wrote:
> 2008/8/8 Kent-Andre Mardal <kent-and@xxxxxxxxx>:
> > On fr., 2008-08-08 at 10:15 +0200, Martin Sandve Alnæs wrote:
> >> 2008/8/8 Kent-Andre Mardal <kent-and@xxxxxxxxx>:
> >> > On fr., 2008-08-08 at 09:50 +0200, Martin Sandve Alnæs wrote:
> >> >> How would you do this? The way the dolfin.Function class is created
> >> >> destroys the documentation of constructor signatures, which in my
> >> >> opinion is really really bad.
> >> >>
> >> >> You could just add:
> >> >>
> >> >> def as_vector(x):
> >> >>     v = Vector(len(x))
> >> >>     v.set(x)
> >> >>     return v
> >> >>
> >> >> then we can do
> >> >> x = zeros(10)
> >> >> v = as_vector(x)
> >> >>
> >> >> and the dolfin.Function constructor can just as easily do this step.
> >> >>
> >> >
> >> > We could add something like this to the SWIG interface file.
> >> >
> >> > %extend dolfin::Vector {
> >> >  %pythoncode %{
> >> >
> >> >    def __init__(self, v):
> >> >      a = Vector(len(v))
> >> >      a.set(v)
> >> >      return a
> >> >  %}
> >> > }
> >> >
> >> >
> >> > This might remove other constructors ? I'm not exactly sure how SWIG
> >> > deal with constructors both in Python and C++.
> >> >
> >> > Kent
> >>
> >> Python doesn't even have function overriding, so that doesn't make
> >> much sense (there would be two conflicting __init__ functions).
> >>
> >
> > I know Python does not support overloading, but you can write a __init__
> > function that parses the arguments and either does something in Python
> > or pass the arguments to the constructors in the extension module.
> > Whether SWIG will do this when parsing both constructors in Python and
> > C++ I don't know, probably not automatically. It should still be
> > possible, but maybe not worth the effort.
> >
> > Kent
> 
> SWIG can't possibly implement this kind of code rewriting logic.
> 
> Doing it manually requires either removing the constructors SWIG
> generates somehow (don't know if that's even possible), or making a
> subclass like Function, which hides the constructor signatures from
> the documentation.

Is it possible to do some trick to move the documentation strings over
to the Python subclasses? Something like

   Foo.__doc__ = ...

?

-- 
Anders

Attachment: signature.asc
Description: Digital signature