Misuse of <tab>
Gisle Vanem
No need for {} as in Perl etc. But the misuse of <tab> that many
.py writers do makes it hard to understand how a script operates.
E.g.
def main():
terminate = 0
def foo():
line = sys.stdin.readline()
<tab> try:
bar()
except:
terminate = 1
main()
Now, with an editor with different tab-settings it's difficult to see where
the try statement belongs. In 'def main()' or in 'def foo()' ?
I'm confused, please enlighten me.
--gv
John Roth
"Gisle Vanem" <gi...@users.sourceforge.net> wrote in message
news:3f27f0e3$1...@news.broadpark.no...
You're quite right - mixing spaces and tabs when indenting is
not the thing to do. In fact, it's warned against in a number of
places. The recommended practice is to use spaces, and
avoid tabs completely.
I think you'll find that all the modules in the standard library
use spaces exclusively.
John Roth
>
> --gv
>
>
max
> not the thing to do. In fact, it's warned against in a number of
> places. The recommended practice is to use spaces, and
> avoid tabs completely.
>
> I think you'll find that all the modules in the standard library
> use spaces exclusively.
to get decent-looking indentation :).
Donald 'Paddy' McCarthy
> I'm a .py newbie and fascinated by the simplicity of formatting.
> No need for {} as in Perl etc. But the misuse of <tab> that many
> .py writers do makes it hard to understand how a script operates.
>
> E.g.
>
> Now, with an editor with different tab-settings it's difficult to see where
> the try statement belongs. In 'def main()' or in 'def foo()' ?
> I'm confused, please enlighten me.
The usual rule is to either:
1) Don't use tabs for indentation at all. Or
2) If you must use tabs, then always use just tabs/
If you have an editor that might automatically change several spaces to
tabs then turn that feature off or don't use the editor.
Cheers, Pad.
John J. Lee
[...]
> The problem with spaces is that you need to do 5 times the work of a
> tab to get decent-looking indentation :).
Get an editor. :-)
John
Keith Jones
> The problem with spaces is that you need to do 5 times the work of a tab
> to get decent-looking indentation :).
Not if you have a good editor.. Use vim or emacs. In vim, try :h sts (I
think, or :h softtabstop) ...it would suck to have to type
<space><space><space><space> all the time, but you don't. :)
Michael Sampson
When it automaticly indents does it do it with spaces or tabs? If you hit
tab in the IDLE will it just put 5 spaces in for you?
"Gisle Vanem" <gi...@users.sourceforge.net> wrote in message
news:3f27f0e3$1...@news.broadpark.no...
Skip Montanaro
Gisle> I'm confused, please enlighten me.
Don't use TABs and break the knuckles of any of your co-workers who do. ;-)
More seriously, I suspect most editors have some sort of setting which
causes it to insert SPACE characters up to the next tab stop.
Skip
Cliff Wells
> The problem with spaces is that you need to do 5 times the work of a tab
> to get decent-looking indentation :).
Or you get a decent editor that inserts 4 spaces when you hit tab and
erases 4 spaces when you hit backspace.
--
Cliff Wells, Software Engineer
Logiplex Corporation (www.logiplex.net)
(503) 978-6726 (800) 735-0555
Sean 'Shaleh' Perry
> How does the IDLE that comes with the latest release of python handle this?
> When it automaticly indents does it do it with spaces or tabs? If you hit
> tab in the IDLE will it just put 5 spaces in for you?
>
thou shalt always use even numbered indents.
Or to paraphrase Monty Python:
Thou shalt count to 4, 4 being the sacred number. Thou shalt not count 3 and
5 is right out.
Ben Finney
> thou shalt always use even numbered indents.
More accurately, thou shalt always use even, factor-of-8 indents.
(Making 2 and 4 the only valid indent sizes.)
Ironically, this has its origins in the standard literal tab stop being
8 (which number thou shalt not alter). Using factor-of-8 indent sizes
means that every literal tab stop falls on an indent column. The irony
comes from the deprecation of using literal tabs for indent at all :-)
--
\ "I put instant coffee in a microwave oven and almost went back |
`\ in time." -- Steven Wright |
_o__) |
Ben Finney <http://bignose.squidly.org/>
Asun Friere
If you use vim remember to put 'set expandtab' (or if you wanna be
fancy 'au BufRead,BufNewFile *.py set expandtab' ) into your .vimrc
(or .exrc) file. This way you can use '[Ctrl]-[T]' and '[Ctrl]-[D]'
to in- and un-dent in insert mode, as well as '>>' and '<<' in command
mode, without fear of hard tabs being inserted. (Though the way vi(m)
mixes tabs and spaces is consistent enough that you wouldn't usually
get into any trouble with it.)
Christopher Koppler
<milkc...@hotmail.com> wrote:
>How does the IDLE that comes with the latest release of python handle this?
>When it automaticly indents does it do it with spaces or tabs? If you hit
>tab in the IDLE will it just put 5 spaces in for you?
>
IDLE 1.0 (from Python 2.3) has a pretty configuration dialog, accessed
via Options|Configure IDLE, which lets you define its behaviour - do
you want it to insert tabs as tabs or spaces, and how many spaces do
you want, the default seeming to be converting a tab to 4 spaces.
And, as others have said, DON'T use 5.
--Christopher
Gerhard Häring
> On Wednesday 30 July 2003 13:20, Michael Sampson wrote:
>
>>When it automaticly indents does it do it with spaces or tabs? If you hit
>>tab in the IDLE will it just put 5 spaces in for you?
>
Why?
-- Gerhard
Gerhard Häring
> [tab settings]
> And, as others have said, DON'T use 5.
I'd still like to hear a reason for this.
-- Gerhard
Thomas Heller
Justin Guerin
In this case, you can tell by the except clause. except: can only follow a
try:, and they must be on the same indent level. Also, if the try: was in
'def foo()', 'bar()' would have to have a higher indent level than 'line =
sys.stdin.readline()'. (From what I can see, it does, but I'm not sure that
was intended, as the except came in at a different indent level from either)
So for this example, the try: belongs in 'def main()'
Justin
James Graves
>If you use vim remember to put 'set expandtab' (or if you wanna be
>fancy 'au BufRead,BufNewFile *.py set expandtab' ) into your .vimrc
>(or .exrc) file. This way you can use '[Ctrl]-[T]' and '[Ctrl]-[D]'
>to in- and un-dent in insert mode, as well as '>>' and '<<' in command
>mode, without fear of hard tabs being inserted. (Though the way vi(m)
>mixes tabs and spaces is consistent enough that you wouldn't usually
>get into any trouble with it.)
That's handy. I had known about 'set expandtab' for a while, but I
wanted to figure out how to use it for just Python.
And now I don't have to.
Thanks,
James Graves
Keith Jones
> 'au BufRead,BufNewFile *.py set expandtab' ) into your .vimrc (or .exrc)
> file. This way you can use '[Ctrl]-[T]' and '[Ctrl]-[D]' to in- and
> un-dent in insert mode, as well as '>>' and '<<' in command mode,
> without fear of hard tabs being inserted. (Though the way vi(m) mixes
> tabs and spaces is consistent enough that you wouldn't usually get into
> any trouble with it.)
Oh, yeah, forgot to mention expandtab; I did not know about >>, <<,
Ctrl+T, and Ctrl+D, however; so thanks for those. I had mapped <tab> and
<s-tab> to : s/^/ /<cr> and : s/^ /<cr> for command mode, which I
guess I won't have to use anymore. I noticed in visual mode, you can just
use '>' or '<' to tab or untab multiple lines, though sadly the visual
mode disappears. This leads to the question: what python specific entries
people have in their .vimrc's?
I've got the following:
" smart indenting is necessary of course
autocmd FileType python set autoindent smartindent et sts=4
\ cinwords=class,def,elif,else,except,finally,for,if,try,while
" I hate that vim puts # at the beggining of the line if it's the
" first
character, so this prevents that
autocmd FileType python inoremap # X#
" as described above, insert or remove tabs (works with visual, to)
autocmd FileType python map <tab> : s/^/ /<cr>
autocmd FileType python map <S-tab> : s/^ //<cr>
" These move to the top of the next or previous class or function
autocmd FileType python map [[ ?^\s*class\s<cr>
autocmd FileType python map ]]/^\s*class\s<cr>
autocmd FileType python map [] ?^\s*def\s<cr>
autocmd FileType python map ][ /^\s*def\s<cr>
" find some of my stupid mistakes
autocmd FileType python map <F5> :w<CR>:!pychecker %<CR>
" comment or uncomment multiple lines in visual mode
autocmd FileType python vmap # : s/^/#/<cr>
autocmd FileType python vmap @ : s/^#*//<cr>
I should just put all those commands in a vim file and source it.
Ben Finney
<http://groups.google.com/groups?selm=slrnbih09e.vpm.bignose-hates-spam%40iris.polar.local>
--
\ "During the Middle Ages, probably one of the biggest mistakes |
`\ was not putting on your armor because you were 'just going down |
_o__) to the corner.'" -- Jack Handey |
Ben Finney <http://bignose.squidly.org/>
Asun Friere
> > If you use vim remember to put 'set expandtab' (or if you wanna be fancy
> > 'au BufRead,BufNewFile *.py set expandtab' ) into your .vimrc (or .exrc)
> > file. This way you can use '[Ctrl]-[T]' and '[Ctrl]-[D]' to in- and
> > un-dent in insert mode, as well as '>>' and '<<' in command mode,
> > without fear of hard tabs being inserted. (Though the way vi(m) mixes
> > tabs and spaces is consistent enough that you wouldn't usually get into
> > any trouble with it.)
>
>
> Oh, yeah, forgot to mention expandtab; I did not know about >>, <<,
> Ctrl+T, and Ctrl+D, however; so thanks for those. I had mapped <tab> and
> <s-tab> to : s/^/ /<cr> and : s/^ /<cr> for command mode, which I
> guess I won't have to use anymore.
[ctrl]-[t] and [ctrl]-[d] also exist in vanilla vi, but are much more
nicely implemented in vim. In vi you have to make sure you are at the
front of the line, or else you indent will be inserted into your line
(which is hardly ever what you would want). In vim it doesn't matter
where in the line your cursor is, the commands will move the line as a
unit, much like your mappings would.
I should perhaps also mention the very useful ex versions of this
command as well. ie '>' for a single indent, '>>' for two indents,
'<<<' for three dedents, etc, which like ex commands generally are
especially useful when you want to move a bunch of lines at a time.
Thanks for that resource file listing, that is going to up a whole new
vista of vim/python usage for me.
Asun Friere
> That's handy. I had known about 'set expandtab' for a while, but I
> wanted to figure out how to use it for just Python.
Note how Keith Jones, in the following post, achieves the same:
au FileType python set et
I wasn't aware of the 'FileType' setting, but it has the advantage of
working with files which vim recognises as python source, but which
don't necessarily end in 'py'. Nice!
Robin Munn
Don't forget the "smarttab" option (:h smarttab). My .vimrc looks like:
set shiftwidth=4
set expandtab
set smarttab
OK, if you want to be precise about it, *part* of my .vimrc looks like
the above. :-)
--
Robin Munn <rm...@pobox.com> | http://www.rmunn.com/ | PGP key 0x6AFB6838
-----------------------------+-----------------------+----------------------
"Remember, when it comes to commercial TV, the program is not the product.
YOU are the product, and the advertiser is the customer." - Mark W. Schumann