On Mar 27, 2010, at 8:13 AM, Haoyu Bai wrote:
> 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)
There's also Py3 scope binding rules for list comprehensions,
exception blocks, etc.
> 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.
That's an interesting idea, but how would one resolve
from cython import *
from X import *
?
Also cython.int != __builtin__.int is important. Perhaps this would
just be disallowed...
> 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?
We have an IRC channel, but I don't think it's usually very heavily
populated. Email works well for most people in the Cython community,
but of course everyone has individual preferences.
I think 1 & 2 above would make a great project, and be a very valuable
contribution. Under the same heading (depending on how things are
going timewise) there are numerous improvements non-Py3 improvements
one could make for pure mode as well.
- Robert
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev