The IDLE IDE (Integrated Development Environment) is installed with the Python language and can be used with SPSS, but I am often asked to recommend a better one. I'll tell you what I do and offer some tips on using it with IBM SPSS Statistics. This is not an in-depth review of any of these editors.
IDLE has the virtue of always being present if Python is installed, and Python scripting (not programmability) within Statistics uses it by default, but there are much better choices available. Many of the alternatives are free, and many are multi-platform. I will focus on Windows, though, since that's what I know best. If you want to follow up on any of these, you can find them easily via Google, so I won't add urls. Any Python IDE or even the plain Python command line can drive Statistics in external mode where your Python program invokes and drives Statistics without the usual user interface. Using one in internal mode is tougher.
In the free and simple category, I use Pythonwin, which as the name suggests is Windows only. It comes with the win32 COM extensions, but you don't have to get into those to use it. As you can see from the image below, it's a pretty plain window, but it provides syntax coloring, pop-up help, syntax checking and other niceties. The output from any commands you run appears right in the interactive window, but you can open a program window and run a complete program. That separates the input and output.
The Pythonwin IDE
Pythonwin is quite easy to learn, and it's free. It gives you lots more help than the Statistics syntax window, which knows about Statistics syntax but not about Python syntax. I have used this in training classes, and attendees pick it up quite quickly. It has a debugger, but it's hard to use and not especially powerful. It's best for trying out bits of code and running small programs. You can develop a program or Python script with it and then transfer it to the Statistics syntax window later.
If you are going to do a lot of Python work or you want to debug code running in internal mode, it is worth getting a more powerful tool. Some people like Pydev, the Eclipse plug-in for Python, but I find that way too busy and complicated for my needs. Stani is another popular free editor.
I do not claim to know all the available IDEs, but what I like best of what I have tried is Wing IDE. It's a commercial product but inexpensive. I chose it originally several years ago because it was tops in a comparative review of a number of IDEs and was used by some Python gurus I knew. It's interface is a lot more complicated than IDLE or Pythonwin, because it has many tool and debugging windows, but I have used it in teaching, and students catch on more quickly than I originally expected. It separates the output into its own window, and provides much deeper help on command completion than Pythonwin. Here's a picture. It's scrunched down, but you should be able to get the general idea.
The user interface is pretty configurable. I usually have many modules open at the same time and the Debug window open on a second monitor.
Wing really shines when it comes to debugging, but there are a number of settings and a little extra code that really amp up what you can do. If you are running Statistics in external mode, then the obvious debugging features don't require any special settings. Debugging in internal mode, where you start from the Statistics syntax window and invoke a saved Python module is a really powerful way to to work, but you need to do a few special things to make this work. The setup is that you are starting from the syntax window (or an INSERTed syntax file), and the Python code you want to debug is in a saved module that is open in Wing.
First, you need to adjust some settings in Wing (some of this information is available from the Wing help material.)
- Go to Edit>Preferences>Debugger>External/Remote. Check the box Enable Passive Listen
- In Debugger I/O you may want to tinker with the settings for Debug I/O Encoding and Debug Shell Encoding if you are working with characters beyond 7-bit ascii.
- Open the file wingdbstub.py in the editor. You will find it in the Wing installation directory. It's heavily commented to guide you through the settings, but all you need to do is to find the kEmbedded line and change it to read
kEmbedded = 1
- Make sure that the line that sets the value of WINGHOME points to where you have installed WING. (This is usually automatically done by the install process.)
- Save wingdbstub.py and copy it also to wherever you keep your Python modules.
The steps above are a one-time thing. The next part is what you do to your code whenever you want to debug. I always insert this code into a new module and just toggle it on or off as needed. You can do that using the Source>Comment Region Toggle menu item. (The exact menu wording varies with different versions of Wing.
Insert the following code someplace where it will be executed each time you want to debug the code. That implies that you should not just put this at the top of a module so that it is executed on module import, because you need to execute the code each time you debug something. Putting it outside executing code means it only gets executed once - when the module is imported.
if wingdbstub.debugger != None:
This code uses a try block so that if you forget to comment it out before distributing a module, your code will still work even though the users don't have Wing. The rest of it ensures that the debugger is listening and can grab control when a breakpoint is encountered. (This is more complicated than the usual debugging situation because of the way Statistics and programmability/scripting are architected.)
Once this block of code has been executed, if a breakpoint has been set, the program will pause at that point and give control to the editor. You can examine or change variables, step through the code from that point or do any other useful debugging operations. Just click Debug to continue execution to the next breakpoint or the end of the code.
This facility is incredibly useful, but there are a few things you can't do this way. If you change code that has already been imported in your Statistics session and rerun the module, the old code will still be used, because import is a no-op if repeated. You can use the Python reload function to get a new version, but that isn't entirely reliable. And any existing variables are not automatically replaced unless the relevant code is reexecuted.
It's safer to restart Statistics after you change the code (and don't forget to save the file in the editor!). Because of the way Python scripts (not programs) are executed, you might not have to restart Statistics for those, but if your changes don't seem to be working, it might be because you need to restart.
Finally, if you are not sure whether the debugger is hooked in, watch the icon at the left of the Wing status bar. It will change color when the debugger is active.
Debugger not watching
You may be thinking that having adopted a better IDE, you would like to use it in place of IDLE when you create or edit a script from within Statistics by using File>New>Script or File>Open>Script. How well this works depends on the IDE, but it is possible.
The IDE configuration is specified in the file clientscriptingcfg.ini, which lives in your Statistics installat ion directory. First, save a copy of the file in case of trouble. Then open the standard version in an editor that understands Unicode and Unix-style line endings. You might be surprised to learn that Wordpad on Windows works.
In the section marked [Python], change the EDITOR_PATH line to point to your chosen IDE. Mine looks like this
EDITOR_PATH=C:\Wing IDE 3.2\bin\wing.exe
The second step is to change the EDITOR_ARGS line to read
Save the file and restart Statistics, and your IDE should come up from the menus. For Wordpad, be sure to save it as a Unicode Text Document, not as rtf. For the Open action, the file to be edited will not be opened, but you can just open it from the editor directly. If you are using Wing, it will remember the file the next time (along with any other files you opened), so this isn't too inconvenient.
You can't do this for programs, so you would have to edit them independently in the IDE.
In summary, using a good IDE will help you get the most out of programmability and maximize your productivity.