Ondrej Certik | 1 Apr 02:40 2010
Picon

Re: [Cython] LiE in Cython

On Tue, Mar 30, 2010 at 9:20 PM, David Simmons-Duffin
<dsimmons.com <at> gmail.com> wrote:
> Dear All,
>
> I've finally gotten around to posting the code for my cython wrapper for the computer algebra package LiE:
>
> http://github.com/davidsd/lie
>
> Basically, the project contains a copy of the LiE source, some extra C files, and a cython file (lie.pyx)
that references functions from LiE and defines extension classes and some more abstract python objects.
>
> It currently works well enough for what I made it for (http://arxiv.org/abs/0910.4585).  However,
there are many ways it could be improved.  Since I'm no longer striving towards a specific goal, and I have
other projects to work on, it's hard for me to prioritize one improvement over another.  So I'd be
grateful if those who are interested could take a look, let me know what improvements/features they think
are important, and perhaps help me work towards them.

I don't have time at the moment to figure out how to compile it on
linux, but looking at the readme and examples in there, it looks very
interesting. And your article too.

Ondrej
_______________________________________________
Cython-dev mailing list
Cython-dev <at> codespeak.net
http://codespeak.net/mailman/listinfo/cython-dev
Haoyu Bai | 2 Apr 07:53 2010
Picon

Re: [Cython] GSoC project for improving Python compatibility

On Wed, Mar 31, 2010 at 1:36 AM, Robert Bradshaw
<robertwb <at> math.washington.edu> wrote:
>
> There's also Py3 scope binding rules for list comprehensions,
> exception blocks, etc.
>

Thanks. I added these to my list.

>> 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  <at> cdef  <at> cpdef as decorator. This is a possible
>> solution for get rid of .pxd files (ticket #112). A demo:
>>
>> import cython
>>  <at> cython.cdef
>> class Foo:
>>     <at> 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 *
(Continue reading)

maximem | 2 Apr 16:05 2010

[Cython] Combination of decorator and cpdef with cython 0.13

Dear developer of cython,

First of all I thank you for all your work. Thanks to Cython and the
documentation and tutorial that you displayed on internet, I have
successfully managed to create a cython code approximately 250 times
quicker than with python and even 1.4times quicker than C.

In fact I created two cython codes corresponding to two python codes of
the same algorithm (one with a single function and one with several
classes and function).

I hesitated several minutes before posting in this list or in the user
list but since this is not simple cython problem but a problem with the
new version of cython, i have finally chosen to post here. I hope I made
the right choice.

I downloaded the version 0.13 of cython yesterday (I was previously using
the version 0.12.1) and two problems appeared when I used cython.

The first one is that it seems that we can no more combine cpdef and
decorator :

     <at> cython.boundscheck(False)
     <at> cython.wraparound(False)
    cpdef run(self,adjacencyMatrix_,nodesPosition_,int dimension,nbLink_):
   ^
------------------------------------------------------------

/homelocal/max/Memoire/Sources/CAttractionRepulsionAlgorithm.pyx:48:4:
Decorators can only be followed by functions
(Continue reading)

Dag Sverre Seljebotn | 2 Apr 17:30 2010
Picon
Picon

Re: [Cython] Combination of decorator and cpdef with cython 0.13

maximem@... wrote:
> Dear developer of cython,
>
> First of all I thank you for all your work. Thanks to Cython and the
> documentation and tutorial that you displayed on internet, I have
> successfully managed to create a cython code approximately 250 times
> quicker than with python and even 1.4times quicker than C.
>
> In fact I created two cython codes corresponding to two python codes of
> the same algorithm (one with a single function and one with several
> classes and function).
>
> I hesitated several minutes before posting in this list or in the user
> list but since this is not simple cython problem but a problem with the
> new version of cython, i have finally chosen to post here. I hope I made
> the right choice.
>
> I downloaded the version 0.13 of cython yesterday (I was previously using
> the version 0.12.1) and two problems appeared when I used cython.
>
> The first one is that it seems that we can no more combine cpdef and
> decorator :
>
>      <at> cython.boundscheck(False)
>      <at> cython.wraparound(False)
>     cpdef run(self,adjacencyMatrix_,nodesPosition_,int dimension,nbLink_):
>    ^
> ------------------------------------------------------------
>
> /homelocal/max/Memoire/Sources/CAttractionRepulsionAlgorithm.pyx:48:4:
(Continue reading)

maximem | 2 Apr 18:36 2010

Re: [Cython] Combination of decorator and cpdef with cython 0.13

> maximem@... wrote:
>> Dear developer of cython,
>>
>> First of all I thank you for all your work. Thanks to Cython and the
>> documentation and tutorial that you displayed on internet, I have
>> successfully managed to create a cython code approximately 250 times
>> quicker than with python and even 1.4times quicker than C.
>>
>> In fact I created two cython codes corresponding to two python codes of
>> the same algorithm (one with a single function and one with several
>> classes and function).
>>
>> I hesitated several minutes before posting in this list or in the user
>> list but since this is not simple cython problem but a problem with the
>> new version of cython, i have finally chosen to post here. I hope I made
>> the right choice.
>>
>> I downloaded the version 0.13 of cython yesterday (I was previously
>> using
>> the version 0.12.1) and two problems appeared when I used cython.
>>
>> The first one is that it seems that we can no more combine cpdef and
>> decorator :
>>
>>      <at> cython.boundscheck(False)
>>      <at> cython.wraparound(False)
>>     cpdef run(self,adjacencyMatrix_,nodesPosition_,int
>> dimension,nbLink_):
>>    ^
>> ------------------------------------------------------------
(Continue reading)

Jonas H. | 3 Apr 01:26 2010

[Cython] __dealloc__ with gil

I need to acquire the GIL for a `__dealloc__` method, but the Cython 
grammar does not allow this:

     cdef  __dealloc__ with gil:: "special methods must be `def`"
     def   __dealloc__ with gil:: Python syntax error (of course)
     cpdef __dealloc__ with gil:: see `cdef`

What is the right way to do this?

     Jonas
Stefan Behnel | 3 Apr 08:40 2010
Picon

Re: [Cython] __dealloc__ with gil

Hi,

note that this is a question for the cython-users mailing list.

Jonas H., 03.04.2010 01:26:
> I need to acquire the GIL for a `__dealloc__` method, but the Cython
> grammar does not allow this:
>
>       cdef  __dealloc__ with gil:: "special methods must be `def`"
>       def   __dealloc__ with gil:: Python syntax error (of course)
>       cpdef __dealloc__ with gil:: see `cdef`
>
> What is the right way to do this?

No need to do that. The __dealloc__ method is only called when the GIL is held.

Stefan
Haoyu Bai | 3 Apr 09:18 2010
Picon

[Cython] Compile-time decorator

Hi,

Thinking about how to implement Cython decorators ( <at> cclass,  <at> cfunc
etc.) for pure Python mode, I come up with an idea of "compile-time
decorator". Basically, we want these decorators to have effect during
compile time, rather than normal Python decorator that is called in
runtime. So, to implement  <at> cfunc, we can actually implement a function
cfunc(node), which inputs a DefNode and transform it to a
CFuncDefNode, then put the function into the compile-time scope.

Cython directives could also be dealt in this way. This may even
extend to a kind of plugin framework, which allows user to write their
compile-time decorator.

A problem is in which phase these decorators should be called. I guess
it should be somewhere between DecoratorTransform and
AnalyseDeclarationsTransform, but would that be  too late for compiler
directives?

Any comment about this? Thanks!

--

-- 
Haoyu BAI
School of Computing,
National University of Singapore.
Stefan Behnel | 3 Apr 12:50 2010
Picon

Re: [Cython] Compile-time decorator

Haoyu Bai, 03.04.2010 09:18:
> Thinking about how to implement Cython decorators ( <at> cclass,  <at> cfunc
> etc.) for pure Python mode, I come up with an idea of "compile-time
> decorator". Basically, we want these decorators to have effect during
> compile time, rather than normal Python decorator that is called in
> runtime. So, to implement  <at> cfunc, we can actually implement a function
> cfunc(node), which inputs a DefNode and transform it to a
> CFuncDefNode, then put the function into the compile-time scope.

-1, we shouldn't expose Cython compiler internals to the language level.

It's better to use a transform that intercepts on certain decorators.

Stefan
Haoyu Bai | 3 Apr 14:15 2010
Picon

Re: [Cython] Compile-time decorator

On Sat, Apr 3, 2010 at 6:50 PM, Stefan Behnel <stefan_ml@...> wrote:
> Haoyu Bai, 03.04.2010 09:18:
>> Thinking about how to implement Cython decorators ( <at> cclass,  <at> cfunc
>> etc.) for pure Python mode, I come up with an idea of "compile-time
>> decorator". Basically, we want these decorators to have effect during
>> compile time, rather than normal Python decorator that is called in
>> runtime. So, to implement  <at> cfunc, we can actually implement a function
>> cfunc(node), which inputs a DefNode and transform it to a
>> CFuncDefNode, then put the function into the compile-time scope.
>
> -1, we shouldn't expose Cython compiler internals to the language level.
>
> It's better to use a transform that intercepts on certain decorators.
>
> Stefan

By implement  <at> cfunc as a function, I'm not mean to implement it *in
Cython*, it is still a part of the Cython compiler, as the transforms.
And the main motivation is not to expose Cython internal to the users,
but to have a flexible mechanism to support the various decorators -
Cython directives,  <at> cclass  <at> cfunc, and even some Python builtin
decorator ( <at> classmethod,  <at> staticmethod and  <at> property).

These are decorators need to be executed in compile time. Currently,
the code to deal with these decorators are scattered in many places,
some in transforms, some in nodes. It would be better to have a
unified mechanism to deal with all of these decorators. That's what I
proposed.

Indeed, the node classes do not provide an API so we should not expose
(Continue reading)


Gmane