dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Tue, Oct 21, 2008 at 10:03:32AM +0100, Garth N. Wells wrote:
> 
> 
> Anders Logg wrote:
> > On Mon, Oct 20, 2008 at 08:40:49AM +0200, Johan Hake wrote:
> >> On Sunday 19 October 2008 23:32:55 Martin Sandve Alnæs wrote:
> >>> 2008/10/19 Anders Logg <logg@xxxxxxxxx>:
> >>>> On Sun, Oct 19, 2008 at 09:04:17PM +0200, 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.
> >>>> ok.
> >>>>
> >>>>> 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 don't mind longer function names now that we don't use camelCaps
> >>>> anymore... :-)
> >>>>
> >>>> I'll wait for Martin's opinion.
> >>>>
> >>> As Johan said, "a in b" or equivalently b.__contains__(a) is usually
> >>> taken to mean "a is an item in the container b". If type(b) is a
> >>> container type, it would be essential for __contains__ to have this
> >>> meaning, as it is a part of the "mapping protocol".
> >>>
> >>> However, since FunctionSpace is not a container type, overloading
> >>> FunctionSpace.__contains__(self, f) to mean "f in self" shouldn't pose
> >>> any problems that I see. There may exist python code in the world at
> >>> large that assumes an implementation of __contains__ means a container
> >>> type, but we don't need to interact with that code anyway.
> >>>
> >>> So I think we can safely e.g. rename "Function::in" to
> >>> "Function::in_space" in the swig interface, and then extend
> >>> FunctionSpace with an implementation of __contains__ like this:
> >>>
> >>>     def __contains__(self, f):
> >>>         return f.in_space(self)
> >> Sounds resonable. 
> >>
> >> Should I wait to send a patch for this untill we have renamed NewFunction to 
> >> Function? We need to change the python interface of Function any way when we 
> >> do the switch.
> >>
> >> Johan
> > 
> > Sounds good.
> >
> 
> Are we ready to rename NewFunction -> Function?
> 
> Garth

Yes, it will break everything but now is a good time.

If you want to start, just tell me when you are done / want to give up
and I can have a go... :-)

In addition to renaming, we need to

  1. Add a new class ConstantFunction inheriting from Function

  2. Make adjustments for minor interface changes (if any) in
  Assembler etc

  3. Make adjustments for major interface changes in all demos
  where now a FunctionSpace must be used

  4. Lots of work on Python interface to get wrapping in place
  and clean up some old hacks

-- 
Anders

Attachment: signature.asc
Description: Digital signature