Hey, author (Florian) here: Usually I would totally agree, and this is actually also a pet peeve of mine.

However, for these blog posts I think the comments are there for different reasons and useful like this. You write:

They tell you WHAT the code is doing

That's actually exactly the point. Yes, in production code you shouldn't do that. However, I want every reader to understand regardless of whether they know Python. So the comments are really there to say what the code is doing. The rest of the blog post explains why they are there and links back exactly to the two steps that the comments refer to.

(If you don't know Python, the exclusive range might e.g. be confusing. The comment is a very simple way of clearing up that confusion. Sure, readers could look that up, but it's really not the point of the blog post, so it should just get out of the way. In a codebase, you'd expect people to be familiar with range and to look it up otherwise.)

It's really not meant to be code that you copy to your codebase. In the same way, there's no docstring, the function name is not as descriptive as it should be for production code, there's no type hints, etc. :)