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

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

BI about Code Schools
by kirby urner 01 May '16

01 May '16

As some of you know, I've been studying the emerging market for "code schools", not an entirely new phenomenon, but spiraling through a next iteration around now. Why am I interested? Because per my LinkedIn profile, I've been working in this arena for a long time, back to the 1980s when I was a trainer in Lotus 1-2-3, dBase and WordPerfect. "I go way back" as they say, in the Way Back Machine (see archive.org). Here's one of my recent BI-like findings, using my own neural net (the one between my ears): code schools are in need of on-the-shelf prototypes that students might hack on, both alone and together, and a logical application every code school needs is (drum role): an on-line gift shop (with optional brick 'n mortar add-on with point of sale devices). Why? Well lets take the case of many colleges and universities that teach computer science as an academic subject. If one drills down, with the question, "do they eat their own dog food?" the answer is often "no, they use Banner" or some other engine to manage registration, enrollment, HR stuff. They don't roll their own and why should they? Their business is teaching the theory, not designing college-management applications. Admin is free to not bother faculty and outsource instead; buy off the shelf stuff (COTS) if you can find it. [1] With a code school though, it's different, at least when it comes to those advertising "full stack engineer" as what they're hatching (eager eggheads lining up). Any code school worth its salt should be turning out the very folks who write those on-line gift shop applications, in Django, Rails or whatever. The Shopping Cart. Other paradigms. "How do we know they're learning those skills and actually writing such applications?" the hopeful employer wants to know. We can see their checked in code in Github that's how. Front End, Back End, whatever, they've hacked on a gift shop prototype, maybe not the one running at the moment, but that's neither here nor there (the Ux keeps changing out, as the code school rotates its look and feel). Some capstone project: a gift shop in Haskell, fully operational. Wow. Another capstone: a MEAN stack using TypeScript with Angular2, classic implementation. Again wow. "This school has the cheese! We want our people from there!" Plus every school needs a gift shop, of course, for alumni and enrollees, partners and siblings, who want to partake of the swag. This won't all happen overnight. Some code schools have gift shops already. I'm anticipating a trend here, so we can all look back and see if my crystal ball was cloudy or clear. Kirby [1] https://en.wikipedia.org/wiki/Commercial_off-the-shelf

1 1

more simmering debate...
by kirby urner 01 May '16

01 May '16

I want to suggest that the much-used metaphor (by me included): "class is a blueprint, with instances the buildings made from it" (houses usually) is a good start, but not nuanced enough to take us all the way to the end of our story. These days I've taken a two pronged approach: yes, OO is meant to model how we think normally, about things with properties and behaviors. "The language gets out of the way and lets you think in terms you're already familiar with, from work" and such PR, some truth in it... ... However (big pause), OO also is it's own knowledge domain with its own concepts and those are better faced directly and dealt with than dismissed as mere noise. The blueprint metaphor, in being so simple, is maybe too simple, and therefore dismissive, at least if left in place for too long. So yes, OO has its cost, the knowledge domain that is OO with all its twisted tails of multiple inheritance and the method resolution order. But learning that little overhead is more than worth the price of admission (the PR again). The whole idea of inheritance, and of static and class methods, undermines this simplistic beginning of "blueprint" and so could become corrosive vectors of entropy (leaking sense), if not contained within more fitting metaphors. I like to say the class is a "mother ship" and serves as a kind of "home base" or "platform". How about an "amusement park"? Each self brings its little __dict__ to the theme park, but all the "rides" (the "stuff happening") are anchored in the class's __dict__. The self parameter is like an empty seat in a ride, which the rider's self then fills. This so-called "blueprint" is where the methods are happening, which is so not what it's like in the case of houses. The many instances (the selves) are but little bags of state, little "var stashes" (uh oh, JavaScript creeping in... :-D). Anyway, ya catch my drift, right? If we over-stress the blueprint metaphor they'll not be as open minded about blueprints having their own "batteries included" and doing stuff on their own, no "selves" need apply in some cases (not all methods need a self). Literal blueprints don't light up and do stuff all on their own like that. Our classes often behave a lot more like objects with a life of their own. ... and that's true of course as they're each instances of the type "type", one more example of what that "bag o' tricks" we called 'a class' might look like. Kirby

3 10

more about a classic code school spiral...
by kirby urner 30 Apr '16

30 Apr '16

On Fri, Apr 29, 2016 at 12:20 PM, kirby urner <kirby.urner(a)gmail.com> wrote: << SNIP >> > Here's one of my recent BI-like findings, using my own neural > net (the one between my ears): code schools are in need of > on-the-shelf prototypes that students might hack on, both alone > and together, and a logical application every code school needs > is (drum role): > (drum roll): <--- oops The curriculum I'm envisioning (for some schools to adopt) looks like this: X --> JavaScript (good parts) --> Front End (static HTML / CSS, then DOM animation) --> dive into alien LISPish language, in parallel with... --> dive into Python --> back to JavaScript (and so on, in a spiral) --> X By LISPish language I mean such as: Clojure, Pyret, Racket, Scala... feel free to add. Where does J fit in? Definitely J, like APL before it, shares the paradigm of a "pipeline of transformations" and that's what this segment will show off: concurrent / parallel throughput as we work through examples of machine learning. Pyret has image objects self representing right in the REPL, making the concepts come easily. Apply image filtering interactively. I like that theme of "Where's Waldo" https://youtu.be/U89BmApmnE8?t=1870 # <-- that's 31 minutes, 10 seconds I'm not saying Python can't do a deep learning learning pipeline, it can and does, but we're purposely going from JavaScript to LISPish because we want our spiral to branch off in all directions, future career-wise. If you end up doing Java or C#, you'll have your Python to build on. If you're pulled towards Clojure, your code school will have prepared you. Starting and ending with JavaScript is just another way of saying "to be continued" i.e. on the next iteration through JavaScript we might look at ES7 or one of the transpiler variants (TypeScript). Lots to learn! Kirby

1 0

anti-idiom checker?
by Jurgis Pralgauskis 27 Apr '16

27 Apr '16

Hi, As I teach Py after C, guys like to index list items more than needed... Maybe you know some check'er which would automatically detect such and similar stuff (and propose the idioms :). https://en.wikibooks.org/wiki/Python_Programming/Idioms#Data_types Thanks :) ps.: I imagine I could make sth via AST analysis... -- Jurgis Pralgauskis tel: 8-616 77613; Don't worry, be happy and make things better ;) http://galvosukykla.lt

2 3

Libro: Aprendiendo a programar en Python con mi Computador
by Sergio Rojas 24 Apr '16

24 Apr '16

Un libro que puede interesar a los usuarios de edu-sig es "Aprendiendo a programar en Python con mi Computador" de distribución bajo licencia Atribución-NoComercial-CompartirIgual 3.0 Venezuela (CC BY-NC-SA 3.0 VE) cuyos términos y condiciones están disponible en: http://creativecommons.org/licenses/by-nc-sa/3.0/ve/ El mismo lo hemos hecho disponible en : https://github.com/rojassergio/Aprendiendo-a-programar-en-Python-con-mi-com… or Saludos, Sergio

2 2

Re: [Edu-sig] Edu-sig Digest, Vol 153, Issue 9
by Marianne McKenna 22 Apr '16

22 Apr '16

I am out of the office today April 21, 2016. If you need immediate help, please contact tech support. Thanks

1 0

Re: [Edu-sig] Edu-sig Digest, Vol 153, Issue 8
by Marianne McKenna 21 Apr '16

21 Apr '16

I am out of the office today April 21, 2016. If you need immediate help, please contact tech support. Thanks

1 0

of Brython, JavaScript and closures
by kirby urner 15 Apr '16

15 Apr '16

Those of you tracking the Cuba working group will have seen that Brython is to be a topic [0]. That's "Python is the browser", which I'm eager to try (haven't yet). Brython is a segue to JavaScript, which I'm relearning from scratch ('The Good Parts' etc.). Over on mathfuture I'm continuing to discuss what I call the Lambda Calc track [1] where we introduce programming as a math-relevant way of thinking / activity / skill. A long-running theme here on edu-sig already. In comparing JavaScript and Python, I'm learning quite a bit. Example: JavaScript allows closures wherein a function in a function retains its memory of the variables (names) in the surrounding scope. The following example of a closure is from: Speaking JavaScript by Axel Rauschmayer Publisher: O'Reilly Media, Inc. Release Date: March 2014 ISBN: 9781449365035 in the intro section on Closures. function createIncrementor(start) {return function () { start++; return start; }} ... which gives the following behavior: > var inc = createIncrementor(5); > inc() 6 > inc() 7 > inc() 8 Lets try that same thing in Python. def createIncrementor(x): def increm(): x += 1 return x return increm At first it seems not to work (not just seems, it doesn't): >>> from closure import createIncrementor >>> inc = createIncrementor(5) >>> inc() Traceback (most recent call last): File "<pyshell#30>", line 1, in <module> inc() File "/Users/kurner/Documents/classroom_labs/closure.py", line 4, in increm x += 1 UnboundLocalError: local variable 'x' referenced before assignment That's where the keyword nonlocal comes in. The increm function was originally looking in the global namespace for x whereas we need it to look "close to home" (at the originally surrounding scope): def createIncrementor(x): def increm(): nonlocal x x += 1 return x return increm >>> from closure import createIncrementor >>> inc = createIncrementor(5) >>> inc() 6 >>> inc() 7 >>> inc() 8 Voila, a closure. Closures turn out to be really important in JavaScript thanks to its weak modularization model i.e. namespaces are difficult to segregate minus such patterns. Closures get used to mitigate name collisions. Python is less dependent on that pattern, given it has other ways to confine names to local scopes. Kirby [0] http://tinyurl.com/hpgrebf (Brython sprint / Cuba) [1] http://tinyurl.com/jbpef72 (mathfuture posting)

1 1