alternatives to making blocks like { } or other ??

[CYBER]

Hello

Is there any other way under python to create blocks ??

instead of

def sth(x):
return x



could i use something else like

def sth(x):
{
return x
}


???

 

[Larry Bates]

Blocks in Python are defined not with {} but rather
with indention. You indent to start a block and
stop indenting when you wish to end it. Seems odd
at first, but turns out to be excellent way to
handle blocks (and to properly format you code).

HTH, Larry Bates

 

[Paul McGuire]

Blocks in Python are defined not with {} but rather
with indention. You indent to start a block and
stop indenting when you wish to end it. Seems odd
at first, but turns out to be excellent way to
handle blocks (and to properly format you code).

HTH, Larry Bates

.... and no religious wars on where the braces are supposed to go, HOORAY!!!

And I'll second Larry's comment - it takes about 10-20 minutes to get used
to, but then you just focus on indentation, and it seems *very* natural -
liberating, even!

-- Paul

 

[Timo Virkkala]

Is there any other way under python to create blocks ??
instead of
def sth(x):
return x
could i use something else like
def sth(x):
{
return x
}

Not without changing the language a lot. But just try the normal way for a
couple of days, you'll get used to it in no time.

 

[Russell Blau]

Not without changing the language a lot. But just try the normal way for a
couple of days, you'll get used to it in no time.

Or you could try this, which works almost exactly as well:

def sth(x):
#
return x
#

<g,d&r>

 

[Christopher Koppler]

Hello

Is there any other way under python to create blocks ??

instead of

def sth(x):
return x



could i use something else like

def sth(x):
{
return x
}


???

Of course there is another way!

Just use # in front of your favourite block separator.

I'm too lazy now to search the archives on who first suggested this,
but it works:

def something(x):
#{
return x
#}

However, as with any and all block separators, this can lead to holy
wars - is the above the 'one true way', or is it one of the following?
All are valid Python...

def something_else(x):
#{
return x
#}

def something_or_other(x):
#{
return x
#}

def something_completely_different(x): #(
return x
#}

 

[CYBER]

Of course there is another way!

Just use # in front of your favourite block separator.

I'm too lazy now to search the archives on who first suggested this,
but it works:

def something(x):
#{
return x
#}

Thank you.

 

[Chad Thompson]

Hello

Is there any other way under python to create blocks ??

instead of

def sth(x):
return x



could i use something else like

def sth(x):
{
return x
}


???

http://www.python.org/doc/Humor.html#parsing

 

[Christopher Koppler]

http://www.python.org/doc/Humor.html#parsing

Ah yes, that was the link, I'd completely forgotten about the Python
humour page!

Oh, and CYBER: my post was *meant* ironic, but Python is flexible
enough that it can be taken at face value - so glad to have been of
help ;-)

 

[Grant Edwards]

... and no religious wars on where the braces are supposed to
go, HOORAY!!!

But as religious wars go, the great Python "tab" debate ranks
right up there.

And I'll second Larry's comment - it takes about 10-20 minutes
to get used to, but then you just focus on indentation, and it
seems *very* natural - liberating, even!

Especially if you've got an editor with a "python mode".

 

[Grant Edwards]

Thank you.

You realize that was a joke, right?

Please, please don't write code like that. You'll be shunned
just like the BASIC programmers who switched to C and pulled
crap like

#define IF if (
#define THEN ) {
#define ELSE } else {
#define ENDIF }

#define WHILE while (
#define DO ) {
#define DONE }

....

I once saw a very complete set of macros like that used to make
a C program look surprising like some brand or other of
structured BASIC. It was impressive in a sick sort of way. The
program didn't actually work right since the author was trying
to impliment a recursive descent parsing algorithm without
using recursion (he didn't know what recursion was, since BASIC
didn't have it), and was attempting to keep a "stack" in a user
space data structure without realizing that's what he was
doing.

 

[Paul McGuire]

You realize that was a joke, right?

<snip>

Actually, it was worse than a joke, in that it looks like it works, but
really doesn't.

If you thought this was somehow magically doing grouping by reading the
commented-out braces, you could end up doing things like:

if condition: #{
do_something if condition is true
#} else: #{
do_something if condition is false
#}

which would have some surprising results (both true and false "paths" are
executed, because they are really the same path, the condition-is-true
path).

So, no, CYBER, this doesn't really work, although most cases will not
complain, and *usually* do what you want. But in general, don't even start
this habit, just use the language features as-designed.

-- Paul

 

[Duncan Booth]

Please, please don't write code like that. You'll be shunned
just like the BASIC programmers who switched to C and pulled
crap like

#define IF if (
#define THEN ) {
#define ELSE } else {
#define ENDIF }

#define WHILE while (
#define DO ) {
#define DONE }

That's not even a very good set of macros.

You want:

#define IF if(((
#define THEN ))){

and then you can have something like:

#define AND ))&&((
#define OR )||(

for added fun and enjoyment. N.B. This cleverly changes the operator
priorities to match the language of your choice.

Safety Warning: The definitions of 'want' and 'cleverly' above may not
exactly match the usual dictionary definitions.

 

[Tim Williams]

<snip>

Actually, it was worse than a joke, in that it looks like it works, but
really doesn't.

If you thought this was somehow magically doing grouping by reading the
commented-out braces, you could end up doing things like:

if condition: #{
do_something if condition is true
#} else: #{
do_something if condition is false
#}

which would have some surprising results (both true and false "paths" are
executed, because they are really the same path, the condition-is-true
path).

So, no, CYBER, this doesn't really work, although most cases will not
complain, and *usually* do what you want. But in general, don't even start
this habit, just use the language features as-designed.

-- Paul

I have to put my 2 cents in here. I love Python, but the one thing I
miss is using {} or something to enclose blocks. I edit in emacs
python-mode, and believe in indentation, but sometimes I'll
inadvertently change a line of code's indentation and it throws the
logic off. I found a bug in one of my programs recently where a line
of code should have been outside of an 'if', but wasn't because I hit
TAB one too many times. A {} block would've caught that. I know that's
just being careless, but I need all the help I can get!

One thing I have done is to put a '#' at the end of the block so I
know not to indent the next line when adding code.

 

[Leif K-Brooks]

I have to put my 2 cents in here. I love Python, but the one thing I
miss is using {} or something to enclose blocks. I edit in emacs
python-mode, and believe in indentation, but sometimes I'll
inadvertently change a line of code's indentation and it throws the
logic off. I found a bug in one of my programs recently where a line
of code should have been outside of an 'if', but wasn't because I hit
TAB one too many times. A {} block would've caught that. I know that's
just being careless, but I need all the help I can get!

And if you came back a few months later, wouldn't you have been confused
about what your code was doing? The beauty of Python's indentation is
that the code does what you'll expect from looking at it.

 

[Greg Ewing]

(he didn't know what recursion was, since BASIC
didn't have it)

That's not quite true. Recursive GOSUBs worked fine in
most versions of BASIC. There just weren't any local
variables or parameter passing, making recursion
somewhat awkward to use...

 

[Greg Ewing]

I found a bug in one of my programs recently where a line
of code should have been outside of an 'if', but wasn't because I hit
TAB one too many times.

And for some reason it wasn't obvious from looking
at the indentation?

In a brace-delimited language, you can get the
opposite problem, which is much worse: the code
*looks* right judging by the indentation, but it
doesn't match the brace structure.

Python is a WYSIWYG language!

 

[Dan Bishop]

....
You realize that was a joke, right?

Please, please don't write code like that. You'll be shunned
just like the BASIC programmers who switched to C and pulled
crap like

#define IF if (
#define THEN ) {
#define ELSE } else {
#define ENDIF }

Also,

#define ELSEIF } else if {

because using "ELSE IF" gives you unbalanced braces.

#define WHILE while (
#define DO ) {
#define DONE }

I don't remember BASIC ever using the syntax "WHILE cond DO ... DONE";
you've probably got it mixed up with another language.

"WHILE cond ... WEND" would be more accurate, but then it's harder to
deal with the ")" on the first line.

Also, you might want to support the QBasic DO...LOOP syntax, which had
four forms:

' 1. Pretest loop (while), positive condition
DO WHILE cond : statements : LOOP
' 2. Pretest loop (while), negative condition
DO UNTIL cond : statements : LOOP
' 3. Posttest loop (do...while), positive condition
DO : statements : LOOP WHILE cond
' 4. Posttest loop (do...while), negative condition
DO : statements : LOOP UNTIL cond

I doubt it's even possible to #define DO, LOOP, WHILE, and UNTIL to
handle all of them.

 

[Tim Williams]

And for some reason it wasn't obvious from looking
at the indentation?

Not right away. It wasn't until I noticed things started running
differently that I ran it in the debugger and saw my error. I had the
offending line in the right place at one point, but after adding some
code, I mistakenly indented that one line when I was indenting the
new code. (I think that's what happened anyway - it's been awhile.)

I don't know about anyone else, but I've spent more than enough time
looking over and over at pieces of my code where a bug existed, not
finding the error sooner because I "knew" this piece of code was
right. Maybe this just says something about my programming ability.

In a brace-delimited language, you can get the
opposite problem, which is much worse: the code
*looks* right judging by the indentation, but it
doesn't match the brace structure.

Python is a WYSIWYG language!

But at least there, I can turn on paren-match mode in emacs and see
what code is in the block. If it's indented inconsistenly, then I can
fix how it looks, but I'm not changing the logic with whitespace.

Enough of this thread. I'll agree to disagree on this.

 

[Andrei Smirnov]

Joke? On my previous job my boss included smthng like that to local
code standard. everybody were supposed to do that.

if python would have compatibility mode for braces, please...

otherwise perl is everywhere because of braces and most people were taking
classes in C or Java or C++. that the only reason besides people like dollar
signs

i do really suffer. i have to use Perl and i know that i have no chance
to convince my new boss (very smart guy) to switch to Python because of
braces. that means wasted time on debugging perl crap code and listening
about Perl 6 future might.

Please, Python writers, do provide braces as compatibility mode.

Give the chance to the world!

Andrei