Mailman 3 March 2018 - 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

MineCraft with Python
by Jurgis Pralgauskis 04 Dec '22

04 Dec '22

Hi, intro: many kids like MineCraft :) probably you know/heared of MineCraft Pi https://www.raspberrypi.org/learning/getting-started-with-minecraft-pi/ But there seems to be Py for real MC http://coderdojotc.readthedocs.io/projects/python-minecraft/en/latest/ http://www.instructables.com/id/Python-coding-for-Minecraft/ PS.: a nice article (from js4MC world) https://github.com/walterhiggins/ScriptCraft/blob/master/docs/YoungPersonsG… -- Jurgis Pralgauskis tel: 8-616 77613; Don't worry, be happy and make things better ;) http://galvosukykla.lt

6 6

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

Simplest webapps
by Aivar Annamaa 01 Apr '18

01 Apr '18

Hi! Let's say my students are able to write programs like this: name = input("name") if name == "Pete": greeting = "Hi" else: greeting = "Hello!" print(f""" <html> <body> {greeting} {name}! </body> </html> """) I'd like to allow them start writing web-apps without introducing functions first (most web-frameworks require functions). It occurred to me that it's not hard to create a wrapper, which presents this code as a web-app (input would be patched to look up GET or POST parameters with given name). This approach would allow simple debugging of the code on local machine and no extra libraries are required in this phase. Any opinions on this? Has this been tried before? best regards, Aivar

6 7

probability and statistics demo for kids
by Perry Grossman 30 Mar '18

30 Mar '18

I am thinking of doing a simplified interactive presentation on probability and Bayesian statistics for my kids' elementary school. I think it would probably be best for 6-8th graders, but there might be ways to do this for younger students. I'd like to run some Python code to show probability distributions and statistics. I am thinking of simplified examples from these works: Maybe the dice problem, or the cookie problem here: Allen Downey - Bayesian statistics made simple - PyCon 2016 <https://youtu.be/TpgiFIGXcT4?t=1741> A friend also suggested doing an analysis of how many cards (e.g. pokemon) that one might need to buy to colleft the whole set. Any suggestions on how to make this manageable approachable for kids? Perry On Feb 20, 2018 12:02 PM, <edu-sig-request(a)python.org> wrote: > Send Edu-sig mailing list submissions to > edu-sig(a)python.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mail.python.org/mailman/listinfo/edu-sig > or, via email, send a message with subject or body 'help' to > edu-sig-request(a)python.org > > You can reach the person managing the list at > edu-sig-owner(a)python.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Edu-sig digest..." > > > Today's Topics: > > 1. if I taught high school calculus today... (kirby urner) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 19 Feb 2018 19:50:28 -0800 > From: kirby urner <kirby.urner(a)gmail.com> > To: "edu-sig(a)python.org" <edu-sig(a)python.org> > Subject: [Edu-sig] if I taught high school calculus today... > Message-ID: > <CAPJgG3Q5XVmSsiWafNsq928EiYGKYi7XMmQiBsi4fm9-1_HP4w(a)mail.gm > ail.com> > Content-Type: text/plain; charset="utf-8" > > I was a high school calculus teacher (also algebra, geometry, trig) first > job outta university, stuck with it for two years. > > Fast forward to almost age 60, and I'm teaching coding to middle schoolers, > thinking it's all still math. [1] > > Shouldn't take a "computer scientist" to cover this stuff... Algorithms are > algorithms after all. > > Were I to teach calculus today, in light of what I now know, I'd focus on > probability density functions right when we get to integration, as "area > under the probability curve" is precisely how we figure out chances of > something happening. > > We would use Jupyter Notebooks with SciPy, all free & open source. > > As I recall, our calc curriculum never did much to bridge to statistics, > but in SciPy / NumPy, every continuous probability distribution function > (PDF) comes with a cumulative distribution function (CDF) that's defined > exactly as a definite integral between A and B, and giving the probability > some x in distribution X falls between A and B. > > Forming a bridge twixt calculus and data science would be another strategy > for getting scientific calculators to share the road, with more relevant > free tools (always an ulterior motive for me). I don't think a TI is able > to do definite integration over a standard normal curve. > > Actually, I see I'm wrong: > http://cfcc.edu/faculty/cmoore/TINormal.htm > > Oh well, back to the drawing board. I still think a strong tie-in twixt > calc and data science makes a lot of sense at the high school level. With > or without Jupyter Notebooks. > > Kirby > > PS: right now I'm going through Allen Downey's tutorial on Bayesian stats > using the above mentioned tools, from Pycon 2016: > https://youtu.be/TpgiFIGXcT4 > I attended this conference, but didn't manage to make this tutorial. > > [1] I've shared this before, still relevant: > https://medium.com/@kirbyurner/is-code-school-the-new-high- > school-30a8874170b > > Also this blog post: > http://mybizmo.blogspot.com/2018/02/magic-squares.html >

5 11

still admiring J
by kirby urner 23 Mar '18

23 Mar '18

Greetings edu-siggers! Way back in the archives you'll find me extolling a language known as J, by Kenneth Iverson, his son Eric, and Roger Hui. I never met any of these guys in person, but knew of Iverson through APL, which I discovered at Princeton, and fell in love with. Iverson helped me squish some typos in my Jiving with J.[1] What I admire about J, as about R and Python via Numpy, is the inclusion of an n-Dimensional Block (array, addressable memory with multiple axes), as a language native, a core star. J reads like a right-to-left pipeline with an nD Block going through it. I guess we'd need to call that a Functional Programming language right? As the former high school math teacher (long ago -- though I'm still in the schools, as recently as today in fact, as an after school Python instructor), I still chafe at the fact that we don't dive in with these tools at that age level, except in rare cases, and instead insist on students buying all those TIs year after year. But that's me the broken record. For those schools that break out, charter or public (nevermind, how they talk in the US makes noooo sense), there's a world of wonderful technology to explore, while learning the math that matters. y = mx + b. Turn m over for w, and b is for bias.[2] Kirby [1] http://www.4dsolutions.net/ocn/Jlang.html [2] https://www.google.com/search?q=mcdonalds+upside+down+w&safe=off&source=lnm… (recent meme)

2 3

generic objects (including lambdas) as dict keys?: not usually a problem
by kirby urner 20 Mar '18

20 Mar '18

I just discovered for myself what many must already know: lambda expressions may serve as dict keys (I knew values). That means they may partake of the mutability of some functions, in having mutable default parameter values. In [122]: d = {lambda x=[10]: print(x.append(11), x) : 3} In [123]: list(d.keys())[0]() None [10, 11] In [124]: list(d.keys())[0]() None [10, 11, 11] In [125]: list(d.keys())[0]() None [10, 11, 11, 11] In [126]: list(d.keys())[0]() None [10, 11, 11, 11, 11] That's not going to corrupt the dict though. In general, callable objects may serve as keys, with lambda expressions a special case. So what if the object points to mutable content. In [127]: class Callable: ...: def __init__(self): ...: self.the_list = [] ...: def __call__(self, *args): ...: self.the_list.extend(args) In [128]: obj = Callable() In [129]: the_dict = {obj : 3} In [130]: list(the_dict.keys())[0]("troll farm") In [131]: obj.__dict__ Out[131]: {'the_list': ['troll farm']} On the other hand, if you define __eq__ vis-a-vis something mutable, then the dict-maker will have 2nd thoughts about the viability of your enterprise. So nothing that earth-shaking. It's the Python we all know. Just thought I'd say hi. More soon. Kirby Urner Portland, OR

1 0

Online Python (and other scripts) debug tool (onlinegdb.com)
by Jurgis Pralgauskis 08 Mar '18

08 Mar '18

Nice for education purposes :) https://www.onlinegdb.com/blog/introducing-python-debugger-mode-with-pdb-co… -- Jurgis Pralgauskis tel: 8-616 77613; Don't worry, be happy and make things better ;) http://galvosukykla.lt

2 1