On 28/08/2024 23:49, Lawrence D'Oliveiro wrote:
> 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.

The aim is to not NEED refactoring when you are playing around with
different, short-term bits of code.

Requiring letter-case that is exactly right plus indentation that is
exactly right, plus requiring you to choose between spaces and tabs
(plus requiring endless 'imports' to added for standard language
features), is just a nuisance.

On 2024-08-28, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> Bart <bc@freeuk.com> writes:
>> On 28/08/2024 19:48, David Brown wrote:
>> 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.

In a language with brackets or braces, the indentation can adjust itself
for you.

The proof of concept for this is the "parinfer" algorithm, for Lisp
languages. Someone came up with this a bunch of years ago and now
it's fairly widely implemented.

Parinfer creates a real-time link between indentation and parentheses.

It can be configured to infer one from the other: you can manually
control indentation and have parentheses magically appear and disappear
as needed, or you can control parentheses and have the code indent
itself.

Likely, a much more complicated version of the algorithm could work
for "C likes" and others. Maybe someone has done it by now? No idea.

There are some animated demos on the original home page, and maybe
elsewhere:

https://shaunlebron.github.io/parinfer/

I use a somewhat poor but usable Vim implementation of this.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> 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"

That's not the conventional way to format a docstring. If you're using
backslashes to splice lines in Python, it's likely you're doing
something wrong.

> for key in kwargs :
> if kwargs[key] :
> if key == "managed_objects" :
> if self._managed_objects != None :

I think "is not None" is more idiomatic.

> raise asyncio.InvalidStateError \
> (
> "object manager interface already registered"
> )

You don't need the \ if you put the ( on the same line.

> #end if
> self.register \
> (
> path = "/",
> interface = ManagedObjectsHandler(),
> fallback = True
> )

Again, you've decided how you want to place parentheses and you're
forcing the syntax to cater to that. I might write that as:

self.register(
path = "/",
interface = ManagedObjectsHandler(),
fallback = True
)

> self._managed_objects = {}
> else :

You leave a space between "else" and ":". It's not wrong, but it's not
something I've ever seen. It's likely to be just a little jarring to
readers.

> raise TypeError("unrecognized argument keyword “%s”" % key)

Do you have a requirement to use older versions of Python that don't
support f-strings?

> #end if
> #end if
> #end for
> return \
> self

Why not just "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

Again, the #end comments don't make it any more readable *for me*.
I suspect that would be even more true for more experienced Python
programmers.

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

In any language, if a block of code is so deeply indented that it's
confusing, you should consider refactoring it. (Though that's not
always the answer.)

I once reviewed some C code with misleading indentation. Depending on
the viewer's tab settings (4 vs 8 columns) it looked either like this:

if (condition)
this;
that;

or like this:

if (condition)
this;
that;

Of course it meant the same to the compiler.

In any language, I think it's important to use consistent indentation
that reflects the structure of the code, and to avoid mixing tabs and
spaces. (My personal preference is to use spaces exclusively, but I'll
conform to what existing code does.) As I've said elsethread, Python's
rules just force me 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 Thu, 29 Aug 2024 00:21:43 +0100, Bart wrote:

> On 28/08/2024 23:49, Lawrence D'Oliveiro wrote:
>
>> 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.
>
> The aim is to not NEED refactoring when you are playing around with
> different, short-term bits of code.

“Playing around” is exactly one of those situations where you will need to
do all kinds of things to the code, including refactoring.

On Wed, 28 Aug 2024 17:23:25 -0700, Keith Thompson wrote:

> That's not the conventional way to format a docstring. If you're using
> backslashes to splice lines in Python, it's likely you're doing
> something wrong.

What exactly is wrong?

> I think "is not None" is more idiomatic.

When I want an equality comparison, I use “==”, not “is”.

> You don't need the \ if you put the ( on the same line.

But I do otherwise.

> You leave a space between "else" and ":". It's not wrong, but it's not
> something I've ever seen.

People who look at my code tend to get triggered by the little things;
maybe it’s a way to avoid thinking about the big things?

> In any language, if a block of code is so deeply indented that it's
> confusing, you should consider refactoring it. (Though that's not
> always the answer.)

The point being, the same kind of code in a language with explicit
statement brackets would reach the point of confusion later, rather than
sooner.

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> On Wed, 28 Aug 2024 17:23:25 -0700, Keith Thompson wrote:
>
>> That's not the conventional way to format a docstring. If you're using
>> backslashes to splice lines in Python, it's likely you're doing
>> something wrong.
>
> What exactly is wrong?

Perhaps "wrong" overstates it, but your code certainly doesn't follow
common Python conventions.

https://peps.python.org/pep-0257/

>> I think "is not None" is more idiomatic.
>
> When I want an equality comparison, I use “==”, not “is”.
>
>> You don't need the \ if you put the ( on the same line.
>
> But I do otherwise.

So I see. I don't know why -- and I'm ok with that.

>> You leave a space between "else" and ":". It's not wrong, but it's not
>> something I've ever seen.
>
> People who look at my code tend to get triggered by the little things;
> maybe it’s a way to avoid thinking about the big things?

Why would I want to avoid thinking about the big things?

One of Henry Spencer's Ten Commandments for C Programmers seems relevant
(indirectly, of course):

Thou shalt make thy program's purpose and structure clear to thy
fellow man by using the One True Brace Style, even if thou likest it
not, for thy creativity is better used in solving problems than in
creating beautiful new impediments to understanding.

https://www.lysator.liu.se/c/ten-commandments.html

My impression is that your unconventional style indicates a relative
lack of experience in Python. Maybe that's an invalid conclusion, but
it's one that others are likely to reach as well.

And if you want to discuss Python, I suggest that comp.lang.python would
be a better place to do so. I see that you already post there. (And
you seem to have a problem with the gateway to the python-list mailing
list, for reasons you have declined to explain.) I follow that
newsgroup, and I'm going to bow out of this thread here.

>> In any language, if a block of code is so deeply indented that it's
>> confusing, you should consider refactoring it. (Though that's not
>> always the answer.)
>
> The point being, the same kind of code in a language with explicit
> statement brackets would reach the point of confusion later, rather than
> sooner.

I'm not convinced of that.

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

On Wed, 28 Aug 2024 20:48:08 +0200
David Brown <david.brown@hesbynett.no> wrote:
>On 28/08/2024 19:43, Muttley@dastardlyhq.com wrote:
>> 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.

Don't be a patronising prick, it doesn't help your argument. Personally I
have better things to do that figure out some obscure functionality of vim
to achieve something I shouldn't have to do in the first place if the
language was designed properly. Thankfully I don't have to use Python much.

On 29/08/2024 02:16, Lawrence D'Oliveiro wrote:
> On Thu, 29 Aug 2024 00:21:43 +0100, Bart wrote:
>
>> On 28/08/2024 23:49, Lawrence D'Oliveiro wrote:
>>
>>> 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.
>>
>> The aim is to not NEED refactoring when you are playing around with
>> different, short-term bits of code.
>
> “Playing around” is exactly one of those situations where you will need to
> do all kinds of things to the code, including refactoring.

Here:

if a == b:
s1
return
s2
s3

that return statement is added temporarily for some reason that is not
relevant to the discussion.

Real life code would have much busier statements, and the whole thing
would in the middle of lots of other stuff that can include actual
return statements.

The problem is that that line doesn't stand out, when later you have to
find it to remove it or comment it. It blends into the surrounding code.

Without the constraints imposed by the language, I could just write it as:

if a == b:
s1
RETURN
s2
s3

NOW it stands out! Of course, I could just do:

if a == b:
s1
return # TEMPORARY RETURN
s2
s3

But this is extra effort that shouldn't be necessary, like adding #end
comments. I might for example move that line to a different part of the
function, but it might use a different indent level.

On 2024-08-29 12:49, Bart wrote:

> Without the constraints imposed by the language, I could just write it as:
>
>     if a == b:
>         s1
> RETURN
>         s2
>         s3
>
> NOW it stands out!

In Ada I use indentation for the purpose:

if A = B then -- This I will remove later
s1;
end if;
s2;
s3;

I remember FORTRAN in its glory days had D-comments. In the first column
the letter D meant a conditional, compiled in the debug mode, ignored
otherwise.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

On 29/08/2024 02:23, Keith Thompson wrote:
> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>> 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.

So why not try to write /all/ your code in a well-structured manner, so
that you don't feel the need to add these "#end" comments?

>>
>> 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"
>
> That's not the conventional way to format a docstring. If you're using
> backslashes to splice lines in Python, it's likely you're doing
> something wrong.

Agreed 100%.

>
>> for key in kwargs :
>> if kwargs[key] :
>> if key == "managed_objects" :
>> if self._managed_objects != None :
>
> I think "is not None" is more idiomatic.

I don't know if that is true or not that it is more idiomatic - I would
certainly be happy with either.

def register_additional_standard(self, managed_objects) :
"""
registers additional standard interfaces that are not automatically
installed at Connection creation time. Currently the only one is
the object-manager interface, registered with

«conn».register_additional_standard(managed_objects = True)
"""

if 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 = {}
return self

(Usenet formatting is limited to 72 characters standard - modern
programming is not. Overly long lines are not good, but a hard limit
at, say, 80 characters is a bad idea.)

>
>> raise asyncio.InvalidStateError \
>> (
>> "object manager interface already registered"
>> )
>
> You don't need the \ if you put the ( on the same line.

Line continuation characters in Python are usually an indicator of poor
formatting, or an unhealthy obsession with line length limits.

>
>> #end if
>> self.register \
>> (
>> path = "/",
>> interface = ManagedObjectsHandler(),
>> fallback = True
>> )
>
> Again, you've decided how you want to place parentheses and you're
> forcing the syntax to cater to that. I might write that as:
>
> self.register(
> path = "/",
> interface = ManagedObjectsHandler(),
> fallback = True
> )
>
>> self._managed_objects = {}
>> else :
>
> You leave a space between "else" and ":". It's not wrong, but it's not
> something I've ever seen. It's likely to be just a little jarring to
> readers.

I personally prefer a space before the colon in Python. It is probably
less common than no space, but it is certainly not a rare habit.

>
>> raise TypeError("unrecognized argument keyword “%s”" % key)
>
> Do you have a requirement to use older versions of Python that don't
> support f-strings?
>
>> #end if
>> #end if
>> #end for
>> return \
>> self
>
> Why not just "return self"?

Indeed.

>
>> #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
>
> Again, the #end comments don't make it any more readable *for me*.
> I suspect that would be even more true for more experienced Python
> programmers.

I don't know if I am more experienced than you in Python (I may have
been using Python for longer, but you may have worked with it more), but
I would say that the "#end" comments directly detract from readability.

>
>> I was looking for quite a tricky example I remember seeing on the
>> ArjanCodes channel on YouTube, but I can’t find it.
>
> In any language, if a block of code is so deeply indented that it's
> confusing, you should consider refactoring it. (Though that's not
> always the answer.)

Agreed.

>
> I once reviewed some C code with misleading indentation. Depending on
> the viewer's tab settings (4 vs 8 columns) it looked either like this:
>
> if (condition)
> this;
> that;
>
> or like this:
>
> if (condition)
> this;
> that;
>
> Of course it meant the same to the compiler.

As someone who works with C programming that is often high-reliability
(not necessarily safety critical, but updates after production can be
very expensive), both are unacceptable in the kind of coding standards
we use. I accept single-line "if" statements without braces if they are
simple enough, otherwise braces are required.

if (condition) return;

if (condition) {
return;
} else {
break;
}

If the "true" statement is on a separate line, braces are /always/
required for my type of code. Almost any indentation is done inside a
pair of braces - it keeps everything simple and consistent, and it's
easy to spot mistakes.

>
> In any language, I think it's important to use consistent indentation
> that reflects the structure of the code, and to avoid mixing tabs and
> spaces. (My personal preference is to use spaces exclusively, but I'll
> conform to what existing code does.) As I've said elsethread, Python's
> rules just force me to do what I would have done anyway.
>

I do the same. (Well, I use tabs more than spaces, but otherwise I do
the same.)

On 29/08/2024 03:19, Lawrence D'Oliveiro wrote:
> On Wed, 28 Aug 2024 17:23:25 -0700, Keith Thompson wrote:
>
>> That's not the conventional way to format a docstring. If you're using
>> backslashes to splice lines in Python, it's likely you're doing
>> something wrong.
>
> What exactly is wrong?
>
>> I think "is not None" is more idiomatic.
>
> When I want an equality comparison, I use “==”, not “is”.
>
>> You don't need the \ if you put the ( on the same line.
>
> But I do otherwise.
>
>> You leave a space between "else" and ":". It's not wrong, but it's not
>> something I've ever seen.
>
> People who look at my code tend to get triggered by the little things;
> maybe it’s a way to avoid thinking about the big things?

"""
There are two ways of constructing a software design: One way is to make
it so simple that there are obviously no deficiencies, and the other way
is to make it so complicated that there are no obvious deficiencies. The
first method is far more difficult.
"""

You are clearly aiming for the second method here - put in so much extra
crap and silliness that readers get caught up in that instead of
noticing that most of the function is meaningless.

On 28/08/2024 21:27, Bart wrote:
> 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.

If I am adding or removing blocks (such as surrounding existing code in
a new conditional), then I /have/ to change the indentation - in /any/
language. (I use indents in my assembly programming too.) Call it OCD
or compulsive behaviour if you like, but I cannot consider code to be
finished - even to the level of a quick compile or test - if the
indentation is not correct.

I simply cannot see the problem with Python here, because I would not
indent things in any other way in any language.

The only thing I see as annoying in Python is when you have two or three
indentations left hanging :

def foo(a, b, c) :
if a :
if b :
if c :
doThis()

That looks unfinished to me. So I will add a "return" at the end (with
a single tab indent, in this case). If it is not the end of the
function, I will sometimes use a "pass" to pull back the indent level.

> A lesser one
> is having to rely on whatever varied features that 100s of different
> editors may have to do so.

I also rely on editors being able to accept keypresses, to load and save
files, and to have features like "search".

Of course, being a sane software developer, I do most of my programming
using editors that are suitable for software development. Most
professional carpenters use hammers for their nails, rather than bashing
them in with stones - it's the same thing, really.

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

So mark the boundary. Add a blank line. Put a comment line describing
the steps of the function. You are making up problems for which you
already have good solutions that you would be using in any programming
language.

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

Having made your own language(s) gives you no more and no less right to
comment about features of other languages that you like or dislike.

Your problem here is that you are obsessed with finding things that you
want to see as misfeatures, design flaws, or problems in other languages
- and then obsess about how you can find new ways to make it more
difficult to "work around" them.

Don't you ever just accept that a language is the way it is, and it is
perfectly useable that way? Or think that perhaps other people in the
world know better than you do about how they want their language to
work? Has it never occurred to you that the people behind a given
language - such as Python - considered various alternatives and decided
that making it the way they did was the best choice overall for the
language they wanted?

As Bjarne Stustroup said, there are two kinds of programming languages -
those that people complain about, and those that no one uses.

On 29/08/2024 09:28, Muttley@dastardlyhq.com wrote:
> On Wed, 28 Aug 2024 20:48:08 +0200
> David Brown <david.brown@hesbynett.no> wrote:
>> On 28/08/2024 19:43, Muttley@dastardlyhq.com wrote:
>>> 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.
>
> Don't be a patronising prick, it doesn't help your argument. Personally I
> have better things to do that figure out some obscure functionality of vim
> to achieve something I shouldn't have to do in the first place if the
> language was designed properly. Thankfully I don't have to use Python much.
>

Then don't use vim - use an editor that suits your needs.

If you are trying to claim that you do software development, and that
the editor(s) you use regularly do not have easily available functions
for indenting and un-indenting sections of code, then you are either
lying, or you /are/ an aforementioned special kind of genius.

Presumably you are /not/ trying to claim that - you are just trolling.

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On 2024-08-29 12:49, Bart wrote:
>
>> Without the constraints imposed by the language, I could just write it as:
>>     if a == b:
>>         s1
>> RETURN
>>         s2
>>         s3
>> NOW it stands out!
>
> In Ada I use indentation for the purpose:
>
> if A = B then -- This I will remove later
> s1;
> end if;
> s2;
> s3;
>
> I remember FORTRAN in its glory days had D-comments. In the first column
> the letter D meant a conditional, compiled in the debug mode, ignored
> otherwise.

That was a non-standard extension, so it was not really part of FORTRAN
but just some FORTRAN implementations. (The ones I have used didn't
have that, for example.)

--
Ben.

On Thu, 29 Aug 2024 14:24:01 +0200
David Brown <david.brown@hesbynett.no> wrote:

> Don't you ever just accept that a language is the way it is, and it
> is perfectly useable that way? Or think that perhaps other people in
> the world know better than you do about how they want their language
> to work? Has it never occurred to you that the people behind a given
> language - such as Python - considered various alternatives and
> decided that making it the way they did was the best choice overall
> for the language they wanted?

They probably did - but did they do that *because* of the point in
question, in spite of it, or without any meaningful inclination toward
or against it? There are plenty of other aspects about Python that may
tip the balance in spite of its annoyances.

F'rinstance, the *very* comprehensive set of libraries make bashing out
quick utilities to do A Complex Thing often very simple. (That was the
reason I first used it - needed a quick-'n-easy way to programmatically
deliver data in a POST request from a Windows box in production, and it
beat the hell out of trying to wrap my head around Win32 network
programming.) But if the language "wins" on that score, that doesn't
mean its annoyances or flaws are any less real or worthy of complaint.

Like, obviously it's way too late in the game for Python to change this
now. But we can still say it's stupid for them to have done it that way
in the first place. Is that a matter of opinion? Sure, but that's never
stopped anybody from expressing themselves re: any other language. (How
many people are still bitching about C being "insecure," 50+ years down
the line?)

On Thu, 29 Aug 2024 14:30:27 +0200
David Brown <david.brown@hesbynett.no> wrote:
>Presumably you are /not/ trying to claim that - you are just trolling.

Ah ok, you're the type who thinks anyone who disagrees with you is a troll.
You're not worth the effort mate.

On 29.08.2024 14:30, David Brown wrote:
> On 29/08/2024 09:28, Muttley@dastardlyhq.com wrote:
>> [...]
>
> Then don't use vim - use an editor that suits your needs.

LOL. (You appear to be joking. - If not, continue reading...)

But what makes you think that his needs are not covered by Vim?

>
> If you are trying to claim that you do software development, and that
> the editor(s) you use regularly do not have easily available functions
> for indenting and un-indenting sections of code, then you are either
> lying, or you /are/ an aforementioned special kind of genius.

Vim is an editor that has the most simple and also very powerful
indenting for well structured data and programs I've yet seen.
(Not mentioning its equally powerful other editing facilities.)

And even badly designed languages can be indented in the same
ways that other editors (more primitive ones or Emacs) provide.
Not as efficient as with previously mentioned cleanly designed
data or languages, but as efficient as all these other editors.

Why should he use any editor that is - in the general case, for
editing all sorts of data - mostly much less efficient than Vim?
(From the handful of popular editors I don't see any candidate.)

But this is not an untypical reflex on the Internet; ignoring
factual design issues, questioning the used tools instead, and
giving folks with different experiences and preferences names.

Janis

On 29/08/2024 17:52, John Ames wrote:
> On Thu, 29 Aug 2024 14:24:01 +0200
> David Brown <david.brown@hesbynett.no> wrote:
>
>> Don't you ever just accept that a language is the way it is, and it
>> is perfectly useable that way? Or think that perhaps other people in
>> the world know better than you do about how they want their language
>> to work? Has it never occurred to you that the people behind a given
>> language - such as Python - considered various alternatives and
>> decided that making it the way they did was the best choice overall
>> for the language they wanted?
>
> They probably did - but did they do that *because* of the point in
> question, in spite of it, or without any meaningful inclination toward
> or against it? There are plenty of other aspects about Python that may
> tip the balance in spite of its annoyances.
>

I don't know the early history of Python, so I can't answer that. But
there can be no doubt that the BDFL and other "founding fathers" of the
language were aware of the pros and cons of making white space
significant for block structuring in the language, and that they
actively decided to make its syntax the way it is as the best balance,
in their opinions, for the expected use of the language. However, it is
also likely that they did not predict where the language would be, and
how it would be used, decades later. Maybe if they had had a crystal
ball they would have designed things differently - maybe not.

/All/ languages, except perhaps Bart's private language that is only
used by him, have their annoyances. I have worked at least a little
with a fair number of languages, and I've never seen one that I thought
was "perfect". But different people have different things that the like
and dislike about any given language.

So if you have the choice of which language to use (many programmers do
not), you pick one that has more things you like for the task in
question in comparison to the things you don't like.

> F'rinstance, the *very* comprehensive set of libraries make bashing out
> quick utilities to do A Complex Thing often very simple. (That was the
> reason I first used it - needed a quick-'n-easy way to programmatically
> deliver data in a POST request from a Windows box in production, and it
> beat the hell out of trying to wrap my head around Win32 network
> programming.) But if the language "wins" on that score, that doesn't
> mean its annoyances or flaws are any less real or worthy of complaint.
>
> Like, obviously it's way too late in the game for Python to change this
> now. But we can still say it's stupid for them to have done it that way
> in the first place. Is that a matter of opinion? Sure, but that's never
> stopped anybody from expressing themselves re: any other language. (How
> many people are still bitching about C being "insecure," 50+ years down
> the line?)
>

You are welcome to your opinions on languages - I have plenty of my own
(and I prefer explicit block delimiters - I would even go further in
languages like C and insist on them in more situations). But it's
important to understand that these are opinions - the designers of
Python were /not/ stupid to have made the language that way. They just
had different opinions from you, and the had a much better basis for
forming those opinions than you or I.

On 29/08/2024 18:19, Muttley@dastardlyhq.com wrote:
> On Thu, 29 Aug 2024 14:30:27 +0200
> David Brown <david.brown@hesbynett.no> wrote:
>> Presumably you are /not/ trying to claim that - you are just trolling.
>
> Ah ok, you're the type who thinks anyone who disagrees with you is a troll.

No, I was talking about /you/. I don't know of anyone here with whom I
don't disagree at times, and most of the rest are not trolling.

> You're not worth the effort mate.
>

Feel free to ignore my posts.

On 29/08/2024 18:44, Janis Papanagnou wrote:
> On 29.08.2024 14:30, David Brown wrote:
>> On 29/08/2024 09:28, Muttley@dastardlyhq.com wrote:
>>> [...]
>>
>> Then don't use vim - use an editor that suits your needs.
>
> LOL. (You appear to be joking. - If not, continue reading...)
>

I was not joking.

> But what makes you think that his needs are not covered by Vim?

You seem to have missed the point - sorry if I was not clear.

He complained that he didn't want to learn complicated macros in Vim
just to be able to indent or un-indent lines of code. The solution is
obvious - he should use an editor other than Vim.

He could, of course, learn how to use Vim. It's a perfectly good editor
with a lot of features. It's never been my cup of tea, and nor has
Emacs - but that's preference and habit, and says nothing about whether
or not it is a good editor or useful for other people.

There are more than enough decent editors to choose from, that cover the
basic needs of programmers. Some people use one editor for everything,
others use a range for different purposes - whatever suits you. But it
is pretty absurd to complain that it is difficult to indent code just
because you (i.e., Muttley) think it is hard to do in one particular editor.

On Thu, 29 Aug 2024 14:24:01 +0200, David Brown wrote:

> def foo(a, b, c) :
> if a :
> if b :
> if c :
> doThis()
>
> That looks unfinished to me. So I will add a "return" at the end (with
> a single tab indent, in this case).

A redundant “return” ... kind of like my redundant “#end” comments, except
yours work in a more restricted set of places ...

> Don't you ever just accept that a language is the way it is, and it is
> perfectly useable that way?

Of course not.

> Or think that perhaps other people in the world know better than you do
> about how they want their language to work?

And vice versa.

> Has it never occurred to you that the people behind a given
> language - such as Python - considered various alternatives and decided
> that making it the way they did was the best choice overall for the
> language they wanted?

Barring a few obvious stupidities, yes of course they were, and are, smart
people.

On Thu, 29 Aug 2024 14:01:05 +0200, David Brown wrote:

> On 29/08/2024 02:23, Keith Thompson wrote:
>>
>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>>
>>> 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.
>
> So why not try to write /all/ your code in a well-structured manner, so
> that you don't feel the need to add these "#end" comments?

Because not all examples can be made that neat, as I demonstrated.

> def register_additional_standard(self, managed_objects) :
> """
> registers additional standard interfaces that are not
> automatically installed at Connection creation time. Currently
> the only one is the object-manager interface, registered with
>
> «conn».register_additional_standard(managed_objects = True)
> """

Note that Python’s indentation rules don’t apply to multiline string
literals -- don’t you wish they did? So you end up with all that extra
space within the literal. Do you see why I prefer to avoid that?

> Line continuation characters in Python are usually an indicator of poor
> formatting, or an unhealthy obsession with line length limits.

I like to keep within a line length limit of about 100 characters.

> I don't know if I am more experienced than you in Python (I may have
> been using Python for longer, but you may have worked with it more), but
> I would say that the "#end" comments directly detract from readability.

Think about why you bother to indent code in languages where the compiler
ignores such indentation anyway: it means you are expressing the structure
of code in two different ways, one via statement brackets, and the other
via indentation. This redundancy aids in understanding that the code does
what you think it does.

Python gets rid of this redundancy, by having the compiler take notice of
the whitespace and removing the statement bracketing symbols. So I put it
back, by adding statement bracketing symbols that the compiler ignores.

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
[...]
> Think about why you bother to indent code in languages where the compiler
> ignores such indentation anyway: it means you are expressing the structure
> of code in two different ways, one via statement brackets, and the other
> via indentation. This redundancy aids in understanding that the code does
> what you think it does.
>
> Python gets rid of this redundancy, by having the compiler take notice of
> the whitespace and removing the statement bracketing symbols. So I put it
> back, by adding statement bracketing symbols that the compiler ignores.

You might find Bython useful.

https://github.com/mathialo/bython

(I don't, but you might.)

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

On Thu, 29 Aug 2024 18:44:35 +0200, Janis Papanagnou wrote:

> Vim is an editor that has the most simple and also very powerful
> indenting for well structured data and programs I've yet seen. (Not
> mentioning its equally powerful other editing facilities.)

Vim is only good for text-editing, though. It assumes a file is split into
lines. Emacs makes no such assumption, and can also edit non-text files.

On Thu, 29 Aug 2024 16:57:21 -0700, Keith Thompson wrote:

> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> [...]
>> Think about why you bother to indent code in languages where the
>> compiler ignores such indentation anyway: it means you are expressing
>> the structure of code in two different ways, one via statement
>> brackets, and the other via indentation. This redundancy aids in
>> understanding that the code does what you think it does.
>>
>> Python gets rid of this redundancy, by having the compiler take notice
>> of the whitespace and removing the statement bracketing symbols. So I
>> put it back, by adding statement bracketing symbols that the compiler
>> ignores.

Another reason for “#end” comments is they give me something to jump to in
the editor.

I have Emacs commands defined to move quickly between lines with matching
indentation. Since I have these at the beginning and end of every compound
construct, that allows me easy navigation around my code.