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

Reply via email to