[CentralOH] Idle on Mac OSX 10.6 (Snow Leopard)
mark at microenh.com
Sun Jun 5 03:54:18 CEST 2011
When I'm experimenting with Python on Windows and Linux, I find the Idle IDE very useful. It's easy to quickly try things interactively. In fact, before moving on to more "advanced" development environments, I felt I was quite productive using Idle. On the Mac it is a different story. One thing, the version of Idle that is pre-installed is flaky. It would crash most times that I used it. This really suprised me. Up to that time, the 'official' Python software had been very robust. Also, that experience didn't jibe well with my perception of the Mac as a very stable platform. Recently, I found this post http://www.python.org/download/mac/tcltk/ that explains the problems and offers work-arounds. In a nutshell, the problem turns out to be incompatibilities with Python and the version of Tcl/Tk. I upgraded to Python 2.7 which seems to solve the stability issues.
The other problem on the Mac was the default directory when Idle was launched. On Windows and Linux, if you use a context (right-click) menu to launch Idle with a file, the default directory (os.getcwd()) will be the directory containing the file which is usually what I want. On the Mac, the default directory seems to be my Documents (/Users/mark/Documents) directory, which makes navigating around files in the same directory as the initial file difficult. I did a little investigating and it looked like the behavior was due to the way AppleEvents are used in the launch process.
The first workaround I found was that I opened a terminal window in the directory with my Python file and launched Idle from the command line, the default directory is properly set. While this works, having the terminal window around is ugly. The terminal window is dead while Idle is running.
The Python 2.7 that I installed comes with a Build Applet applet. These applets are designed to have files or directories (folders) dropped on them. I decided to write an applet that when a Python file is dropped on it, would open Idle with that file with the default directory set to the directory containing the file. If a folder is dropped on the applet, Idle is opened without a file, and with the default directory set to that folder. While I was at it, I added some code from the activate_this.py script to set up a virtualenv. Here's what I came up with:
> Use the Python "Build Applet" Applet to conver this script to an applet.
> Drag a .py file to the applet to launch Idle and open the file with
> the current directory set to the directory containing the file.
> Drag a folder to the applet to launch Idle with the current directory
> set to that folder. Note: ignore the error.
> Note: the Console shows a Python error: "Tried to setup shared memory more
> than once." - seems benign.
> import sys
> import os
> d = sys.argv
> if not os.path.isdir(d):
> d = os.path.dirname(d)
> base = None
> p1 = d
> while True:
> p2 = os.path.join(p1, 'bin', 'activate')
> if os.path.exists(p2):
> base = p1
> if p1 == '/':
> p1 = os.path.dirname(p1)
> if base:
> # activate virtualenv
> if sys.platform == 'win32':
> site_packages = os.path.join(base, 'Lib', 'site-packages')
> site_packages = os.path.join(base, 'lib', 'python%s' % sys.version[:3], 'site-packages')
> prev_sys_path = list(sys.path)
> import site
> sys.real_prefix = sys.prefix
> sys.prefix = base
> # Move the added items to the front of the path:
> new_sys_path = 
> for item in list(sys.path):
> if item not in prev_sys_path:
> sys.path[:0] = new_sys_path
> # os.execl("/usr/local/bin/idle2.7", "")
> # launch idle
> from idlelib import idle
There are currently a couple of minor problems as noted in the docstring: Python writes a message to stderr (visible in the Mac's Console app), "Tried to set up shared memory more than once." and when you drop a folder on the applet, while it works as desired, there is a popup message "xxx is a directory". Both of these appear to be benign.
The scheme used to determing the virtualenv to activate is based on the way I set up my workspaces. I set up one workspace (top level directory) for each virtualenv. Inside that directory, I create a directory for each project using that virtualenv. Thus, the virtualenv's bin, include and lib directories are sibling directories to the project's top level directory. To check for a virtualenv, I back up the directory path of the file os.path.dirname looking for a level at which I find a sibling bin directory that contains the activate file. If I find one, that's the virtualenv I activate. If I reach the top of the file system without finding one, I don't setup a virtualenv.
Comments are welcome.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the CentralOH