Python indentation

[bruno modulix]

Re: Python indentation

Jacek Generowicz a écrit :[color=blue]
> "Sateesh" <ext-sateesh.kavuri@ nokia.com> writes:
>
>[color=green]
>>Hi,
>>I am a beginner in Python, and am wondering what is it about the indentation
>>in Python, without which python scripts do not work properly.
>>Why can't the indentation not so strict so as to give better freedom to the
>>user?
>>Is there any plausible reason behind this?[/color]
>
>
> def ask(lang, noise):
> print """I am a beginner in %s, and am wondering what is it about the %s in
> %s, without which %s programs do not work properly.
> Why can't the %s not so strict so as to give better freedom to
> the user?
> Is there any plausible reason behind this?""" % (lang, noise, lang, lang, noise)
> print
>
> for l,n in [['C', '{,} and ;'],
> ['C++', '{,} and ;'],
> ['Java', '{,} and ;'],
> ['Pascal', 'begin and end'],
> ['Lisp', '( and )'],
> ['Perl', '!@#*$&!@$#/\'],[/color]
['PHP', '$ and {,} and ;']]:[color=blue]
> ask(l,n)
>
> keywords: parody, irony[/color]

Keyboard !

(5 minutes later)

Is it GPL'ed ?-)

Bruno

[Steve Lamb]

Re: Tab wars revisited (was Re: Python indentation)

On 2004-07-07, Peter Hansen <peter@engcorp. com> wrote:[color=blue]
> Istvan Albert wrote:[color=green]
>> Yeah, yeah I know that this or that editor has a shortcut enabled via
>> CTRL+ALT+INSERT +SPACE+double-click+W and that will do the job in one
>> keystroke,[/color][/color]
[color=blue]
> *Any* decent editor can be configured to inject spaces up to the
> next defined tab-stop when TAB is hit. By definition, therefore,
> any editor that cannot is broken.[/color]

What Istvan is using is better known, to me at least, as "the vi
argument". IE, it was best for people to learn vi over another editor because
one could be stuck with nothing but vi to do editing with since all unixes
came with vi stock. Whatever would someone do if they were incapable of using
their preferred editor and stuck *only* with vi!?

Nevermind that there are now several well used flavors of unix which do
not come stock with vi or, at the very least, only vi. And some of the
situations that the people would create. "What if you only had a laptop, an
install disc for intel solaris and were stuck on a stranded isle with no
network access to get anything else!? You really need to conserve battery
power so you can't waste time learning vi then but you need it to write the
perfect program to calculate the best method of communication using firewood.
YOU DON'T KNOW VI!!! WHAT WOULD YOU DO!!!!! AIYEEEEEE!!!!" Ok, I may be
exagerrating a tiny bit but only a tiny bit.

Personally I've not been in a situation where I haven't had a decent
editor to program with in the past decade or two. I use spaces for just the
reason you gave; a SPACE is a SPACE is a SPACE. Anyone who's worried about
how many keystrokes they're going to expend because they're programming Python
on a laptop on a deserted isle in the middle of the pacific with only notepad
really needs to reexamine their priorities.

Oh, and for the record, I can tweak the collective noses of the vi
zealots who came up with such absurd and convoluted reasonings on why everyone
simply MUST learn vi because I use vim. ;)

--
Steve C. Lamb | I'm your priest, I'm your shrink, I'm your
PGP Key: 8B6E99C5 | main connection to the switchboard of souls.
-------------------------------+---------------------------------------------

[Steve Lamb]

Re: [OT] Python indentation

On 2004-07-07, Reinhold Birkenfeld <reinhold-birkenfeld-nospam@wolke7.n et> wrote:[color=blue]
> As we can see a few threads later, it is replaced by the
> tabs-or-spaces-war...[/color]

Not really. First off if one follows the offical coding style it is 4
spaces. Go against it at your own peril. The braces-placement war isn't
replaced with the tabs-or-spaces war. That presumes the tab-or-spaces war
doesn't exist side-by-side with the braces-placement war. We just notice it
more since we don't have the braces-placement war to detract us. :)

--
Steve C. Lamb | I'm your priest, I'm your shrink, I'm your
PGP Key: 8B6E99C5 | main connection to the switchboard of souls.
-------------------------------+---------------------------------------------

[bruno modulix]

Re: [OT] Python indentation

Tor Iver Wilhelmsen a écrit :[color=blue]
> "Sateesh" <ext-sateesh.kavuri@ nokia.com> writes:
>
>[color=green]
>>Why can't the indentation not so strict so as to give better freedom to the
>>user?[/color]
>
>
> It's a core syntactical feature of the language. Your request is like
> asking, say, a C family language to adopt BEGIN and END instead of
> those weird braces, because you're used to it from Pascal.[/color]

Quite easy :
#define BEGIN {
#define END }

Bruno

[Christopher Weimann]

Re: Tab wars revisited (was Re: Python indentation)

On 07/07/2004-08:36PM, Steve Lamb wrote:[color=blue]
>
> What Istvan is using is better known, to me at least, as "the vi
> argument". IE, it was best for people to learn vi over another editor because
> one could be stuck with nothing but vi to do editing with since all unixes
> came with vi stock.[/color]

Thats not the reason to learn vi, its the reason to learn ed :)

[Dan Bishop]

Re: Python indentation

Grant Edwards <grante@visi.co m> wrote in message news:<slrncentb i.ak.grante@gra nte.rivatek.com >...[color=blue]
> On 2004-07-07, Reinhold Birkenfeld <reinhold-birkenfeld-nospam@wolke7.n et> wrote:
>[color=green][color=darkred]
> >> I am a beginner in Python, and am wondering what is it about
> >> the indentation in Python, without which python scripts do not
> >> work properly. Why can't the indentation not so strict so as
> >> to give better freedom to the user? Is there any plausible
> >> reason behind this?[/color]
> >
> > Yes. It's about readability.
> >
> > In many languages, such as C or Perl, you can write readable code, but
> > you can also squeeze your code in as few lines as possible, resulting in
> > hard to read, hard to maintain, hard to debug code[1]. Whenever I
> > translate a Perl script into Python, I end up with about 25-40% more
> > lines, but the script is much more readable than the Perl counterpart
> > (mostly, of course, because of the lacking $'s ;).[/color]
>
> Compare C and Python:
>
> In C, we have 10 lines [compared to 6 in Python]
>
> if (condition)
> {
> doThis();
> doThat();
> }
> else
> {
> doWhatever();
> andSoOn();
> }[/color]

Only because you're using an inefficient brace style.

The style I use writes it as:

if (condition) {
doThis();
doThat();
} else {
doWhatever();
andSoOn();
}

which is 7 lines, only 1 more than the Python version.

But this does demonstrate an advantage of Python: No arguments over
where to put braces :-)

[Istvan Albert]

Re: Tab wars revisited (was Re: Python indentation)

Peter Hansen wrote:
[color=blue]
>
> Ambiguity sucks but a SPACE is a SPACE is a SPACE.[/color]

Is there a reason why a TAB is not a TAB is not a TAB?
[color=blue]
> *Any* decent editor can be configured to inject spaces up to the
> next defined tab-stop when TAB is hit. By definition, therefore,
> any editor that cannot is broken.[/color]

Is it really that trivial to set up an editor so that when one hits
delete/backspace to 'un-align' a line of code it deletes as
many space characters as the soft-tab has inserted?

I don't think so.

Istvan.

[Jarek Zgoda]

Re: Tab wars revisited (was Re: Python indentation)

Istvan Albert <ialbert@mailbl ocks.com> pisze:
[color=blue][color=green]
>> Ambiguity sucks but a SPACE is a SPACE is a SPACE.[/color]
>
> Is there a reason why a TAB is not a TAB is not a TAB?[/color]

Because TAB is TAB and not 8 * SPACE nor 4 * SPACE nor 2 * SPACE. In
editor you don't see a TAB, you see 8 * SPACE or 4 * SPACE or 2 * SPACE
or any number of spaces you set in your editor options. There's no
display character for TAB, it is substituted by SPACES.

As you see, TAB is down, while spaces are up. Resistance is futile. You
will be assimilated.

--
Jarek Zgoda

http://jpa.berlios.de/

[Ville Vainio]

Re: Tab wars revisited (was Re: Python indentation)

>>>>> "Istvan" == Istvan Albert <ialbert@mailbl ocks.com> writes:

Istvan> Is it really that trivial to set up an editor so that when
Istvan> one hits delete/backspace to 'un-align' a line of code it
Istvan> deletes as many space characters as the soft-tab has
Istvan> inserted?

Emacs python-mode does it.

Lesser editors often achieve the same effect by shift-tab.

--
Ville Vainio http://tinyurl.com/2prnb

[Mike C. Fletcher]

Re: Tab wars revisited (was Re: Python indentation)

Jarek Zgoda wrote:
[color=blue]
>Istvan Albert <ialbert@mailbl ocks.com> pisze:
>
>
>[color=green][color=darkred]
>>>Ambiguity sucks but a SPACE is a SPACE is a SPACE.
>>>
>>>[/color]
>>Is there a reason why a TAB is not a TAB is not a TAB?
>>
>>[/color]
>
>Because TAB is TAB and not 8 * SPACE nor 4 * SPACE nor 2 * SPACE. In
>editor you don't see a TAB, you see 8 * SPACE or 4 * SPACE or 2 * SPACE
>or any number of spaces you set in your editor options. There's no
>display character for TAB, it is substituted by SPACES.
>
>As you see, TAB is down, while spaces are up. Resistance is futile. You
>will be assimilated.
>
>[/color]
Nope. People have been telling me to use spaces in my Python for
*years*, and I'm nowhere near assimilated. The number of silly
occasions where hitting <del> or <backspace> to remove a tab works where
the editor doesn't pick up an attempt to remove 4-or-so-spaces keeps me
going back to the simple "a tab is an indent" approach. The simple fact
( ;) I know, it's a holy war, there are no facts, but I feel like
tweaking the spacies) is that having 3 or 4 or 2 or 8 characters
represent the concept "indentatio n level" is just silly when you've got
the single character representation available.

Oh, and decent editors (hint: PythonWin rules), that is, those based on
Scintilla (almost every Python-specific IDE) *do* have a character for
displaying <tab>, it's an elongated arrow that looks surprisingly like
the arrow on my keyboard's tab key :) . BTW the fact that I can set the
display of an indentation level (tab) to whatever width I like is a
*benefit* :) .

Of course, normally I just tell people telling me to switch "sure, I
could change, but I have more Python code than you[1], so *you* conform"
;) ,
Mike

[1] And, generally speaking, this is true, as anyone who has written
more Python is almost certainly one of us old-timers and would never
think of starting this silly thread *again*... :)

_______________ _______________ _______________ ___
Mike C. Fletcher
Designer, VR Plumber, Coder

http://members.rogers.com/mcfletch/

blog: http://zope.vex.net/~mcfletch/plumbing/

[Christopher T King]

Re: Tab wars revisited (was Re: Python indentation)

On Wed, 7 Jul 2004, Jarek Zgoda wrote:
[color=blue]
> Istvan Albert <ialbert@mailbl ocks.com> pisze:
>[color=green][color=darkred]
> >> Ambiguity sucks but a SPACE is a SPACE is a SPACE.[/color]
> >
> > Is there a reason why a TAB is not a TAB is not a TAB?[/color]
>
> Because TAB is TAB and not 8 * SPACE nor 4 * SPACE nor 2 * SPACE. In
> editor you don't see a TAB, you see 8 * SPACE or 4 * SPACE or 2 * SPACE
> or any number of spaces you set in your editor options. There's no[/color]

Which is exactly why I use tabs -- if I don't like the indentation width,
I just change and option and BAM! it's changed! Whereas with spaces, I'm
stuck with looking at one- or eight- character indents, rather than my
preferred tab width setting.

My other reason for using tabs is that my preferred editor (JOE)
couldn't unindent space-based indents prior to its 3.0 release (very
recent). Now my excuse is WHAT IF I HAVE TO USE NOTEPAD?!?! :)

[Ubergeek]

Re: Tab wars revisited (was Re: Python indentation)

Mike C. Fletcher wrote:
[color=blue]
> Jarek Zgoda wrote:
>[color=green]
>> Istvan Albert <ialbert@mailbl ocks.com> pisze:
>>
>>
>>[color=darkred]
>>>> Ambiguity sucks but a SPACE is a SPACE is a SPACE.
>>>>
>>>
>>> Is there a reason why a TAB is not a TAB is not a TAB?
>>>[/color]
>>
>>
>> Because TAB is TAB and not 8 * SPACE nor 4 * SPACE nor 2 * SPACE. In
>> editor you don't see a TAB, you see 8 * SPACE or 4 * SPACE or 2 * SPACE
>> or any number of spaces you set in your editor options. There's no
>> display character for TAB, it is substituted by SPACES.
>>
>> As you see, TAB is down, while spaces are up. Resistance is futile. You
>> will be assimilated.
>>
>>[/color]
> Nope. People have been telling me to use spaces in my Python for
> *years*, and I'm nowhere near assimilated. The number of silly
> occasions where hitting <del> or <backspace> to remove a tab works where
> the editor doesn't pick up an attempt to remove 4-or-so-spaces keeps me
> going back to the simple "a tab is an indent" approach. The simple fact
> ( ;) I know, it's a holy war, there are no facts, but I feel like
> tweaking the spacies) is that having 3 or 4 or 2 or 8 characters
> represent the concept "indentatio n level" is just silly when you've got
> the single character representation available.[/color]

IMHO, it doesn't make that much difference if you use all tabs or you
use all spaces for your indentation if you're the only one that ever
edits the source file. The problem comes in if the two ever get mixed
in the same file, which is particularly problematic if you have more
than one person working on a file or if you share some code as open source.

If you use tabs in your source with a 4-space width and I make a mod to
one of your files when I have my editor configured to insert 4 spaces
for indent, it'll look the same on the screen but Python will get very
unhappy. Because all blocking in Python is based on lines with
identical amounts of indentation, Python has to convert all those tabs
to some amount of spaces in order to calculate indentation. Since
Python has no idea what tab width you have set in your editor, it has to
assume a fixed size for tabs (which, IIRC, is 8 spaces). Because of
this, your 4-space wide tab and my 4 real spaces represent different
indentation levels and the blocking of the code is now hosed.

The advantage of using all spaces is that no matter what editor you load
a source file in or what your tab-width configuration is, it is
guaranteed that a human being and the Python interpreter will both see
the indentation the same way.

[Peter Hansen]

Re: Tab wars revisited (was Re: Python indentation)

Steve Lamb wrote:
[color=blue]
> What Istvan is using is better known, to me at least, as "the vi
> argument". IE, it was best for people to learn vi over another editor because
> one could be stuck with nothing but vi to do editing with since all unixes
> came with vi stock. Whatever would someone do if they were incapable of using
> their preferred editor and stuck *only* with vi!?
>
> Nevermind that there are now several well used flavors of unix which do
> not come stock with vi or, at the very least, only vi. And some of the
> situations that the people would create. "What if you only had a laptop, an
> install disc for intel solaris and were stuck on a stranded isle with no
> network access to get anything else!? You really need to conserve battery
> power so you can't waste time learning vi then but you need it to write the
> perfect program to calculate the best method of communication using firewood.
> YOU DON'T KNOW VI!!! WHAT WOULD YOU DO!!!!! AIYEEEEEE!!!!" Ok, I may be
> exagerrating a tiny bit but only a tiny bit.[/color]

I'm actually pretty inept with vi (or vim), to the point that I don't
actually know how to configure it for use with Python. And every
now and then, I'm forced to use it. When that happens, I find
that writing my little one-off (since inevitably that's what it
is, even if it's to figure out how to use smoke signals on a
desert island) is best done with single spaces. Bingo-bango, no
typing disadvantage over TABs... even better, I get to use
my *thumb*, which is much stronger than my middle finger, and
don't need to move my wrist at all, decreasing the effect of the
whole process on my carpal tunnel syndrome.

Basically, the "vi argument" has no merit, since the only times
one can't get access to a decent editor, preconfigured to do the
Right Thing with Python, is an emergency, and in an emergency,
single spaces work as well as tabs. End of argument. :-) (No,
really, that will stop the discussion permanently. Really!)

-Peter

[Steve Lamb]

Re: Python indentation

On 2004-07-07, Dan Bishop <danb_83@yahoo. com> wrote:[color=blue]
> The style I use writes it as:
>
> if (condition) {
> doThis();
> doThat();
> } else {
> doWhatever();
> andSoOn();
> }[/color]
[color=blue]
> which is 7 lines, only 1 more than the Python version.[/color]
[color=blue]
> But this does demonstrate an advantage of Python: No arguments over
> where to put braces :-)[/color]

Damn skippy. 'round these parts it would look like this:

if (condition) {
doThis();
doThat();
}
else {
doWhatever();
andSoOn();
}

8 lines. But that's because I never understood why anyone would
willingly use the '} else {' construct since the else is ovten obscured.
Keyword opens the block, } ends the block, never put a block open and close on
the same line.


--
Steve C. Lamb | I'm your priest, I'm your shrink, I'm your
PGP Key: 8B6E99C5 | main connection to the switchboard of souls.
-------------------------------+---------------------------------------------

[Steve Lamb]

Re: Tab wars revisited (was Re: Python indentation)

On 2004-07-07, Istvan Albert <ialbert@mailbl ocks.com> wrote:[color=blue]
> Is there a reason why a TAB is not a TAB is not a TAB?[/color]

Yes. Name the number of spaces a TAB should translate into.

That was easy. Now explain why your answer is right and the next guy's
answer, which is different than yours, is wrong.

Oh, not so easy, eh? TAB, by it's very nature, is a variable and
configurable width. A SPACE is not.
[color=blue]
> Is it really that trivial to set up an editor so that when one hits
> delete/backspace to 'un-align' a line of code it deletes as
> many space characters as the soft-tab has inserted?[/color]
[color=blue]
> I don't think so.[/color]

Uhm, yes, it is. With vim part of my configuration when loading Python
files:
au FileType python set autoindent smartindent et sts=4 sw=4 tw=80 fo=croq

Translates into:

Autoindent on
Smartindent on
Expandtab on
SoftTabStop 4 spaces
ShiftWidth 4 spaces
TextWidth 80 spaces
FormatOptions
c - auto-wrap comments, automatically inserting current comment character
r - Automatically insert current comment character after hitting enter in
in insert mode
o - Automatically insert current comment character after hitting o or O in
command mode.
q - allow formatting of comments with gq (IE, reflow and keep comment
characters at the front of the line).

Where's the magic? Here:

-----
'softtabstop' 'sts' number (default 0)
local to buffer
{not in Vi}
Number of spaces that a <Tab> counts for while performing editing
operations, like inserting a <Tab> or using <BS>. It "feels" like
<Tab>s are being inserted, while in fact a mix of spaces and <Tab>s is
used. This is useful to keep the 'ts' setting at its standard value
of 8, while being able to edit like it is set to 'sts'. However,
commands like "x" still work on the actual characters.
When 'sts' is zero, this feature is off.
-----

Number of spaces that a <Tab> counts for while performing editing
operations like....<BS> (Backspace). IE, I set STS to 4. I hit tab, 4 spaces
are inserted. I hit backspace, 4 spaces are removed. It's just that simple.

As for alignment operations ShiftWidth is used for << and >> which are
used to (de)indent blocks of code.

--
Steve C. Lamb | I'm your priest, I'm your shrink, I'm your
PGP Key: 8B6E99C5 | main connection to the switchboard of souls.
-------------------------------+---------------------------------------------