If you have a couple of evenings I'm happy to help with pointers as it would be
a good investment of time.
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?
Brief scetch on the first step anyway (please ask about any hazy points and
I'll give better help when I'm at a computer):
1) The file you want to work in is ParseTreeTransforms.py. Your goal is to
intercept decorated DefNode-s and transform them into CFuncDefNodes. Have a
look and see how transforms are written...
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.
3) the general workflow is this: Create a small testcase with both "from" code
and "to" code as given above. Then add this function to ResolveDirectives (not
entirely sure about the node class name, see Nodes.py):
def visit_CFuncDefNode(self, node):
print node.dump()
return node
this gives you an idea about the node structure you must convert to.
5) To transform, edit the function visit_DefNode to also take into account
"earlybind" (hardcode it) before checking the decorator against directives, and
if so, simply set node = self.convert_def_to_cpdef(node), which you write.
"node.dump()" here gives you the from-tree.
6) if you fancy unit tests in addition to integration tests, have a look at
TestWithTransform.py (or similar) for how to do it. You should literally be
able to input the decorated def example above as a string and assert that the
result after the transform is the expected cpdef version... though you may need
to extend CodeWriter.py to serialize cpdef to strings.
Send an email whenever something is not obvious -- it would be really cool to
see this in Cython.
Note on names: It is easily changeable so it is not a big point...but here
goes: I think personally the cdef and cpdef are very cython-specific and
communicate badly with python users. Also, considering cpdef exists, I think
the need for cdef should be small? If wanted it could be called
"@cython.nativeonly" perhaps. Anyway, "earlybind" also gets in the important
message that you cannot reassign the symbol it binds to at runtime, which is a
difference with how you expect a "def" to work.
Dag Sverre Seljebotn
-----Original Message-----
From: "Ondrej Certik" <[EMAIL PROTECTED]>
Date: Friday, Sep 26, 2008 4:00 pm
Subject: Re: [Cython] Support .pxd files for plain Python source files?
To: "Robert Bradshaw" <[EMAIL PROTECTED]>
CC: [EMAIL PROTECTED]: [email protected]
On Wed, Aug 27, 2008 at 6:02 PM, Ondrej Certik <[EMAIL PROTECTED]> wrote:
> On Wed, Aug 27, 2008 at 5:51 PM, Robert Bradshaw
> <[EMAIL PROTECTED]> wrote:
>>
>> On Aug 27, 2008, at 3:54 AM, Dag Sverre Seljebotn wrote:
>>
>>> Stefan Behnel wrote:
>>>>
>>>> Stefan Behnel wrote:
>>>>>
>>>>> we've already discussed a couple of times how to provide type
>>>>> information
>>>>> for pure Python source code. It was generally agreed that it's difficult
>>>>> to do so inside of the function body and easier to do for function
>>>>> signatures if we use Py3 annotations. I don't remember any good ideas
>>>>> how
>>>>> to provide type information for classes, i.e. how to make them extension
>>>>> types.
>>>
>>> Someone must have mentioned this?:
>>>
>>> @cython.cdef
>>> class A:
>>> ...
>>>
>>> @cython.cdef
>>> def func(): ...
>>>
>>> Just mentioning it as a possibility.
>>
>> This is the way I was imagining doing it, especially as .pxd files move
>> towards being auto-generated. The proposal of being able to simply declare
>> them in the pxd file is an interesting one, and though it feels a bit sloppy
>> to me perhaps it would be good to support as well (curious for more input).
>
>> There also needs to by some syntax to define variables etc, but
> anything that allows me to use the full power of Cython yet stay in
> pure Python is fine with me.
>
>I am scarce on time, but I'd like to see this happen soon. How would you
>suggest me to modify Cython to support that? I can try to write
>some preparser, that takes pure python code (for example with
>decorators specifying types) and turn it into a regular .pyx file that Cython
>understands. But I am not sure if such a work would be helpful to you, I guess
>the ultimate solution would be to modify the Cython
>itself, but I am not sure how, without thorough studying of it, which I am not
>sure how much time (days?) will take.
>
>Those of you who know Cython well, if you have some ideas where I
>should start to help get this done, it'd be awesome. I can spend
>couple evenings on that.
>
>Ondrej
>_______________________________________________
>Cython-dev mailing list
>[email protected]
>http://codespeak.net/mailman/listinfo/cython-dev
>
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
