Mailman 3 September 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

The making of a great Education Summit
by Jeff Elkner 30 Sep '18

30 Sep '18

Dear fellow EDU Pythonistas, The Education Summit this year is shaping up to be wonderful: https://us.pycon.org/2019/speaking/education-summit/ I just wanted to let folks know. Jeff Elkner Arlington Career Center Let's work together to create a just and sustainable world!

1 0

Two Jupyter Notebook exhibits
by kirby urner 27 Sep '18

27 Sep '18

I'm on a listserv where colleges and universities compare notes for using nbgrader, while serving Jupyter Notebooks locally, as part of the curriculum delivery architecture. My way of sharing is less cloud-based in that I invite students to run the course notebooks locally, each booting to localhost:8888 using the JN server that comes with Anaconda. Or install with pip. They're getting me live, closed circuit, and we're able to discuss the materials in real time with no central server, other than shared Github repos and a course Google Drive. The difference is I'm not grading. There's no requirement to turn stuff in, just optional workouts during the tutorials. More like at a Pycon or OSCON. Steve Holden was showing me JNs long before now, and I'm still far from expert. I appreciate them for many reasons, not the least of which is supporting LaTeX. The technology is also a meeting ground for folks from many walks of life, given how the back end kernel need no longer be only Python. I'm able to compare Python directly with JavaScript, in the same notebook (such comparisons are worth making [1]). === Two exhibits: This first one is from just this morning. A Facebook friend has found a numeric pattern, and what I see is an excuse to: 1) practice some LaTeX 2) show off Python generators 3) show off unittest 4) share about "evil" eval The Decimal class does not support trig, so I'm not in a position to use it as I did in the case of verifying the cited Ramanujan expression for 1/pi. https://github.com/4dsolutions/Python5/blob/master/VerifyArctan.ipynb The second: Graphene & Quadrays is about using an obscure Vector class to create a hex grid or hex mesh, written out by Python in Scene Description Language, and changing to XYZ only at this last opportunity. POV-Ray (free open source, povray.org) doesn't understand about Quadrays. However my algorithm for generating the mesh depends on the Python set type and its ability to prevent duplicates, especially when the set members are all 4-tuples of integers. Floating point numbers get fuzzy and create false negatives i.e. they're treated as different when they're not. All integer coordinates do not suffer from this deficiency. Lots more about Quadrays in my repo, or see Wikipedia. [ I'm not saying XY coordinates cannot be overlaid on a grid of hexagons in clever ways. Many people have contributed nifty hex grid algorithms. I'm just showing another application for a coordinate system almost no one has ever heard of. I enjoy sharing esoterica.[2] ] Quadrays assign integer coordinates not only to hexagonal mesh points, but to the volume-filling equivalent FCC (=CCP) = rhombic dodecahedrons space-filling matrix. I take that up in a connected Notebook. [3] https://github.com/4dsolutions/Python5/blob/master/GrapheneWithQrays.ipynb ==== ENDNOTES [1] https://medium.com/@kirbyurner/as-a-python-instructor-i-tend-to-recommend-a… [2] https://www.redblobgames.com/grids/hexagons/ is an authoritative website on the topic. [3] https://github.com/4dsolutions/Python5/blob/master/Generating%20the%20FCC.i…

1 0

REQ: HOWTO mailing lists resources
by Wes Turner 25 Sep '18

25 Sep '18

What are some good resources for learning how to mailing list? Was: "Re: [Edu-sig] Python teacher notes, preparing for class..." On Thursday, August 30, 2018, Wes Turner <wes.turner(a)gmail.com> wrote: > Mailing list tips and tricks, PEPs, Write the Docs > > Since you asked, although this isn't in scope of the original subject > line, and since I'd like to just continue this thread instead of breaking > the thread by changing the subject line, and since this isn't technically > OT (off-topic) in the interest of conversing toward an objective, here I've > added a first-line summary of this message. I should probably change the > subject and start a new thread. > > You can search mailing lists in a number of ways: > > - Google search with "site:mail.python.org" and/or "inurl:" queries > https://www.google.com/search?q=site%3Amail.python.org > (inurl doesn't match mm3-migrated lists too) > > - Google Groups, if the list is set up there too > > - Gmail "list:python.org" queries > - This doesn't find messages that you didn't receive because you weren't > subscribed yet. > > - "from:list@mail.python.org" queries > - This doesn't find messages that you didn't receive because you weren't > subscribed yet. > > - Markmail "list:org.python.edu-sig" queries > https://markmail.org/search/?q=list%3Aorg.python > https://markmail.org/search/?q=list%3Aorg.python.edu-sig > > The Python mailing lists aren't yet all upgraded to mailman 3 (/mm3/ > URLs); so some lists have the classic mailman archive interface (where "by > thread" breaks at the month boundary, for example) and upgraded lists have > the new Django-based HyperKitty interface with e.g. search and a full > thread view. > > With mm3, it's also possible to reply to threads you didn't receive > because you weren't subscribed at the time. > > e.g. -- for example > i.e. -- that is > (List of acronyms OTOH/OTOMH) > > Reply-all is unnecessary, but often helpful. If you just click reply, it > may be addressed off-list to only the sender (and not the list email > address, which is what you want if you want the mailing list app to archive > for and relay the message to every subscriber). If that happens, you (or > the recipient) can forward the message to the list, but it'll be > unnecessarily quote-indented unless you just copy and paste (which can be > lossy with HTML quote indents inferred from plaintext-quoted lines that > start with '>'), so it pays to verify the to: field before you start > composing a message. > > Some old hands argue for like 72 character fixed width messages so that > when they're n-levels quote-indented, they still fit on an 80 character > terminal without rewrapping. Old-school email clients like mutt, for > example, can handle this; > though, on a phone, fixed width hard-broken lines > wrap like > this sometimes; which is not as easy to read. > > TL;DR (too long; didn't read) is an acronym of Reddit; though the standard > form of intro summary, body, conclusion summary is equally helpful for > long-form mailing list posts. Many email clients show the first part of the > first line of the message after the overly-long narrowly descriptive > subject line that doesn't actually describe the scope of the discussion > anymore. > > For Python features, the ultimate objective is to write or develop a PEP. > There is a PEP template here: > https://www.python.org/dev/peps/pep-0012/ > https://github.com/python/peps/blob/master/pep-0012.rst > > PEP 1 explains PEPs: > "PEP 1 -- PEP Purpose and Guidelines" > https://www.python.org/dev/peps/pep-0001/ > https://github.com/python/peps/blob/master/pep-0001.txt > > PEPs must be justified (as indicated by the Rationale heading in the PEP > template); so starting with a justification is a good approach to arguing > that you need the whole list's time before you spend your precious time > writing an actual PEP like actual contributors do sometimes (when they're > getting actual work done). > > Bug and issue discussions are for the issue tracker (Roundup), though > sometimes it's a really good idea to ask a list for help and feedback. > > Mailing lists don't support ReStructuredText, but docs, docstrings, and > PEPs do; so it's perfectly reasonable -- even advisable, though not at all > strictly necessary -- to format mailing list messages that would be helpful > for those purposes in reStructuredText from the start. By the time you've > added RST setext headings, you might as well be collaboratively drafting a > PEP. > > Though it doesn't happen nearly frequently enough, it's often really > helpful to update the docs with wisdom culled from the mailing lists (and > Q&A sites which have labels). > > "6. Helping with Documentation¶" > https://devguide.python.org/docquality/ > > "7. Documenting Python¶" > https://devguide.python.org/documenting/ > > The ultimate source of Python documentation (an often-cited strength of > Python as a language choice): > https://github.com/python/cpython/tree/master/Doc > > "16. Accepting Pull Requests¶" > https://devguide.python.org/committing/ > > > > On Thursday, August 30, 2018, Wes Turner <wes.turner(a)gmail.com> wrote: > >> >> >> On Thursday, August 30, 2018, kirby urner <kirby.urner(a)gmail.com> wrote: >>> >>> >>> Thanks. Yes, I'll add some links to the docs as you suggest. Great >>> feedback! >>> >> >> Glad to be helpful. >> >> I've trimmed out the text I'm not replying to and tried to use plaintext >> only in order to: make sure the thread stays below the 40K limit, and make >> it easy to reply inline without breaking HTML tags. >> >> >>> >>> Actually as part of my class I'm showing them edu-sig and other >>> python.org lists, so we were actually viewing this conversation. I'll >>> extend that to showing your corrections, as I want to demonstrate how the >>> Python community all teaches each other, is friendly and so on. >>> >> >> Code review with pull requests / merge requests and GitHub, Gerrit, >> GitLab etc is an essential skill. >> >> Src: https://github.com/jupyter/nbdime >> Docs: https://nbdime.readthedocs.io/ >> >> > nbdime provides tools for diffing and merging of Jupyter Notebooks. >> >> There are a number of real-time collaborative platforms for working with >> notebooks (CoCalc, Colab, ) >> >> https://hypothes.is highlights and annotations work on anything with a >> URL, are threaded, and support Markdown. >> >> >>> >>> Kirby >>> >>>

2 6

Editors/IDEs for teaching
by Andre Roberge 14 Sep '18

14 Sep '18

Hi everyone, I'm compiling a list of available editors for Python designed specifically for teaching, with information about the primary targeted audiences and would welcome your comments and/or suggestions for additions or corrections. So far, I have Target audience (my own draft definition; feel free to improve upon this): * young learners (elementary and high school students) * hobbyists - beginners of all ages learning on their own * CS 100 course: elective course targeted at non CS (or even non STEM) students. The focus is more on concepts, using Python as the practical tool to learn these concepts, rather than learning the Pythonic idioms or learning the effectiveness of various algorithms. For example, list comprehensions would likely not be covered in such a course as it does not add anything conceptually to an explicit for loop. * CS 101 course: core course in CS meant as a requirement for future courses. Some pythonic idioms and details about algorithms would likely be covered. Editors / IDEs : * IDLE: included with Python. Intended for everyone. * Mu (https://codewith.mu/). Primarily intended for young learners and hobbyists. * Thonny. (http://thonny.org/) I am guessing that it is primarily intended for CS 101. * Wing 101 (https://wingware.com/downloads/wingide-101) Primarily intended for CS 101. * PyCharm Edu (https://www.jetbrains.com/pycharm-edu/) Primarily intended for CS 101. I am not looking for web-based solutions [otherwise, I would have had included Reeborg's World ;-)] and do not want to include obsolete or no longer maintained software (like rur-ple, the precursor to Reeborg's World.) Best, André

9 19

Re: [Edu-sig] Edu-sig Digest, Vol 181, Issue 4
by Kent Tong 09 Sep '18

09 Sep '18

Hi Stephen Much to my surprise, my 10-year-old student figured out how to do recursion even before I told them to and wrote the code below, which puts the mole at (1, 1) when button 1 is clicked, waits 1 second, executes the code in box 2. In box 2, the code puts the mole at (2, 2), waits 1 second and then execute the code in box 1. [image: image.png] --- Kent Tong Yes! Kids can learn Python. Free chapters and learning environment at https://www.istudycenter.org/yes-kids-can-learn-python

1 0

Python Code snippets for Irish second level students
by Stephen Murphy 07 Sep '18

07 Sep '18

Hello all, My name is Stephen Murphy from the Republic of Ireland. In November last year I founded the Computer Science Teachers’ Association of Ireland. I have recently published the first edition of the CSTAI magazine: Ré na Ríomheolas (link below) https://tinyurl.com/ReNaRiomh1 <https://www.google.com/url?q=https://tinyurl.com/ReNaRiomh1&sa=D&ust=153635…> In addition to the articles, I also include a section on code snippets that might be useful for second level teachers and students. If anyone has any ideas about little bits of interesting code, I would be delighted if you could send them to me with a little explanation of what the code does and what it is used for. Best wishes, Stephen

1 0

multiple inheritance and method resolution order
by kirby urner 07 Sep '18

07 Sep '18

I have a standard exercise in sharing Python's data structures, wherein I bury the string "Waldo" in some deeply nested object, say as an element in a tuple in a dict in a list... to some demented level.[1] When we're learning Python grammar, that's when "demented" makes sense i.e. this isn't about writing production code so much as getting the basic principles. Along similar lines, when introducing super() and the method resolution order, I'm often looking for a class hierarchy that (A) involves multiple inheritance, (B) is several levels deep and (C) has "diamond patterns". Finally it hit me: I could turn to the Book of Genesis for a family tree with all these features, plus the advantage of being easy to lookup. Adam and Eve had several kids (they lived enormously long lives by today's standards), and the siblings had to have kids by each other given they were the only humans on the planet. Adam and Eve's son Seth and daughter Azura (two cases of multiple inheritance), had a son (another case). Also, Noah's mom goes back to a great grandparent shared with his dad. Diamond pattern. Eureka. There's already some precedent in mixing CS with bible studies (thinking of Knuth), and besides, Python is heavily used in the humanities for natural language processing. Bridging from Python to Genesis doesn't seem too far-fetched. :-D http://nbviewer.jupyter.org/github/4dsolutions/SAISOFT/blob/master/OO_Parad… (see "Multiple Inheritance") There "where's Waldo" exercise and this investigation into the MRO may be combined: bury a waldo() instance or class method somewhere in the Genesis family try, in a couple places and go: >>> subject = Noah() >>> subject.waldo() to find out where the name resolves. Have the waldo method report on its class. Kirby Cross reference to connected edu-sig topic: Rich Data Structures [1] Example code: # -*- coding: utf-8 -*- """ Created on Mon Apr 17 17:23:45 2017 @author: Kirby Urner Example of the "Where's Waldo" genre: https://i.ytimg.com/vi/SiYrSYd7mlc/maxresdefault.jpg Extract "Waldo" from each data structure """ data = {"id:":["Joe", "Smith"], "mother": ["Judy", "Smith"], "father": ["Waldo", "Smith"]} waldo = "???" # output "Waldo" print(waldo) #============================ data = {"Waldo": {"scores":[34,56,23,98,89]}} waldo = "???" # output "Waldo" hint: dict.keys() print(waldo) #============================ data = {(1,2):{"Name":["Waldeen", "Smith"]}, (4,5):{"Name":["Waldorf", "Smith"]}, (9,0):{"Name":["Waldo", "Smith"]}} waldo = "???" # output "Waldo" hint: tuples may be keys print(waldo) #============================ data = ["Joe", 3, 7, ["dog", ("cat", "Waldo")], 27, {}] waldo = "???" print(waldo) # output "Waldo' #============================ data = ([], [], ()) data[1].append("Wendy") data[1].append("Waldo") data[1].append("Willow") # where's Waldo? waldo = "???" # <your answer> print(waldo) # NOW MAKE UP SOME OF YOUR OWN!

1 1

training materials and learning environment for teaching kids python available
by Kent Tong 05 Sep '18

05 Sep '18

Hi all, This is a set of training materials I used to successfully teach Python to kids as little as 10 years old. It was a success because the kids didn't just finish the course, they independently completed most of the coding challenges by applying the knowledge they had learned. The first four lessons and a lite version of the learning environment are freely available at: https://www.istudycenter.org/yes-kids-can-learn-python Let me know your ideas.

2 1