Re: on writing a while loop for rolling two dice
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
Re: on writing a while loop for rolling two dice
On 2021-09-06, Stefan Ram wrote:
> "Avi Gross" 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
Re: on writing a while loop for rolling two dice
Grant Edwards writes:
> On 2021-09-06, Stefan Ram wrote:
>> "Avi Gross" 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
Re: on writing a while loop for rolling two dice
On Tue, 07 Sep 2021 14:53:29 +, Grant Edwards wrote:
> On 2021-09-06, Stefan Ram wrote:
>> "Avi Gross" 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
Re: on writing a while loop for rolling two dice
On Tue, 7 Sep 2021 16:08:04 +1200, Greg Ewing 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 [email protected]://wlfraed.microdiversity.freeddns.org/ -- https://mail.python.org/mailman/listinfo/python-list
RE: on writing a while loop for rolling two dice
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 On Behalf Of alister via Python-list Sent: Tuesday, September 7, 2021 2:58 PM To: [email protected] Subject: Re: on writing a while loop for rolling two dice On Tue, 07 Sep 2021 14:53:29 +, Grant Edwards wrote: > On 2021-09-06, Stefan Ram wrote: >> "Avi Gross" 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
Re: on floating-point numbers
Hope Rouselle writes: > Christian Gollwitzer writes: >> >> I believe it is not commutativity, but associativity, that is >> violated. > > Shall we take this seriously? (I will disagree, but that doesn't mean I > am not grateful for your post. Quite the contary.) It in general > violates associativity too, but the example above couldn't be referring > to associativity because the second sum above could not be obtained from > associativity alone. Commutativity is required, applied to five pairs > of numbers. How can I go from > > 7.23 + 8.41 + 6.15 + 2.31 + 7.73 + 7.77 > > to > > 8.41 + 6.15 + 2.31 + 7.73 + 7.77 + 7.23? > > Perhaps only through various application of commutativity, namely the > ones below. (I omit the parentheses for less typing. I suppose that > does not create much trouble. There is no use of associativity below, > except for the intented omission of parentheses.) > > 7.23 + 8.41 + 6.15 + 2.31 + 7.73 + 7.77 >= 8.41 + 7.23 + 6.15 + 2.31 + 7.73 + 7.77 >= 8.41 + 6.15 + 7.23 + 2.31 + 7.73 + 7.77 >= 8.41 + 6.15 + 2.31 + 7.23 + 7.73 + 7.77 >= 8.41 + 6.15 + 2.31 + 7.73 + 7.23 + 7.77 >= 8.41 + 6.15 + 2.31 + 7.73 + 7.77 + 7.23. But these transformations depend on both commutativity and associativity, precisely due to those omitted parentheses. When you transform 7.23 + 8.41 + 6.15 + 2.31 + 7.73 + 7.77 into 8.41 + 6.15 + 2.31 + 7.73 + 7.77 + 7.23. it isn't just assuming commutativity, it's also assuming associativity since it is changing from (7.23 + 8.41 + 6.15 + 2.31 + 7.73) + 7.77 to (8.41 + 6.15 + 2.31 + 7.73 + 7.77) + 7.23. If I use parentheses to modify the order of operations of the first line to match that of the last, I get 7.23 + (8.41 + 6.15 + 2.31 + 7.73 + 7.77) Now, I get 39.61 evaluating either of them. -- https://mail.python.org/mailman/listinfo/python-list
[RELEASE] Python 3.10.0rc2 is available
Python 3.10 is one month away, can you believe it? This snake is still trying to bite as it has been an interesting day of fighting fires, release blockers, and a bunch of late bugs but your friendly release team always delivers :) You can get this new release while is still fresh here: https://www.python.org/downloads/release/python-3100rc2/ This is the second release candidate of Python 3.10 This release, **3.10.0rc2** , is the last preview before the final release of Python 3.10.0 on 2021-10-04. Entering the release candidate phase, only reviewed code changes which are clear bug fixes are allowed between release candidates and the final release. There will be no ABI changes from this point forward in the 3.10 series and the goal is that there will be as few code changes as possible. *The next release will be the final release of Python 3.10.0, which is currently scheduled for Monday, 2021-10-04.* Call to action ⚠️⚠️⚠️⚠️⚠️⚠️⚠️ *The 3.10 branch is now accepting changes for 3.10.**1*. To maximize stability, the final release will be cut from the v3.10.0rc2 tag. If you need the release manager (me) to cherry-pick any critical fixes, mark issues as release blockers, and/or add me as a reviewer on a critical backport PR on GitHub. To see which changes are currently cherry-picked for inclusion in 3.10.0, look at the short-lived branch-v3.10.0 https://github.com/python/cpython/tree/branch-v3.10.0 on GitHub. ⚠️⚠️⚠️⚠️⚠️⚠️⚠️ *Core developers: all eyes on the docs now* - Are all your changes properly documented? - Did you notice other changes you know of to have insufficient documentation? *Community members* We strongly encourage maintainers of third-party Python projects to prepare their projects for 3.10 compatibilities during this phase. As always, report any issues to [the Python bug tracker ](https://bugs.python.org/). Please keep in mind that this is a preview release and its use is **not** recommended for production environments. And now for something completely different Maxwell's demon is a thought experiment that would hypothetically violate the second law of thermodynamics. It was proposed by the physicist James Clerk Maxwell in 1867. In the thought experiment, a demon controls a small massless door between two chambers of gas. As individual gas molecules (or atoms) approach the door, the demon quickly opens and closes the door to allow only fast-moving molecules to pass through in one direction, and only slow-moving molecules to pass through in the other. Because the kinetic temperature of a gas depends on the velocities of its constituent molecules, the demon's actions cause one chamber to warm up and the other to cool down. This would decrease the total entropy of the two gases, without applying any work, thereby violating the second law of thermodynamics. We hope you enjoy those new releases! Thanks to all of the many volunteers who help make Python Development and these releases possible! Please consider supporting our efforts by volunteering yourself or through organization contributions to the Python Software Foundation. Regards from a plane going to Malaga, Your friendly release team, Pablo Galindo @pablogsal Ned Deily @nad Steve Dower @steve.dower -- https://mail.python.org/mailman/listinfo/python-list
Re: on writing a while loop for rolling two dice
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
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
RE: on writing a while loop for rolling two dice
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 On Behalf Of Greg Ewing Sent: Tuesday, September 7, 2021 9:08 PM To: [email protected] 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
Re: on writing a while loop for rolling two dice
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
RE: on writing a while loop for rolling two dice
I think I already agreed with much of your point. That is indeed the problem. You are allowed to do some possibly non-standard things. A static evaluation/replacement may show the wrong function being called and a dynamic one may still mess up as there are many ways to do indirection. I mention this partially because of a recent discussion on another computer where the question was why they got an error message that the object being given a function was not a data.frame or something compatible. What was being passed was a data structure meant to hold some simulation of an EXCEL spreadsheet. Not quite the same. But they insisted it had to be a data.frame because they called functionA() and it is documented to return a data.frame. It turned out that they had loaded lots of packages (modules but not) and had not paid attention when they got a message that one function called functionA was now being covered by another with the same name. Each such package loaded often gets a new namespace/environment and when searching for a function by name, the new package was ahead of the older package, hence the warning. So one solution was to change his code in one of several ways, but more generally to call any functions that may be hidden this way in a fully qualified manner as in packageA::functionA(...) do you do not accidentally get package::functionA(...) Now note this is not so much a bug as a feature in that language and It is quite common to sort of redefine a function name to do what you want. But if you have developed your own package and want to guarantee the user does not undo your work in specific cases, you should also call some things as explicitly within your own namespace. Back to Python, it is a tad too flexible in some places and my point was that it would be interesting, along the lines of a linter, to have some tools that help explain what the program might be doing a tad more explicitly. But as an interpreted language, so much can happen at runtime that this may not be very effective or accurate. The language is full of places where slipping in another object means you over-rode the meaning of += for instance. -Original Message- From: Python-list On Behalf Of Richard Damon Sent: Tuesday, September 7, 2021 10:09 PM To: [email protected] Subject: Re: on writing a while loop for rolling two dice 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 -- https://mail.python.org/mailman/listinfo/python-list
