On 12/31/2010 12:51 PM, Cesare Di Mauro wrote:
2010/12/31 s...@pobox.com mailto:s...@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?
snarky
I don't know. Maybe he wants his program to run faster.
/snarky
:D
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.
--Ned.
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).
Cesare
___
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
___
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/archive%40mail-archive.com