Python and Ruby

waku waku at idi.ntnu.no
Tue Feb 2 11:21:02 CET 2010


Steven D'Aprano wrote:
> On Sat, 30 Jan 2010 16:58:34 +0000, tanix wrote:

[...]

> > The very idea of using a number of blanks to identify your block level
> > is as insane as it gets.
>
> Not at all. People do it all the time. The very idea of expecting people
> to count nested braces to identify block level is what is crazy, which is
> why in languages with braces people still indent the blocks.

for reading written code, it's surely helpful to have the code
indented, though for *human* reading, the count of blanks seems rather
inessential, as long as intended difference in indents is more
pronounced than incidental difference between same-level lines.

for writing new code, it's not necessarily that helpful to be *forced*
to keep with strict indenting rules.  in early development phases,
code is often experimental, and parts of it may need to be blocked or
unblocked as the codebase grows, and for experimentation, the need to
carefully and consistently indent and de-indent large chunks of code
can easily lead to a mess (blame it on the programmer, not the
language, but still).  yes, there are editors that help you indent
chunks of code, but see below.

there are languages where indentation can be either enforced and allow
one to omit some syntactic nuissance like braces or begin-end clauses,
or made optional, requiring other syntactic means for delimiting
blocks etc.  (consider f# with its #light declaration, for example.)

[...]

> In any case, if your IDE mixes tabs and spaces, your IDE is broken and
> you should fix your tools rather than blame the language.

as long as you are limited to your own code, sure.  but if many work
on the same bit, and use different editors and indentation policies,
blanks-tabs indentation issues are not unlikely.  you can have blanks
converted to tabs and vice versa automatically, but that's clearly a
nuisance.


>
>
> > Braces is the most reliable way to identify blocks.
>
> Nonsense. For the compiler, both are equally reliable, and for the human
> reader, indents beat braces easily.

if blanks and tabs are mixed together as indentation, the setting of
your ide can easily mess up the indentation, making the structure
unclear.  in some editors, you can have braces highlighted, so that
it's even easier to see where a block ends or starts.  and more
advanced editors help one see the structure of the code, whereby both
indentation and braces are made less important for the reader.

but yes, indentation surely helps in reading the code.

>
>
> > Sane compilers ignore blanks altogether.
>
> Really? So a "sane compiler" sees no difference between:
>
> for x in mylist:
>
> and
>
> forxinmylist:
>
>
> I'm glad I don't have to program using a compiler you consider "sane".

the point here was, i think, that blanks may have no syntactic
meaning, though they can still be essential at the lexical level.
your example targeted the lexical level, and that's rather irrelevant
to the problem of syntactically meaningful indentation discussed here.

vQ



More information about the Python-list mailing list