dolfin team mailing list archive
-
dolfin team
-
Mailing list archive
-
Message #24168
Re: [Ufl] Pretty print of UFL form
On Monday August 8 2011 09:48:26 Anders Logg wrote:
> On Mon, Aug 08, 2011 at 08:35:05AM -0700, Johan Hake wrote:
> > On Monday August 8 2011 05:31:41 Martin Sandve Alnæs wrote:
> > > On 6 August 2011 09:24, Johan Hake <johan.hake@xxxxxxxxx> wrote:
> > > > Hello!
> > > >
> > > > When you print a form to get its str representation in pydolfin it is
> > > > severaly polluted by the layer DOLFIN add to especially
> > > > Function.__str__.
> > > >
> > > > I know this is PyDOLFIN's fault, but would it be possible to let the
> > > > pretty print algorithm in ufl use some internal str function instead
> > > > of __str__ when the str representation of a form is gathered.
> > > > Coefficient.__str__ could then just call that function and from ufl
> > > > it would just be the same.
> > > >
> > > > Johan
> > >
> > > Not sure what you mean here. I don't see a solution that
> > > doesn't involve changing all __str__ functions in ufl.
> >
> > Yes this would probably be required. I guess that was a "no that wont
> > happen"
> >
> > :)
> >
> > Then I am inclined to let Function.__str__ just use
> > ufl.Coefficient.__str__.
>
> Is it not possible to use some kind of downcasting to make sure that
> ufl.Coefficient.__str__ is used in pretty-print from PyDOLFIN?
There are no downcasting in Python ;)
But you can dynamically call another function depending on who is looking at
an object. That was my original solution. This have to be implemented in ufl,
which would be the caller in this case. But creating a special solution for
Coefficient would not be satisfactory, so one would need to do some sort of
change through out the whole library, which is not cool, I guess.
> I'm not sure removing the dolfin.Function information is a good option.
I tend to agree. But printing a form create so much polution in terms of
Function string representation that it become useless. We could move the
verbose information in todays Function.__str__ to Function.str. Then we would
trigger that information by taking:
>>> info(u)
<Function in <Function space of dimension 9 (<CG1 on a <triangle cell in
R2>>)>>
Then we need to make sure that Function.__str__ maps to Coeffcicient.__str__.
A nice compromise?
Johan
Follow ups
References