Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Bart <bc@freeuk.com>
Newsgroups: comp.unix.shell,comp.unix.programmer,comp.lang.misc
Subject: Re: Python (was Re: I did not inhale)
Date: Tue, 27 Aug 2024 11:26:18 +0100
Organization: A noiseless patient Spider
Lines: 80
Message-ID: <vak9k9$2ujrs$1@dont-email.me>
References: <uu54la$3su5b$6@dont-email.me> <v9m4gd$14scu$1@dont-email.me>
 <20240815182717.189@kylheku.com> <v9npls$1fjus$1@dont-email.me>
 <v9t204$2dofg$1@dont-email.me> <va28pi$3dldm$1@dont-email.me>
 <va2ro9$3gd7v$1@dont-email.me> <va2vt0$3h3gj$1@dont-email.me>
 <va44rh$3p1l6$1@dont-email.me> <va45eq$3pkt9$1@dont-email.me>
 <va4aut$3q4g0$1@dont-email.me> <va4fbr$3qvij$1@dont-email.me>
 <va5108$3tmmd$1@dont-email.me> <va51ok$3tqr9$1@dont-email.me>
 <va5ec2$3vluh$1@dont-email.me> <va6q4g$c1a7$1@dont-email.me>
 <va6rpa$c6bg$1@dont-email.me> <va6se9$cb8e$1@dont-email.me>
 <20240826083330.00004760@gmail.com> <vaises$2k7o6$2@dont-email.me>
 <20240826155113.000005ba@gmail.com> <wwvo75eicla.fsf@LkoBDZeT.terraraq.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 27 Aug 2024 12:26:18 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="0eb40e535de99d049ec5580a004404e4";
	logging-data="3100540"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19e6ibPXtf15fYnLde6Z3aW"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:t4KK95iKFwxavJiRoexToSo48p8=
In-Reply-To: <wwvo75eicla.fsf@LkoBDZeT.terraraq.uk>
Content-Language: en-GB
Bytes: 5551

On 27/08/2024 09:39, Richard Kettlewell wrote:
> John Ames <commodorejohn@gmail.com> writes:
>> But even if that helps you organizationally, it doesn't resolve issues
>> of the interpreter potentially mis-parsing things due to mismatches in
>> tab/space factor between $EDITOR and the Python RTE, which is a truly
>> ridiculous thing to have to be concerned about.
> 
> In many years of using Python routinely and extensively I’ve simply
> never found the whitespace issues that people are worrying about here to
> be a problem in practice. Some of this may be a matter of experience but
> if so, it’s a form of experience that must have built up very quickly.
> 
> As an aesthetic objection, of course, there’s no accounting for
> taste. But it doesn’t seem to be a practical problem in reality.
> 
> (In contrast C’s rules have occasionally been a practical problem,
> contributing to at least one high-profile software vulnerability and
> attracting compiler warnings to mitigate the risks.)

These are the problems I've seen. I haven't used the language 
extensively, but I've used it enough.

(1) An tab at the start of a line gets accidentally indented or 
unindented. If you weren't paying close attention, it may not be clear 
that that has happened, if this line was either the last line of an 
indented block, or the line following

(2) You want to temporarily comment out an 'if' line so that the 
following block is unconditional. You can't do that with also 
unindenting the block. And, also  the block then merges with the 
following one as it's at the same level, so when you want to change it 
back...

(3) Similarly, you want to temportarily wrap an 'if' statement, for 
example, around a block of code. But you can't do it witout indenting 
that block.

(4) Sometimes you want to add temporary debug code as part of a block. 
Usually I write such lines in all-caps and without indentation to make 
them stand out clear. With Python, I can't use all-caps and I have to 
use exactly the same indent as the rest of the block. So the lines 
merge. Then when I need to remove the code, it's not clearly delimited.

(5) Sometimes you want to temporarily comment out the contents of a 
block. But Python doesn't allow an empty block; now you have to use 
'pass'. And then get rid of if later.

(6) You want to add extra statements to the end of a block, but where IS 
the end? You have to INFER the ending by looking for a line with a 
smaller indent. But suppose you're at the bottom of a window; is that 
bottom line the last in the block, or is there another one at the same 
indent just out of sight? You have to tentatively keep peeking ahead!

(6a) And maybe there's big comment blocking in the middle of block; 
comments don't need nesting! If there are lots of comments and few 
statements, finding the end of the block (ie. the last statement of this 
block) can become quite an exercise.

(7) You take some Python code you've seen online (eg. in a usenet post) 
and paste into your editor. Maybe you want to merge it with your own code.

But its tabbing is all spaces; yours is all tabs. Plus invariably, the 
whole thing has extra indentation (eg. the leftmost statement is already 
indented). Or you want to copy code from within a block to a different 
indent level.

The whole thing gets very messy and error prone. You need special editor 
commands to deal with the mess.

Indented, non-delimited code and data is fine for machine-generated and 
machine processed code. But it's a disaster for code that has to be 
human-generated and human-maintained. It's just too fragile.

The fact that people have to resort to adding #end lines, which only 
partly deals with one or two of those problems, suggest that something 
is badly wrong.