[Cython] buffer bug
Hey, I'm unable to login in trac, but I found a bug in the buffer support: cimport cython cimport numpy as np @cython.boundscheck(False) @cython.wraparound(False) cdef void func(np.ndarray[np.float32_t, ndim=2] a) nogil: pass This calls __Pyx_GetBufferAndValidate, which needs the GIL. When I get the last failing tests fixed (introduced after rebasing on the latest master) for memoryviews, should be transform the current buffer support to memoryviews before doing a release? The only incompatibility I see is that readonly buffers are not supported. On the other hand it might be a good idea to wait with that, in case there are any bugs. We don't want to break everyone's existing code. Opinions? Mark ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] buffer bug
On 10/02/2011 12:38 PM, mark florisson wrote: Hey, I'm unable to login in trac, but I found a bug in the buffer support: cimport cython cimport numpy as np @cython.boundscheck(False) @cython.wraparound(False) cdef void func(np.ndarray[np.float32_t, ndim=2] a) nogil: pass This calls __Pyx_GetBufferAndValidate, which needs the GIL. Hmm. I thought buffers were disallowed as arguments to cdef functions? When I get the last failing tests fixed (introduced after rebasing on the latest master) for memoryviews, should be transform the current buffer support to memoryviews before doing a release? The only incompatibility I see is that readonly buffers are not supported. Do you mean readonly memoryviews? I'm not sure how much of an issue it is. NumPy arrays support being readonly, but it is not straightforward to make a NumPy array so. Eventually I guess "const int[:]" should be supported; one could do so even without allowing const anywhere else. On the other hand it might be a good idea to wait with that, in case there are any bugs. We don't want to break everyone's existing code. Opinions? I think this is mostly a question of how much time you have to work on it. Transforming buffer support into memoryviews would be a new feature branch, and whether that branch is merged into next release depends on the timing for the next release I'd say. I don't think a new release has to happen in the meantime, if you want to make it before, all the better! Dag Sverre ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] buffer bug
On 2 October 2011 12:04, Dag Sverre Seljebotn wrote: > On 10/02/2011 12:38 PM, mark florisson wrote: >> >> Hey, >> >> I'm unable to login in trac, but I found a bug in the buffer support: >> >> cimport cython >> cimport numpy as np >> >> @cython.boundscheck(False) >> @cython.wraparound(False) >> cdef void func(np.ndarray[np.float32_t, ndim=2] a) nogil: >> pass >> >> This calls __Pyx_GetBufferAndValidate, which needs the GIL. > > Hmm. I thought buffers were disallowed as arguments to cdef functions? Ah, perhaps they are, but I didn't get any error message. >> When I get the last failing tests fixed (introduced after rebasing on >> the latest master) for memoryviews, should be transform the current >> buffer support to memoryviews before doing a release? The only >> incompatibility I see is that readonly buffers are not supported. > > Do you mean readonly memoryviews? > > I'm not sure how much of an issue it is. NumPy arrays support being > readonly, but it is not straightforward to make a NumPy array so. > > Eventually I guess "const int[:]" should be supported; one could do so even > without allowing const anywhere else. Right, readonly memoryviews, I think the current buffer support supports not asking for a buffer with PyBUF_WRITABLE (when there is no item assignment in that function). Memoryviews cannot make the same assumption because they can be passed anywhere without requesting a new buffer, so they always insert PyBUF_WRITABLE in the flags when requesting the buffer. >> On the other hand it might be a good idea to wait with that, in case >> there are any bugs. We don't want to break everyone's existing code. >> Opinions? > > I think this is mostly a question of how much time you have to work on it. > Transforming buffer support into memoryviews would be a new feature branch, > and whether that branch is merged into next release depends on the timing > for the next release I'd say. I don't think a new release has to happen in > the meantime, if you want to make it before, all the better! > > Dag Sverre > ___ > cython-devel mailing list > cython-devel@python.org > http://mail.python.org/mailman/listinfo/cython-devel > Ok, sounds good. Let's see what happens, I'm probably going to be quite busy, but the weather forecast also mentioned rain... :) ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] CyFunction refactoring plan
2011/9/30 mark florisson : > On 30 September 2011 07:47, Vitja Makarov wrote: >> 2011/9/30 Vitja Makarov : >>> 2011/9/30 Robert Bradshaw : On Thu, Sep 29, 2011 at 10:43 PM, Stefan Behnel wrote: > Vitja Makarov, 30.09.2011 06:41: >> >> 2011/9/28 Vitja Makarov: >>> >>> I tried to build simple plan for ongoing cython function refactoring >>> >>> * Replace assignment synthesis with SingleAssignmentNode, where LHS is >>> NameNode and RHS is PyCFunctionNode >>> * Split function body into python wrapper and C function >>> http://wiki.cython.org/enhancements/generators#Pythonfunctionrefactoring >>> >>> Then we can implement some features and optimizations: >>> >>> * Reduce difference between cdef and def functions >>> * Store runtime evaluated default values inside CyFunction, ticket #674 >>> * Implement no-args super(), ticket #696 >>> * Function call inlining >> >> If nobody don't mind I would start with first one. I would love to see this happen. > Please go ahead. :) > > Note that you will encounter some problems when enabling name assignments > for all named functions. I tried that at least once and it "didn't work", > but I didn't take the time yet to investigate them further. > > I assume you are going to work on this in your own repo? Please also coordinate with Mark's work on function dispatching for fused types. >>> >>> I assume that that fused type functions are cdef ones so I think that >>> should be easy to merge. >>> On the other hand it's better to have Mark's branch merged into master. >>> >>> Mark, what is the state of your fused types branch? >>> Is it possible to break it into smaller parts to ease reviewing and merging? >>> >> >> It seems I meant memview branch not fusedtypes. > > There are 2 pending branches, _memview_rebase, which has support for > memoryviews, and fusedtypes. The former is ready for merge, it's > waiting to be reviewed. The fused types branch needs to subclass > CyFunction (it basically modified the old binding function). There was > also some duplicate functionality there, so I thought it'd be easier > and more convenient to use the utility code loading there. > > Since it's not a strict dependency and it will be blocking progress, I > will try to find some time to get it merge-ready for master. > > But no, it does cdef, cpdef and def methods, and it has some changes > to all function nodes (FuncdefNode, CFuncdefNode and DefNode). These > changes shouldn't be major though, but the logic in FusedFuncdefNode > does differentiate between all the different functions in order to > support them. Feel free to ask me about specifics any time. > I've moved def node assignment synthesis into DefNodeAssignmentSynthesis transformation. https://github.com/vitek/cython/commit/efacfed3c9cd8216b6c2100073a9df809b76675a Instead of moving defnode into PyCFunctionNode I've inserted assignment statement right after defnode. This is much more easy and seems ok to me. -- vitja. ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] CyFunction refactoring plan
On 2 October 2011 18:52, Vitja Makarov wrote: > 2011/9/30 mark florisson : >> On 30 September 2011 07:47, Vitja Makarov wrote: >>> 2011/9/30 Vitja Makarov : 2011/9/30 Robert Bradshaw : > On Thu, Sep 29, 2011 at 10:43 PM, Stefan Behnel > wrote: >> Vitja Makarov, 30.09.2011 06:41: >>> >>> 2011/9/28 Vitja Makarov: I tried to build simple plan for ongoing cython function refactoring * Replace assignment synthesis with SingleAssignmentNode, where LHS is NameNode and RHS is PyCFunctionNode * Split function body into python wrapper and C function http://wiki.cython.org/enhancements/generators#Pythonfunctionrefactoring Then we can implement some features and optimizations: * Reduce difference between cdef and def functions * Store runtime evaluated default values inside CyFunction, ticket #674 * Implement no-args super(), ticket #696 * Function call inlining >>> >>> If nobody don't mind I would start with first one. > > I would love to see this happen. > >> Please go ahead. :) >> >> Note that you will encounter some problems when enabling name assignments >> for all named functions. I tried that at least once and it "didn't work", >> but I didn't take the time yet to investigate them further. >> >> I assume you are going to work on this in your own repo? > > Please also coordinate with Mark's work on function dispatching for > fused types. > I assume that that fused type functions are cdef ones so I think that should be easy to merge. On the other hand it's better to have Mark's branch merged into master. Mark, what is the state of your fused types branch? Is it possible to break it into smaller parts to ease reviewing and merging? >>> >>> It seems I meant memview branch not fusedtypes. >> >> There are 2 pending branches, _memview_rebase, which has support for >> memoryviews, and fusedtypes. The former is ready for merge, it's >> waiting to be reviewed. The fused types branch needs to subclass >> CyFunction (it basically modified the old binding function). There was >> also some duplicate functionality there, so I thought it'd be easier >> and more convenient to use the utility code loading there. >> >> Since it's not a strict dependency and it will be blocking progress, I >> will try to find some time to get it merge-ready for master. >> >> But no, it does cdef, cpdef and def methods, and it has some changes >> to all function nodes (FuncdefNode, CFuncdefNode and DefNode). These >> changes shouldn't be major though, but the logic in FusedFuncdefNode >> does differentiate between all the different functions in order to >> support them. Feel free to ask me about specifics any time. >> > > I've moved def node assignment synthesis into > DefNodeAssignmentSynthesis transformation. > > https://github.com/vitek/cython/commit/efacfed3c9cd8216b6c2100073a9df809b76675a > > Instead of moving defnode into PyCFunctionNode I've inserted > assignment statement right after defnode. > This is much more easy and seems ok to me. > > -- > vitja. > ___ > cython-devel mailing list > cython-devel@python.org > http://mail.python.org/mailman/listinfo/cython-devel > Ah, I thought you were going to wait until fused types were merged. In any case, this doesn't look like it will give too many conflicts, but there will be a few. I'm currently moving CyFunction to a utility code file and making a FusedFunction subclass. ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] CyFunction refactoring plan
2011/10/2 mark florisson : > On 2 October 2011 18:52, Vitja Makarov wrote: >> 2011/9/30 mark florisson : >>> On 30 September 2011 07:47, Vitja Makarov wrote: 2011/9/30 Vitja Makarov : > 2011/9/30 Robert Bradshaw : >> On Thu, Sep 29, 2011 at 10:43 PM, Stefan Behnel >> wrote: >>> Vitja Makarov, 30.09.2011 06:41: 2011/9/28 Vitja Makarov: > > I tried to build simple plan for ongoing cython function refactoring > > * Replace assignment synthesis with SingleAssignmentNode, where LHS is > NameNode and RHS is PyCFunctionNode > * Split function body into python wrapper and C function > http://wiki.cython.org/enhancements/generators#Pythonfunctionrefactoring > > Then we can implement some features and optimizations: > > * Reduce difference between cdef and def functions > * Store runtime evaluated default values inside CyFunction, ticket > #674 > * Implement no-args super(), ticket #696 > * Function call inlining If nobody don't mind I would start with first one. >> >> I would love to see this happen. >> >>> Please go ahead. :) >>> >>> Note that you will encounter some problems when enabling name >>> assignments >>> for all named functions. I tried that at least once and it "didn't >>> work", >>> but I didn't take the time yet to investigate them further. >>> >>> I assume you are going to work on this in your own repo? >> >> Please also coordinate with Mark's work on function dispatching for >> fused types. >> > > I assume that that fused type functions are cdef ones so I think that > should be easy to merge. > On the other hand it's better to have Mark's branch merged into master. > > Mark, what is the state of your fused types branch? > Is it possible to break it into smaller parts to ease reviewing and > merging? > It seems I meant memview branch not fusedtypes. >>> >>> There are 2 pending branches, _memview_rebase, which has support for >>> memoryviews, and fusedtypes. The former is ready for merge, it's >>> waiting to be reviewed. The fused types branch needs to subclass >>> CyFunction (it basically modified the old binding function). There was >>> also some duplicate functionality there, so I thought it'd be easier >>> and more convenient to use the utility code loading there. >>> >>> Since it's not a strict dependency and it will be blocking progress, I >>> will try to find some time to get it merge-ready for master. >>> >>> But no, it does cdef, cpdef and def methods, and it has some changes >>> to all function nodes (FuncdefNode, CFuncdefNode and DefNode). These >>> changes shouldn't be major though, but the logic in FusedFuncdefNode >>> does differentiate between all the different functions in order to >>> support them. Feel free to ask me about specifics any time. >>> >> >> I've moved def node assignment synthesis into >> DefNodeAssignmentSynthesis transformation. >> >> https://github.com/vitek/cython/commit/efacfed3c9cd8216b6c2100073a9df809b76675a >> >> Instead of moving defnode into PyCFunctionNode I've inserted >> assignment statement right after defnode. >> This is much more easy and seems ok to me. >> >> -- >> vitja. >> ___ >> cython-devel mailing list >> cython-devel@python.org >> http://mail.python.org/mailman/listinfo/cython-devel >> > > Ah, I thought you were going to wait until fused types were merged. In > any case, this doesn't look like it will give too many conflicts, but > there will be a few. Yeah, I just had a free time and decided to try. I think fused types should be merged first. > I'm currently moving CyFunction to a utility code > file and making a FusedFunction subclass. > That's cool! Btw, have you seen utility code related bug in hudson it happens only with py2.4? -- vitja. ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] CyFunction refactoring plan
On 2 October 2011 19:44, Vitja Makarov wrote: > 2011/10/2 mark florisson : >> On 2 October 2011 18:52, Vitja Makarov wrote: >>> 2011/9/30 mark florisson : On 30 September 2011 07:47, Vitja Makarov wrote: > 2011/9/30 Vitja Makarov : >> 2011/9/30 Robert Bradshaw : >>> On Thu, Sep 29, 2011 at 10:43 PM, Stefan Behnel >>> wrote: Vitja Makarov, 30.09.2011 06:41: > > 2011/9/28 Vitja Makarov: >> >> I tried to build simple plan for ongoing cython function refactoring >> >> * Replace assignment synthesis with SingleAssignmentNode, where LHS >> is >> NameNode and RHS is PyCFunctionNode >> * Split function body into python wrapper and C function >> http://wiki.cython.org/enhancements/generators#Pythonfunctionrefactoring >> >> Then we can implement some features and optimizations: >> >> * Reduce difference between cdef and def functions >> * Store runtime evaluated default values inside CyFunction, ticket >> #674 >> * Implement no-args super(), ticket #696 >> * Function call inlining > > If nobody don't mind I would start with first one. >>> >>> I would love to see this happen. >>> Please go ahead. :) Note that you will encounter some problems when enabling name assignments for all named functions. I tried that at least once and it "didn't work", but I didn't take the time yet to investigate them further. I assume you are going to work on this in your own repo? >>> >>> Please also coordinate with Mark's work on function dispatching for >>> fused types. >>> >> >> I assume that that fused type functions are cdef ones so I think that >> should be easy to merge. >> On the other hand it's better to have Mark's branch merged into master. >> >> Mark, what is the state of your fused types branch? >> Is it possible to break it into smaller parts to ease reviewing and >> merging? >> > > It seems I meant memview branch not fusedtypes. There are 2 pending branches, _memview_rebase, which has support for memoryviews, and fusedtypes. The former is ready for merge, it's waiting to be reviewed. The fused types branch needs to subclass CyFunction (it basically modified the old binding function). There was also some duplicate functionality there, so I thought it'd be easier and more convenient to use the utility code loading there. Since it's not a strict dependency and it will be blocking progress, I will try to find some time to get it merge-ready for master. But no, it does cdef, cpdef and def methods, and it has some changes to all function nodes (FuncdefNode, CFuncdefNode and DefNode). These changes shouldn't be major though, but the logic in FusedFuncdefNode does differentiate between all the different functions in order to support them. Feel free to ask me about specifics any time. >>> >>> I've moved def node assignment synthesis into >>> DefNodeAssignmentSynthesis transformation. >>> >>> https://github.com/vitek/cython/commit/efacfed3c9cd8216b6c2100073a9df809b76675a >>> >>> Instead of moving defnode into PyCFunctionNode I've inserted >>> assignment statement right after defnode. >>> This is much more easy and seems ok to me. >>> >>> -- >>> vitja. >>> ___ >>> cython-devel mailing list >>> cython-devel@python.org >>> http://mail.python.org/mailman/listinfo/cython-devel >>> >> >> Ah, I thought you were going to wait until fused types were merged. In >> any case, this doesn't look like it will give too many conflicts, but >> there will be a few. > > Yeah, I just had a free time and decided to try. I think fused types > should be merged first. > >> I'm currently moving CyFunction to a utility code >> file and making a FusedFunction subclass. >> > > That's cool! Btw, have you seen utility code related bug in hudson it > happens only with py2.4? Yeah I'll fix that, thanks for pointing it out, I don't have a 2.4 build myself. I think it's not eating unicode keys for keyword arguments. > -- > vitja. > ___ > cython-devel mailing list > cython-devel@python.org > http://mail.python.org/mailman/listinfo/cython-devel > ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] CyFunction refactoring plan
On 2 October 2011 19:44, Vitja Makarov wrote: > 2011/10/2 mark florisson : >> On 2 October 2011 18:52, Vitja Makarov wrote: >>> 2011/9/30 mark florisson : On 30 September 2011 07:47, Vitja Makarov wrote: > 2011/9/30 Vitja Makarov : >> 2011/9/30 Robert Bradshaw : >>> On Thu, Sep 29, 2011 at 10:43 PM, Stefan Behnel >>> wrote: Vitja Makarov, 30.09.2011 06:41: > > 2011/9/28 Vitja Makarov: >> >> I tried to build simple plan for ongoing cython function refactoring >> >> * Replace assignment synthesis with SingleAssignmentNode, where LHS >> is >> NameNode and RHS is PyCFunctionNode >> * Split function body into python wrapper and C function >> http://wiki.cython.org/enhancements/generators#Pythonfunctionrefactoring >> >> Then we can implement some features and optimizations: >> >> * Reduce difference between cdef and def functions >> * Store runtime evaluated default values inside CyFunction, ticket >> #674 >> * Implement no-args super(), ticket #696 >> * Function call inlining > > If nobody don't mind I would start with first one. >>> >>> I would love to see this happen. >>> Please go ahead. :) Note that you will encounter some problems when enabling name assignments for all named functions. I tried that at least once and it "didn't work", but I didn't take the time yet to investigate them further. I assume you are going to work on this in your own repo? >>> >>> Please also coordinate with Mark's work on function dispatching for >>> fused types. >>> >> >> I assume that that fused type functions are cdef ones so I think that >> should be easy to merge. >> On the other hand it's better to have Mark's branch merged into master. >> >> Mark, what is the state of your fused types branch? >> Is it possible to break it into smaller parts to ease reviewing and >> merging? >> > > It seems I meant memview branch not fusedtypes. There are 2 pending branches, _memview_rebase, which has support for memoryviews, and fusedtypes. The former is ready for merge, it's waiting to be reviewed. The fused types branch needs to subclass CyFunction (it basically modified the old binding function). There was also some duplicate functionality there, so I thought it'd be easier and more convenient to use the utility code loading there. Since it's not a strict dependency and it will be blocking progress, I will try to find some time to get it merge-ready for master. But no, it does cdef, cpdef and def methods, and it has some changes to all function nodes (FuncdefNode, CFuncdefNode and DefNode). These changes shouldn't be major though, but the logic in FusedFuncdefNode does differentiate between all the different functions in order to support them. Feel free to ask me about specifics any time. >>> >>> I've moved def node assignment synthesis into >>> DefNodeAssignmentSynthesis transformation. >>> >>> https://github.com/vitek/cython/commit/efacfed3c9cd8216b6c2100073a9df809b76675a >>> >>> Instead of moving defnode into PyCFunctionNode I've inserted >>> assignment statement right after defnode. >>> This is much more easy and seems ok to me. >>> >>> -- >>> vitja. >>> ___ >>> cython-devel mailing list >>> cython-devel@python.org >>> http://mail.python.org/mailman/listinfo/cython-devel >>> >> >> Ah, I thought you were going to wait until fused types were merged. In >> any case, this doesn't look like it will give too many conflicts, but >> there will be a few. > > Yeah, I just had a free time and decided to try. I think fused types > should be merged first. If you want you can rebase your branch on https://github.com/markflorisson88/cython/tree/fusedmerge, I'm not going to rebase that branch. It needs a few more fixes though. >> I'm currently moving CyFunction to a utility code >> file and making a FusedFunction subclass. >> > > That's cool! Btw, have you seen utility code related bug in hudson it > happens only with py2.4? > > -- > vitja. > ___ > cython-devel mailing list > cython-devel@python.org > http://mail.python.org/mailman/listinfo/cython-devel > ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] CyFunction refactoring plan
2011/10/3 mark florisson : > On 2 October 2011 19:44, Vitja Makarov wrote: >> 2011/10/2 mark florisson : >>> On 2 October 2011 18:52, Vitja Makarov wrote: 2011/9/30 mark florisson : > On 30 September 2011 07:47, Vitja Makarov wrote: >> 2011/9/30 Vitja Makarov : >>> 2011/9/30 Robert Bradshaw : On Thu, Sep 29, 2011 at 10:43 PM, Stefan Behnel wrote: > Vitja Makarov, 30.09.2011 06:41: >> >> 2011/9/28 Vitja Makarov: >>> >>> I tried to build simple plan for ongoing cython function refactoring >>> >>> * Replace assignment synthesis with SingleAssignmentNode, where LHS >>> is >>> NameNode and RHS is PyCFunctionNode >>> * Split function body into python wrapper and C function >>> http://wiki.cython.org/enhancements/generators#Pythonfunctionrefactoring >>> >>> Then we can implement some features and optimizations: >>> >>> * Reduce difference between cdef and def functions >>> * Store runtime evaluated default values inside CyFunction, ticket >>> #674 >>> * Implement no-args super(), ticket #696 >>> * Function call inlining >> >> If nobody don't mind I would start with first one. I would love to see this happen. > Please go ahead. :) > > Note that you will encounter some problems when enabling name > assignments > for all named functions. I tried that at least once and it "didn't > work", > but I didn't take the time yet to investigate them further. > > I assume you are going to work on this in your own repo? Please also coordinate with Mark's work on function dispatching for fused types. >>> >>> I assume that that fused type functions are cdef ones so I think that >>> should be easy to merge. >>> On the other hand it's better to have Mark's branch merged into master. >>> >>> Mark, what is the state of your fused types branch? >>> Is it possible to break it into smaller parts to ease reviewing and >>> merging? >>> >> >> It seems I meant memview branch not fusedtypes. > > There are 2 pending branches, _memview_rebase, which has support for > memoryviews, and fusedtypes. The former is ready for merge, it's > waiting to be reviewed. The fused types branch needs to subclass > CyFunction (it basically modified the old binding function). There was > also some duplicate functionality there, so I thought it'd be easier > and more convenient to use the utility code loading there. > > Since it's not a strict dependency and it will be blocking progress, I > will try to find some time to get it merge-ready for master. > > But no, it does cdef, cpdef and def methods, and it has some changes > to all function nodes (FuncdefNode, CFuncdefNode and DefNode). These > changes shouldn't be major though, but the logic in FusedFuncdefNode > does differentiate between all the different functions in order to > support them. Feel free to ask me about specifics any time. > I've moved def node assignment synthesis into DefNodeAssignmentSynthesis transformation. https://github.com/vitek/cython/commit/efacfed3c9cd8216b6c2100073a9df809b76675a Instead of moving defnode into PyCFunctionNode I've inserted assignment statement right after defnode. This is much more easy and seems ok to me. -- vitja. ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel >>> >>> Ah, I thought you were going to wait until fused types were merged. In >>> any case, this doesn't look like it will give too many conflicts, but >>> there will be a few. >> >> Yeah, I just had a free time and decided to try. I think fused types >> should be merged first. > > If you want you can rebase your branch on > https://github.com/markflorisson88/cython/tree/fusedmerge, I'm not > going to rebase that branch. It needs a few more fixes though. > Ok. I'll try tomorrow. -- vitja. ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
