Is using range() in for loops really Pythonic?

Lie Lie.1296 at gmail.com
Tue May 13 10:58:06 EDT 2008


On May 13, 9:20 pm, Lie <Lie.1... at gmail.com> wrote:
> On May 13, 11:01 am, John Salerno <johnj... at NOSPAMgmail.com> wrote:
>
>
>
> > Ben Finney wrote:
> > > I think that the idiom
>
> > >     for unused in xrange(10):
> > >         # do stuff with no reference to 'unused'
>
> > > is quite common. Is that what you're asking about?
>
> > Yes. I was more or less asking about the specific situation of using a
> > for loop to do something X number of times, but I think the more
> > generalized problem that everyone is talking about -- using a counter
> > variable that is never referenced in the loop -- probably puts the point
> > I was trying to make in a better light.
>
> > The reason I even brought this up is because I remember someone saying a
> > while back (probably here on the newsgroup) that the true use of a for
> > loop was to iterate through a sequence (for the purpose of using that
> > sequence), not to do something X number of times. Once they made this
> > comment, I suddenly saw the for loop in a new (and I believe purer)
> > light. That was the first time I realized what it was really meant
> > to do.
>
> > Using something like:
>
> > for unused in xrange(10):
> >     # do stuff 10 times
>
> > suddenly seemed to me like a hackish way to replace
>
> > for (int i=0; i<10; i++) {
> >     // do stuff 10 times;
>
> > }
>
> > Not that I think the above code (C#) looks all that elegant either. But
> > in C# there is a distinction between the above, and this:
>
> > foreach (int i in sequence)
> >     // do something;
>
> > which is more closely related to the Python for loop.
>
> > Now, you could easily make the argument that the Python for loop is a
> > much simpler tool to accomplish *both* of the above, and I suppose that
> > makes sense. Seems a little silly to have two separate for loops to do
> > these things. I just wasn't sure if the "counter" version of the Python
> > for loop was considered slightly unpythonic.
>
> What was unPythonic, I think, as most people would agree, is to use
> for like this:
>
>  --
>     for i in xrange(len(lst)):
>         pass
>  --
>
> In VB, my language before Python, I've never used For Each even for a
> sequence (Array, in VB), it seems too messy back then. Now, with
> Python that only allowed a foreach statement, I realized that I never
> really needed a for i in range(10) at all. Most of the time the places
> where I need to do that is where the code is just a test code that
> loops a certain number of times (with randomized input data), almost
> never (probably never) met that in a real program code. And even in
> some of those cases, the variables are usually used too (as a test
> argument to the function being tested) or for logging purpose.
>
> On May 13, 8:25 pm, Larry Bates <larry.ba... at websafe.com`> wrote:
> (snip)
>
> > I use it quite often, especially if I want to implement a fixed number of
> > retries on a communications channel.
>
> > -Larry
>
> That still have semantic meaning: 'tries'. If it was me, I'll go to
> the trouble of giving names, since I would use it for logging or
> informational purpose ('first try' 'second try' 'third try' 'no more
> try').
>
> I've never really met a real "do something n times" case, where the
> variable doesn't hold any semantic meaning that I don't want to use
> and is not a test case.
>
> For me, a _ (or any other dummy variable[1]) is good enough and it's
> easy to change if later I realized that I actually need to use the
> variable. I agree though, that i, j, k for unused name is a bad choice
> because single letter names is in common usage in mathematics.
>
> [1] PEP 8 is useless if a certain code base has other agreed
> convention, as long as the name used for a unused name in certain code
> base is consistent (and probably documented), it never becomes a
> problem.

On my last message, I'm tempted not to say: "We need to have /dev/null
for Python" though I proved to fail.



More information about the Python-list mailing list