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

a common misconception
by kirby urner 23 Jan '16

23 Jan '16

A common misconception in communicating Python is that range() and even list() are "function calls". That's correct for range() in 2.x: >>> type(range) <type 'builtin_function_or_method'> but has never been correct terminology regarding list(). Example: """ >From Chapter 9 of Inventing in Python: The range() and list() Functions When called with one argument, range() will return a range object of integers from 0 up to (but not including) the argument. This range object can be converted to the more familiar list data type with the list() function. Try entering list(range(10)) into the interactive shell: """ The author knows a range object is returned, however that's our clue that range() is calling a type (a class) and returning an instance of that class, ditto list( ). I'd like to see the Python 3.x teaching literature not muddying the waters by referring to range() and list() -- and zip() and enumerate() -- as "function calls". Kirby

2 2

greetings from <guild />; looking forward to pep 0498
by kirby urner 12 Jan '16

12 Jan '16

I've started to pick up some new Python students (adult age) through PDX Code Guild (<guild />). http://worldgame.blogspot.com/2016/01/bootcamp.html I was there last night watching their lead instructor coax them into gamely tackling the game of Zombie Dice, which has some pretty simple rules, not unlike Black Jack. https://flic.kr/p/CwcxzH (I assume the rule are Googleble) Tiffany is an accomplished instructor who inspires confidence in her team. https://flic.kr/p/CXDmZ4 ("duck typing" -- inside joke) Here's a snapshot of the kind of 'intro to classes' material we're using at <guild />, I'm sure reminiscent of what you've seen elsewhere, that you've written yourself: https://github.com/4dsolutions/Python5/blob/master/intro_classes.py I'm also planning to use this little quiz idea I picked up at Portland Python User Group (PPUG) -- code appended. That'll be when I guest lecture @ <guild /> on Wednesday, included in the Bootcamp course I'm aiming to pick up, after Intro to Python (starting soon InshaAllah). I'll also share some of the odyssey of our little gem of a School @ O'Reilly, not a sales pitch as we've decided on a different tack ("we" as in ORM, for whom I'm still working even as we speak, marathon runner students rushing to the finish line). Hey, I'm really looking forward to this new PEP being in 3.6: https://mail.python.org/pipermail/portland/2016-January/001733.html (re 0498) My other gig is teaching State of California folks enrolled in an enlightened professional development program. Saisoft.net -- some of you may already know that outfit. That's using Internet, but in real time, whereas School job is / was asynchronous (it's not either / or). Aside: I'm finding Lynda.com has some dynamite content around JavaScript / JQuery I'm thinking. Yes, that's a commercial. Safari Online is dynamite too, a perk I get to keep as a thank you (our faculty was dynamite). http://mybizmo.blogspot.com/2016/01/what-is-jquery.html (the Joe Marini movies are great!) Looking forward to Pycon in Portland! Kirby ==== # -*- coding: utf-8 -*- """ Created on Sun Jan 10 21:15:06 2016 @author: kurner Keywords Quiz Can you think of them all? """ import keyword all_kw = keyword.kwlist[:] # make a copy found = [ ] while len(all_kw) > 0: print("{} keywords left to guess".format(len(all_kw))) guess = input("What is your guess? (q to quit): ") if guess == 'q': print("You gave up!") print("Unguessed: ", all_kw) print("Guessed: ", found) break if guess in all_kw: print("Yes, that's one of them") all_kw.remove(guess) found.append(guess) elif guess in found: print("You got that one already") print("Found:", found) else: print("{} is not a keyword in Python.".format(guess)) else: print("Congratulations; you got them all!") Kirby

1 0

MicroPython and BBC micro:bit things
by Nicholas H.Tollervey 10 Jan '16

10 Jan '16

Hi Folks, Happy new year everyone! Apologies for cross-posting. Here's hoping it's worth it. We're getting close to a version 1.0 of MicroPython for the BBC's micro:bit device (a small programmable device that'll be given out to the UK's 11 year olds later this year - that's around 1 million devices). You can learn more about the project here: http://ntoll.org/article/story-micropython-on-microbit Damien George (the creator of MicroPython) has really delivered on this and demonstrated what a gifted developer he is. We've also been lucky to have help from a small band of talented developers who have contributed some really great work. But that's not all! Over the autumn I visited lots of UK based Python user groups and teacher led events (mainly CAS related) to show people the work that has been done so far and so we can get feedback from teachers. The bottom line is that we need a *simple* and easy to set-up editor that exposes MicroPython in the best possible way (while the official web-based "TouchDevelop" is great, it doesn't allow you to automatically flash the device, doesn't include a REPL connection for live coding and requires that you're always connected to the internet). Since December I've been working on an alternative solution, called "Mu". It's almost feature complete while still being a work in progress. Check out this video for the current state of affairs: https://www.youtube.com/watch?v=zmOxOusMvjo We need testers for this! If you're a teacher, programmer or developer I'd love to hear from you for help, feedback and bug reporting. You'll get to use the editor and I'll "loan" you a micro:bit (although there will be some caveats that apply because of BBC bureaucracy). If you're interested drop me a line. It's definitely a work in progress, but progress is fast. My autumnal research demonstrated that we also needed resources. To this end I've been running the micro-world-tour ~ an international community of Python developers have been building and sharing cool stuff that uses MicroPython on the micro:bit. Have a read here, I especially love the robots: http://microworldtour.github.io/ We also realised that teachers, developers and kids will need some easy way to share micro:bit output. With the help of the amazingly talented designer, Steve Hawkes I've done two things: 1) A very Wallace and Grommit "micro:bit-o-matic" hosted here: http://pycomic.github.io/microbit.html This lets you easily create and share simulations of the *outputs" from a micro:bit for demonstrative purposes (note - THIS IS NOT A FULL SIMULATOR - rather, it's a quick JavaScript hack so people can create, share and embed demos of micro:bit-y things). 2) We also had a batshit crazy idea to create a fun user-generated PyComic that can be included in educational resources. We want our resources to appeal to the 11yo target age group. So those with more of an affinity with visual rather than verbal instructions are catered for, we've decided to create some of our resources as comics. Our comics will feature "Yellow" and "Blue", the Python snakes..! (Yes, we've had approval from the PSF's trademark committee to use the modified snakes). Check out a proof of concept here (apologies to Guido - but it's such a lovely photograph): http://pycomic.github.io/?title=Testing%201,%202,%203...&author=@ntoll&bg1=… Notice how the comic is specified in the URL (it's a static website so there's no backend and state is stored in the query string). You're probably asking, "that's a bit of a long URL isn't it?" to which I'd reply http://bit.ly/ have an API I'm going to use. Again, another work in progress... I'm waiting on some design work from Steve before releasing the "editor" that'll allow you to create your own comics in a simple and easy to share way. It's important to note that these comics are not micro:bit specific - they could be used for any Python related resource and for comedic effect. Finally, we need teacher and student focussed resources (i.e. lesson plans and kid friendly how-tos). We already have developer documentation as a work in progress here: http://microbit-micropython.readthedocs.org/en/latest/ If anyone is interested in helping create these resources I'd love to hear from you. We have plans afoot to help you generate such things in, once again, an easy to create and share manner. As always, comments, constructive critique and ideas are most welcome! Best wishes, Nicholas.

2 1

[CfP] 5th IEEE Track on Collaborative Modeling and Simulation (Comets 2016)
by Daniele Gianni 09 Jan '16

09 Jan '16

(Please accept our apologies if you receive multiple copies of this message) ################################################################# IEEE WETICE 2016 5th IEEE Track on Collaborative Modeling and Simulation (Comets 2016) in cooperation with (approval pending) INCOSE Italy MIMOS (Italian Association for M&S) CALL FOR PAPERS ################################################################# June 13-16, 2016 - Paris (France) http://www.sel.uniroma2.it/comets16 ################################################################# # Papers Due: February 15, 2016 # Accepted papers will be published in the conference proceedings # by the IEEE Computer Society Press and will be submitted for # indexing through INSPEC, Compendex, Scopus, Thomson Reuters, # DBLP, Google Scholar and EI Index. ################################################################# Modeling and Simulation (M&S) is increasingly becoming a central activity in the design of new systems and in the analysis of existing systems because it enables designers and researchers to investigate systems behavior through virtual representations. For this reason, M&S is gaining a primary role in many industrial and research fields, such as space, critical infrastructures, manufacturing, emergency management, biomedical systems and sustainable future. However, as the complexity of the investigated systems increases and the types of investigations widens, the cost of M&S activities increases for the more complex models and for the communications among a wider number and variety of M&S stakeholders (e.g., sub-domain experts, simulator users, simulator engineers, and final system users). To address the increasing costs of M&S activities, collaborative technologies must be introduced to support these activities by fostering the sharing and reuse of models, by facilitating the communications among M&S stakeholders, and more generally by integrating processes, tools and platforms. Aside from seeking applications of collaborative technologies to M&S activities, the track seeks innovative contributions that deal with the application of M&S practices in the field of collaborative engineering platforms. These platforms are continuously becoming more complex, and therefore their design requires systematic approaches to meet the required quality of collaboration. This is important for two reasons: to reduce rework activities on the actual collaborative environment, and to maximize the productivity and the quality of the process the collaborative environment supports. M&S offers the methodologies and tools for such investigations and therefore it can be used to improve the quality of collaborative environments. A non-exhaustive list of topics of interest includes: * collaborative requirements modeling * collaborative environments for M&S * collaborative Systems of Systems M&S * business process modeling for collaborative environments * agent-based M&S * collaborative distributed simulation * collaborative component-based M&S * net-centric M&S * web-based M&S * model sharing and reuse * model building and evaluation * modeling and simulation of business processes * modeling for collaboration * simulation-based performance analysis of collaborative engineering platforms * model-driven approaches for collaborative engineering * domain specific languages for collaborative M&S * databases and repositories for M&S * distributed virtual environments * virtual research environment for M&S * collaborative DEVS M&S * multi-method M&S To stimulate creativity, however, the track maintains a wider scope and invites interested researchers to present contributions that offer original perspectives on collaboration and M&S. +++++++++++++++++++++++++++++++++++ On-Line Submissions and Publication +++++++++++++++++++++++++++++++++++ CoMetS'16 intends to bring together researchers and practitioners to discuss key issues, approaches, open problems, innovative applications and trends in the track research area. Papers should contain original contributions not published or submitted elsewhere. Papers up to six pages (including figures, tables and references) can be submitted. Papers should follow the IEEE format (http://www.ieee.org/conferences_events/conferences/ publishing/templates.html). All submissions should be submitted in PDF format and will be peer-reviewed by at least three program committee members. Accepted papers will be included in the proceedings and published by the IEEE Computer Society Press. Please note that at least one author for each accepted paper should register to attend WETICE 2016 (http://www.wetice.org) to have the paper published in the proceedings. Interested authors and participants may contact the organizers for expression of interests and content appropriateness at any time. Papers and posters can be submitted in PDF format at the conference submission site (https://www.easychair.org/conferences/? conf=wetice2016), by selecting the ÒCollaborative Modeling and SimulationÓ track. +++++++++++++++ Important Dates +++++++++++++++ * Submission Deadline: February 15, 2016 * Notification to authors: March 28, 2016 * Camera Ready to IEEE: April 11, 2016 * Conference date: June 13-16, 2016 +++++++++++++++++ Program co-chairs +++++++++++++++++ Andrea D'Ambrogio, University of Roma TorVergata, Italy Gregory Zacharewicz, University of Bordeaux, France Daniele Gianni, Guglielmo Marconi University, Italy *** Contact Information *** Andrea D'Ambrogio (track co-chair) Email: dambro(a)uniroma2.it

1 0

continuing with coroutines
by kirby urner 06 Jan '16

06 Jan '16

This code is practical mainly in the trivial sense that it runs to completion. # -*- coding: utf-8 -*- """ Created on Sun Jan 3 13:51:20 2016 @author: kurner """ import itertools def assemble(): drv = yield None drv.result = 1 drv = yield drv drv.result += 1 drv.name = "Alvin" drv = yield drv drv.result += 1 drv.color = "Red" drv = yield drv drv.result += 1 drv.age = 100 return drv class Driver: def __init__(self, g): self.g = g self.g.send(None) # primed self.counter = 1 def go(self): while True: try: self.counter *= 10 self = self.g.send(self) except StopIteration as exc: return exc.args[0].__dict__ d = Driver(assemble()) r = d.go() print(r) Console output: {'name': 'Alvin', 'color': 'Red', 'age': 100, 'counter': 10000, 'g': <generator object assemble at 0x110078af0>, 'result': 4} The tractor classes I posted earlier should more properly by referred to as co-routines, as they were driven by a "tick" loop. Python itself is growing more powerful in this area. What stands out about assemble() is it has yields, so is clearly a generator, but also it returns, and the StopIteration value is not only recoverable, but what we expect more generally from a 'yield from'. What assemble returns is a thing that keeps pushing the coroutine with a send(), actually sending itself, meaning it grows attributes from both inside and outside the coroutine. I dump the state of said "thing" as the end result. One starts to see the relevance to concurrency when imagining many coroutines such as assemble() that keep relinquishing control while holding their place, each advancing as driven to do so by a "driver" (task) that whips in on. Kirby

1 2

pep380: yield from
by kirby urner 04 Jan '16

04 Jan '16

I working through Luciano's Fluent Python, which I really appreciate reading in Safari On-Line as so many of the links are live and relevant. Luciano packs his 'For Further Reading' with links directly in Google groups, where we can see Guido studying Twisted so to better communicate his alternative vision in asyncio (formerly tulip). Here's a tiny test module I'm using, based on Gregory Ewing's PEP 380. https://www.python.org/dev/peps/pep-0380/ from itertools import takewhile def fibo(a,b): "Fibonacci Numbers with any seed" while True: yield a a, b = a + b, a def pep380(EXPR): _i = iter(EXPR) try: _y = next(_i) except StopIteration as _e: _r = _e.value else: while 1: try: _s = yield _y except GeneratorExit as _e: try: _m = _i.close except AttributeError: pass else: _m() raise _e except BaseException as _e: _x = sys.exc_info() try: _m = _i.throw except AttributeError: raise _e else: try: _y = _m(*_x) except StopIteration as _e: _r = _e.value break else: try: if _s is None: _y = next(_i) else: _y = _i.send(_s) except StopIteration as _e: _r = _e.value break return _r def get_em(): # fibs = fibo(0,1) # yield from fibs # delegates to subgenerator # return fibs return pep380(fibo(0,1)) g = get_em() print(tuple(takewhile(lambda n: n < 1000, g))) Console output: (0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, 233, 377, 610, 987) Now if I comment out differently: def get_em(): fibs = fibo(0,1) yield from fibs # delegates to subgenerator # return fibs # return pep380(fibo(0,1)) Same answer: (0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, 233, 377, 610, 987) One may also return fibs directly from get_em, showing that 'yield from' is driving the same process i.e. delegation is happening. Just scratching the (itchy) surface. Kirby

1 1