For-else deserves its own section in the tutorial

[nedbat]

---

📚 Documentation preview 📚: https://cpython-previews--123946.org.readthedocs.build/

[blhsing]

As noted in Discourse, I think the concept of “loop unrolling” may sound too foreign to novices reading a tutorial. The paragraph may serve the purpose just as well without this sentence.

[nedbat]

How about:

As the loop executes, it will run a sequence like if/if/if/else. The if is inside the loop, encountered a number of times. If the condition is ever true, a break will happen. If the condition is never true, the else clause outside the loop will execute.

[blhsing]

Ah yes that sounds to be in much plainer English to me. 👍

[AsgerJon]

I recently wrote about this elsewhere and even included an example:

class Integer:

  __fallback_value__ = 0
  __inner_value__ = None

  def __init__(self, *args) -> None:
    """This constructor method accepts any number of positional arguments.
     It then implements the under-used and underappreciated 'for-loop'
     ending with an 'else' clause. The code in the 'else' block runs 
     after the loop completes. The point is that the 'break' keyword also 
     applies to this block. So if 'break' is encountered, the code in the 
     'else' block does not run. To translate to natural language: 
     
     'Go through each positional argument and when you find an integer, 
     assign it to the inner value. Use the fallback value if you have not found any integer 
     after looking through each positional argument.'  
     
     It is the opinion of this author that the 'else' clause in a loop is
     both underused and underappreciated."""
    for arg in args:
      if isinstance(arg, int):
        self.__inner_value__ = arg
        break
    else:
      self.__inner_value__ = self.__fallback_value__

Hope this helps in some small way!

[JelleZijlstra]

Is this paragraph necessary? Many readers of the tutorial will not be familiar with try/else, so I'm not sure this helps many people.

[nedbat]

I don't expect people to read purely linearly, and this could help cement the semantics in the reader's mind.

[miss-islington-app]

Thanks @nedbat for the PR 🌮🎉.. I'm working now to backport this PR to: 3.12.
🐍🍒⛏🤖

[miss-islington-app]

Thanks @nedbat for the PR 🌮🎉.. I'm working now to backport this PR to: 3.13.
🐍🍒⛏🤖

[bedevere-app]

GH-124563 is a backport of this pull request to the 3.12 branch.

[bedevere-app]

GH-124564 is a backport of this pull request to the 3.13 branch.

[JelleZijlstra]

@nedbat minor feedback: it's good practice to clean up the commit message before merging so that the git log is more understandable. GitHub's default includes the titles of all the commits, which are often not very informative. In this case, I would have shortened the commit message to just:

For-else deserves its own section in the tutorial

Co-authored-by: Jelle Zijlstra jelle.zijlstra@gmail.com

[terryjreedy]

I complete agree that break/continue should be separated from else. But I am sorry I did not see this earlier.

Existing lines 203 to 205 after the patch are incomplete. 'else' is paired with any loop exit.

In a :keyword:!for or :keyword:!while loop, any of :keyword:!break, :keyword:!return, and :keyword:!raise: may be paired with an :keyword:!else clause. (There ``raise`` may come from code executed elsewhere.) If the loop finishes without executing and of the 'exit' statements, the :keyword:!else` clause executes.

Ned, do you want to make another PR, or should I?

[nedbat]

#124591