On Fri, 23 Aug 2024 09:19:06 +0200, David Brown wrote:

> On 23/08/2024 02:19, Lawrence D'Oliveiro wrote:
>
>> On Thu, 22 Aug 2024 12:47:16 +0200, David Brown wrote:
>>
>>> But it is quite happy with
>>> mixtures of tabs and spaces as long as the result after tab-to-space
>>> conversion is consistent with Python syntax.
>
> Mixtures of tabs and spaces are accepted without complaint.

I understood you to mean that different mixtures of tabs and spaces would
work, so long as they were equivalent to the same indentation under the 8-
spaces = 1 tab rule that you cited.

In fact there is no such equivalence rule. Tabs are tabs, and spaces are
spaces, and never the twain shall be interconvertible.

> (The incompatibilities between Python 2 and Python 3 are another pain in
> Python.

The fundamental problem was that Unicode was a mess in Python 2 that
needed to be cleaned up. Since they had no choice but to break backward
compatibility in that regard, they figured they would fix a few other
things while they were at it.

On 2024-08-23 10:29, Lawrence D'Oliveiro wrote:

> The fundamental problem was that Unicode was a mess in Python 2 that
> needed to be cleaned up. Since they had no choice but to break backward
> compatibility in that regard, they figured they would fix a few other
> things while they were at it.

and again in Python 4... (:-))

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

On 23/08/2024 10:29, Lawrence D'Oliveiro wrote:
> On Fri, 23 Aug 2024 09:19:06 +0200, David Brown wrote:
>
>> On 23/08/2024 02:19, Lawrence D'Oliveiro wrote:
>>
>>> On Thu, 22 Aug 2024 12:47:16 +0200, David Brown wrote:
>>>
>>>> But it is quite happy with
>>>> mixtures of tabs and spaces as long as the result after tab-to-space
>>>> conversion is consistent with Python syntax.
>>
>> Mixtures of tabs and spaces are accepted without complaint.
>
> I understood you to mean that different mixtures of tabs and spaces would
> work, so long as they were equivalent to the same indentation under the 8-
> spaces = 1 tab rule that you cited.

That is what I was thinking, but I was not very clear or accurate.

>
> In fact there is no such equivalence rule. Tabs are tabs, and spaces are
> spaces, and never the twain shall be interconvertible.

There /was/ such an equivalence rule in Python 2 - but it has been more
restrictive in Python 3. I was not aware of the extent of the
difference until recently.

>
>> (The incompatibilities between Python 2 and Python 3 are another pain in
>> Python.
>
> The fundamental problem was that Unicode was a mess in Python 2 that
> needed to be cleaned up. Since they had no choice but to break backward
> compatibility in that regard, they figured they would fix a few other
> things while they were at it.

That's one thing - arguably quite a bit thing, but only one of many
differences.

Basically, there were lots of aspects of Python that they felt could be
improved or done in better ways, but would break compatibility. Python
has always had the philosophy that major version numbers did not need
maximal compatibility - similar things happened between Python 1 and
Python 2. The difference is that Python was massively more popular by
the 2 to 3 change than it was at the 1 to 2 change, and there is still
vast amounts of Python 2 code and libraries that are not available or
easily convertible to Python 3.

On Fri, 23 Aug 2024 12:04:09 +0200, Dmitry A. Kazakov wrote:

> On 2024-08-23 10:29, Lawrence D'Oliveiro wrote:
>
>> The fundamental problem was that Unicode was a mess in Python 2 that
>> needed to be cleaned up. Since they had no choice but to break backward
>> compatibility in that regard, they figured they would fix a few other
>> things while they were at it.
>
> and again in Python 4... (:-))

Apparently some Python developers were so spooked by all the badmouthing
they received over the 2→3 transition that they have decided there will
never be a “Python 4”.

On the other hand, the deep-seated architectural changes going on with the
removal of the GIL, and their potential for subtle backward-compatibility
issues, seem to me like a good reason to say that the new versions should
start numbering with 4.0.

In comp.unix.programmer Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
> Windows did many things wrong, but accessing file descriptors by numbers
> is beyond even Windows. In Windows a file is an OS object. You access it
> getting an opaque handle to. Note that a handle can be marshaled from
> one process to another. Try that with process-local numbers!

UNIX domain sockets support the passing of file descriptors between
processes.

On 2024-08-25 09:50, Sebastian wrote:
> In comp.unix.programmer Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>> Windows did many things wrong, but accessing file descriptors by numbers
>> is beyond even Windows. In Windows a file is an OS object. You access it
>> getting an opaque handle to. Note that a handle can be marshaled from
>> one process to another. Try that with process-local numbers!
>
> UNIX domain sockets support the passing of file descriptors between
> processes.

File descriptor (a pointer to) is not file number.

You cannot pass number 1 simply because 1 is already in use.

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

On Sun, 25 Aug 2024 12:32:10 +0200, "Dmitry A. Kazakov"
<mailbox@dmitry-kazakov.de> wrote in <vaf179$1rnhl$1@dont-email.me>:

> On 2024-08-25 09:50, Sebastian wrote:
>> In comp.unix.programmer Dmitry A. Kazakov <mailbox@dmitry-kazakov.de>
>> wrote:
>>> Windows did many things wrong, but accessing file descriptors by
>>> numbers is beyond even Windows. In Windows a file is an OS object. You
>>> access it getting an opaque handle to. Note that a handle can be
>>> marshaled from one process to another. Try that with process-local
>>> numbers!
>>
>> UNIX domain sockets support the passing of file descriptors between
>> processes.
>
> File descriptor (a pointer to) is not file number.
>
> You cannot pass number 1 simply because 1 is already in use.

On this Linux system, "man 7 unix", in the section
"SCM_RIGHTS", it explains how the passing mechanism
is handled. One paragraph reads:

Commonly, this operation is referred to as "passing a
file descriptor" to another process. However, more
accurately, what is being passed is a reference to an
open file description (see open(2)), and in the re‐
ceiving process it is likely that a different file de‐
scriptor number will be used. Semantically, this op‐
eration is equivalent to duplicating (dup(2)) a file
descriptor into the file descriptor table of another
process.

--
-v

On 8/25/24 06:32, Dmitry A. Kazakov wrote:
> On 2024-08-25 09:50, Sebastian wrote:
>> In comp.unix.programmer Dmitry A. Kazakov <mailbox@dmitry-kazakov.de>
>> wrote:
>>> Windows did many things wrong, but accessing file descriptors by numbers
>>> is beyond even Windows. In Windows a file is an OS object. You access it
>>> getting an opaque handle to. Note that a handle can be marshaled from
>>> one process to another. Try that with process-local numbers!
>>
>> UNIX domain sockets support the passing of file descriptors between
>> processes.
>
> File descriptor (a pointer to) is not file number.
>
> You cannot pass number 1 simply because 1 is already in use.

True, but since passing the file descriptor provides you with all you
need to achieve the same functionality, that distinction is unimportant.

(Note: I'm not setting Followup-To since I don't know where the
participants are reading this, but do note that I'm only subscribed to
comp.unix.programmer. I will probably subscribe to .shell soon, though.)

On 2024-08-21, David Brown wrote:

> On 21/08/2024 17:37, John Ames wrote:
>> Yes, books can be wrong, and yes, community fora can have valuable
>> information - but there really is no substitute for a good manual, in
>> print or otherwise. StackOverflow is very useful for clearing up some
>> kinds of esoteric-yet-common questions, but if you just need to double-
>> check what the legal values for parameter X in function Y are, it's
>> much quicker (and usually less error-prone) to turn to a reference
>> guide than it is to go poking around looking for records of times in
>> history where someone else might've had the same question.
>>
>> (Doubly so, now that Google is as friggin' useless as it's gotten the
>> last few years.)
>>
>
> I do like a good manual, whether it be a physical book or an online
> manual. So I am not objecting to reading them, learning from them, or
> using them as references.

I'd say the online manual can be useful as a reference, at least in my
experience with Linux programming. It also has some information on
POSIX. And is local, so can be used even in the absence of a network
connection of any sort.

Do people feel differently about online manuals on other systems? Or are
these usually good to be used as a reference? (Asking out of curiosity,
as I don't have much experience yet coding on environments other than
"GNU/Linux".)

> I am just objecting to the concept that reading particular books is
> somehow "required" in order to write "useful C" or "program for
> Linux". They are neither necessary nor sufficient, especially when
> picking one or two particular books.

But once you start pointing out that there are bad books, doesn't that
also imply that people commenting on which books they found good is
useful, so that one can have an idea of which books to avoid or prefer,
even if some comments end up being subjective to some extent?

(But yes, it might well be the case that someone just can't work so well
with a book as a medium and prefers some other approach. A lot of people
these days are sharing youtube videos as "tutorials" and that's
something I can't easily "consume", so I can kind of imagine what that'd
be like. - Now if only Google had a GET parameter in the web (not video)
search for "do not provide video results. ever."...)

--
Nuno Silva

On 25/08/2024 17:32, Nuno Silva wrote:
> (Note: I'm not setting Followup-To since I don't know where the
> participants are reading this, but do note that I'm only subscribed to
> comp.unix.programmer. I will probably subscribe to .shell soon, though.)
>
>
> On 2024-08-21, David Brown wrote:
>
>> On 21/08/2024 17:37, John Ames wrote:
>>> Yes, books can be wrong, and yes, community fora can have valuable
>>> information - but there really is no substitute for a good manual, in
>>> print or otherwise. StackOverflow is very useful for clearing up some
>>> kinds of esoteric-yet-common questions, but if you just need to double-
>>> check what the legal values for parameter X in function Y are, it's
>>> much quicker (and usually less error-prone) to turn to a reference
>>> guide than it is to go poking around looking for records of times in
>>> history where someone else might've had the same question.
>>>
>>> (Doubly so, now that Google is as friggin' useless as it's gotten the
>>> last few years.)
>>>
>>
>> I do like a good manual, whether it be a physical book or an online
>> manual. So I am not objecting to reading them, learning from them, or
>> using them as references.
>
> I'd say the online manual can be useful as a reference, at least in my
> experience with Linux programming. It also has some information on
> POSIX. And is local, so can be used even in the absence of a network
> connection of any sort.
>

Reference manuals relevant to the topic are, of course, extremely
helpful to most people - whether they are physical manuals or online.
But the key point is the /relevance/. My argument is not that books or
manuals are unnecessary, merely that there are no universally required
or essential references or topics. And you certainly don't need to read
through an entire reference to have use of it.

> Do people feel differently about online manuals on other systems? Or are
> these usually good to be used as a reference? (Asking out of curiosity,
> as I don't have much experience yet coding on environments other than
> "GNU/Linux".)
>

For many programming languages or major libraries or toolkits, there are
"official" online references, manuals or documentation, and these can
often be valuable sources of information. Often they are not at all
suitable for reading through as a whole, and are no substitute for
tutorials, courses, or other learning material.

>> I am just objecting to the concept that reading particular books is
>> somehow "required" in order to write "useful C" or "program for
>> Linux". They are neither necessary nor sufficient, especially when
>> picking one or two particular books.
>
> But once you start pointing out that there are bad books, doesn't that
> also imply that people commenting on which books they found good is
> useful, so that one can have an idea of which books to avoid or prefer,
> even if some comments end up being subjective to some extent?
>

Sure. It's fine - and possibly helpful - for someone to say "I liked
this book". It's even more helpful to have some details, such as "it
was good for me because I was already an experienced programmer in
languages X, Y and Z" or "it was good for me as a complete newbie who
had to take things slowly". What is almost never helpful, is someone
claiming that you /must/ read this book or that it is somehow
objectively the "best".

> (But yes, it might well be the case that someone just can't work so well
> with a book as a medium and prefers some other approach. A lot of people
> these days are sharing youtube videos as "tutorials" and that's
> something I can't easily "consume", so I can kind of imagine what that'd
> be like. - Now if only Google had a GET parameter in the web (not video)
> search for "do not provide video results. ever."...)
>

I think videos are a better medium than books for some things and some
people, and vice versa. As I mentioned before, there are a great many
different ways to learn (and to reference details later). The "best"
choice at any given time depends on a large number of factors.

On Sun, 25 Aug 2024 16:32:04 +0100, Nuno Silva wrote:

> Do people feel differently about online manuals on other systems?

I decided about 20 years ago that, if I were going to have printed manuals
for all the material I have to know, I’d need a whole extra room in my
house just to hold it all.

Also, paper books related to computers start falling out of date from the
moment they’re published, or even before.

On Sun, 25 Aug 2024 12:32:10 +0200, Dmitry A. Kazakov wrote:

> On 2024-08-25 09:50, Sebastian wrote:
>
>> In comp.unix.programmer Dmitry A. Kazakov <mailbox@dmitry-kazakov.de>
>> wrote:
>>>
>>> Windows did many things wrong, but accessing file descriptors by
>>> numbers is beyond even Windows. In Windows a file is an OS object. You
>>> access it getting an opaque handle to. Note that a handle can be
>>> marshaled from one process to another. Try that with process-local
>>> numbers!
>>
>> UNIX domain sockets support the passing of file descriptors between
>> processes.
>
> File descriptor (a pointer to) is not file number.
>
> You cannot pass number 1 simply because 1 is already in use.

You implied above that “accessing descriptors by numbers” is somehow a bad
thing, then when it is pointed out that *nix doesn’t actually work that
way, you somehow insist that is a drawback as well.

On Sun, 25 Aug 2024 13:41:50 -0000 (UTC), vallor wrote:

> On this Linux system, "man 7 unix", in the section "SCM_RIGHTS", it
> explains how the passing mechanism is handled. One paragraph reads:
>
> Commonly, this operation is referred to as "passing a
> file descriptor" to another process. However, more
> accurately, what is being passed is a reference to an
> open file description (see open(2)), and in the re‐
> ceiving process it is likely that a different file de‐
> scriptor number will be used.

Note the distinction between “file description” (the in-kernel data
structure that stores the context about the open file), and “file
descriptor” (the userland reference to the file description).

On Thu, 22 Aug 2024 08:21:29 -0000 (UTC)
Muttley@dastardlyhq.com wrote:

> >I am a big fan of clear and consistent layout and indentation, which
> >is forced on you by Python (and Occam), but I too prefer explicit
> >blocking.
> > It's harder to get things wrong with explicit blocking, and you
> > are
>
> Indeed. You delete a bracket by mistake and it won't compile, end of.
> In Python you can delete a spaces/tabs by mistake and if its at the
> end of the block the thing could still run.
>
> >never faced with space vs. tab conflicts causing semantic changes to
> >the code.
>
> Yes, this is a royal PITA. I use tabs as in vim I can instantly
> change the indentation using "set ts=". With spaces its fixed short
> of dicking about with macros.

All of this. Are there some safeguards in place for the most egregious
cases? Yes - but literal whitespace is still a horrendous misfeature,
something the world at large has known for so long that it was already
an established joke by the time Ed Post was cracking wise about JCL in
freakin' _Datamation._

Python is far from the worst language out there - in fact, it's quite
usable for a wide variety of applications, in spite of that - but the
simple fact that Guido & co. made a boneheaded choice like that is the
reason I'll never be able to *respect* it, even when I do find myself
using it. There should - plain and simple - *never* be a time where you
can end up with unexpected semantic behavior because of settings in
your editor-of-choice.

On Mon, 26 Aug 2024 08:33:30 -0700
John Ames <commodorejohn@gmail.com> wrote:
>On Thu, 22 Aug 2024 08:21:29 -0000 (UTC)
>Muttley@dastardlyhq.com wrote:
>> Yes, this is a royal PITA. I use tabs as in vim I can instantly
>> change the indentation using "set ts=". With spaces its fixed short
>> of dicking about with macros.
>
>All of this. Are there some safeguards in place for the most egregious
>cases? Yes - but literal whitespace is still a horrendous misfeature,
>something the world at large has known for so long that it was already
>an established joke by the time Ed Post was cracking wise about JCL in
>freakin' _Datamation._
>
>Python is far from the worst language out there - in fact, it's quite
>usable for a wide variety of applications, in spite of that - but the
>simple fact that Guido & co. made a boneheaded choice like that is the
>reason I'll never be able to *respect* it, even when I do find myself
>using it. There should - plain and simple - *never* be a time where you
>can end up with unexpected semantic behavior because of settings in
>your editor-of-choice.

Literal whitespace also has a knock on effect that I'm guessing Guido didn't
consider. It prevents python being used in command line shell pipes for
anything useful unlike perl and awk.

On Mon, 26 Aug 2024 08:33:30 -0700, John Ames wrote:

> ... the simple fact that Guido & co. made a boneheaded choice like that
> is the reason I'll never be able to *respect* it, even when I do find
> myself using it.

I restore the redundancy by using “#end” comments. E.g. a seriously
nontrivial case:

def def_struct_class(name, ctname, extra = None) :
# defines a class with attributes that are a straightforward mapping
# of a ctypes struct. Optionally includes extra members from extra
# if specified.

ctstruct = getattr(CAIRO, ctname)

class result_class :

__slots__ = tuple(field[0] for field in ctstruct._fields_) # to forestall typos

def to_cairo(self) :
"returns a Cairo representation of the structure."
result = ctstruct()
for name, cttype in ctstruct._fields_ :
setattr(result, name, getattr(self, name))
#end for
return \
result
#end to_cairo

@classmethod
def from_cairo(celf, r) :
"decodes the Cairo representation of the structure."
result = celf()
for name, cttype in ctstruct._fields_ :
setattr(result, name, getattr(r, name))
#end for
return \
result
#end from_cairo

def __getitem__(self, i) :
"allows the object to be coerced to a tuple."
return \
getattr(self, ctstruct._fields_[i][0])
#end __getitem__

def __repr__(self) :
return \
(
"%s(%s)"
%
(
name,
", ".join
(
"%s = %s" % (field[0], getattr(self, field[0]))
for field in ctstruct._fields_
),
)
)
#end __repr__

#end result_class

#begin def_struct_class
result_class.__name__ = name
result_class.__doc__ = \
(
"representation of a Cairo %s structure. Fields are %s."
"\nCreate by decoding the Cairo form with the from_cairo method;"
" convert an instance to Cairo form with the to_cairo method."
%
(
ctname,
", ".join(f[0] for f in ctstruct._fields_),
)
)
if extra != None :
for attr in dir(extra) :
if not attr.startswith("__") :
setattr(result_class, attr, getattr(extra, attr))
#end if
#end for
#end if
return \
result_class
#end def_struct_class

On Mon, 26 Aug 2024 21:35:25 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

> I restore the redundancy by using “#end” comments. E.g. a seriously
> nontrivial case:

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.

(Thing I'm curious about, but don't have a test environment to hand -
does a blank line with a different indent level, in between lines of
the same level, break out of the block? E.g., given the following:

if condition:
foo()

bar()

baz()

if one needs to re-arrange the order of operations, for reasons, and
one is incautious about selecting and shuffling lines in one's editor,
such that one ends up with this:

if condition:
bar()

foo()

baz()

....what happens? Does the interpreter catch this as an "obvious"
mistake? Does foo() get called regardless of condition? Depending on
$EDITOR/settings this is visually indistinguishable and not a difficult
position to end up in.)

On 26/08/2024 22:35, Lawrence D'Oliveiro wrote:
> On Mon, 26 Aug 2024 08:33:30 -0700, John Ames wrote:
>
>> ... the simple fact that Guido & co. made a boneheaded choice like that
>> is the reason I'll never be able to *respect* it, even when I do find
>> myself using it.
>
> I restore the redundancy by using “#end” comments. E.g. a seriously
> nontrivial case:

This might the human reader but the redundancy really needs to be
supported by the language.

Here, that s2 line has been knocked out of place; the indent is missing.
But the language can't detect it, even with #end; it makes s2 unconditional:

if c:
s1
s2
#end

With language support:

if c:
s1
s2
end

Here the redundancy means the compiler knows both s1 and s2 are in the
same conditional block, and it can choose to report an indentation
inconsistency.

On 2024-08-26, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> I restore the redundancy by ...

just standing here?

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

On Mon, 26 Aug 2024 23:51:40 +0100, Bart wrote:

> This might [...] the human reader but the redundancy really needs to be
> supported by the language.

Consider what I mean by “redundancy”: it means the structure of the code
is expressed two different ways.

In a conventional language with statement bracketing symbols, the compiler
ignores the indentation, but you use that to delineate the same structure
as defined by the actual language symbols, thereby providing redundancy to
the human reader.

In Python, the compiler goes by the indentation, so I add standins for
statement bracketing symbols in the form of “#end” comments: these are
ignored by the compiler, but I use that as an alternative, redundant way
of delineating the same program structure to the human reader.

On Mon, 26 Aug 2024 15:51:13 -0700, John Ames wrote:

> if condition:
> foo()
>
> bar()
>
> baz()
>
> if one needs to re-arrange the order of operations, for reasons, and one
> is incautious about selecting and shuffling lines in one's editor, such
> that one ends up with this:
>
> if condition:
> bar()
>
> foo()
>
> baz()

Try:

if condition:
foo()
bar()
#end if
baz()

versus

if condition:
bar()
foo()
#end if
baz()

Does that make things clearer?

In comp.unix.programmer John Ames <commodorejohn@gmail.com> wrote:
> On Mon, 26 Aug 2024 21:35:25 -0000 (UTC)
> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>
>> I restore the redundancy by using ?#end? comments. E.g. a seriously
>> nontrivial case:
>
> 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.
>
> (Thing I'm curious about, but don't have a test environment to hand -
> does a blank line with a different indent level, in between lines of
> the same level, break out of the block? E.g., given the following:
>
> if condition:
> foo()
>
> bar()
>
> baz()

The answer is that it doesn't matter if the blank line between foo() and
bar() contains four spaces. bar() will always be treated as being part
of the if statement's body.

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

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

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.

Bart <bc@freeuk.com> writes:
> 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.

All I can say is that for the most part these issues just don’t arise
for me. Some are plainly aesthetic; I already addressed that. Others
sounds like issues with your tooling - changing the indentation of a
range of lines is easy in most editors, for example.

The cases that actually seem familiar:

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

You can put ‘or True’ at the end of the condition.

> (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 put an ‘if False’ at the top.

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

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