Hi, Robert Bradshaw wrote: > These last couple of days we have appreciated having Dag Sverre > Seljebotn and Dan Gindikin (the creator of Pex) around, and have had > a lot of discussions (if not yet a lot of code).
A good design is sometimes worth a thousand lines of code. I'll first have to read a bit closer through the PEX page and Dag's buffer proposal before I can comment on it, but it looks interesting if not more. BTW, before the code gets written (or migrated or whatever) and reviewed, I think this might be worth a read: http://blog.red-bean.com/sussman/?p=96 > The biggest proposals for change are: > > - 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. 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 (normal return or exception), which avoids the INCREF/DECREF None overhead for the return value. > - Phasing out cimport, letting import be cimport whenever the > relevant header files are found. That's an interesting idea. And it might open up some advanced optimisations for normal Python code, too. Think of plain Python code accompanied by a .pxd file where Python would use the normal .py module and Cython would see both the .py and the .pxd file. We could even allow function signature overrides specifically for .py files when we find a .pxd file. We might want to output something from the compiler though, to tell users what was imported at compile time and what was left to runtime. For them, it might or might not be an error when things aren't found at compile time. OTOH, Cython might be able to determine errors from the code it sees anyway. For example, a "cdef class" with an unknown but imported base class is definitely an error. > - Using the .pyx file for "cimport" when a .pxd file is unavailable > (basically auto-generation of pxd files). I'm not so sure about that one. This basically means cimporting from .pyx files, which might really lead to a performance drop of the compiler (remember that the slowest thing is still the scanner). I see that it goes somewhat hand in hand with the "cimport imports" change above, and I also see that it's easy to work around by actually providing .pxd files. So maybe this is really a non-issue. > These last two have the disadvantage that the dependancy tree could > become much more connected, so we would provide a way to disable > them. Thoughts? Why? Do you mean "dependency tree" in terms of files depending on each other? Greg's .dep files would handle that... Stefan _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
