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

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

On 27/08/2024 12:26, Bart wrote:
> On 27/08/2024 09:39, Richard Kettlewell wrote:
>> John Ames <commodorejohn@gmail.com> writes:
>>> But even if that helps you organizationally, it doesn't resolve issues
>>> of the interpreter potentially mis-parsing things due to mismatches in
>>> tab/space factor between $EDITOR and the Python RTE, which is a truly
>>> ridiculous thing to have to be concerned about.
>>
>> In many years of using Python routinely and extensively I’ve simply
>> never found the whitespace issues that people are worrying about here to
>> be a problem in practice. Some of this may be a matter of experience but
>> if so, it’s a form of experience that must have built up very quickly.
>>

I have occasionally, but only occasionally, seen problems with white
space. And those would normally be caught by Python 3.

>> As an aesthetic objection, of course, there’s no accounting for
>> taste. But it doesn’t seem to be a practical problem in reality.
>>
>> (In contrast C’s rules have occasionally been a practical problem,
>> contributing to at least one high-profile software vulnerability and
>> attracting compiler warnings to mitigate the risks.)
>
> These are the problems I've seen. I haven't used the language
> extensively, but I've used it enough.

Your problems below are all valid, but not insurmountable. I too would
rather have explicit block delimiters, but it's not actually hard to
work with Python as it is.

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

That /can/ happen. It is a good idea to avoid mixing tabs and spaces in
the same file. Most editors can be configured one way or the other, but
if you use different editors under different circumstances (as I do),
mistakes are possible. They are usually quickly identified and quickly
handled.

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

Replace your

if cond :

with

if 1 :

or

if True :

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

True. But any editor will let you select the lines and indent them.

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

Comments are an extremely easy way to make the code stand out.

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

You can leave the "pass" in, if you don't want to get ride of it later.
I sometimes find "pass" to be helpful as an alternative to leaving a
hanging indented block.

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

Keep your blocks small and neat.

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

That applies to every programming language (unless you know of one that
doesn't support comments).

>
> (7) You take some Python code you've seen online (eg. in a usenet post)
> and paste into your editor. Maybe you want to merge it with your own code.
>
> But its tabbing is all spaces; yours is all tabs. Plus invariably, the
> whole thing has extra indentation (eg. the leftmost statement is already
> indented). Or you want to copy code from within a block to a different
> indent level.

Any sane editor will give you tools to fix that - automatic indentation,
tab-to-space and space-to-tab conversion, manual indent or outdent block
tools, etc.

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

No, you don't. (Unless you think "special" means "anything but Windows
Notepad" .)

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

In real-life Python coding, it works fine. I prefer explicit block
delimiters, but I cannot say Python's white-space blocking has been a
significant source of trouble or inconvenience for me. Perhaps that's
because I have always been used to careful and consistent formatting. I
don't write C code (or any other code) with inconsistent spacing, mixes
of tabs and spaces, or unexpected indentations. So for me, the spacing
and tabbing of Python code would be identical if it had braces or other
begin-end markers.

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

No one has to do that. It's a Lawrence peculiarity, and his coding
style (in Python or C, and probably anything else) would be rejected by
anyone with a coding standard. I agree that it suggests that something
is badly wrong, but it is not with the language!

On 27/08/2024 14:10, David Brown wrote:
> On 27/08/2024 12:26, Bart wrote:
>> On 27/08/2024 09:39, Richard Kettlewell wrote:
>>> John Ames <commodorejohn@gmail.com> writes:
>>>> But even if that helps you organizationally, it doesn't resolve issues
>>>> of the interpreter potentially mis-parsing things due to mismatches in
>>>> tab/space factor between $EDITOR and the Python RTE, which is a truly
>>>> ridiculous thing to have to be concerned about.
>>>
>>> In many years of using Python routinely and extensively I’ve simply
>>> never found the whitespace issues that people are worrying about here to
>>> be a problem in practice. Some of this may be a matter of experience but
>>> if so, it’s a form of experience that must have built up very quickly.
>>>
>
> I have occasionally, but only occasionally, seen problems with white
> space.  And those would normally be caught by Python 3.
>
>>> As an aesthetic objection, of course, there’s no accounting for
>>> taste. But it doesn’t seem to be a practical problem in reality.
>>>
>>> (In contrast C’s rules have occasionally been a practical problem,
>>> contributing to at least one high-profile software vulnerability and
>>> attracting compiler warnings to mitigate the risks.)
>>
>> These are the problems I've seen. I haven't used the language
>> extensively, but I've used it enough.
>
> Your problems below are all valid, but not insurmountable.  I too would
> rather have explicit block delimiters, but it's not actually hard to
> work with Python as it is.
>
>>
>> (1) An tab at the start of a line gets accidentally indented or
>> unindented. If you weren't paying close attention, it may not be clear
>> that that has happened, if this line was either the last line of an
>> indented block, or the line following
>>
>
> That /can/ happen.  It is a good idea to avoid mixing tabs and spaces in
> the same file.  Most editors can be configured one way or the other, but
> if you use different editors under different circumstances (as I do),
> mistakes are possible.  They are usually quickly identified and quickly
> handled.
>
>> (2) You want to temporarily comment out an 'if' line so that the
>> following block is unconditional. You can't do that with also
>> unindenting the block. And, also  the block then merges with the
>> following one as it's at the same level, so when you want to change it
>> back...
>
> Replace your
>
>     if cond :
>
> with
>
>     if 1 :
>
> or
>
>     if True :
>
>
>>
>> (3) Similarly, you want to temportarily wrap an 'if' statement, for
>> example, around a block of code. But you can't do it witout indenting
>> that block.
>>
>
> True.  But any editor will let you select the lines and indent them.
>
>> (4) Sometimes you want to add temporary debug code as part of a block.
>> Usually I write such lines in all-caps and without indentation to make
>> them stand out clear. With Python, I can't use all-caps and I have to
>> use exactly the same indent as the rest of the block. So the lines
>> merge. Then when I need to remove the code, it's not clearly delimited.
>
> Comments are an extremely easy way to make the code stand out.
>
>>
>> (5) Sometimes you want to temporarily comment out the contents of a
>> block. But Python doesn't allow an empty block; now you have to use
>> 'pass'. And then get rid of if later.
>
> You can leave the "pass" in, if you don't want to get ride of it later.
> I sometimes find "pass" to be helpful as an alternative to leaving a
> hanging indented block.
>
>>
>> (6) You want to add extra statements to the end of a block, but where
>> IS the end? You have to INFER the ending by looking for a line with a
>> smaller indent. But suppose you're at the bottom of a window; is that
>> bottom line the last in the block, or is there another one at the same
>> indent just out of sight? You have to tentatively keep peeking ahead!
>
> Keep your blocks small and neat.
>
>>
>> (6a) And maybe there's big comment blocking in the middle of block;
>> comments don't need nesting! If there are lots of comments and few
>> statements, finding the end of the block (ie. the last statement of
>> this block) can become quite an exercise.
>
> That applies to every programming language (unless you know of one that
> doesn't support comments).
>
>>
>> (7) You take some Python code you've seen online (eg. in a usenet
>> post) and paste into your editor. Maybe you want to merge it with your
>> own code.
>>
>> But its tabbing is all spaces; yours is all tabs. Plus invariably, the
>> whole thing has extra indentation (eg. the leftmost statement is
>> already indented). Or you want to copy code from within a block to a
>> different indent level.
>
> Any sane editor will give you tools to fix that - automatic indentation,
> tab-to-space and space-to-tab conversion, manual indent or outdent block
> tools, etc.
>
>>
>> The whole thing gets very messy and error prone. You need special
>> editor commands to deal with the mess.
>
> No, you don't.  (Unless you think "special" means "anything but Windows
> Notepad" .)
>
>>
>> Indented, non-delimited code and data is fine for machine-generated
>> and machine processed code. But it's a disaster for code that has to
>> be human-generated and human-maintained. It's just too fragile.
>>
>
> In real-life Python coding, it works fine.  I prefer explicit block
> delimiters, but I cannot say Python's white-space blocking has been a
> significant source of trouble or inconvenience for me.  Perhaps that's
> because I have always been used to careful and consistent formatting.  I
> don't write C code (or any other code) with inconsistent spacing, mixes
> of tabs and spaces, or unexpected indentations.  So for me, the spacing
> and tabbing of Python code would be identical if it had braces or other
> begin-end markers.
>
>> The fact that people have to resort to adding #end lines, which only
>> partly deals with one or two of those problems, suggest that something
>> is badly wrong.
>>
>
> No one has to do that.  It's a Lawrence peculiarity, and his coding
> style (in Python or C, and probably anything else) would be rejected by
> anyone with a coding standard.  I agree that it suggests that something
> is badly wrong, but it is not with the language!

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

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

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

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

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

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

With these changes, the porting went much more smooothly.

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

On Tue, 27 Aug 2024 15:10:08 +0200
David Brown <david.brown@hesbynett.no> wrote:

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

That's very much one for the "good advice that is not always feasible
in the Real World" file. Every project has its own natural balance of
"large things that can be easily re-factored into sets of small things"
(i.e. things you can function-ize) vs. "large things that cannot."

> > (6a) And maybe there's big comment blocking in the middle of block;
> > comments don't need nesting! If there are lots of comments and few
> > statements, finding the end of the block (ie. the last statement of
> > this block) can become quite an exercise.
>
> That applies to every programming language (unless you know of one
> that doesn't support comments).

It applies very much moreso to languages where comments *must* follow
the indentation level of the surrounding code, so that the deeper you
go, the more lines you have to split comments across.

On Tue, 27 Aug 2024 08:03:20 -0700
John Ames <commodorejohn@gmail.com> wrote:
>It applies very much moreso to languages where comments *must* follow
>the indentation level of the surrounding code, so that the deeper you
>go, the more lines you have to split comments across.

Unless you're one of those developers for whom breaking up lines is a foreign
concept and you just continue on a single line until you're done no matter
how long it is.

On 27/08/2024 17:03, John Ames wrote:
> On Tue, 27 Aug 2024 15:10:08 +0200
> David Brown <david.brown@hesbynett.no> wrote:
>
>>> (6) You want to add extra statements to the end of a block, but
>>> where IS the end? You have to INFER the ending by looking for a
>>> line with a smaller indent. But suppose you're at the bottom of a
>>> window; is that bottom line the last in the block, or is there
>>> another one at the same indent just out of sight? You have to
>>> tentatively keep peeking ahead!
>>
>> Keep your blocks small and neat.
>
> That's very much one for the "good advice that is not always feasible
> in the Real World" file. Every project has its own natural balance of
> "large things that can be easily re-factored into sets of small things"
> (i.e. things you can function-ize) vs. "large things that cannot."
>

Sure. But if you keep such advice at hand, then it is often easier to
make it feasible. Occasionally code is best formatted with a big
function or two, but most of the time it is possible and preferable to
have relatively small function.

>>> (6a) And maybe there's big comment blocking in the middle of block;
>>> comments don't need nesting! If there are lots of comments and few
>>> statements, finding the end of the block (ie. the last statement of
>>> this block) can become quite an exercise.
>>
>> That applies to every programming language (unless you know of one
>> that doesn't support comments).
>
> It applies very much moreso to languages where comments *must* follow
> the indentation level of the surrounding code, so that the deeper you
> go, the more lines you have to split comments across.
>

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

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.

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

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

Again, “#end” comments help with this.

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

Like I said, Emacs makes this easy. Also a quick application of “untabify”
will turn all tabs in the selected region to spaces, to match with the
rest of my code.