> `for _ in range(x, y, z)`

Makes little sense, since there's still a fixed amount of steps and normal range(x) could just be used instead. As a matter of fact, it can be replaced with either of these, arguably `repeat_for` version being cleaner:

  for _ in range((y-x+1)//z)
  repeat_for (y - x + 1) // z

And in that one *extremely* unlikely and rare scenario where someone really does need range() with variable start, stop, and step, and doesn't need the returned variable, he can freely still use `for _ in range`. This won't remove it.

Your other two examples:

> `for _ in one_list`
> `for _ in any_other_kind_of_iterable`

Aren't related to the syntax I'm proposing, you even quoted this part yourself:

> there's never a reason to use `for _ in range` anymore.

But your examples don't use range() to begin with.
That's exactly my point ! What you propose is exaggeratedly specific. It will only work to replace exactly `for _ in range(x)`, nothing more. Every Python developer needs to know about `for i in range(x)`, as it is a really common pattern. It feels really strange to switch to a completely different syntax just for the case we don't care about `i`, a syntax that'll never be used for anything else. And to lose its readability if your `range` requires more that one argument.

The Zen of Python tells that way better than I do;
- There should be one-- and preferably only one --obvious way to do it. -> As we won't forbid the syntax with range, why add a second obvious way to do it?
- Special cases aren't special enough to break the rules. -> The new syntax aims at a very specific special case, don't break the rules for it.

-Brice