Python's biggest compromises

[John Roth]

"Andy C" <ayc8NOSPAM at cornell.edu> wrote in message
news:mEVWa.279$jw6.24163477 at newssvr21.news.prodigy.com...
> > Many tools don't allow you to configure tabs, and of those that do,
> > each uses its own incompatible syntax and has its own quirks. In other
> > words, tabs may seem like a good thing if you use just one or two tools
> > that do what you want, but as soon as your program moves out into
> > the wild world, things change.
>
> What are these quirks?  By far the most common I've seen is mixing tabs
and
> spaces, but this should be relatively easily solved by requiring one or
the
> other (minus continuation lines, which are still a problem).  Using spaces
> has some disadvantages too, since not everyone will use the same number of
> spaces, and editors don't behave as nicely.  I like when you hit the arrow
> key at a tab, and it jumps the full tab, rather than having to press an
> arrow key 4 times.

I'm used to a certain minimum standard from my editors, and smart
tabs are one of those things that's part of the price of admission these
days, just like syntax highlighting. A programming editor's job is to help
where it's useful, and get out of the way when it's not. When you want
to indent, you hit the tab button. It's the editor's job to know I want,
for example, four spaces, and deliver them. In Python, it's the editor's
job to know that when I hit return at the end of a line, there are only one
or two legitimate places to put the cursor on the next line, and to put
it in the most likely of them.

As to the different number of spaces between developers, that's
another thing I'd expect from my editors. It's easy enough in Python
to figure out what's an indent and infer the number of spaces. I'd
expect a decent editor to be able to load a program and tell me
what the indentation policy was! I'd also expect to be able to tell
it to change it, and have it automatically reindent the program for
me.

John Roth