On 12/31/2010 12:51 PM, Cesare Di Mauro wrote:
2010/12/31 <firstname.lastname@example.org mailto:email@example.com>
>> Another example. I can totally remove the variable i, just using the >> stack, so a debugger (or, in general, having the tracing enabled) >> cannot even find something to change about it. Ethan> -1 Ethan> Debugging is challenging enough as it is -- why would you want to Ethan> make it even more difficult? <snarky> I don't know. Maybe he wants his program to run faster. </snarky>
"Aggressive" optimizations can be enabled with explicit options, in
order to leave normal "debugger-prone" code.
I wish the Python compiler would adopt a strategy of being able to
disable optimizations. I wrote a bug about a "leaky abstraction"
optimization messing up coverage testing 2.5 years ago, and it was
closed as won't fix: http://bugs.python.org/issue2506. The debate
centered around, "but that line isn't executed, because it's been
optimized away." It's common in sophisticated compilers (as in, any C
compiler) to be able to choose whether you want optimizations for speed,
or disabling optimizations for debugging and reasoning about the code.
Python would benefit from the same choice.
If you use print statements for the bulk of your debugging (many people do), unrolling loops doesn't affect your debugging ability. Skip
It's a common practice. Also IDEs helps a lot, and advanced interactive shells too (such as DreamPie).
Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/ned%40nedbatchelder.com