For Counter Variable

[jimbo1qaz]

Am I missing something obvious, or do I have to manually put in a counter in the for loops? That's a very basic request, but I couldn't find anything in the documentation.

 

[Rodrick Brown]

Am I missing something obvious, or do I have to manually put in a counter in the for loops? That's a very basic request, but I couldn't find anything in the documentation.

for idx in <list of elm>: print (idx)

i.e.. for idx in range(10): print(idx)

 

[Chris Angelico]

Am I missing something obvious, or do I have to manually put in a counter in the for loops? That's a very basic request, but I couldn't find anything in the documentation.

You mean, if you want the indices as well as the values? Try the
enumerate() function:

my_list = ["foo", "bar", "quux"]
for idx,val in enumerate(my_list):
print("Element "+str(idx)+" is: "+val)

ChrisA

 

[jimbo1qaz]

Am I missing something obvious, or do I have to manually put in a counter in the for loops? That's a very basic request, but I couldn't find anything in the documentation.

Ya, they should really give a better way, but for now, enumerate works pretty well.

 

[Steven D'Aprano]

Ya, they should really give a better way, but for now, enumerate works
pretty well.

Define "a better way". What did you have in mind that would work better?

 

[Tim Chase]

Define "a better way". What did you have in mind that would work better?

I can only imagine jimbo1qaz intended "a more C-like way". blech.

I **far** prefer The Python Wayâ„¢. The vast majority of the time,
I'm looping over some iterable where indices would only get in the
way of readability. Tuple-unpacking the results of enumerate() is
an elegant way of getting both the items+indices on the seldom
occasion I need the index too (though I'm minorly miffed that
enumerate()'s starting-offset wasn't back-ported into earlier 2.x
versions and have had to code around it for 1-based indexing; either
extra "+1"s or whip up my own simple enumerate() generator).

-tkc

 

[Tim Chase]

You can always use a counter if you don't like our fancy for-each loops;

foolist = [1,24,24,234,23,423,4]
for i in xrange(len(foolist)):
print foolist

http://www.seas.upenn.edu/~lignos/py_antipatterns.html

The first one on the list of anti-patterns is doing exactly this.
Just don't. Ewww. Inefficient, ugly, and harder to read.

Part of learning to write in Python is, well, learning to write
*Python*, not {C,C++,Java,PHP}-in-Python.

-tkc

 

[Mark Lawrence]

You can always use a counter if you don't like our fancy for-each loops;

foolist = [1,24,24,234,23,423,4]
for i in xrange(len(foolist)):
print foolist

http://www.seas.upenn.edu/~lignos/py_antipatterns.html

The first one on the list of anti-patterns is doing exactly this.
Just don't. Ewww. Inefficient, ugly, and harder to read.

Part of learning to write in Python is, well, learning to write
*Python*, not {C,C++,Java,PHP}-in-Python.

-tkc

Maybe my mind is rather more warped than I thought it was, but my first
impression was that foolist was a play on foolish.

I also like the anti-pattern on the link namely:-

for (index, value) in enumerate(alist):
print index, value

Fancy wasting time, money and effort typing those unnecessary round
brackets.

 

[Ethan Furman]

Ya, they should really give a better way, but for now, enumerate works pretty well.

ROFLOL!!

I look forward to the day when you look back on that statement and
think, "Wow, I've come a long way!"

~Ethan~

 

[Dwight Hutto]

ROFLOL!!

I look forward to the day when you look back on that statement and think,
"Wow, I've come a long way!"

It's a function usage. Not to be too serious, there are usually
simpler solutions, and built in functions.

But you usually sticks with what works, and seems timely in return of
data output

 

[Dwight Hutto]

*How* would one implement this better, more simply (for the user, not the

implementator) or in a more readable manner? Chose *any* one of those.

Well if you're learning then the builtin might be more like how we
answer students questions here, than those doing work.

Write out the algorithmic function, and if you find one you can stuff
a few parameters in fine, but you still now how to do it by yourself
algorithmically.

 

[alex23]

Well if you're learning then the builtin might be more like how we
answer students questions here, than those doing work.

STOP SAYING THIS NONSENSE.

Using a pre-defined function is _not_ the "student" approach. Rolling
your own version of an existing function from scratch is _not_ the
"professional" approach.

If you're unable to realise this, then please stop dispensing advice
here like you know something.

 

[Dwight Hutto]

It's a function usage. Not to be too serious, there are usually
simpler solutions, and built in functions.

`enumerate` _is_ a built-in function. Please provide an example of a
"simpler solution".

It's not the simpler solution I'm referring to, it's the fact that if
you're learning, then you should be able to design the built-in, not
just use it.

You don't always know all the built-ins, so the builtin is simpler,
but knowing how to code it yourself is the priority of learning to
code in a higher level language, which should be simpler to the user
of python.

 

[alex23]

It's not the simpler solution I'm referring to, it's the fact that if
you're learning, then you should be able to design the built-in, not
just use it.

Garbage. I don't need to be able to build a SQLAlchemy to use it. I
don't need to be able to build an XML parser to use one. The whole
goddamn point of abstractions is to _ease the cognitive load_ in
building a complex system.

You don't always know all the built-ins, so the builtin is simpler,
but knowing how to code it yourself is the priority of learning to
code in a higher level language, which should be simpler to the user
of python.

"Higher level" means, in part, not _having to give a shit_ about the
sort of low level coding you're obsessed with. If it rocks your world
to declare your own index pointer and increment it on each pass of a
loop, knock yourself out. Just accept that others will criticise your
code for being "unpythonic". Why even use the language if you're not
prepared to _use_ the language...and that means _more than the
syntax_. It extends to the standard library and through to the entire
ecosystem that has developed around it.

People are drawn to Python to get shit done, not to spend pointless
time in recreating every wheel.

 

[Dwight Hutto]

Well if you're learning then the builtin might be more like how we

STOP SAYING THIS NONSENSE.

Using a pre-defined function is _not_ the "student" approach.

What are talking about, I suggested they roll there own in several
responses this week.

Rolling

your own version of an existing function from scratch is _not_ the
"professional" approach.

Yes it is, if you don't know the builtin, and everyone has memory flaws.

If you're unable to realise this, then please stop dispensing advice
here like you know something.

Dude, you know jack shit, so go shovel this bullshit somewhere else,
where people aren't intelligent enough to read the rest of my posts

 

[Dwight Hutto]

Propaganda over...

 

[alex23]

Rolling> your own version of an existing function from scratch is _not_ the

Yes it is, if you don't know the builtin, and everyone has memory flaws.

Let me break this down for you in simple terms.

Code represents experience. Code that is considered important enough
to be in the standard library or as a built-in is something that
encapsulates a _lot_ of experience over time. You in your naive
approach to re-implement will _never capture that experience_. You'll
miss the edge cases that were already addressed. You'll over- or under-
extend the metaphor in ways the original doesn't.

And the first thing any experienced programmer would do when they
encountered your code is _refactor it to use the built-in_.

Dude, you know jack shit, so go shovel this bullshit somewhere else,
where people aren't intelligent enough to read the rest of my posts
CEO: http://www.hitwebdevelopment.com

Is the animated GIF on your website under 60MB yet?

 

[alex23]

what's the fucking point of that question

To highlight the vast gulf between what you think you are and what you
actually produce.

 

[Dwight Hutto]

To highlight the vast gulf between what you think you are and what you

actually produce.

I produce working code, and if it works, then I don't just think...I know.

 

[Littlefield, Tyler]

I produce working code, and if it works, then I don't just think...I know.

Working code != good code. Just an observation. Also, I've noticed a vast differences between someone who can explain their answers as Alix has done on multiple threads you've replied to in the last 5 minutes, and someone who cobbles something together with "your variable isn't being shown right because there's no self.a," which actually really makes no sense at all. Just my $0.02.

--
Take care,
Ty
http://tds-solutions.net
The aspen project: a barebones light-weight mud engine:
http://code.google.com/p/aspenmud
He that will not reason is a bigot; he that cannot reason is a fool; he that dares not reason is a slave.