On Mon, Dec 19, 2005 at 07:12:44AM -0500, Jim Fulton wrote: | Sidnei da Silva wrote: | >On Mon, Dec 19, 2005 at 06:50:19AM -0500, Jim Fulton wrote: | >| >There is a drawback: Debugging becomes a lot harder and sometimes | >| >impossible because you get no or faulty line number information in | >| >tracebacks and when using pdb. | >| | >| That isn't true. Line numbers are included and valid. | >| | >| All -O does is: | >| | >| - cause __debug__ to be false | >| | >| - cause assert statements to be noop. | > | >I think Jens was referring to the fact that since some version (which I | >don't remember correctly), when run with -O python will show the line | >number of the function definition on tracebacks instead of the real | >line number where the exception occurred. | | I don't think this is the case for recent versions of Python. Indeed, was speaking from memory, and understood the SET_LINENO changes backwards. Mark help me out understand the issue: """ actually, when -O was first introduced, -O did magic with the SET_LINENO opcode. but in recent (even 2.3 I believe), even non-optimised Python manages to use the same perf tricks, but keep a correct lineno. This is reflected if you ever look in the debugger - a frame's f_lineno structure element is indeed only ever the function decl. Magically f_lineno as exposed to Python does get the right thing though... """ -- Sidnei da Silva Enfold Systems, LLC. http://enfoldsystems.com