On Tue, 20 Aug 2024 20:56:00 -0000 (UTC)
kalevi@kolttonen.fi (Kalevi Kolttonen) boringly babbled:
>In comp.unix.programmer David Brown <david.brown@hesbynett.no> wrote:
>> No, you do not need your particular favourite out of the thousand and
>> one Linux programming books in order to program for Linux. You do not
>> need /any/ book in order to write useful and successful code for Linux.
>> Of course you need /some/ reference - and in the days before the
>> internet was so easily available and so full of information, I went
>> through a lot of programming books. Some were good, some less so, and
>> some have become famous. But none of them were /necessary/ in any way.
>
>Well, I am a quite bad programmer but I am interested enough in the
>Linux/UNIX workings so that reading the newest APUE and The Linux
>Programming Interface did not feel painful or unnecessary at all. On
>the contrary, it was a great pleasure to examine what kind of
>programming facilities my favourite OS offers.
>
>Having these two books, or just one of them, is a great way to educate
>oneself about Linux/UNIX. I see that The Linux Programming Interface
>is available online as a free PDF, but I am not sure whether it is
>a pirated version.
>
>There is no better way to learn Linux/UNIX workings than these two
>books. Period.

The advantage of books written by professionals is that the code and
explanations are usually much clearer and of better equality than the quickly
knocked up might-work-might-not crap you often find on stack overflow and
similar sites. Thats not to say good example code isn't out there but wading
through the rubbish can be a tedious business and IME its often quicker just
to reach for APUE or similar.

On Wed, 21 Aug 2024 09:26:41 +0200
David Brown <david.brown@hesbynett.no> boringly babbled:
>So I don't question that it is interesting, informative, or a pleasure
>to read. I question that it is /necessary/. You simply cannot argue
>that people who want to program for Linux /must/ read that book. There
>is no justification for that claim. There is no justification for
>claiming that people wanting to program for Linux need to read any books
>on the topic at all, nor for claims that people need to "know POSIX" to
>be able to write code for Linux and/or in C.

Only knowing core C will severely limit what you can do on any OS. If
you're happy just coding up file processors or some self contained
mathematical algo and simply writing to stdout or a file then fine, but to do
anything more sophisticated you'll need to know the OS API whether its posix
+ X on *nix or Win32 on Windows.

>There are a thousand and one ways to learn about the workings of Linux -
>and that's counting "reading books" as one way, regardless of /which/

Linear learning is usually better than snippets from google. If you want
to learn a shakespear play you read the book, you don't google little bits
of it at a time.

On Wed, 21 Aug 2024 09:26:41 +0200, David Brown wrote:

> And you don't need to know anything about Linux, UNIX or POSIX to
> program in C.

I think the point has been made on comp.lang.c more than once, that C
without POSIX can be a very dull language indeed ...

On 2024-08-21 02:59, Lawrence D'Oliveiro wrote:
> On Tue, 20 Aug 2024 10:27:01 +0200, Dmitry A. Kazakov wrote:
>
>> The question is sustainability in long term.
>
> In the long term, proprietary software is in retreat, while Free software
> is on the rise. So it’s quite clear which one is more “sustainable”.

I mean economic sustainability. Normally you cannot sustain a whole
branch of economy keeping it black.

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

In comp.unix.programmer Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> On Tue, 20 Aug 2024 14:21:38 -0000 (UTC), Kalevi Kolttonen wrote:
>
>> Even though his PhD thesis was
>> something like 100-150 pages of strange-looking formulas, he said he had
>> problems with C on the Amiga. For some reason, he was unable to remember
>> what functions where provided as standard libraries, so he always ended
>> up writing his own functions instead of using libraries.
>
> Was he not able to keep some reference docs handy? For example, I rarely
> get very far in working on Python code without having this page
> <https://docs.python.org/3/library/> open in a browser.

Sorry, I don't know. I only know that he told me he was
unable to remember what the standard libraries on Amiga
offered. So he did much unnecessary duplication of code
writing the functions himself.

I have never owned Commodore Amiga and I have no
knowledge about its C compilers or the related
documentation.

br,
KK

On 21/08/2024 09:36, Muttley@dastardlyhq.com wrote:
> On Wed, 21 Aug 2024 09:26:41 +0200
> David Brown <david.brown@hesbynett.no> boringly babbled:
>> So I don't question that it is interesting, informative, or a pleasure
>> to read. I question that it is /necessary/. You simply cannot argue
>> that people who want to program for Linux /must/ read that book. There
>> is no justification for that claim. There is no justification for
>> claiming that people wanting to program for Linux need to read any books
>> on the topic at all, nor for claims that people need to "know POSIX" to
>> be able to write code for Linux and/or in C.
>
> Only knowing core C will severely limit what you can do on any OS. If
> you're happy just coding up file processors or some self contained
> mathematical algo and simply writing to stdout or a file then fine, but to do
> anything more sophisticated you'll need to know the OS API whether its posix
> + X on *nix or Win32 on Windows.

No, you do not.

Why is this so difficult for some people to understand? You need to
know about the parts relevant to the things you are doing. Modern OS's
are /huge/. It is meaningless to talk about "knowing the OS API",
because before you have learned 10% of it, major new versions will be
available and at least part of your knowledge may be outdated. By the
time you have learned /all/ of it, several versions have passed and
you've been fired from your job for pissing around for years learning
things that have no relevance to your task, and you've probably
forgotten at least half of it. And then you can start learning the
third-party libraries and APIs that are not part of the OS but useful
for the task.

If you are writing network software for Linux, how is it relevant to
learn about the sound API, or the more advanced filesystem API's ? If
you are writing a gui program with QT, why should you be interested in X
APIs or POSIX threading and file handling - you'll be using the QT
libraries and APIs for graphics, threading and file handling.

I have not suggested, or even hinted, that all you need is "core C" -
what you need is the knowledge that is relevant to the task at hand,
regardless of the OS, language, or whatever.

>
>> There are a thousand and one ways to learn about the workings of Linux -
>> and that's counting "reading books" as one way, regardless of /which/
>
> Linear learning is usually better than snippets from google. If you want
> to learn a shakespear play you read the book, you don't google little bits
> of it at a time.
>

When did I suggest that snippets from google was "the" way to learn?

I'd agree that reading a book or two is likely to be better than reading
nothing but "snippets from google". You now have another 999 strawmen
to go through.

On 21/08/2024 09:38, Lawrence D'Oliveiro wrote:
> On Wed, 21 Aug 2024 09:26:41 +0200, David Brown wrote:
>
>> And you don't need to know anything about Linux, UNIX or POSIX to
>> program in C.
>
> I think the point has been made on comp.lang.c more than once, that C
> without POSIX can be a very dull language indeed ...

It was wrong on comp.lang.c, and it is wrong here. Proof by repeated
assertion is not valid.

On 21/08/2024 09:27, Muttley@dastardlyhq.com wrote:
> On Tue, 20 Aug 2024 20:56:00 -0000 (UTC)
> kalevi@kolttonen.fi (Kalevi Kolttonen) boringly babbled:
>> In comp.unix.programmer David Brown <david.brown@hesbynett.no> wrote:
>>> No, you do not need your particular favourite out of the thousand and
>>> one Linux programming books in order to program for Linux. You do not
>>> need /any/ book in order to write useful and successful code for Linux.
>>> Of course you need /some/ reference - and in the days before the
>>> internet was so easily available and so full of information, I went
>>> through a lot of programming books. Some were good, some less so, and
>>> some have become famous. But none of them were /necessary/ in any way.
>>
>> Well, I am a quite bad programmer but I am interested enough in the
>> Linux/UNIX workings so that reading the newest APUE and The Linux
>> Programming Interface did not feel painful or unnecessary at all. On
>> the contrary, it was a great pleasure to examine what kind of
>> programming facilities my favourite OS offers.
>>
>> Having these two books, or just one of them, is a great way to educate
>> oneself about Linux/UNIX. I see that The Linux Programming Interface
>> is available online as a free PDF, but I am not sure whether it is
>> a pirated version.
>>
>> There is no better way to learn Linux/UNIX workings than these two
>> books. Period.
>
> The advantage of books written by professionals is that the code and
> explanations are usually much clearer and of better equality than the quickly
> knocked up might-work-might-not crap you often find on stack overflow and
> similar sites. Thats not to say good example code isn't out there but wading
> through the rubbish can be a tedious business and IME its often quicker just
> to reach for APUE or similar.
>

"Usually" suggests you have statistics to back that up.

The reality is that there are endless numbers of crap books with poor
explanations, buggy examples, and outdated information - as well as
their being books that are high quality, accurate, and keep enough
generality to be relevant for many years. Equally, there are lots of
posts on stack overflow and other such sites with top-quality code just
as there are posts with complete nonsense, or (worse) subtly wrong code
and answers.

The medium, or the price of getting the information, is at most only in
vague correlation with the quality of the information.

On Wed, 21 Aug 2024 11:10:53 +0200
David Brown <david.brown@hesbynett.no> boringly babbled:
>If you are writing network software for Linux, how is it relevant to
>learn about the sound API, or the more advanced filesystem API's ? If

You don't, but the subsystems don't exist in isolation, there's a lot of
overlap. Eg network sockets use a lot of the same API functions as files
(eg: read, write, fcntl, ioctl) so understanding may well help to understand
the other.

>you are writing a gui program with QT, why should you be interested in X
>APIs or POSIX threading and file handling - you'll be using the QT
>libraries and APIs for graphics, threading and file handling.

Not necessarily.

>I have not suggested, or even hinted, that all you need is "core C" -
>what you need is the knowledge that is relevant to the task at hand,
>regardless of the OS, language, or whatever.

Its certainly the impression you gave.

On 21/08/2024 12:26, Muttley@dastardlyhq.com wrote:
> On Wed, 21 Aug 2024 11:10:53 +0200
> David Brown <david.brown@hesbynett.no> boringly babbled:
>> If you are writing network software for Linux, how is it relevant to
>> learn about the sound API, or the more advanced filesystem API's ? If
>
> You don't, but the subsystems don't exist in isolation, there's a lot of
> overlap. Eg network sockets use a lot of the same API functions as files
> (eg: read, write, fcntl, ioctl) so understanding may well help to understand
> the other.

Sure.

Of course understanding /some/ of this is essential for a lot of tasks.
And understanding a bit more can be /useful/. My argument is against
this idea that you need to learn it all.

Let's take an example. In my line of work, I use UARTs a lot - I've
probably used UART's on 20-30 different microcontroller families, as
well as external UART chips, bit-banging in software, with polling, DMA,
interrupts, RTOS abstractions, SDK routines. I've used them a /lot/.

Trying to understand the Linux documentation for UARTs is a nightmare.
They are horrendous - the APIs, structs, flag sets, etc., are a vast
jumble of crap for handling terminals that haven't been seen outside a
museum for 50 years, long before Linux was conceived. Trying to get the
right selection of API calls, struct setups, etc., simple raw UART
access to send and receive characters can take many days of studying
documentation of questionable standard, trial and error, and guesswork.
A good "Programming Linux" book /might/ help - but it might be out of
date. Snippets from googling, however, /does/ get the job done - you
can find examples, try them out and see what works, and in a few hours I
had everything running.

Even better, of course, is to ditch C and use Python - "pyserial" does
it all, simply and cleanly. (And the same code works on Windows, if
that happens to be useful - though Windows picks pseudo-random names for
serial ports and has nothing like udev rules.) But for this particular
customer, it had to be in C (well, C++, but that's a minor detail).

Would that task have been easier if I'd studied the details of fcntl,
ioctl, and other calls that were needed for the task? No, not at all.
Would "knowing POSIX" have helped? Would reading some old book on Linux
programming have helped? No. (I /have/ read books on Linux programming.)

But a rough idea of some of the concepts of Linux development was
useful. Knowing /something/ about the OS is helpful.

>
>> you are writing a gui program with QT, why should you be interested in X
>> APIs or POSIX threading and file handling - you'll be using the QT
>> libraries and APIs for graphics, threading and file handling.
>
> Not necessarily.
>
>> I have not suggested, or even hinted, that all you need is "core C" -
>> what you need is the knowledge that is relevant to the task at hand,
>> regardless of the OS, language, or whatever.
>
> Its certainly the impression you gave.
>

I can't imagine how you got that from my posts.

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

On Wed, 21 Aug 2024 17:27:04 +0200
David Brown <david.brown@hesbynett.no> boringly babbled:
>On 21/08/2024 12:26, Muttley@dastardlyhq.com wrote:
>Trying to understand the Linux documentation for UARTs is a nightmare.
>They are horrendous - the APIs, structs, flag sets, etc., are a vast
>jumble of crap for handling terminals that haven't been seen outside a
>museum for 50 years, long before Linux was conceived. Trying to get the

Unfortunately terminals are complex beasts with many permutations though
all that should be a higher level that what you were doing with a UART.

>Even better, of course, is to ditch C and use Python - "pyserial" does
>it all, simply and cleanly. (And the same code works on Windows, if

The problem with pyserial is you have to use Python. Horrible language
though like BASIC, useful for teaching kids to code.

On 21/08/2024 17:40, Muttley@dastardlyhq.com wrote:
> On Wed, 21 Aug 2024 17:27:04 +0200
> David Brown <david.brown@hesbynett.no> boringly babbled:
>> On 21/08/2024 12:26, Muttley@dastardlyhq.com wrote:
>> Trying to understand the Linux documentation for UARTs is a nightmare.
>> They are horrendous - the APIs, structs, flag sets, etc., are a vast
>> jumble of crap for handling terminals that haven't been seen outside a
>> museum for 50 years, long before Linux was conceived. Trying to get the
>
> Unfortunately terminals are complex beasts with many permutations though
> all that should be a higher level that what you were doing with a UART.
>

Agreed. It is bad design to mix terminal handling with UART handling.

>> Even better, of course, is to ditch C and use Python - "pyserial" does
>> it all, simply and cleanly. (And the same code works on Windows, if
>
> The problem with pyserial is you have to use Python. Horrible language
> though like BASIC, useful for teaching kids to code.
>

Let's just say, opinions differ. Python /can/ be used for beginner
programmers - but it is also an excellent language for many real tasks.
Of course it has its weaknesses and disadvantages as well as its
strengths, and aspects that will appeal to some programmers and not others.

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

On Wed, 21 Aug 2024 10:07:47 +0200, Dmitry A. Kazakov wrote:

> On 2024-08-21 02:59, Lawrence D'Oliveiro wrote:
>>
>> On Tue, 20 Aug 2024 10:27:01 +0200, Dmitry A. Kazakov wrote:
>>
>>> The question is sustainability in long term.
>>
>> In the long term, proprietary software is in retreat, while Free
>> software is on the rise. So it’s quite clear which one is more
>> “sustainable”.
>
> I mean economic sustainability.

So did I.

On Wed, 21 Aug 2024 08:45:41 -0000 (UTC), Kalevi Kolttonen wrote:

> I have never owned Commodore Amiga and I have no knowledge about its C
> compilers or the related documentation.

The programming documentation was always readily available, as I recall.
Commodore’s number-one priority was to get developers to develop apps for
their platform.

On Wed, 21 Aug 2024 11:11:46 +0200, David Brown wrote:

> On 21/08/2024 09:38, Lawrence D'Oliveiro wrote:
>>
>> On Wed, 21 Aug 2024 09:26:41 +0200, David Brown wrote:
>>
>>> And you don't need to know anything about Linux, UNIX or POSIX to
>>> program in C.
>>
>> I think the point has been made on comp.lang.c more than once, that C
>> without POSIX can be a very dull language indeed ...
>
> It was wrong on comp.lang.c, and it is wrong here. Proof by repeated
> assertion is not valid.

It came up repeatedly because of repeated examples where it was true.

On Wed, 21 Aug 2024 21:15:14 +0200
David Brown <david.brown@hesbynett.no> boringly babbled:
>On 21/08/2024 17:40, Muttley@dastardlyhq.com wrote:
>> The problem with pyserial is you have to use Python. Horrible language
>> though like BASIC, useful for teaching kids to code.
>>
>
>Let's just say, opinions differ. Python /can/ be used for beginner

Yes, its ultimately subjective. The reasons I don't like it are that I can't
stand dynamic typing in supposed "proper" languages and the syntatically
meaningful whitespace nonsense they took from Occam really grinds my gears.
In my current job I'm forced to use it but I'd never do it out of choice.

>programmers - but it is also an excellent language for many real tasks.
>Of course it has its weaknesses and disadvantages as well as its
>strengths, and aspects that will appeal to some programmers and not others.

IMO its fine for small scripts up to maybe a few hundred lines. Beyond that
no.

On Thu, 22 Aug 2024, Muttley@dastardlyhq.com wrote:

> On Wed, 21 Aug 2024 21:15:14 +0200
> David Brown <david.brown@hesbynett.no> boringly babbled:
>> On 21/08/2024 17:40, Muttley@dastardlyhq.com wrote:
>>> The problem with pyserial is you have to use Python. Horrible language
>>> though like BASIC, useful for teaching kids to code.
>>>
>>
>> Let's just say, opinions differ. Python /can/ be used for beginner
>
> Yes, its ultimately subjective. The reasons I don't like it are that I can't
> stand dynamic typing in supposed "proper" languages and the syntatically
> meaningful whitespace nonsense they took from Occam really grinds my gears.
> In my current job I'm forced to use it but I'd never do it out of choice.
>
>> programmers - but it is also an excellent language for many real tasks.
>> Of course it has its weaknesses and disadvantages as well as its
>> strengths, and aspects that will appeal to some programmers and not others.
>
> IMO its fine for small scripts up to maybe a few hundred lines. Beyond that
> no.
>

I liked python in the beginning, but I find that over the years, it has
become worse. My biggest complaint is dependency management and that you
have to download so many things in order to get a modern project to work.

On the other hand, I'm not a programmer, so I'm probably doing it wrong or
not accordin to best practices by not using containers for all my python
stuff.

On 22/08/2024 09:42, Muttley@dastardlyhq.com wrote:
> On Wed, 21 Aug 2024 21:15:14 +0200
> David Brown <david.brown@hesbynett.no> boringly babbled:
>> On 21/08/2024 17:40, Muttley@dastardlyhq.com wrote:
>>> The problem with pyserial is you have to use Python. Horrible language
>>> though like BASIC, useful for teaching kids to code.
>>>
>>
>> Let's just say, opinions differ. Python /can/ be used for beginner
>
> Yes, its ultimately subjective. The reasons I don't like it are that I can't
> stand dynamic typing in supposed "proper" languages and the syntatically
> meaningful whitespace nonsense they took from Occam really grinds my gears.
> In my current job I'm forced to use it but I'd never do it out of choice.
>

Dynamic typing has its advantages and disadvantages. You do lose a lot
of human checking and static checking when you have dynamic typing, but
you gain flexibility. Have you tried using type annotations in Python?
For some code it can give a reasonable compromise, letting you have at
least some control of types while also being flexible where you want.

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
never faced with space vs. tab conflicts causing semantic changes to the
code.

>> programmers - but it is also an excellent language for many real tasks.
>> Of course it has its weaknesses and disadvantages as well as its
>> strengths, and aspects that will appeal to some programmers and not others.
>
> IMO its fine for small scripts up to maybe a few hundred lines. Beyond that
> no.
>

Oh, it's fine for /far/ bigger programs than that. But it is excellent
for small scripts and utilities.

Like any language, you need discipline and to work in a way that suits
the language. If you approach Python coding as though it were C, or
vice versa, you'll make a mess.

On Thu, 22 Aug 2024 09:52:24 +0200
D <nospam@example.net> boringly babbled:
>On Thu, 22 Aug 2024, Muttley@dastardlyhq.com wrote:
>>> programmers - but it is also an excellent language for many real tasks.
>>> Of course it has its weaknesses and disadvantages as well as its
>>> strengths, and aspects that will appeal to some programmers and not others.
>>
>> IMO its fine for small scripts up to maybe a few hundred lines. Beyond that
>> no.
>>
>
>I liked python in the beginning, but I find that over the years, it has
>become worse. My biggest complaint is dependency management and that you
>have to download so many things in order to get a modern project to work.

Yes, that appears to be a big issue these days. On a project I was working
on recently the version of Pandas (stupid name but thats python libs) had
some minor bug and to update Pandas we had to update just about everything
else as well.

>On the other hand, I'm not a programmer, so I'm probably doing it wrong or
>not accordin to best practices by not using containers for all my python
>stuff.

For a properly designed language a container shouldn't be required. Using
a container to prevent library hell is like seeing a mess on your floor but
instead of clearing the mess you sweep it into seperate piles depending on
the type of rubbish. With C/C++ you can set LD_LIBRARY_PATH to use particular
shared object files but doing something similar with Python AFAIK is a hell of
a task.

On Thu, 22 Aug 2024 10:10:18 +0200
David Brown <david.brown@hesbynett.no> boringly babbled:
>On 22/08/2024 09:42, Muttley@dastardlyhq.com wrote:
>> Yes, its ultimately subjective. The reasons I don't like it are that I can't
>> stand dynamic typing in supposed "proper" languages and the syntatically
>> meaningful whitespace nonsense they took from Occam really grinds my gears.
>> In my current job I'm forced to use it but I'd never do it out of choice.
>>
>
>Dynamic typing has its advantages and disadvantages. You do lose a lot
>of human checking and static checking when you have dynamic typing, but
>you gain flexibility. Have you tried using type annotations in Python?

No, i'll look into it, thanks.

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

>> IMO its fine for small scripts up to maybe a few hundred lines. Beyond that
>> no.
>>
>
>Oh, it's fine for /far/ bigger programs than that. But it is excellent

As you said, opinions may differ.

On Thu, 22 Aug 2024 10:10:18 +0200, David Brown 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
> never faced with space vs. tab conflicts causing semantic changes to the
> code.

Python prohibits those space/tab inconsistencies.

Nevertheless, I don’t like the loss of redundancy in the way code
structure is expressed, which is why I like to put in “#end” comments.

On 22/08/2024 09:52, D wrote:
>
> I liked python in the beginning, but I find that over the years, it has
> become worse. My biggest complaint is dependency management and that you
> have to download so many things in order to get a modern project to work.
>

I agree that can be a poor point.

Dependency management for languages is a complex beast. It can often
make it easy to get hold of libraries, or update versions - but it can
be very hard to keep consistency and get old versions. Most dependency
management is strongly based on the idea that you have the latest
version of the language, and want the latest version of the libraries,
and that is not always true. This can be a real pain for long-running
projects.

This is not a Python-specific issue, IME. I think it applies to many or
most languages and systems with dependency and library management tools.
I certainly see it all the time for C and C++ using microcontroller
manufacturers' SDK's and libraries.

On 22/08/2024 11:02, Lawrence D'Oliveiro wrote:
> On Thu, 22 Aug 2024 10:10:18 +0200, David Brown 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
>> never faced with space vs. tab conflicts causing semantic changes to the
>> code.
>
> Python prohibits those space/tab inconsistencies.
>

No, it does not. Python treats tabs (at the start of lines, which is
the only relevant point here) as 8 spaces by default. You can change
that with command-line flags if you want. 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.

So if you have an editor set to 8-space tabs, you can mix spaces and
tabs freely, and Python will treat your code exactly as it appears. If,
as many people do, you have an editor with 4-space tabs then mixing tabs
and spaces will risk strange effects. In some cases, Python can see it
as inconsistent indentation. In other cases, you might get indentation
that is valid Python syntax but not what the programmer saw in the editor:

if cond :
doThis() # 8 spaces
doThat() # One tab

An editor that sees the tab as 4 spaces will show a very different
picture from Python that treats it as 8 spaces.

> Nevertheless, I don’t like the loss of redundancy in the way code
> structure is expressed, which is why I like to put in “#end” comments.

I would not recommend that. But I think it makes sense to add a
"return" at the end of functions if they otherwise end in indentations,
to give a clear ending to the function definition. That is vastly
better than an "# end" comment because it is checked for Python syntax
and correct (or at least plausible) indentation. If you need an end
marker for other blocks, "pass" is your friend - again it is better than
a comment.