On Sep 26, 2008, at 9:55 AM, Dag Sverre Seljebotn wrote: > 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.
Some preliminary support for this is up at http://hg.cython.org/ cython-devel/rev/cfc5c05e0292 and http://hg.cython.org/cython-devel/ rev/c9f3badef047 . There's *lots* of room for improvement (e.g. no support for the p*_int notation, etc) but that should be fairly easy once the framework is in place. One can now do import cython @cython.locals(s=cython.double, i=int, n=int) def harmonic_sum(n): s = 0 for i in range(1, n+1): s += 1.0 / i return s and it will work in Python or Cython (there's a new "shadow" module). One can also do @cython.locals(ptr="void*") def my_id(x): ptr = cython.cast("void*", x) return cython.cast(long, ptr) though of course that won't work in Python. This does not handle def - > c[p]def. Until we have auto-generation of .pxd files, this is probably easiest to handle by letting the declarations in the .pxd file "mutate" the def nodes in the .py file into the right thing. - Robert _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
