← Back to team overview

ufl team mailing list archive

Re: Pretty print of UFL form

 

On Mon, Aug 08, 2011 at 10:26:07AM -0700, Johan Hake wrote:
> 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?

Sounds like a clever solution to me.

--
Anders


Follow ups

References