By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
439,931 Members | 2,015 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 439,931 IT Pros & Developers. It's quick & easy.

About reading Python code

P: n/a
Hello. I wonder what's the effective way of figuring out how a piece
of python code works. With C I often find it very useful to be able to
run the code in step mode and set breakpoints in a debugger so I can
watch how the it executes, how the data change and how the code jumps
from one function to another. But with Python, the debugger is a
little primitive. The default IDLE doesn't even allow me to set a
breakpoint. When the code is long, I am often lost in it.

So I'm curious how to read code effectively. I agree that python code
is clear, but when it becomes long, reading it can still be a hard
work.
Mar 17 '08 #1
Share this Question
Share on Google+
12 Replies


P: n/a
On Mar 17, 11:54 am, WaterWalk <toolmas...@163.comwrote:
Hello. I wonder what's the effective way of figuring out how a piece
of python code works. With C I often find it very useful to be able to
run the code in step mode and set breakpoints in a debugger so I can
watch how the it executes, how the data change and how the code jumps
from one function to another. But with Python, the debugger is a
little primitive. The default IDLE doesn't even allow me to set a
breakpoint. When the code is long, I am often lost in it.

So I'm curious how to read code effectively. I agree that python code
is clear, but when it becomes long, reading it can still be a hard
work.
BTW. I think this problem also exists in other script languages.
Mar 17 '08 #2

P: n/a
On Sun, 16 Mar 2008 20:54:01 -0700, WaterWalk wrote:
Hello. I wonder what's the effective way of figuring out how a piece of
python code works.
If your Python code is well-written, it should be easy figuring out what
it means by just reading it. For more complex programs, of course, this
method can fail.
With C I often find it very useful to be able to run
the code in step mode and set breakpoints in a debugger so I can watch
how the it executes, how the data change and how the code jumps from one
function to another. But with Python, the debugger is a little
primitive. The default IDLE doesn't even allow me to set a breakpoint.
When the code is long, I am often lost in it.
IDLE is just, well, a batteries-included editor. There are many people
(me included) who do *not* like it because it's so weak and doesn't have
any real uses cases if your programs get sufficiently complex (because
IDLE itself is sufficiently primitive).

You might be interested in *real* debuggers, such as the Python Debugger
`PDB <http://docs.python.org/lib/module-pdb.html>`_. If you don't find
its usage obvious, a quick google search just turned up a nice `tutorial
<http://www.ferg.org/papers/debugging_in_python.html>`_.

You might find the `Python Profilers <http://docs.python.org/lib/
profile.html>`_ particularly interesting, `profile` for finding out which
function sucks up the most calls/time, `trace` for more sophisticated
stuff.
`pythontracer <http://code.google.com/p/pythontracer/>` sounds like a
good combination of both.
So I'm curious how to read code effectively. I agree that python code is
clear, but when it becomes long, reading it can still be a hard work.
A common practice is just inserting `print` statements since it's so
easy. If you think your debugging isn't temporary but could be useful and
will be enabled every now and then, you could also use the `logging
module <http://docs.python.org/lib/module-logging.html>`_ with the
``DEBUG`` level.

There was a blog post recently about how to do this `generically for
functions <http://wordaligned.org/articles/echo>`_.
BTW. I think this problem also exists in other script languages.
FWIW, I think it's particularly easier in scripting languages to
implement all kinds of tracing (apart from debugging, which is rather
unpopular in Python) because you have one *extra* level (the interpreter)
between your machine and your code.

HTH,
Stargaming
Mar 17 '08 #3

P: n/a
On Mar 17, 1:54 pm, Stargaming <stargam...@gmail.comwrote:
On Sun, 16 Mar 2008 20:54:01 -0700, WaterWalk wrote:
Hello. I wonder what's the effective way of figuring out how a piece of
python code works.

If your Python code is well-written, it should be easy figuring out what
it means by just reading it. For more complex programs, of course, this
method can fail.
With C I often find it very useful to be able to run
the code in step mode and set breakpoints in a debugger so I can watch
how the it executes, how the data change and how the code jumps from one
function to another. But with Python, the debugger is a little
primitive. The default IDLE doesn't even allow me to set a breakpoint.
When the code is long, I am often lost in it.

IDLE is just, well, a batteries-included editor. There are many people
(me included) who do *not* like it because it's so weak and doesn't have
any real uses cases if your programs get sufficiently complex (because
IDLE itself is sufficiently primitive).

You might be interested in *real* debuggers, such as the Python Debugger
`PDB <http://docs.python.org/lib/module-pdb.html>`_. If you don't find
its usage obvious, a quick google search just turned up a nice `tutorial
<http://www.ferg.org/papers/debugging_in_python.html>`_.

You might find the `Python Profilers <http://docs.python.org/lib/
profile.html>`_ particularly interesting, `profile` for finding out which
function sucks up the most calls/time, `trace` for more sophisticated
stuff.
`pythontracer <http://code.google.com/p/pythontracer/>` sounds like a
good combination of both.
So I'm curious how to read code effectively. I agree that python code is
clear, but when it becomes long, reading it can still be a hard work.

A common practice is just inserting `print` statements since it's so
easy. If you think your debugging isn't temporary but could be useful and
will be enabled every now and then, you could also use the `logging
module <http://docs.python.org/lib/module-logging.html>`_ with the
``DEBUG`` level.

There was a blog post recently about how to do this `generically for
functions <http://wordaligned.org/articles/echo>`_.
BTW. I think this problem also exists in other script languages.

FWIW, I think it's particularly easier in scripting languages to
implement all kinds of tracing (apart from debugging, which is rather
unpopular in Python) because you have one *extra* level (the interpreter)
between your machine and your code.

HTH,
Stargaming
Thanks for your informative reply. I'll try them. I think I need more
practice to familiarize myself with those idioms of Python.
Mar 17 '08 #4

P: n/a
On 2008-03-17, WaterWalk <to********@163.comwrote:
Hello. I wonder what's the effective way of figuring out how a piece
of python code works. With C I often find it very useful to be able to
run the code in step mode and set breakpoints in a debugger so I can
watch how the it executes, how the data change and how the code jumps
from one function to another. But with Python, the debugger is a
little primitive. The default IDLE doesn't even allow me to set a
breakpoint.
It does, you just right-click and go "set breakpoint". But yes IDLE is a
bit basic.
Mar 17 '08 #5

P: n/a
Nir
On Mar 17, 5:54 am, WaterWalk <toolmas...@163.comwrote:
Hello. I wonder what's the effective way of figuring out how a piece
ofpythoncode works. With C I often find it very useful to be able to
run the code in step mode and set breakpoints in adebuggerso I can
watch how the it executes, how the data change and how the code jumps
from one function to another. But withPython, thedebuggeris a
little primitive. The default IDLE doesn't even allow me to set a
breakpoint. When the code is long, I am often lost in it.

So I'm curious how to read code effectively. I agree thatpythoncode
is clear, but when it becomes long, reading it can still be a hard
work.
Try Winpdb - www.winpdb.org (works on Linux as well). Don't forget to
send feedback.

Mar 17 '08 #6

P: n/a


WaterWalk пишет:
Hello. I wonder what's the effective way of figuring out how a piece
of python code works. With C I often find it very useful to be able to
run the code in step mode and set breakpoints in a debugger so I can
watch how the it executes, how the data change and how the code jumps
from one function to another. But with Python, the debugger is a
little primitive. The default IDLE doesn't even allow me to set a
breakpoint. When the code is long, I am often lost in it.

So I'm curious how to read code effectively. I agree that python code
is clear, but when it becomes long, reading it can still be a hard
work.
You also can use free IDE (for example Eclipse) and PyDev plugin, which
includes comfortable Debugger
Mar 17 '08 #7

P: n/a
En Mon, 17 Mar 2008 01:54:01 -0200, WaterWalk <to********@163.com>
escribi�:
Hello. I wonder what's the effective way of figuring out how a piece
of python code works. With C I often find it very useful to be able to
run the code in step mode and set breakpoints in a debugger so I can
watch how the it executes, how the data change and how the code jumps
from one function to another. But with Python, the debugger is a
little primitive. The default IDLE doesn't even allow me to set a
breakpoint. When the code is long, I am often lost in it.
See the wiki at http://wiki.python.org/moin/DevelopmentTools for more
editors, debugging tools and IDEs.

--
Gabriel Genellina

Mar 17 '08 #8

P: n/a
On 17 Mar, 04:54, WaterWalk <toolmas...@163.comwrote:
So I'm curious how to read code effectively. I agree that python code
is clear, but when it becomes long, reading it can still be a hard
work.
First, I recommend that you write readable code! Don't use Python as
if you're entering the obfuscated C contest.

Two particularly important points:

* If you find yourself thinking this module is too long, that's
probably what it is. Half a page of code per module is fine. Two pages
of code per module can be too much.

* Comments are always helpful to the reader.

Second, I recommend getting a good IDE. E.g. pick one of:

* Microsoft Visual Studio (commercial)
* Eclipse with PyDev and CDT (free)
* SPE (free)
* ActiveState Komodo IDE (commercial)

Mar 18 '08 #9

P: n/a
WaterWalk <to********@163.comwrites:
from one function to another. But with Python, the debugger is a
little primitive. The default IDLE doesn't even allow me to set a
breakpoint. When the code is long, I am often lost in it.
Try winpdb.org which despite the name has nothing to do with MS Windows.
Mar 18 '08 #10

P: n/a
On 18 , 03:57, sturlamolden <sturlamol...@yahoo.nowrote:
On 17 Mar, 04:54, WaterWalk <toolmas...@163.comwrote:
So I'm curious how to read code effectively. I agree that python code
is clear, but when it becomes long, reading it can still be a hard
work.

First, I recommend that you write readable code! Don't use Python as
if you're entering the obfuscated C contest.

Two particularly important points:

* If you find yourself thinking this module is too long, that's
probably what it is. Half a page of code per module is fine. Two pages
of code per module can be too much.

* Comments are always helpful to the reader.

Second, I recommend getting a good IDE. E.g. pick one of:

* Microsoft Visual Studio (commercial)
* Eclipse with PyDev and CDT (free)
* SPE (free)
* ActiveState Komodo IDE (commercial)
under Microsoft Visual Studio do you mean IronPython instance?
Mar 18 '08 #11

P: n/a
On 18 Mar, 08:00, hellt <Dodin.Ro...@gmail.comwrote:
under Microsoft Visual Studio do you mean IronPython instance?
AFAIK, with the latest VS 2008 you can develop for CPython and
IronPython.

http://blogs.msdn.com/haibo_luo/arch...6/5482940.aspx

Mar 18 '08 #12

P: n/a
On 2008-03-18, sturlamolden <st**********@yahoo.nowrote:
First, I recommend that you write readable code! Don't use Python as
if you're entering the obfuscated C contest.

Two particularly important points:

* Comments are always helpful to the reader.
It would be nice if this was the case! I once saw a preogram where
a line of code like this:

foo++;

Would be annotated with a comment like this:

/************************************************** **/
/* */
/* Increment foo */
/* */
/************************************************** **/

This comment was worse than useless, because it (and others like
it) took up space that distracted from the information-containing
parts of the code.

Mar 25 '08 #13

This discussion thread is closed

Replies have been disabled for this discussion.