On Thu, 28 Jan 2010 13:20:02 -0500, Terry Reedy wrote: > On 1/28/2010 3:37 AM, Paul Rubin wrote: >> Jonathan Gardner<jgard...@jonathangardner.net> writes: >>> If you're going to have statements, you're going to need the null >>> statement. That's "pass". >> >> Why? Expressions are statements, so you could just say "pass" (in >> quotes, denoting a string literal), or 0, or None, os anything else >> like that, instead of having a special statement. > > As Python is currently compiled, you are right, pass is not needed. A > string becomes the doc attribute, and becomes local var 0, but 0 is just > ignored. I actually expected a load_const but that is now optimized > away. I am not sure this was always true. Perhaps 'pass' is easier than > '0' for mewcomers reading the tutorial, but I have no data.
As I said earlier, a dedicated statement `pass` indicates the intent of the author better than some arbitrary constant. if flag: 0 else: do_something() could be a mistake, perhaps the programmer intended to write "x = 0", but there is no ambiguity with the pass statement. I would hope that PyChecker and the equivalent would flag the use of bare constants in code and give a warning. In any case, while such a idiom works in code, it plays havoc with the interactive interpreter: >>> while 1: ... "pass" ... 'pass' 'pass' 'pass' 'pass' 'pass' Traceback (most recent call last): File "<stdin>", line 2, in <module> KeyboardInterrupt I have trimmed the output for convenience -- in reality, it fills my terminal's output buffer faster than I can hit ctrl-C. Using a constant as a proxy for the pass statement would get obnoxious really fast. -- Steven -- http://mail.python.org/mailman/listinfo/python-list