Mailman 3 September 2011 - cython-devel

PEP 380 approved: syntax for generator delegation
by Stefan Behnel March 6, 2012

March 6, 2012

Hi, PEP 380 ("yield from") recently went through the approval gate. http://www.python.org/dev/peps/pep-0380/ The implementation in CPython isn't rounded up yet and lots of tests are missing from the test suite. But it's agreed that it'll make it into 3.3, and we should try to support it as well. It's a really nice feature. Stefan

2 3

relative_path_in_code_position_comments
by Brett Calcott Nov. 15, 2011

Nov. 15, 2011

Hi all, The path in cython's error output is insensitive to the cwd where cython in invoked. It seems to be based on this variable in Cython/Compiler/Main.py: relative_path_in_code_position_comments = True, If I understand it right, the path output is relative to module it is in, instead of relative to the cwd. This plays havoc with my editor (Vim), as it attempts to try and load the file that caused the error based on parsing the output. I've just changed this variable to False in my install, and it works fine. Is there a reason for this? Am I missing some easy way around this? Thanks, Brett

3 2

Can't login into my trac account
by Vitja Makarov Oct. 9, 2011

Oct. 9, 2011

Hi! Today I found that I can't login into my trac account. Is that common problem or only mine? -- vitja.

2 2

Any news from the IronPython port?
by Stefan Behnel Oct. 8, 2011

Oct. 8, 2011

Hi, subject says it all. The port to IronPython appears to run completely in stealth mode, so I wonder if it has become any usable yet, or if the project was already swept under the carpet and buried for good. Stefan

4 4

Re: [Cython] [cython-users] Re: callback function pointer problem
by mark florisson Oct. 6, 2011

Oct. 6, 2011

On 29 September 2011 22:48, Robert Bradshaw <robertwb(a)math.washington.edu> wrote: > On Thu, Sep 29, 2011 at 5:29 AM, mark florisson > <markflorisson88(a)gmail.com> wrote: >> On 29 September 2011 13:13, Miguel Angel <skuda21(a)gmail.com> wrote: >>>> >>>> Structs already coerce to python dicts. In the memoryview branch it >>>> also does the reverse, i.e. coerce a dict to a struct (you have to be >>>> careful with strings, making sure you hold a reference to the string >>>> object as long as you use the pointer in the struct). You have to be >>>> sure to declare every struct attribute though. >>> >>> Could i see an example usage of this in any repository or the documentation? I >>> can't find any. >>> >>> Regards, >>> Miguel Angel. >>> >> >> It's not in the documentation yet, I updated that in a branch that >> still needs to be merged (which hopefully will be in 0.16). The >> functionality from struct -> object is there though: >> >> cdef extern from *: >> ctypedef struct MyStruct: >> int attrib >> >> cdef MyStruct s = {'attrib':10} # Note, this is NOT object->struct >> conversion, it only eats compile-time expressions here > > or even > > s = MyStruct(attrib=10) That looks very nice, a lot more intuitive than the dict assignment. > It would be natural to support array -> list conversion for slices the > baseclass is convertable, e.g. > > cdef double* data = ... > print data[:10] > > Converting an int[10] to a Python object without slicing is a bit odd as > > cdef int a[10] > [compute a] > cdef object o = a > a[0] = something else > o[1] = another thing > > is non-initiative, as arrays can't be assigned in C and "assignment" > of lists in Python are by reference, not by copy. "o = a[:]" is plenty > clear that there's a copy, so that's better. The other way is a bit > messier, but > > a[:n] = [python list] > > could certainly be supported via an implicit loop. Another > consideration is that with primitive data types we're venturing into > memory view territory, which might be a more useful representation > than Python lists. > > - Robert > Indeed. Currently you can only cast pointers to memoryview slices, but there's no reason to not support arrays as well (without also needing to first cast the array to a pointer). So if arrays have shape information, you could immediately coerce to memoryview (cython.array) objects without needing a cast. This would also work for arrays in structs, as they can only ever have a static size (known at C compile time). Shall we support that? I won't be hard as the infrastructure for casting pointers is already there.

4 8

CyFunction refactoring plan
by Vitja Makarov Oct. 2, 2011

Oct. 2, 2011

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 -- vitja.

4 13

Re: [Cython] adding support for __dict__ in extension types
by Lisandro Dalcin Sept. 26, 2011

Sept. 26, 2011

Bringing up this old post... On 21 June 2010 15:41, Robert Bradshaw <robertwb(a)math.washington.edu> wrote: > On Jun 17, 2010, at 9:31 AM, Lisandro Dalcin wrote: > >> If we special case a __dict__ attribute in extension types, i.e: >> >> cdef class Foo: >> cdef dict __dict__ >> >> and fill type->tp_dictoffset, then we can support __dict__ in >> extension types. >> >> What do you think? > > Sounds like a good idea to me. Note that we check tp_dictoffset for > fast dispatching for cpdef methods (which would be correct as a dict > lookup *would* be needed if __dict__ is available). > I still have this patch lying around in my disk. I remember Stefan had some objections. For example, when the user ask for __dict__, a new dict is unconditionally created (in CPython, type dict are allocated on-demand). I propose to get this patch pushed now, and optimize later (however, I really don't know how to safely implement this optimization). -- Lisandro Dalcin --------------- CIMEC (INTEC/CONICET-UNL) Predio CONICET-Santa Fe Colectora RN 168 Km 472, Paraje El Pozo 3000 Santa Fe, Argentina Tel: +54-342-4511594 (ext 1011) Tel/Fax: +54-342-4511169

3 4

crash bug for closures on extension type methods
by Stefan Behnel Sept. 26, 2011

Sept. 26, 2011

Hi, yes, I know - right after a release is the best time to find crash bugs. Here is one that I find particularly unpleasant: http://trac.cython.org/cython_trac/ticket/742 Given that this was broken for basically forever without anyone noticing, this won't qualify for an emergency release, but I think we shouldn't wait too long with a follow-up release to get this out. Stefan

1 0

cython 0.15 breaks callback code.
by Brett Calcott Sept. 25, 2011

Sept. 25, 2011

Hi. I've just reverted to 0.14.1 because 0.15 breaks code that implements a cpp callback in python. It seems to be a name-mangling problem. I've attached a short test case that shows the problem. They both compile fine on 14.1 and 15. But if I try and run the 15 compiled version I get this: Traceback (most recent call last): File "try_hello.py", line 1, in <module> import test ImportError: dlopen(/Users/brett/Dropbox/Code/kli-project/cython-test/test.so, 2): Symbol not found: __Z19callback_test_helloP7_objecti Referenced from: /Users/brett/Dropbox/Code/kli-project/cython-test/test.so Expected in: dynamic lookup Is there anything new I should be doing? Brett

2 2

'local variable referenced before assignment' warnings
by robert.rex＠exasol.com Sept. 25, 2011

Sept. 25, 2011

Hi, I got a (misleading) Cython warning from the following code example: -------------------------------- cdef extern from "<bar.h>": void foo(int &a, int &b) cdef cyfoo(): cdef int cya, cyb foo(cya, cyb) -------------------------------- Executing "cython --cplus" produced these messages: -------------------------------- warning: example.pyx:6:11: local variable 'cya' referenced before assignment warning: example.pyx:6:16: local variable 'cyb' referenced before assignment -------------------------------- This started with Cython 0.15 (and 0.15.1 also issues these warnings). I assume this warning shouldn't be produced (as in a similar issue here: http://trac.cython.org/cython_trac/ticket/714), right?! Thanks, Robert

5 13