Sample code for the article on for loops

[lpozo]

Where to put new files:

• New files should go into a top-level subfolder, named after the article slug. For example: my-awesome-article

How to merge your changes:

1. Make sure the CI code style tests all pass (+ run the automatic code formatter if necessary).
2. Find an RP Team member on Slack and ask them to review & approve your PR.
3. Once the PR has one positive ("approved") review, GitHub lets you merge the PR.
4. 🎉

[martin-martin]

LGTM, two file name typos and a question about whitespaces around the self-documenting expression in f-strings.

[martin-martin]

flake8 compains and I was also wondering about it, I've generally only seen this used without whitespace:

Suggested change

	print(f"{number = }")
	print(f"{number=}")

pycodestyle, which implements the check, seems to be stubborn about keeping it this way: PyCQA/pycodestyle#1201

$ flake8 break_continue.py 
break_continue.py:11:20: E251 unexpected spaces around keyword / parameter equals
break_continue.py:11:22: E202 whitespace before '}'
break_continue.py:11:22: E251 unexpected spaces around keyword / parameter equals

But I know you're using space around the equals sign also in the f-string tutorial.

So IDK, I guess the linters don't fail on it?

If you decide to change it, you'd also have to change it in the written tutorial.

[lpozo]

If I remember correctly, in one of my previous articles I used this feature without spaces and I guess it was Geir Arne who suggested adding the spaces for readability. However, I don't think this is a written rule.

[martin-martin]

Ok, yeah I'm fine with leaving it considering it passes our linter checks. @gahjelle should we note this somewhere, that we'll ignore E251 and E202 for these cases?

[martin-martin]

Same as in the previous comment, flake8 doesn't like the whitespace:

Suggested change

	print(f"{x = } and {y = }")
	print(f"{x=} and {y=}")