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.h...@gmail.com> 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 _______________________________________________ Mailing list: https://launchpad.net/~dolfin Post to : dolfin@lists.launchpad.net Unsubscribe : https://launchpad.net/~dolfin More help : https://help.launchpad.net/ListHelp
