> I can't help you, but: If not much is assumed at the moment, my vote is > to be able to start assuming stuff (and that the backwards compatability > breakage is a sacrifice one can make). > > Basically, if a pxd and a Python module has the same name, assume that > the pxd file is written with detailed knowledge of what goes on in the > Python module, and exists to provide hints to Cython about faster execution.
This is what I'm hoping everyone agrees on. :) > But one can still do import tricks etc., as long as the pxd file written > is written with knowledge about it. > True. I was more worried about the case that we were overstepping our bounds: I was imagining a "stub" implementation of some class (i.e. all functions just return None), along with the corresponding .pxd, and that (based on some flag or the like) which module was actually loaded would change at runtime. In this case, if we analyzed the stub module, we'd get a bunch of type information that would be *incorrect* at runtime. I don't know of a system using Cython that does this, but it sounds perfectly plausible ... > Hmm. In my experience the return value of functions is much more > important though, and how can one possibly get those through > introspection? So I'm unsure about the gain... > I guess I'm not sure what you mean by introspection here. I was thinking of being able to decorate imports in a .pyx file (or even .py or .pxd, really) to say "go ahead and analyze these at compile-time," specifically to do things like determine return types. It's true that in many cases you couldn't come up with much ... it's definitely something we'd want as an "opt-in" thing, because it could be extremely expensive for little gain. > This is more in a grey zone, because there's a long tradition of making > standalone C files which can be compiled on any system independent of > the exact installed version of the Python library (at least, with a pxd > file, there's a human to make conscious decisions about everything). > True -- this would mean that certain changes to the .py files that get imported would require calling Cython again to regenerate the C files. > But I'm usually not opposed to directives that are off by default... > This would *definitely* be off by default. Accidentally analyzing the whole python standard library because of an "import urllib, distutils" would *not* make us a lot of friends. ;) -cc _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
