← Back to team overview

ffc team mailing list archive

Re: [Branch ~ffc-core/ffc/dev] Rev 1443: Remove \n in formats

 

On Wednesday 13 January 2010 12:42:46 Anders Logg wrote:
> On Wed, Jan 13, 2010 at 12:35:35PM -0800, Johan Hake wrote:
> > On Wednesday 13 January 2010 12:26:25 Marie Rognes wrote:
> > > Anders Logg wrote:
> > > > On Wed, Jan 13, 2010 at 08:27:33PM +0100, Marie Rognes wrote:
> > > >> Anders Logg wrote:
> > > >>> On Wed, Jan 13, 2010 at 06:39:56PM +0100, Marie Rognes wrote:
> > > >>>> noreply@xxxxxxxxxxxxx wrote:
> > > >>>>> ------------------------------------------------------------
> > > >>>>> revno: 1443
> > > >>>>> committer: Anders Logg <logg@xxxxxxxxx>
> > > >>>>> branch nick: ffc-dev
> > > >>>>> timestamp: Wed 2010-01-13 17:00:13 +0100
> > > >>>>> message:
> > > >>>>> Remove \n in formats
> > > >>>>> modified:
> > > >>>>> ffc/cpp.py
> > > >>>>
> > > >>>> I like the \n in formats. Makes more sense to me to have a line
> > > >>>> break after for instance "each assignment" than explicitly stating
> > > >>>> breaks in the code generation functions.
> > > >>>
> > > >>> I agree, but it becomes problematic in some cases. For example when
> > > >>> we insert things into the UFC format strings in the formatting
> > > >>> stage:
> > > >>>
> > > >>>  /// Return the dimension of the finite element function space
> > > >>>  virtual unsigned int space_dimension() const
> > > >>>  {
> > > >>> %(space_dimension)s
> > > >>>  }
> > > >>>
> > > >>> Then we get things like
> > > >>>
> > > >>>  virtual unsigned int space_dimension() const
> > > >>>  {
> > > >>>    return 3;
> > > >>>
> > > >>>  }
> > > >>
> > > >> Remove the "\n" in the format["return", "comment"] then ... and keep
> > > >> "iadd" and "assign" then?
> >
> > Sorry for bumping into the discussion with a potentially irrelevant
> > comment.
> >
> > Have you considered collecting code snippets in a list by
> >
> >   code_snippets.append(code_snippet)
> >
> > and then last you do a
> >
> >   code = "\n".join(code_snippets)
> >
> > This might also be faster (if this snippeting is ever going to be a
> > bottle neck?), as string is immutable in Python which means that
> >
> >   code_snippet += some_code
> >
> > always creates a new string.
> 
> Good point. This makes good sense in some places but not in others.

Sure!

> I've used it now in one more place.

:)

Johan



References