Robert Bradshaw wrote:
> On Jun 27, 2009, at 12:02 AM, Dag Sverre Seljebotn wrote:
>> 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.
We already did a lot of discussion on this; I'm rather confident that
you know all the issues involved by now. As far as I'm concerned you two
(Danilo & Robert) can just make a decision.
That said, I believe I still have something to contribute here though,
which follows. But it is going rather deep into operators and not being
focused on constructors (can't be helped). And if you think it is taking
the discussion off the path then you certainly don't need to compose a
detailed answer, see above.
EXAMPLE:
Looking at operator++ (e.g. the need to do it++ on some STL iterators)
here are the options I see:
i) Take A from above, and introduce cython.inc. So declare as operator++
and use as cython.inc(it).
ii) Take B from above, and introduce cython.inc. One then needs to
invent __inc__, which is not in Python, for this purpose.
iii) What was originally my proposal, which is to somehow do
cdef cppclass MyIterator:
def next(self):
# somehow manage to express that you want ++
# invoked on self. My proposal was just arbitrary inline
# cpp code, which would thus allow mapping ANY kind of wierd
# C++ semantics into Cython semantics, through defining custom
# methods. And I actually consider the feature much neater than
# all the current hacks that's going on --
# let's make hacking easy! So:
cython.c("++self")
Note: For i) and ii), += 1 can be made a synonym from cython.inc; that
is quite besides the point though.
DISCUSSION:
The problem I have with B, as I think you think of it, is that it seems
to limit what you are able to do with C++ libraries, since only a
"Cython subset" is available.
With an ability to define new, arbitrary, Cython-specific methods with
inline C++ code though, one ensures that one can always make a map from
C++ to Cython semantics.
But without such an ability, I'm tempted to prefer A instead; which at
least would make it easier to, eventually, bring the full set of C++
semantics into Cython (without inventing wierd things like __inc__).
It's just the idea of being able to wrap "C++ libraries if they are not
too strange" I have some issues with.
--
Dag Sverre
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
