Style question...

[Anthony Roberts]

If I end indentation levels with "pass" statements, will I piss off people
that have to read my code? eg:

for i in xrange(0,5):
if i:
print i
pass
print i * -1
pass

I ask for two reasons... a) it helps emacs figure it out, and b) I'm more
comfortable ending compound statements with a token.

 

[Peter Hansen]

If I end indentation levels with "pass" statements, will I piss off people
that have to read my code? eg:

for i in xrange(0,5):
if i:
print i
pass
print i * -1
pass

I ask for two reasons... a) it helps emacs figure it out, and b) I'm more
comfortable ending compound statements with a token.

Sorry, but yes, I find that ugly. If you're just starting out with
Python, please just give it a shot without that approach for a while
and see whether you become much more comfortable *without* the token
than you ever were with it.

-Peter

 

[Chad Netzer]

If I end indentation levels with "pass" statements, will I piss off people
that have to read my code? eg:

for i in xrange(0,5):
if i:
print i
pass
print i * -1
pass

I do this myself at times, to help emacs. But I'd suggest you not
overdo it. It is more "pythonic" to simply leave the line blank (ie.
vertical whitespace), than have "pass" everywhere.

Pressing backspace once (to undo the auto-indent that emacs gives inside
loops) is less typing than 'pass'. And if you need to reindent large
chunks of code, you are better off using emacs block indent/dedent
feature than relying on "pass" as defacto block delimiter (this has been
my experience)

Also, look into the pindent.py script (included in Python's "Tools"
directory with the distribution), for another way of producing block
closing tokens.

 

[Sean Ross]

If I end indentation levels with "pass" statements, will I piss off people
that have to read my code? eg:

for i in xrange(0,5):
if i:
print i
pass
print i * -1
pass

I ask for two reasons... a) it helps emacs figure it out, and b) I'm more
comfortable ending compound statements with a token.

Hi. I tried to do something like that too, early on. (I recall being
frustrated to find I couldn't just alias "end = pass", and use 'end' as a
block delimiter... heh). I didn't actually want to use 'end' (I like
significant whitespace), I just saw a lot of posts with complaints about
"no-block-delimiter", and I thought, I wonder if you can make one. Well, you
can (of course), but not like that.

Anyway. I think the suggested idiom for people who must have a visible block
delimiter is "# end <keyword>". If you use this, I think emacs can "figure
it out" (I don't know, I don't use emacs, but I think pymode can handle
this), and you can also use Tools/scripts/pindent.py, if you like.

"from pindent.py"
# This file contains a class and a main program that perform three
# related (though complimentary) formatting operations on Python
# programs. When called as "pindent -c", it takes a valid Python
# program as input and outputs a version augmented with block-closing
# comments. When called as "pindent -d", it assumes its input is a
# Python program with block-closing comments and outputs a commentless
# version. When called as "pindent -r" it assumes its input is a
# Python program with block-closing comments but with its indentation
# messed up, and outputs a properly indented version.

[snip]

# Secret feature:
# - On input, a block may also be closed with an "end statement" --
# this is a block-closing comment without the '#' sign.

Hmm. Looks like you can also use "end", or perhaps 'end' . I don't know if
the <keyword> is optional or not, having never used this module.
Anyway, if you use this format, then, if someone doesn't like seeing all
that noise when they read your code, they can strip it out with
"pindent -d". Handy. And, when you read other peoples code, you can clutter
it up nicely with "pindent -c". Best of both worlds, really.

HTH
Sean

 

[Bruno Desthuilliers]

If I end indentation levels with "pass" statements, will I piss off people
that have to read my code? eg:

for i in xrange(0,5):
if i:
print i
pass
print i * -1
pass

*yuck*

(oops, sorry...)

Bruno

 

[Anthony Roberts]

Sorry, but yes, I find that ugly. If you're just starting out with

Python, please just give it a shot without that approach for a while
and see whether you become much more comfortable *without* the token
than you ever were with it.

Well, when in Rome I guess.

Having the closing token at the same indent level as the compound statement
is ugly anyway.

 

[John Roth]

If I end indentation levels with "pass" statements, will I piss off people
that have to read my code? eg:

for i in xrange(0,5):
if i:
print i
pass
print i * -1
pass

I ask for two reasons... a) it helps emacs figure it out, and b) I'm more
comfortable ending compound statements with a token.

Isn't there some kind of emacs plugin, macro or mode that
handles Python? I'm not an emacs person, but I've heard that
there is, and I would expect that it would handle things like
auto-indent for you.

John Roth

 

[Anthony Roberts]

Isn't there some kind of emacs plugin, macro or mode that

handles Python? I'm not an emacs person, but I've heard that
there is, and I would expect that it would handle things like
auto-indent for you.

There is, but it can't tell if I want some stuff indented or not.

 

[Anthony Roberts]

Hi. I tried to do something like that too, early on. (I recall being

frustrated to find I couldn't just alias "end = pass", and use 'end' as a
block delimiter... heh). I didn't actually want to use 'end' (I like
significant whitespace), I just saw a lot of posts with complaints about
"no-block-delimiter", and I thought, I wonder if you can make one. Well, you
can (of course), but not like that.

Anyway. I think the suggested idiom for people who must have a visible block
delimiter is "# end <keyword>". If you use this, I think emacs can "figure
it out" (I don't know, I don't use emacs, but I think pymode can handle
this), and you can also use Tools/scripts/pindent.py, if you like.

My emacs can't handle it... I think I'm going to subject myself to a bit
more of the Python way to see if I change my mind.

 

[Anthony Roberts]

*yuck*

LOL!

I'm sorry.

 

[Erik Max Francis]

What's the keystroke for that?

C-c < and C-c >.

 

[Chad Netzer]

Sure it can. Hit tab or backspace.

I think the problem is that people learn to reindent chunks of code by
the following technique:

<arrow down>
<TAB>
<arrow down>
<TAB>
..
..
..


This has the unfortunate consequence of breaking your code when you hit
multiply indented loops, nested functions, function or loop boundaries,
etc.

However, by sticking 'pass' at the end of loops, emacs's python-mode
will assume a dedent and preserve the indenting at boundaries.

But, this technique will STILL fail on multiply nested loops, etc.
(emacs does it's best, but it cannot mind read) So it is a terrible
habit to get into, because it WILL cause you problems if relied upon
blindly.

So, it is better to NOT rely on the 'pass' crutch, and instead rely on
the python mode operations for reindenting blocks of code (which Eric
provided; surely this is becoming a FAQ)

So, to Anthony, if you are using the TAB key to indent blocks of code,
and relying on 'pass' to make it easier, just be aware that this
technique is NOT robust.

 

[Erik Max Francis]

But, this technique will STILL fail on multiply nested loops, etc.
(emacs does it's best, but it cannot mind read) So it is a terrible
habit to get into, because it WILL cause you problems if relied upon
blindly.

So, it is better to NOT rely on the 'pass' crutch, and instead rely on
the python mode operations for reindenting blocks of code (which Eric
provided; surely this is becoming a FAQ)

Agreed. If you're going to write code in a particular language, you
should fully embrace the language and its style, or move on to something
that you feel more comfortable with. These kind of crutches will only
serve to bite you later -- they aren't panaceas, and you may forget to
use them or be hobbled when interacting with someone else's code (where
you're not going to convince others to use your crutches). There's also
an indirect effect; if I'm reading someone else's Python code, and, say,
see someone using semicolons as statement delimiters on every line, I'm
not exactly going to be struck with a great deal of confidence.

 

[Anthony Roberts]

C-c < and C-c >.

Thanks.

BTW: I've had your website bookmarked since 2001 because a number of the
things there are useful and cool.

 

[Anthony Roberts]

I think the problem is that people learn to reindent chunks of code by

the following technique:

Yup. In emacs, it is robust for C and C decendants. Indent region can do it
to entire files.

It's good for structural modifications when you want to change some outer
loop that ends up changing the indent/nesting level of some inner loop.

In Java, which is where I really started to lean of that feature heavily, it
comes with so *many* data structure classes that even though they mostly
share interfaces, you still come up with a cleaner way later on and go back
to change it. I'm finding Python is more a matter of "for x in
<whatever>:"...

But I still change my mind sometimes.

 

[Anthony Roberts]

Agreed. If you're going to write code in a particular language, you

should fully embrace the language and its style, or move on to something
that you feel more comfortable with. These kind of crutches will only
serve to bite you later -- they aren't panaceas, and you may forget to
use them or be hobbled when interacting with someone else's code (where
you're not going to convince others to use your crutches). There's also
an indirect effect; if I'm reading someone else's Python code, and, say,
see someone using semicolons as statement delimiters on every line, I'm
not exactly going to be struck with a great deal of confidence.

It sits better with me if I have a good idea why I'm doing it.

 

[Erik Max Francis]

BTW: I've had your website bookmarked since 2001 because a number of
the
things there are useful and cool.

.

 

[Michael Hudson]

Thanks.

It's worth doing "C-h m" and "C-c ?" and reading the results, too.

Cheers,
mwh