← Back to team overview

ffc team mailing list archive

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

 

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.


I think this is what we did before, and I can happily revert to that.

--
Marie

I've used it now in one more place.

Note that we are currently pushing to ffc/dev instead of ffc/main so
changes will appear there.

--
Anders




References