Mailman 3 January 2019 - 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

Python in Education - Request for Ideas
by Ewa Jodlowska 31 Jan '19

31 Jan '19

The Python Software Foundation Board Committee for Python in Education wants to hear how the PSF can help members of our community increase the presence of Python in education. Our first goal is to gather ideas from the community on ways the PSF can fund work to improve Python in education. We want to collect a broad spectrum of ideas and projects at all levels and in all disciplines. After the ideas phase, we will use the ideas provided to guide our request for proposals. Timeline Here’s the full timeline: - January 23- February 18, 2019: Request for Ideas phase - February 18 - March 31, 2019: Request for Proposals phase - April 1-17, 2019: Review process - April 18, 2019: Notify the accepted proposals - June-August of 2019: Accepted proposal work begins Scope The scope of the “request for ideas” phase is vague on purpose. We do not want to steer the ideas brought forth and want to see a wide variety of pitches. Think small. If you had $100 USD what would you do? Think BIG! If you had $10,000,000 USD what would you do? There is no limit to the amount of money that your pitch might cost. If we think you have a great idea and it serves to improve Python in education, we will support it. Smaller requests will come from funds we have on hand. Larger funding requests will take more work to fulfill as we will work to gather funds through several methods such as donation drives and grants from other organizations. While the Request for Ideas is vague and open ended, there are some guidelines. These guidelines will come into play during the Request for Proposal phase, but they may help you in the Request for Ideas phase. Here are some things that we will look for and consider in a proposal: Basic requirements - The criteria for acceptance will be based on the following guidelines: - Does the proposal adhere to PSF’s Code of Conduct <https://www.python.org/psf/codeofconduct/>? - Does the proposal align with the Python Software Foundation’s mission <https://www.python.org/psf/mission/>? - Is the proposal well organized and detailed? Be sure to tell us what the main issue, problem, or subject is and why is it important. - Does the proposer have any experience relevant to the proposal? While not strictly a requirement, having previous experience in what is being proposed will be considered in the overall application. - Is the subject pertaining to underrepresented topics within our community? As we strive to improve the diversity of our community, priority will be given to proposals that bring new viewpoints and additional representation to the Python ecosystem. Advanced requirements - The proposal should include a timeline and capture major milestones for the work being proposed. - If the proposal includes assistance from other contributors/resources, please share the details. - The proposal should include the expected outcomes of proposed work as well as metrics for how the outcomes will be evaluated. Submit your ideas and questions to edu-committee(a)python.org. Please avoid attaching large files such as .zip files. It is preferred that you send a shareable link (e.g. via Dropbox). Thank you for your time and we look forward to seeing all of the wonderful ideas!

1 0

Python in Education: Requests for ideas
by Peter Farrell 30 Jan '19

30 Jan '19

Hi, Has anybody else been trying to submit ideas in response to the PSF's request from last week? The blog post is at http://pyfound.blogspot.com/2019/01/python-in-education-request-for-ideas.h… and the email is edu-committee(a)python.org I've had my email bounced back 4 times since Friday. Am I doing something wrong? Peter Farrell

3 4

making types matter (notes for beginners)
by kirby urner 29 Jan '19

29 Jan '19

In my on ramp to Python, for beginners, I find harping on "types" a great intro (if unoriginal -- a lot of us do it). For one thing, we can hold fixed to the "type" idea while changing the source of the type from built-in, to standard library module, to 3rd party -- three tiers in my "dimensions of Python". These dimensions are (again): * keywords and core syntax (punctuation symbols e.g. [ ] ( ) : etc.) * built-ins * __ribs__ (special names e.g. __getitem__) * standard library * 3rd party (or cloud, or ecosystem, most of what you write yourself) What I say about OO and types is: this was an attempt to mirror your natural language thinking in terms of things having type and thereby characteristics. Computer languages were reaching out to meet us half way, in our native context. "Easy to reason about" in proportion to one's having a strong sense of metaphor perhaps. Not self-proving. The datetime type is, like the string, great for escaping the vortex of "number types only" (where high school math teachers seem to wish to confine themselves for some reason, although this is not a limitation of maths). Many newcomers to programming expect incessant number crunching and languages that only care about numeric methods. That's a stereotype to smash early. Some types help us do that. I have a "permutation" type that's like a number in being very mathy, supports __mul__ and __invert__, but it's not a "number" type. https://repl.it/@kurner/Permutations (repl.it worth checking out if you haven't) datetime also persuades us to appreciate that others have dealt with the complexity. We get the fruits of their efforts. Calendar stuff is sooo... tedious? Not forgetting timezones and daylight savings time. It's a lot of useful machinery that used to stay locked away in temples. A good example of a 3rd party type? Actually there's a lot of 3rd party datetime stuff. Lets get back to number crunching why not? gmpy2 - Extended Precision Decimals. Very like decimals in Standard Library, which is great, for comparing and contrasting similar types. A strong focus on types right from the get go then helps explain the power of Python's 'class' keyword: Python lets you extend the type system with types of your own. That's the OO model after all (not at all unique to Python), and meant to mirror reality in some ways, a different goal then being "easy to reason about" (which is a holy grail as well -- it's not either/or). Example using of gmpy2 in a "learning Python" curriculum context: https://nbviewer.jupyter.org/github/4dsolutions/Python5/blob/master/S_Train… (more links from the bottom if wanting more of the same) The feature I want to emphasize is the results of decimal calculations mostly look like this: JB Icosa: 18.512295868219161196009899292654531923571426913640152615969 JB Cubocta: 20.000000000000000000000000000000000000000000000000000000000 SuperRT: 21.213203435596425732025330863145471178545078130654221097650 Not what you'd be seeing with a calculator (too precise). Not floating point numbers, clearly, in the sense of IEEE 754. I find extended precision types useful for inspiring students to developing that special and useful skill, of going from conventional sigma notation, to working programs using loops -- what sigmas stand for. Ramanujan had some doozies converging to Pi (or 1/Pi) or whatever. We've looked at those before on edu-sig. Example: https://github.com/4dsolutions/Python5/blob/master/Extended%20Precision.ipy… Kirby

2 4

Question about certifying teachers
by Charles Severance 25 Jan '19

25 Jan '19

Hi all, I am working with a group of college professors at small schools and developing a program to help them teach programming to non-programmers. One aspect of this is to provide training for the teachers. It might be cool to invent a certificate to give them after they complete training. I wonder if there is a common approach to issuing certificates to teachers as they do professional development and gain skills. This is in the USA and there might be several hundred teachers - it would not be worth creating a company to issue these certificates. It would be best if there was some general certificate approach and/or infrastructure that I could tap into. Thanks in advance. /Charles Severance

7 7

threads on teaching w/ jupyter (high school + France, Binder...)
by kirby urner 13 Jan '19

13 Jan '19

Contributors here might want to add to this discussion thread or bookmark it for the links: https://groups.google.com/d/topic/jupyter-education/2Cv7B3td9LA/discussion Overlaps our threads here quite a lot. Also, I've been getting into using Binder more, with my Jupyter Notebooks on Github. Here's another thread on that: https://groups.google.com/d/topic/jupyter-education/z9L4mTDyKsM/discussion OSCON 2019 submissions still open a few more days... hope to see some of you there. Good to see more PR for Math Adventures in Python out there. https://nostarch.com/mathadventures Kirby

1 0