python 3's adoption

Steven D'Aprano steve at REMOVE-THIS-cybersource.com.au
Fri Jan 29 00:33:19 CET 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