First day beginner to python, add to counter after nested loop

[Alister]

On Wed, 30 Oct 2013 16:07:47 +0000, Alister wrote:

> On Wed, 30 Oct 2013 15:56:32 +0100, Antoon Pardon wrote:
> 
>> Op 30-10-13 15:22, Alister schreef:
>>> On Wed, 30 Oct 2013 13:42:37 +0100, Antoon Pardon wrote:
>>> 
>>>> Op 30-10-13 13:17, Chris Angelico schreef:
>>>>> On Wed, Oct 30, 2013 at 11:01 PM, Antoon Pardon
>>>>> <antoon.pardon at rece.vub.ac.be> wrote:
>>>>> I broadly agree with your post (I'm of the school of thought that
>>>>> braces are better than indentation for delimiting blocks), but I
>>>>> don't think this argument holds water. All you need to do is be
>>>>> consistent about tabs OR spaces (and I'd recommend tabs, since
>>>>> they're simpler and safer), and you'll never have this trouble.
>>>>
>>>> Easier said than done. First of all I can be as consistent as
>>>> possible, I can't just take code from someone else and insert it
>>>> because that other person may be consistenly doing it different from
>>>> me.
>>> 
>>> I disagree it is very easy.
>> 
>> You can disagree, as much as you want. You don't get to define my
>> experience. Maybe all those things you enumerate are all easy, all
>> taken together they can makes it cumbersome at times.
>> 
>>> 1) make sure you editor is set to inset 4 spaces rather than tab when
>>> pressing the tab key. consistency in your own code is now not an
>>> issue.
>>> 
>>> 2) when importing code from someone else a simple search & replace of
>>> tab with 4 spaces will instantly correct the formatting on code using
>>> tab without breaking code that doesn't.
>> 
>> But why should I have to do all that. When I write other code I just
>> don't have to bother and it is all indented as desired too.
>> 
>>>> Then if you are working on different machines, the settings of your
>>>> editor may not always be the same so that you have tabs on one
>>>> machine and spaces on an other, which causes problem when you move
>>>> the code.
>>>>
>>> that is fixed by setting your environment consistantly but step 2
>>> above will fix it if you forget.
>> 
>> Again why should I have to bother. Why does python force me to go
>> through all this trouble when other languages allow themselves to be
>> happily edited without all this.
>> 
>>>> Also when you have an xterm, selecting a tab and pasting it into
>>>> another it will turn the tab into spaces.
>>> 
>>> Read pep 11 & always use 4 spaces for indentation not tab.
>> 
>> I'll decide how to layout my code.
>> 
>>>> All these things usually can be ignored, they typically only show up
>>>> when you print something and things aren't aligned as you expect but
>>>> with python you are forced to correct those things immediately,
>>>> forcing you to focus on white space layout issues instead of on the
>>>> logic of the code.
>>>>
>>>>> Also, the parser should tell you if you mix tabs and spaces, so that
>>>>> won't trip anything either.
>>>>
>>>> Maybe you mean something different than I understand but a program
>>>> throwing a syntax error because there is a tab instead of a number of
>>>> spaces or vice versa, is something I would understand as tripping.
>>> 
>>> no more than failing to close a brace in a C like language indentation
>>> is the syntax of python you will grow to love it, like most people I
>>> found it distracting at first even though i tended to indent other
>>> code (inconsistently)to make it readable.
>> 
>> I didn't like it at first, accustomed to it a bit and then disliked it
>> again. So no I don't think I will grow to love it. Python is a tool,
>> not a religion, so I can live with it if the tool I use has some
>> featurese I dislike about it. As long as I evaluate the usefulness of
>> the tool as positive I can live with the peeves.
>> 
>> What is more annoying are the people with some kind of need to reason
>> your peeves away, as if it is sacriledge daring to dislike something
>> about the language.
> 
> I guess your experience & mine differ, that is personal taste I am
> certainly not trying to "reason your peeves away" just presenting an
> alternate view.
> 
> Just for fun I knocked up a quick function to parse a poorly writen
> program as described by the OP (with end as a block terminator) and came
> up with the following
> 
> def fixfile(i,o):
>     infile=open(i,'r')
>     outfile=open(o,'w')
>     indent=0 for line in infile:
>         text=line.strip()
>         if text[-3:]=='end':
>             indent=indent -1 continue
>         outfile.write("%s%s\r\n"%(" "*(indent*4),text))
>         if text[-1]==":":
>             indent=indent+1
> 
> obviously this is just proof of concept with no error checking vbut it
> did convert this:-
> 
> def function():
> print "this should be indented but isnt"
> 	print "indented with tab"
>        print "too many spaces"
>     for x in range(10):
> print "this should be indented twice!"
> end print "should be indented once"
> end
>         print "this should not be indented at all!"
> 
> 
> into this:-
> 
> def function():
>     print "this should be indented but isnt"
>     print "indented with tab"
>     print "too many spaces"
>     for x in range(10):
>         print "this should be indented twice!"
>     print "should be indented once"
> print "this should not be indented at all!"

there is a slight typo in my example input file with a missing line break.



-- 
Very few things happen at the right time, and the rest do not happen
at all.  The conscientious historian will correct these defects.
		-- Herodotus