dolfin team mailing list archive

[Johan Hake <hake@xxxxxxxxx>]

On Friday 08 August 2008 10:15:08 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++.

I thought of this too. And I actually tried it, using a more complex logic, 
dealing with the other arguments as well, but as Marting says, there will be 
two conflicting __init__ functions.

Johan

> > Kent
>
> Python doesn't even have function overriding, so that doesn't make
> much sense (there would be two conflicting __init__ functions).