Robert Kern wrote: > Christopher Barker wrote: >> agreed, though I may never use the stuff used to process XML docs, but >> it gets first class treatment... > > There really isn't any special "stuff used to process XML docs" in Cython. > There > is special stuff in Cython to interact with numpy arrays.
I never used the term "special". My point was that for many users, working with numpy arrays may be just as or more important that python strings (or even lists, etc.) As I see it, the only thing "special" about numpy arrays is that they are not part of the standard library (which I think they should be) -- but they are part of the standard Cython distro. Robert Bradshaw wrote: >>> Then you have any kind of wrappers around native libraries. >> yes, but if those native libraries are working with arrays of data, >> numpy may well be a good idea there, too. > > I would say that most (non-scientific) libraries don't work with > arrays of data. It might be interesting to do a survey, but I can, off the top of my head, think of a couple broad categories that I've worked with: - text-oriented : not numpy - image processing: numpy could/should play a role here - scientific/numerical: duh! - GUI: numpy could/should play a role here, too. mainly for graphics, etc. - GIS: numpy does/could/should play a role here, too. As an example, if pyOpenGL didn't work with numpy arrays, it would be crippled -- or it would have to provide its own data types for storing/manipulating big blocks of data. Any C library is going to work with one or both of two things: text and numbers -- what fraction of libs only work with text? Of course, what I'm really doing here is advocating for an nd-array in the standard lib... > Maybe something like > > Intro > - Brief overview of what Cython is (and is not) > - Building (very simple example, setup.py) -- note that this can be > skipped if using the sage notebook. (Eventually it might be good to > have a link right to the sage notebook for people to try all the > examples out--the setup can be a hurdle, and this gives people a > chance to see how easy and powerful it is to have motivation to > actually set it up on their machines). Sage is wonderful, but I'd not like to see it get too tied into Cython... > - Basics cdef variables, methods(?), and types. cython -a > > All of the above is essential to any use of Cython. We could then > dive into topic-specific tutorials, specifically: > > - NumPy -- this would be the SciPy paper, minus intro stuff > - Calling and wrapping external libraries > - Creating extension classes > - String processing > - Advanced topics (for...from, include, .pxd files) > - Common pitfalls > - Pure mode > - ??? > > All of the above would assume only the background of the (shortish) > intro chapter(s), and be relatively self-contained. Yes, this is a great outline! I think it accomplished what I was getting at -- a short path from newbie to working with numpy arrays, but also an equally short path to working with strings, etc. A new user is likely to come to Cython with a particular problem to solve, and this looks like a good structure to get them there quickly. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception [email protected] _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
