Mailman 3 June 2014 - Edu-sig

a short essay about programming
by kirby urner Dec. 8, 2022

Dec. 8, 2022

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

Re: [Edu-sig] Getting more involved with education and the PSF...
by Jeff Elkner Jan. 9, 2015

Jan. 9, 2015

Two questions: 1. Andre, what do I need to do to begin maintaining that page? 2. Is there anyone in this thread not on edu-sig? My next reply will go only to the list. On Thu, May 22, 2014 at 10:09 AM, Jessica Nickel <jessanickel(a)gmail.com> wrote: > Sounds like a plan. I would be happy to talk with Selena about the work to > bridge the gap between k-12 educators and Python programmers. I was a k-12 > teacher for 10 years (music) and I have been working in schools with my > program to teach python coding to kids for the past year and a half, so I do > have some experience in that area. > > > > > On Thu, May 22, 2014 at 10:02 AM, Jeff Elkner <jeff(a)elkner.net> wrote: >> >> Great! So it seems we have two short term goals: >> >> 1. Get someone to agree to maintain the website (I'm volunteering if >> there isn't anyone else chomping at the bit to do it). >> 2. Reach out to Selena Deckelman to help her with her efforts to >> bridge the gap between developers and K-12 teachers (a noble goal >> indeed!). >> >> Do we agree that edu-sig is the sensible place to hold this conversation? >> >> If we do, can we ask Selena to join the list if she is not already >> there? I'll also encourage folks like Lee Harr (cc'd here), the >> creator of the wonderful Pynguin environment >> (https://code.google.com/p/pynguin/) to join the list and the >> discussion. >> >> On Thu, May 22, 2014 at 8:01 AM, Naomi Ceder <naomi.ceder(a)gmail.com> >> wrote: >> > One point of info I can add - the person you're thinking of running for >> > PSF >> > board is Selena Deckelman, who was on Nate's panel at the edu summit. >> > She's >> > been very into bridging the gap between developers and K-12 teachers. >> > >> > Naomi > >

6 14

More about Internationalization (i18n) / Unicode
by kirby urner June 30, 2014

June 30, 2014

I've been fostering debate around work about i18n ("internationalization") a tried and true topic in Geek World bar none, and otherwise known, paradoxically, as "localization" as in "make all these Ubuntu menus appear in the Basque language." I remember being in Lithuania and booting up Blogger, to find my control panel in Lithuanian. Cool! We're brainstorming a promo / commercial for OST (oreillyschool.com) harvesting footage at OSCON, where I'm suggesting a mostly non-English sound track with students bragging about the jobs they got or the skills they learned from our courses + mentors, in various non-English languages. "Mostly non-English" is likely way too radical to make the final cut as a story-board for this promo (maybe another one), but I do hope we'll have at least some soundtrack in fluent Russian, with sub-titles added later. Why? Because the two alumni / active students I've recruited for the promo, are fluent Russian speakers, so duh, right? But zoom out and here's the bigger debate: should we think of English as the language of instruction or more just an important language for documentation? It's an important decision. In the latter case, it would be important to have our Python track materials in fluent Portuguese, including of course the source code, ditto in China we would use mostly Chinese. However, the docstring APIs in the Standard Library would stay as they are. The Standard Library is to remain in English. So I'm all for keeping it straight Python 3.4.1 or whatever, i.e. I don't want to have truck with these "replace the keywords" versions, because we want to standardize on Python.org distros, known to be best. Your viability in the job market depends on not being too specialized. In the former case (English as the language of instruction), we go for "dumbed down" or "for dummies" English ala Business English (BE) as the one and only language of instruction and make that a per-requisite for our computer courses. Mentors such as myself need only know BE and we'll be able to do our jobs. That's true now in fact, but not because of any decision or ideology, simply because of geography and history. The school grew up in the corn fields of Illinois. Only now are we experiencing the ripple effects of globalization / Unicode / cosmopolitan best practices. We could very well hire a native Chinese-speaking counter-part for my Python teaching job tomorrow, but then we'd have to launch a new version of the text as well, by either the current author (Steve Holden) in translation, or by someone equally well versed in Python. Usually translations lose something don't you think? Maybe a friend of Steve's who writes in her or his own voice would be the ideal candidate. Anyway, it's not like we have to settle this debate right away. I think many colleges and universities are looking at the same issue. I invite others to jump in with their musings. What's you long range forecast of how things will go? Case in point: Portland State works with a sister campus abroad (Fudan University) where many of the courses are in Chinese, naturally, and yet videos of US English-speaking professors -- e.g. my friend Allen Taylor, author of 'SQL for Dummies' and an electronics engineer -- are included in for-credit English language courses as well, so it's a mix. Allen is a very skilled teacher (I've been to many of his talks) and lectures on cruise ships these days. Having him on video in China is not a waste of anyone's time, if they have the skills to follow, and many Chinese do.[1] My point: a heterogeneous environment is what I expect, with many students pursuing their areas of concentration using two or three human languages, actually the standard for an educated person going way back. I don't expect a mono-lingual future and don't see why anyone would. Obviously, Unicode was / is a huge undertaking and we're only beginning to reap the rewards of this investment. One of those rewards is the ability to break free of the limitations of ASCII's 127 and later Latin-1's 256+. We're ready for the millions of characters that comprise our heritage. I, for one, am looking forward to the diversity that brings to our Python community. Carl Trachte and I have been focusing on i18n within the Python community for some time now.[2] Kirby [1] http://worldgame.blogspot.com/2005/01/shanghai-city.html [2] http://pyright.blogspot.com/search?q=unicode

1 0

Changes to edu-sig web page...
by Jeff Elkner June 17, 2014

June 17, 2014

I spent much of the National Day of Civic Hacking working on our web page: https://www.python.org/community/sigs/current/edu-sig The main task was fixing broken links. I believe I got them all, but please let me know if I missed any. I added two links that Philip Guo sent me, and I also added a link to Pynguin. I had to remove content that could no longer be found. Jeff Elkner

5 8

The THIRD PyconUK 2014 Education track
by Nicholas H.Tollervey June 17, 2014

June 17, 2014

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear All, Yup, it's coming up to that time of year again... http://pyconuk.org/education Please tweet, retweet, blog, post, talk about and generally spread the word - ESPECIALLY IF YOU'RE IN THE UK! We'll have around 40 teachers attending the professional training day (20 of whom will be student or newly qualified teachers sponsored by our wonderful PSF) and up to 60 kids turning up for some inspiring explorations in code the following day. We have the Raspberry Pi Foundation sending their education team, various "master" teachers giving workshops and, of course, hordes of enthusiastic Pythonistas. We'll even have a Robot Python Code Dojo where we'll get our hands on seven of these little critters to "hack" along with teachers: https://en.wikipedia.org/wiki/Nao_%28robot%29 (The kids will get to play with them too.) That's far too much fun, learning, coding and networking for just 48 hours out of the four day PyconUK conference. If you're about, please do come. You'll be made more than welcome! Phew. :-) N. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJToFVnAAoJEP0qBPaYQbb6vS8H/2or6J/wP0zmIekZANEOYTgt ZHY32ug0UihWw7CoCnpeiZutDsqhGUaAVH0O+nzIn9oZJ+qB1oy8bSmbor+wk85P BOxB3QALRfUMbsHvpnI3IRc+ElSuoYWX2/i6ktEnd+maeG5rO8c3LBboV8daoGnk dYuTmruqDnlDvrIPAJN0SJpnawSLxlHdh4rLe4f+PA8m5uioO3DYm7L3EspWMc7i iV5bKJ4iggpi+O4mz9ZPGLe1SlEbPjuuDYYySlpf8GOQptVnKzGtJLdsfAPWBCUV nlRc7/LnJjGNG87ExTzEQBKZvlvnsTmtGTYoBZnsAsIQQ5QOdQ9chXVunhqglWQ= =JOgR -----END PGP SIGNATURE-----

1 0

Micro Python
by Jeff Elkner June 4, 2014

June 4, 2014

A friend of mine just sent me a link to a new micro controller that runs python 3: http://micropython.org/ Now this is something to get excited about! It also could be one of the more effective ways to use Python in education. All I have to do now is get my hands on a few of these... Jeff

1 0