Python syntax in Lisp and Scheme

Ingvar Mattsson ingvar at cathouse.bofh.se
Mon Oct 6 05:29:45 EDT 2003


Joe Marshall <jrm at ccs.neu.edu> writes:

> Alexander Schmolck <a.schmolck at gmx.net> writes:
> 
> > prunesquallor at comcast.net writes:
> >
> >> mike420 at ziplip.com writes:
> >> 
> >> > I think everyone who used Python will agree that its syntax is
> >> > the best thing going for it. 
> >> 
> >> I've used Python.  I don't agree.
> >
> > I'd be interested to hear your reasons. *If* you take the sharp distinction
> > that python draws between statements and expressions as a given, then python's
> > syntax, in particular the choice to use indentation for block structure, seems
> > to me to be the best choice among what's currently on offer (i.e. I'd claim
> > that python's syntax is objectively much better than that of the C and Pascal
> > descendants -- comparisons with smalltalk, prolog or lisp OTOH are an entirely
> > different matter).
> 
> (I'm ignoring the followup-to because I don't read comp.lang.python)
> 
> Indentation-based grouping introduces a context-sensitive element into
> the grammar at a very fundamental level.  Although conceptually a
> block is indented relative to the containing block, the reality of the
> situation is that the lines in the file are indented relative to the
> left margin.  So every line in a block doesn't encode just its depth
> relative to the immediately surrounding context, but its absolute
> depth relative to the global context.  Additionally, each line encodes
> this information independently of the other lines that logically
> belong with it, and we all know that when some data is encoded in one
> place may be wrong, but it is never inconsistent.
> 
> There is yet one more problem.  The various levels of indentation
> encode different things: the first level might indicate that it is
> part of a function definition, the second that it is part of a FOR
> loop, etc.  So on any line, the leading whitespace may indicate all
> sorts of context-relevant information.  Yet the visual representation
> is not only identical between all of these, it cannot even be
> displayed.

It's actually even worse than you think. Imagine you want "blank
lines" in your code, so act as paragraph separators. Do these require
indentation, even though there is no code on them? If so, how does
that interact with a listener? From what I can tell, the option chosen
in the Python (the language) community, the listener and the file
reader have different view on blank lines. This makes it harder than
necessary to edit stuff in one window and "just paste" code from
another. Bit of a shame, really.

//ingvar
-- 
When it doesn't work, it's because you did something wrong.
Try to do it the right way, instead.




More information about the Python-list mailing list