Mailman 3 February 2021 - 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

a "covid camp" specimen (online curriculum materials)
by kirby urner 31 Mar '21

31 Mar '21

A Python camp for teens stuck at home. [Exhibit](https://github.com/4dsolutions/python_camp/blob/master/README.md ) (work in progress)

3 2

good programing env features?
by Jurgis Pralgauskis 18 Feb '21

18 Feb '21

Hi, it not directly Py oriented -- but I think you have some hints :) We are trying to choose among programming envs for 5th graders: Scratch https://pencilcode.net https://edublocks.org MicroBit blocks Logo CodeMonkey and the discussions are a bit chaotic based on each ones experience... Maybe you know like 5 good aspects/categories to evaluate by? kind of like here, but may be more abstract https://github.com/aroberge/reeborg-howto/blob/master/src/checklist.md -- Jurgis Pralgauskis tel: 8-616 77613; Don't worry, be happy and make things better ;) https://galvosukykla.wordpress.com/

3 2

Re: Friendly-traceback: useful tool for those teaching Python
by kirby urner 09 Feb '21

09 Feb '21

Me: If I ask for type(__builtins__) I get a list of all the things dicts can do, not the contents of the module. Of course I should have said dir(__builtins__) above (not type). Anyway, I was glad to clear this up. I’m guessing the use of both __builtin__ and __builtins__ is not Spyder’s original idea, but characteristic of the I-Python console more generally. Indeed, my conda environment lets me ask for ipython directly at the bash shell and sure enough, it’s the same story. What about IDLE? Right, only __builtins__, no __builtin__. Kirby

1 0

Re: Friendly-traceback: useful tool for those teaching Python
by kirby urner 09 Feb '21

09 Feb '21

Andre: I think you mean simply __builtins__, without the dir(). I was puzzled by this remark at first but now I’m seeing why. When I boot into the Python shell directly from bash, and ask for the type of __builtins__ i.e. type(__builtins__), I get back that it’s a module. Then dir(__builtins__) lists the contents, of the module, same as dir(math) would do. However, if I’m in the Spyder IDE and ask for the type of __builtins__, I’m told it’s a dict. If I ask for type(__builtins__) I get a list of all the things dicts can do, not the contents of the module. Ah, but there’s more…in Spyder, I have not only __builtins__ but __builtin__ (singular), and the latter is a module that behaves like __builtins__ (plural) in the primitive shell. At the same time, the primitive shell doesn’t have a __builtin__, only __builtins__. Spyder has added complexity. I’m using the same version of Python (3.9) in both cases. Kirby

1 0

Friendly-traceback: useful tool for those teaching Python
by André Roberge 03 Feb '21

03 Feb '21

Hello everyone, For about 20 months now, I have been working on a Python package intended to help beginners figure out what went wrong when their program generates a traceback. This package is called Friendly-traceback; you can find the fairly extensive documentation at https://aroberge.github.io/friendly-traceback-docs/docs/html/ Friendly-traceback can be used to run programs from the command line, or from an editor; it also comes with its own REPL. Jupyter notebooks are also supported. While there is still much to be added to it (I don't know if I'll ever reach a "complete enough" version to be designated as version 1.0), I would appreciate feedback from those of you who teach beginners (or advanced beginners), including any suggestion as to how it could be made more useful. All the best and stay safe, André Roberge

3 5

Online introductory Python course
by Whipp, David M 02 Feb '21

02 Feb '21

Hi all, I’ve been silently following this mailing list for a few years now and wanted to share an online course that some colleagues and I have developed at the University of Helsinki, Finland. The course is intended for Bachelor’s and Master’s students in Geology and Geography, but introduces Python programming assuming no previous programming experience. In other words, it could likely be adapted for use by many different groups, even advanced high school students. All of the course lesson materials and exercises are available freely online (and in English), and you’re also most welcome to fork our GitHub repository with the course materials and adapt them for your use. Below are a few links you might find useful if you want to check it out. Course website: https://geo-python.github.io Course GitHub organisation: https://github.com/Geo-Python We’re also currently working on a textbook that builds on the basic Python materials and applies them to geographic data analysis. The book is expected to be published later this year or in early 2022. It will also be available online, and you’re welcome to check out the work in progress at https://python-gis-book.readthedocs.io/en/develop/. Just thought you folks might be interested, and if you have any questions or feedback on the course (and book), please feel free to contact us via email. Kind regards, Dave Whipp - david.whipp(a)helsinki.fi Henrikki Tenkanen - henrikki.tenkanen(a)aalto.fi Vuokko Heikinheimo - vuokko.heikinheimo(a)helsinki.fi -- David M. Whipp, Professor Institute of Seismology | Dept. of Geosciences and Geography | Univ. of Helsinki Seismologian instituutti | Geotieteiden ja maantieteen osasto | Helsingin yliopisto +358 (0)2 941 51617 | www.helsinki.fi/en/researchgroups/geodynamics | twitter.com/HUGeodynamics

3 5