wxPython GUI killed by enthought - python

I am writing a wxPython GUI. For certain functionality this requires that I use the Enthought distribution of python, but when I upgraded to Canopy it completely breaks my GUI. When I call up a certain window, everything freezes and I have to force quit. I don't get any kind of error message or traceback, just a freeze.
I am using the 64 bit Canopy, version 1.4.0.1938, and wxPython 2.9.2.4.
I am looking for either of two kinds of advice. 1. What is a good debugging protocol in this kind of situation? 2. How to get wxPython and Canopy to play nice?
I greatly appreciate any suggestions. I am happy to include any code that might be helpful, but I suspect that this is not particularly specific to my code.
edit:
I need the Enthought distribution specifically because my GUI builds on older code that uses some of the data analysis and plotting that EPD provides. This GUI actually incorporates and streamlines several older GUIs for analyzing paleomagnetic data.

This question is inaccurately titled and both your question and your own answer to it are inaccurate and incomplete. On the evidence, and from your comments on the Enthought knowledge base, your problem is twofold:
1) You want to use WXPython 2.8 in 64-bit Python on OSX. This is a fundamental technical impossibility because WxPython 2.8 uses Carbon OSX graphics, which is not supported for OSX 64-bit programs.
2) Failing that, you expect your program to run unmodified with WxPython 2.9 but apparently you have not taken any steps to migrate it to WxPython 2.9. See http://wxpython.org/migrationguide.php.

(Edited 5/6/2014)
My temporary solution was installing the 32 bit version of Canopy and then using the Package Manager to install an older version of wxPython (2.8.10.1). This worked temporarily, until I was able to get to the actual cause of the error.
https://support.enthought.com/entries/22601196-wxPython?page=1#post_22146884
The real problem did indeed turn out to be the version of wxPython.
The specific issue was calling ShowModal() instead of simply Show() for the main window of the GUI, which apparently worked in wxPython 2.8 but caused a freeze in 2.9. The code now thankfully works with 64 bit Canopy. Thanks to Jonathan March for pointing me in the right direction.

Related

New version Python running on Old version Python TKINTER & TURTLE

So I have an application that uses Turtle (because its built in)... Runs perfectly, like 100 people are needing it and wanting to run it across many organizations. It was written in version 3.6.5. However these organizations have much older version 3.4.1 is one of them. I can't share the code, nor can they easily upgrade their version in a timely manner....
The screen on their version opens and quickly closes, but in the 3.6.5 version it works perfectly.
My Question is: What are some clues to look for a work around, or to trouble shoot the differences between these versions for tkinter --> turtle ?
Thanks in andvance.

Handling multiple python distributions

I guess I am partly responsible for the mess, but I can imagine that several users might have similar problems. I installed several python versions/distributions on my new Ubuntu-Gnome 13.04, which comes with python3.3 (0), including
python2.7.5
PyLab (python2.7.3)
EPD-python2.7.3
Canopy-1.1.0 (??)
Anaconda 1.6.1 (python2.7.5)
My main purpose for doing so was to get a python environment with the functionality of the Qt-console, which previously worked perfectly with the EPD-python distribution.
I now encountered several problems with basically all of the above. "Plain" pythons, such as 0, 1 and 2 do not offer the functionality I desire, while the others have their problems by their own, and I hope somebody knows to help here:
3: When starting the Qt-console shipped with the EPD-python distribution (installation worked perfectly fine), it cannot load the graphics package Matplotlib anymore, telling me
ImportError: Matplotlib backend_wx and backend_wxagg require wxPython >=2.8
Error initializing pylab, pylab mode will not be active
Manually importing does also not work. Why doesn't it work by itself as a stand-alone version, but requires a python version which is higher than the one EPD installed.
4: Cannot figure out how to use Canopy within a Qt-console or use the GUI for multi-tasking, i.e. multiple kernels. I previously addressed this issue here: Multiple kernels in Enthought Canopy.
5: Anaconda should also have an Qt-console. But after installing it, I cannot find any application relating to it. The only thing I can do is to run it in the terminal, either as normal python or ipython (the same I can do with EPD-python as well). It seems that this is not the full functionality of Anaconda, but I might be wrong here.
Any help is appreciated!!
BTW, can one make all these python communicate with each other and make them somehow "harmonise"?

Building PyGTK- and poppler-based binaries under Windows

For quite some time now, I've been fighting in vain to get a software I'm working on to work under Windows. It's written in Python (the 2.x series), and although all Linux users can benefit from its GUI when they use the source package, it seems that many people who download it go for the Windows package, for which I've only been able to provide command-line binaries.
The GUI was built using Glade/GTK, and uses poppler to embed a PDF viewer. I've found various howto's in the past (I don't have them at hand right now, sorry), which I've tried to follow religiously, but I never got things to work at all.
So, is there a reliable tutorial explaining exactly how to install the needed libraries (GTK and Poppler), so that I can build the corresponding binaries for my users?
There is a window installer here: http://download.gnome.org/binaries/win32/pygtk/2.22/

CPython vs. Jython vs. IronPython for cross-platform GUI development [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I'm thinking of making some kind of experimental IDE for digital hardware design. So I can't decide witch platform to choose.
I'm going to have text-editor with syntax highlighting, some vector graphics and lots of tabbed windows.
My goals:
1. to make GUI using as less custom components as possible.
2. to make it as cross-platform as possible
(I know already that CPython and Jython are cross-platform-friendly, but what about IronPython+Mono?)
So - the question is about GUI - what should I choose?
IronPython with Mono is cross platform - to whatever platforms supported by Mono, and for the feature set supported by Mono (which pretty much means Windows Forms is supported fairly well). Other options for GUI toolkits are available, however, which may provide better "cross platform" capabilities, or at least a better feel on non-Windows platforms.
CPython will depend on the GUI suite you choose. Personally, I've found CPython with PyQt to be the most usable, cross platform GUI option from Python. It's very powerful, feature-rich, and works quite well.
Jython will work, but I personally don't like the GUI options as much (this is a 100% personal preference, however).
I'd say that if cross-platform is a goal, forget IronPython. A lot of people hate the dependency hell it causes so it'll be too much work to get it up in running in some OSes/distributions. Jython will suffer this also, albeit to a lesser degree.
Well, Mono does not come with the base of most Linux distributions. It's not a terribly lightweight dependency either, and I think Java is considerably more likely for people to already have. Would you plan on using "Winforms" with Mono? If so, and you don't have experience with Winforms, read about what others have to say :-) The other .NET GUI toolkit is WPF, which unfortunately Mono has no plans to implement.
Jython would be better too, because you can use SWT, which renders native widgets and provides lots of layout possibilities easily. Or you can use Jython with Swing, or whatever else -- even AWT if you love ugliness.
I really like wxPython (which you can use with CPython, which is on most distros by default), because it renders good-looking native widgets in OSX, Windows and Linux (I've only seen the Gnome widgets in person). wxPython is by far the easiest to use GUI toolkit I've used -- even programatically (i.e. layout without Glade or similar). I've also used SWT, which I found quite nice, and Swing, which I personally don't really like the looks of, and Winforms, which was a nightmare to try to do even simple layouts with.
Here's a quick comparison of the existence of the interpreter/language runtime by OS
CPython
Windows - Probably not installed, and you'd have to make a non-python installer install it with your software :-P
Linux - Probably installed (Ubuntu, Gentoo and RedHat all have system tools that are written in Python and run on CPython)
Mac - Preinstalled on OSX
Jython
Windows - Probably installed at some point in my experience, though it doesn't come with
Linux - Probably installed, but more importantly nobody would hate you for depending on it like Mono
Mac - Preinstalled on OSX ("Mac OS X Leopard comes with J2SE 5.0 preinstalled, based on JDK 1.5.0_13_b05" -- Apple's site)
IronPython
Windows - Will probably run fine because I bet most people have at the very least .NET 2.0 if they have a recent version of Windows
Linux - Probably not installed -- the only application with which I've used Mono on Linux was Rasterbator, which worked well but I felt weird putting .NET on Linux
Mac - See above
I would choose a GUI toolkit first, since that will very much impact the user experience and overall difficulty (I would choose wxPython but SWT would be a close second) then consider the above as well maybe as a tiebreaker.
I faced this same question roughly a year ago. After looking at all the alternatives, I ended up with CPython and PyQt. IMO, Qt/PyQt is by far the best choice amongst all of the Python GUI toolkits. After hitting many bugs in wxPython I switched to PyQt and never looked back. Qt/PyQt are much more solid than the wx toolkits in my experience.
I use the exact same code base and build stand alone executables with PyInstaller for Windows and Py2App for the Mac (PyInstaller can be used for Linux as well). Because these builders embed the Python interpreter and all of the dependencies, it takes a lot of the hassle away. The only rub is that you'll need both a Windows and Mac to do the builds. Getting all of the configurations correct can be a pain too, but it's possible and time worth investing.
Take a look at comparable GUI's written in python/jython/ironpython. Look for programs that you like and find out what they use. I guess most if not all will be written in cpython + gtk or cpython + qt. I think all gui toolkits in python are cross platform.
Java is the most portable platform. Jython is written in 100% pure Java. 'Nuff said.
BTW I just switched a CPython/GTK project to Jython (trying to remove as much unmanaged code as possible), the only problem is that Jython is at 2.5 still, which kind of sucks when you're used to 2.6/2.7/3 :)
There are plenty of answers already, but I'd like to add one important thing - regardless of which library you learn, most of the principles will be the same when you move to another library.
I don't know about Qt, but for most graphics programs (in PyGTK or Tkinter) the best thing to do, as far as editing goes, is to use a PIL image (or something similar) to draw on and then draw that image on your canvas widget, otherwise you can lose pixel data if your window gets covered.
You may use Python 2.7 or 3.1 (CPython) with ttk (in Standart Library in 2.7, 3.1), ttk support themes (looks nice and very simple coding)
(1-st screen is text-editor with tabs and syntax highlighting) ttk screenshots

OpenGL in Python with Snow Leopard?

I'm interested in playing around with OpenGL in Python. I've used OpenGL in C++ and Objective-C, but I don't have much experience in Python. I'm wondering if there's a good tutorial that works in Snow Leopard. I'd prefer to stay in 64-bit mode if possible, since I've heard 32-bit programs require loading a lot of extra 32-bit libraries.
I've already tried a PyOpenGL/wxPython tutorial. When I ran the code, it crashed with this message:
ImportError: /System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/wx-2.8-mac-unicode/wx/_core_.so: no appropriate 64-bit architecture (see "man python" for running in 32-bit mode)
It looks like there's a bug in wxPython that prevents it from working on a 64-bit system.
I also looked at Pyglet, but they have a similar issue. They provide a work-around (setting Python to 32-bit mode), but it doesn't look like they're going to fix it.
Finally, I looked at PyGLUT, but I think it's only for Windows.
Are there any other libraries that would let me access OpenGL and draw on the screen? Again, I'd prefer to stay in 64-bit mode, but if nothing works, I'll switch to 32-bit and try wxPython or Pyglet again.
Edit: I've also tried PyGame. It depends on SDL which is broken in SL. I thought about trying to use Cocoa through PyObjc, but the Xcode Python application templates have been removed.
I've used PyOpenGL 3.0.0 quite successfully on Snow Leopard. It uses ctypes, so it should be making 64-bit calls if those libraries are available (and Snow Leopard's Python includes a 64-bit version). I haven't used the wxPython stuff with PyOpenGL so that's where you might be running into problems, but PyOpenGL also includes GLUT, which both run fine.
There's probably no good reason to avoid 32-bit mode. Unless your Python programs need to larger address space, of course.
You could try pygame. Pygame is a python wrapper around SDL. According to their website they have Max OS X binaries. Here is a simple example of using pygame with OpenGL. Once you are able to create the window and handle events most OpenGL programming is just like it would be in C or C++, but with some added python goodness. For OpenGL a great tutorial is NeHe.
Also when programing with OpenGL in python remember that Python datastructures can be rather slow when it comes to requirements for 3D graphics. PyGL developers for example recommend using ctypes for operations that concern graphics, since that way you can get enough performance for some complicated geometry with bareable FPS.

Categories