Ondrej wrote:
> On Fri, Sep 26, 2008 at 4:43 PM, Dag Sverre Seljebotn
> <[EMAIL PROTECTED]> wrote:
>> I can write more later when I'm not on my phone, but: I'd suggest
>> starting with implementing
>>
>> @cython.earlybind
>> def f(x, y): ...
>>
>> and have it turn to
>>
>> cpdef f(x, y): ...
>>
>> (note on the name below)
>>
>> Just getting this working, with arguments and result typed to "object",
>> should get your feet wet. Then I suppose the next step is implementing
>> the Py3 PEP supporting decorators on arguments and return type. (I think
>> one should aim for Py2.6+ here, though I suppose arguments to the
>> decorator could work too: @cython.earlybind(x=cython.uint,
>> localvar=cython.float)...opinions?
>
> I need it to be working with python2.4+, so I'll choose something that
> works in python2.4. Debian just switched to python2.5 recently, so
> it's a long, long way before python2.6 could become a de facto
> standard. But generally I agree one should design this so that things
> are especially easy in python2.6+.
(Writing this just so that you can look it up when you are ready for
types, ideally when declaring cpdef without any non-object types works
already).
We've had long discussions about options for this earlier and it is
something people care strongly about, so please check with the mailing
list before fixing too hard on a given syntax.
Until something else is proposed then I'm +1 on my following proposal (but
at least Stefan or Robert should +1 it before it has any kind of official
status):
@cython.earlybind(cython.uint, x=cython.uint, v=cython.float)
def f(x):
v = x
return x
The first positional argument is the return type, while any keyword
arguments are for either arguments or local variables. Support for the
Py2.6+ syntax can be added in addition later.
We had a discussion already about the type names, I think we agreed on
something like (though others should comment too):
- cython.uint, cython.int, cython.float, cython.longdouble, etc.
- cython.p_uint for unsigned*. Up to three pointers provided like this:
cython.ppp_uint is unsigned***. (Hmm, in fact, as this is likely parsed as
a string and not declared anywhere, one can make the number of p-s
arbitrary).
- For people preferring verbosity: cython.ptr(cython.uint), with nesting
of ptr as many times as one like. Finally, cython.ptr(cython.uint,
levels=4) for unsigned****...
- Pointers to functions provided in a similar fashion, i.e.
cython.func_ptr(cython.int, cython.float) etc.
Notes you can look at again when you get as far (I enjoy thinking about
how to do stuff, coding it is the boring part :-) of course, if you do
things in your own way instead there's no harm to it though):
1) This is already parseable by Parsing.py, so you should be able to
implement this purely by staying in the transform I wrote about and output
type nodes in the appropriate places.
2) It would work by having the transform simply inserting "cdef unsigned
int v" statements (i.e. CVarDeclNode) at the beginning of the function
body, or changing info in the argument list of the function (anything in
the argument list goes there, the rest is inserted at beginning of
function without checking whether it is used).
3) As cpdef functions cannot take pointer arguments, one should generate
cdef functions instead when there are pointer arguments. IMO this should
be automagic, i.e. cpdef is selected whenever the arguments are coercable
from objects and cdef otherwise. (An alternative I would like better,
though, is to have cpdef functions taking pointer arguments be allowed in
the language, but lead to a "def" version containing a stub raising a
run-time error! This way things could be more consistent with good error
reporting. Long term, ctypes pointers could be coercable to Cython
pointers too.)
>> 2) The ResolveDirectives transform (or something like that) already has
>> code in it to intercept @cython.X-decorators on functions for compiler
>> directives, I think you want to extend that transform, in time changing
>> the name appropriately to give it a wider scope.
Having thought about this, the transform should be renamed and
redocumented to "Handle the parts of the cython scope that are not normal
run-time functions, i.e. any 'magic' functions and decorators in the
cython cimportable module." Something like CythonScopeTransform perhaps.
Dag Sverre
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
