headers
Robert Bradshaw | 2 Jul 2008 06:49
Favicon

Re: [Cython] .pxd's that depend on other .pxd's

Did this work in a former version of Cython? This may be an issue  
with the way the __init__ stuff was merge in. A short-term workaround  
would be to just use relative imports (i.e. "from translatable  
cimport Translatable" for now.

- Robert

On Jun 30, 2008, at 8:12 AM, Peter Todd wrote:

> Using the attached tarball I get this error message with Cython 0.9.8:
>
>
> pete <at> tilt:~/t/bug$ cython Tuke/id.pyx
>
> Error converting Pyrex file to C:
> ------------------------------------------------------------
> ...
> from Tuke.translatable cimport Translatable
> ^
> ------------------------------------------------------------
>
> /home/pete/t/bug/Tuke/id.pyx:1:0: 'Tuke.translatable.pxd' not found
>
> Error converting Pyrex file to C:
> ------------------------------------------------------------
> ...
> from Tuke.translatable cimport Translatable
>                               ^
> ------------------------------------------------------------
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Stefan Behnel | 2 Jul 2008 08:03
Picon
Favicon

Re: [Cython] .pxd's that depend on other .pxd's

Hi,

Peter Todd wrote:
> Using the attached tarball I get this error message with Cython 0.9.8:
> 
> 
> pete <at> tilt:~/t/bug$ cython Tuke/id.pyx 
> /home/pete/t/bug/Tuke/id.pyx:1:0: 'Tuke.translatable.pxd' not found

Do you have an __init__.py in the Tuke package?

Stefan
Permalink | Reply | 0 comments |
headers
Dag Sverre Seljebotn | 2 Jul 2008 11:00
Picon
Picon

[Cython] Best way to fake buffers in Py2?

Part of my buffer proposal is to provide our own implementation of it 
for Python 2 (I'm unsure about the status for 2.6, it seems like not the 
whole buffer API might be backported). For now I'll just do whatever 
will get us something to play with, but what do people think is a 
long-term solution for this?

What is needed is that for Python 2 is that we bundle something like 
this (psuedo-code):

#ifdef Py2
PyAPI_FUNC(int) PyObject_GetBuffer(PyObject *obj, Py_buffer *view,
    int flags) {

   if (numpy is available && obj instanceof numpy.ndarray) {
     view->buf = obj->data;
     view->strides = obj->strides;
     view->shape = obj->shape;
     ...
   } else if (PIL is available && obj instanceof Imaging.Image) {
     ...
   } ... other buffers ...

}
#endif

Now the question is, how do I best do this? The "X is available" (and if 
so, #include its headers...) is the tricky part. I'm thinking along the 
lines of having a new special attribute on the classes in question, 
something like this:
(Continue reading)

Permalink | Reply | 2 comments |
headers
Dag Sverre Seljebotn | 2 Jul 2008 11:02
Picon
Picon

Re: [Cython] Best way to fake buffers in Py2?

Dag Sverre Seljebotn wrote:
> And then generate a pyx-file-specific local PyObject_GetBuffer depending 
> on the __cython_py2_buffer__ we can find:
> 
> #ifdef Py2
> static int PyObject_GetBuffer(PyObject *, Py_buffer *, int);
> #endif
> 
> ... code using PyObject_GetBuffer ...
> 
> #ifdef Py2
> PyAPI_FUNC(int) PyObject_GetBuffer(PyObject *obj, Py_buffer *view,
>    int flags) {

Sorry, this should have been declared static int as well.

--

-- 
Dag Sverre
Permalink | Reply | 0 comments |
headers
Robert Bradshaw | 2 Jul 2008 11:18
Favicon

Re: [Cython] Best way to fake buffers in Py2?

On Jul 2, 2008, at 2:00 AM, Dag Sverre Seljebotn wrote:

> Part of my buffer proposal is to provide our own implementation of it
> for Python 2 (I'm unsure about the status for 2.6, it seems like  
> not the
> whole buffer API might be backported). For now I'll just do whatever
> will get us something to play with, but what do people think is a
> long-term solution for this?
>
> What is needed is that for Python 2 is that we bundle something like
> this (psuedo-code):
>
> #ifdef Py2
> PyAPI_FUNC(int) PyObject_GetBuffer(PyObject *obj, Py_buffer *view,
>     int flags) {
>
>    if (numpy is available && obj instanceof numpy.ndarray) {
>      view->buf = obj->data;
>      view->strides = obj->strides;
>      view->shape = obj->shape;
>      ...
>    } else if (PIL is available && obj instanceof Imaging.Image) {
>      ...
>    } ... other buffers ...
>
> }
> #endif

That looks good.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Fernando Perez | 2 Jul 2008 23:50
Picon
Gravatar

[Cython] Is this a bug in ye'ole cython?

Hi folks,

I'm wondering if this is expected behavior.  Consider some trivial
little class like

class Simpleton:
    def __str__(self):
        return "A simpleton"

    def incr(self,x):
        """Increment x by one.

        Examples:

        >>> s = Simpleton()
        >>> s.incr(1)
        2
        >>> s.incr(10)
        12
        """
        return x+1

If I build this thing in cython, the Simpleton.incr.__module__
attribute is set to None, while if I make it a pure python module,
it's correctly set to the module name:

In [18]: p sprimes.primes.Simpleton.incr.__module__
None

In [19]: p sprimes.pyprimes.Simpleton.incr.__module__
(Continue reading)

Permalink | Reply | 2 comments |
headers
Robert Bradshaw | 3 Jul 2008 03:19
Favicon

Re: [Cython] Is this a bug in ye'ole cython?

No, this sounds like a bug.

On Jul 2, 2008, at 2:50 PM, Fernando Perez wrote:

> Hi folks,
>
> I'm wondering if this is expected behavior.  Consider some trivial
> little class like
>
> class Simpleton:
>     def __str__(self):
>         return "A simpleton"
>
>     def incr(self,x):
>         """Increment x by one.
>
>         Examples:
>
>>>> s = Simpleton()
>>>> s.incr(1)
>         2
>>>> s.incr(10)
>         12
>         """
>         return x+1
>
> If I build this thing in cython, the Simpleton.incr.__module__
> attribute is set to None, while if I make it a pure python module,
> it's correctly set to the module name:
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Fernando Perez | 3 Jul 2008 07:40
Picon
Gravatar

Re: [Cython] Is this a bug in ye'ole cython?

On Wed, Jul 2, 2008 at 6:19 PM, Robert Bradshaw
<robertwb@...> wrote:
> No, this sounds like a bug.

OK, thanks.  I was able to work around it for my purposes (doctesting
of extension code using nose) so it's no biggie for me, but it's still
probably worth fixing.

Cheers,

f
Permalink | Reply | 0 comments |
headers
Dag Sverre Seljebotn | 4 Jul 2008 23:46
Picon
Picon

[Cython] Buffer must know exact C types

Currently, wherever a C type is used in Cython, it is enough to specify 
sort-of what kind of class of type it is... the following will work all 
right:

cdef extern ...:
     ctypedef int int8
     ctypedef int int16
     ctypedef int int32
     ctypedef int int64

However, when types are used in buffers:

cdef object[int16, 3] x

one must translate the type (dtype) into a character representation (as 
listed in http://docs.python.org/lib/module-struct.html). For instance, 
signed short is "h" and signed int is "i"; and one can imagine int16 to 
be any of these (which one being decided by the included header-file; 
NumPy comes with a long list defining intXX for a lot of cases; you can 
choose whether to use a C-dependant type like "npy_longlong" or a fixed 
type like "npy_int64").

I see two options:
a) Start requiring exact ctypedefs in Cython; at least to get correct 
buffer behaviour. However, for NumPy this would require a lot of 
"#ifdefs" Cython-side. (NumPy comes with two options for each type,

b) "Somehow" get the C compiler to map the C-compiler-resolved type to 
the char. With C++ this would be easy:
(Continue reading)

Permalink | Reply | 8 comments |
headers
Dag Sverre Seljebotn | 4 Jul 2008 23:49
Picon
Picon

Re: [Cython] Buffer must know exact C types

Dag Sverre Seljebotn wrote:

> int main() {
>    int t;
>    cout << TypeChar<typeof(t)>::value;
> }
> 
> however I'm not sure if any tricks are possible in C to get something 
> like this?
> 

To be clear, C++ would then also allow this:

typedef int foo;
int main() {
   foo t;
   cout << TypeChar<typeof(t)>::value;
}

and so, one wouldn't need an "exact" foo ctypedef in Cython, one would 
just use the template to map the type to the character when needed...

--

-- 
Dag Sverre
Permalink | Reply | 0 comments |

Gmane