0

Is there a technical reason why pass must be used to express "no action" in python, rather than letting absence-of-a-statement signify it?

According to the python3.8 doc:

The pass statement does nothing. It can be used when a statement is required syntactically but the program requires no action".

This is followed by the following three examples: 

while True:
    pass  # Busy-wait for keyboard interrupt (Ctrl+C)

class MyEmptyClass:
    pass

def initlog(*args):
    pass  # Remember to implement this!

It looks to me like all these uses of pass are driven by the fact that each of the keywords while, if, class, def, etc. require one-or-more following indented statements. So, if the language were relaxed so that each of those keywords could be followed by zero-or-more statements, then it seems that pass wouldn't be necessary.

If that were done, then the above examples could be written as: 

while True:
    # Busy-wait for keyboard interrupt (Ctrl+C)

class MyEmptyClass:

def initlog(*args):
    # Remember to implement this!

Is there any technical reason why this wouldn't work?

What I'm asking for is either:

  • an example where allowing absence-of-a-statement instead of pass would introduce a parsing ambiguity, or other concrete parsing difficulty (such as the language no longer being LL(1), if it was before) Or,

  • a convincing argument showing that changing python's grammar in this way would not introduce any such difficulty.

Commentary on closure

I don't think this is an opinion question; I am neither offering nor soliciting opinions on whether pass is more or less natural, simple, readable, convenient, or error-resistant than absence-of-a-statement would be.

In particular, an answer or comment that includes the words "explicit is better than implicit" is not what I am ideally seeking.

I don't believe this is a duplicate of "How to use the pass statement" since it is not answered by any of the answers currently attached to that question.

halfer
  • 19,824
  • 17
  • 99
  • 186
Don Hatch
  • 5,041
  • 3
  • 31
  • 48
  • https://stackoverflow.com/a/22612774/476 – deceze Feb 25 '20 at 09:41
  • 6
    Yes, you *could* probably change the Python syntax so it would allow for empty statements. There's very little that's *technically impossible*. But as it is Python has a syntactical requirement for blocks to not be empty, which is likely a conscious design decision ("explicit is better than implicit" and all…), *and* it may make the implementation of the parser easier, so nobody sees a reason to change that. – deceze Feb 25 '20 at 09:44
  • Thanks for the link, @deceze; it's interesting background, but I just read it and found nothing relevant to this question. Also, as I tried to say, I'm really truly not looking for opinions or opinion-based reasons for the original design decision (in particular, "explicit is better than implicit" is exactly the opinion that I was trying to keep out of this discussion by my **NOTE** at the end of the question). – Don Hatch Feb 25 '20 at 10:04
  • 1
    What qualifies as a "technical reason why this wouldn't work" for you? Obviously, if one were to change the syntax to accept empty blocks, one could remove any other potential conflicts (if they were to exist in the first place). Is your question "does the grammar require more modifications than *zero or* one or more statements"? – MisterMiyagi Feb 25 '20 at 10:47
  • 1
    Since any block of the form ``:\n`` is functionally equivalent to ``:\npass\n``, it is trivially possible without loss of functionality to *replace* any block of the form ``:\n`` with ``:\npass\n`` during parsing. Note that ``pass`` itself satisfies ````. That means there trivially exists a parser that is able to interpret empty blocks. – MisterMiyagi Feb 25 '20 at 10:55
  • @MisterMiyagi I moved my answer to your clarification request into the question. – Don Hatch Feb 26 '20 at 06:23
  • 1
    Well, this question sure isn't popular-- even after the accidental immediate closure and subsequent reopen, there are now two downvotes, and one vote to close due to "needs more focus". Really? I did put in quite a bit of effort to make the question very clear and focused, and I've been continually adding more edits trying to make it even more so, although at this point I doubt it's doing any good. Would any downvoters or closevoters care to explain or make constructive suggestions on how the question can be improved? – Don Hatch Feb 26 '20 at 06:41
  • This is a bit abstract, but "a statement that does nothing" and "no statement" aren't really the same thing, trying to replace one with the other may make sense in certain context, but not all. For example, running an empty python program, vs. simply running no program at all. Both actions do "nothing", but we wouldn't always call them equivalent. – Hymns For Disco Feb 26 '20 at 09:02
  • 1
    In the now deleted comments to the now deleted answer by MisterMiyagi, you said you want to keep discussions about different behaviours and pros and cons out of the discussion. Okay, but then… what *can* we really answer here? *Could you imagine a Python with empty blocks, where the block is simply ended by dedenting?* Sure. You could quite obviously produce such a thing if you wanted to. If it makes sense logically, it could be programmed. It would behave differently though in edge cases, so you pretty much have to talk about pros and cons as part of the technical consideration. – deceze Feb 26 '20 at 13:46
  • @deceze, would you please read the question again, especially the part beginning with "What I'm asking for is either" and the two bullet points? They are precise and there is nothing subjective about them. Is there something you don't understand about the two bullet points? – Don Hatch Feb 26 '20 at 13:59
  • 1
    @DonHatch After trying to answer your question, and the subsequent drilling for implementation details, I have to say it is entirely unclear what you would consider an acceptable answer. Do you want someone to actually *implement* the thing? – MisterMiyagi Feb 26 '20 at 14:30
  • @MisterMiyagi Thanks for explaining. I am looking for a clear proof (or counterexample) that "python with empty blocks", as you call it, would work without introducing ambiguity and without requiring a qualitatively more powerful parser. I understand that you believe you have a clear proof in mind, and that the terminology you introduced was clear to you, but I was unable to follow it, so I would need more precise definitions and/or details, or something, in order for me to understand it and be convinced. – Don Hatch Feb 26 '20 at 20:42
  • @DonHatch And that "more precipice definition and/or details [..] in order for **[you]** to understand it and be convinced" makes it completely unclear what exactly is needed. If the answer is specific to your personal expertise and jargon in parsers/interpreters, *and you don't tell us what that is*, it is completely subjective. – MisterMiyagi Feb 26 '20 at 20:45
  • @MisterMiyagi Ah, thank you. The answer is that I understand the terminology and concepts of the python [tokenizer](https://docs.python.org/3/library/tokenize.html) and [grammar](https://docs.python.org/3/reference/grammar.html) documentation, and I will also understand if you talk in terms of formal language classes and properties/parsers thereof (LL(1), LR(0), etc.). I am not familiar with the term/concept `` that you introduced which is apparently neither a token nor a grammar nonterminal, but if it is a precise concept and you can define it, I should be able to follow that. – Don Hatch Feb 26 '20 at 20:59
  • ```` is a level of indentation. I seriously have no idea how that is in any way a term or concept that needs defining, seeing how the very language this question is about is indentation level based. – MisterMiyagi Feb 26 '20 at 21:12

0 Answers0