Develop Reference

Why GASP doesn't work when I run it from IDLE?

I made this script:
from gasp import *
begin_graphics()
Circle((200, 200), 60)
Line((100, 400), (580, 200))
Box((400, 350), 120, 100)
update_when('key_pressed')
end_graphics()
When I start it from terminal, it works perfectly. When I run it from IDLE, it doesn't work, I get no answer (shell prompt (>>>) disappears but nothing happens).

In general, you can't run GUI apps in the embedded Python interpreter in IDLE, unless the library you're using is designed to integrate with IDLE. Or, worse, it may work on one machine and not on another. I'll explain why below, but first just take that on faith.
As far as I can tell, gasp's documentation doesn't address this, but similar libraries either warn you that they may not work in IDLE (easygui, early versions of graphics, etc.) or come with special instructions for how to use them in IDLE (e.g., later versions of graphics).
Now, maybe gasp should be designed to integrate with IDLE, given that it's specifically designed for novices, and many of those novices will be using the IDE that comes built in with Python. Or maybe not. But, even if that should be true, that's something for gasp to deal with. File a bug or feature request, but you'll need some way to keep working until someone gets around to writing the code.
The simplest solution here is to use a different IDE, one that runs its interactive Python interpreter in a completely separate process, exactly the same as you get when running it yourself in the terminal. There are lots of good options out there that are at least free (-as-in-beer) for non-commercial use (PyCharm, Komodo, Eclipse PyDev, emacs with your favorite collection of packages, etc.). Although Stack Overflow is not a good place for advice on picking the best one for you (if googling isn't sufficient, try asking on a mailing list or forum), almost any of them will work.
Another option: instead of using an interpreter built into an IDE, you might want to to consider running an enhanced interpreter environment (like ipython-gtk or emacs with a smaller set of packages) alongside your IDE. Of course they'll no longer be tightly integrated (the "I" in "IDE"), but in my experience, even working in an environment where the whole team uses PyCharm or PyDev, I still end up doing most of my interactive testing in ipython; you may find you prefer that as well. Or you may not, but give it a try and see.
So, why is there a problem in the first place?
First, if you don't understand what an "event loop" or "runloop" or "mainloop" is, please read either Why your GUI app freezes or the Wikipedia page or some other introduction to the idea.
Normally, when you run the interactive Python interpreter (e.g., by typing python at the bash or C: prompt in your terminal), it runs in its own process. So, it can start up a runloop and never return (until you quit), and the terminal won't get in your way.
But when you run the interactive Python interpreter inside IDLE, it's actually running in the same process as IDLE, which has its own runloop. If you start up a runloop and never return, IDLE's runloop doesn't get to run. That means it doesn't get to respond to events from the OS, like "refresh your window" or "prepare for a new window to open", so from the user's (your) point of view, IDLE and your app are both just frozen.
One way to get around this is in your code is to spawn another thread for your runloop, instead of taking over the main thread. (This doesn't work with all GUI libraries, but it works with some. This is how graphics solved the problem.) Another way is to spawn a whole new child process to run your GUI. (This works with all GUI libraries, but it's a lot more work—now you have to deal with inter-process communication. One of the novice-friendly matplotlib wrappers does this.) Finally, you can integrate your runloop with IDLE's Tkinter runloop by having one drive the other. (Not all GUI libraries can be driven this way, but Tkinter's can, and IDLE can be monkeypatched to work this way; graphics used to do this.) But none of these are even remotely simple. And they're probably things that gasp itself should be doing, not your code.

In Python, how do I debug with an interactive command line (and visual breakpoints?)

I've recently moved from Matlab to Python. Python is a much better language (from the point of view of a computer scientist), but Python IDEs all seem to lack one important thing:
A proper interactive debugger.
I'm looking for:
The ability to set breakpoints graphically by clicking next to a line of code in the editor.
The ability to run ANY CODE while stopped in the debugger, including calling functions from my code, showing new windows, playing audio, etc.
When an error occurs, the debugger should automatically open an interactive console at the error line.
Once done with the interactive console, you can resume normal execution.
Matlab has all these features and they work incredibly well, but I can't find them anywhere in Python tools.
I've tried:
PyCharm: the interactive console is clunky, often fails to appear, and crashes all the time (I've tried several different versions and OSs).
IPython: can't set breakpoints -Launching a Python console programatically: you have to stop your code, insert an extra line of code, and run again from the beginning to do this. Plus, you can't access functions already imported without re-importing them.
Being able to debug and fix problems THE FIRST TIME THEY APPEAR is very important to me, as I work in programs that often take dozens of minutes to re-run (computational neuroscience).
CONCLUSION: there is NO way to do all of these in Python at the moment. Let us hope that PyLab development accelerates.

At the top of your code, write
import pdb
And within your code, use the following statement wherever you want to debug.
pdb.set_trace()
You will have an interactive shell thus, whenever the set_trace() statement is met.
You can then use step(s), next(n), continue(c) and so on to check the execution flow, and print values of variables like print var
For more details on pdb, refer here

There are many Python IDEs. That was a topic here: What IDE to use for Python?
"The ability to set breakpoints graphically by clicking next to a line of code in the editor."
PyDev has this. Double-click in the gray margin bar.
"The ability to run ANY CODE while stopped in the debugger, including calling functions from my code, showing new windows, playing audio, etc."
PyDev has this. It's not the only one. PyScripter's stated features seem to include this.
"When an error occurs, the debugger should automatically open an interactive console at the error line."
PyDev does this. (I think. Or at worst do you need to double-click on the console message that states the error's location in the code?)
"Once done with the interactive console, you can resume normal execution."
PyDev has this. It's called "resume". It's what the green "play" triangle in a toolbar does. Some other software calls this feature "continue".

I've been searching for the same, but unfortunately Python IDEs are not as well-featured as Matlab's at this point. For scientific programming, you will also want graphics/plotting to run in an entirely different thread, so IPython integration is essential. As far as I can tell, the Matlab IDE feature to change the workspace from the debugger, which then affects code running subsequently, is quite unique. Each of the features exist in some IDE, but none exist in all:
Spyder has good integration with scientific tools, but its debugging is limited to the built-in pdb, which lacks the requirement to execute any code and have this code affect the namespace after continuing.
PyDev and PyCharm, and quite a few others, have decent debugging features, but I don't think it has good integration with scientific tools. That means, if you plot, you lose access to your prompt. Not good.
As far as I've experienced, the closest comes Wing IDE. It is a propietry product, but if you're making the transition from Matlab 89$/year for non-commercial-use should be acceptable (you can evaluate it first). But for me, I've ultimately settled to alter my workflow, and not using any sophisticated IDE at all. When I looked was some years ago, so perhaps the situation has improved.
You might also be interested in this article from April 2013, Evaluating IDEs for Scientific Python. It doesn't really reach a conclusion either.

Seeing as you are comming from Matlab, I would suggest you give a look at
Python(x,y)
The page decribes it as follows:
Python(x,y) is a free scientific and engineering development software for numerical computations, data analysis and data visualization based on Python programming language, Qt graphical user interfaces and Spyder interactive scientific development environment.
It will not cater to all your wishes, but it certainly made me feel comfortable when I started out with Python, coming from Matlab.
Hope it helps

You can do all this in the iPython Notebook. Use the magic command %pdb to stop on error.

If using the command line,
alias ipythondebug='ipython --InteractiveShell.pdb true'
in your ~/.profile will give you debug on error like Matlab. This of course requires ipython installed.
Not sure about the resuming part.
You can also edit the ipython config file if you want the debug on error to be permanent. See
https://ipython.readthedocs.io/en/stable/interactive/magics.html#magic-pdb

Is it possible to implement automatic error highlighting for Python?

Are there any IDEs for Python that support automatic error highlighting (like the Eclipse IDE for Java?) I think it would be a useful feature for a Python IDE, since it would make it easier to find syntax errors. Even if such an editor did not exist, it still might be possible to implement this by automatically running the Python script every few seconds, and then parsing the console output for error messages.

eclipse+pydev
pycharm
many others ....

If you use VIM or don't have a problem with it, try this extension. https://github.com/klen/python-mode
This is for Emacs as well: https://github.com/gabrielelanaro/emacs-for-python
Also pycharm and eclipse with pydev work fine.

If I don't use vim I really enjoy spyder. It is easy to use and has some really nice features, like integrated debugging and profiling, graphical variable explorer and object inspector. The latter shows, e.g., the integrated documentation for every function of class you use.

I built an extension to Eclipse and PyDev that does what you describe, it runs the Python code as you're typing, and displays all the variable values and any exceptions that occur. It's called Live Coding in Python, and the web site has a tutorial and a demo video.
PyDev can highlight some problems in your code by analysing it, and Live Coding in Python can show you problems that happen when you run it.

Experienced Python programmers (ESPECIALLY former php programmers) : How do I debug python?

In PHP, it was extremely easy to start hacking away and figuring out what was going on on a page. Just throw in a bunch of echos and print_r's and that was about it. It appears that this technique is not working for me in python. I am getting practice by hacking around in a python photo upload module, and when a photo is uploaded, it creates 3 different size photos. I found the code that does this, but I want to see the state at that particular moment. I tried doing a "print" on the size variable, but it did not show up in my browser.
I guess a more straightforward question would be, is it "pythonic" do debug using the browser ( equivalent to echo's and print_r's in php ), or is this what the python console is for? Thanks!

Use the logging module rather than printing stuff to stdout.
Using the interpreter in interactive mode is a great way to try out code, and pdb is very useful for real debugging.

It's "pythonic" to do debugging using the pdb module.
But really, if you're just "hacking around", then I suggest messing around with an interactive interpreter interface, especially one that supports autocompletion (Python itself comes with IDLE right out of the box).

You need to learn how to use a debugger ;) Hacking with prints is cool for simple php, but you can save a lot of time in higher languages with a debugger.
As mentioned, PDP is a place to start http://docs.python.org/library/pdb.html

As others have mentioned PDB, I'll take the opportunity to sing the praises of Eclipse using the pydev plugin, which is absolutely fantastic. IDLE is also well worth a go. Both of these IDEs allow you to step through code, inspect variables, auto-complete, etc. etc.
http://pydev.org/
Download Eclipse then use the Software Updates menu to add in PyDev.
http://pydev.org/updates

PyCharm from JetBrains is as good as all their other products. It has an integrated debugger and lots more.

Python Debugging: code editing on the fly

I am new to python and haven't been able to find out whether this is possible or not.
I am using the PyDev plugin under Eclipse, and basically all I want to find out is, is it possible to edit code whilst you're sitting at a breakpoint? I.e. Edit code whilst you're debugging.
It allows me to do this at present, but it seems to still be executing the line of code that previously existed before I made changes.
Also, are you able to drag program execution back like you can in VBA and C# for example?
If either of these are possible, how can I enable them?

PyDev supports this to some extend since version 1.4.8, see the change notes and the corresponding blog entry.

When you start a Python program, it will be compiled into bytecode (and possibly saved as .pyc file). That means you can change the source but since you don't "open" the source again, the change won't be picked up.
There are systems like TurboGears (a web framework) which detect these changes and restart themselves but that's probably going to confuse the debugger.
Going back in time also isn't possible currently since the bytecode interpreter would need support for this.

You can run arbitrary commands in the console during the breakpoint. For my needs, this typically achieves the same purpose as coding live, although I do wish it were as elegant as simply using the editor.