On Jun 17, 2008, at 5:49 PM, Greg Ewing wrote: > 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.
Yep, I think that is a distinction I am willing to make. This is why I said "all implemented functions" rather than "all [defined] functions." > 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. The current behavior leads to confusion too. > >> >> 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? I agree. > 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.) I don't like errflag either--in that case why not explicitly make it int? >> 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. No false positives. > 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. We will surely keep explicit .pxd files around for Sage for these reasons. It's more work (by the compiler) for less work on the user's end. - Robert _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
