python 3's adoption
Steven D'Aprano
steve at REMOVE-THIS-cybersource.com.au
Thu Jan 28 18:33:19 EST 2010
On Thu, 28 Jan 2010 13:20:02 -0500, Terry Reedy wrote:
> On 1/28/2010 3:37 AM, Paul Rubin wrote:
>> Jonathan Gardner<jgardner at 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
More information about the Python-list
mailing list