🌐 Mailman 3 September 2021 - Python-list - python.org

[RELEASE] Python 3.10.0rc2 is available
by Pablo Galindo Salgado Sept. 8, 2021

Sept. 8, 2021

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

1 0

Re: on writing a while loop for rolling two dice
by Greg Ewing Sept. 8, 2021

Sept. 8, 2021

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

2 1

Re: on writing a while loop for rolling two dice
by Hope Rouselle Sept. 8, 2021

Sept. 8, 2021

Grant Edwards <grant.b.edwards(a)gmail.com> writes: > On 2021-09-06, Stefan Ram <ram(a)zedat.fu-berlin.de> wrote: >> "Avi Gross" <avigross(a)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.)

1 0

RE: on writing a while loop for rolling two dice
by Avi Gross Sept. 7, 2021

Sept. 7, 2021

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(a)python.org> On Behalf Of Stefan Ram Sent: Monday, September 6, 2021 7:49 PM To: python-list(a)python.org Subject: Re: on writing a while loop for rolling two dice "Avi Gross" <avigross(a)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

1 0

RE: on writing a while loop for rolling two dice
by Avi Gross Sept. 7, 2021

Sept. 7, 2021

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(a)python.org> On Behalf Of Stefan Ram Sent: Monday, September 6, 2021 12:34 PM To: python-list(a)python.org Subject: Re: on writing a while loop for rolling two dice "Avi Gross" <avigross(a)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

3 4

Re: on writing a while loop for rolling two dice
by Hope Rouselle Sept. 7, 2021

Sept. 7, 2021

Chris Angelico <rosuav(a)gmail.com> writes: > On Fri, Sep 3, 2021 at 4:33 AM Hope Rouselle <hrouselle(a)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.)

4 4

Re: on floating-point numbers
by Hope Rouselle Sept. 7, 2021

Sept. 7, 2021

Chris Angelico <rosuav(a)gmail.com> writes: > On Sun, Sep 5, 2021 at 1:04 PM Hope Rouselle <hrouselle(a)jevedi.com> wrote: >> The same question in other words --- what's a trivial way for the REPL >> to show me such cycles occur? >> >> >>>>>> 7.23.as_integer_ratio() >> >>> (2035064081618043, 281474976710656) >> >> Here's what I did on this case. The REPL is telling me that >> >> 7.23 = 2035064081618043/281474976710656 >> >> If that were true, then 7.23 * 281474976710656 would have to equal >> 2035064081618043. So I typed: >> >> >>> 7.23 * 281474976710656 >> 2035064081618043.0 >> >> That agrees with the falsehood. I'm getting no evidence of the problem. >> >> When take control of my life out of the hands of misleading computers, I >> calculate the sum: >> >> 844424930131968 >> + 5629499534213120 >> 197032483697459200 >> ================== >> 203506408161804288 >> =/= 203506408161804300 >> >> How I can save the energy spent on manual verification? > > What you've stumbled upon here is actually a neat elegance of > floating-point, and an often-forgotten fundamental of it: rounding > occurs exactly the same regardless of the scale. The number 7.23 is > represented with a certain mantissa, and multiplying it by some power > of two doesn't change the mantissa, only the exponent. So the rounding > happens exactly the same, and it comes out looking equal! That's insightful. Thanks! > The easiest way, in Python, to probe this sort of thing is to use > either fractions.Fraction or decimal.Decimal. I prefer Fraction, since > a float is fundamentally a rational number, and you can easily see > what's happening. You can construct a Fraction from a string, and > it'll do what you would expect; or you can construct one from a float, > and it'll show you what that float truly represents. > > It's often cleanest to print fractions out rather than just dumping > them to the console, since the str() of a fraction looks like a > fraction, but the repr() looks like a constructor call. > >>>> Fraction(0.25) > Fraction(1, 4) >>>> Fraction(0.1) > Fraction(3602879701896397, 36028797018963968) > > If it looks like the number you put in, it was perfectly > representable. If it looks like something of roughly that many digits, > it's probably not the number you started with. That's pretty, pretty nice. It was really what I was looking for. -- You're the best ``little lord of local nonsense'' I've ever met! :-D (Lol. The guy is kinda stressed out! Plonk, plonk, plonk. EOD.)

1 0

Re: on floating-point numbers
by Hope Rouselle Sept. 6, 2021

Sept. 6, 2021

"Peter J. Holzer" <hjp-python(a)hjp.at> writes: > On 2021-09-05 03:38:55 +1200, Greg Ewing wrote: >> If 7.23 were exactly representable, you would have got >> 723/1000. >> >> Contrast this with something that *is* exactly representable: >> >> >>> 7.875.as_integer_ratio() >> (63, 8) >> >> and observe that 7875/1000 == 63/8: >> >> >>> from fractions import Fraction >> >>> Fraction(7875,1000) >> Fraction(63, 8) >> >> In general, to find out whether a decimal number is exactly >> representable in binary, represent it as a ratio of integers >> where the denominator is a power of 10, reduce that to lowest >> terms, > > ... and check if the denominator is a power of two. If it isn't (e.g. > 1000 == 2**3 * 5**3) then the number is not exactly representable as a > binary floating point number. > > More generally, if the prime factorization of the denominator only > contains prime factors which are also prime factors of your base, then > the number can be exactle represented (unless either the denominator or > the enumerator get too big). So, for base 10 (2*5), all numbers which > have only powers of 2 and 5 in the denominator (e.g 1/10 == 1/(2*5), > 1/8192 == 1/2**13, 1/1024000 == 1/(2**13 * 5**3)) can represented > exactly, but those with other prime factors (e.g. 1/3, 1/7, > 1/24576 == 1/(2**13 * 3), 1/1024001 == 1/(11 * 127 * 733)) cannot. > Similarly, for base 12 (2*2*3) numbers with 2 and 3 in the denominator > can be represented and for base 60 (2*2*3*5), numbers with 2, 3 and 5. Very grateful to these paragraphs. They destroy all the mystery.

1 0

Re: on writing a while loop for rolling two dice
by Hope Rouselle Sept. 6, 2021

Sept. 6, 2021

David Raymond <David.Raymond(a)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.)

2 1

Re: Problem with python
by Hope Rouselle Sept. 5, 2021

Sept. 5, 2021

Igor Korot <ikorot01(a)gmail.com> writes: > Hi, > Will this syntax work in python 2? If you say print(something) it works in both. So, stick to this syntax.

2 1