Non-Indented python

[Huaiyu Zhu]

On Tue, 27 Nov 2001 00:40:46 -0500, Peter Hansen <peter at engcorp.com> wrote:
>Huaiyu Zhu wrote:
>> 
>> On Sat, 24 Nov 2001 21:25:22 -0500, Peter Hansen <peter at engcorp.com> wrote:
>
>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.

Just to clear up possible misunderstanding: no one is arguing with you about
tab "size" vs tab "position" - this is a minor issue.  If you think that's
the argument, you are missing the point.

The argument is whether the display of tab (be it size, position, shape,
color, sound, smell, whatever) should have ANY default at all.

Now that is clear, maybe you can reread the previous articles in a different
light.

>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.

Have it ever occured to you, that it might be possible, however unlikely at
first glance, that the rule itsself is the source of inconsistency? 

Maybe, just maybe, that ANY setting of equivalence between tab and space
would be inconsistent?

Maybe, just maybe, that if a language identifies m with rn it would cause
similar amount of headache?

Just give it a thought.  You have to admit that it is a possibility.

Yeah, yeah, Python did not invent the rule.  That does not change whether
the rule is consistent.

>
>> 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.

Not if your argument is consistent.  In your ideal world that everyone
interprets tab as 8 spaces there would be no problem mixing them.  If you
accept that mixing them is inconsistent whatever the equivalence is defined,
why would you insist on tab=8?  Wouldn't it be just as wrong as tab=42?

So my understanding of your point is that tab=8 is prefered to tab=other,
not about whether tab=anything is allowed.

I hope you do agree that they are two different questions.

>  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.

It is in fact the beginning of everybody's problem.

> 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.... 

Why don't *I* define that?  Because, as you might have figure out by now, I
don't think it is possible.  It does not matter who defines it.  Any
definition would be inconsistent.  Why don't *you* define whether m equals
rn or nn?

> 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...

Of course you can use these terms to describe the proper editor actions or
screen positions and so on.  But have you realized that you need an argument
before associating these terms with tab the character?

>  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.

You are concerned if they make the mistake when their tab is set to 4, or 2,
or 7 or 9, or whatever, except that you are not concerned when they make
exactly the same mistake when it is set to 8?  What is so special about this
magic number 8?

If I were to care about this, I would be concerned about this mistake even
if their tab is set to ANY size, or position, or shape, or sound, ...

If a mistake is not allowed in any special cases, it is much less likely to
be made in all cases at all.

>
>> 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.

If the inconsistency is mixing tabs with spaces, then setting a default
equivalence between them actually contribute to it instead of prevent it.

>
>> 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.

We understand your point perfectly clear.

I think you refuse to believe that it could be possible that people are
arguing against ANY default display property of tab altogether.  Therefore
you continue to interpret them as trivial arguments about HOW the default
should be defined.

So let me repeat it once and for all:

Question: What should tab be default to in terms of other charactors, or
  screen positions, or editor actions, or anything else that is not the tab
  charactor?

Answer: It shouldn't.

Huaiyu