On 12/31/2010 12:51 PM, Cesare Di Mauro wrote:
2010/12/31  <skip@pobox.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?

I don't know.  Maybe he wants his program to run faster.


"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 there 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.


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