On 20 May 2013 12:44, David Ham <[email protected]> wrote: > Hi all, > > I'm writing Dolfin-compatible wrappers for PyOP2 as previously advertised at > FEniCS '13, which is causing me to bump into one of the "interesting" quirks > of the Python Dolfin API. Lots of things which would appear to naturally be > properties are actually methods and have to be called to be accessed. For > one among many, many examples, consider the value_size method of a Function. > This is accessed with: > > f.value_size() > > while > > f.value_size > > would seem more natural. Given the existence of the @property decorator in > standard Python which translates the former into the latter, this is > particularly mysterious. Is there a reason why this is done in Dolfin? >
A few of us discussed this in January. I agree that the latter is cleaner. First point, the Python interface is largely generated automatically, so that's our starting position. We would save on C++ code and get the syntax ' f.value_size' in many cases by not accessing member data via functions. I like skipping the function, and have been doing so lately with new code. The issue we discussed in January was backwards compatibility - we could make a lot of C++ changes to get the syntax 'f.size', but users would have to update their code (this point bothers me less than it does others :)). In some cases we need a method, e.g. to get the size of a vector from a linear algebra backend. Storing the size in a wrapper is error prone. In summary, the reason for the interface in some parts is history/convention (with no technical reason), and in other cases it's a method for technical reasons. We could move more towards direct access to member data. Garth > For PyOP2, many of these properties of classes really are properties in the > Python sense, so I find myself writing an awful lot of wrapper routines just > to achieve compatibility with Dolfin. > > David > > -- > Dr David Ham > Department of Computing > Imperial College London > > http://www.imperial.ac.uk/people/david.ham > > _______________________________________________ > fenics mailing list > [email protected] > http://fenicsproject.org/mailman/listinfo/fenics > _______________________________________________ fenics mailing list [email protected] http://fenicsproject.org/mailman/listinfo/fenics
