Non-Indented python

[Peter Hansen]

Huaiyu Zhu wrote:
> 
> On Sat, 24 Nov 2001 21:25:22 -0500, Peter Hansen <peter at engcorp.com> wrote:
[...]
> 
> - That there is no reason to associate tab with any equivalent in spaces.
>   It should only be used as a distinct character in its own right.
> 
> - That the problems with different tab-sizes are all caused by people
>   presuming tab can be used as a short hand for spaces.

I didn't miss those points.  I agree with the latter.  The
former is also true, provided you are talking strictly about TAB==X spaces,
which is *never* something I said.  By the way, the phrase "tab size"
was outlawed by David a few messages back, I believe.  Remember,
tabs don't have sizes, or so we were told.  See below.

> >Yes, the above is what people call a tab.  That doesn't say anything
> >about the uses to which people (and software) put it.  It is *that*
> >which is ambiguous and inconsistent.  
> 
> There is no problem in using it the right way - as a place-holder of
> indentation level.  It can be displayed anyway you want, as long as you do
> not _assume_ the writer and reader will ever display them the same way in
> terms of spaces.

This would of course not cause any trouble provided those who used
it, used it consistently.  That is, they *never* used anything spaces
for indentation.  Problem is, they don't follow that rule, and 
don't seem to understand that, with Python having mandated a convention, 
any mixed use of spaces and tabs set to other than every 8 columns will 
confuse Python.

> If you get around the notion that tab can ever be translated into spaces in
> a _universal_ way, you'll find that all the problems dissappear.
>
> For example, got a problem with mixing tab and space?  Well, just don't do
> it.  They are two different characters.  It's the same as mixing w with vv
> or mixing m with rn.  If this is enforced with the same strictness there
> would be no more problem with mixing tab and space than mixing w and vv.

Obviously.  Isn't this the whole point?  Didn't I say that 
mixing tabs and spaces was going to cause trouble?  Thought I did.
Anyway, much of this discussion, if not all of it, revolves 
around the fact that some people *do* mix them.  That is
apparently inevitable.  Therefore, to at least set a convention,
if not completely solve the problem, the Python standard is to
define TAB as representing indentation to the next multiple of
eight spaces.  End of story... beginning of some people's problem.
Mixing the two without using 8-space TABs confuses Python.
Mixing the two even with 8-space TABs confuses everyone, 
including the programmer, when indentation levels are changed.

(And no, I do *not* mean TABs which translate directly into
8 spaces, I mean TABs which advance to the next column multiple
of eight.  Or however you insist on pronouncing it.)

> >Tab, tabstop, whatever.  There's no "tab" in the binary world either.
> >Just ones and zeros.
> 
> Nonesense.  There does exist a tab character, which is _defined_ as a
> combination of zeros and ones.  What has that to do with tabstop, which is a
> horizontal postition?

Yadda yadda yadda.  Of course there is a TAB character.  The
fact that I know that was readily apparent.  Yes, we all 
understand binary.  That too is apparent.  Why don't *you*
define an easy way to describe the "size" -- no wait, I mean
"tabstop" -- no wait, I can't say that either -- the indescribable
characteristic of the TAB character which when represented 
onscreen as a shift in cursor position can be considered to 
represent a particular *number* of columns.... I've been told
I can't use "tab size" for that, nor "tabstop", nor probably
tab width, spacing, or any other term ever used by an editor.
If we not only can't agree on a term for it, and you won't
even let me define my own term clearly and attempt to use
it for rational discussion, I guess we're done...

> >Once again, the point you missed is that tabs are sometimes
> >treated (by software) in such a way as to advance the cursor
> >other than to the next multiple of 8 (which effect I was calling
> >the tabstop, so I wouldn't get jumped on by people like you for
> >saying tabs represented a fixed 8 spaces).
> 
> Why would it matter to you how other people are displaying a particular
> character on screen?  They could just as well display it as red circle
> inside a blue star followed by a yellow triangle inside a green square.  As
> long as this character is encoded correctly all the programs they sent you
> will display on your screen the way you want to.

I care nothing for other people <wink>, nor how they 
display TABs.  I am only concerned about them wasting time
when they mistakingly think they will be able to type Python
code with a mix of TABs and SPACEs when their TABs are not 
set to 8.

> Where is the inconsistency you are complaining about?

When they mix it with spaces.  Which is where I started about
when I mentioned "ambiguity", but we seem to have agreed about the 
inadvisability of that, so there's no argument.

> I think his point is quite clear.  The reason you do not see it that way is
> because, IMHO, you have not seriously considered the possibility that people
> might be arguing for the position that tabs can be used consistently without
> a defined equivalence as spaces.

If you think I was suggesting TABs should be treated as X spaces,
you missed everything I said.  By the way, is that phrase you used --
"the position of tabs" -- the permitted way of describing what I 
inappropriately (so it seems) termed tab "size", and "width", and
when my wrist was slapped tried "tabstop" as a temporary substitute?
Maybe if we all talk about "position of tabs" we can get somewhere.
Problem is, that's the first time in this discussion *that* 
particular way of describing it has come up

Sigh.  All that typing, and still you two seem to insist
that I was saying things I did not intend, because you seem
to believe I don't understand about TAB *characters* just
because I used a different term for "width/size/stop/position"
than you did.  I think I'll quit while I'm way behind on this one.

-- 
----------------------
Peter Hansen, P.Eng.
peter at engcorp.com