I have EPD 7.3 and have installed wxPython 2.9 through the Enthought repositories. I tried running winPDB, which requires wxPython and I got this message :
This program needs access to the screen.
Please run with a Framework build of python, and only when you are
logged in on the main display of your Mac.
I have seen similar messages from wxPython on Mac, but I haven't found a solution yet. Does anyone know about this message? And, has anyone got WinPDB to work on OS X 10.8 w/ wxPython 2.9?
This error message will happen when the Python used to run a wxPython script is not a full framework build. OSX requires that applications that are given full access the screen be run from an application bundle or are part of a framework.
Usually all Pythons are framework builds these days and there is no need to worry about this any more, however there is one situation where it is still an issue, and that is with virtualenv or similar tools. With the way that the virtualenv is constructed the Python that is there sort of loses its connection with the framework that it comes from, and so using it directly triggers that security mechanism and the wx code is not able to get full access to the screen. If you are experiencing a problem in a virtualenv then I've written up a workaround here: http://wiki.wxpython.org/wxPythonVirtualenvOnMac
Hmm... I just went to double-check this with EPD and I found that the "python" executable they provide is not a front-end for the Python.app binary like in normal framework builds, but is more like a normal unixy Python. Since I'm at Enthought now I'll ask the responsible parties if this is a bug or is intended, but in the meantime you can work around this by changing which Python is being executed. For example, you could create a "pythonw" alias in your bash shell that points to the Python.app binary, like this:
alias pythonw=/Library/Frameworks/EPD64.framework/Versions/7.3/Resources/Python.app/Contents/MacOS/Python
Then you should be able to run WinPDB or other wxPython applications by using pythonw instead of python.
Related
I'm new to programming and to be more specific, Python. I was going through the installation process from Robert Sedgewick's Introduction to Programming in Python website until right before the section "Downloading and Installing the Booksite Library". My problem occurred with:
In the Terminal window issue the command idleX.Y (for example, idle2.7). If an IDLE window appears, then you have installed IDLE properly. Close the IDLE window.
As I was installing Python 2.7, I attempted to use the command idle2.7, but I received the following response. As far as I can tell, I followed all of the directions provided by Mr. Sedgewick's website and I have already verified that Python was being installed as version 2.7.10. After looking for answers online, I found a similar one here on Stack Overflow. Unfortunately, the potential solutions listed for that question didn't help resolve my issue. At this point, I should mention that I am trying this on a MacBook Pro (2015 model) running the latest version of OS X (El Capitan).
Thanks for your help!
For 2.7, the following, where 'python' is 'whatever string needed to start 2.7' (perhaps 'python', perhaps 'python2'), should work on any OS:
python -m idlelib.idle
For 3.x, .idle can be omitted. In *nix (but not on Windows), python should probably be replaced by python3. The usability of shortcut scripts such as 'idle2.7' depends on the script being both present and on the executable path. That, in turn, depends on the specific installers. In the last year, Python core developers have veered away from the use of a multiplicity of short-cut scripts, which are not dependable, toward python -m module, which is dependable as long as one can start a particular version of Python. On Windows and, I believe on Mac, after using the PSF installers, python can be replaced by py -x or py -x.y if one has multiple python installations.
I've been looking for a GUI system for python applications for a while and have found these 2, Tkinter and PyQT. The issue I'm having is that I cannot work out whether PyQT requires the end user to have QT installed and whether Tkinter will work properly on another computer as I have read a lot about it being touchy when it comes to Tk/Tcl version.
What I'm trying to do with it is create an application for a friend so that he can keep track of his beehives more easily and I didn't think that having it in a terminal would be the way to go. Thanks.
I have worked with both in the past and from my observations:
whether PyQT requires the end user to have QT installed
Yes, it does. However you can bundle your app along with the dependencies (Python + QT) using tools like PyInstaller. You will get a single package that you can distribute to your users. They can run it without installing anything.
You can also create custom installers which install Python and QT on the target systems for you. Then the users can just run the Python script.
whether Tkinter will properly on another computer as I have read a lot
about it being touchy when it comes to Tk/Tcl version
I have never faced any issues with it since I mostly deployed my Tkinter apps to Windows and I installed the same version of Python on the target systems that I used to develop. However, there might be version conflicts on other platforms (eg. Linux/OS X).
What I'm tying to do with it is create an application for a friend so
that he can keep track of his beehives more easily
Have you thought about web based GUI? A python script running a webserver on a local machine? You can use the "webbrowser" module to open up a browser to load the url when the script is run.
There is another alternative: Kivy.
So I'm testing out the SPy library in Anaconda's Spyder, and have run into a strange error:
SystemExit: This program needs access to the screen.
Please run with a Framework build of python, and only when you are
logged in on the main display of your Mac.
This happens when I try to call the view_cube command from Spectral Python (SPy), which requires wxPython.
I have a feeling that this is related to Spyder's displaying of all the images generated by my program in its onboard console, instead of in independent windows.
How can I fix this error, and is there a way to tell Spyder to display images in their own windows? Can I run a "Framework Build" within Spyder?
EDIT:
I was able to display the resulting images in separate windows by going to Preferences > IPython console > Graphics, and setting Backend to Mac OSX. However, the error when trying to run the view_cube command still persists...
I expect you're using the system version of python that comes installed on mac by default, which isn't a framework build.
You'll want to install a version of python from python.org which are all framework builds. I expect you'll want the latest version of python 2. You will also have to install your dependancies again against this new python install.
I'm writing a program in python using PySide(PyQt) and I want to distribute it to friends and family when I'm finished. I have looked at other posts in stack overflow, but I can't seem to find any good ones showing an easy solution(command line or otherwise) that will create an executable for my program to be run on other computers who don't have python or Qt etc. I'm running Ubuntu right now, however I would like to be able to package for windows as well.
Edit: I wrote all the Qt interface in my python script, so the whole project is contained in the one script.
I have used PyInstaller to create executables for scripts using PyQt4 under Windows without any trouble. Though I have not used it on Linux, it claims Linux (and OSX) support as well. You may need to create your Windows binaries in a Windows system or through Wine according to the FAQ:
Can I package Windows binaries while running under Linux?
No, this
is not supported. Please use Wine for this, PyInstaller runs fine in
Wine. You may also want to have a look at this thread in the
mailinglist. In version 1.4 we had build in some support for this, but
it showed to work only half. It would require some Windows system on
another partition and would only work for pure Python programs. As
soon as you want a decent GUI (gtk, qt, wx), you would need to install
Windows libraries anyhow. So it's much easier to just use Wine.
I have a lovely Macbook now, and I'm enjoying coding on the move. I'm also enjoying coding in Python. However, I'd like to distribute the end result to friends using Windows, as an executable.
I know that Py2Exe does this, but I don't know how portable Python is across operating systems. Can anyone offer any advice? I'm using PyGame too.
Many thanks
The Python scripts are reasonably portable, as long as the interpreter and relevant libraries are installed. Generated .exe and .app files are not.
Py2exe generates Windows executables, so they will only work on the Windows Platform. The FAQ at http://www.py2exe.org/index.cgi/FAQ has more information on how it all works. Essentially it provides what is needed to run on Win9x as well as more current platforms. NOTE: the FAQ mentions some potential gotchas with character encodings and the work arounds.
With python, it is common enough on Unix based systems, as several Linux distributions have their custom maintenance scripts written in the language. So the Python scripts will be just as portable as Ruby scripts, etc. As long as the target machine has the interpreter and you are not using external programs that are only on one type of platform, others will be able to use your work.
Personally I experienced huge difficult with all the Exe builder, py2exe , cx_freeze etc. Bugs and errors all the time , keep displaying an issue with atexit module.
I find just by including the python distro way more convinient. There is one more advantage beside ease of use.
Each time you build an EXE for a python app, what you essential do is include the core of the python installation but only with the modules your app is using. But even in that case your app may increase from a mere few Kbs that the a python module is to more than 15 mbs because of the inclusion of python installation.
Of course installing the whole python will take more space but each time you send your python apps they will be only few kbs long. Plus you want have to go to the hussle of bundling the exe each time you change even a coma to your python app. Or I think you do , I dont know if just replacing the py module can help you avoid this.
In any case installing python and pygame is as easy as installing any other application in windows. In linux via synaptic is also extremly easy.
MACOS is abit tricky though. MACOS already come with python pre installed, Snow leopard has 2.6.1 python installed. However if you app is using a python later than that and include the install of python with your app, you will have to instruct the user to set via "GET INFO -> open with" the python launcher app which is responsible for launcing python apps to use your version of python and not the onboard default 2.6.1 version, Its not difficult and it only takes a few seconds, even a clueless user can do this.
Python is extremely portable, python pygame apps cannot only run unchanged to the three major platform , Windows , MACOS ,Linux . They can even run on mobile and portable devices as well. If you need to build app that runs across platform , python is dead easy and highly recomended.
If you are planning to include Linux in your portability criteria, it's worth remembering that many distributions still package 2.6 (or even 2.5), and will probably be a version behind in the 3.x series as well (I'm assuming your using 2.x given the PyGame requirement though).
Versions of PyGame seem to vary quite heavily between distros as well.