Johan Hake wrote:
> On Sunday 19 October 2008 00:24:36 Anders Logg wrote:
>
>> On Sat, Oct 18, 2008 at 11:55:32PM +0200, Johan Hake wrote:
>>
>>> On Saturday 18 October 2008 23:23:24 Anders Logg wrote:
>>>
>>>> On Sat, Oct 18, 2008 at 10:16:32PM +0200, Johan Hake wrote:
>>>>
>>>>> On Saturday 18 October 2008 21:24:53 Anders Logg wrote:
>>>>>
>>>>>> On Thu, Oct 16, 2008 at 03:38:01PM +0200, Martin Sandve Alnæs wrote:
>>>>>>
>>>>>>> "in" is a reserved keyword in python. Suggestions:
>>>>>>> "f.in_space(V)" or "f.in_function_space(V)" or "f.member(V)"
>>>>>>>
>>>>>> How about keeping u.in(V) in C++ and then map it to something
>>>>>> suitable in Python so that one may write
>>>>>>
>>>>>> if u in V:
>>>>>> ...
>>>>>>
>>>>>> in Python. Does anyone know how to do that?
>>>>>>
>>>>> There is a problem in the logic here. In c++ you ask the function if
>>>>> it is in a certain FunctionSpace, but the python code "u in V" would
>>>>> check if u is in V by calling V.__contains__(u). To make it more
>>>>> consistent we could implement the 'in' function in FunctionSpace, and
>>>>> then just rename 'in' to __contains__.
>>>>>
>>>>> You could also keep it the way it is and then rename Function.in to
>>>>> let say Function._in and then extend FunctionSpace with
>>>>>
>>>>> def __contains__(self,u).
>>>>> assert(u,Function)
>>>>> return u._in(self)
>>>>>
>>>>> But then we would have different logics in c++ and python.
>>>>>
>>>>> Johan
>>>>>
>>>> I think that would be ok, considering it is Python that maps "in" to
>>>> "contains". The logic and notation from a user perspective would be
>>>> the same in C++ and Python:
>>>>
>>>> if (u.in(V))
>>>> {
>>>>
>>>> }
>>>>
>>>> if u in V:
>>>>
>>> I see your point and I agree.
>>>
>>> My logical error was attached to who implemented what. But to get the
>>> nice and from a user perspective logical syntax you present above, we
>>> need to implement it differently in c++ and python.
>>>
>> ok, good. Can you implement it?
>>
>
> Yes, but I would like to have Martins feedback on how 'pythonic' the
> implementation is.
>
> In most regards will the python version, "u in V" answer the question "is u
> an
> item in V", where V is interpreted as a sequence or container. The function,
> u is strictly speeking not an item in V. You can for example not access u
> from V.
>
> It's just a gut feeling I have that we might stretch the python interface a
> bit here. This is maybee not a bad idea when you have the somewhat
> minimalistic function name 'in' from c++ in mind, but if you have a pure
> python background it could be a bit confusing.
>
> I think I would go for the _slightly_ more verbal u.in_space(V)
> implementation. You should not avoid two word function name for all cost ;)
>
>
I might be butting in here, but isn't the main idea of the special
Python methods __contains etc, precisely the possibility of decoupling
the abstraction idea from the implementation?
Here, I imagine that the point is to represent a mathematical
abstraction - whether a function is an element of a function space. In
my opinion, the syntax
if u in SpaceOfPiecewiseSomething:
does this well.
--
Marie E. Rognes
Ph.D Fellow,
Centre of Mathematics for Applications,
University of Oslo
http://folk.uio.no/meg
_______________________________________________
DOLFIN-dev mailing list
[email protected]
http://www.fenics.org/mailman/listinfo/dolfin-dev
