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.
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
