On Tue, Mar 23, 2010 at 3:07 AM, Craig Citro <[email protected]> wrote:
>> Thanks for your advice, Dag. Your suggestion about Python 3 support
>> also lead to an interesting idea. That is, to make use of the Python 3
>> function annotation syntax to have a more convenient pure Python mode
>> in Cython.
>>
>
> I really like this idea -- I just ran into PEP 3107 (function
> annotations) for the first time recently, and I was thinking exactly
> the same thing. I'd definitely be interested in mentoring a project on
> this front, and the Py3 angle probably gives us a good shot at getting
> accepted by PSF.
>
> -cc
Thanks for all the encouragements and suggestions. I have go through
the relevant PEPs, CEPs, Cython issue tracker in these days. To
getting familiar with Cython codebase, I even made a small patch for
ticket #399 (but seems there is no way to submit it on trac?).
As Stefan suggested, annotation support alone may not sufficient for a
GSoC project. So I have go through the issue tracker to find other
related things that could be included in a py3k project. So far, the
works could fall into 4 groups: 1) Minor tickets related to Py3; 2)
Pure Python mode with Py3 features; 3) m_clear() and per interpreter
support; 4) Buffer related tickets. However, to include all of them
may exceed the workload of GSoC, so maybe pick 2 or 3 of them is ok.
Below is some details of the 4 groups.
1. Minor tickets related to Py3
This includes:
* 'cython3' command directives for py3
* Exception chaining (#423)
* Emulate Py3 print() for python <2.6 (#69)
* Support 'nonlocal' (#490)
* 'with' with multiple managers (#487)
* future division not respected by C int (#259)
(However, I cannot reproduce this, any detail about this?)
* support for Ellipsis ('...') (#488)
2. Pure Python mode with py3 features
I agree that we need to support tuple as annotation for a convention
to be compatible with others. Besides function annotation, I'm also
thinking to make use of decorators. As decorators now supported for
classes, we could have @cdef @cpdef as decorator. This is a possible
solution for get rid of .pxd files (ticket #112). A demo:
import cython
@cython.cdef
class Foo:
@cython.cdef
def bar(self, x: cython.int) -> cython.p_char:
...
Also, one could always use "from cython import *" to make the code more concise.
3. m_clear() and per interpreter state
I tried to investigate this. However, even Python built-in modules are
not implemented these, so maybe there's no example about how this
could be done yet.
So at first we should have test cases to demonstrate the problem, eg.
memory leak after Py_Finalize(), or module states shared between
interpreter instances. Then, Cython may need a proper resource
management framework - we need to know where an object is allocated
to, and when we should release it.
If we are interested in doing this, I'll investigate more.
4. Buffer related tickets
The new buffer protocol is also related to Py3, and there are many
tickets about it. Is there already someone working on these, or I
could also take these as part of GSoC work?
I think a combination of 1,2,3 or 1,2,4 could be a well enough GSoC
project. To me, 4. is more doable than 3., and of course, 2. is the
most interesting part. Any suggestion?
Craig, if you are interested to mentor, how could I contact you? Is
there a Cython IRC channel, or an IRC channel you guys usually hanging
on?
Thank you!
--
Haoyu BAI
School of Computing,
National University of Singapore.
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
