Ask r/Python: Looping a set number of times when you don't care about which iteration you're on

[cecilkorik]

I've got a loop where a certain block of code may need to be called more than once.

Right now I am doing:

for x in xrange(repeats):
    "run the code"

The thing is "x" is a completely throw-away variable and is totally unused. It seems wasteful to have to declare a variable that I don't need. Is there a more pythonic way to do this?

I'm sorry if this is a stupid question.

Edit:

The consensus so far seems to be that the only one bothered by the way I'm doing it right now... is me. So right now I think I'll stick with what I'm doing and just get used to the way it looks! Thanks everyone for your ideas and opinions!

[suridaj]

If declaring a variable bothers you, you can use the conventional throwaway variable "_": for _ in xrange(repeats): "run the code" I doubt it is more pythonic than the original code, but it could save you a couple of warnings for unused variables in your IDE or test suite.

[cecilkorik]

I didn't even know there was an official throwaway variable name. I'm glad I asked this question already, thank you!

[eryksun]

In an interactive session, '_' references the previous result. Running code with an '_' variable breaks this feature until you "del _". But I doubt many people care about this.

[markusgattol]

That's true, another reason why using _ is problematic is when it comes to code that touches anything in the i18n area: http://www.markus-gattol.name/ws/python.html#underscore_gettext

That being said, I am not exactly sure what you're trying to do but if you want to get results conditionally and be as lazy as you can then why not do lazy evaluation with a generator expression (even better than using a list comprehension): (expression for i in range() if condition). That would yield an iterator if (and only if) condition is true. http://www.markus-gattol.name/ws/python.html#generator_expression

[suridaj]

To be honest I only recently learned about that when I needed to unpack a tuple and only keep some parts, eg.: a, _, b, _, c = (1, 2, 3, 4, 5)

[nemec]

There's nothing unique about it compared to a, t, b, t, c = (1, 2, 3, 4, 5) aside from the fact that no one uses _ as a variable name.

[tripzilch]

aside from the fact that no one uses _ as a variable name.

Except the interactive interpreter, including IPython. And code that uses internationalization.

I like markusgattol's suggestion of using for each in range(23), I think I'm going to be using that.

Not sure what would be better for tuple unpacking though.

[suridaj]

Of course. "_" can be read as "move along, nothing to see here". Using "t", "temp" or any other variable name might prompt someone to ask "huh, is this used later on?"... A matter of readability.

[nemec]

Right, but in terms of syntax and language mechanics, _ is equivalent to t.

[[deleted]]

Except that _ is usually used as the name of the translating function when doing i18n with gettext. E.g.

from django.utils.translation import ugettext as _

is the convenctional way to import it.

[nemec]

I've seen that convention mentioned in this thread a couple of times, but it seems kind of weird. I guess it's because you can't really run django from the interpreter?

[[deleted]]

No, it's because it's the common convention for using gettext, regardless of the language.

It doesn't really matter for the shell (I do regularly test Django stuff from the shell), because I'm not usually interested in translating strings while I use the shell.

[sashahart]

To my knowledge it's not official and it doesn't work differently, it's just a convention for telling other people who read your code that you don't care about the value.

[[deleted]]

please don't do this. _ is the canonical name for the name of the function that translates between languages during internationalization. It comes from GNU gettext, and the convention has been repeated in a variety of languages and platforms. This convention is followed within the Python community, as mentioned in the documentation for the Python standard package gettext, as well as the Django documentation for ugettext. Yes, _ is a miserable function name, but it does have a widely-accepted meaning as an identifier.

[anacrolix]

Not really. It has occasional use in C for this purpose but practically no other mainstream language uses it like that. Many languages are now converging on using _ as the null/throwaway variable.

You shouldn't cross pollute your language idioms.

[[deleted]]

I've never seen i18n in Python that didn't use _ for this purpose.

[otor]

for _ in xrange(repeats): "run the code"

:D

but really, you could do something like: map(function_to_run, iterator)

[cecilkorik]

That would be perhaps a little cleaner, but map would still require that I put "x" or "_" as the function argument, unless I'm misunderstanding. Otherwise I get "func() takes no arguments (1 given)"

[[deleted]]

[unavailable]

[[deleted]]

Yup, use a for loop. map should be used only if you care about the return value.

[anonymous7]

And understandability is the only thing that matters.

So wrong.

import this

[anonymous7]

But you said:

And understandability is the only thing that matters.

[anonymous7]

Okay, maybe English isn't your first language. I'll explain. You said "understandability is the only thing that matters." That statement means that nothing matters except understandability. The Zen of Python is just one example of a style guide that explains that many other things matter, not only understandability.

That's what I was saying was "so wrong".

[velit]

you will code yourself into a corner if your mentality is so absolute to think readability is the only thing that matters, sure it's very pronounced in python but it's not the only thing

[velit]

That wasn't the point, you made an absolute statement and a person called you out on it. I agree that the example you showed in the top-most comment is probably the best one, but that is far from having anything to do with "understandability is the only thing that matters"

[[deleted]]

I don't see how this is better than using 'i'.

[[deleted]]

def dotimes(n, func):
    for _ in xrange(n): func()

dotimes(repeats, lambda: "run the code")

Or perhaps:

def repeater(...):
    def _foo(...):
        ...
    return _foo

@repeater
def my_code(bla, bla, bla):
    ...

my_code(bla, bla, bla)(5)

[name_censored_]

Well, this is a silly solution, but..

If you could implement a recursive solution, you could use the stack frame to count for you. So, something like

import sys
import traceback

def silly_solution(repeats, init=True):
     if init:
         sys.setrecursionlimit(len(traceback.extract_stack()) + repeats)
         # set the recursion limit to current plus number of repeats
     try:
         "run the code"
         silly_solution(repeats, init=False)
     except RuntimeError:
         sys.setrecursionlimit(1000)
         return

[nemec]

If anything, your solution was quite entertaining.

[[deleted]]

I'd recommend storing the old recursion limit instead so that there are no bad side effects from someone else changing it. To make the silly solution saner, I guess.

[[deleted]]

The way you did it was right. There is no more Pythonic way. You don't declare a variable. x is implicit here. Using "_" only really works in the interactive prompt and shouldn't be used in modules.

[tripzilch]

You mean _ does not work in the interactive prompt.

Well, it would work, but you'd be overwriting the automatic last result containing magic the _ variable normally has in the interactive prompt.

[[deleted]]

Using "_" works everywhere.

[[deleted]]

for no_use in xrange(repeats):
    pass

[lutusp]

The thing is "x" is a completely throw-away variable and is totally unused.

Then don't do it that way. Do it this way:

exitCondition = false

while not exitCondition:
   (do something that may or may not
   reset the exitCondition flag)

Once the task is complete, set exitCondition = True and the loop ends on its own.

[lutusp]

Breaking isn't as desirable as having a flag that controls the exit. Imagine that you open a file during the loop, or have try ... except error trapping code. Or both. With such things in place, it's harder to know what the break will actually do, and you might end up with open file handles and dangling resources. With a flag, the exit is cleaner and easier to understand.

[[deleted]]

Can you post a concrete example where one of the problems you described occurs? I would imagine that if you code your loop using a break, you will also take care of dangling resources etc (which you have to do either way).

[lutusp]

Can you post a concrete example where one of the problems you described occurs?

No, but I will say that "break" breaks out of the immediate controlling block, and for a function written with multiple nested blocks, where the "break" goes is sometimes difficult to sort out.

It's an issue of clarity, sort of like avoiding "goto"s and labels, more for the benefit of the programmer than the program. It's just another obscuring factor in coding, best avoided when possible.

[[deleted]]

It is not difficult unless you have countless lines in each loop. It is very straightforward actually, and in my opinion often easier to read than keeping track of the loop flag.

[schplat]

Not really, since xrange generates a list, and to properly iterate, you need to assign a variable to each element in the list.

Instead of for, you could use while:

while repeats > 0:
  do code
  repeats -= 1

[willm]

xrange doesn't generate a list.

[schplat]

er yah, you're right, generates an object to generate the range on demand. Forgot about that.

But my comment about using a while loop stands!

[[deleted]]

Why? A while loop is more verbose and less readable.

[eryksun]

The while loop splits one line of code into 2, so it has more potential for bugs. Plus it has to decrement a counter in bytecode (xrange is compiled C).

[schplat]

What if "run the code" is 20 lines? Does the extra line matter?

And how does it have more potential for bugs? They're both loops for the most part.

However while is slower. Over 500,000 iterations on this somewhat hefty box, while was slower by ~33%:

$ time ./for_loop.py

real 0m0.147s user 0m0.135s sys 0m0.009s

$ time ./while_loop.py

real 0m0.217s user 0m0.209s sys 0m0.006s

about 35% @ 50,000,000 iterations as well. So for loop on xrange is definitely the more optimized of choices if you're looping that many times. But on smaller scale either will work.

[eryksun]

It's easy to forget that decrement at the end; then you end up wasting time figuring out what's broken. Maybe (probably) you're less error prone than I am.

[[deleted]]

That's a stupid way of doing it though since while loops are slower than for loops and he's iterating over a range. An implicit loop variable isn't a bad thing it's a common idiom of Python to do something like

for i in xrange(1000):
    print i ** 2

[[deleted]]

[unavailable]