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

recruiting for delta-calc / lambda-calc among post-algebra students
by kirby urner Sept. 29, 2014

Sept. 29, 2014

Edu-siggers might be interested in a rhetorical move, mainly for PR reasons (recruiting, morale...), to rebrand "differential / integral calculus" (Newton-Leibniz stuff) as also (equivalently) "delta calculus" (picture Greek letter del hyphen calculus). Why? Well for one "calculus" is too generic a word to surrender to just one brand or ethnicity and is qualified already as "differential calculus" etc. (i.e. the delta concept is already implicit), But also... To help "level the playing field" so that lambda-calculus (an umbrella for CS-friendly topics) might come to the foreground more as an equal player in the high school setting. For more on this meme / mnemonic: http://worldgame.blogspot.com/2014/09/lambda-versus-delta.html (with links to other fora e.g. maththinking-l with some overlap in membership) Kirby More recently (providing more context for same theme): http://mathforum.org/kb/message.jspa?messageID=9608019

1 1

example code: Descriptors
by kirby urner Sept. 27, 2014

Sept. 27, 2014

""" Demonstrating the descriptor protocol (cl) MIT by K. Urner """ class Property: def __init__(self, start): self.it = start def __set__(self, obj, val): if isinstance(obj, ReadOnly): print("Can't set property from this child") else: obj.it = val def __get__(self, obj, objtype=None): if not hasattr(obj, "it"): obj.it = self.it return obj.it class Thing: property = Property(0) class ReadOnly(Thing): pass class ReadWrite(Thing): pass # Test Code # Subclasses treated differently the_thing = ReadOnly() print("Before:",the_thing.property) the_thing.property = 42 print("After:",the_thing.property) print("="*10) the_thing = ReadWrite() print("Before:", the_thing.property) the_thing.property = 42 print("After:",the_thing.property) # Multiple instances have their own values print("="*10) thing1 = Thing() thing2 = Thing() thing1.property = 1 thing2.property = 2 print("thing1.property:", thing1.property, thing1.__dict__) print("thing2.property:", thing2.property, thing2.__dict__) # from the docs: https://docs.python.org/3.4/howto/descriptor.html class Dict(dict): # subclass rather than presume defining Dict top-level def fromkeys(klass, iterable, value=None): "Emulate dict_fromkeys() in Objects/dictobject.c" d = klass() for key in iterable: d[key] = value return d fromkeys = classmethod(fromkeys) print(Dict.fromkeys('abracadabra')) # {'a': None, 'r': None, 'b': None, 'c': None, 'd': None} OUTPUT from the above: Before: 0 Can't set property from this child After: 0 ========== Before: 0 After: 42 ========== thing1.property: 1 {'it': 1} thing2.property: 2 {'it': 2} {'a': None, 'r': None, 'b': None, 'c': None, 'd': None} Process finished with exit code 0

1 0

[CfP] 5th International Workshop on Model-driven Approaches for Simulation Engineering (Mod4Sim)
by Daniele Gianni Sept. 8, 2014

Sept. 8, 2014

################################################################# 5th International Workshop on Model-driven Approaches for Simulation Engineering part of the Symposium on Theory of Modeling and Simulation (SCS SpringSim 2015) CALL FOR PAPERS ################################################################# April 12-15, 2015, Alexandria, VA (USA) http://www.sel.uniroma2.it/Mod4Sim15 ################################################################# # Papers Due: *** November 10, 2014 *** Accepted papers will be # published in the conference proceedings and archived in the ACM # Digital Library. ################################################################# The workshop aims to bring together experts in model-based, model-driven and software engineering with experts in simulation methods and simulation practitioners, with the objective to advance the state of the art in model-driven simulation engineering. Model-driven engineering approaches provide considerable advantages to software systems engineering activities through the provision of consistent and coherent models at different abstraction levels. As these models are in a machine readable form, model-driven engineering approaches can also support the exploitation of computing capabilities for model reuse, programming code generation, and model checking, for example. The definition of a simulation model, its software implementation and its execution platform form what is known as simulation engineering. As simulation systems are mainly based on software, these systems can similarly benefit from model-driven approaches to support automatic software generation, enhance software quality, and reduce costs, development effort and time-to-market. Similarly to systems and software engineering, simulation engineering can exploit the capabilities of model-driven approaches by increasing the abstraction level in simulation model specifications and by automating the derivation of simulator code. Further advantages can be gained by using modeling languages, such as UML and SysML, but not exclusively those. For example, modeling languages can be used for descriptive modeling (to describe the system to be simulated), for analytical modeling (to specify analytically the simulation of the same system) and for implementation modeling (to define the respective simulator). A partial list of topics of interest includes: * model-driven simulation engineering processes * requirements modeling for simulation * domain specific languages for modeling and simulation * model transformations for simulation model building * model transformations for simulation model implementation * model-driven engineering of distributed simulation systems * relationship between metamodeling standards (e.g., MOF, Ecore) and distributed simulation standards (e.g., HLA, DIS) * metamodels for simulation reuse and interoperability * model-driven technologies for different simulation paradigms (discrete event simulation, multi-agent simulation, sketch-based simulation, etc.) * model-driven methods and tools for performance engineering of simulation systems * simulation tools for model-driven software performance engineering * model-driven technologies for simulation verification and validation * model-driven technologies for data collection and analysis * model-driven technologies for simulation visualization * executable UML * executable architectures * SysML/Modelica integration * simulation model portability and reuse * model-based systems verification and validation * simulation for model-based systems engineering To stimulate creativity, however, the workshop maintains a wider scope and welcomes contributions offering original perspectives on model-driven engineering of simulation systems. +++++++++++++++ Important Dates +++++++++++++++ * Abstract Submission Deadline (optional): September 12, 2014 * Paper Submission Deadline: November 10, 2014 * Decision to paper authors: January 9, 2015 * Camera ready due: February 10, 2015 * Conference dates: April 12-15, 2015 ++++++++++++++++++++ Organizing Committee ++++++++++++++++++++ * Andrea DÕAmbrogio - University of Rome "Tor Vergata", Italy * Paolo Bocciarelli - University of Rome "Tor Vergata", Italy

1 0

water cooler talk... Python mentors, post DjangoCon / Portland (next year Austin)
by Kirby Urner Sept. 5, 2014

Sept. 5, 2014

Water cooler talk at a Python-teaching academy, fellow faculty hobnobbing... Anyone out there on edu-sig wanna share more about PlotDevice? Of course I need to do some homework on my own, don't worry I will... very soon. My best to all at DjangoCon I got to yak with, around lunch tables especially, and in Steve's suite [ our own Steve Holden, Python track author and erstwhile PSF chair, produces this conference, which has been in Chicago and DC under his care as well -- small and esoteric, these Djangocons, under 300 I'd say, followed by sprints (going on now) ] Our school even got to be a DjangoCon sponsor this year, check it out... https://www.flickr.com/photos/kirbyurner/14963846568/ (OST a player!) ... high five Patrick! Kirby From: Kirby Urner [that's me] Date: Fri, Sep 5, 2014 at 1:41 PM Subject: Re: Interesting Mac-only Python graphics program(?) To: Patrick Barton [ Python Track mentor ] On Fri, Sep 5, 2014 at 12:00 PM, Patrick Barton wrote: FYI... http://plotdevice.io/ Interesting. Lots to look at here. I will likely post a heads up to edu-sig, my old time hangout in Python.org world. Before I forget: Django guy don't recall who right now: the request module is awesome. For wrapping head around HTTP API. In comparison to urllib2 in standard library. I haven't even Googled it yet, now I will... This looks like a good entry point: http://stackoverflow.com/questions/2018026/should-i-use-urllib-or-urllib2-o… OK, back to work. -- > Patrick J. Barton > Senior Instructor > O'Reilly School of Technology > Phone: 503.504.5239 > Skype: patbartonpdx >

1 0