headers
Stefan Behnel | 1 May 2010 23:11
Picon
Favicon

Re: [Cython] coercion of char/Py_UNICODE to Python objects - string or integer?

Stefan Behnel, 25.04.2010 10:30:
> Stefan Behnel, 25.04.2010 07:28:
>> the question is just if we want
>>
>>        py_int_val = uval
>>        py_ustr_val =<unicode>uval
>>
>> or
>>
>>        py_int_val =<int>uval
>>        py_ustr_val = uval
>>
>> My gut feeling is that the coercion to strings would be more straight
>> forward. It would also clean up the compiler code a bit as implicit
>> coercions (e.g. for comparisons) would then work out-of-the-box in both
>> ways. Currently, "Py_UNICODE in unicode" must be special cased (which it
>> still would in the future, but only for optimisation purposes, not to make
>> it work at all).
>
> Given that only char->bytes breaks backwards compatibility, since
> Py_UNICODE wasn't supported at all until now - could we agree on making
> Py_UNICODE->unicode the default behaviour and leaving char->PyInt as is for
> the time being? We can still decide to break backwards compatibility later
> on, and we can always support the explicit
>
>       py_s =<bytes>char_val
>       py_i =<int>pyunicode_val
>
> safely, so users can just rely on that if they need safe behaviour.
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Lisandro Dalcin | 2 May 2010 23:49
Picon
Gravatar

Re: [Cython] ssize_t_T399 test failing in Py2.4

On 1 May 2010 14:10, Stefan Behnel <stefan_ml <at> behnel.de> wrote:
> Hi Lisandro,
>
> I get this in Py2.4 after your last commit. Can you take a look?
>

Is that machine a 64bits one?

In such case, the test is broken, because of this line:

SSIZE_T_MAX = <ssize_t>((<size_t>-1)>>1)

I've pushed a quick fix: http://hg.cython.org/cython-devel/rev/66bc28d5c751

PS: Can you see now why I was no so happy about using Py_ssize_t? Do
you think that my original way of defining SSIZE_T_MAX was a nonsense?
We should not enforce ssize_t meaning Py_ssize_t, but in case we do it
anyway, we should provide users a last chance to change our decision
(i.e, add an indirection and #define __Pyx_ssize_t Py_ssize_t).

>
>
> Traceback (most recent call last):
>  File
> "/home/scoder/hudson/jobs/py24-svn/workspace/INSTALL/py24/lib/python2.4/doctest.py",
> line 2157, in runTest
>    raise self.failureException(self.format_failure(new.getvalue()))
> AssertionError: Failed doctest test for ssize_t_T399
>  File
> "/mnt/usb1/scratch/hudson/jobs/cython-devel-tests-py24-c/workspace/BUILD/run/c/ssize_t_T399.so",
(Continue reading)

Permalink | Reply | 0 comments |
headers
Lisandro Dalcin | 3 May 2010 00:45
Picon
Gravatar

Re: [Cython] coercion of char/Py_UNICODE to Python objects - string or integer?

On 1 May 2010 18:11, Stefan Behnel <stefan_ml@...> wrote:
> ... and this even matches the behaviour of the 'bytes' type in Python 3
> which really returns integer values on indexing/iteration, whereas the
> 'str' (i.e. 'unicode') type returns substrings.

VERY good point...

--

-- 
Lisandro Dalcin
---------------
CIMEC (INTEC/CONICET-UNL)
Predio CONICET-Santa Fe
Colectora RN 168 Km 472, Paraje El Pozo
Tel: +54-342-4511594 (ext 1011)
Tel/Fax: +54-342-4511169
Permalink | Reply | 0 comments |
headers
Haoyu Bai | 3 May 2010 12:19
Picon
Gravatar

Re: [Cython] Haoyu Bai's application accepted for GSoC

On Thu, Apr 29, 2010 at 1:14 AM, Craig Citro <craigcitro@...> wrote:
>>> The list of accepted applications for Google Summer of Code 2010 were
>>> just announced yesterday, and Haoyu Bai's Cython application was
>>> officially accepted. Congratulations, and we're looking forward to a
>>> lot of great stuff happing this summer.
>>
>> Happy to read this. Congratulations!
>>
>
> Ditto -- between this and several of us having other responsibilities
> off our shoulders, it should be an exciting summer for Cython. ;)
>
> -cc

Thank you all! I'm excited about the summer, too! :)

Craig and I have discussed about the workflow. I'll use some local hg
branches to maintain the patches and submit the patches to trac.
Hopefully I can start to work on Cython sooner.

--

-- 
Haoyu BAI
School of Computing,
National University of Singapore.
Permalink | Reply | 14 comments |
headers
Kurt Smith | 3 May 2010 17:34
Picon

Re: [Cython] Haoyu Bai's application accepted for GSoC

On Mon, May 3, 2010 at 5:19 AM, Haoyu Bai <baihaoyu@...> wrote:
> On Thu, Apr 29, 2010 at 1:14 AM, Craig Citro <craigcitro@...> wrote:
>>>> The list of accepted applications for Google Summer of Code 2010 were
>>>> just announced yesterday, and Haoyu Bai's Cython application was
>>>> officially accepted. Congratulations, and we're looking forward to a
>>>> lot of great stuff happing this summer.
>>>
>>> Happy to read this. Congratulations!
>>>
>>
>> Ditto -- between this and several of us having other responsibilities
>> off our shoulders, it should be an exciting summer for Cython. ;)
>>
>> -cc
>
> Thank you all! I'm excited about the summer, too! :)
>
> Craig and I have discussed about the workflow. I'll use some local hg
> branches to maintain the patches and submit the patches to trac.
> Hopefully I can start to work on Cython sooner.

Just a suggestion, take it or leave it:

For my GSoC work I found google's codereview to be a very helpful tool.

http://code.google.com/p/rietveld/wiki/CodeReviewHelp

It allows you to submit patches that are presented in an app-engine
GUI.  Reviewers can make comments & suggestions that are local to each
change in the patch.
(Continue reading)

Permalink | Reply | 13 comments |
headers
Craig Citro | 3 May 2010 17:40
Picon
Gravatar

Re: [Cython] Haoyu Bai's application accepted for GSoC

> Just a suggestion, take it or leave it:
>
> For my GSoC work I found google's codereview to be a very helpful tool.
>
> http://code.google.com/p/rietveld/wiki/CodeReviewHelp
>
> It allows you to submit patches that are presented in an app-engine
> GUI.  Reviewers can make comments & suggestions that are local to each
> change in the patch.
>
> Perhaps it would be easier to use for interactive patch review than
> trac. (It works seamlessly with mercurial, too).
>

+10 -- we should *totally* start using rietveld. (Plus, in a month or
two, Robert and I will be totally in love with it.)

-cc
Permalink | Reply | 12 comments |
headers
Robert Bradshaw | 3 May 2010 19:58
Favicon

Re: [Cython] Haoyu Bai's application accepted for GSoC

On May 3, 2010, at 8:40 AM, Craig Citro wrote:

>> Just a suggestion, take it or leave it:
>>
>> For my GSoC work I found google's codereview to be a very helpful  
>> tool.
>>
>> http://code.google.com/p/rietveld/wiki/CodeReviewHelp
>>
>> It allows you to submit patches that are presented in an app-engine
>> GUI.  Reviewers can make comments & suggestions that are local to  
>> each
>> change in the patch.
>>
>> Perhaps it would be easier to use for interactive patch review than
>> trac. (It works seamlessly with mercurial, too).
>>
>
> +10 -- we should *totally* start using rietveld. (Plus, in a month or
> two, Robert and I will be totally in love with it.)

I already am :). It may be good to put up a repo on hg.cython.org (so  
it's easy for people to sync up with what you have to try it out and  
play with it). Also, did you set up a blog yet?

- Robert
Permalink | Reply | 11 comments |
headers
Marien Zwart | 3 May 2010 20:22
Picon

[Cython] Missed optimization for list.pop

Hi,

http://trac.cython.org/cython_trac/ticket/447 describes an added
optimization for calls to list.pop(). Somewhat counter-intuitively this
optimization is only applied if pop() is called on things of type
"object", not if it is called on things explicitly typed as "list".
Compare the following (silly) examples:

def f():
    cdef list l = []
    l.append(0)
    l.pop()
    return l

def f():
    cdef object l = []
    l.append(0)
    l.pop()
    return l

Using either Cython 0.12.1 or cython-devel the second one generates
calls to __Pyx_Object_Append and __Pyx_Object_Pop, which take fast paths
if called on a list. The first one generates a direct to PyList_Append,
but then PyObject_GetAttr and PyObject_Call for pop().

It might be nice to add:
    _handle_simple_method_list_pop = _handle_simple_method_object_pop

somewhere in Cython/Compiler/Optimize.py, which at least makes Cython
not generate worse code for the more restrictively typed list (tested it
(Continue reading)

Permalink | Reply | 2 comments |
headers
Stefan Behnel | 4 May 2010 07:30
Picon
Favicon

Re: [Cython] Missed optimization for list.pop

Marien Zwart, 03.05.2010 20:22:
> http://trac.cython.org/cython_trac/ticket/447 describes an added
> optimization for calls to list.pop(). Somewhat counter-intuitively this
> optimization is only applied if pop() is called on things of type
> "object", not if it is called on things explicitly typed as "list".
> Compare the following (silly) examples:
>
> def f():
>      cdef list l = []
>      l.append(0)
>      l.pop()
>      return l
>
> def f():
>      cdef object l = []
>      l.append(0)
>      l.pop()
>      return l
>
> Using either Cython 0.12.1 or cython-devel the second one generates
> calls to __Pyx_Object_Append and __Pyx_Object_Pop, which take fast paths
> if called on a list. The first one generates a direct to PyList_Append,
> but then PyObject_GetAttr and PyObject_Call for pop().

Yes, I stumbled over that, too, but didn't care to fix it so far. I'll look 
into it.

Stefan
Permalink | Reply | 0 comments |
headers
Stefan Behnel | 4 May 2010 07:57
Picon
Favicon

Re: [Cython] Missed optimization for list.pop

Marien Zwart, 03.05.2010 20:22:
> It might be nice to add:
>      _handle_simple_method_list_pop = _handle_simple_method_object_pop
>
> somewhere in Cython/Compiler/Optimize.py, which at least makes Cython
> not generate worse code for the more restrictively typed list (tested it
> briefly, the resulting code looked reasonable and compiled).

That's also the right thing to do. The resulting code is just about as fast 
as a specialised function for typed lists, so it's not worth doing anything 
more than that.

Thanks!

Stefan
Permalink | Reply | 0 comments |

Gmane