On Tue, 27 Aug 2024 20:46:27 +0200, David Brown wrote:

> It is not common to have to have indent comment lines (certainly in
> Python it is not necessary). And if you find yourself writing large
> comments in the middle of a block in the middle of a function, it is
> probably time to consider re-organising the code and/or the comments and
> documentation. (Again, there can be exceptions to this general rule.)

Counterexample: <https://www.cairographics.org/cookbook/freetypepython/>
(Yes, that’s one of mine). Note the explanation of the user-data dance,
for backward compatibility with older FreeType. Where else would you put
the comments, if not next to the code they’re explaining?

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> On Tue, 27 Aug 2024 11:26:18 +0100, Bart wrote:
[...]
>> 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...
>
> This is where my “#end” comments come in.
[...]

It's worth noting that you're the only person I've ever heard of
who feels the need to do this. People here who aren't familiar
with Python should be aware that this is not common practice.

I've done some Python programming, and it wouldn't occur to me to
add "#end" comments. If I saw them in a code review I'd probably
recommend deleting them. I prefer to approach each language on
its own terms. (I happen to like the way Python uses semantically
significant indentation, but even if I didn't I'd still do the same.)

In brace-delimited languages (C, C++, Perl, etc.), I'm very careful
to keep the indentation consistent with the program structure.
I do the same in Python. The difference is that in Python the
indentation is the single source of truth about program structure,
while in other languages it's a matter of convention.

https://en.wikipedia.org/wiki/Single_source_of_truth

As for tabs vs. spaces, my understanding is that recent versions
of Perl allow mixing them (something I avoid), but if the meaning
can change depending on the size of a tabstop the code is rejected.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

On Tue, 27 Aug 2024 14:49:19 -0700, Keith Thompson wrote:

> I've done some Python programming, and it wouldn't occur to me to add
> "#end" comments. If I saw them in a code review I'd probably recommend
> deleting them.

Give them a try. They simplify a lot of situations. I already posted a
reasonably complex example in this thread. Go have a look at it, and see
what happens when you delete those comments.

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> On Tue, 27 Aug 2024 14:49:19 -0700, Keith Thompson wrote:
>> I've done some Python programming, and it wouldn't occur to me to add
>> "#end" comments. If I saw them in a code review I'd probably recommend
>> deleting them.
>
> Give them a try. They simplify a lot of situations. I already posted a
> reasonably complex example in this thread. Go have a look at it, and see
> what happens when you delete those comments.

No, I won't be doing that.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

In comp.unix.programmer Richard Kettlewell <invalid@invalid.invalid> 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've seen bugs in production that are due to Python's indentation rules.
Consider this class:

class Foo:
def method1(self):
call1()
call2()
call3()

def method2(self):
call4()
if some_condition:
with some_object() as o:
call5()
# hundreds of other lines of code
call6()

At my company, somebody tried to delete a method like method2() above,
but forgot the last few lines (represented by call6()). This does
not introduce a SyntaxError. Instead, call6() is now part of method1()
because it's at the same level of indentation. In most programming
languages, the beginning of method2() would be preceded by some delimiter
marking the end of method1(), which would prevent an accidental merger
of this type.

In comp.unix.programmer Richard Kettlewell <invalid@invalid.invalid> wrote:
> Bart <bc@freeuk.com> writes:
>> On 27/08/2024 09:39, Richard Kettlewell wrote:
>
>> 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.
>
> I?ve never encountered anyone else doing that in Python. It suggests
> more than the individual doing that just doesn?t like the language, in
> which case I?d just suggest that person doesn?t use it.

I think it's a great idea. I'm considering asking my team to start adding
#end comments to our codebase.

In comp.unix.programmer David Brown <david.brown@hesbynett.no> wrote:
>
> It is not common to have to have indent comment lines (certainly in
> Python it is not necessary). And if you find yourself writing large
> comments in the middle of a block in the middle of a function, it is
> probably time to consider re-organising the code and/or the comments and
> documentation. (Again, there can be exceptions to this general rule.)
>

It may not be "common" (ie, not a lot of languages have this requirement),
but if it's your job to maintain a project written in such a language,
then you'll have to deal with that problem every single day.

On Tue, 27 Aug 2024 19:10:57 -0700, Keith Thompson wrote:

> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>
>> On Tue, 27 Aug 2024 14:49:19 -0700, Keith Thompson wrote:
>>>
>>> I've done some Python programming, and it wouldn't occur to me to add
>>> "#end" comments. If I saw them in a code review I'd probably
>>> recommend deleting them.
>>
>> Give them a try. They simplify a lot of situations. I already posted a
>> reasonably complex example in this thread. Go have a look at it, and
>> see what happens when you delete those comments.
>
> No, I won't be doing that.

I wonder why? You expressed an opinion about them, yet when I try to find
out more about why you feel that way, you run away.

On 28/08/2024 05:19, Sebastian wrote:
> In comp.unix.programmer David Brown <david.brown@hesbynett.no> wrote:
>>
>> It is not common to have to have indent comment lines (certainly in
>> Python it is not necessary). And if you find yourself writing large
>> comments in the middle of a block in the middle of a function, it is
>> probably time to consider re-organising the code and/or the comments and
>> documentation. (Again, there can be exceptions to this general rule.)
>>
>
> It may not be "common" (ie, not a lot of languages have this requirement),
> but if it's your job to maintain a project written in such a language,
> then you'll have to deal with that problem every single day.

If you have some code that needs a lot of documentation (and some does),
then put the comments in a place that does not interfere with reading
and understanding the code. Comments that make code harder to read are
counter-productive.

Where these comments end up - elsewhere in the function, outside the
function, at the head of the file, in a separate file, in completely
separate documentation - depends on the situation.

Sebastian <sebastian@here.com.invalid> writes:
>In comp.unix.programmer Richard Kettlewell <invalid@invalid.invalid> wrote:
>> Bart <bc@freeuk.com> writes:
>>> On 27/08/2024 09:39, Richard Kettlewell wrote:
>>
>>> 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.
>>
>> I?ve never encountered anyone else doing that in Python. It suggests
>> more than the individual doing that just doesn?t like the language, in
>> which case I?d just suggest that person doesn?t use it.
>
>I think it's a great idea. I'm considering asking my team to start adding
>#end comments to our codebase.

I think you're a L'D'O sockpuppet.

On Wed, 28 Aug 2024 02:48:59 -0000 (UTC)
Sebastian <sebastian@here.com.invalid> wrote:

> At my company, somebody tried to delete a method like method2() above,
> but forgot the last few lines (represented by call6()). This does
> not introduce a SyntaxError. Instead, call6() is now part of method1()
> because it's at the same level of indentation. In most programming
> languages, the beginning of method2() would be preceded by some
> delimiter marking the end of method1(), which would prevent an
> accidental merger of this type.

(Waiting for the Python advocates to fire back with "well, don't do
that, then!" and completely miss the point that it's exactly the topic
of contention here that Python's scope-by-layout approach that makes it
easy to do that...)

John Ames <commodorejohn@gmail.com> writes:
> Sebastian <sebastian@here.com.invalid> wrote:
>
>> At my company, somebody tried to delete a method like method2()
>> above, but forgot the last few lines (represented by call6()). This
>> does not introduce a SyntaxError. Instead, call6() is now part of
>> method1() because it's at the same level of indentation. In most
>> programming languages, the beginning of method2() would be preceded
>> by some delimiter marking the end of method1(), which would prevent
>> an accidental merger of this type.
>
> (Waiting for the Python advocates to fire back with "well, don't do
> that, then!" and completely miss the point that it's exactly the topic
> of contention here that Python's scope-by-layout approach that makes it
> easy to do that...)

Earlier I wrote:

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

The situation seems pretty similar. In any language if you delete the
wrong thing then you probably won’t like the outcome. In both cases if
it’s not quickly detected by unit tests or some other automation then
it’s probably time to review your approach to quality.

--
https://www.greenend.org.uk/rjk/

On 28/08/2024 17:41, Bart wrote:
> On 28/08/2024 16:25, John Ames wrote:
>> On Wed, 28 Aug 2024 02:48:59 -0000 (UTC)
>> Sebastian <sebastian@here.com.invalid> wrote:
>>
>>> At my company, somebody tried to delete a method like method2() above,
>>> but forgot the last few lines (represented by call6()). This does
>>> not introduce a SyntaxError. Instead, call6() is now part of method1()
>>> because it's at the same level of indentation. In most programming
>>> languages, the beginning of method2() would be preceded by some
>>> delimiter marking the end of method1(), which would prevent an
>>> accidental merger of this type.
>>
>> (Waiting for the Python advocates to fire back with "well, don't do
>> that, then!" and completely miss the point that it's exactly the topic
>> of contention here that Python's scope-by-layout approach that makes it
>> easy to do that...)
>>
>
> Or they will say that whoever deleted method2 could also have deleted
> that 'end' line if one was used. Whilst also forgetting to delete
> method2's own 'end' line.
>
> Or maybe they deleted method2 plus both the preceding and succeeding
> lines so that method1 merges into method3.
>
> Generally, they might point all the ways that such oversights and all
> kinds of other typos can result in still-valid code in any language. But
> fragile syntax like Python's just makes it so easier to do that.
>

Having overly-large functions in any language is a risky way to code.
Deleting large chunks of a function is risky in any language. Failing
to have check in place (like automated tests) that catch the error
fairly quickly is also risky in any language.

But it is fair to say, I think, that Python's space-sensitive syntax
combined with limited static checking (even with tools like pylint) mean
you are more likely to be able to make a mistake that is not spotted
until later in testing, compared to languages with explicit block
delimiters.

And it is made worse by Python common practice of defining all methods
of a class inline in the class, leading to long stretches of code that
is all indented at least one tabstop. It is possible to add methods to
a class later on - optionally after giving a placeholder, but it is not
common practice (as far as I have seen) :

class A :
def __init__(self) :
self.x = 10
def foo(self) :
"Increment x"
self.x = self.x + 1
return self.x
def foobar(self) :
"Complicated action"
raise NotImplementedError

def A_foobar(self) :
self.x = self.x * 10
return self.x

A.foobar = A_foobar

(I'm sure a decorator could be used to make this slightly neater.)

On Tue, 27 Aug 2024 21:34:54 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>On Tue, 27 Aug 2024 11:26:18 +0100, Bart wrote:
>
>> (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.
>
>In Emacs, I have commands defined to adjust the indentation of the
>selected region. Surely any other decent editor would offer the same.

Writing editor editor macros in order to work around fundamentally bad
language design is not something a programmer should have to waste time on.

On Tue, 27 Aug 2024 14:49:19 -0700
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>I do the same in Python. The difference is that in Python the
>indentation is the single source of truth about program structure,

Sadly.

>while in other languages it's a matter of convention.
>
>https://en.wikipedia.org/wiki/Single_source_of_truth

That reads like the sort of pseudo philosphical gasbagging beloved of a
certain type of ivory tower university lecturer who would probably last 2 days
in a commercial IT enviroment.

On 28/08/2024 19:43, Muttley@dastardlyhq.com wrote:
> On Tue, 27 Aug 2024 21:34:54 -0000 (UTC)
> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>> On Tue, 27 Aug 2024 11:26:18 +0100, Bart wrote:
>>
>>> (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.
>>
>> In Emacs, I have commands defined to adjust the indentation of the
>> selected region. Surely any other decent editor would offer the same.
>
> Writing editor editor macros in order to work around fundamentally bad
> language design is not something a programmer should have to waste time on.
>
>

I don't know about Emacs, but in most editors the way you indent a block
of code is to select the lines, then press "Tab". Unindenting is
"shift-Tab". Changing tabs to spaces or spaces to tabs is done by
selecting "Tabs to spaces" from the Edit menu, or something equally
simple and obvious. Many editor can be set to convert tabs to spaces
(or vice versa) when saving files, perhaps specific to the file type (so
you don't muck up your makefiles).

It takes a special kind of genius to be able to program, and yet still
have trouble with this kind of thing.

On 28/08/2024 19:48, David Brown wrote:
> On 28/08/2024 19:43, Muttley@dastardlyhq.com wrote:
>> On Tue, 27 Aug 2024 21:34:54 -0000 (UTC)
>> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>> On Tue, 27 Aug 2024 11:26:18 +0100, Bart wrote:
>>>
>>>> (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.
>>>
>>> In Emacs, I have commands defined to adjust the indentation of the
>>> selected region. Surely any other decent editor would offer the same.
>>
>> Writing editor editor macros in order to work around fundamentally bad
>> language design is not something a programmer should have to waste
>> time on.
>>
>>
>
> I don't know about Emacs, but in most editors the way you indent a block
> of code is to select the lines, then press "Tab".  Unindenting is
> "shift-Tab".  Changing tabs to spaces or spaces to tabs is done by
> selecting "Tabs to spaces" from the Edit menu, or something equally
> simple and obvious.  Many editor can be set to convert tabs to spaces
> (or vice versa) when saving files, perhaps specific to the file type (so
> you don't muck up your makefiles).
>
> It takes a special kind of genius to be able to program, and yet still
> have trouble with this kind of thing.

The main problem isn't in changing the indentation of a block of code;
it is in HAVING to do so because of poor language design. A lesser one
is having to rely on whatever varied features that 100s of different
editors may have to do so.

And yet another, of more significance, if that after you've indented a
block, it may now merge into an adjacent block that was already at that
new indent. If you later need to revert that first block back to it's
original position, you'd better make sure you mark that boundary.

It is a language design issue pure and simple. Don't try and pin it on
the users and make out it's due to lack of expertise with their editors.
Of course we can all indent blocks; it's just an unnecessary palaver.

Clearly your point of view is as a language /user/ where languages and
their characteristics are an invariant that you can't do anything about,
can't change, and need to work around.

But some of us devise (and, importanly, implement) languages of our own
and can be more vocal about misfeatures in others.

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> On Tue, 27 Aug 2024 19:10:57 -0700, Keith Thompson wrote:
>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>> On Tue, 27 Aug 2024 14:49:19 -0700, Keith Thompson wrote:
>>>> I've done some Python programming, and it wouldn't occur to me to add
>>>> "#end" comments. If I saw them in a code review I'd probably
>>>> recommend deleting them.
>>>
>>> Give them a try. They simplify a lot of situations. I already posted a
>>> reasonably complex example in this thread. Go have a look at it, and
>>> see what happens when you delete those comments.
>>
>> No, I won't be doing that.
>
> I wonder why? You expressed an opinion about them, yet when I try to find
> out more about why you feel that way, you run away.

I didn't intend to run away, I was just declining to engage.

But ok, I found your post and removed all the #end comments. I found it
just as readable without them as with them.

I'm very much aware that different people perceive things differently.
(An unrelated example: I find "Yoda conditions" like `if (42 == value)`
deeply annoying, but some people like them.) If #end comments help you,
I'm not going to tell you not to use them. But be aware that (a) other
readers might dislike them, and (b) if you're going to be reading Python
code written by others, you'll need to be able to get along without
them.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

Bart <bc@freeuk.com> writes:
> On 28/08/2024 19:48, David Brown wrote:
>> On 28/08/2024 19:43, Muttley@dastardlyhq.com wrote:
>>> On Tue, 27 Aug 2024 21:34:54 -0000 (UTC)
>>> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>>> On Tue, 27 Aug 2024 11:26:18 +0100, Bart wrote:
>>>>
>>>>> (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.
>>>>
>>>> In Emacs, I have commands defined to adjust the indentation of the
>>>> selected region. Surely any other decent editor would offer the same.
>>>
>>> Writing editor editor macros in order to work around fundamentally bad
>>> language design is not something a programmer should have to waste
>>> time on.
>>>
>>>
>> I don't know about Emacs, but in most editors the way you indent a
>> block of code is to select the lines, then press "Tab".  Unindenting
>> is "shift-Tab".  Changing tabs to spaces or spaces to tabs is done
>> by selecting "Tabs to spaces" from the Edit menu, or something
>> equally simple and obvious.  Many editor can be set to convert tabs
>> to spaces (or vice versa) when saving files, perhaps specific to the
>> file type (so you don't muck up your makefiles).
>> It takes a special kind of genius to be able to program, and yet
>> still have trouble with this kind of thing.
>
> The main problem isn't in changing the indentation of a block of code;
> it is in HAVING to do so because of poor language design. A lesser one
> is having to rely on whatever varied features that 100s of different
> editors may have to do so.
>
> And yet another, of more significance, if that after you've indented a
> block, it may now merge into an adjacent block that was already at
> that new indent. If you later need to revert that first block back to
> it's original position, you'd better make sure you mark that boundary.
>
> It is a language design issue pure and simple. Don't try and pin it on
> the users and make out it's due to lack of expertise with their
> editors. Of course we can all indent blocks; it's just an unnecessary
> palaver.
>
> Clearly your point of view is as a language /user/ where languages and
> their characteristics are an invariant that you can't do anything
> about, can't change, and need to work around.
>
> But some of us devise (and, importanly, implement) languages of our
> own and can be more vocal about misfeatures in others.

If I'm moving chunks of code around in a C or C++ program, from one
scope to another, I can get away with leaving the indentation as it is,
because all the compiler cares about is where the braces are. But I
*always* adjust the indentation to fit the code's new context.

Python's use of indentation to indicate scoping just means that I have
to do what I would have done anyway.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

On 28/08/2024 21:37, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
>> On 28/08/2024 19:48, David Brown wrote:
>>> On 28/08/2024 19:43, Muttley@dastardlyhq.com wrote:
>>>> On Tue, 27 Aug 2024 21:34:54 -0000 (UTC)
>>>> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>>>> On Tue, 27 Aug 2024 11:26:18 +0100, Bart wrote:
>>>>>
>>>>>> (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.
>>>>>
>>>>> In Emacs, I have commands defined to adjust the indentation of the
>>>>> selected region. Surely any other decent editor would offer the same.
>>>>
>>>> Writing editor editor macros in order to work around fundamentally bad
>>>> language design is not something a programmer should have to waste
>>>> time on.
>>>>
>>>>
>>> I don't know about Emacs, but in most editors the way you indent a
>>> block of code is to select the lines, then press "Tab".  Unindenting
>>> is "shift-Tab".  Changing tabs to spaces or spaces to tabs is done
>>> by selecting "Tabs to spaces" from the Edit menu, or something
>>> equally simple and obvious.  Many editor can be set to convert tabs
>>> to spaces (or vice versa) when saving files, perhaps specific to the
>>> file type (so you don't muck up your makefiles).
Newsgroups: comp.unix.shell,comp.unix.programmer,comp.lang.misc
Subject: Re: Python (was Re: I did not inhale)
Date: Wed, 28 Aug 2024 21:44:56 +0100
Organization: A noiseless patient Spider
Lines: 72
Message-ID: <vao288$3k01j$1@dont-email.me>
References: <uu54la$3su5b$6@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>
>>> It takes a special kind of genius to be able to program, and yet
<20240826083330.00004760@gmail.com> <vaises$2k7o6$2@dont-email.me>
>>> still have trouble with this kind of thing.
>>
>> The main problem isn't in changing the indentation of a block of code;
>> it is in HAVING to do so because of poor language design. A lesser one
>> is having to rely on whatever varied features that 100s of different
>> editors may have to do so.
>>
>> And yet another, of more significance, if that after you've indented a
>> block, it may now merge into an adjacent block that was already at
>> that new indent. If you later need to revert that first block back to
>> it's original position, you'd better make sure you mark that boundary.
>>
>> It is a language design issue pure and simple. Don't try and pin it on
>> the users and make out it's due to lack of expertise with their
>> editors. Of course we can all indent blocks; it's just an unnecessary
>> palaver.
>>
>> Clearly your point of view is as a language /user/ where languages and
>> their characteristics are an invariant that you can't do anything
>> about, can't change, and need to work around.
>>
>> But some of us devise (and, importanly, implement) languages of our
>> own and can be more vocal about misfeatures in others.
>
> If I'm moving chunks of code around in a C or C++ program, from one
> scope to another, I can get away with leaving the indentation as it is,
> because all the compiler cares about is where the braces are. But I
> *always* adjust the indentation to fit the code's new context.
>
> Python's use of indentation to indicate scoping just means that I have
> to do what I would have done anyway.

If you glance at the top you will see that my original example involved
/temparily/ commenting out the 'if' part of a conditional block. Another
example was in temporarily /adding/ an 'if' around a block. And yet
another (you might want to see my original longer post) was in adding in
temporary code but deliberately not using the right indent to make it
more visible.

You don't want to waste time getting the layout exactly right and then
also risk that block disappearing into neighbouring code because
everything is now at the same indent level.

On 27/08/2024 15:18, Bart wrote:
[Previous discussion and code snipped -- ANW]
> 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.

ISTM that the difficulty in reading and writing code like that
stems not from the indentation, but
from a
long narrow
corridor
of program
which is
difficult to
read
and write
no matter how
it is indented.
Variable indentation
merely
makes the long
column wriggly.
It reminds me of the early autocodes, before the days of block structure.
I don't know Nim [and only a little of Python], so I can't apportion the
difficulty of understanding the code between the language and the chosen
programming style. But I can't resist adding a few comments:

(a) Bart takes 14 lines [from "if q1>=4" to the corresponding "# end"]
to express the notion [E&OE]

for i from 2 to q1%2
swap (q[i], q[q1 - i + 1])

Small wonder that he found the code hard to get right!

(b) There are two occurrences of "while true" and two of "break" in the
code which would not be necessary or appropriate in C or Algol [amongst
others]. Again, IMO these contribute to the obscurity of the code.

(c) I recognise that code as coming from a version of the "Fannkuch"
benchmark, so I already have it in C and in Algol 68G. Bart's Nim code
is substantially longer [around twice the length of the A68G]. Brevity
is not everything, but if you are forever scrolling from one window to
the next while your friend gets it all into one window [without losing
clarity of expression], then guess who is going to find it easier to
read, write and understand the code.

(d) Further, if the code is harder to understand, it has more need of
explanatory comments, which in turn make the code longer, so harder to
navigate around.

--
Andy Walker, Nottingham.
Andy's music pages: www.cuboid.me.uk/andy/Music
Composer of the day: www.cuboid.me.uk/andy/Music/Composers/Hertel

On Wed, 28 Aug 2024 20:27:53 +0100, Bart wrote:

> The main problem isn't in changing the indentation of a block of code;
> it is in HAVING to do so because of poor language design.

If you think the need for refactoring is something that can be solved by
“language design”, I’d like to hear how.

On Wed, 28 Aug 2024 12:45:40 +0200, David Brown wrote:

> If you have some code that needs a lot of documentation (and some does),
> then put the comments in a place that does not interfere with reading
> and understanding the code.

Put them next to the code they’re helping you read and understand.

On Wed, 28 Aug 2024 13:29:18 -0700, Keith Thompson wrote:

> But ok, I found your post and removed all the #end comments. I found it
> just as readable without them as with them.

You know what? You are right. That example was just too
well-structured.

Here’s a more dangerous one:

def register_additional_standard(self, **kwargs) :
"registers additional standard interfaces that are not automatically" \
" installed at Connection creation time. Currently the only one is" \
" the object-manager interface, registered with\n" \
"\n" \
" «conn».register_additional_standard(managed_objects = True)\n"
for key in kwargs :
if kwargs[key] :
if key == "managed_objects" :
if self._managed_objects != None :
raise asyncio.InvalidStateError \
(
"object manager interface already registered"
)
#end if
self.register \
(
path = "/",
interface = ManagedObjectsHandler(),
fallback = True
)
self._managed_objects = {}
else :
raise TypeError("unrecognized argument keyword “%s”" % key)
#end if
#end if
#end for
return \
self
#end register_additional_standard

versus

def register_additional_standard(self, **kwargs) :
"registers additional standard interfaces that are not automatically" \
" installed at Connection creation time. Currently the only one is" \
" the object-manager interface, registered with\n" \
"\n" \
" «conn».register_additional_standard(managed_objects = True)\n"
for key in kwargs :
if kwargs[key] :
if key == "managed_objects" :
if self._managed_objects != None :
raise asyncio.InvalidStateError \
(
"object manager interface already registered"
)
self.register \
(
path = "/",
interface = ManagedObjectsHandler(),
fallback = True
)
self._managed_objects = {}
else :
raise TypeError("unrecognized argument keyword “%s”" % key)
return self

I was looking for quite a tricky example I remember seeing on the
ArjanCodes channel on YouTube, but I can’t find it.