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]

On Sep 23, 2012, at 12:42 PM, jimbo1qaz <jimmy...@gmail.com> wrote:

> 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)

> --
> http://mail.python.org/mailman/listinfo/python-list

[Chris Angelico]

On Mon, Sep 24, 2012 at 2:36 AM, jimbo1qaz <jimmy...@gmail.com> wrote:
> 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]

On Sunday, September 23, 2012 9:36:19 AM UTC-7, jimbo1qaz wrote:
> 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]

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



--
Steven

[Tim Chase]

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]

On 09/23/12 18:52, Alec Taylor wrote:
> 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[i]

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]

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.

--
Cheers.

Mark Lawrence.

[Ethan Furman]

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

--
Best Regards,
David Hutto
CEO: http://www.hitwebdevelopment.com

[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]

On Sep 25, 8:58 am, Dwight Hutto <dwightdhu...@gmail.com> wrote:
> 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]

On Sep 25, 8:26 am, Dwight Hutto <dwightdhu...@gmail.com> wrote:
> 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]

On Sep 25, 9:39 am, Dwight Hutto <dwightdhu...@gmail.com> wrote:
> 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
>> answer students questions here, than those doing work.
>
> 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]

On Sep 25, 9:49 am, Dwight Hutto <dwightdhu...@gmail.com> wrote:
> 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.

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?

[Dwight Hutto]

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

yeah a command line called convert, and taking out a few jpegs used to
convert, and I can reduce it to any size, what's the fucking point of
that question other than ignorant rhetoric, that you know is easily
fixable?

[alex23]

On Sep 25, 10:18 am, Dwight Hutto <dwightdhu...@gmail.com> wrote:
> 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]

On 9/24/2012 6:25 PM, Dwight Hutto wrote:
>> 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.
>

> 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.

[Dwight Hutto]

>> Just my $0.02.
>
I'd estimate it at that value anyday.

[Dwight Hutto]

On Mon, Sep 24, 2012 at 8:32 PM, Littlefield, Tyler <ty...@tysdomain.com> wrote:
> On 9/24/2012 6:25 PM, Dwight Hutto wrote:
>>>

>>> 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.
>>
>> 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

I might have mispoke, forgive me for knowing several languages,and
getting a little class syntax wrong,. It's called computer science and
interdisciplinary study you dumb fucking double digit IQ'd twit.

>> because there's no self.a," which actually really makes no sense at all.

That was in a class scenario

>> 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.
>

> --
> http://mail.python.org/mailman/listinfo/python-list

[Paul Rubin]

alex23 <wuw...@gmail.com> writes:
> To highlight the vast gulf between what you think you are and what you
> actually produce.

By now I think we're in the DNFTT zone.

[Dwight Hutto]

Anything else bitch?

[Thomas Rachel]

Am 25.09.2012 01:39 schrieb Dwight Hutto:

> 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.

In some simpler cases you are right here. But the fact that you are able
to design it doesn't necessarily mean that you should actually use your
self-designed version.

But what you post suggests is important as well: if using the neat fancy
built-in simplifications, you should always be aware what overhead they
imply.

An example:

Let l be a big, big list.

for i in <some source>:
if i in l: <do something>

This looks neat and simple and doesn't look as expensive as it really is.

If l is converted to a set beforehand, it nearly looks the same, but it
is simpler.

So even if you use builtins, be aware what they do.

> 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.

When learning Python, it often happend me to re-inven the wheel. But as
soon as I saw the presence of something I re-wrote, I skipped my
re-written version and used the built-in.


Thomas

[Dwight Hutto]

> By now I think we're in the DNFTT zone.

> --
Taking a bite yourself there buddy. Hop under the bridge, and
comment...it make you a troll, and you're trying to feed yourself with
pile on comment from the rest of the under bridge dwellers.

[Steven D'Aprano]

On Tue, 25 Sep 2012 07:53:55 +0200, Thomas Rachel wrote:

> When learning Python, it often happend me to re-inven the wheel. But as
> soon as I saw the presence of something I re-wrote, I skipped my
> re-written version and used the built-in.

And me.

Not just Python either. The very first piece of code I wrote on a Linux
machine was a shell script that (very badly, and even more very slowly)
counted the number of files in a directory. 20 lines (if I remember
correctly) to duplicate a simple:

ls | wc -l


It was a humbling lesson to always check what features a programming
environment or language offers before reinventing the wheel with four
sides.



--
Steven

[Chris Angelico]

On Tue, Sep 25, 2012 at 11:32 AM, Dwight Hutto <dwight...@gmail.com> wrote:
>> By now I think we're in the DNFTT zone.

>> --
> Taking a bite yourself there buddy. Hop under the bridge, and
> comment...it make you a troll, and you're trying to feed yourself with
> pile on comment from the rest of the under bridge dwellers.

Dwight/David, may I courteously recommend and request that you refrain
from posting until you've calmed down a little? You're really not
doing your reputation much good. Unfortunately you're also impacting
the reputation of the list/newsgroup. People will come here looking
for help, and will see that people are biting and scratching at one
another[1], and will turn away. And that, in turn, reflects badly on
the language.

It's fine to disagree with someone - that's one of the best ways to
explore a problem space and turn up more information. What's not fine
is the bad language and vitriol.

To Paul Rubin (whose name and citation were omitted from Dwight's
quoted text): My apologies, I fear I am feeding a troll here. But
something needed to be said.

[1] Galations 5:15, eg http://bible.cc/galatians/5-15.htm - come to
think of it, the whole chapter applies fairly well here.
http://www.biblegateway.com/passage/?search=Galatians+5

ChrisA

[Mark Lawrence]

Thankfully easier in a relatively concise language like Python as
opposed to (say) Java. Which reminds me, in what version of Python are
we getting the singletonMap? :)

--
Cheers.

Mark Lawrence.

[wxjm...@gmail.com]

I wrote my first program on a PDP-8. I discovered Python
at release 1.5.?

Now years later... I find Python more and more unusable.

As an exemple related to this topic, which summarizes a
little bit the situation. I just opened my interactive
interpreter and produced this:

>>> for i in range(len(s)-1, -1,-1):
... '{} {}'.format(i, s[i])
...
'2 c'
'1 b'
'0 a'

I did it so many times with a reverse/enumerate combination,
I'm unable to do it again, I simply do not remember!


One another really annoying aspect of Python, illustrated
in my previous code: ''.format() .
Was it not supposed to be *the* new formating scheme?

I'm toying more and more with the go language. I really
appreciate and rediscover the strictness I learned with
Pascal.

jmf

[wxjm...@gmail.com]

[Mark Lawrence]

On 25/09/2012 10:32, wxjm...@gmail.com wrote:
> I wrote my first program on a PDP-8. I discovered Python
> at release 1.5.?
>
> Now years later... I find Python more and more unusable.

Dementia is a growing problem for us older people :)

>
> As an exemple related to this topic, which summarizes a
> little bit the situation. I just opened my interactive
> interpreter and produced this:
>
>>>> for i in range(len(s)-1, -1,-1):
> ... '{} {}'.format(i, s[i])
> ...
> '2 c'
> '1 b'
> '0 a'
>
> I did it so many times with a reverse/enumerate combination,
> I'm unable to do it again, I simply do not remember!

Based on things I've read as I've never used it myself try using Perl as
that should simplify things for you.

>
>
> One another really annoying aspect of Python, illustrated
> in my previous code: ''.format() .
> Was it not supposed to be *the* new formating scheme?

That might have been the original intention but it's not going to take
over the world as there's too much legacy code using the C style %
formatters. IIRC isn't there also something about string templates???

>
> I'm toying more and more with the go language. I really
> appreciate and rediscover the strictness I learned with
> Pascal.

So go and use go as nobody here is stopping you.

>
> jmf
>

--
Cheers.

Mark Lawrence.

[Chris Rebert]

On Tue, Sep 25, 2012 at 2:46 AM, Mark Lawrence <bream...@yahoo.co.uk> wrote:
> On 25/09/2012 10:32, wxjm...@gmail.com wrote:
>>

>> I wrote my first program on a PDP-8. I discovered Python
>> at release 1.5.?
>>
>> Now years later... I find Python more and more unusable.

<snip>

>> I'm toying more and more with the go language. I really
>> appreciate and rediscover the strictness I learned with
>> Pascal.
>

> So go and use go as nobody here is stopping you.

Well, the PSU might, except they emphatically do not exist...

Cheers,
Chris
--
PEP-401 compliant

[Mark Lawrence]

On 25/09/2012 10:53, Chris Rebert wrote:

[snip]

>
> Well, the PSU might, except they emphatically do not exist...

I know that they exist but if I admit to it I'd have to shoot myself.
If I can get the bra off of the debutante that is.

>
> Cheers,
> Chris
> --
> PEP-401 compliant
>

--
Cheers.

Mark Lawrence.

[Tim Chase]

As a beginning Pythonista, I found myself doing the same thing. I
implemented my own CSV parsing until I discovered how easy it was to
do with the built-in library. I implemented my own option-parsing
until I found optparse/argparse. I implemented config-files until I
found ConfigFile.

Coming from C where just about *nothing* is in the stdlib and Java &
PHP where only some core functionalities are in the stdlib, to
Python where just the list of modules in the stdlib is humongous, I
have to make http://docs.python.org/library/ my first stop before I
try implementing anything I think might have even a remote
possibility of being there.

-tkc

[Mark Lawrence]

On 25/09/2012 11:57, Tim Chase wrote:

[snip]

>
> Coming from C where just about *nothing* is in the stdlib and Java &
> PHP where only some core functionalities are in the stdlib, to
> Python where just the list of modules in the stdlib is humongous, I
> have to make http://docs.python.org/library/ my first stop before I
> try implementing anything I think might have even a remote
> possibility of being there.
>
> -tkc

I find the above paragraph amusing given the recent discussion about the
Java singletonMap, i.e. it's someone that is rarely if ever needed but
core functionalities are missing, how strange.

I think the next port of call after the standard library should be pypi
followed by the search engine, possibly targetted at sites like github,
followed by a question here. I'm not certain about the next step, help
please.

--
Cheers.

Mark Lawrence.

[Steven D'Aprano]

On Tue, 25 Sep 2012 11:16:40 +0100, Mark Lawrence wrote:

> On 25/09/2012 10:53, Chris Rebert wrote:
>
> [snip]
>
>> Well, the PSU might, except they emphatically do not exist...
>
> I know that they exist

You are delusional. The PSU certainly do not exist and it is a myth that
they

[Chris Angelico]

Something got cut off. I wonder if Steven's computer's Power Supply
Unit just let off its magic smoke...

ChrisA

[Prasad, Ramit]

Tim Chase wrote:
> [snip] 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).


Starting offset is in Python 2.6, unless you meant
earlier than 2.6.

>>> for idx, x in enumerate( xrange(5), 10 ):
... print idx, x
...
10 0
11 1
12 2
13 3
14 4

This email is confidential and subject to important disclaimers and
conditions including on offers for the purchase or sale of
securities, accuracy and completeness of information, viruses,
confidentiality, legal privilege, and legal entity disclaimers,
available at http://www.jpmorgan.com/pages/disclosures/email.

[Ramchandra Apte]

There are children (such as me) here!

[Ramchandra Apte]