Python's biggest compromises

[John Roth]

"John J. Lee" <jjl at pobox.com> wrote in message
news:87el06d2i6.fsf at pobox.com...
> "John Roth" <newsgroups at jhrothjr.com> writes:
> [...]
> > That said, I've come to the conclusion that the editor should take
> > care of these things for you. If you prefer a brace free notation,
> > you should be able to tell your editor to present the program to you
> > that way. If you prefer braces, then it should be able do that for
> > you as well. That kind of stylistic thing doesn't belong in the
> > language.
>
> 100% agreed: once-and-only-once dictates this.  Manually maintaining
> both braces and indentation (as in C, with some editors) is Just Plain
> Bad for this reason.
>
>
> > In fact, if I didn't have to deal with the braces, I think I'd come
> > around to the view that the text should have them. Explicit is
> > better than implicit,
>
> At least in the absence of proper research results, I think this part
> of it *is* religious.  To some people, it's obvious that whitespace is
> better on the eyes.  To others, it's obvious that whitespace + braces
> is better on the eyes.  One group may well be wrong <0.5 wink>.
>
> This argument (that braces are another visual cue which make code
> easier to read -- provided that they're automatically maintained in
> sync with the indentation), is the only argument against
> pure-whitespace that has ever made any sense to me.

I believe there was quite a bit of research on this issue in ABC,
which was the research system that Guido learned on when he
was in university. One of the fallouts from that is the colon at the
end of block headers: it's syntactically unnecessary, but it does
seem to help the eyes.

I wouldn't characterize it as religious. Brains don't work the
way most people think they do, and if you've programmed yours
one way, it seems to depend on a proper choice of grandparents,
or the proper diet, or maybe the phase of the moon whether you'll
be comfortable changing it.

> Irrespective of
> whether you pick whitespace or braces as the thing the compiler takes
> notice of, though, the optimal solution probably still involves an
> editor that supports showing/hiding braces, so the syntax is
> (theoretically!) a non-issue.  In practice, editors don't seem to
> currently support showing and hiding braces automatically.  At least
> editors do get you out of most mistakes caused by brace-y languages.
>
> Of course, whitespace *is* still superior because the storage format
> doesn't duplicate state -- so people with poor editors can't produce
> ambiguous code :-) (remember code can be ambiguous to *people* even if
> it isn't to a compiler).  OTOH, *Python's* scheme is inferior to a
> pure-space-character indentation scheme because off the tab-vs.-space
> issue :-(

Well, that's been recognized as a problem for a long time. I believe
that the intention is to mandate spaces only in Python 3.0. On the
other hand, I'm not holding my breath waiting for Guido to decide
he's had enough 2.x releases and start work on 3.0 To be frank
about it, I don't see a crying need for 2.4 before 3.0,
and if he's after mind share, he's got both Ruby and the redesign
of Perl breathing down his neck. The new Perl regex package looks
nice! Three years ago, he didn't have any credible competition in
the high quality but easy to use scripting language arena. Now he
does.

> > and there are a few things that the
> > automatic indentation makes rather difficult in the design area.
> [...]
>
> What are those things??

Embedding Python in other languages, such as HTML, for
starters. It can be done, but it isn't pretty.

I've run across a couple of other places where I wished I
had braces, but they weren't important enough to stick in
my memory.

John Roth

>
>
> John