On Thu, Feb 21, 2008, Barry Warsaw wrote: > > So I have some particularly troublesome code that I want to set a > breakpoint at and start stepping through. I usually will stick this > tidbit at the place I want to break: > > good_code() > import pdb; pdb.set_trace() > call_buggy_code() > > In doctests it's a little ickier because I have to put that all on the > line where I want to break, not before it or doctest won't do the > right thing, e.g.: > > >>> import pdb; pdb.set_trace(); call_buggy_code() > > I suggest that setting a breakpoint be done with a new built-in, e.g > breakpoint(). So now I would do this: > > good_code() > breakpoint() > call_buggy_code()
-0 >From my POV, this is cruft in the builtins (I mostly do web apps) -- and I don't particularly like your suggestions for modifying the result of breakpoint() (note that Facundo wants to use gdb). Why not simply inject set_trace() into the builtins in your startup code? You can control whether it gets injected with a DEBUG env var or something. -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ "All problems in computer science can be solved by another level of indirection." --Butler Lampson _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
