Mailing List Archive

On Fri, Sep 3, 2021 at 4:51 AM Hope Rouselle <hrouselle@jevedi.com> wrote:
>
> Chris Angelico <rosuav@gmail.com> writes:
>
> > On Mon, Aug 30, 2021 at 11:13 PM David Raymond <David.Raymond@tomtom.com> wrote:
> >>
> >> > def how_many_times():
> >> > x, y = 0, 1
> >> > c = 0
> >> > while x != y:
> >> > c = c + 1
> >> > x, y = roll()
> >> > return c, (x, y)
> >>
> >> Since I haven't seen it used in answers yet, here's another option using our new walrus operator
> >>
> >> def how_many_times():
> >> roll_count = 1
> >> while (rolls := roll())[0] != rolls[1]:
> >> roll_count += 1
> >> return (roll_count, rolls)
> >>
> >
> > Since we're creating solutions that use features in completely
> > unnecessary ways, here's a version that uses collections.Counter:
> >
> > def how_many_times():
> > return next((count, rolls) for count, rolls in
> > enumerate(iter(roll, None)) if len(Counter(rolls)) == 1)
> >
> > Do I get bonus points for it being a one-liner that doesn't fit in
> > eighty characters?
>
> Lol. You do not. In fact, this should be syntax error :-D --- as I
> guess it would be if it were a lambda expression?

It got split across lines when I posted it, but if I did this in a
program, I'd make it a single long line. That said, though - Python
doesn't mind if you mess up the indentation inside a parenthesized
expression. Even broken like this, it WILL work. It just looks even
uglier than it does with proper indentation :)

BTW, this sort of thing is great as an anti-plagiarism check. If a
student ever turns in an abomination like this, you can be extremely
confident that it was copied from some programming site/list.
Especially since I've used the two-arg version of iter() in there -
that's quite a rarity.

Hmmmmm.

My mind is straying to evil things.

The two-arg iter can do SO much more than I'm using it for here.

By carefully designing the second argument, we could make something
that is equal to anything whose two elements are equal, which would
then terminate the loop. This... could be a lot worse than it seems.

I'll leave it as an exercise for the reader to figure out how to
capture the matching elements for return.

ChrisA
--
https://mail.python.org/mailman/listinfo/python-list

>> def how_many_times():
>> x, y = 0, 1
>> c = 0
>> while x != y:
>> c = c + 1
>> x, y = roll()
>> return c, (x, y)
>
> Since I haven't seen it used in answers yet, here's another option using our new walrus operator
>
> def how_many_times():
> roll_count = 1
> while (rolls := roll())[0] != rolls[1]:
> roll_count += 1
> return (roll_count, rolls)
>

I would go even further, saying there is no need to «roll dices»:

def how_many_times():
nb_times = random.choice([n for n in range(50) for _ in
range(round(10000*(1/6)*(5/6)**(n-1)))])
return nb_times, (random.randint(1, 6),) * 2

If i had more time on my hands, i would do something with bissect to get
nb_times with more precision, as i have (mis)calculated that the
probability of having nb_times = N is N = (1/6) * (5/6) ** (N-1)
Something like this may work:

nb_times = [.random.random() < (1/6) * (5/6) ** (N-1) for N in
range(1, 50)].index(True)+1
--
https://mail.python.org/mailman/listinfo/python-list

On 2021-09-02 11:28:21 -0300, Hope Rouselle wrote:
> dn <PythonList@DancesWithMice.info> writes:
> > On 29/08/2021 08.46, Hope Rouselle wrote:
> >> Here's my solution:
> >>
> >> --8<---------------cut here---------------start------------->8---
> >> def how_many_times():
> >> x, y = 0, 1
> >> c = 0
> >> while x != y:
> >> c = c + 1
> >> x, y = roll()
> >> return c, (x, y)
> >
> >>
> >> Why am I unhappy? I'm wish I could confine x, y to the while loop.
> >> The introduction of ``x, y = 0, 1'' must feel like a trick to a
> >> novice. How would you write this?
[...]
> But perhaps we may agree that while rolling dice until a certain
> success, we want to roll them while something happens or doesn't happen.
> One of the two. So while-True is a bit of a jump. Therefore, in this
> case, the easier and more natural option is to say while-x-not-equal-y.
>
> But this approach seems to force me into initializing x, y with
> different values.

You can get around this by using NaN:

def how_many_times():
c, x, y = 0, math.nan, math.nan
while x != y:
c = c + 1
x, y = roll()
return c, x, y

Not sure if this is an improvement. Now you have to explain to your
students why math.nan != math.nan.

When I need a guaranteed unique value I often just use object():

def how_many_times():
c, x, y = 0, object(), object()
while x != y:
c = c + 1
x, y = roll()
return c, x, y

Of course now you are back to two different values, but they look the
same. Which may be better or worse for your students. Plus x and y are
now bound to objects of different types during their lifetime, which may
be a bit dicey.

hp


--
_ | Peter J. Holzer | Story must make more sense than reality.
|_|_) | |
| | | hjp@hjp.at | -- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"

Chris Angelico <rosuav@gmail.com> writes:

> On Fri, Sep 3, 2021 at 4:33 AM Hope Rouselle <hrouselle@jevedi.com> wrote:
>> Yeah. Here's a little context. I came across this by processing a list
>> of exercises. (I'm teaching a course --- you know that by now, I
>> guess.) So the first thing I observed was the equal volume of work
>> dedicated to while loops and for loops --- so I decided to compared
>> which appeared more often in a certain sample of well-written Python
>> code. It turns out the for loop was much more frequent. Students have
>> been reporting too much work in too little time, so I decided to reduce
>> the number of exercises involving while loops. When I began to look at
>> the exercises, to see which ones I'd exclude, I decided to exclude them
>> all --- lol! --- except for one. The one that remained was this one
>> about rolling dice until a satisfying result would appear. (All other
>> ones were totally more naturally written with a for loop.)
>>
>> So if I were to also write this with a for-loop, it'd defeat the purpose
>> of the course's moment. Besides, I don't think a for-loop would improve
>> the readability here.
>
> It's on the cusp. When you ask someone to express the concept of "do
> this until this happens", obviously that's a while loop; but as soon
> as you introduce the iteration counter, it becomes less obvious, since
> "iterate over counting numbers until this happens" is a quite viable
> way to express this. However, if the students don't know
> itertools.count(), they'll most likely put in an arbitrary limit (like
> "for c in range(100000000)"), which you can call them out for.
>
>> But I thought your protest against the while-True was very well put:
>> while-True is not too readable for a novice. Surely what's readable or
>> more-natural /to someone/ is, well, subjective (yes, by definition).
>> But perhaps we may agree that while rolling dice until a certain
>> success, we want to roll them while something happens or doesn't happen.
>> One of the two. So while-True is a bit of a jump. Therefore, in this
>> case, the easier and more natural option is to say while-x-not-equal-y.
>
> That may be the case, but in Python, I almost never write "while
> True". Consider the two while loops in this function:
>
> https://github.com/Rosuav/shed/blob/master/autohost_manager.py#L92
>
> Thanks to Python's flexibility and efficient compilation, these loops
> are as descriptive as those with actual conditions, while still
> behaving exactly like "while True". (The inner loop, "more pages",
> looks superficially like it should be a for loop - "for page in
> pages:" - but the data is coming from successive API calls, so it
> can't know.)

That's pretty nice. I did suggest the same to my students, showing your
code to them, actually. The course explicitly avoided talking about
regular values being considered True, but now I couldn't keep the truth
from them.

>> I don't see it. You seem to have found what we seem to agree that it
>> would be the more natural way to write the strategy. But I can't see
>> it. It certainly isn't
>>
>> --8<---------------cut here---------------start------------->8---
>> def how_many_times_1():
>> c, x, y = 0, None, None
>> while x != y:
>> c = c + 1
>> x, y = roll()
>> return c, x, y
>> --8<---------------cut here---------------end--------------->8---
>>
>> nor
>>
>> --8<---------------cut here---------------start------------->8---
>> def how_many_times_2():
>> c, x, y = 0, None, None
>> while x == y:
>> c = c + 1
>> x, y = dados()
>> return c, x, y
>> --8<---------------cut here---------------end--------------->8---
>>
>> What do you have in mind? I couldn't see it.
>
> You're overlaying two loops here. One is iterating "c" up from zero,
> the other is calling a function and testing its results. It's up to
> you which of these should be considered the more important, and which
> is a bit of extra work added onto it. With the counter as primary, you
> get something like this:
>
> for c in itertools.count():
> x, y = roll()
> if x == y: return c, x, y
>
> With the roll comparison as primary, you get this:
>
> c, x, y = 0, 0, 1
> while x != y:
> x, y = roll()
> c += 1
> return c, x, y
>
> Reworking the second into a do-while style (Python doesn't have that,
> so we have to write it manually):
>
> c = 0
> while "x and y differ":
> x, y = roll()
> c += 1
> if x == y: break
> return c, x, y
>
> And at this point, it's looking pretty much identical to the for loop
> version. Ultimately, they're all the same and you can pick and choose
> elements from each of them.

I see. That's why C must have added the do-while, but yeah --- it's not
really worth it. (An educational investigation. Thank you.)
--
https://mail.python.org/mailman/listinfo/python-list

"Peter J. Holzer" <hjp-python@hjp.at> writes:

> On 2021-09-02 11:28:21 -0300, Hope Rouselle wrote:
>> dn <PythonList@DancesWithMice.info> writes:
>> > On 29/08/2021 08.46, Hope Rouselle wrote:
>> >> Here's my solution:
>> >>
>> >> --8<---------------cut here---------------start------------->8---
>> >> def how_many_times():
>> >> x, y = 0, 1
>> >> c = 0
>> >> while x != y:
>> >> c = c + 1
>> >> x, y = roll()
>> >> return c, (x, y)
>> >
>> >>
>> >> Why am I unhappy? I'm wish I could confine x, y to the while loop.
>> >> The introduction of ``x, y = 0, 1'' must feel like a trick to a
>> >> novice. How would you write this?
> [...]
>> But perhaps we may agree that while rolling dice until a certain
>> success, we want to roll them while something happens or doesn't happen.
>> One of the two. So while-True is a bit of a jump. Therefore, in this
>> case, the easier and more natural option is to say while-x-not-equal-y.
>>
>> But this approach seems to force me into initializing x, y with
>> different values.
>
> You can get around this by using NaN:
>
> def how_many_times():
> c, x, y = 0, math.nan, math.nan
> while x != y:
> c = c + 1
> x, y = roll()
> return c, x, y
>
> Not sure if this is an improvement. Now you have to explain to your
> students why math.nan != math.nan.
>
> When I need a guaranteed unique value I often just use object():
>
> def how_many_times():
> c, x, y = 0, object(), object()
> while x != y:
> c = c + 1
> x, y = roll()
> return c, x, y
>
> Of course now you are back to two different values, but they look the
> same. Which may be better or worse for your students. Plus x and y are
> now bound to objects of different types during their lifetime, which may
> be a bit dicey.

Lol. I would argue that it's quite appropriate to the event (``of
rolling dice'' --- clarity-obsession). :D Pretty nice alternatives.
Thank you so much.
--
https://mail.python.org/mailman/listinfo/python-list

On 04/09/2021 08.53, Hope Rouselle wrote:
> Chris Angelico <rosuav@gmail.com> writes:

>> And at this point, it's looking pretty much identical to the for loop
>> version. Ultimately, they're all the same and you can pick and choose
>> elements from each of them.
>
> I see. That's why C must have added the do-while, but yeah --- it's not
> really worth it.

Kernighan and Ritchie agree(d) with you. Per _The C Programming
Language__:
Experience shows that do-while is much less used that while
and for.

(Second edition, Section 3.6, page 63)

--
Michael F. Stemper
Outside of a dog, a book is man's best friend.
Inside of a dog, it's too dark to read.
--
https://mail.python.org/mailman/listinfo/python-list

"Michael F. Stemper" <michael.stemper@gmail.com> writes:

> On 04/09/2021 08.53, Hope Rouselle wrote:
>> Chris Angelico <rosuav@gmail.com> writes:
>
>>> And at this point, it's looking pretty much identical to the for loop
>>> version. Ultimately, they're all the same and you can pick and choose
>>> elements from each of them.
>> I see. That's why C must have added the do-while, but yeah --- it's
>> not
>> really worth it.
>
> Kernighan and Ritchie agree(d) with you. Per _The C Programming
> Language__:
> Experience shows that do-while is much less used that while
> and for.
>
> (Second edition, Section 3.6, page 63)

Special thanks for the reference! Here's what they say on the first
edition.

``As might be expected, do-while is much less used than while and for,
accounting for perhaps five percent of all loops.'' (First edition,
section 3.6, page 59.)

They looked into a sample and decided to remove the statistic. :-)
--
https://mail.python.org/mailman/listinfo/python-list

On Sat, 4 Sep 2021 12:27:55 -0500, "Michael F. Stemper"
<michael.stemper@gmail.com> declaimed the following:

>
>Kernighan and Ritchie agree(d) with you. Per _The C Programming
>Language__:
> Experience shows that do-while is much less used that while
> and for.
>

And just for confusion, consider languages with "repeat / until"...

"do / while" repeats so long as the condition evaluates to "true";
"repeat / until" /exits/ when the condition evaluates to "true".

Then... there is Ada...

While one is most likely to encounter constructs:

for ix in start..end loop
...
end loop;

and

while condition loop
...
end loop;

the core construct is just a bare

loop
...
end loop;

which, with the "exit when condition" statement allows low-level emulation
of any loop... (same as Python "if condition: break"

loop -- "while" loop
exit when not condition;
...
end loop;

loop -- "repeat / until"
...
exit when condition;
end loop;

loop -- split
...
exit when condition;
...
end loop;

{I'm not going to do the "for" loop, but one can easily manage
initialization/increment/test statements}.


To really get your mind blown, look at loops in REXX...

do while condition
...
end

do until condition
/* note that the termination parameter is listed at top, */
/* but takes effect at the bottom, so always one pass */
...
end

do forever
...
if condition then
leave
...
end

do idx = start to end /* optional: by increment */
...
end

do idx = 1 by increment for repetitions
...
end

AND worse! You can combine them...

do idx = start for repetitions while condition1 until condition2
...
end

{I need to check if both while and until can be in the same statement}


--
Wulfraed Dennis Lee Bieber AF6VN
wlfraed@ix.netcom.com http://wlfraed.microdiversity.freeddns.org/

--
https://mail.python.org/mailman/listinfo/python-list

For some people the "while true" method seems reasonable but it has a
problem if the internal body does not have some guarantee of an exit. And
that exit can be subtle. Many have mentioned ways an end condition can fail
due to rounding errors not being exactly equal to what you are looking for,
or an asymptotic process that approaches zero with a cutoff that is thus
never reached.

But I have seen some cases where you want a process or thread to run
indefinitely until it is killed by another process or you reboot. You could
of course use something like flag="green" and have your while keep testing
that value but that is just wasted motion. Of course, properly used, it does
help explain to the reader what your intention is, if done properly. It also
can confuse if you put in "while 5 < 6" or other weird ways to say do this
indefinitely.

I think part of this conversation is about programming styles and what we
should teach new students versus those who are trying to find more creative
ways to do things or more efficiently or more generality. Sometimes a more
direct method may be reasonable. On another forum, I saw someone write
somewhat lengthy and redundant code on how to deal with partitioning data
into three clusters randomly. My algorithm was general and handled any
number of N clusters and since N often does not cleanly divide the number of
items, has to place the remaining items into one of the N clusters or
distribute them one at a time into some to make them almost even in size.

His solution was to repeat large sections of code, three times, with some
modification, for the cases where the remainder (modulo N) was 0, 1 or 2.
The latter method was longer but in an odd way, much easier to understand.
It boiled down to, if you have one extra put it here. If you have two, put
one here and one there. My method had all kinds of bells and whistles that
this specific case did not need.

Let me end with asking if anyone has ever seen a mild variant of this:

... # code

while false
apologize()

... # more code

-----Original Message-----
From: Python-list <python-list-bounces+avigross=verizon.net@python.org> On
Behalf Of Hope Rouselle
Sent: Thursday, September 2, 2021 10:42 AM
To: python-list@python.org
Subject: Re: on writing a while loop for rolling two dice

David Raymond <David.Raymond@tomtom.com> writes:

>> def how_many_times():
>> x, y = 0, 1
>> c = 0
>> while x != y:
>> c = c + 1
>> x, y = roll()
>> return c, (x, y)
>
> Since I haven't seen it used in answers yet, here's another option
> using our new walrus operator
>
> def how_many_times():
> roll_count = 1
> while (rolls := roll())[0] != rolls[1]:
> roll_count += 1
> return (roll_count, rolls)

That's nice, although it doesn't seem more readable to a novice seeing a
while for the first time, seeing a loop for the first time, than that
while-True version. In fact, I think the while-True is the clearest so far.
But it's always nice to spot a walrus in the wild! (If you're somewhere
safe, that is.)
--
https://mail.python.org/mailman/listinfo/python-list

--
https://mail.python.org/mailman/listinfo/python-list

I actually like it if a language lets you spell out your intention, although adding many keywords is not a plus.

So, yes something like:

loop
...
end loop;

Is appealing as it makes clear the decision on when to exit the loop must be within the loop (or till something kills ...)

In languages like C/C++ there are people who make up macros like:

#define INDEFINITELY_LOOP while (true)

Or something like that and then allow the preprocessor to replace INDEFINITELY_LOOP with valid C code.

So, how to do something like that in python, is a challenge left to the user ????

Bottom line I find is it is a great idea to write comments as even if you are the one reviewing the code much later, you may struggle to figure out what you did and why.

-----Original Message-----
From: Python-list <python-list-bounces+avigross=verizon.net@python.org> On Behalf Of Dennis Lee Bieber
Sent: Sunday, September 5, 2021 12:50 PM
To: python-list@python.org
Subject: Re: on writing a while loop for rolling two dice

On Sat, 4 Sep 2021 12:27:55 -0500, "Michael F. Stemper"
<michael.stemper@gmail.com> declaimed the following:

>
>Kernighan and Ritchie agree(d) with you. Per _The C Programming
>Language__:
> Experience shows that do-while is much less used that while
> and for.
>

And just for confusion, consider languages with "repeat / until"...

"do / while" repeats so long as the condition evaluates to "true"; "repeat / until" /exits/ when the condition evaluates to "true".

Then... there is Ada...

While one is most likely to encounter constructs:

for ix in start..end loop
...
end loop;

and

while condition loop
...
end loop;

the core construct is just a bare

loop
...
end loop;

which, with the "exit when condition" statement allows low-level emulation of any loop... (same as Python "if condition: break"

loop -- "while" loop
exit when not condition;
...
end loop;

loop -- "repeat / until"
...
exit when condition;
end loop;

loop -- split
...
exit when condition;
...
end loop;

{I'm not going to do the "for" loop, but one can easily manage initialization/increment/test statements}.


To really get your mind blown, look at loops in REXX...

do while condition
...
end

do until condition
/* note that the termination parameter is listed at top, */
/* but takes effect at the bottom, so always one pass */
...
end

do forever
...
if condition then
leave
...
end

do idx = start to end /* optional: by increment */
...
end

do idx = 1 by increment for repetitions
...
end

AND worse! You can combine them...

do idx = start for repetitions while condition1 until condition2
...
end

{I need to check if both while and until can be in the same statement}


--
Wulfraed Dennis Lee Bieber AF6VN
wlfraed@ix.netcom.com http://wlfraed.microdiversity.freeddns.org/

--
https://mail.python.org/mailman/listinfo/python-list

--
https://mail.python.org/mailman/listinfo/python-list

Let me add something, Stefan. Some people just want to get a job done. For
this person, he had a very specific need for a one-time project where the
rest of it was understood but one small step was confusing. Frankly, he
could have done it faster by opening a text editor on something like a CSV
file and flipped some (actual) three-sided coins while manually doing a cut
and past of lines into three new files and near the end, make sure the last
few only went into files with a missing row or two.

I have too often had people ask me for programming help and when I suggested
they learn how to do it or let me make a more careful piece of code that
checks for errors or will easily work under various changed conditions,
guess what I usually encounter? Many just want it DONE. They often
sheepishly come back some time later with some variant of the same need that
mysteriously does not work with code they asked to be designed to just work
in one case! Often they hack away at the code in odd ways first and then
come to me to have it fixed.

But there are costs to generality and creating functions with dozens of
optional arguments and that handle a wide variety of inputs and thus
constantly are checking what types they are working with and perhaps
converting to others or need to create objects with lots of dunders, can
also make it error prone.

Looking at our forever loop discussion, how often are the contents of the
loop written with multiple terminating parts within the loop body that get
complex? I mean lots of break or continue statements all over the place
with multi-part if statements. Some can be rewritten as a more standard loop
with a condition like "while (a < 5 && found_it == FALSE || ( ... )) ..."
and often in the body you need if statements that let you skip the rest if
found_it is true. It can be a mess either way. At times you need to consider
rewriting it from scratch. This especially happens as requirements keep
changing. Ages ago we had code that processed MTA headers and every time we
had a meeting of standards bodies, we kept adding ever more headers and
keywords that often required some existing code to also look at other
headers that now might be present as they might change what you did in
existing code locations. I eventually suggested a rewrite and it turned out
to be more compact now that we evaluated some things first, rather than
within many existing parts.

Has anyone mentioned the really stupid looking forever loop in languages
with the other style of for loop?

for ( ; ;)

All that generally was, was an initialization command before a while and so
on but here all three parts were null, so why use it?

And in the python version, has anyone made a generator that returned NULL or
the like so you can say uselessly:

for ( _ in forever() ) ...


-----Original Message-----
From: Python-list <python-list-bounces+avigross=verizon.net@python.org> On
Behalf Of Stefan Ram
Sent: Monday, September 6, 2021 12:34 PM
To: python-list@python.org
Subject: Re: on writing a while loop for rolling two dice

"Avi Gross" <avigross@verizon.net> writes:
>For some people the "while true" method seems reasonable but it has a
>problem if the internal body does not have some guarantee of an exit.
>And

A programming error where the condition used does not
express the intent of the programmer can happen with
any kind of while loop.

>help explain to the reader what your intention is, if done properly. It
>also can confuse if you put in "while 5 < 6" or other weird ways to say
>do this indefinitely.

If any reader cannot understand "while True:", it's not
a problem with the source code.

When someone writes "while True:", it is clearly his intention
that the following indented code is repeated until it's exited
by some means, which means is not the while condition.

>His solution was to repeat large sections of code, three times, with
>some modification, for the cases where the remainder (modulo N) was 0, 1 or
2.

This is typical of

- beginners who just do not know the means of the language
to reduce redundancy yet,

- less experience programmers, who know the language but
still are not able to apply features to reduce redundancy
always,

- premature publication of unfinished code where the
redundancy has not yet been reduced, or

- programmers who do not have the personal means to climb to
the level of abstraction needed to remove the redundancy
in a specific case.

And, I think you wrote that too, sometimes less smart code is
more readable or maintainable. Maybe three very similar blocks
are repeated literally because future modifications are expected
that will make them less similar.


--
https://mail.python.org/mailman/listinfo/python-list

--
https://mail.python.org/mailman/listinfo/python-list

On 2021-09-06 at 20:11:41 -0400,
Avi Gross via Python-list <python-list@python.org> wrote:

> And in the python version, has anyone made a generator that returned
> NULL or the like so you can say uselessly:
>
> for ( _ in forever() ) ...

while "forever":
...
--
https://mail.python.org/mailman/listinfo/python-list

I hate to quibble but as almost anything in Python can evaluate to being
truthy, a command like

while "never"

evaluates to true as the string is not empty.

I meant a generator like

>>> def boring():
while True: yield()


>>> for _ in boring():
print("repeating ...")

The above gives me a nice infinite loop, with the second one looking like a
normal loop but actually doing nothing much.

-----Original Message-----
From: Python-list <python-list-bounces+avigross=verizon.net@python.org> On
Behalf Of 2QdxY4RzWzUUiLuE@potatochowder.com
Sent: Monday, September 6, 2021 8:28 PM
To: python-list@python.org
Subject: Re: on writing a while loop for rolling two dice

On 2021-09-06 at 20:11:41 -0400,
Avi Gross via Python-list <python-list@python.org> wrote:

> And in the python version, has anyone made a generator that returned
> NULL or the like so you can say uselessly:
>
> for ( _ in forever() ) ...

while "forever":
...
--
https://mail.python.org/mailman/listinfo/python-list

--
https://mail.python.org/mailman/listinfo/python-list

It has been nearly three decades since I have had to write in C, Stefan, but
what I suggested jokingly is quite mild compared to what the winners of the
obfuscated C Contest do:

https://www.ioccc.org/

Time for me to drop out of this thread. Personally I fully agree uses of
"while' as described are perfectly understandable. Features that
sophisticated programmers love tend to confuse novices. I recall my exposure
to PERL where weird things seemed to just happen with no rhyme or reason or
connections. Turned out just about everything puts things into or takes them
out of hidden variables so much of the time, a string of commands just does
what might be expected. Another variant on the elusive concept of a
pipeline. But all the nice gimmicks and tricks make novices a bit puzzled.
On the other hand, you can still write most programs the old fashioned way
and sort of start normal then head off into hyperspace at warp speed.

Python too has a way to write fairly unsophisticated programs as well as
idioms and methods that rapidly become hard to comprehend.

-----Original Message-----
From: Python-list <python-list-bounces+avigross=verizon.net@python.org> On
Behalf Of Stefan Ram
Sent: Monday, September 6, 2021 7:49 PM
To: python-list@python.org
Subject: Re: on writing a while loop for rolling two dice

"Avi Gross" <avigross@verizon.net> writes:
> In languages like C/C++ there are people who make up macros like:
>#define INDEFINITELY_LOOP while (true)
>Or something like that and then allow the preprocessor to replace
>INDEFINITELY_LOOP with valid C code.

Those usually are beginners.

>So, how to do something like that in python, is a challenge left to the
>user

Such a use of macros is frowned upon by most C programmers,
because it renders the code unreadable.

"while(1)" in C or "while True:" in Python is perfectly clear.
Don't fix it if it ain't broke!


--
https://mail.python.org/mailman/listinfo/python-list

--
https://mail.python.org/mailman/listinfo/python-list

On 7/09/21 11:38 am, Avi Gross wrote:

> #define INDEFINITELY_LOOP while (true)
>
> So, how to do something like that in python, is a challenge left to the user ????

def hell_frozen_over():
return False

while not hell_frozen_over():
....

--
Greg

--
https://mail.python.org/mailman/listinfo/python-list

On 2021-09-06, Stefan Ram <ram@zedat.fu-berlin.de> wrote:
> "Avi Gross" <avigross@verizon.net> writes:
>> In languages like C/C++ there are people who make up macros like:
>>#define INDEFINITELY_LOOP while (true)
>>Or something like that and then allow the preprocessor to replace
>>INDEFINITELY_LOOP with valid C code.
>
> Those usually are beginners.
>
>>So, how to do something like that in python, is a challenge left to the
>>user
>
> Such a use of macros is frowned upon by most C programmers,
> because it renders the code unreadable.

I remember engineering manager I worked with about 35 years ago who
used a set of C macros to try to make his code look as much like BASIC
as possible:

#define IF if (
#define THEN ) {
#define ELSE } else {
#define ENDIF }
...

IIRC he copied them out of a magazine article.

He then proceeded to try to implement a tree search algorithm (he
didn't actually know that's what he was doing) using his new
"language" without using recursion (which he had never heard of and
couldn't grok) by keeping track of state using an array. It did not go
well and made him a bit of a laughingstock. IIRC, he had first tried
to write it in actual BASIC, but gave up on that before switching to C
and his ridiculous macro set.


--
https://mail.python.org/mailman/listinfo/python-list

On Tue, 07 Sep 2021 14:53:29 +0000, Grant Edwards wrote:

> On 2021-09-06, Stefan Ram <ram@zedat.fu-berlin.de> wrote:
>> "Avi Gross" <avigross@verizon.net> writes:
>>> In languages like C/C++ there are people who make up macros like:
>>>#define INDEFINITELY_LOOP while (true)
>>>Or something like that and then allow the preprocessor to replace
>>>INDEFINITELY_LOOP with valid C code.
>>
>> Those usually are beginners.
>>
>>>So, how to do something like that in python, is a challenge left to the
>>>user
>>
>> Such a use of macros is frowned upon by most C programmers,
>> because it renders the code unreadable.
>
> I remember engineering manager I worked with about 35 years ago who used
> a set of C macros to try to make his code look as much like BASIC as
> possible:
>
> #define IF if ( #define THEN ) { #define ELSE } else {
> #define ENDIF }
> ...
>
> IIRC he copied them out of a magazine article.
>
> He then proceeded to try to implement a tree search algorithm (he didn't
> actually know that's what he was doing) using his new "language" without
> using recursion (which he had never heard of and couldn't grok) by
> keeping track of state using an array. It did not go well and made him a
> bit of a laughingstock. IIRC, he had first tried to write it in actual
> BASIC, but gave up on that before switching to C and his ridiculous
> macro set.

1 Simple rule, if you are programming in language 'a' then write Language
'a' Code it.

Just because you can do something doesn't mean you should


--
Help! I'm trapped in a Chinese computer factory!
--
https://mail.python.org/mailman/listinfo/python-list

Grant Edwards <grant.b.edwards@gmail.com> writes:

> On 2021-09-06, Stefan Ram <ram@zedat.fu-berlin.de> wrote:
>> "Avi Gross" <avigross@verizon.net> writes:
>>> In languages like C/C++ there are people who make up macros like:
>>>#define INDEFINITELY_LOOP while (true)
>>>Or something like that and then allow the preprocessor to replace
>>>INDEFINITELY_LOOP with valid C code.
>>
>> Those usually are beginners.

[...]

>> Such a use of macros is frowned upon by most C programmers,
>> because it renders the code unreadable.
>
> I remember engineering manager I worked with about 35 years ago who
> used a set of C macros to try to make his code look as much like BASIC
> as possible:
>
> #define IF if (
> #define THEN ) {
> #define ELSE } else {
> #define ENDIF }
> ...
>
> IIRC he copied them out of a magazine article.
>
> He then proceeded to try to implement a tree search algorithm (he
> didn't actually know that's what he was doing) using his new
> "language" without using recursion (which he had never heard of and
> couldn't grok) by keeping track of state using an array. It did not go
> well and made him a bit of a laughingstock. IIRC, he had first tried
> to write it in actual BASIC, but gave up on that before switching to C
> and his ridiculous macro set.

LOL! (Had fun reading this.)
--
https://mail.python.org/mailman/listinfo/python-list

On Tue, 7 Sep 2021 16:08:04 +1200, Greg Ewing <greg.ewing@canterbury.ac.nz>
declaimed the following:

>On 7/09/21 11:38 am, Avi Gross wrote:
>
>> #define INDEFINITELY_LOOP while (true)
>>
>> So, how to do something like that in python, is a challenge left to the user ?
>
>def hell_frozen_over():
> return False
>
>while not hell_frozen_over():
> ....

Hell typically freezes every January (scroll down to monthly average):
https://www.worldweatheronline.com/hell-weather-averages/michigan/us.aspx


--
Wulfraed Dennis Lee Bieber AF6VN
wlfraed@ix.netcom.com http://wlfraed.microdiversity.freeddns.org/

--
https://mail.python.org/mailman/listinfo/python-list

Although I sort of agree with Alister, I also note that many languages
deliberately provide you with the means to customize in ways that make your
personal life more amenable while making it perhaps harder for others.

Consider the humble import statement frequently used as:

import numpy as np
import pandas as pd

The above is perfectly legal and in some circles is expected. But I suspect
many people do not care about being able to type a slightly abbreviated
np.name(..) rather than numpy.name(...) and yet others import specific
functions from a package like:

from numpy import arrange

The bottom line is that there are many ways the same code can be called,
including quite a few other variations I am not describing. People can
customize their code in many ways including making it look more like the way
they might program in some other computer language/environment. Anyone
reading their code with a different viewpoint may have some adjustment
issues.

I am wondering if anyone has written programs that would take some complete
body of code and not prettify it or reformat it as some tools do, but sort
of make it into a standard format. In the above example, it might undo
things like renaming numpy to np and change all the code that looks like
np.name to numpy.name and similarly changes any function imported directly
to also be fully qualified.

Of course, some code I have seen changes things mid-stream or has some if
statement that sets one of several function calls to be the one to use
beyond that point.

So, I am not sanguine on trying to enforce some standards to make your code
easy to read by others and am more a fan of suggesting enough comments in
the code to guide anyone on your own idiosyncratic uses.


-----Original Message-----
From: Python-list <python-list-bounces+avigross=verizon.net@python.org> On
Behalf Of alister via Python-list
Sent: Tuesday, September 7, 2021 2:58 PM
To: python-list@python.org
Subject: Re: on writing a while loop for rolling two dice

On Tue, 07 Sep 2021 14:53:29 +0000, Grant Edwards wrote:

> On 2021-09-06, Stefan Ram <ram@zedat.fu-berlin.de> wrote:
>> "Avi Gross" <avigross@verizon.net> writes:
>>> In languages like C/C++ there are people who make up macros like:
>>>#define INDEFINITELY_LOOP while (true) Or something like that and
>>>then allow the preprocessor to replace INDEFINITELY_LOOP with valid C
>>>code.
>>
>> Those usually are beginners.
>>
>>>So, how to do something like that in python, is a challenge left to
>>>the user
>>
>> Such a use of macros is frowned upon by most C programmers,
>> because it renders the code unreadable.
>
> I remember engineering manager I worked with about 35 years ago who
> used a set of C macros to try to make his code look as much like BASIC
> as
> possible:
>
> #define IF if ( #define THEN ) { #define ELSE } else {
> #define ENDIF }
> ...
>
> IIRC he copied them out of a magazine article.
>
> He then proceeded to try to implement a tree search algorithm (he
> didn't actually know that's what he was doing) using his new
> "language" without using recursion (which he had never heard of and
> couldn't grok) by keeping track of state using an array. It did not go
> well and made him a bit of a laughingstock. IIRC, he had first tried
> to write it in actual BASIC, but gave up on that before switching to C
> and his ridiculous macro set.

1 Simple rule, if you are programming in language 'a' then write Language
'a' Code it.

Just because you can do something doesn't mean you should


--
Help! I'm trapped in a Chinese computer factory!
--
https://mail.python.org/mailman/listinfo/python-list

--
https://mail.python.org/mailman/listinfo/python-list

On 07/09/2021 15:53, Grant Edwards wrote:

> I remember engineering manager I worked with about 35 years ago who
> used a set of C macros to try to make his code look as much like BASIC
> as possible:
>
> #define IF if (
> #define THEN ) {
> #define ELSE } else {
> #define ENDIF }
> ...
>
> IIRC he copied them out of a magazine article.

That was quite common in C before it became popular(early/mid 80s).
I've seen Pascal, Algol and Coral macro sets in use.
You could even download pre-written ones from various
bulletin boards (remember them?!) for a while.

--
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos


--
https://mail.python.org/mailman/listinfo/python-list

On 8/09/21 2:53 am, Grant Edwards wrote:
> #define IF if (
> #define THEN ) {
> #define ELSE } else {
> #define ENDIF }
> ...

I gather that early versions of some of the Unix utilities were
written by someone who liked using macros to make C resemble Algol.

I guess you can get away with that sort of thing if you're a
Really Smart Person.

--
Greg
--
https://mail.python.org/mailman/listinfo/python-list

Greg,

Yes, a smart person may come up with such tricks but a really smart person,
in my view, adjusts. With some exceptions, such as when trying to port
existing code to a new language quickly, someone who is not too obsessive
will try to pick up the goals and spirit of a new language and use them when
it seems reasonable. And, a smart person, if they see nothing new, might
just go back to their old language or ...

Pick a language that easily supports regular expressions and object creation
and functional programming and so on, like python, and ask why you might
want to use it to simulate a really old version of BASIC when you can just
use BASIC.

Admittedly, most people are not flexible. I find that with human languages
too that some learn another language just enough to recognize words but not
to use the changed grammar or the different idioms and never become fluent.

I am amused though at the fact that python, by using indentation rather than
things like curly braces, would make some of the games like shown below
quite a bit more difficult.

-----Original Message-----
From: Python-list <python-list-bounces+avigross=verizon.net@python.org> On
Behalf Of Greg Ewing
Sent: Tuesday, September 7, 2021 9:08 PM
To: python-list@python.org
Subject: Re: on writing a while loop for rolling two dice

On 8/09/21 2:53 am, Grant Edwards wrote:
> #define IF if (
> #define THEN ) {
> #define ELSE } else {
> #define ENDIF }
> ...

I gather that early versions of some of the Unix utilities were written by
someone who liked using macros to make C resemble Algol.

I guess you can get away with that sort of thing if you're a Really Smart
Person.

--
Greg
--
https://mail.python.org/mailman/listinfo/python-list

--
https://mail.python.org/mailman/listinfo/python-list

On 9/7/21 3:51 PM, Avi Gross via Python-list wrote:
> and similarly changes any function imported directly
> to also be fully qualified.

One danger with this is that it can actual change the behavior of the
program. Maybe more likely with global objects than functions, but still
an issue.

Remember, "from module import fun" will bind the name fun in this
modules namespace to the current definiton of the object fun in the
other modules name space. If after that point, something rebinds the
name in the other module, the module that did the from import won't see
that change, but if the reference is changed to module.fun, it will.

Since that rebinding might even be some third module doing a 'monkey
patch', detecting if it is safe is basically impossible.

Admittedly, if this is an issue, the sensitivity to timing makes the
difference something very fussy to exactly the order you do things, the
cases where the difference is intended is likely fairly small.

--
Richard Damon

--
https://mail.python.org/mailman/listinfo/python-list

On 9/7/2021 9:20 PM, Avi Gross wrote:
> Greg,
>
> Yes, a smart person may come up with such tricks but a really smart person,
> in my view, adjusts. With some exceptions, such as when trying to port
> existing code to a new language quickly, someone who is not too obsessive
> will try to pick up the goals and spirit of a new language and use them when
> it seems reasonable. And, a smart person, if they see nothing new, might
> just go back to their old language or ...
>
> Pick a language that easily supports regular expressions and object creation
> and functional programming and so on, like python, and ask why you might
> want to use it to simulate a really old version of BASIC when you can just
> use BASIC.
>
> Admittedly, most people are not flexible. I find that with human languages
> too that some learn another language just enough to recognize words but not
> to use the changed grammar or the different idioms and never become fluent.
>
> I am amused though at the fact that python, by using indentation rather than
> things like curly braces, would make some of the games like shown below
> quite a bit more difficult.
>
> -----Original Message-----
> From: Python-list <python-list-bounces+avigross=verizon.net@python.org> On
> Behalf Of Greg Ewing
> Sent: Tuesday, September 7, 2021 9:08 PM
> To: python-list@python.org
> Subject: Re: on writing a while loop for rolling two dice
>
> On 8/09/21 2:53 am, Grant Edwards wrote:
>> #define IF if (
>> #define THEN ) {
>> #define ELSE } else {
>> #define ENDIF }
>> ...
>
> I gather that early versions of some of the Unix utilities were written by
> someone who liked using macros to make C resemble Algol.
>
> I guess you can get away with that sort of thing if you're a Really Smart
> Person.
>
> --
> Greg
> --
> https://mail.python.org/mailman/listinfo/python-list
>

So what do yoy think or feel about a language like RATFOR (Rational
FORTRAN) which was implemented as macros? Should they instead have
simply adapted themselves to FORTRAN?
--
https://mail.python.org/mailman/listinfo/python-list