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

Search Discussions

  • Peter Hansen at Aug 27, 2003 at 10:51 pm

    Anthony Roberts wrote:
    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
  • Anthony Roberts at Aug 28, 2003 at 1:31 am

    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. :)
  • Chad Netzer at Aug 27, 2003 at 11:20 pm

    On Wed, 2003-08-27 at 15:45, Anthony Roberts wrote:
    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.

    --

    Chad Netzer




    From n/a Thu Aug 28 01:26:06 2003
    From: n/a (Mike Thompson)
    Date: Thu, 28 Aug 2003 09:26:06 +1000
    Subject: My future Python IDE article
    References: <mailman.1061920192.21278.python-list@python.org><3f4ca68c$0$4190$afc38c87@news.optusnet.com.au> <mailman.1061989090.23114.python-list@python.org>
    Message-ID: <3f4d3e12$0$4190$afc38c87@news.optusnet.com.au>

    "Gerhard H?ring" <gh at ghaering.de> wrote in message
    news:mailman.1061989090.23114.python-list at python.org...
    Mike Thompson wrote:
    "David Mertz" wrote:
    So c.l.py readers... make the case for your favorite one getting on the
    list.
    I'm surprised no one has mentioned Boa. I tryed Wing & Komodo, before
    finding
    Boa.
    Boa is far from finished. Depending on your wxPython version and how you
    use the IDE, it could work surprisingly well or annoy you to no end in
    my experience.

    I'd recommend to not review alpha software like Boa.

    That's not my experience. I've found Boa both stable, functional and well
    priced.

    I tried Wing and generally liked it, except that I'm used to an editor with
    tabs for each open file and I found Wing's "one file at a time arrangement"
    didn't match my way of working.

    I tried Komodo, which has an enormous feature set that goes well beyond python,
    which I liked until I came to run my first wxPython based program under the
    debugger and it froze. I never did get to the bottom of why.

    In between all this I attempted to use Eric but had difficulty getting it
    setup. From memory, after some googling around, I found a few similar reports
    and abandoned the effort.

    I then tried Boa and haven't moved since.

    My search has occurred over the last six months. About twelve months ago I also
    tried the Secret Labs IDE (can't remember the name) which I found a bit of work
    initially, but ended up quite liking. However this product now seems to have
    been withdrawn from the market.

    If you have to restrict it to 3, my suggestion would be:
    Wing
    Boa
    IDLE

    That would give you a mix of commerical and free. All are cross-platform.

    If not IDLE, then Komodo which has a very inexpensive licence for personal
    use..

    --
    Mike
  • Sean Ross at Aug 27, 2003 at 11:38 pm
    "Anthony Roberts" <anthonyr-at-hotmail-dot-com at nospam.com> wrote in message
    news:Uva3b.49430$la.826046 at news1.calgary.shaw.ca...
    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
  • Anthony Roberts at Aug 28, 2003 at 1:50 am

    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.
  • John Roth at Aug 28, 2003 at 1:46 am
    "Anthony Roberts" <anthonyr-at-hotmail-dot-com at nospam.com> wrote in message
    news:Uva3b.49430$la.826046 at news1.calgary.shaw.ca...
    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 at Aug 28, 2003 at 1:48 am

    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.
  • Erik Max Francis at Aug 28, 2003 at 2:06 am

    Anthony Roberts wrote:

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

    --
    Erik Max Francis && max at alcyone.com && http://www.alcyone.com/max/
    __ San Jose, CA, USA && 37 20 N 121 53 W && &tSftDotIotE
    / \ Nobody's on nobody's side
    \__/ Florence, _Chess_
  • Chad Netzer at Aug 28, 2003 at 2:38 am

    On Wed, 2003-08-27 at 19:06, Erik Max Francis wrote:
    Anthony Roberts wrote:
    There is, but it can't tell if I want some stuff indented or not.
    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.

    --
    Chad Netzer <cnetzer at sonic.net>
  • Erik Max Francis at Aug 28, 2003 at 3:34 am

    Chad Netzer wrote:

    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.

    --
    Erik Max Francis && max at alcyone.com && http://www.alcyone.com/max/
    __ San Jose, CA, USA && 37 20 N 121 53 W && &tSftDotIotE
    / \ Don't ever get discouraged / There's always / A better day
    \__/ TLC
  • Anthony Roberts at Aug 28, 2003 at 5:00 am

    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.
  • Anthony Roberts at Aug 28, 2003 at 4:14 am

    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 at Aug 28, 2003 at 1:48 am

    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)
    What's the keystroke for that?
  • Erik Max Francis at Aug 28, 2003 at 2:05 am

    Anthony Roberts wrote:

    What's the keystroke for that?
    C-c < and C-c >.

    --
    Erik Max Francis && max at alcyone.com && http://www.alcyone.com/max/
    __ San Jose, CA, USA && 37 20 N 121 53 W && &tSftDotIotE
    / \ Nobody's on nobody's side
    \__/ Florence, _Chess_
  • Anthony Roberts at Aug 28, 2003 at 3:36 am
    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.
  • Erik Max Francis at Aug 28, 2003 at 5:31 am

    Anthony Roberts wrote:

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

    --
    Erik Max Francis && max at alcyone.com && http://www.alcyone.com/max/
    __ San Jose, CA, USA && 37 20 N 121 53 W && &tSftDotIotE
    / \ I'll tell them that their daddy was / A good man
    \__/ India Arie
  • Michael Hudson at Aug 28, 2003 at 11:45 am

    "Anthony Roberts" <anthonyr-at-hotmail-dot-com at nospam.com> writes:

    C-c < and C-c >.
    Thanks. :)
    It's worth doing "C-h m" and "C-c ?" and reading the results, too.

    Cheers,
    mwh

    --
    In case you're not a computer person, I should probably point out
    that "Real Soon Now" is a technical term meaning "sometime before
    the heat-death of the universe, maybe".
    -- Scott Fahlman <sef at cs.cmu.edu>
  • Anthony Roberts at Aug 28, 2003 at 1:51 am
    *yuck* :(
    LOL!

    I'm sorry. :)
  • U. N. Owen at Aug 28, 2003 at 6:23 am
    Re: Anthony Roberts wrote:
    Re: >
    Re: > If I end indentation levels with "pass" statements, will I piss off people
    Re: > that have to read my code? eg:
    Re: >
    Re: > for i in xrange(0,5):
    Re: > if i:
    Re: > print i
    Re: > pass
    Re: > print i * -1
    Re: > pass
    Re: >
    Re: > I ask for two reasons... a) it helps emacs figure it out, and b) I'm more
    Re: > comfortable ending compound statements with a token.
    Re:
    Re: Sorry, but yes, I find that ugly. If you're just starting out with
    Re: Python, please just give it a shot without that approach for a while
    Re: and see whether you become much more comfortable *without* the token
    Re: than you ever were with it.
    Re:
    Re: -Peter
    Re: --


    Sorry, but no ;-) Ok it's "one line more", and
    is not very useful. But...
    For the moment I work on (a small part of) a project
    that has hundreds of thousands of lines, almost
    eveything in Python (and some in C and Fortran),
    and when you have a loop several pages long, or
    nested blocks to 8 levels or more, I may say
    it's *very* convenient to see where the end
    of a block exactly is. It's convenient to
    have some long variable names too.
    --
    _______________________________________________
    Get your free email from http://www.uymail.com

    Powered by Outblaze
  • Dave Brueck at Aug 28, 2003 at 7:07 am

    On Thursday 28 August 2003 12:23 am, U. N. Owen wrote:
    Re: Anthony Roberts wrote:
    Re: >
    Re: > If I end indentation levels with "pass" statements, will I piss off
    people Re: > that have to read my code? eg:
    Re: >
    Re: > for i in xrange(0,5):
    Re: > if i:
    Re: > print i
    Re: > pass
    Re: > print i * -1
    Re: > pass
    Re: >
    Re: > I ask for two reasons... a) it helps emacs figure it out, and b) I'm
    more Re: > comfortable ending compound statements with a token.
    Re:
    Re: Sorry, but yes, I find that ugly. If you're just starting out with
    Re: Python, please just give it a shot without that approach for a while
    Re: and see whether you become much more comfortable *without* the token
    Re: than you ever were with it.
    Re:
    Re: -Peter
    Re: --


    Sorry, but no ;-) Ok it's "one line more", and
    is not very useful. But...
    For the moment I work on (a small part of) a project
    that has hundreds of thousands of lines, almost
    eveything in Python (and some in C and Fortran),
    and when you have a loop several pages long, or
    nested blocks to 8 levels or more, I may say
    it's *very* convenient to see where the end
    of a block exactly is. It's convenient to
    have some long variable names too.
    Sorry, but yes * 2. ;-) Please just don't tolerate loops several pages long
    and/or nested blocks that deep - such things should occur very, very rarely
    (essentially never). Putting an end-block delimiter after such beasts is like
    putting a band-aid on top of a compound fracture.

    -Dave
  • Peter Hansen at Aug 28, 2003 at 12:50 pm

    "U. N. Owen" wrote:
    For the moment I work on (a small part of) a project
    that has hundreds of thousands of lines, almost
    eveything in Python (and some in C and Fortran),
    and when you have a loop several pages long, or
    nested blocks to 8 levels or more, I may say
    it's *very* convenient to see where the end
    of a block exactly is. It's convenient to
    have some long variable names too.
    I use Scite, which provides a graphical means of representation
    the indentation, with vertical lines that extend down at every
    indent level. (It would have to be later in the day for me to
    be coherent enough to describe it better.) Suffice to say that
    it provides more than adequate (for me) visual indication of the
    end of a block that stretches too far.

    A better point I'd make however is that if you have a loop several
    pages long, or a nested block 8 levels deep, the code needs
    refactoring! Saying this occurs in a large project does nothing
    to excuse it: the more code you have, the greater the need for
    structuring it well.

    -Peter
  • Rzed at Aug 28, 2003 at 1:03 pm

    Peter Hansen wrote:
    "U. N. Owen" wrote:
    For the moment I work on (a small part of) a project
    that has hundreds of thousands of lines, almost
    eveything in Python (and some in C and Fortran),
    and when you have a loop several pages long, or
    nested blocks to 8 levels or more, I may say
    it's *very* convenient to see where the end
    of a block exactly is. It's convenient to
    have some long variable names too.
    I use Scite, which provides a graphical means of representation
    the indentation, with vertical lines that extend down at every
    indent level. (It would have to be later in the day for me to
    be coherent enough to describe it better.) Suffice to say that
    it provides more than adequate (for me) visual indication of the
    end of a block that stretches too far.

    A better point I'd make however is that if you have a loop several
    pages long, or a nested block 8 levels deep, the code needs
    refactoring! Saying this occurs in a large project does nothing
    to excuse it: the more code you have, the greater the need for
    structuring it well.
    The only times I've seen the lack of a block delimiter as a problem is
    when somebody plops some sample code in a usenet message and uses tabs
    for indenting. OE strips out the leading tabs for some reason, so
    everything winds up flush to the left margin. Once in awhile it is not
    possible to recreate the proper indention, and for that reason I try
    to include comment delimiters in code I send. When I don't forget, at
    least. A better solution might be to physically restrain the posters
    of tab-infested code from doing that, but there are only so many hours
    in the day. And if OE wouldn't do what it does ... but then, where
    would be the fund in that?

    --
    rzed
  • Steve Lamb at Aug 29, 2003 at 2:39 pm

    On 2003-08-28, rzed wrote:
    A better solution might be to physically restrain the posters of
    tab-infested code from doing that, but there are only so many hours in
    the day. And if OE wouldn't do what it does ... but then, where would
    be the fund in that?
    Well, actually, a better solution would be to skip OE for something
    sensible, no? :)


    --
    Steve C. Lamb | I'm your priest, I'm your shrink, I'm your
    PGP Key: 8B6E99C5 | main connection to the switchboard of souls.
    -------------------------------+---------------------------------------------
  • Alex Martelli at Aug 29, 2003 at 2:48 pm

    Steve Lamb wrote:
    On 2003-08-28, rzed wrote:
    A better solution might be to physically restrain the posters of
    tab-infested code from doing that, but there are only so many hours in
    the day. And if OE wouldn't do what it does ... but then, where would
    be the fund in that?
    Well, actually, a better solution would be to skip OE for something
    sensible, no? :)
    OE is far from the only news user-agent that doesn't display tabs the
    way you might like -- KDE's KNode has similar issues, for example.


    Alex
  • Rzed at Aug 29, 2003 at 3:16 pm

    Steve Lamb wrote:
    On 2003-08-28, rzed wrote:
    A better solution might be to physically restrain the posters of
    tab-infested code from doing that, but there are only so many
    hours in the day. And if OE wouldn't do what it does ... but then,
    where would be the fund in that?
    Well, actually, a better solution would be to skip OE for
    something sensible, no? :)
    On my own hook, I'm doing that, but here in the office I don't have
    the choice. I do have the choice to spell "fun" correctly, though I
    see I opted not to.

    --
    rzed




    From tina_li23AThotmailDOTcom Fri Aug 29 17:19:41 2003
    From: tina_li23AThotmailDOTcom (Tina Li)
    Date: Fri, 29 Aug 2003 11:19:41 -0400
    Subject: pmw menu item's 'command' attribute
    References: <3f4e5687_4@corp.newsgroups.com> <bilrdk$6j5$04$1@news.t-online.com>
    Message-ID: <3f4f6f5f$1_4@corp.newsgroups.com>

    Thanks so much! Both the explanation and the code worked. Basically when a
    lambda function is created, any references to global variables are not
    evaluated until when it's executed. So if the global var changes value
    before that the lambda function follows suit and takes the last value it has
    settled at.

    Thanks again!

    Tina


    "Peter Otten" <__peter__ at web.de> wrote in message
    news:bilrdk$6j5$04$1 at news.t-online.com...
    "Tina Li" <tina_li23 AT hotmail DOT com> wrote:
    for size in ('tiny', 'small', 'average', 'big', 'huge'):
    self.menuBar.addmenuitem('Size', 'command', 'Set size to ' +
    size,
    command = lambda: cmd.do('change size ' + size),
    label = size)
    The variable size in the lambda expression is bound to the global variable
    size, so if you do

    size = 42

    later, the menu command will even raise an exception.
    Solution:

    command=lambda size=size: cmd.do('change size ' + size)

    This creates a local variable size that defaults to the same string that the
    outer size variable is bound to when the lambda expression is created.
    (Don't know if the explanation works, but the code should :-)

    Peter


    -----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
    http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
    -----== Over 100,000 Newsgroups - 19 Different Servers! =-----

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppython-list @
categoriespython
postedAug 27, '03 at 10:45p
activeAug 29, '03 at 3:16p
posts26
users12
websitepython.org

People

Translate

site design / logo © 2022 Grokbase