Non-Indented python

[David Bolen]

"Delaney, Timothy" <tdelaney at avaya.com> writes:

> If you use spaces everywhere, you are at the mercy of other code
> that doesn't use the *same number* of spaces for indentation. For
> example, if you use four spaces for indentation, and you cut and
> paste code that uses two spaces per indentation, nothing will
> work. You will need to reformat one or the other before copying the
> code.

Only if you are cut 'n pasting subsets of blocks to insert into other
blocks.  And if the pasted block is indented further you could always
cheat and put it within an "if 1:" or something.  Then again, for such
small subsets, it's probably fairly easy to just reindent the copied
block (environments such as python mode in emacs make that a few
keystrokes operation).

If you are working in complete block chunks you should be fine, as
Python doesn't care if you use the same indentation for all blocks
within a set of source, only that each block on its own is consistent.
Of course, visually having different indents won't look any better
than viewing tabs with a different configuration of spacing for each
hard tab than used when written.

> The problem is simply that people use the tab key and character to
> mean different things. Originally the tab key was designed to do the
> same thing as on a typewriter - advance to the next tab stop (i.e. a
> certain number of spaces). Thus you end up with editors which
> distinguish between indentation and tab because a tab is too big for
> indentation.

Well, I guess it depends on the definition of originally.  Certainly
on typewriters, the physical tab key was a mechanical way to advance
to the next tab stop.  I'm not sure about very early line printing
devices (teletypes, etc...) but on early video display terminals they
mimiced the behavior by having internal tab stops that they would move
the active cursor position to upon receive of a tab character.
Sometimes the settings were changeable in software, but sometimes just
by the terminal setup via the keyboard.

But even in the earliest video displays, and unlike with typewriters,
there was no forced linkage between the tab key on the keyboard and
the processing of the tab character.  Yes, editors at the time often
just echoed back the characters received, so pressing the tab key
ended up sending the tab character out to the display where it got
processed, but there was no requirement that it did so.

> It would have been so much easier if it had originally been defined
> that the tab key always generated a tab *character*,

It did - terminals would send back a tab character when the tab key
was pressed.  Technically (keyboard scan codes, and virtual stuff like
X mappings and what not aside) it still does that today.

It's really the interpretation end that has changed - e.g., not
blindly echoing that tab character back out to the display device, but
doing more complicated software processing on it instead.

>                                             and that the tab *character*
> had been defined as equivalent in size to four spaces (or 3
> perhaps). This rule of course would be broken by applications which
> can set their own tab stops, but that's up to the application. The
> important thing is that there should *always* be a direct mapping
> between the tab key and the tab character.

And I think there is.  I think instead what you're arguing more for is
on the processing end, and simply a different definition of what a
display device should do upon receipt of a tab character (or even more
generally, how software should emulate such behavior), which is
probably an exercise in futility, since there will be such a wide
variety of possibilities.

--
-- David
-- 
/-----------------------------------------------------------------------\
 \               David Bolen            \   E-mail: db3l at fitlinxx.com  /
  |             FitLinxx, Inc.            \  Phone: (203) 708-5192    |
 /  860 Canal Street, Stamford, CT  06902   \  Fax: (203) 316-5150     \
\-----------------------------------------------------------------------/