"python" <[EMAIL PROTECTED]> writes:
> i am a long time windows user and have had a great way to learn new api.
There's a better way. See below.
> to write some code and then run it.
> if there is an error, the debugger will load.
> then i can figure out what the eror is, just touch up the ocde and continue
> to run the code.
> i do not have to stop the code, modify the code, rerun the code.
> often an error will only happen after a complex set of conditions and not
> have to completely stop the app is a fantastic
> way to debug.
Yup. It's been around for decades. The cooler implementations will
interpose a stage that offers you a set of proposed fixes as well as
the ability to get to the debugger.
> so how can i use python to debug code and change that code without having to
> restart the code.
Well, as James mentioned, you can use "reload" to reload your
modules. But in general, this kind of thing doesn't work very well in
OO languages in general, and in Python in particular. Here's an
example of why:
>>> def f():
... print "Version 1"
...
>>> fp = f:
>>> def f():
... print "Version 2"
...
>>> f()
Version 2
>>> fp()
Version 1
>>>
I changed the function f on the fly - just like you want to - but all
the existing references to it will still refer to the *old* version of
the function(*). To do the right thing, you need to fix all the
references to the old code to refer to the new code as well. Unless
your language has some ability to capture a code reference - first
class functions, closures, or objects - that won't be a problem. But
Python ha all those things, and every one of them causes problems like
this. So you really can't "continue" your program from the debugger;
you need to restart it to get everything that references code to
reference the edited code.
But if the point is to learn an API, then there's something a lot
better than tweaking code inside a debugger. That's testing code
inside the interpreter. When writing web scraping software with
BeautifulSoup, writing the first guess at the scrape sequence and then
tweaking it in the debugger would be ok. But being able to get the
soup object in the interpreter, and try scrape sequences to see what
they return directly is even better. Doing it in an Emacs buffer means
I have a complete log of what I did to create the scrape, so I can
reconstruct even complicated sequences if the need arises.
If you hang out in this group long enough, you'll hear a lot about
"unit testing". It's an excellent idea, and I recommend it
highly. However, it's always struck me as a very batch oriented
approach. A more interactive approach is "exploratory proramming",
which is closer to what you're describing, and is appropriate when you
don't know the problem space very well, or if - as when learning a new
api - you don't know the tool set very well. Python is an excellent
tool for this. It's not exactly like what you described, but different
isn't necessarily inferior.
<mike
*) This is a feature. Classic use is:
oldfoo = foo
def foo(*args, *kwds):
# preprocess the arguments
return oldfoo(*args, *kwds)
--
Mike Meyer <[EMAIL PROTECTED]> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
--
http://mail.python.org/mailman/listinfo/python-list
