On 20 May 2013 13:44, David Ham <[email protected]> wrote: > Apologies for the premature send: > > Thanks, Garth. The direction of travel towards properties rather than > methods will make our life easier. > > On the point of class members which need to be called (such as the vector > size you mention below), the python @property decorator deals with exactly > this circumstance. The method is declared as a function but accessed via > property syntax. E.g > > class Foo(object): > > @property > def myproperty(self): > ... do something... > return somevalue > > now: > > f = Foo() > > f.myproperty > > This will cause the myproperty method to be called. >
Neat. Is there a way to direct Swig to do this (semi-)automatically? Garth > Regards, > > David > > >> >> >> >> >> On 20 May 2013 13:09, Garth N. Wells <[email protected]> wrote: >>> >>> 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 >>> > >> >> >> >> >> -- >> Dr David Ham >> Department of Computing >> Imperial College London >> >> http://www.imperial.ac.uk/people/david.ham > > > > > -- > 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
