[Cython] Cython test coverage

Hi,

I just ran coverage.py over the test suite.

http://nedbatchelder.com/code/modules/coverage.html

$ python -m coverage -x runtests.py
[...]
$ python -m coverage -r Cython/Compiler/*.py
Name                         Stmts   Exec  Cover
------------------------------------------------
Cython/Compiler/Annotate       107     19    17%
Cython/Compiler/Builtin         17     17   100%
Cython/Compiler/CmdLine         68      0     0%
Cython/Compiler/Code           246    226    91%
Cython/Compiler/DebugFlags       3      3   100%
Cython/Compiler/Errors          68     41    60%
Cython/Compiler/ExprNodes     1969   1245    63%
Cython/Compiler/Lexicon         39      2     5%
Cython/Compiler/Main           212    137    64%
Cython/Compiler/ModuleNode    1048    914    87%
Cython/Compiler/Naming          67     66    98%
Cython/Compiler/Nodes         2038   1412    69%
Cython/Compiler/Options         11     11   100%
Cython/Compiler/Parsing       1556   1078    69%
Cython/Compiler/PyrexTypes     589    484    82%
Cython/Compiler/Scanning       260    186    71%
Cython/Compiler/Symtab         803    666    82%
Cython/Compiler/TypeSlots      264    259    98%
Cython/Compiler/Version          1      1   100%

[Cython] Cython and Python 3k

Hi,

just starting a little thread here to collect things to remember when we
migrate to Python 3k one day.

Robert Bradshaw wrote:
> Stefan Behnel wrote:
>>>> Also, there's Python 3, where especially the C-API is still in flux.
>>>> Not sure
>>>> if it's worth to start thinking about that yet, but it should at least
>>>> stay on the list.
>>>
>>> Yep.
>>
>> I asked on cython-dev to see how far the C-API is. Answer I got is
>> that it may
>> take a bit to stabilize, including renaming types (str etc.) and
>> fixing the
>> outdated docs. So we'll have to see what the status will be in June.
>> It might really be worth a sprint by then.
>>
>> http://comments.gmane.org/gmane.comp.python.devel/92255?set_lines=100000
>>
>> Two additional things I see here: 1) porting Cython itself, and 2)
>> working on
>> better optimisation support in general, to keep users from doing
>> direct C-API
>> calls in Cython code, as this might lead to reduced portability.
>
> I think Python 2.x will be around for quite a while, even after P3k

Re: [Cython] Cython and Python 3k

Stefan Behnel wrote:
> I added bundles that fix at least the obvious "print()" and "<>" stuff.

Sorry, incomplete bundle. Here we go.

Stefan

Stefan Behnel wrote:
> I added bundles that fix at least the obvious "print()" and "<>" stuff.

Sorry, incomplete bundle. Here we go.

Stefan

[Cython] make extension type accesible from python?

I'm trying to learn cython.  As a simple first try, I have some generic c++
code 'my_sum'.  I want to pass it an intvec (std::vector<int>).

It seems to work OK when accessed from c-code:

cdef extern from "vector":
    pass

cdef extern from "test1.hpp":
    ctypedef struct intvec "std::vector<unsigned int>":
        void (* push_back)(int elem)

    intvec intvec_factory "std::vector<unsigned int>"(int len)

    int my_sum "my_sum<std::vector<unsigned int> >"(intvec vec)

cdef intvec v = intvec_factory(2)
v.push_back(2)

print my_sum (v)

I have no idea how to expose intvec to python, and then be able to call
my_sum from python.

I assume there is some way to make extension types that can be used from
python?  Of course, I'd want to be able to add other methods, so that, for
example, intvec can be constructed and manipulated from python.

Any simple examples I could look at?

Re: [Cython] make extension type accesible from python?

Neal Becker wrote:
[real problem stripped]
> I assume there is some way to make extension types that can be used from
> python?  Of course, I'd want to be able to add other methods, so that, for
> example, intvec can be constructed and manipulated from python.

Yes, wrapping it in a Python extension type is the right approach here.

> Any simple examples I could look at?

The Pyrex docs, for example:

http://www.cosc.canterbury.ac.nz/greg.ewing/python/Pyrex/
http://www.cosc.canterbury.ac.nz/greg.ewing/python/Pyrex/version/Doc/Manual/extension_types.html

Stefan

Re: [Cython] make extension type accesible from python?

Stefan Behnel wrote:

> Neal Becker wrote:
> [real problem stripped]
>> I assume there is some way to make extension types that can be used from
>> python?  Of course, I'd want to be able to add other methods, so that,
>> for example, intvec can be constructed and manipulated from python.
> 
> Yes, wrapping it in a Python extension type is the right approach here.
> 
> 
>> Any simple examples I could look at?
> 
> The Pyrex docs, for example:
> 
> http://www.cosc.canterbury.ac.nz/greg.ewing/python/Pyrex/
>
http://www.cosc.canterbury.ac.nz/greg.ewing/python/Pyrex/version/Doc/Manual/extension_types.html
> 
> Stefan
I've been studying these, but I haven't seen my question addressed.  Are
there any examples I could look at?

[Cython] wrapping c++

I've made some progress on learning to wrap std::vector.  I've got a
__getitem__, but I don't know what to do about __setitem__.
cdef extern from "vector":
    pass

cdef extern from "test1.hpp":
    ctypedef struct intvec "std::vector<unsigned int>":
        void (* push_back)(int elem)
        inline int get "operator[]" (int i)

    intvec intvec_factory "std::vector<unsigned int>"(int len)

    int my_sum "my_sum<std::vector<unsigned int> >"(intvec vec)

cdef intvec v = intvec_factory(2)
v.push_back(2)

#print my_sum (v)

cdef class intvec_wrap:
    cdef intvec vec
    def __init__(self):
        self.vec = intvec_factory (2)
    def __getitem__(self, int i):
        return self.vec.get (i)

Problem is, operator[] (or at()) returns an int&.  I don't have a clue what
to do with this.

Re: [Cython] wrapping c++

On Tue, Mar 4, 2008 at 6:39 AM, Neal Becker <ndbecker2@...> wrote:
> I've made some progress on learning to wrap std::vector.  I've got a
>  __getitem__, but I don't know what to do about __setitem__.
>  cdef extern from "vector":
>     pass
>
>  cdef extern from "test1.hpp":
>     ctypedef struct intvec "std::vector<unsigned int>":
>         void (* push_back)(int elem)
>         inline int get "operator[]" (int i)
>
>     intvec intvec_factory "std::vector<unsigned int>"(int len)
>
>     int my_sum "my_sum<std::vector<unsigned int> >"(intvec vec)
>
>
>
>  cdef intvec v = intvec_factory(2)
>  v.push_back(2)
>
>  #print my_sum (v)
>
>  cdef class intvec_wrap:
>     cdef intvec vec
>     def __init__(self):
>         self.vec = intvec_factory (2)
>     def __getitem__(self, int i):
>         return self.vec.get (i)
>
>  Problem is, operator[] (or at()) returns an int&.  I don't have a clue what

Re: [Cython] wrapping c++

William Stein wrote:
> cdef extern from "":
>     void DEFINE_SET "#define SET(a,b,c) a[b]=c; //"()
>     void SET(intvec, int, int)
> DEFINE_SET()
>
> The key thing is the evil dirty trick to define a SET macro directly in
> Cython.

"Evil" and "dirty" were exactly the two words that came to my mind before
I even got to reading your own comment on this. :)

I would really put something like this into an external header file, and
just declare "SET()" as being external...

Stefan

Re: [Cython] wrapping c++

Stefan Behnel wrote:

> William Stein wrote:
>> cdef extern from "":
>>     void DEFINE_SET "#define SET(a,b,c) a[b]=c; //"()
>>     void SET(intvec, int, int)
>> DEFINE_SET()
>>
>> The key thing is the evil dirty trick to define a SET macro directly in
>> Cython.
> 
> "Evil" and "dirty" were exactly the two words that came to my mind before
> I even got to reading your own comment on this. :)
> 
> I would really put something like this into an external header file, and
> just declare "SET()" as being external...
> 
> Stefan
Any thoughts on what it would take to support a non-evil implementation?