Warp wrote:
>   How does the Python interpreter/compiler even work with different types of
> whitespace? 

I'm pretty sure most compilers complain if you mix tabs and spaces in the 
same source file, at least at the beginning of lines.  Pick one, stick with it.

>   I bet it can become pretty confusing when the interpreter is giving you
> error messages or, much worse, it will parse ok but run complately wrongly,
> even though it *looks* to be ok.

nah. If you put tabs and spaces at the start of the line in the same source 
file, you get an error message and you need to figure out why you're doing that.

>   Relying on the use of whitespace for actual syntax is idiotic (with the
> exception of separating tokens with at least one whitespace character,
> while not being important how many).

I think distinguishing newline from other whitespace is reasonable.

>   I'm not concerned about typos. I'm concerned about whitespaces being lost
> in transfer 

Well, don't do that. :-) Treat python source code as something other than 
prose, and you won't have that problem.

Really, if you're not using unicode, you're already behind the ball. So if 
your transfer mechanism can't handle whitespace, you shouldn't be using it 
to ship code around.

>   You seem to assume that statements never get longer than a certain length,
> so that they will all nicely fit in one line. Sometimes it's useful to be
> able to split statements into several lines.

You don't need special characters to do this in most line-oriented 
languages. Python, for example, happily continues the statement on the next 
line if the current line isn't finished.

    x = 27 +
        15

is all one statement.

>> Otherwise, use a pasting service.
> 
>   Why should I have to use such things just because the language has a
> braindead idea of using whitespace as syntax?

The same reason you need to if your posting service has a braindead idea 
about HTML-special tags. Why in the world would you use a language where < 
and > are significant characters, when every web service out there might 
corrupt them??

>   Because when your editor can autoindent your code, it makes programming
> enormously easier (similarly to how syntax highlighting does).

Python editors auto-indent code. I'm not sure what you mean. An indent 
always follows a line ending with a colon, and the dedent is no harder than 
your closing brace in C.

-- 
Darren New, San Diego CA, USA (PST)
   Linux: Now bringing the quality and usability of
   open source desktop apps to your personal electronics.

Post a reply to this message