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

turtle coordinates: Y increase downards - as in most graphics API?
by Jurgis Pralgauskis July 2, 2018

July 2, 2018

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

trails through the ecosystem: language sequence
by kirby urner Aug. 1, 2015

Aug. 1, 2015

Thinking of how I might design a robust computer science learning thread using today's open source tools. See caveats at the bottom. Python is oft circled as a great first language, but then what? From a practical standpoint, I'd say: leverage your Python to tackle a second OO language: Java (not JavaScript yet). Then leverage your Java, which need not be super polished, to tackle Clojure. That'll be a first LISP-family language and will start to formalize ground covered, making the concepts more clear. Pick up concurrency concepts here. Finally: back to Python i.e. take what you've learned on this circle tour to move into concurrency with Python if you wish, and with new fondness for a LISPish mindset. From here you're ready to branch to whatever your career calls for: more C family? More Apache stuff (Tomcat?). I'd say you've got even going on the language side with this point to start tackling DB world and its SQL/noSQL APIs. In sum: Python first Bridge to Java Tackle concurrency in Clojure (runs on JVM) back to Python, add more layers and polish === DB stuff: SQL + noSQL In between all this comes installation and simple sysadmin devops baby steps i.e. just learning the above interactively will bring an OS shell and perhaps an IDE into focus. Speaking of IDEs, that's a good place to introduce version control, where you can back end your code plane (screens) straight into some repository. Caveats: Note that I'm not talking about theory, not trying to outline general principles, hardware abstractions, parsing / compiling (back to theory of data structures, parse trees etc.). I'm imagining all that as content and/or background, while the above simply tracks an evolving skills set in terms of language and exposure to specific APIs. An alternative would be a more traditional LAMP stack approach, which still works as a thumbnail guide: L -- OS level on down to hardware A -- All lower level server processes e.g. httpd M -- Persistence Layer (keeping / updating state) P -- Application layer (hosted processes e.g. PHP's) i.e. it remains useful to break it down that way. Kirby

2 4

OSCON: Lessons Learned
by Kirby Urner July 30, 2015

July 30, 2015

OSCON: Lessons Learned by Kirby Urner, Mentor, O'Reilly School of Technology What the bigger enterprises are discovering, along with small and mid-sized, is that Open Source is not just end products, such as Perl and FireFox, but a way of working together to create those products, a supply chain, a process. In order to attract and keep the loyalty of engineers who work in the Open Source way, which has proved highly productive, the enterprise needs to not only use, but contribute to the Open Source commons. In supporting public projects, such as Asgard in the case of Netflix, OpenStack in the case of HP, Linux in the case of IBM, companies throw their hats in the ring, demonstrating they understand contributing source code is a way of earning good will, while reaping the benefits. Those who contribute quality code to the commons are seen as competent and powerful, using a currency engineers respect. Money is just data after all, whereas code is what harvests and controls data, moves it around in the cloud. Both Walmart Labs and Paypal, OSCON sponsors, provided eloquent testimony regarding their embracing of the Open Source way. Governments are not far behind, with the UK and US both sending heads of Digital Services departments to deliver complementary OSCON keynotes. Conway's Law states that organizations end up with systems reflective of their own internal communications. These days, staying nimble and on top of one's game, means adopting such Open Source practices as having "two pizza teams" (no bigger than might be fed on two pizzas) each tasked with maintaining and contributing features to smallish, well-defined products and services. Netflix sees the benefits of this design, with some teams committing new code at a relatively high rate compared to others. Loosely coupled services with managers highly aligned to company goals: that's a recipe for success. Monolithic proprietary applications, in contrast, tend to develop so many internal dependencies (including on a small cadre of indispensable programmers) that they encounter logjams in development. The whole enterprise bogs down. PayPal's name for adopting Open Source practices in-house is InnerSource. The core discovery is when engineers code on the assumption their code will be world readable, source open, they simply write better code. In practice, the sphere of projects supported by the Apache Foundation defines a ready-made commons. For PayPal, InnerSource means "Apache Inside" -- including such products as Spark and Tomcat, not just the famous web server. For WalMart Labs, the code base includes Node.js, Cassandra and Mongo. Engineers following the Open Source way do a better job at decoupling their projects, following the Unix philosophy of having many independent tools that each does something well-defined and discrete. The APIs are clearer that way. Innovation leverages the power of a community, including contributions from non-employees. When the license keeps the source open, the company partakes of greater positive synergies. Geniuses continue pouring their best thinking into vital enterprise assets, precisely because these assets are owned in common. No one may steal and possess exclusively of others: that's the hallmark of Free (as in liberated) Software. The Open Source approach is conducive to: (a) ownership by responsible teams, capable of responding to feedback (b) containerization and micro-services in the cloud, the most scalable and economical setting for enterprise computing (c) quick on-boarding of new talent, oft recruited from the community of contributers to one of these open projects a company values. The Open Source way includes using version control and such Agile techniques as test driven development (TDD is featured along our Python Track here at OST). As Allison Randal summarized recent history in her keynote: in the distant dino past of thirty years ago, a lot of people assumed Open Source was slated to always be playing catch up i.e. the "community edition" would always be second fiddle to what the closed source engineers were doing. That world view has been turned inside out in many critical domains, where open also means transparent, as in trusted, as well as best of breed. Who wants to build "the cloud" using tools owned and controlled by a tiny few? Open Source is a way to insure interoperability and hence long term profitability. Embracing the Open Source way is out of economic necessity, not just altruism. Open Source is about keeping control out of controlling hands and then competing (with "secret sauce" i.e. "value added") within that shared context. As it turns out, the business case for "keeping it open" is uber-compelling. OSCON's long list of big name sponsors is evidence of what's accepted as common wisdom these days: Open Source has won.

1 0

Infrastructure Issues (typo + broken link + outta date info)
by kirby urner July 13, 2015

July 13, 2015

(1) From our home page: More and more, Python is making inroads <http://wiki.python.org/moin/SchoolsUsingPython> at all levels in education. Python offers an interactive environment in which to explore procedural, functional and object oriented approaches to problem solving. Its high level data structures and clear syntax make it an ideal first language, while the large number of existing libraries make it suitable to tackle almost any programming tasks. Slightly better grammar: any programming task. In the singular. "All tasks, any task". (2) Broken link: On our mailman front page: https://mail.python.org/mailman/listinfo/edu-sig the link to "edu-sig" home page: www.python.org/sigs/edu-sig/ fails and resolves instead to: www.python.org/community/sigs/ (link from mailman oughta be: www.python.org/community/sigs/current/edu-sig/ ) (3) I think the mailmain front page has wrong info re listownership, right? Kirby

1 0

Fairwell PyKata
by David MacQuigg July 6, 2015

July 6, 2015

I just got a notice from Google that PyKata and a few other programs I developed using the Google App Engine, will no longer work unless I migrate these applications to their new High Replication Datastore. I took a quick look at that process, but it has been too many years, and I am too busy with my other activities to complete that process. So PyKata will die very soon, unless someone wants to take over as admin, and keep this website alive. You'll need to know Django and Google App Engine as well as Python. The plan, which I was never able to complete, was to make this website into a template that could be customized by anyone wanting to use it in their own teaching activities. The homepage would appear as unique to each school. Every teacher could have their own set of exercises, or use whatever they like of someone else's set. It's all under a Creative Commons license.

1 0