Stefan Behnel wrote:
> Hi Dag,
>
> Dag Sverre Seljebotn wrote:
>> I guess it depends on the motivation. I'm sceptical of hit-or-miss
>> optimization in general -- that is, I don't think we can aim for
>> "magically optimizing" very much user code through single optimization
>> points like this. They are more for users who already know that their
>> code will be both interpreted in Python and compiled with Cython -- of
>> course, for such users an optimized izip could still be useful.
>
> Besides the obvious advantage of optimising Python code, I think even
> Cython code will benefit, as it's ugly when you have to unroll izip()
> yourself in your code. When you need that functionality, there should be no
> reason to work around it for performance reason.
>
>
>> I think my opinion is that I'd like to see this split this into a couple
>> of orthogonal and generic features:
>>
>> a) Auto-cimport (if a directive is set, which defaults to on?). I.e. if
>> you do a Python import, and a pxd file can be found, a cimport is done
>> automatically.
>
> +0.7 given that this may really have a performance impact, as Robert
> stated. There should at least be a cache for the standard include path that
> survives multiple compilations in one compiler run (another orthogonal
> feature that would be nice for .pxd files in general).
with cython.nopxd:
import mymodule
?
It works just fine in Python :-)
Sage would likely just do --directive nopxd=True.
(The default can be discussed once the feature is actually there I suppose).
>> b) Overloading combined with fall-through to Python space. I started a
>> CEP on this [1], Robert discussed it with me, but it never got finished.
>>
>> One way is to allow e.g. (in "math.pxd")
>>
>> double sin(double x): return libc.math.sin(x)
>> object sin(object x)
>
> +1, nice feature.
>
>
>> Somehow it must be added here though that sin should be looked up at
>> module initialization using getattr rather than through
>> __pyx_capi/Cython call convention.
>
> That would be implied by the fact that you used a Python import. But
> leaving this to the poor importer might turn out to be error prone, given
> that the math module actually is a C extension...
-1 on leaving it to importer; I'd like to use "import" to cimport Cython
extensions too! Lower learning curve etc.
This could actually be done at runtime. Support code:
static PyObject* math_sin_looked_up_with_getattr = NULL;
static PyObject* math_sin_with_getattr(PyObject* obj) {
/* call math_sin_looked_up_with_getattr using CPython API */
}
In module initialization:
if hasattr(math module, "__pyx_capi"):
set math_sin as today
else:
look up and set math_sin_looked_up_with_getattr
set math_sin to math_sin_with_getattr
Then, call math_sin as today in general.
The minus is that it blows up code size somewhat for cimported Cython
modules; new syntax would avoid that.
--
Dag Sverre
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
