Mailman 3 February 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 03 Jul '18

03 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

frustrations attempting to join edu-sig?
by kirby urner 02 Mar '16

02 Mar '16

Do we have a listowner here? On the behest of this would-be poster I'm sharing about his attempt to join our discussions. Kirby FYI. ---------- Forwarded message ---------- From: Aivar Annamaa <aivar.annamaa(a)ut.ee> Date: Thu, Feb 25, 2016 at 7:51 AM Subject: Writing to Python Edu-Sig mailing list To: kirby.urner(a)gmail.com Hi, Kirby! I noticed you are an active member in Python Edu-Sig mailing list. I joined the list and tried to write to it several times but seems that my letters are just vanishing. I also wrote to edu-sig-owner(a)python.org and wilson(a)visi.com (couple of weeks ago) but got no response. Could you please notify the right persons that there seems to be problem in accepting new members into the list? Maybe you can forward my letter to the list? In case you think my e-mails were discarded because they contained spam, here's what I wanted to discuss: * There's a Python type checker MyPy (http://mypy-lang.org/) based on PEP 484. I wanted to ask, whether someone has any experience in using type annotations in teaching Python. * I have created a Python IDE for beginners (http://thonny.cs.ut.ee/) and I believe people in this mailing list would be interested in it. best regards, Aivar Annamaa University of Tartu

2 1

Project Euler with Python
by Peter Farrell 01 Mar '16

01 Mar '16

Hello to the Education group! Thought you might be interested in some mathy Python stuff I've been doing lately. I took my Coder School students through a lesson from my book, creating fractal trees using recursion, and a few of them finished that with enough time to look at a use of recursion to do something other than draw stuff. We looked at Project Euler problem #18 <https://projecteuler.net/problem=18>. We used the same recursive method we used to make trees to search through a tree of numbers. Here's a recursive function for finding the maximum path through the triangle: def maxPath(r,c): if r == 14: #if it's in the last row return cell[r][c] #return the value of that cell else: #return the cell + the max of the maxPaths of the lower two cells return cell[r][c] + max(maxPath(r+1,c),maxPath(r+1,c+1)) I'm still tickled that recursive functions work. I picture it as a recipe for baking a loaf of bread containing the step "Bake a loaf of bread." Anyway, it worked! Problem #67 <https://projecteuler.net/problem=67> is the same idea but with a much bigger array. My method didn't scale well from 15 rows to 100 but the site predicted that and hinted that "a clever method is needed." I thought of a better method (clever? idk), and it worked on problem 18, so I copied the big honking array into a txt file and changed the parameters to handle 100 rows. Got the right answer in 4 hundredths of a second. Let me know if you're dying to see that solution, too. Maybe a Project Euler-based math course or eBook is in order. I'm so fascinated by the mathematical nature of the step from brute force to more elegant solutions and I'm sure there are lots of common factors (pun intended) that could serve as topics of discussion. It's interesting to make Python tools that seem to be needed repeatedly on PE like a prime number generator, a function to create a list of the permutations of the digits of a number, and so on. I'm interested in any feedback the group has. Peter Farrell

1 0

1-2-3 testing (forwarded announcement)
by kirby urner 26 Feb '16

26 Feb '16

From: Ted Boulou <tboulou(a)somtou.com> Date: Fri, Feb 26, 2016 at 4:55 AM Subject: How we are using a Python-powered wooden-made Pi-based device to help micro-entrepreneurs in Senegal To: python-announce(a)python.org Hello sir,madam, I am Ted, CEO of a start-up based in Senegal that has built the Somtou. The Somtou is a *wooden-made* tablet-like device based on a *Raspberry Pi* running a *Python kivy-based software* that helps the micro-entrepreneurs in Africa and in emerging markets manage easily their businesses. We use 3D printing, CNC combined with pure craftsmanship to build the Somtou. I have enclose a small presentation. You can check our website www.somtou.com We will be delighted to discuss forward, BOULOU *Founder and Elephant* Mob : (221) 76 644 50 25 @ : tboulou(a)somtou.com <tboulou(a)poeyek.com> skype : ted.boulou *Visit us : www.somtou.com <http://www.somtou.com/>* -- https://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations/

1 0

Re: [Edu-sig] what is a "variable" in Python?
by kirby urner 19 Feb '16

19 Feb '16

On Thu, Feb 18, 2016 at 11:17 AM, Al Sweigart <al(a)inventwithpython.com> wrote: > Reference issue aside, I think the container works as a mental model. The > problem with the tag/label model is that if you think of the variable > `spam` as being attached to the value 42 and `eggs` as being attached also > to 42, it brings up the confusing idea: why do you have separate 42s if you > could just put both variable tag/labels on one 42? Where does this 42 > exist? Do all possible integers and strings just exist "out there", waiting > to have a tag/label attached to them? > Would "yes" be a wrong answer? >>> spam = eggs = 42 >>> id(spam) == id(eggs) True Two labels (two names), one thing (object, e.g. 42). But no, they don't always all exist already because the types are the birthing sources i.e. you need int, str, dict, tuple and so on to populate the space with actual instances. spam = 42 is short for spam = int('42', 10), where we're less fussy about base in the general sense. If you *can* jettison containers, and just stick with pieces of paper, it's lighter weight, conceptually. I encourage the bucket kickers. Hah hah. As in "kicking the habit" of thinking "variables are buckets". That's early stages something not-so-healthy around Python, could be fine if you're smoking C. :-D Kirby

1 0

[CfP] 5th IEEE Track on Collaborative Modeling and Simulation (Comets 2016) **** Submission Deadline Extended ****
by Daniele Gianni 17 Feb '16

17 Feb '16

*************** Submission Deadline Extended ********************** (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 25, 2016 ***** Extended ****** # 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 25, 2016 ***** Extended ***** * 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

Re: [Edu-sig] what is a "variable" in Python?
by kirby urner 17 Feb '16

17 Feb '16

I'm noticing that postings with edu-sig as one among several take longer to show up in the archives. I'm going to not reply-all in future and just use edu-sig for its mail reflector powers. That should make the moderator's job a little easier. Kirby On Tue, Feb 16, 2016 at 9:33 AM, kirby urner <kirby.urner(a)gmail.com> wrote: << SNIP >> > > > One imperils the precious new freedoms pioneered by VHLLs when > reintroducing all the cruft. > > The nitty gritty of Von Neumann architecture is not part of the mental > model we may dispense with for the time being. > "not part of the mental model [and so] we may dispense with [it] for the time being".

1 0

Re: [Edu-sig] what is a "variable" in Python?
by Andrew Harrington 16 Feb '16

16 Feb '16

I agree with Gary that mutability is a property of objects, not of variables. An object has methods. A name does not - it can refer to an object with a particular method. I do not get the variable and remote buttons analogy at all. The importance of a variable naming a memory *location* with a reference is that clearly there can be only one reference at that memory location at a time. There is nothing saying with the English word "label" that two different objects/places could not have the same naming label slapped on them, so relying too heavily on easy English analogies is tricky. In my Hands-on Python Tutorial <http://anh.cs.luc.edu/python/hands-on/3.1> I say all data has a type, and I start with immutable objects types. I say initially that a variable is a name used to refer to a piece of data. Much later I get to mutable objects, and then the idea of a reference to an object is key to understanding. I point out that with immutable objects this does not make much difference, but when we start dealing with mutable objects, it is important to be more precise. This sequence seems to work fine. Andy Dr. Andrew N. Harrington Computer Science Department Graduate Program Director gpd(a)cs.luc.edu Loyola University Chicago 529 Lewis Towers, 111 E. Pearson St. (Downtown) 417 Cudahy Science Hall (Rogers Park campus) http://www.cs.luc.edu/~anh Phone: 312-915-7982 Fax: 312-915-7998 aharrin(a)luc.edu (as professor, not gpd role) On Mon, Feb 15, 2016 at 8:58 PM, kirby urner <kirby.urner(a)gmail.com> wrote: > > > On Mon, Feb 15, 2016 at 5:23 PM, Carl Karsten <carl(a)nextdayvideo.com> > wrote: > >> I think the point of this thread is: how important is this subject? >> >> > I don't know that there's a scale of 1-10 answer. If / when it comes up, > as a student question, it becomes important, but also instructors need to > explain how a given object may have many names, whereas of we're focused on > "containers" how does that look? > > > >> I have one of many answers: in my 2 hour 500 line intro to python, it >> gets about 60 seconds spent on this 1 line: >> >> """Other languages have variables; technically, Python doesn't. But it >> has something that looks like a var: It has names. So don't call it a var. >> For a good explanation of this see >> http://python.net/~goodger/projects/pycon/2007/idiomatic/handout.html#other… >> """ >> > > This is excellent. > > I was racking my brains where to find visuals like this, specifically > showing the buckets versus post-its models. > > I've added links to my make_links_v2.py and make_links_v3.py @ <guild /> > [1] > > This thread was useful for our trains at PDX Code Guild at least, as I'm > having philosophical differences with some of my peers regarding the > uber-basics and how best to teach them. > > I've been told repeatedly that code school students will start out *not* > knowing what a variable is and my number one most important responsibility, > right from the get go, is to introduce the concept. > > Fine. But what if the curriculum hard-codes that we should see variables > as "containers". > > Before I lead a boot camp, Python-centric, I want to make sure I'm not > shackled to a misinforming presentation I'm not comfortable teaching. It'd > just feel wrong, like I'm lying, to force the "container metaphor". I > needed ammo. > > By now, thanks to these threads today, I feel well armed in my views that > I'm free to avoid said metaphor if I want to. > > Here's a screen shot of our faculty Slack feed from a few minutes ago: > > https://flic.kr/p/DduBoA > > There's enough consensus out there to defend my position. Yay. > > What I want to avoid is another instructor insisting on the "variable as > container" metaphor to a point where I feel I have to do extra work to undo > that picture. > > Thanks again for the tools, should that come up. > > Kirby > > [1] > https://www.dropbox.com/home/PDX%20Code%20Guild/Accelerated%20Programming%2… > > > >

3 3

Re: [Edu-sig] what is a "variable" in Python?
by kirby urner 16 Feb '16

16 Feb '16

On Mon, Feb 15, 2016 at 5:23 PM, Carl Karsten <carl(a)nextdayvideo.com> wrote: > I think the point of this thread is: how important is this subject? > > I don't know that there's a scale of 1-10 answer. If / when it comes up, as a student question, it becomes important, but also instructors need to explain how a given object may have many names, whereas of we're focused on "containers" how does that look? > I have one of many answers: in my 2 hour 500 line intro to python, it gets > about 60 seconds spent on this 1 line: > > """Other languages have variables; technically, Python doesn't. But it has > something that looks like a var: It has names. So don't call it a var. For > a good explanation of this see > http://python.net/~goodger/projects/pycon/2007/idiomatic/handout.html#other… > """ > This is excellent. I was racking my brains where to find visuals like this, specifically showing the buckets versus post-its models. I've added links to my make_links_v2.py and make_links_v3.py @ <guild /> [1] This thread was useful for our trains at PDX Code Guild at least, as I'm having philosophical differences with some of my peers regarding the uber-basics and how best to teach them. I've been told repeatedly that code school students will start out *not* knowing what a variable is and my number one most important responsibility, right from the get go, is to introduce the concept. Fine. But what if the curriculum hard-codes that we should see variables as "containers". Before I lead a boot camp, Python-centric, I want to make sure I'm not shackled to a misinforming presentation I'm not comfortable teaching. It'd just feel wrong, like I'm lying, to force the "container metaphor". I needed ammo. By now, thanks to these threads today, I feel well armed in my views that I'm free to avoid said metaphor if I want to. Here's a screen shot of our faculty Slack feed from a few minutes ago: https://flic.kr/p/DduBoA There's enough consensus out there to defend my position. Yay. What I want to avoid is another instructor insisting on the "variable as container" metaphor to a point where I feel I have to do extra work to undo that picture. Thanks again for the tools, should that come up. Kirby [1] https://www.dropbox.com/home/PDX%20Code%20Guild/Accelerated%20Programming%2…

1 0