Mailman 3 October 2015 - 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

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

"star alone" syntax
by kirby urner 27 Oct '15

27 Oct '15

Whew, glad to see email(a)python.org working again. It was out there for a few. The video below covers what I call "star alone" syntax: https://youtu.be/0TtHCK1q-Tg Errata: I spell some English words incorrectly, even though it's my first language. Sorry for the low rez, a tad fuzzy. Kirby

1 0

Opening up MicroPython on the BBC micro:bit
by Nicholas H.Tollervey 20 Oct '15

20 Oct '15

Hi Folks, Many apologies for cross posting. Here's some good news - we've finally been given permission to open-source our work on the BBC micro:bit (http://www.bbc.co.uk/mediacentre/mediapacks/microbit) and be a bit more vocal and public about what we're doing. Put simply, around 1 million of these devices will be given to the UK's 11yo in the spring. They are all capable of running Python. If you think the following is of interest, please spread the word! It'd be great to see the wider Python community get involved in this. Damien George (creator of MicroPython) announced it here: http://forum.micropython.org/viewtopic.php?f=8&t=1042 I've written up a "story so far" blog post, for those of you who need some context, here: http://ntoll.org/article/story-micropython-on-microbit The actual source code can be found here: https://github.com/bbcmicrobit/micropython I'm more than happy to answer any questions you may have. Best wishes, Nicholas.

1 0

bioinformatics?
by kirby urner 17 Oct '15

17 Oct '15

I don't think code like this is exactly what's meant by bioinformatics, which is more statistical in nature. However as a way of reinforcing both knowledge domain content and learning Python concepts, I think it has utility. If you're already familiar with some cell biology, this would be a useful way to hammer home Python. I tossed up a simple 7 minute Youtube on the code below, talking mostly about Inheritance & Composition in the OO sense. https://youtu.be/UoHJdQeYa8k (sound not so great, just using laptap microphone). I encourage others to do something more produced. Example usage: In [3]: the_cell = Eukaryote(0, 'GATACA') In [4]: the_cell.nucleus.dna Out[4]: ('GATACA', '') In [5]: the_cell.nucleus.dna[0] Out[5]: 'GATACA' In [6]: the_cell.S_phase() # this is when DNA replicates In [7]: the_cell.nucleus.dna # cell is now "mature" (ready to divide) Out[7]: ('GATACA', 'CTATGT') In [8]: new_cell = the_cell.divide() In [9]: new_cell.nucleus.dna Out[9]: ('GATACA', '') Related: https://mail.python.org/pipermail/edu-sig/2012-December/010709.html Kirby # -*- coding: utf-8 -*- """ Created on Sat Oct 10 12:02:55 2015 @author: Kirby Urner, MIT License """ class Mitochondrion: """Cell Battery""" pass class Golgi: """Router""" pass class Nucleus: """DNA Hut""" def __init__(self, dna_A): """Get half the DNA""" self.dna = dna_A, '' def mitosis(self): """Split DNA in two""" return self.dna[0], self.dna[1] class Cell: def __init__(self, gen=0): """Age""" self.gen = gen + 1 class Prokaryote(Cell): pass # won't have a nucleus class Eukaryote(Cell): def __init__(self, gen, dna): super().__init__(gen) # get older self.nucleus = Nucleus(dna) # store DNA self.organelles = [Golgi(), Mitochondrion()] self.mature = False def S_phase(self): """Make other half of DNA""" dna_B = [] dna_A = self.nucleus.dna[0] for base in dna_A: if base=='A': dna_B.append('T') elif base=='T': dna_B.append('A') elif base=='G': dna_B.append('C') elif base=='C': dna_B.append('G') dna_B = "".join(dna_B) self.nucleus.dna = (dna_A, dna_B) self.mature = True # I'm ready for sex! def divide(self): if not self.mature: # don't try it! raise ValueError dna_A, dna_B = self.nucleus.mitosis() new_cell = Eukaryote(self.gen, dna_A) # next generation of me self.gen += 1 # should be an upper limit self.nucleus.dna = '', dna_B self.mature = False return new_cell # spawn of me

1 1

Fwd: more PR for the __ribs__ mnemonic vis-a-vis "special names"
by kirby urner 11 Oct '15

11 Oct '15

Below: some followup from Google Plus, to my little videos. Joe Snyder is a retired veterinarian and fellow Friend (Quaker) whom I see at our Meeting ("church") sometimes. Here's a blog post with all three videos, for anyone interested: http://controlroom.blogspot.com/2015/10/pythons-ribs-special-names.html Also, I've been promoting edu-sig on python-cuba-wg, the connection being somewhat tenuous: when I held a competition around Python and generating Pi to a thousand places, way back in 2011, a student at University of Havana won. Now here we are in 2015, revisiting yet another way to converge to Pi, thanks to this generator we talked about last month. https://mail.python.org/pipermail/python-cuba/2015-October/000124.html Kirby ================ Joe Snyder Yesterday 1:51 PM So nice pictures, but I'm clueless about the lesson. Thanks for trying. Curious that after your presentation, it wants to show me a lot of yucky videos of various large snakes attacking and eating things. Hmmmm Kirby Urner 8:14 AM Yeah, Youtube tends to be sensationalist around snakes. The computer language was named for Monty Python (which was named for?). However, as shown, I take good advantage of snake anatomy by inventing __ribs__ as terminology for what in the language we call "special name" (they have this underline thing going, two __ on each side). The three videos, each < 5 mins, form a triptych. Maybe enlightenment will come somewhere in the middle. :-D https://youtu.be/lwDfvdUxuQc (special names) https://youtu.be/nOzMG-cPWnc (giving birth) https://youtu.be/9pxshtSJI8E (touching on inheritance) More depth: http://controlroom.blogspot.com/2015/10/integrated-learning.html Great to have an animal vet check my presentation on Python __ribs__, couldn't ask for a better form of peer review, even if it's hard to make head or tail, coming into it cold. (I was asked to audition by a commercial training provider: "Don't over-think it, type and talk at the same time, no editing". Having done one, I couldn't resist tying off some loose ends). On Sat, Oct 10, 2015 at 2:02 PM, kirby urner <kirby.urner(a)gmail.com> wrote: > > > A Youtube new this morning: > > https://youtu.be/lwDfvdUxuQc (4 mins 44 secs) > > Kirby > > > _______________________________________________ > Edu-sig mailing list > Edu-sig(a)python.org > https://mail.python.org/mailman/listinfo/edu-sig > >

1 0

more PR for the __ribs__ mnemonic vis-a-vis "special names"
by kirby urner 10 Oct '15

10 Oct '15

A Youtube new this morning: https://youtu.be/lwDfvdUxuQc (4 mins 44 secs) Kirby

1 0

more positive remarks re Fluent Python by L. Ramalho
by kirby urner 10 Oct '15

10 Oct '15

http://controlroom.blogspot.com/2015/10/integrated-learning.html -- twisting together my usual themes. :-D Kirby

1 0

Free 'Intro to Python' talk offer to PPS
by kirby urner 06 Oct '15

06 Oct '15

Although full time employed with benefits, my hours are shifting such that I'm making more room during the day (I've done this before). In the run-up to PyCon, I want to put it out there that I'd be happy to drive to any Portland Public School and do a free talk on Python, to whatever mix of faculty + admin + students. *Resume*: former HS teacher (maths / history / honors philo ) Portland User Group organizer PSF voting member Full Time Python mentor for O'Reilly Had two daughters enrolled in PPS through HS Taught Python as volunteer to 8th graders @ Winterhaven PPS for some weeks Yes, I know, I should share this offer with PPS directly... so this is my way of creating something to link to. Others may want to jump in as willing 'Intro to Python' talk givers. Other audiences besides PPS would be totally viable, I'm just trying to limit my scope to stay sane. :-D Kirby

1 0

Re: [Edu-sig] Research on best language to use for teaching beginners
by Andrew Harrington 03 Oct '15

03 Oct '15

Look at page 19 on how the loop syntax was used! It was used just for "repeat n times" - really simple, (and with a trivial useless loop body). "while" is for a more complicated situation (in general) where there the number of repetitions is controlled by a significant and flexible condition. Such loops (particularly with code to prepare for the next time through the loop) are likely the most difficult for my students to understand, but I am not convinced that it is because of the word keyword used, but just because of the more complicated real situation. Also the keywords were not tested when a definite collection of objects was being iterated over, as opposed to a simple repetition or an artificial sequence created just to repeat. Then foreach sounds like a clear winner, likely somewhat better than to shorter Python "for". "while" and "for" require complicated additional syntax if you just want "repeat n times". The question then becomes whether adding special syntax for a simple repetition complicates the overall learning situation more than sticking with fewer keywords and depending on flexible synthesis, like using "for" with "range" in Python. This is the only thing I get out of the looping section of the article. I find the table very misleading. Dr. Andrew N. Harrington Computer Science Department Graduate Program Director gpd(a)cs.luc.edu Loyola University Chicago 529 Lewis Towers, 111 E. Pearson St. (Downtown) 417 Cudahy Science Hall (Rogers Park campus) http://www.cs.luc.edu/~anh Phone: 312-915-7982 Fax: 312-915-7998 aharrin(a)luc.edu (as professor, not gpd role) On Fri, Oct 2, 2015 at 9:02 AM, David Handy <david(a)handysoftware.com> wrote: > On Thursday, October 1, 2015 4:50pm, "Andre Roberge" < > andre.roberge(a)gmail.com> said: > > > ... > > > The best keywords (combining result from the two groups) are thought to > include: repeat, again, loop, cycle > The worst keywords are thought to include: foreach, while, echo, > duplicate, for .... with "for" getting the worst result of all. > Now that you mention it, I have hazy memories from > 30 years ago, when I > was learning BASIC, of puzzling over the meaning of the FOR keyword and > wondering why they chose that word. So I'm not surprised to see that on the > list of difficult keywords. > However, the WHILE keyword in BASIC was intuitive for me. So it surprises > me to see that on their list of bad keywords. > David H >

4 4