On 20/05/13 14:22, David Ham wrote: > On 20 May 2013 13:59, Garth N. Wells <[email protected] > <mailto:[email protected]>> wrote: > > On 20 May 2013 13:44, David Ham <[email protected] > <mailto:[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 > > > My swig knowledge is essentially non-existent. But this conversation > appears to indicate how to do it: > > http://swig.10945.n7.nabble.com/Extending-Python-proxy-classes-with-decorators-td12347.html
Johan would probably be the person to comment on this. You might not want to go that route, but another option is leaving the SWIG layer untouched and monkey patching / subclassing the SWIG generated classes in dolfin.cpp and add @property decorators in there. Florian > > Regards, > > > > David > >> > >> On 20 May 2013 13:09, Garth N. Wells <[email protected] > <mailto:[email protected]>> wrote: > >>> > >>> On 20 May 2013 12:44, David Ham <[email protected] > <mailto:[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
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ fenics mailing list [email protected] http://fenicsproject.org/mailman/listinfo/fenics
