Julien Delafontaine | 21 Oct 16:44 2014
Picon

Distributing a script in a Cython module

Hello,

I packaged a Cython module that contains a command-line script. Because I declare it with "scripts=[...]" in setuptools, it gets installed at some random place (/usr/local/bin/) outside of the module when I execute the setup.py.
Now I need to import my functions in this script, tried everything and it is driving me crazy. I suppose it is Cython-specific because I follow the same steps as everybody else and it works for them otherwise.
The arborescence of the package is as follows:

myapp            (package name)
-myapp           (module name)
----__init__.py
----myapp         (the script)
----myapp.pyx
----myapp.c
-dist
-build
----...                   (.so and stuff)
----scripts-2.7/myapp    (built script)


How can I import functions from the .so inside my script so that they remain available after installation (pip install...) ?
So far on top of my script I tried both

import myapp
from myapp import myapp

to call a method

myapp.method

"import myapp" never works, but I'd like to make it work... 
"from myapp import myapp" works for my local installation (setup.py) but not through "pip install".
After installation with "pip install", it is still possible to "import myapp" in a python console but it has no user defined contents and points to the __init__.py, or some get only "No module named myapp".

Can you help me with this ?

--

---
You received this message because you are subscribed to the Google Groups "cython-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cython-users+unsubscribe <at> googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Abbeville | 21 Oct 14:13 2014
Picon

Cythonizing Python objects

Want to understand what is the most efficient way to cythonize common python objects wrt performance.  For example:

my_list = ['what', 'a', 'hoot', 'this' 'is']

To iterate through my_list, we can use standard Python as:

for word in my_list:
    <do stuff>

With cython, we can use the above code as-is or add type information as:

for i in range(len(my_list)):
    cdef unsigned int i
    word = my_list[i]
    <do stuff>

Next, consider a dictionary:

my_dict = {9:'what', 5:'a', 3:'hoot', 7:'this' 1:'is'}

To iterate through my_dict to get both the key and value, we can use standard Python as:

for k, v in my_dict.items():
    <do stuff>

With cython, we can use the above code as-is or add type information as:

keys = my_dict.keys()
for i in range(len(my_dict)):
    cdef unsigned int i, k
    
    k = keys[i]
    v = my_dict[k]
    <do stuff>

Is the cythonizing of the list and dictionary iteration correct wrt improving performance?

--

---
You received this message because you are subscribed to the Google Groups "cython-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cython-users+unsubscribe <at> googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Abbeville | 20 Oct 12:44 2014
Picon

AttributeError: 'module' object has no attribute 'locals'

Getting this error with cython (0.21 & 0.21.1) from Anaconda (2.1) on both windows and linux

> python do_cythonize.py build_ext --inplace

Traceback (most recent call last):
  File "do_cythonize.py", line 14, in <module>
    from Cython.Build import cythonize
  File "C:\Anaconda\lib\site-packages\Cython\Build\__init__.py", line 1, in <module>
    from .Dependencies import cythonize
  File "C:\Anaconda\lib\site-packages\Cython\Build\Dependencies.py", line 148, in <module>
    <at> cython.locals(start=long, end=long)
AttributeError: 'module' object has no attribute 'locals'
Exception KeyError: KeyError(26750608,) in <module 'threading' from 'C:\Anaconda\lib\threading.pyc'> ignored

do_cythonize.py

import numpy
from distutils.core import setup
from Cython.Build import cythonize 
 
ext_modules = cythonize(["config.pyx"])
 
setup(
    ext_modules = ext_modules, 
    include_dirs=[numpy.get_include()]

Any idea what the problem is? Thx.

--

---
You received this message because you are subscribed to the Google Groups "cython-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cython-users+unsubscribe <at> googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
1989lzhh | 20 Oct 07:06 2014
Picon

The type inference of Memoryview slice is not supported in cython

Hi,
I find that the type inference of  memoryview slice and index is not supported in the current cython. I look up
the source code and find 'analyses_types' method in the IndexNode have the ability to infer memoryview
slice. It seems this method have the same ability with 'infer_type' method, right?
Regards,
Liu zhenhai

--

-- 

--- 
You received this message because you are subscribed to the Google Groups "cython-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cython-users+unsubscribe <at> googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Martin Bammer | 20 Oct 06:57 2014
Picon

Re: Cython 0.21.1 released

When I try to execute a file (without compiling) which contains:

<at> cython.returns(cython.unicode)

It will fail with an error that unicode is not defined in module cython.
But compiling the source file and executing the compiled file succeeds.

--

---
You received this message because you are subscribed to the Google Groups "cython-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cython-users+unsubscribe <at> googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Jeroen Demeyer | 19 Oct 21:08 2014
Picon

Re: Repeating cdef declarations in derived classes

On 2014-10-18 16:31, Stefan Behnel wrote:
>> Is there even a difference between
>>
>> cdef class Derived(Base):
>>      cdef int foo()
>>      cdef int bar()
>>
>> and
>>
>> cdef class Derived(Base):
>>      cdef int bar()
>
> Yes. It's as in Python. If you redefine a method in a derived class, it
> gets overwritten.
My original question was not so clear, I meant for .pxd declarations.
Does it make a difference there?

--

-- 

--- 
You received this message because you are subscribed to the Google Groups "cython-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cython-users+unsubscribe <at> googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

jelle feringa | 19 Oct 11:40 2014
Picon

loading a .pyc file from a cython extesion fails

I'm working on having my module distributed through conda and ran into the following:

fcl.fcl is the cython .so extension
fcl.collision_data is a .py python module

>>> from fcl import fcl
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "fcl/fcl.pyx", line 9, in init fcl.fcl (fcl/fcl.cpp:15449)
ImportError: No module named collision_data

[ deletes the collisiont_data.pyc ]

>>> from fcl import fcl

[ all is peachy ]


its likely that the .pyc file was compiled in another directory then the directory where the file currently resides.

it would be cool for a cython module to disregard the .pyc if directory where its corresponding .py file is another one than the .pyc file.
not sure if the .pyc file stores a path to the referenced .py file though...

Best,

-jelle




--

---
You received this message because you are subscribed to the Google Groups "cython-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cython-users+unsubscribe <at> googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Robert Bradshaw | 18 Oct 18:29 2014
Picon

Re: Repeating cdef declarations in derived classes

On Sat, Oct 18, 2014 at 7:31 AM, Stefan Behnel <stefan_ml <at> behnel.de> wrote:
Jeroen Demeyer schrieb am 17.10.2014 um 12:10:
> Suppose I have
>
> cdef class Base:
>     cdef int foo()
>
> If I now create a derived class, should the "cdef int foo()" be repeated?

No.

> Is there even a difference between
>
> cdef class Derived(Base):
>     cdef int foo()
>     cdef int bar()
>
> and
>
> cdef class Derived(Base):
>     cdef int bar()

Yes. It's as in Python. If you redefine a method in a derived class, it
gets overwritten.

(If that's currently not the case in a Cython .pxd file, it's a bug.)

Note that if it is re-declared, they should agree. I've been fixing these in Sage: https://github.com/robertwb/sage/commit/8a45bd072afac01a63a12d38cc77f2f86055c9e6 

I might lean towards simply disallowing unnecessary re-declarations like this, but unfortunately it's been this way for a while: https://github.com/cython/cython/commit/a686fdc49d4813cfccd637697e6155b3e262bf6e (which happens to be the first modification ever). Then maybe we could finally get rid of https://github.com/cython/cython/commit/a48ee51299894459ef2d1f3e46698326a25093ed

- Robert

--

---
You received this message because you are subscribed to the Google Groups "cython-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cython-users+unsubscribe <at> googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Jeroen Demeyer | 17 Oct 15:52 2014
Picon

Optimal return type just for exception propagation

Hello,

I often find myself in the situation where I have a cdef function which 
shouldn't return anything (so "cdef void foo():" would be logical), 
however I do want to propagate exceptions.

What is the recommended return type then (assuming there is a 
recommendation)?

I guess a simple "cdef foo():" with a Python return value of Py_None in 
the non-exception case isn't optimal in terms of efficiency. Should I 
use "cdef int foo() except -1:" and rely on the fact that no return 
value means "return 0"?

I sometimes think we should have a special type "bvoid" or something, 
similar to "bint", which is a C int which is 0 if there was no exception 
and -1 on exception.

--

-- 

--- 
You received this message because you are subscribed to the Google Groups "cython-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cython-users+unsubscribe <at> googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Jeroen Demeyer | 17 Oct 12:10 2014
Picon

Repeating cdef declarations in derived classes

Suppose I have

cdef class Base:
     cdef int foo()

If I now create a derived class, should the "cdef int foo()" be 
repeated? Is there even a difference between

cdef class Derived(Base):
     cdef int foo()
     cdef int bar()

and

cdef class Derived(Base):
     cdef int bar()

--

-- 

--- 
You received this message because you are subscribed to the Google Groups "cython-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cython-users+unsubscribe <at> googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

george.trojan | 15 Oct 21:08 2014
Picon

fortran elemental functions

I a writing a Python module to access fortran library that has elemental functions. I came up with the following code (an example):

The library function is fthe(t, p)

I created a fortran wrapper:

! calculate equivalent potential temperature given temperature and
! pressure
subroutine c_fthe(t, nt, p, np, the, nthe) bind(c)
    integer(c_int), intent(in):: nt, np, nthe
    real(c_float), intent(in):: t(nt), p(np)
    real(c_float), intent(out):: the(nthe)
    real(krealfp):: pk(np)
    pk = fpkap(p)  ! another elemental function, not relevant to the discussion
    if (nt.eq.np) then
        the = fthe(t, pk)
    else if (nt.eq.1) then
        the = fthe(t(1), pk)
    else if (np.eq.1) then
        the = fthe(t, pk(1))
    end if
end subroutine

In *.pyx file I have

cdef extern void c_fthe(float *t, int *nt, float *pk, int *npk, float *the, int *nthe)

def pt2the(object p, object t):
    '''Compute equivalent potential temperature at the LCL
    from pressure and temperature.
   Temperature range is 183.16 to 303.16 Kelvin, pressure
    4000 to 110000 Pa.
    Input argument list:
        t:      LCL temperature in Kelvin
        p:      LCL pressure
    Returns equivalent potential temperature in Kelvin.
    Output values outside valid range are masked.
    '''
    t = np.clip(t, 183.16, 303.16)
    p = np.clip(p, 4.0e3, 1.1e5)
    return generic2arg(t, p, &c_fthe)

and the following monstrosity (generic3arg is much worse):

cdef generic2arg(object o1, object o2, f3arg f):
    cdef np.ndarray[np.float32_t, ndim=1, mode='c'] o1c, o2c, oc
    cdef int n1, n2, n
    n1 = o1.size
    n2 = o2.size
    mask1 = o1.mask if hasattr(o1, 'mask') else None
    mask2 = o2.mask if hasattr(o2, 'mask') else None
    mask = None
    if o1.shape == o2.shape:
        n = n1
        shape = o1.shape
        if mask1 is not None and mask2 is not None:
            # if objects are arrays, both must be masked or not masked
            mask = mask1 | mask2
    elif n1 == 1:
        n = n2
        shape = o2.shape
        mask = mask2
    elif n2 == 1:
        n = n1
        shape = o1.shape
        mask = mask1
    else:
        raise ValueError('Invalid dimensions: %d, %d' % (n1, n2))
    if shape == (0,):
        return np.array([], dtype=o1.dtype)
    o1c = np.ascontiguousarray(o1.ravel(), dtype=np.float32)
    o2c = np.ascontiguousarray(o2.ravel(), dtype=np.float32)
    oc = np.ascontiguousarray(np.zeros((n,)), dtype=np.float32)
    f(&o1c[0], &n1, &o2c[0], &n2, &oc[0], &n)
    if mask is not None:
        return np.ma.array(oc.reshape(shape), mask=mask)
    else:
        return oc.reshape(shape)

Is there a better way of handling this? I know C does not know about elemental functions. Googling for "cython fortran elemental functions" produced no hits.

George

--

---
You received this message because you are subscribed to the Google Groups "cython-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cython-users+unsubscribe <at> googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Gmane