On 20 May 2013 13:59, Garth N. Wells <gn...@cam.ac.uk> wrote: > On 20 May 2013 13:44, David Ham <david....@imperial.ac.uk> 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 > > > Regards, > > > > David > > > > > >> > >> > >> > >> > >> On 20 May 2013 13:09, Garth N. Wells <gn...@cam.ac.uk> wrote: > >>> > >>> On 20 May 2013 12:44, David Ham <david....@imperial.ac.uk> 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 > >>> > fenics@fenicsproject.org > >>> > 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 > -- Dr David Ham Department of Computing Imperial College London http://www.imperial.ac.uk/people/david.ham
_______________________________________________ fenics mailing list fenics@fenicsproject.org http://fenicsproject.org/mailman/listinfo/fenics
