I think A is quite acceptable (and probably a good idea). Anytime I hear "very contrived" in the design phase I get worried, so I don't like B. I think C might make a good topic to talk about eventually, but I think it is far more important to get numpy support in now (without worrying about optimization at all). Making C happen will probably require some design changes in Cython, so it is important in my book to define a public API to the parse tree and not let plugins poke around and do whatever they want.
On 3/15/08, Dag Sverre Seljebotn <[EMAIL PROTECTED]> wrote: > > > Having a full python interperter around to get around the fact that we > > don't have decent dependencies is almost certainly not the way to do > > this. My dislike of parse tree optimizations mainly centers around > > using it for very complicated things that can be much better served by > > other algorithms. > > > I'll admit (as you've probably concluded) that I'm out of my field of > knowledge here. Still, seeing that you don't think my hack isn't ideal, > what do you think would be the best way forward to get clean NumPy > integration in, say, six weeks of full-time work by somebody who has no > experience with compilers, but knows programming and text-book algorithms > well? > > a) Custom plugin doing custom NumPy rewrites on the parse tree. (Easily > done in one week for that matter...) > b) Find a (very contrived) declarative syntax instead of Cython function > calls for making the kind of code we need > c) Just forget it, and start the long route of figuring out dependencies > etc. towards a full-fledged optimizing compiler. > > I sort of figured my hack could provide a quick way forward... > > (BTW, reading books on compiler design would be an option.) > > > Dag Sverre > > _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
