Stefan Behnel wrote:
>
> Robert Bradshaw wrote:
> > - Having an except [uncommon value]? by default on all implemented
> > functions.
>
> I first thought about that as a door opener for performance problems, but I
> actually think most functions forward exceptions anyway, so this won't change
> much in that regard.
I'm not sure I like this idea. Most functions from external
C libraries will not be raising exceptions, so if you don't
want performance penalties and code bloat when calling those,
you would have to make a distinction between Cython-implemented
functions and extern ones.
This would be a major conceptual change, as there is currently
no such distinction -- a given function signature always means
the same thing however the function is implemented. I'm
worried that this would lead to confusion.
>
> One thing I'd add is an optimisation for normal object-returning functions
> that do not have a return statement, i.e. that do not really return anything
> but exceptions. Here, we could change the signature internally to returning a
> bint instead
This would mean that you wouldn't be able to determine the
return type of a function from looking at its header, as it
would depend on what goes on in the body. How would you tell
from an extern declaration or a declaration in a .pxd file how
to call such a function?
However, it might be feasible to have a special return type
that you can explicitly use in that case, such as
cdef errflag foo():
...
where errflag is equivalent to int except that it implicitly
has an error return value of -1. (I don't really like the
name 'errflag' much, but I can't think of anything better
off the top of my head.)
> Why? Do you mean "dependency tree" in terms of files depending on each other?
> Greg's .dep files would handle that...
The problem is that if you're using timestamps to tell when
things need to be recompiled, then *any* change to the .pyx
file will trigger recompilation of everything that imports
from it, whether the change affects the external interface
or not.
To avoid that, you would have to perform some sort of
analysis to compare the current interface with what it
had last time it was compiled, which could become tricky
depending on what level of false positives you're willing
to accept.
This may also have a bearing on the import/cimport
distinction. Currently, a cimport implies interface
dependency, whereas an import doesn't. If you merge them,
you will have to take note of what kinds of things are
being imported to determine whether an interface
dependency exists.
Another advantage of explicit .pxd files is that it's
always clear when you're changing the interface and
when you aren't. You know that nothing you do to a
.pxd file can change the interface, which can be
important when other people are using your module.
--
Greg
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
