What are good ways to make my Python code run first time? [closed]

Answer 1

Python provides a debugger which allows you to step through your code, inspect variables and manipulate them. Refer to http://pythonconquerstheuniverse.wordpress.com/category/python-debugger/ which can take you over the steps...

Also check the python standard library reference for pdb http://www.python.org/doc/2.5.2/lib/module-pdb.html

Answer 2

I am new to python, and have been trying several different debuggers. Here are the options I've come across so far:

1. Eclipse with Pydev - If you're already using eclipse, this is probably the way to go. The debugger works well, and is pretty featureful.
2. Komodo IDE - A light-weight python IDE. Basically a text editor + a debugger. It was really easy to figure out and be productive with immediately.
3. WinPDB - Trying this one next. Looks very featureful, and I get to use whichever editor I choose.
4. PDB - Haven't tried yet since I've read about how WinPDB is a better alternative.
5. Ipython with %run command - I've used IPython, but not as a debugger like this. I need to try this out. (Thanks for the tip, EOL)
6. Eric IDE - Also on the list to try.
7. Old-school print, assert statements - Simple, useful, but not a full solution.

Memory debugging - To debug memory problems, I've come across a few tools:

1. objgraph - Will generate png's of reference graphs. Neat. There's other functionality as well, like: import objgraph;print(objgraph.show_most_common_types(limit=10)) will print the top 10 most common types in memory.
2. gc module - Interact directly with the garbage collector.
3. heapy - Heap analyzer. For example: from guppy import hpy; hp = hpy(); print(hp.heap()) will print the most common types, their memory usage, etc.

This is a very incomplete list, but hopefully it's a good start.

Answer 3

For a most integrated experience you can use full blown IDE like PyCharm:

http://blog.jetbrains.com/pycharm/files/2011/05/template-debug2.png

Answer 4

All the really cool stuff is easily demonstrated in the interactive interpreter. I think this might be the "gold standard" for good design:

Can you exercise your class interactively?

If you can do stuff interactively, then you can write unittests and doctests with confidence that it's testable, simple, reliable.

And, more important, you can explore it interactively. There's nothing better than the instant gratification that comes from typing code and seeing exactly what happens.

The compiled language habits (write a bunch of stuff, debug a bunch of stuff, test a bunch of stuff) can be left behind. Instead, you can write a little bit of stuff, explore it, write a formal test and then attach your little bit of stuff to your growing final project.

You still do overall design. But you don't squander time writing code that may or may not work. In Python you write code that works. If you're not sure, you play with it interactively until you're sure. Then you write code that works.

Answer 5

Test early and test often.

This doesn't necessarily mean to jump into the test driven design pool head first (though that's not such a bad idea). It just means, test your objects and methods as soon as you have something that works. Don't wait until you have a huge pile of code before doing testing.

Invest some time in learning a testing framework. If it's trivial for you to type in a test case you'll more likely do it. If you don't have any sort of framework testing can be a pain so you'll avoid it. So, establish some good habits early on and you'll have fewer problems down the road.

Answer 6

Here is some techniques to facilitate debugging in Python:

• use interactive shell e.g., ipython. Python is a dynamic language you can explore your code as you type. The shell is running in the second window in my editor at all times.

• copy-paste from the shell into docstrings a code that illustrates a dominant usage and corner cases of the function (class, module). doctest.testmod() placed in a if __name__=="__main__" section allows to test all docstrings in the module. doctest can be easily integrated with unittest.

• use assert for stuff that can never happen.

• print() can solve many debugging problems; logging module is suitable for long-living python processes.

• write tests (not necessarily before your code), run them often (automatically or with one keystroke at most); nose provides extended test discovery and running features for unittest.

• run pylint occasionally.

At this point there is a little use for a formal python debugger. Winpdb is an external multi-platform GPL'ed GUI python debugger if you need one.