ending an if statement in python

[velious]

how do i end a statement in python in this following code:

if x == 1:
print "right"
else
print "bad"


but how does the condition end?....like in vbs, an if statement is ended by saying "end if"

[jkd]

You undo a level of indentation.

if x==1:
    print "right"
else:
    print "wrong"
print "moving along"

Bam, that's it.

[shmoove]

Indentation, really? Using whitespace as part of the syntax? Bad python...

shmoove

PS: to velious - I'm not saying jkd is wrong or anything like that, I know nothing about python, just commenting about the language.

[jkd]

Originally Posted by shmoove

Indentation, really? Using whitespace as part of the syntax? Bad python...

shmoove

PS: to velious - I'm not saying jkd is wrong or anything like that, I know nothing about python, just commenting about the language.

Why is that bad? It forces clean coding techniques. Code blocks are just as obvious with proper indentation as they are with begin/ends or { and }.

[liorean]

Actually, I can see the merits of using indentation instead of semicolon termination or {} block creation for a langauge. It makes for a consistent coding style, among other things.

[firepages]

Actually, I can see the merits of using semicolon termination or {} block creation instead of indentation for a langauge. It makes for a consistent coding style, among other things.

[shmoove]

I don't like it. I thought about the fact that it would force "clean coding" as you said, but I think there is too much room for errors with this approach. Whitespace is not "visible" enough.

shmoove

[liorean]

Originally Posted by firepages

Actually, I can see the merits of using semicolon termination or {} block creation instead of indentation for a langauge. It makes for a consistent coding style, among other things.

Grr, you copycat!


Well, compare the following example

if boolean
    do this
    do that
    do thut

(The only thing you can vary there, is the number of spaces/tabs. And even that can be locked.)

To the following examples:

                if
(
   boolean
){
 do this;
                      do that;    do thut;
}

if (boolean)
{
    do this;
    do that;
    do thut;
}

if (boolean){do this;do that;do thut;}

Then tell me where the consistency lies in doing it the {;} way as compared to the indentation way.


(As a note, you can have a look at my code samples as of half a year back - they almost always use indentation for grouping, in a fairly consistent manner. And that in a language which uses the {;} system. They wouldn't lose one iota of clarity if you removed the {;} syntax and instead relied on indentation.)

[shmoove]

liorean - if you submitted code like that to me you would be fired on the spot .
I'm not saying that indentation is bad. You can (and should) write properly indented code in any case.
It's just my opinion that basing the syntax of a language on invisible characters (a.k.a. whitespace) is asking for trouble. But then again, I've never used python (or any other language where whitespace was integral to the syntax) so maybe it's just that I'm set in my ways.

shmoove

[liorean]

The thing is, developers never agree if you allow coding formatting to be any which way, and use block and termination structures instead. Just look at C/C++ - when one developer says that you should always place the opening brace on the line below the control statement, the other say that you should always place the opening brace directly after the statement, and the third only uses braces for multiple statement blocks. While one says you should use a single tab for indentation the other says you should use three spaces, and the third doesn't use indentation at all. When one says that you should always use single line comments for programmer comments, the other uses block comments, and the third separate commentation documents. It's a mess. Sure, there is a certain consistency within groups, but that consistency is frail, and the chosen consistent syntax differs between such groups.

In a langauge where indentation is required, you don't need the {} characters for creating blocks. Then you might find a better use for those characters for some other programming construct. Same goes for semicolon, since a newline without an added level of indentation means the previous statement is terminated.

[firepages]

This consistency lies in the compilation or tokenization to byte-code, more or less more whitespace (sensibly ignored) and the tokenized output is the same , now thats the PHP interpreter , but you see what I mean, edit that python code of Jasons machine in vi + then edit it on a mac & back doing a spell check on win32, then try and run it... (I know some bugger will proove me wrong but you get the point !)

So OK that won't happen in real life , but seriously, even moving from win32 to unix can be a pain unless you are aware of the difference in line breaks/carriage returns , you simply can't break some languages that way , to me thats a good thing, some you can & thats IMO less of a good thing.

T_OPEN_TAG :: <?
T_STRING :: php
T_WHITESPACE ::
T_IF :: if
T_WHITESPACE ::
UNKNOWN(
T_VARIABLE :: $boolean
UNKNOWN)
UNKNOWN{
T_DO :: do
T_WHITESPACE ::
T_STRING :: this
UNKNOWN;
T_DO :: do
T_WHITESPACE ::
T_STRING :: that
UNKNOWN;
T_DO :: do
T_WHITESPACE ::
T_STRING :: thut
UNKNOWN;
UNKNOWN}
T_CLOSE_TAG :: ?>

[liorean]

Sure, the tokenisation provides consistency, but that's beyond the point. You could use two radically different syntaces and still get the same tokenised machine or runtime code from it. What we're talking about is the original syntax.

As for the whitespace you normally transfer sourcecode files in ASCII mode. That means that the files are normalised to use only your operative systems default line break. However, if you happen to use binary transmission of the files, Mac OS X and Linux both use LF, I believe. (Haven't checked, though.) Classic Mac OS used CR. DOS, OS/2 and Windows uses CRLF, and IBM uses NEL on some of their systems. These can all be handled by a smart editor or a smart interpreter.

Just convert the following line breaks used per default by some systems:
- U+000d, U+000a
- U+000d, U+0085
- U+000d
- U+0085
- U+2028
into the Unix standard line break character:
- U+000a
before you do any parsing, and you have only a single line breaking character to worry about. As an example of a language that does this, look at HTML. Or XML. Or JavaScript. (Only XML1.1 converts U+2028 to U+000a before parsing, but they all do the rest of them.)

The benfit of the indentation way of providing grouping is that you have only one way of writing a certain statement. You can rely on all other writers to use the same coding conventions as you in that language. And really, what's the benefit of using something like this:

int a(bool b)
{
    int c;
    if(b)
    {
        c=42;
    }
    else
    {
        c=11;
    }
    return c;
}

a(true);

instead of using something like this:

int a (bool b)
    int c
    if (b)
        c=42
    else
        c=11
    return c
a(true)

?

[firepages]

You could use two radically different syntaces and still get the same tokenised machine or runtime code from it. What we're talking about is the original syntax.

& thats partially my point , in python one or the other would never get that far as it would break the parser, if a language or logic flaw breaks the parser then thats acceptable to me ,but not someone elses subjective view of whats the best indentation.

I fully appreciate why anyone would defend a set coding style as it has so many advantages especially in larger collaberative projects, .... as to which is best, tabs or spaces, camel case or whatever is another feud (and don't they just turn into those sometimes)

so (and a very daft analogy this is..) given the choice of a car that would only brake if you first scratched your nose before pressing the pedal , and one that just braked regardless (still requiring the pedal push of course) , my preference is the latter , as long as the effect is the same.

[liorean]

Originally Posted by firepages

so (and a very daft analogy this is..) given the choice of a car that would only brake if you first scratched your nose before pressing the pedal , and one that just braked regardless (still requiring the pedal push of course) , my preference is the latter , as long as the effect is the same.

I would rather draw the analogy of having a single pedal break, or having fifteen of them scattered on the floor together with the twenty gas pedals, and that other pedal that I don't know the English name for...

Anyway, we're getting severely offtopic - though I like the discussion well enough, and the thread is kinda solved already...

[Antoniohawk]

and that other pedal that I don't know the English name for...

Clutch.