I agree with Chris, this certainly looks like an architecture clash. The same sort of thing happens on Windows (complains about the .dll instead of the .so) when you are attempting 64-bit package with 32-bit python or vice versa.
Another symptom of this architecture clash (on Windows) is when the installer can't find python in the registry. If you install anyway, by pointing the installer to the desired python installation, then you next get the message (upon import) that it can't find the dll or load the dll, etc. It has been my experience that you have to really closely follow the explicit (and implicit!) compatibility instructions for python packages and bindings. I have about six installations on my machine for this reason (32-bit Py2.5, 64-bit Py2.7, 32-bit Py2.7, 32-bit Py3.1, etc) because package x.1.5 is only compatible with external tool y.8.3 and then you have to choose the version of the package which is designed to work with your python version (or install a new python version) and they also all have to be the same architecture (32-bit or 64-bit). AMD vs Intel may be a problem also, though some packages labeled AMD have worked on intel as long as everything is 64-bit. Some packages are labeled AMD but if you read the fine-print it says they work on Intel as well. So, my new policy is never install 64-bit python unless I need really large files (4GB). I'm not sure if there are other reasons to desire 64-bit python besides the larger address space, but what I have found is there are lots of problems with packages not being 64-bit compatible so much safer to go with the 32-bit solution for most purposes. Originally I was using 64-bit packages just because I had a 64-bit architecture but now I see this is not as sensible as I originally assumed. Good luck! Best regards, Melissa ----- Dr. Melissa Rice, PhD Full Moon Technical Solutions, LLC 14202 60th Ave, NW Stanwood, WA 98292-4808 email: mailto:[email protected] phone: 360-654-0709 cell: 425-923-7713 Thursday, December 9, 2010, 11:40:06 AM, Richard Fuhr <[email protected]> wrote: After installing the Mac distribution of wx for Python 2.7, which is called wxPython2.8-osx-unicode-2.8.11.0-universal-py2.7.dmg I got the following, upon launching python 2.7.1 and importing wx. Instead of pursuing the problem in any detail, I just downloaded and installed wx for Python 2.6 and it seems to work fine. But, for reference, here is the transcript of my Python 2.7 session. Richard-Fuhrs-iMac:~ richardfuhr$ python Python 2.7.1 (r271:86882M, Nov 30 2010, 10:35:34) [GCC 4.2.1 (Apple Inc. build 5664)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import wx Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/usr/local/lib/wxPython-unicode-2.8.11.0/lib/python2.7/site-packages/wx-2.8-mac-unicode/wx/__init__.py", line 45, in <module> from wx._core import * File "/usr/local/lib/wxPython-unicode-2.8.11.0/lib/python2.7/site-packages/wx-2.8-mac-unicode/wx/_core.py", line 4, in <module> import _core_ ImportError: dlopen(/usr/local/lib/wxPython-unicode-2.8.11.0/lib/python2.7/site-packages/wx-2.8-mac-unicode/wx/_core_.so, 2): no suitable image found. Did find: /usr/local/lib/wxPython-unicode-2.8.11.0/lib/python2.7/site-packages/wx-2.8-mac-unicode/wx/_core_.so: no matching architecture in universal wrapper On Thu, Dec 9, 2010 at 11:19 AM, Christopher Barker <[email protected]> wrote: On 12/9/10 11:02 AM, Richard Fuhr wrote: that enabled the user to explore some of the properties of Bezier and spline curves. OK -- so you really do need "real" Bezier cublic splines. Now it is time to implement the graphics and a GUI, and I am looking for the following: * APIs that draw cubic Bezier curves ( or several cubic Bezier curves joined together ) ideally without requiring the programmer to implement a linear approximation of the curves (and it looks like wxPython is quite suitable) yup -- wx.GraphicsContext should do that fine. * GUI functionality that responds to mouse down, mouse moved, and mouse up events, so that the user can drag around control points ( represented by circles on the canvas ) and thus modify the curve. None of that interaction comes out of the box with wx. My FloatCanvas would make that pretty easy, once you added the Spline. See the demos that come with the source code in SVN, in particular PolyEditor.py FloatCanvas2 might make it even easier, but I'm not very familiar with that one -- you might try out its demo -- there's a lot of stuff in there. Also -- at one point, it didn't render right on OS-X -- I'm not sure where that's at. A question to the FloatCanvas list should get you an answer. I have just started to explore wxPython today, so this is all still new. I had trouble getting the Python 2.7 wx to work, What were your troubles? I haven't tried 2.7 yet, but it *should* work. Have you posted to the wxyPython list with a questions/bug report? but have downloaded and installed the Python 2.6 version, which is working. which is fine anyway. -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]
