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.

On 22/08/2024 01:43, Lawrence D'Oliveiro wrote:
> 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.

It takes but one single counter-example to invalidate general claims
like this. And for almost the entire branch of small-systems embedded
programming, code is mostly written in C, POSIX is utterly irrelevant,
and the work is not dull.

Then there are those that - wisely or unwisely - program in C for
Windows, without POSIX.

Then there are those that program in C and use libraries, abstractions
or other layers between their own code and the underlying POSIX systems.

Then there are those that write portable C code that does not depend on
any OS at all.

I have no statistics, but I'd imagine that it's actually only a small
fraction of C programmers that have direct regular contact with POSIX in
most of their regular work. C coding is not usually about how you
access a file, or how you start a thread - it's about what you do with
the file contents and the code that runs in the thread.

So - you are still wrong, even if others have said the same thing as you
did.

On 2024-08-22 13:00, David Brown wrote:

> Then there are those that - wisely or unwisely - program in C for
> Windows, without POSIX.

Yes, that is true. There is no reason to use POSIX under Windows,
whatsoever.

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

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

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

Thank you! You make me feel less of an outsider and old timer! ;)

Please forgive my interruption, but something in Muttley's comment needs
some clarification....

On Thu, 22 Aug 2024 15:11:33 +0200, D wrote:

> On Thu, 22 Aug 2024, Muttley@dastardlyhq.com wrote:
[snip]
>> 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

1) The ability to alter the loader's library search path isn't a C/C++ feature,
but, instead, is a feature of the loader, and is applicable to /any/ binary
that uses "shared objects" ("DLL"s to those who came from a Windows environment).

2) LD_LIBRARY_PATH is not "the" Unix environment variable that alters the loader's
library search path. Rather, it is /one flavour/ of such an environment variable.
Depending on the Unix system, the environment variable can be called:
LD_LIBRARY_PATH, or
LIBPATH, or
SHLIB_PATH, and
there may be other names that I don't know of.

>> to use particular shared object files
>> but doing something similar with Python AFAIK is a hell of
>> a task.
>>
>
> Thank you! You make me feel less of an outsider and old timer! ;)

--
Lew Pitcher
"In Skills We Trust"

On Thu, 22 Aug 2024 13:58:54 -0000 (UTC)
Lew Pitcher <lew.pitcher@digitalfreehold.ca> boringly babbled:
>Please forgive my interruption, but something in Muttley's comment needs
>some clarification....
>>> 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
>
>1) The ability to alter the loader's library search path isn't a C/C++ feature,
>
> but, instead, is a feature of the loader, and is applicable to /any/ binary
> that uses "shared objects" ("DLL"s to those who came from a Windows
>environment).

Sure, but the vast majority of *nix binaries will have been written in C or C++.

> Depending on the Unix system, the environment variable can be called:
> LD_LIBRARY_PATH, or

Works on Linux, BSD and Solaris so cover most bases.

> LIBPATH, or
> SHLIB_PATH, and
> there may be other names that I don't know of.

Point is the path to load dynamic libraries from can be switched very
easily and requires no changes to the system (other than installing the
alternate libs in the first place).

On 2024-08-22, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
> On 2024-08-22 13:00, David Brown wrote:
>
>> Then there are those that - wisely or unwisely - program in C for
>> Windows, without POSIX.
>
> Yes, that is true. There is no reason to use POSIX under Windows,
> whatsoever.

David also wrote this, in the same comment:

>> It takes but one single counter-example to invalidate general claims
>> like this.

It applies to your reply as well.

There are excellent, excellent reasons to use POSIX under Windows.

Such as, oh, having an entire POSIX appliation ported to Windows
almost without lifting a finger.

For the TXR project I use a POSIX layer called Cygnal (see signature
below). It gives a decent Windows port which preserves most of the
functionality. All the POSIX stuff in the TXR Lisp standard library just
works. The interactive listener ("REPL") with history and editing just
works, right in your cmd.exe console.

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

On 22/08/2024 16:28, Kaz Kylheku wrote:
> On 2024-08-22, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>> On 2024-08-22 13:00, David Brown wrote:
>>
>>> Then there are those that - wisely or unwisely - program in C for
>>> Windows, without POSIX.
>>
>> Yes, that is true. There is no reason to use POSIX under Windows,
>> whatsoever.
>
> David also wrote this, in the same comment:
>
>>> It takes but one single counter-example to invalidate general claims
>>> like this.
>
> It applies to your reply as well.
>
> There are excellent, excellent reasons to use POSIX under Windows.
>
> Such as, oh, having an entire POSIX appliation ported to Windows
> almost without lifting a finger.
>
> For the TXR project I use a POSIX layer called Cygnal (see signature
> below). It gives a decent Windows port which preserves most of the
> functionality. All the POSIX stuff in the TXR Lisp standard library just
> works. The interactive listener ("REPL") with history and editing just
> works, right in your cmd.exe console.
>

You can use the same argument to justify using X11 under Windows.

(It's also not clear how well your product manages to use POSIX under
pure Windows, or whether you have to drag this other thing called 'CygWin'.

Can you write a normal Windows app and just call into a DLL called
posix.dll or is there an extra layer or two involved?)

Bart <bc@freeuk.com> writes:
>On 22/08/2024 16:28, Kaz Kylheku wrote:

>>
>> For the TXR project I use a POSIX layer called Cygnal (see signature
>> below). It gives a decent Windows port which preserves most of the
>> functionality. All the POSIX stuff in the TXR Lisp standard library just
>> works. The interactive listener ("REPL") with history and editing just
>> works, right in your cmd.exe console.
>>
>

>(It's also not clear how well your product manages to use POSIX under
>pure Windows, or whether you have to drag this other thing called 'CygWin'.

He specified in the paragraph to which you responded the posix
interposer he used.

On 22/08/2024 17:31, Scott Lurndal wrote:
> Bart <bc@freeuk.com> writes:
>> On 22/08/2024 16:28, Kaz Kylheku wrote:
>
>>>
>>> For the TXR project I use a POSIX layer called Cygnal (see signature
>>> below). It gives a decent Windows port which preserves most of the
>>> functionality. All the POSIX stuff in the TXR Lisp standard library just
>>> works. The interactive listener ("REPL") with history and editing just
>>> works, right in your cmd.exe console.
>>>
>>
>
>> (It's also not clear how well your product manages to use POSIX under
>> pure Windows, or whether you have to drag this other thing called 'CygWin'.
>
> He specified in the paragraph to which you responded the posix
> interposer he used.

So this is only indirectly using POSIX under Windows.

On 2024-08-22, Bart <bc@freeuk.com> wrote:
> On 22/08/2024 16:28, Kaz Kylheku wrote:
>> On 2024-08-22, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>>> On 2024-08-22 13:00, David Brown wrote:
>>>
>>>> Then there are those that - wisely or unwisely - program in C for
>>>> Windows, without POSIX.
>>>
>>> Yes, that is true. There is no reason to use POSIX under Windows,
>>> whatsoever.
>>
>> David also wrote this, in the same comment:
>>
>>>> It takes but one single counter-example to invalidate general claims
>>>> like this.
>>
>> It applies to your reply as well.
>>
>> There are excellent, excellent reasons to use POSIX under Windows.
>>
>> Such as, oh, having an entire POSIX appliation ported to Windows
>> almost without lifting a finger.
>>
>> For the TXR project I use a POSIX layer called Cygnal (see signature
>> below). It gives a decent Windows port which preserves most of the
>> functionality. All the POSIX stuff in the TXR Lisp standard library just
>> works. The interactive listener ("REPL") with history and editing just
>> works, right in your cmd.exe console.
>>
>
> You can use the same argument to justify using X11 under Windows.

I could use a similar argument, but it would lack nuance.

Using X11 under Windows requires a server component, which is
somewhat clunky for a stand-alone application to carry.

X11 windows will not integrate nicely into the Windows desktop as
native windows with native widgets and behaviors.

Most POSIX stuff does translate nicely to the Windows environment, largely
because Windows was aped after Unix.

> (It's also not clear how well your product manages to use POSIX under
> pure Windows, or whether you have to drag this other thing called 'CygWin'.

It relies on a DLL, which is a modified/forked version of the Cygwin
DLL, named cygwin1.dll. This just sits in the same directory as the main
executable.

If you wrote a program with Microsoft Visual C, and dynamically linked
it to its run-time, you'd have the same thing: your executable and a
redistributable run-time.

The cygwin1.dll provides C stuff: malloc, printf, sin, cos, ...
Plus POSIX stuff: glob, ftw, fork, dup2, stat, tcgetattr, ...

> Can you write a normal Windows app and just call into a DLL called
> posix.dll or is there an extra layer or two involved?)

You can use Win32 calls (into kernel32.dll, user32.dll, ...) along side
all that stuff from cygwin1.dll, just like you can use Win32 calls in a
program linked to MSVC redistributable run-time.

Here is an example TXR Lisp program that I use for turning a laptop
monitor off. It's saved as "monitor-off.tl", where the .tl suffix
has the correct association that I can launch it by double clicking on
it.

The (usleep ...) call is implemented using POSIX functions.

(typedef HWND (cptr HWND))
(typedef UINT uint)
(typedef LPARAM long)
(typedef WPARAM ulong)

(defsymacro SC_MONITORPOWER #xF170)

(defsymacro WM_SYSCOMMAND #x0112)

(defsymacro MONITOR_OFF 2)

(defvarl HWND_BROADCAST (cptr-int -1 'HWND))

(with-dyn-lib "user32.dll"
(deffi PostMessage "PostMessageW"
int (HWND UINT WPARAM LPARAM)))

(usleep 2000000)

(PostMessage HWND_BROADCAST WM_SYSCOMMAND SC_MONITORPOWER MONITOR_OFF)

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

On 2024-08-22, Bart <bc@freeuk.com> wrote:
> On 22/08/2024 17:31, Scott Lurndal wrote:
>> Bart <bc@freeuk.com> writes:
>>> On 22/08/2024 16:28, Kaz Kylheku wrote:
>>
>>>>
>>>> For the TXR project I use a POSIX layer called Cygnal (see signature
>>>> below). It gives a decent Windows port which preserves most of the
>>>> functionality. All the POSIX stuff in the TXR Lisp standard library just
>>>> works. The interactive listener ("REPL") with history and editing just
>>>> works, right in your cmd.exe console.
>>>>
>>>
>>
>>> (It's also not clear how well your product manages to use POSIX under
>>> pure Windows, or whether you have to drag this other thing called 'CygWin'.
>>
>> He specified in the paragraph to which you responded the posix
>> interposer he used.
>
> So this is only indirectly using POSIX under Windows.

That is correct; the Microsoft POSIX subsystem isn't used, if that's
what you mean by "direct".

It's not designed to be usable, as far as I know.

POSIX is an interface specification which can be implemented on top
of Win32 calls. If you have that, then many POSIX programs work without
modification or without a lot of modification.

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

Kaz Kylheku <643-408-1753@kylheku.com> writes:
>On 2024-08-22, Bart <bc@freeuk.com> wrote:
>> On 22/08/2024 16:28, Kaz Kylheku wrote:
>>> On 2024-08-22, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>>>> On 2024-08-22 13:00, David Brown wrote:
>>>>
>>>>> Then there are those that - wisely or unwisely - program in C for
>>>>> Windows, without POSIX.
>>>>
>>>> Yes, that is true. There is no reason to use POSIX under Windows,
>>>> whatsoever.
>>>
>>> David also wrote this, in the same comment:
>>>
>>>>> It takes but one single counter-example to invalidate general claims
>>>>> like this.
>>>
>>> It applies to your reply as well.
>>>
>>> There are excellent, excellent reasons to use POSIX under Windows.
>>>
>>> Such as, oh, having an entire POSIX appliation ported to Windows
>>> almost without lifting a finger.
>>>
>>> For the TXR project I use a POSIX layer called Cygnal (see signature
>>> below). It gives a decent Windows port which preserves most of the
>>> functionality. All the POSIX stuff in the TXR Lisp standard library just
>>> works. The interactive listener ("REPL") with history and editing just
>>> works, right in your cmd.exe console.
>>>
>>
>> You can use the same argument to justify using X11 under Windows.
>
>I could use a similar argument, but it would lack nuance.
>
>Using X11 under Windows requires a server component, which is
>somewhat clunky for a stand-alone application to carry.

To be fair, the server component can be anywhere on the
local area network - windows-based x11 clients may attach to
a remote DISPLAY (perhaps a linux box, for example).

On 2024-08-22, Kaz Kylheku <643-408-1753@kylheku.com> wrote:
> On 2024-08-22, Bart <bc@freeuk.com> wrote:
>> So this is only indirectly using POSIX under Windows.
>
> That is correct; the Microsoft POSIX subsystem isn't used, if that's
> what you mean by "direct".
>
> It's not designed to be usable, as far as I know.

The Wikipedia has info about this:

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

Over the years, Microsoft shipped different "POSIX-on-Windows"
solutions, making them a moving target.

You cannot rely on any of these, not only because of the moving
target nature, but because of various drawbacks.

None of them are useful when what you want either of these:

- port a POSIX program such that it's a native Windows application,
not requiring any special environment or subsystem.

- develop a native Windows application which uses POSIX interfaces to
interact with the host system as much as possible.

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

On 2024-08-22 19:36, Kaz Kylheku wrote:

> X11 windows will not integrate nicely into the Windows desktop as
> native windows with native widgets and behaviors.

MobaXterm does a decent job actually. I am using it for years to access
Linux GUI applications from Windows. Even such monstrosity as Firefox works!

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

On 2024-08-22 17:28, Kaz Kylheku wrote:

> Such as, oh, having an entire POSIX appliation ported to Windows
> almost without lifting a finger.

It presumes that your application is already limited to POSIX.

In the scenario of designing a portable application there are more
comprehensive choices, e.g. glib (and other parts of GTK).

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

On 2024-08-22, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
> On 2024-08-22 17:28, Kaz Kylheku wrote:
>
>> Such as, oh, having an entire POSIX appliation ported to Windows
>> almost without lifting a finger.
>
> It presumes that your application is already limited to POSIX.
>
> In the scenario of designing a portable application there are more
> comprehensive choices, e.g. glib (and other parts of GTK).

Glib is something you might use in conjunction with POSIX.
It does not have API/feature parity with POSIX.

If you have a POSIX + Glib application, chances are good you can easily
port it to Windows using Cygnal. You can ship it standalone by bundling
it with the cygwin1.dll from Cygnal, and the glib library from Cygwin.

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

On Thu, 22 Aug 2024 13:30:19 +0200, Dmitry A. Kazakov wrote:

> On 2024-08-22 13:00, David Brown wrote:
>
>> Then there are those that - wisely or unwisely - program in C for
>> Windows, without POSIX.
>
> Yes, that is true. There is no reason to use POSIX under Windows,
> whatsoever.

That’s strange. Didn’t Microsoft tout the POSIX compatibility of Windows
to its US Government customers?

On Thu, 22 Aug 2024 12:47:16 +0200, David Brown wrote:

> On 22/08/2024 11:02, Lawrence D'Oliveiro wrote:
>>
>> 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.

src = \
"""
def fun() :
\t\tprint("line 1")
\t\x20\x20\x20\x20\x20\x20\x20\x20print("line 2")

fun()
"""

exec(src)

Output:

TabError: inconsistent use of tabs and spaces in indentation

On 23/08/2024 02:19, Lawrence D'Oliveiro wrote:
> On Thu, 22 Aug 2024 12:47:16 +0200, David Brown wrote:
>
>> On 22/08/2024 11:02, Lawrence D'Oliveiro wrote:
>>>
>>> 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.
>
> src = \
> """
> def fun() :
> \t\tprint("line 1")
> \t\x20\x20\x20\x20\x20\x20\x20\x20print("line 2")
>
> fun()
> """
>
> exec(src)
>
> Output:
>
> TabError: inconsistent use of tabs and spaces in indentation

src = \
"""
def fun() :
\t\x20\x20\x20\x20\x20\x20\x20\x20print("line 1")
\t\x20\x20\x20\x20\x20\x20\x20\x20print("line 2")

fun()
"""

Mixtures of tabs and spaces are accepted without complaint.

But you are right that some of the worst or most dangerous cases are
rejected by Python. Python 3 is stricter here than Python 2 was, and
much of my long-term code is Python 2.

(The incompatibilities between Python 2 and Python 3 are another pain in
Python. Equally, however, it avoids the pain seen in C and C++ where
backwards compatibility can limit new features and force poor features
to remain valid.)

On 23/08/2024 02:15, Lawrence D'Oliveiro wrote:
> On Thu, 22 Aug 2024 13:30:19 +0200, Dmitry A. Kazakov wrote:
>
>> On 2024-08-22 13:00, David Brown wrote:
>>
>>> Then there are those that - wisely or unwisely - program in C for
>>> Windows, without POSIX.
>>
>> Yes, that is true. There is no reason to use POSIX under Windows,
>> whatsoever.
>
> That’s strange. Didn’t Microsoft tout the POSIX compatibility of Windows
> to its US Government customers?

Yes - that's /exactly/ why Windows NT was designed with a POSIX subsystem.

The original plan (I remember a fine magazine article about it in the
mid nineties) was that you'd have the NT kernel and GUI (copied from
Windows 3 at the time) and multiple "personalities" or interfaces,
including POSIX, Win32, Win32s, Win16, and OS/2. Other operating
systems would have similar possibilities - OS/2 certainly had OS/2,
Win16 and Win32s. That way customers could choose there OS and their
apps independently, there would be no vendor lock-in, and the US
Government could buy Windows.

Prototypes were made, big contracts were signed, NT was granted the
required US Government certifications (even security certifications - as
long as the floppy drive was removed, there was no network port, the
serial ports were blocked up, and the computer was in a secure room with
no external connections).

Then the NT POSIX subsystem was minimised and hidden, the OS/2 interface
was never implemented, and Win32s was changed so that new Win32s apps
would not run on OS/2. The Microsoft pretence of compatibility and
vendor independence let them add new markets to their monopoly.

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.