Mailman 3 December 2016 - 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 03 Dec '22

03 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

Python Physics Sandbox released
by Jay Shaffstall 12 Jan '17

12 Jan '17

I'm very pleased to announce the general release of a Python physics sandbox targeting students in intro programming courses. We teach Python as a first language here and a physics simulation has long been one of the students' favorite labs. But the simulation we were using, while easy to use, was pretty limited and only worked in one particular IDE. So I wrote PyPhysicsSandbox, a thin wrapper around pymunk. The sandbox allows students to construct more sophisticated combinations of shapes and joints and interactivity with the user. It should also work in any environment that allows installing libraries to Python using pip. The code lives here: https://github.com/jshaffstall/PyPhysicsSandbox It's freely available for use in your own classes. Jay

3 8

Submit talks for Python Education Summit: Jan 3rd deadline
by Chalmer Lowe 31 Dec '16

31 Dec '16

Do you teach? Do you Python? The deadline to submit your talk proposal to speak at the Python Education Summit is on January 3rd. More details on the submission process here: http://bit.ly/2hxv4HO We can't wait to hear what works (and what doesn't) in teaching Python, whether you teach in a classroom or teach through the written word. Join us for an awesome day full of Python AND Education with educators from around the world @ the annual Pycon Conference. Respectfully, Chalmer | Jessica | Meenal | Ria -- Chalmer Lowe, MS PyHawaii Dark Art of Coding Booz Allen Hamilton

1 0

Re: [Edu-sig] Edu-sig Digest, Vol 161, Issue 9
by Marianne McKenna 29 Dec '16

29 Dec '16

I am currently out of the office. If you need help, please contact building tech support. If it's an immediate need, please contact Paul Musto or Patty Hunter. I will respond to your email as soon as I am able. Thanks

1 0

PyCharm Edu courses
by Jurgis Pralgauskis 22 Dec '16

22 Dec '16

Hi, Seems nteresting concept: https://www.jetbrains.com/pycharm-edu/concepts/ as you can also publish the course https://www.jetbrains.com/pycharm-edu/quickstart/getting_started_educators.… Standart courses are opensource: https://github.com/JetBrains/pycharm-courses/ -- Jurgis Pralgauskis tel: 8-616 77613; Don't worry, be happy and make things better ;) http://galvosukykla.lt

1 0

the Descriptor pattern (new wrinkle in 3.6+)
by kirby urner 19 Dec '16

19 Dec '16

What I like about staying the course on the 3.x track (versus adhering to the 2.7 terminus of the 2.x line), is each new version is an opportunity to catch up on features that have joined over several versions. My capacity to catch up inevitably lags the actual path of Python's evolution, not a tragedy, an opportunity. For example, I've recently pushed a lot more into Descriptor territory and in my last class for adults, spent time with a Python source code implementation of the property callable. As a built-in, it's written in C, however what it does may be modeled in pure Python. You may be familiar with this passage. Here's a Jupyter Notebook: https://github.com/4dsolutions/Python5/blob/master/Descriptors%20and%20Prop… The Property class is what's critical. I then use it to decorate code in other modules, proving that the pure Python class and the builtin do the same work. I've shared my "Prop Circle" before (since adding circumference, the logical next step): """ Created on Thu Oct 20 15:43:14 2016 Modified Wed Dec 7, 2016 @author: Kirby Urner Related reading: https://mail.python.org/pipermail/edu-sig/2016-October/011548.html """ from model_property import Property as property import math class Circle: """setting either the radius or area attribute sets the other as a dependent value. Initialized with radius only, unit circle by default. """ def __init__(self, radius = 1): self.radius = radius @property def area(self): return self._area @property def radius(self): return self._radius @property def circumference(self): return self._circum @circumference.setter def circumference(self, value): self.radius = value / (2 * math.pi) @area.setter def area(self, value): self._area = value self._radius = math.sqrt(self._area / math.pi) self._circum = 2 * math.pi * self._radius @radius.setter def radius(self, value): self._radius = value self._area = math.pi * (self._radius ** 2) self._circum = 2 * math.pi * self._radius def __repr__(self): return "Circle(radius = {})".format(self.radius) # Circle may be imported from prop_circle without all this noise. if __name__ == "__main__": the_circle = Circle(5) print("the_circle:", the_circle) print("Area: ", the_circle.area) the_circle.area = 50 print("Radius when Area=50:", the_circle.radius) I'm also experimenting with new namepaces for terminology, though in general I'm quite happy with the Python lingo. A Descriptor is this miniature unit of bookkeeping, wherein reading and writing operations, also being named at birth, register within the guts of the thing, triggering __set__ and __get__ (and now __set_name__). What if I use the word "Clerk" for "Descriptor" in some passages, and picture something Monty Pythonesque from a Charles Dickens like milieu. For a specific Lesson Plan, such imagery might reinforce comprehension of design pattern possibilities. A class (type) may wish to contract out come of its attributes to this professional bookkeeping class, called a Clerk, actually a Descriptor, that has reprogrammable behavior around setting and getting a value. Introduce these to your own classes as class-level inclusions if you wish. Compose, don't subclass. Don't worry though: when these clerk-monitored attributes are actually used by your instances, that instance will be a known object, passed in to the Clerk, and usable as part of a key to keep values specific to where they came from right down to the instance level. IF that's your goal. Blog post that's more casual, with some screen shots showing source code. http://controlroom.blogspot.com/2016/12/back-on-that-python-train.html Kirby

1 0

learning python the "best" way... (end of year overview)
by kirby urner 15 Dec '16

15 Dec '16

At the PDX Code Guild, which has a Monday night Flying Circus event, which I've been frequenting -- though not in the last five weeks as my teaching gig was Mon / Weds -- I hear quite a few geeks say they've been studying Learning Python the Hard Way by Zed Shaw. I finally took a look at the on-line version yesterday and notice he's very adamant about learning 2.7, not 3.x. Disappointing. Maybe he's working on the 3.x version. Zed does give a lot of fabulous advice about techniques for learning, emphasizing the importance of the hands-on practicum. Just watching videos gives only casual knowledge. To get it in your bones, you need to write code, learn by doing. He also talks about the importance of sleep and even dreams when it comes to gaining new skills. "Day dream and doodle in code" is advice I give my own students. I also encourage writing deliberately "demented" code when learning, to focus on corner cases. Update about me: In addition to teaching Python to adults (night school gig), I'm an instructor- -in-training with Coding With Kids (CwK), which provides right-after-school coding classes, with one Chromebook per child (work is saved in the cloud). Working with kids means diving into Scratch again, as our Python students tend to come with a Scratch background (what CwK uses with the younger kids, not that adults can't have fun with Scratch; it's quite engaging as many on edu-sig already well know. A path I'd recommend (one of many): Mark Pilgrim's Dive Into Python 3 http://www.diveintopython3.net/ Allen Downey's Think Python (2nd edition) http://greenteapress.com/wp/think-python-2e/ John Zelle's excellent book is out in a 3rd edition: http://mcsp.wartburg.edu/zelle/python/ for beginner to intermediate, followed by Luciano Ramahlo's Fluent Python for more advanced concepts (e.g. coroutines and asyncio). I introduce Jupyter Notebooks pretty early when working with adults. Then it's time to branch out into more specialized interests i.e. knowledge domains e.g. mathematics with Amit Saha or Peter Farell, or Litvins (I've got math stuff online, some of it even more specialized to spatial geometry meaning lots of Visual Python). Or physics, or bioinformatics, or stats or web apps or... Pymunk sure looks fun. Geeks coming through Flying Circus on Mondays are into all kinds of weird things; I've missed being at the meetups. I'm going to a Hanukkah Party this Monday now that my night gig is over until January, then lets hope I get to Flying Circus again the day after Christmas. Happy New Year everyone. Kirby Urner 4Dsolutions.net /ocn/cp4e.html

2 2

snap shot from a random Python course (in vitro)
by kirby urner 06 Dec '16

06 Dec '16

I sorta flubbed showing 'em how functions preserve state between calls in their default parameter values. Tried to do it on the fly. But it all worked out, a "teach me" moment (a student helped in the chat window). I talk about this in my lead-up to generators / coroutines (I cover send) in that we usually think of functions folding their tents and forgetting all state between calls, forgetting about this corner case, which I covered for the Hubble folks at STSCI (thanks again for the opportunity). Otherwise a smooth class. I have this "grand unification" segment in Session 07 where they know decorators, and then they know context managers (__enter__, __exit__), then generators as a kind of iterator (__iter__, __next__). Then right away, while the iron is still hot, we use a decorator to turn a generator into a context manager! I have this castle_game.py and castle_game2.py that do the same "can you guess the keyword?" game, the second version employing the decorated generator version of the quiz. Could be the epiphany of a pythonic lifetime (about 10 minutes? -- much shorter than a dog year). Thanks for covering all that in your Advanced Python (OST -- course material still on-line [1]). There's more stuff in contextlib I want to study before tomorrow night. I like smoothing the edges of new concepts with more context from Standard Library. For example after generators, we tour in itertools, scrolling through the docs, getting the flavor of what's there, me the babbling tour guide... See you in 2017. Kirby Cc: edu-sig Archive [1] http://archive.oreilly.com/oreillyschool/courses/courses.html#course_id_158 On Tue, Dec 6, 2016 at 8:50 AM, Steve Holden <steve(a)holdenweb.com> wrote: > That sounds like it could be fun - put me down! S > > Steve Holden > > On Tue, Dec 6, 2016 at 4:20 PM, kirby urner <kirby.urner(a)gmail.com> wrote: > >> >> Just signed up to teach Jan 17 - Feb 16-17, Tue/Thur. I that's a night >> you're in Portland, maybe you can co-star on that show (I run 6-10:30 PM). >> >> Kirby >> >> >

1 0