Mailman 3 September 2015 - Edu-sig

a short essay about programming
by kirby urner 08 Dec '22

08 Dec '22

A common "error" (not too serious) that I see in beginning Python (and no doubt other languages, but Python is the one I'm teaching), is having a while condition that appears to put a lid on things, but then the flow all leaks away through break statements, such that the "front door" condition is never revisited. while guess != secret: guess = int(input("Guess?: ") if guess == secret: print("You guessed it!") break else: print("Nope, try again...") What's messed up about the above code is you never really go back to the top in the case where you'd get to leave. Rather, you exit by the back door, through break. So in that case, wouldn't have been simpler and more elegant, even more "correct" (dare I say it) to have gone: while True: # no ifs ands or buts guess = int(input("Guess?: ") if guess == secret: print("You guessed it!") break else: print("Nope, try again...") I see lots of heads nodding, and that could be the end of the matter, but then a next question arises: wouldn't this also be a more correct solution?: while guess != secret: guess = int(input("Guess?: ") if guess == secret: print("You guessed it!") continue # instead of break else: print("Nope, try again...") We're back to having a variable while condition, not a boolean constant, but this time we actually exit by means of it, thanks to continue or... while guess != secret: guess = int(input("Guess?: ") if guess == secret: print("You guessed it!") else: print("Nope, try again...") ... thanks to no continue. This last one is getting a thumbs up, but then I'd pause here and say "continue" can be easier on the eyes. It's unambiguous where it takes you, in contrast to having to scan on down the gauntlet, looking for possibly other open doors. "What happens next" should not require scanning ahead too far. Help us not to get lost. Be a civic-minded coder. I'm thinking of a programming style that advises two things: (a) if you use a while condition that's variable, that's expected to change, then your goal should be to always exit because of that, i.e. that should be your only exit point. Even if some other criterion suggests exiting, you have the option to flip that "lid" at the top, to crack that front door, and bounce the ball out. (b) which is why 'continue' is your friend. You are showing the user where your 'break' statements are, except you don't use "break" statements, as you've given a non-constant condition, and your aim is to make that your ONLY exit point. In short: never use break to exit a while loop unless your condition is while True. Instead, always flip the condition and exit through the font door. However, as soon as I make that rule I can think of good reasons to break it. The other programmers in the room are shaking their heads. Won't we lose information, needed elsewhere in the program, if we "artificially" force a True condition to False. Aren't we, in effect, lying? That concern could be addressed. Keep all the info true, just treat the "lid condition" (it "keeps a lid on it") as a flag. Go ahead and remember the user's guess. allowed = 5 tries = 1 exit = False while not exit: # no other way out guess = int(input("Guess?: ") if guess == secret: print("You guessed it!") exit = True # instead of break continue print("Nope, try again...") tries += 1 if tries == allowed: print("You've maxed out") exit = True continue I think we all understand the main issue: writing reader-friendly code, and rules for doing so. There's something comforting about approaching a while loop and knowing its not a leaky sieve, riddled with back doors, maybe even an exit( ) time bomb. But in the recursion world we want a minimum of two exits usually: when another round is called for versus when we've "hit bottom". Can we have it both ways? Conclusions: Lets not be too hasty with rules of thumb and: Lets keep the reader in mind when writing code. Just because the interpreter knows to compute the flow unambiguously, doesn't mean all ways of writing it are equally reader-friendly. What may seem a gratuitous gesture, an unnecessary flourish, may actually promote reader comprehension of your code, and that should be a goal as much as satisfying the interpreter. Kirby

8 17

turtle coordinates: Y increase downards - as in most graphics API?
by Jurgis Pralgauskis 02 Jul '18

02 Jul '18

Hi, usually in computer graphics Y is counted to increase downwards. I casn do it with: setworldcoordinates(0, 400, 600, 0) but then, "right(..)" turns to the left :/ I could swap: right, left = left, right but on errror I get a bit misleading message >>> right() Traceback (most recent call last): File "<pyshell#10>", line 1, in <module> right() TypeError: left() takes exactly 1 argument (0 given) I thought to make this hack for kids, so better clearer error msgs... Any Ideas? Thanks :) -- Jurgis Pralgauskis tel: 8-616 77613; Don't worry, be happy and make things better ;) http://galvosukykla.lt

6 20

Research on best language to use for teaching beginners
by Andre Roberge 02 Oct '15

02 Oct '15

Hi everyone, Google has failed me, and I'm hoping that someone on this list could help... About a year or two ago, I read a study comparing different programming languages used for beginners. I believe there were at least four different languages that had been looked at, one of which was Python. I also believe that the (main) author including their newly created language as comparison. As I recall, the author looked at the reading comprehension (and writing ability?) demonstrated by the students for basic programming structures. One thing that jumped at me was that one of the structures used by Python (likely the for loop) was not very understood by the students. I'd appreciate if anyone could turn the above poor description into an actual link to the actual article I'm attempting to describe! ;-) André

3 3

Re: [Edu-sig] followup to older post... re Pi generator
by Tim Peters 29 Sep '15

29 Sep '15

Thanks! It's pretty clearly using a generalized continued fraction algorithm converging to pi, but I'm not clear on which - it's excruciatingly clever ;-) Here are some possibilities for those motivated enough to dig into it: https://en.wikipedia.org/wiki/Continued_fraction#Generalized_continued_frac… On Tue, Sep 29, 2015 at 12:23 PM, Guido van Rossum <guido(a)python.org> wrote: > I adapted this from an ABC program by Lambert Meertens. I don't know where > he got it from, but I wouldn't be surprised if he came up with it himself. > The algorithm basically shows off rational arithmetic in either language. > > On Tue, Sep 29, 2015 at 10:03 AM, kirby urner <kirby.urner(a)gmail.com> wrote: >> >> >> Wow, I never even guessed Guido had anything to do with this code. The >> world shrinks again! >> >> Fun! >> >> Kirby >> >> >> >> On Tue, Sep 29, 2015 at 9:41 AM, Tim Peters <tim.peters(a)gmail.com> wrote: >>> >>> Copying Guido because he's the actual original author of this code. I >>> remember it being in a very early intro to Python, which I can't find >>> now. And it used to be included in a Python distribution's Demo >>> directory. But, e.g., you can see it in this mailing list message >>> from Guido in 1994, during an early discussion of what eventually >>> became Python's generators. Guido, do you remember where this >>> algorithm came from? >>> >>> http://legacy.python.org/search/hypermail/python-1994q2/0429.html >>> scroll down to point "6)" >>> >>> [kirby urner <kirby.urner(a)gmail.com>] >>> > I'm still interested in finding more bibliographic sources for this >>> > one, not >>> > necessarily in Python syntax i.e. did Euler come up with this or who? >>> > >>> > >>> > def pi_digits(): >>> > >>> > k, a, b, a1, b1 = 2, 4, 1, 12, 4 >>> > while True: >>> > p, q, k = k*k, 2*k+1, k+1 >>> > a, b, a1, b1 = a1, b1, p*a+q*a1, p*b+q*b1 >>> > d, d1 = a/b, a1/b1 >>> > while d == d1: >>> > yield int(d) >>> > a, a1 = 10*(a%b), 10*(a1%b1) >>> > d, d1 = a/b, a1/b1 >>> > >>> > [ http://mail.python.org/pipermail/edu-sig/2012-December/010728.html ] >>> > >>> >>>> pi = pi_digits() >>> >>>> "".join([str(next(pi)) for i in range(100)])) >>> > >>> > '3141592653589793238462643383279502884197169399375105820974944592307816406286208998628034825342117067' >>> > >>> > ... so far what we know is some high school student handed it in for >>> > homework. >> >> > > > > -- > --Guido van Rossum (python.org/~guido)

1 0

followup to older post... re Pi generator
by kirby urner 29 Sep '15

29 Sep '15

I'm still interested in finding more bibliographic sources for this one, not necessarily in Python syntax i.e. did Euler come up with this or who? def pi_digits(): k, a, b, a1, b1 = 2, 4, 1, 12, 4 while True: p, q, k = k*k, 2*k+1, k+1 a, b, a1, b1 = a1, b1, p*a+q*a1, p*b+q*b1 d, d1 = a/b, a1/b1 while d == d1: yield int(d) a, a1 = 10*(a%b), 10*(a1%b1) d, d1 = a/b, a1/b1 [ http://mail.python.org/pipermail/edu-sig/2012-December/010728.html ] >>> pi = pi_digits() >>> "".join([str(next(pi)) for i in range(100)])) '3141592653589793238462643383279502884197169399375105820974944592307816406286208998628034825342117067' ... so far what we know is some high school student handed it in for homework. Kirby

2 2

Edu-sig list offline?
by Christian Mascher 24 Sep '15

24 Sep '15

Hi all, as a long-time lurker I seem to be getting no more postings on this list. Has everybody moved to EduWG, or are you all just very busy at the moment? Cheers, Christian

2 1