Tim Hochberg wrote:
but I believe that wxPoints now obey the PySequence protocol, so I think that the whole wxPySwigInstance_Check branch could be removed. To get that into wxPython you'd probably have to convince Robin that it wouldn't hurt the speed of list of wxPoints unduly.
Wait... If the above doesn't work, I think I do have a way that might work for speeding the check for a wxPoint. Before the loop starts, get a pointer to wx.core.Point (the class for wxPoints these days) and call it wxPoint_Type. Then just use for the check: o->ob_type == &wxPoint_Type Worth a try anyway.
Unfortunately, I don't have any time to try any of this out right now.
Chris, are you feeling bored?
Do you mean me? if so: A) I'm not bored. B) This is all kind of beyond me anyway, and C) I'm planning on implementing my own custom DC.DrawLotsOfStuff code, because I have some specialized needs that probably don't really belong in wxPython. My stuff will take Numeric arrays as input (This is for my FloatCanvas, if anyone cares). I'm still using Numeric, as numarray is a LOT slower when used in FloatCanvas, probably because I do a lot with small arrays, and maybe because of what we're talking about here as well.
However, This may turn out to be important to me some day, so who knows? I'll keep this note around.
What's the chance of adding direct support for numarray to wxPython? Our PEP reduces the burden on a package to at worst adding 3 include files for numarray plus the specialized package code. With those files, the package can be compiled by users without numarray and also run without numarray, but would receive a real boost for people willing to install numarray since the sequence protocol could be bypassed.
If the PEP is accepted, and those include files are part of the standard Python distro, I suspect Robin would be quite happy to add direct support, at least if someone else writes the code.
Whether he'd be open to including those files in the wxPython distribution itself, I don't know. Perhaps I'll drop him a line.