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

Re: [Edu-sig] Edu-sig Digest, Vol 137, Issue 18
by Marianne McKenna Dec. 31, 2014

Dec. 31, 2014

I am away from the office. I will try to respond by email. If you need immediate help, please contact tech support. Thanks!

1 0

Re: [Edu-sig] Edu-sig Digest, Vol 137, Issue 17
by Marianne McKenna Dec. 30, 2014

Dec. 30, 2014

I am away from the office. I will try to respond by email. If you need immediate help, please contact tech support. Thanks!

1 0

Re: [Edu-sig] Edu-sig Digest, Vol 137, Issue 16
by Marianne McKenna Dec. 29, 2014

Dec. 29, 2014

I am away from the office. I will try to respond by email. If you need immediate help, please contact tech support. Thanks!

1 0

Call for volunteers for Python Education Summit...
by Chalmer Lowe Dec. 29, 2014

Dec. 29, 2014

Dear edu-sig: The Third Annual Python Education Summit <https://us.pycon.org/2015/events/edusummit/>, held during PyCon <https://us.pycon.org/2015/> on Thursday *April 9th 2015*, is coming together. We are gathering some excellent talk ideas (click here <http://www.google.com/moderator/#16/e=211b44> to see some of the proposed talks). Thanks to those who have summited talks so far. As with any event, the Education Summit can't be pulled off alone, so we are asking for volunteers. Some of the roles that you can help with include: - *Keynote Speaker Team*: help us identify and invite Keynote speakers(s) - *Call for Proposal Manager*: help us support the call for proposal process (answer questions, process submissions, etc) - *Emcee*: help emcee for our second track in the afternoon - *Publicity Rep(s)*: support us in advertising via the twitters/facebooks/etc - *Ushers/go-fers*: help ensure that the actual event runs smoothly If you would like to help, please contact me, Chalmer Lowe <chalmer.lowe(a)gmail.com> or my colleague, Jessica Nickel <jessicanickel(a)gmail.com>. *NOTE*: Even if your schedule doesn't allow you to support through volunteering, please feel free to sign up <http://www.eventbrite.com/e/the-pycon-2015-education-summit-tickets-1502916…> for the Education Summit to meet with your peers in education to learn more about combining Python and Education.

1 0

Re: [Edu-sig] Edu-sig Digest, Vol 137, Issue 15
by Marianne McKenna Dec. 28, 2014

Dec. 28, 2014

I am away from the office. I will try to respond by email. If you need immediate help, please contact tech support. Thanks!

1 0

Need resource for beginners
by Tamim Shahriar Dec. 27, 2014

Dec. 27, 2014

I am going to conduct a workshop next month. I shall use Python in the day-long workshop. The workshop will be for girls only (grade 9-10) who know how to use computers but not familiar with programming. If anyone has experience conducting similar workshop and has resource, please share. Also, what do you think I should show them in the workshop? Every girl will have access to a computer during workshop? Should I go with solving problems from their math / physics book? Or should I try to show them simple games to make it more fun? I am waiting for your ideas. Regards, Tamim. Python Blog : http://love-python.blogspot.com

6 10

Re: [Edu-sig] Edu-sig Digest, Vol 137, Issue 14
by Marianne McKenna Dec. 27, 2014

Dec. 27, 2014

I am away from the office. I will try to respond by email. If you need immediate help, please contact tech support. Thanks!

1 0

easygui_qt
by Andre Roberge Dec. 26, 2014

Dec. 26, 2014

Hi everyone, If you use Python 3 and PyQt in a teaching environment (e.g. the Anaconda distribution), you might be interested in a new project I have started. ==== The original inspiration: http://easygui.sourceforge.net/ ==== About EasyGUI EasyGUI is a module for very simple, very easy GUI programming in the Python programming language. Experienced Pythonistas need to be able to make simple GUI interfaces quickly and easily. New Python programmers, students, and sysadmins need GUI capabilities that don't require knowledge of Tkinter, frames, widgets, callbacks or lambda. This is what EasyGUI provides. Using EasyGUI, all GUI interactions are invoked by simple function calls. EasyGUI is different from other GUIs in that EasyGUI is NOT event-driven. It allows you to program in a traditional linear fashion, and to put up dialogs for simple input and output when you need to. If you have not yet learned the event-driven paradigm for GUI programming, EasyGUI will allow you to be productive with very basic tasks immediately. ========= My new project is easygui_qt (https://github.com/aroberge/easygui_qt). If you go to the github repository, you will see an impressive looking package. Do not be fooled: most of this has been generated automatically by "cookiecutter" - I wanted to learn to use it to create packages that could be easily updated to https://pypi.python.org/pypi and cookiecutter generates all the required boilerplate code (including additional files for automated testing, etc.), most of which I do not use (yet). Right now, there are only two files of potential interest: https://github.com/aroberge/easygui_qt/blob/master/easygui_qt/easygui_qt.py which contains the widgets; and https://github.com/aroberge/easygui_qt/blob/master/demos/guessing_game.py which shows how to use the existing widgets in a simple program. There are still quite a few widgets that I need/want to implement and am always open for feedback and suggestions. André

3 3