I took at the look at the Wikipedia page for GNU Make, the wonderful build
automation tool, and I found an interesting comment.

Make uses a tab character as part of its syntax. Any competent text editor
(except on Microslop) will clearly distinguish between tabs and spaces, but
some still find the practice abhorrent:

'This aspect of the syntax of makefiles is often subject to criticism; it
has been described by Eric S. Raymond as "one of the worst design botches
in the history of Unix" and The Unix-Haters Handbook said "using tabs as
part of the syntax is like one of those pungee stick traps in The Green
Berets".'

Gee. I wonder what these dudes would think of Python?

Ha, ha, ha, ha, ha, ha, ha, ha, ha, ha, ha, ha, ha, ha, ha!

Nuxxie wrote this copyrighted missive and expects royalties:

> I took at the look at the Wikipedia page for GNU Make, the wonderful build
> automation tool, and I found an interesting comment.
>
> Make uses a tab character as part of its syntax. Any competent text editor
> (except on Microslop) will clearly distinguish between tabs and spaces, but
> some still find the practice abhorrent:
>
> 'This aspect of the syntax of makefiles is often subject to criticism; it
> has been described by Eric S. Raymond as "one of the worst design botches
> in the history of Unix" and The Unix-Haters Handbook said "using tabs as
> part of the syntax is like one of those pungee stick traps in The Green
> Berets".'
>
> Gee. I wonder what these dudes would think of Python?

The usage of spaces or tabs to determine statement scope is a great big
turnoff for me.

I don't subscribe to Guido's opinion on the visual ease of indentation.
It's easier to search for braces and use whatever indentation makes it
easy to read in context.

The beauty of C is that white space is not significant except in quotes.

--
Good night to spend with family, but avoid arguments with your mate's
new lover.

On 3/20/2024 7:00 AM, Lameass Larry wrote:

> Gee. I wonder what these dudes would think of Python?
>
> Ha, ha, ha, ha, ha, ha, ha, ha, ha, ha, ha, ha, ha, ha, ha!

Eric Raymond LOVES python.

---------------------------------------------------------------------------

"This was my first clue that, in Python, I was actually dealing with an
exceptionally good design."

---------------------------------------------------------------------------

"Even if we stipulate that I am a fairly talented hacker, this is an
amazing testament to Python's clarity and elegance of design.

There was simply no way I could have pulled off a coup like this in
Perl, even with my vastly greater experience level in that language. It
was at this point I realized I was probably leaving Perl behind."

---------------------------------------------------------------------------

"For anything larger or more complex, I have come to prefer the subtle
virtues of Python—and I think you will, too."

---------------------------------------------------------------------------

That was 24 years ago

https://www.linuxjournal.com/article/3882

And the above is a typical reaction when you discover how much time and
effort Python can save you.

On 3/20/2024 8:13 AM, Chris Ahlstrom wrote:
> Nuxxie wrote this copyrighted missive and expects royalties:
>
>> I took at the look at the Wikipedia page for GNU Make, the wonderful build
>> automation tool, and I found an interesting comment.
>>
>> Make uses a tab character as part of its syntax. Any competent text editor
>> (except on Microslop) will clearly distinguish between tabs and spaces, but
>> some still find the practice abhorrent:
>>
>> 'This aspect of the syntax of makefiles is often subject to criticism; it
>> has been described by Eric S. Raymond as "one of the worst design botches
>> in the history of Unix" and The Unix-Haters Handbook said "using tabs as
>> part of the syntax is like one of those pungee stick traps in The Green
>> Berets".'
>>
>> Gee. I wonder what these dudes would think of Python?
>
> The usage of spaces or tabs to determine statement scope is a great big
> turnoff for me.

Terminating lines with an arbitrary character, such as a semicolon, is
bogus to me.

> I don't subscribe to Guido's opinion on the visual ease of indentation.
> It's easier to search for braces and use whatever indentation makes it
> easy to read in context.

Contradicted yourself from one sentence to the next... shades of Feeb.

Python style (forced indents, no forced brackets) is shorter and more
readable than C style (no forced indents, forced brackets).

> The beauty of C is that white space is not significant except in quotes.

Just because you can doesn't mean you should.

Code without indentation and white space is unreadable and virtually
impossible to follow.

No professional programmer would EVER submit it as work product. No
programming book would EVER use it as an example of programming style.

On 3/20/2024 11:58 AM, Relf wrote:
> DFS:
>> Code without indentation and white space is unreadable
>> No programming book would EVER use it as an example of programming style.
>
> The more spastic the code, the greater the whitespace & comments.

ha! I knew you'd come thru with some drooling like this.

You know your crazed code would NEVER pass muster, which is why you once
admitted:

DFS: "What are you gonna do when someone inherits your program? You're
not going to just let it die, are you?"

You: "Yes, absolutely, I'd tell the next poor fool to totally rewrite it."

On Wed, 20 Mar 2024 11:00:16 +0000, Nuxxie wrote:

> Gee. I wonder what these dudes would think of Python?

Python is consistent: use tabs or spaces, don’t mix them (that’s a syntax
error in Python 3).

Make uses tabs only in particular places, not others.

On Wed, 20 Mar 2024 08:13:18 -0400, Chris Ahlstrom wrote:

> The usage of spaces or tabs to determine statement scope is a great big
> turnoff for me.
>
> I don't subscribe to Guido's opinion on the visual ease of indentation.

There is redundancy in how most reasonable programmers write their
code; in conventional languages, where there are explicit
statement-bracketing symbols, the indentation (which the compiler
ignores) tends to follow these symbols anyway. That redundancy is a
useful check that the code means what you think it means.

Python does away with that redundancy, by making the indentation serve
as statement-bracketing as well. I think this is a mistake. However, I
restore the redundancy by adding “#end” lines (which the compiler
ignores). E.g.

def parse_headers() :
nonlocal content_type, content_type_opts
for keyword, value in scope["headers"] :
keyword = keyword.decode().lower()
if keyword == "content-type" :
content_type = value.decode()
elif keyword == "cookie" :
for item in value.decode().split(";") :
name, val = item.strip().replace(" ", "").split("=", 1)
cookies[name] = val
#end for
#end if
#end for
if content_type != None :
content_type, content_type_opts = \
multipart.multipart.parse_options_header(content_type)
content_type = content_type.decode()
content_type_opts = dict((k.decode(), v) for k, v in content_type_opts.items())
#end if
#end parse_headers

Another useful consequence is, I have custom Emacs commands defined to
jump between lines with matching indentation. This lets me navigate
quickly between the start and end of statement blocks. Without those
“#end” lines, it would not be so easy to find the ends of the blocks.

On Wed, 20 Mar 2024 10:25:39 -0400, DFS wrote:

> Terminating lines with an arbitrary character, such as a semicolon, is
> bogus to me.

It’s a punctuation symbol; its meaning is for that sort of purpose.

On Wed, 20 Mar 2024 10:25:39 -0400, DFS wrote:

> Python style (forced indents, no forced brackets) is shorter and more
> readable than C style (no forced indents, forced brackets).

for i in range(10):
print(f"foo[{i} is {foo[i]}")

for (i=0; i<10; i++) {
printf("foo[%d] is %s\n", i, foo[i]);
}

Whoopee! Python wins by one line! Unless of course

for (i=0; i<10; i++) {printf("foo[%d] is %s\n", i, foo[i]);}

On 21 Mar 2024 07:12:03 GMT, rbowman wrote:

> Whoopee! Python wins by one line! Unless of course
>
> for (i=0; i<10; i++) {printf("foo[%d] is %s\n", i, foo[i]);}

for i in range(10): print(f"foo[{i} is {foo[i]}")

is syntactically valid Python.

On 3/21/2024 3:12 AM, rbowman wrote:
> On Wed, 20 Mar 2024 10:25:39 -0400, DFS wrote:
>
>> Python style (forced indents, no forced brackets) is shorter and more
>> readable than C style (no forced indents, forced brackets).
>
> for i in range(10):
> print(f"foo[{i} is {foo[i]}")
>
> for (i=0; i<10; i++) {
> printf("foo[%d] is %s\n", i, foo[i]);
> }
>
> Whoopee! Python wins by one line!

A win is a win is a win.

> Unless of course
>
> for (i=0; i<10; i++) {printf("foo[%d] is %s\n", i, foo[i]);}

for i in range(2,11): print("%d made %d look like a foo^2" % (i*i,i))

rbowman wrote this copyrighted missive and expects royalties:

> On Wed, 20 Mar 2024 10:25:39 -0400, DFS wrote:
>
>> Python style (forced indents, no forced brackets) is shorter and more
>> readable than C style (no forced indents, forced brackets).
>
> for i in range(10):
> print(f"foo[{i} is {foo[i]}")
>
> for (i=0; i<10; i++) {
> printf("foo[%d] is %s\n", i, foo[i]);
> }
>
> Whoopee! Python wins by one line! Unless of course
>
> for (i=0; i<10; i++) {printf("foo[%d] is %s\n", i, foo[i]);}

for (int n : { 2, 4, 6, 8 })
std::cout << n << ", ";

std::cout << "who do we appreciate?" << std::endl

(std::endl is \n with a flush.

--
Q: How many Zen masters does it take to screw in a light bulb?
A: None. The Universe spins the bulb, and the Zen master stays out
of the way.

On Thu, 21 Mar 2024 07:22:01 -0000 (UTC), Lawrence D'Oliveiro wrote:

> On 21 Mar 2024 07:12:03 GMT, rbowman wrote:
>
>> Whoopee! Python wins by one line! Unless of course
>>
>> for (i=0; i<10; i++) {printf("foo[%d] is %s\n", i, foo[i]);}
>
> for i in range(10): print(f"foo[{i} is {foo[i]}")
>
> is syntactically valid Python.

Yes it is. The PEP8 police will be paying you a visit shortly. Both black
and ruff would try to fix it for you.

black junk.py
reformatted junk.py

All done! ✨ 🍰 ✨
1 file reformatted.

for i in range(10):
print(f"foo[{i} is {foo[i]}")

On Thu, 21 Mar 2024 09:22:06 -0400, DFS wrote:

> for i in range(2,11): print("%d made %d look like a foo^2" % (i*i,i))

Embrace f strings. Unless you're running an obsolete version of course.

Some of the improvements leave me with a yawn but I use

$"The quick red {animal} jumped over the brain dead Windows {user}"

so I really liked that addition. Yeah, the % is sort of like C but half
the time I screw up the tuple. format was more work too.

On Thu, 21 Mar 2024 10:10:33 -0400, Chris Ahlstrom wrote:

> for (int n : { 2, 4, 6, 8 })
> std::cout << n << ", ";
>
> std::cout << "who do we appreciate?" << std::endl
>
> (std::endl is \n with a flush.

cout never did much for me either. That's one of the areas that seemed
like a gratuitous departure from C.

Then there is the Python

print("Never again!", end="\r")

On Thu, 21 Mar 2024 10:10:33 -0400, Chris Ahlstrom wrote:

> std::cout << "who do we appreciate?" << std::endl

“Whom”

On 22 Mar 2024 03:13:46 GMT, rbowman wrote:

> Embrace f strings.

printf-style FTW!

It’s the only style that is (approximately) supported across several
different languages: C, C++, Perl, Python, Java, POSIX shells, even PHP.

On 22 Mar 2024 03:06:35 GMT, rbowman wrote:

> On Thu, 21 Mar 2024 07:22:01 -0000 (UTC), Lawrence D'Oliveiro wrote:
>
>> On 21 Mar 2024 07:12:03 GMT, rbowman wrote:
>>
>>> Whoopee! Python wins by one line! Unless of course
>>>
>>> for (i=0; i<10; i++) {printf("foo[%d] is %s\n", i, foo[i]);}
>>
>> for i in range(10): print(f"foo[{i} is {foo[i]}")
>>
>> is syntactically valid Python.
>
> Yes it is. The PEP8 police will be paying you a visit shortly.

They know me. They’ve seen my “#end” comments, and they have been scarred
for life. They don’t come round any more.

rbowman wrote this copyrighted missive and expects royalties:

> On Thu, 21 Mar 2024 10:10:33 -0400, Chris Ahlstrom wrote:
>
>> for (int n : { 2, 4, 6, 8 })
>> std::cout << n << ", ";
>>
>> std::cout << "who do we appreciate?" << std::endl
>>
>> (std::endl is \n with a flush.
>
> cout never did much for me either. That's one of the areas that seemed
> like a gratuitous departure from C.
>
> Then there is the Python
>
> print("Never again!", end="\r")

operator << is useful with std::ostringstream when you want to avoid having
deal with allocating enough output space. Still, I use this a lot:

char temp[32];
snprintf(temp, sizeof temp, "We have %d idiots here", idcount);

Sometime a printf specification is just easier to read.

The GNU compiler will even warn if the buffer isn't big enough to hold
the largest possible result.

--
Gratitude and treachery are merely the two extremities of the same procession.
You have seen all of it that is worth staying for when the band and the gaudy
officials have gone by.
-- Mark Twain, "Pudd'nhead Wilson's Calendar"

Lawrence D'Oliveiro wrote this copyrighted missive and expects royalties:

> On Thu, 21 Mar 2024 10:10:33 -0400, Chris Ahlstrom wrote:
>
>> std::cout << "who do we appreciate?" << std::endl
>
> “Whom”

Tell that to the cheerleaders!

Winston tastes good like a cigarette should!

--
Have a place for everything and keep the thing somewhere else; this is not
advice, it is merely custom.
-- Mark Twain

Chris Ahlstrom <OFeem1987@teleworm.us> wrote at 12:20 this Friday (GMT):
> rbowman wrote this copyrighted missive and expects royalties:
>
>> On Thu, 21 Mar 2024 10:10:33 -0400, Chris Ahlstrom wrote:
>>
>>> for (int n : { 2, 4, 6, 8 })
>>> std::cout << n << ", ";
>>>
>>> std::cout << "who do we appreciate?" << std::endl
>>>
>>> (std::endl is \n with a flush.
>>
>> cout never did much for me either. That's one of the areas that seemed
>> like a gratuitous departure from C.
>>
>> Then there is the Python
>>
>> print("Never again!", end="\r")
>
> operator << is useful with std::ostringstream when you want to avoid having
> deal with allocating enough output space. Still, I use this a lot:
>
> char temp[32];
> snprintf(temp, sizeof temp, "We have %d idiots here", idcount);
>
> Sometime a printf specification is just easier to read.
>
> The GNU compiler will even warn if the buffer isn't big enough to hold
> the largest possible result.

Using C syntax in CPP isn't best practice though.
--
user <candycane> is generated from /dev/urandom

rbowman <bowman@montana.com> wrote at 03:13 this Friday (GMT):
> On Thu, 21 Mar 2024 09:22:06 -0400, DFS wrote:
>
>> for i in range(2,11): print("%d made %d look like a foo^2" % (i*i,i))
>
> Embrace f strings. Unless you're running an obsolete version of course.
>
> Some of the improvements leave me with a yawn but I use
>
> $"The quick red {animal} jumped over the brain dead Windows {user}"
>
> so I really liked that addition. Yeah, the % is sort of like C but half
> the time I screw up the tuple. format was more work too.

f-strings are so nice, especially since you can use it as arguments for
other functions and don't have to rely on a temporary string var.
--
user <candycane> is generated from /dev/urandom

On 3/21/2024 11:13 PM, rbowman wrote:
> On Thu, 21 Mar 2024 09:22:06 -0400, DFS wrote:
>
>> for i in range(2,11): print("%d made %d look like a foo^2" % (i*i,i))
>
> Embrace f strings. Unless you're running an obsolete version of course.
>
> Some of the improvements leave me with a yawn but I use
>
> $"The quick red {animal} jumped over the brain dead Windows {user}"

heh!

> so I really liked that addition. Yeah, the % is sort of like C but half
> the time I screw up the tuple. format was more work too.

I use and prefer the modulo *because* it's like C printf. Most of my
python gets duped in C (for the practice).

lusers = ['Feeb','Joel','Ahlstrom','bowman']
for luser in lusers:
print ("Linux luser %s loves his Windows money." % (luser))
With the mod operator:
1 add the letter f to print
2 add a newline inside the quote
3 replace the mod % with a comma
4 add a semicolon at the end

and you're done migrating it to C. That's 4 tweaks, but it's as close
as you can get.

py: print ("Linux mama's boy %s loves his allowance." % (luser))
C : printf("Linux mama's boy %s loves his allowance.\n", (luser));

candycanearter07 wrote this copyrighted missive and expects royalties:

> Chris Ahlstrom <OFeem1987@teleworm.us> wrote at 12:20 this Friday (GMT):
>> rbowman wrote this copyrighted missive and expects royalties:
>>
>>> On Thu, 21 Mar 2024 10:10:33 -0400, Chris Ahlstrom wrote:
>>>
>>>> for (int n : { 2, 4, 6, 8 })
>>>> std::cout << n << ", ";
>>>>
>>>> std::cout << "who do we appreciate?" << std::endl
>>>>
>>>> (std::endl is \n with a flush.
>>>
>>> cout never did much for me either. That's one of the areas that seemed
>>> like a gratuitous departure from C.
>>>
>>> Then there is the Python
>>>
>>> print("Never again!", end="\r")
>>
>> operator << is useful with std::ostringstream when you want to avoid having
>> deal with allocating enough output space. Still, I use this a lot:
>>
>> char temp[32];
>> snprintf(temp, sizeof temp, "We have %d idiots here", idcount);
>>
>> Sometime a printf specification is just easier to read.
>>
>> The GNU compiler will even warn if the buffer isn't big enough to hold
>> the largest possible result.
>
> Using C syntax in CPP isn't best practice though.

Well, I could write it as:

#include <cstdio>
char temp[32];
(void) std::snprintf(temp, sizeof temp, "We have %d idiots here", idcount);

:-D

I will use whatever is convenient, easy-to-code and easy-to-read, and safe;
it's a judgment call.

And there are tons of C-only functions out there. Sometimes I will write
a C++ wrapper (or a member function) for some of them. So many decisions to
make!

--
Q: What's the difference betweeen USL and the Graf Zeppelin?
A: The Graf Zeppelin represented cutting edge technology for its time.

candycanearter07 wrote this copyrighted missive and expects royalties:

> rbowman <bowman@montana.com> wrote at 03:13 this Friday (GMT):
>> On Thu, 21 Mar 2024 09:22:06 -0400, DFS wrote:
>>
>>> for i in range(2,11): print("%d made %d look like a foo^2" % (i*i,i))
>>
>> Embrace f strings. Unless you're running an obsolete version of course.
>>
>> Some of the improvements leave me with a yawn but I use
>>
>> $"The quick red {animal} jumped over the brain dead Windows {user}"
>>
>> so I really liked that addition. Yeah, the % is sort of like C but half
>> the time I screw up the tuple. format was more work too.
>
> f-strings are so nice, especially since you can use it as arguments for
> other functions and don't have to rely on a temporary string var.

Those sound like the formatting available for C# String.

--
You own a dog, but you can only feed a cat.