Re: [Cython] Problems with decorated methods in cdef classes

2011-08-22 Thread Stefan Behnel

Robert Bradshaw, 17.08.2011 08:02:

On Sun, Aug 14, 2011 at 8:02 AM, Stefan Behnel wrote:

def print_args(func):
def f(*args, **kwds):
print "args", args, "kwds", kwds
return func(*args, **kwds)
return f

cdef class Num:
@print_args
def is_prime(self, bint print_factors=False):
...

Now, the problem is that Cython considers "is_prime" to be a method of a
cdef class, although it actually is not. It's only an arbitrary function
that happens to be defined inside of a cdef class body and that happens to
be *called* by a method, namely "f". It now crashes for me because the
"self" argument is not being passed into is_prime() as a C method argument
when called by the wrapper function - and that's correct, because it's not a
method call but a regular function call at that point.

The correct way to fix this is to turn all decorated methods in cdef classes
into plain functions. However, this has huge drawbacks, especially that the
first argument ('self') can no longer be typed as the surrounding extension
type. But, after all, you could do this:

def swap_args(func):
def f(*args):
return func(*args[::-1])
return f

cdef class Num:
@swap_args
def is_prime(arg, self):
...

I'm not sure what to make of this. Does it make sense to go this route? Or
does anyone see a way to make this "mostly" work, e.g. by somehow
restricting cdef classes and their methods? Or should we just add runtime
checks to prevent bad behaviour of decorators?


I would be happy in making decorated methods into "ordinary"
functions--this will probably play more nicely with many real-world
decorators as well.


I created a ticket for this:

http://trac.cython.org/cython_trac/ticket/719

Stefan
___
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel


Re: [Cython] Entry.utility_code_definitions vs. Entry.utility_code

2011-08-22 Thread Stefan Behnel

Stefan Behnel, 21.08.2011 14:35:

mark florisson, 21.08.2011 12:57:

I believe the _memview branch is
nearly finished though, so could you wait for that merge? Otherwise
modifying the pipeline wouldn't be too bad either, it might only give
a few conflicts.


I think it can wait a little longer.


http://trac.cython.org/cython_trac/ticket/718

Stefan
___
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel


[Cython] Fwd: PEP 393 Summer of Code Project

2011-08-22 Thread Stefan Behnel

Sounds like he's at a point where this becomes interesting for us.

Stefan

 Original-Message 
Subject: PEP 393 Summer of Code Project
Date: Mon, 22 Aug 2011 14:58:51 -0400
From: Torsten Becker 
To: python-dev...@python.org

Hello all,

I have implemented an initial version of PEP 393 -- "Flexible String
Representation" as part of my Google Summer of Code project.  My patch
is hosted as a repository on bitbucket [1] and I created a related
issue on the bug tracker [2].  I posted documentation for the current
state of the development in the wiki [3].

Current tests show a potential reduction of memory by about 20% and
CPU by 50% for a join micro benchmark.  Starting a new interpreter
still causes 3244 calls to create compatibility Py_UNICODE
representations, 263 strings are created using the old API while 62719
are created using the new API.  More measurements are on the wiki page
[3].

If there is interest, I would like to continue working on the patch
with the goal of getting it into Python 3.3.  Any and all feedback is
welcome.


Regards,
Torsten

[1]: http://www.python.org/dev/peps/pep-0393
[2]: http://bugs.python.org/issue12819
[3]: http://wiki.python.org/moin/SummerOfCode/2011/PEP393
___
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel


[Cython] pyregr testsuite regression

2011-08-22 Thread Vitja Makarov
Hudson shows regression for last 4 pyregr builds.

-- 
vitja.
___
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel


Re: [Cython] pyregr testsuite regression

2011-08-22 Thread Stefan Behnel

Vitja Makarov, 23.08.2011 06:26:

Hudson shows regression for last 4 pyregr builds.


Yes, I enabled the "always_allow_keywords" option for better Python 
compatibility, which disables the signature optimisation into METH_O & 
friends for def functions. That helped in a couple of cases but broke 
others. The regression appears to be mostly because generator expressions 
do not work with this option:


http://trac.cython.org/cython_trac/ticket/720

CyFunction may or may not drop the need for that option eventually, but for 
now, it would be good to fix it.


I also wouldn't object to switching it off again, in case it's not an easy 
fix (I tried but didn't find the right place to fix it).


Stefan
___
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel


Re: [Cython] pyregr testsuite regression

2011-08-22 Thread Vitja Makarov
2011/8/23 Stefan Behnel :
> Vitja Makarov, 23.08.2011 06:26:
>>
>> Hudson shows regression for last 4 pyregr builds.
>
> Yes, I enabled the "always_allow_keywords" option for better Python
> compatibility, which disables the signature optimisation into METH_O &
> friends for def functions. That helped in a couple of cases but broke
> others. The regression appears to be mostly because generator expressions do
> not work with this option:
>
> http://trac.cython.org/cython_trac/ticket/720
>
> CyFunction may or may not drop the need for that option eventually, but for
> now, it would be good to fix it.
>
> I also wouldn't object to switching it off again, in case it's not an easy
> fix (I tried but didn't find the right place to fix it).
>

Ok. I'll take a look later.


-- 
vitja.
___
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel


Re: [Cython] pyregr testsuite regression

2011-08-22 Thread Robert Bradshaw
On Mon, Aug 22, 2011 at 9:41 PM, Stefan Behnel  wrote:
> Vitja Makarov, 23.08.2011 06:26:
>>
>> Hudson shows regression for last 4 pyregr builds.
>
> Yes, I enabled the "always_allow_keywords" option for better Python
> compatibility, which disables the signature optimisation into METH_O &
> friends for def functions. That helped in a couple of cases but broke
> others. The regression appears to be mostly because generator expressions do
> not work with this option:
>
> http://trac.cython.org/cython_trac/ticket/720
>
> CyFunction may or may not drop the need for that option eventually, but for
> now, it would be good to fix it.
>
> I also wouldn't object to switching it off again, in case it's not an easy
> fix (I tried but didn't find the right place to fix it).

IIRC, it is a significant performance penalty to turn that off (which
is why it's disabled by default). We should at least allow one to
disable it.

- Robert
___
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel


Re: [Cython] pyregr testsuite regression

2011-08-22 Thread Vitja Makarov
2011/8/23 Robert Bradshaw :
> On Mon, Aug 22, 2011 at 9:41 PM, Stefan Behnel  wrote:
>> Vitja Makarov, 23.08.2011 06:26:
>>>
>>> Hudson shows regression for last 4 pyregr builds.
>>
>> Yes, I enabled the "always_allow_keywords" option for better Python
>> compatibility, which disables the signature optimisation into METH_O &
>> friends for def functions. That helped in a couple of cases but broke
>> others. The regression appears to be mostly because generator expressions do
>> not work with this option:
>>
>> http://trac.cython.org/cython_trac/ticket/720
>>
>> CyFunction may or may not drop the need for that option eventually, but for
>> now, it would be good to fix it.
>>
>> I also wouldn't object to switching it off again, in case it's not an easy
>> fix (I tried but didn't find the right place to fix it).
>
> IIRC, it is a significant performance penalty to turn that off (which
> is why it's disabled by default). We should at least allow one to
> disable it.
>

That's switched on only for pyregr tests


-- 
vitja.
___
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel


Re: [Cython] pyregr testsuite regression

2011-08-22 Thread Vitja Makarov
2011/8/23 Vitja Makarov :
> 2011/8/23 Robert Bradshaw :
>> On Mon, Aug 22, 2011 at 9:41 PM, Stefan Behnel  wrote:
>>> Vitja Makarov, 23.08.2011 06:26:

 Hudson shows regression for last 4 pyregr builds.
>>>
>>> Yes, I enabled the "always_allow_keywords" option for better Python
>>> compatibility, which disables the signature optimisation into METH_O &
>>> friends for def functions. That helped in a couple of cases but broke
>>> others. The regression appears to be mostly because generator expressions do
>>> not work with this option:
>>>
>>> http://trac.cython.org/cython_trac/ticket/720
>>>
>>> CyFunction may or may not drop the need for that option eventually, but for
>>> now, it would be good to fix it.
>>>
>>> I also wouldn't object to switching it off again, in case it's not an easy
>>> fix (I tried but didn't find the right place to fix it).
>>
>> IIRC, it is a significant performance penalty to turn that off (which
>> is why it's disabled by default). We should at least allow one to
>> disable it.
>>
>
> That's switched on only for pyregr tests
>

I've fixed it here
https://github.com/cython/cython/commit/7c01e8488e12f5e7581a356df5882d5329457369

-- 
vitja.
___
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel


Re: [Cython] pyregr testsuite regression

2011-08-22 Thread Stefan Behnel

Vitja Makarov, 23.08.2011 07:29:

2011/8/23 Vitja Makarov:

2011/8/23 Robert Bradshaw:

On Mon, Aug 22, 2011 at 9:41 PM, Stefan Behnel wrote:

Vitja Makarov, 23.08.2011 06:26:


Hudson shows regression for last 4 pyregr builds.


Yes, I enabled the "always_allow_keywords" option for better Python
compatibility, which disables the signature optimisation into METH_O&
friends for def functions. That helped in a couple of cases but broke
others. The regression appears to be mostly because generator expressions do
not work with this option:

http://trac.cython.org/cython_trac/ticket/720

CyFunction may or may not drop the need for that option eventually, but for
now, it would be good to fix it.

I also wouldn't object to switching it off again, in case it's not an easy
fix (I tried but didn't find the right place to fix it).


IIRC, it is a significant performance penalty to turn that off (which
is why it's disabled by default). We should at least allow one to
disable it.


That's switched on only for pyregr tests


Right, but it's still a useful option for Python compatibility in general.



I've fixed it here
https://github.com/cython/cython/commit/7c01e8488e12f5e7581a356df5882d5329457369


Ah, given the right pair of eyeballs ...

Thanks!

Stefan
___
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel