On Jun 16, 2008, at 11:23 PM, Stefan Behnel wrote: > 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,
Dag can't write a single line of code on that front here for tax reasons, so it'll definitely have time to stew a while. The assumption/inline pxd stuff is powerful and nice, but is not quite enough (one problem is gcc aliasing needs to be on, which limits performance improvements) and less feasible. > I think this might be worth a read: > > http://blog.red-bean.com/sussman/?p=96 Interesting read. > > >> 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. Yep, and it'll save a lot of pain for programmers. > 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. That is a good idea, though might mess up the signature (e.g. for cdef methods that may be overridden). >> - 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. +1 > 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. I imagine we would want to cache this, perhaps in an easier to parse format that .pxds are now (as parsing them can take a while too). > > >> 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... There are several ways it becomes tighter. First, one can import rather than cimport when one doesn't need speed and doesn't want to create a compile-time dependancy (e.g. like in a huge project like Sage). Secondly, everything in the file gets cimported, not just the interface exposed by the .pxd. Thirdly, any time the .pyx file changes, it needs to be checked (instead of only on .pxd changes). These costs are wroth it I think for "normal" behavior, and power- users with 100s of interdependent files can disable them. - Robert _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
