On 27/08/2024 14:10, David Brown wrote:
> On 27/08/2024 12:26, Bart wrote:
>> 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.
>>>
>
> I have occasionally, but only occasionally, seen problems with white
> space.  And those would normally be caught by Python 3.
>
>>> 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.
>
> Your problems below are all valid, but not insurmountable.  I too would
> rather have explicit block delimiters, but it's not actually hard to
> work with Python as it is.
>
>>
>> (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
>>
>
> That /can/ happen.  It is a good idea to avoid mixing tabs and spaces in
> the same file.  Most editors can be configured one way or the other, but
> if you use different editors under different circumstances (as I do),
> mistakes are possible.  They are usually quickly identified and quickly
> handled.
>
>> (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...
>
> Replace your
>
>     if cond :
>
> with
>
>     if 1 :
>
> or
>
>     if True :
>
>
>>
>> (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.
>>
>
> True.  But any editor will let you select the lines and indent them.
>
>> (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.
>
> Comments are an extremely easy way to make the code stand out.
>
>>
>> (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.
>
> You can leave the "pass" in, if you don't want to get ride of it later.
> I sometimes find "pass" to be helpful as an alternative to leaving a
> hanging indented block.
>
>>
>> (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!
>
> Keep your blocks small and neat.
>
>>
>> (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.
>
> That applies to every programming language (unless you know of one that
> doesn't support comments).
>
>>
>> (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.
>
> Any sane editor will give you tools to fix that - automatic indentation,
> tab-to-space and space-to-tab conversion, manual indent or outdent block
> tools, etc.
>
>>
>> The whole thing gets very messy and error prone. You need special
>> editor commands to deal with the mess.
>
> No, you don't.  (Unless you think "special" means "anything but Windows
> Notepad" .)
>
>>
>> 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.
>>
>
> In real-life Python coding, it works fine.  I prefer explicit block
> delimiters, but I cannot say Python's white-space blocking has been a
> significant source of trouble or inconvenience for me.  Perhaps that's
> because I have always been used to careful and consistent formatting.  I
> don't write C code (or any other code) with inconsistent spacing, mixes
> of tabs and spaces, or unexpected indentations.  So for me, the spacing
> and tabbing of Python code would be identical if it had braces or other
> begin-end markers.
>
>> 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.
>>
>
> No one has to do that.  It's a Lawrence peculiarity, and his coding
> style (in Python or C, and probably anything else) would be rejected by
> anyone with a coding standard.  I agree that it suggests that something
> is badly wrong, but it is not with the language!

It's not just him. Below is some Nim code, which uses indentation like
Python. (It's from inside other statements which accounts for the
overall indents.)

Suppose I want to add code to follow that top-level 'if' statement;
where would it go? Since it's not clear from my extract whether that's
the entire content of my if statement.

And at what indent level, since I'm some way off from that if? It's easy
to get it wrong.

if q1!=1:
for i in countup(2,n):
q[i]=p[i]
flips=1
while true:
qq=q[q1]
if qq==1:
sum+=sign*flips
if flips>maxflips:
maxflips=flips
break
q[q1]=q1
if q1>=4:
i=2
j=q1-1
while true:
t=q[i]
q[i]=q[j]
q[j]=t
i+=1
j-=1
if i>=j:
break
q1=qq
flips+=1

This was an attempt to port an benchmark into Nim; I'd spent the best
part of an hour trying to get it right, but it kept going wrong. In the
end I resorted to artificial block terminators.

The final code looked like that below. Now it is much, much easier to
see what goes where, and what belongs to what. I can more confidently
write that extra statement following the opening 'if'.

With these changes, the porting went much more smooothly.

if q1!=1:
for i in countup(2,n):
q[i]=p[i]
# end
flips=1
while true:
qq=q[q1]
if qq==1:
sum+=sign*flips
if flips>maxflips:
maxflips=flips
# end
break
# end
q[q1]=q1
if q1>=4:
i=2
j=q1-1
while true:
t=q[i]
q[i]=q[j]
q[j]=t
i+=1
j-=1
if i>=j:
break
# end
# end
# end
q1=qq
flips+=1
# end
# end

Sure, people CAN program in such languages, but it is harder work and
more error prone.