On Jun 27, 2009, at 12:02 AM, Dag Sverre Seljebotn wrote:
> Stefan Behnel wrote:
>> Hi,
>>
>> Dag Sverre Seljebotn wrote:
>>> Danilo Freitas wrote:
>>>> For my GSoC work with C++ Support, I need to know if we'll use the
>>>> Python '__init__' special method or use C++ way, with the
>>>> constructor
>>>> with the same name of the class:
>>>>
>>>> class Foo
>>>> {
>>>> public:
>>>> Foo() { } //constructor
>>>> }
>>> Well, what is the syntax going to be for other operators? I.e. I
>>> would
>>> think you could have either
>>>
>>> cdef extern cppclass Foo: # or whatever
>>> Foo(int a, int b)
>>> Foo operator+(Foo other)
>>>
>>> or
>>>
>>> cdef extern cppclass Foo:
>>> def __init__(self, int a, int b)
>>> def Foo __add__(self, Foo other)
>>>
>>> or
>>>
>>> cdef extern cppclass Foo:
>>> cdef __init__(self, int a, int b)
>>> cdef Foo __add__(self, Foo other)
>>>
>>> but I wouldn't feel happy about a mixture of those.
You are right that operators and constructors are intimately
connected syntaxwise, and I agree we should do the same for both.
Constructors are more basic (you can't get far without those) but
operators are more nuanced, so they should be decided together.
>> +1 for XOR. Given that the semantics are not necessarily what one
>> would
>> expect from a Python __add__, and given that we need a way to support
>> overloaded signatures anyway, I'm +0.5 for a syntax that differs from
>> Python, such as the above "operator+". Developers who use this
>> feature must
>> be familiar with C++ syntax anyway, so keeping the declarations
>> close to
>> C++ is a plus (pun intended).
>
> I'm not so sure. This has already been discussed, but I'll recap.
>
> C++'s operator[] vary much from Python. There's no seperate setitem
> operator, instead you use the "getitem" operator and the general C++
> support for assigning to the result of a function call (i.e. in C++
> you
> can do a.foo(b) = c, so getitem is enough to support a[b] = c).
>
> Also there's the host of operators which can't really be invoked from
> Cython (at least easily/without magic methods to call them
> explicitly).
>
> Now, there are two approaches:
>
> A) Support the full C++ semantics. In order to get a working setitem,
> you also need to support at least operator= (non-trivial, but I assume
> it would actually be OK here...) and C++ references.
>
> This leads to C++ constructor syntax.
>
> B) Define operators in terms of "what C++ code is output". So, we have
> __setitem__ on C++ classes, and simply define it as "declaring the
> signature of the entire C++ stub a[b] = c".
>
> This approach leads to __init__, IMO.
>
> Note that B pushes the C++/Cython semantics gap to the point "before"
> the cppclass decl is written, i.e. the user has to do the mapping
> in his
> or her head. Approach A allows C++ syntax, but requires Cython to
> decide
> how to deal with C++ semantics in each case.
>
> I was a heavy supporter of B earlier but I'm a little bit less sure
> now.
I'm also leaning towards B. For one thing, it only takes one person
to write the pxd, and then many people go and read/use it. (Think of
the utility of numpy.pxd.) Lots of these people are probably more
fluent in Python than C++ (a natural bias--if it were the opposite,
they'd be more likely to write against the C++ library directly). It
also frees us from the constraint of having to understand and emulate
the C++ operators exactly. It avoids the complexities of dealing with
references and operator= before having anything up and useful. Also,
if we're ever going to support operator overloading on anything but C+
+ classes (e.g. user-defined structs, or fast pathways for cdef class
arithmetic--not saying we definitely should do that now but we might
one day (CEP 503)) it's nice to have a non-C++ notation. There are
advantages for C++ style operator declaration as well though.
This is one of the milestones for Danilo's GSoC midterm evaluation
(July 13) so preferably we can settle this sooner rather than later.
- Robert
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
