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

turtle: properties instead of setters/getters ?
by Jurgis Pralgauskis 29 Apr '15

29 Apr '15

Hi, turtle module is nice way to introduce to Python, but, if I want to increase x by 10, I have to write t.setx( t.xcor() + 1) which is uglier (and not beginner friendly) than common: t.x = t.x + 1 beginners tend to forget () after xcor and so on... This could be achieved with several property <https://docs.python.org/3/library/functions.html#property>/decorator lines Would it be possible for Py 3.5? :) ps.: I teach programming games, and more robust expressions (for collision checking) would look cleaner: if ball.x-5 > box.x-10 and ball.x+5 < box.x+10: ball.x =100 instead of if ball.xcor()-5 > box.xcor()-10 and ball.xcor()+5 < box.xcor()+10: ball.setx( 100 ) pps.: I don't know how would default turtle instance behave could I then write x = x + 1 instead of setx( xcor() + 1) ? -- Jurgis Pralgauskis tel: 8-616 77613; Don't worry, be happy and make things better ;) http://galvosukykla.lt

2 4

Re: [Edu-sig] turtle: properties instead of setters/getters ?
by Jurgis Pralgauskis 29 Apr '15

29 Apr '15

Trinket.io now proposes turtle graphics with good feature -- image rotation while turning (which is absent in TK)...... http://blog.trinket.io/using-images-in-turtle-programs/ so you can try it without installing Py locally :) There is nice collection of over 50 examples: https://code.google.com/p/python-turtle-demo/downloads/list On Mon, Apr 27, 2015 at 7:07 PM, Sebastian Silva <sebastian(a)fuentelibre.org> wrote: > Hi, > I also teach game programming to kids, but haven't used the turtle module. > > I collect and sometimes translate some resources to spanish here: > http://pe.sugarlabs.org/ir/Python > > I don't know if this is the right forum but I wanted to chime in to say +1 > and curious to see how such a requests works within the Python community. > > Best regards > Sebastian > > > > On 27/04/15 10:36, Jurgis Pralgauskis wrote: > > The same would apply to many other properties: > > y > heading > position > > speed > pensize > > color > shape > shear > tilt > visible > > maybe sth else.. > > > > > On Mon, Apr 27, 2015 at 6:19 PM, Jurgis Pralgauskis < > jurgis.pralgauskis(a)gmail.com> wrote: > >> Hi, >> >> turtle module is nice way to introduce to Python, >> but, if I want to increase x by 10, I have to write >> >> t.setx( t.xcor() + 1) >> >> which is uglier (and not beginner friendly) than common: >> t.x = t.x + 1 >> >> beginners tend to forget () after xcor and so on... >> >> This could be achieved with several property >> <https://docs.python.org/3/library/functions.html#property>/decorator >> lines >> Would it be possible for Py 3.5? :) >> >> >> ps.: I teach programming games, >> and more robust expressions (for collision checking) would look cleaner: >> if ball.x-5 > box.x-10 and ball.x+5 < box.x+10: >> ball.x =100 >> >> instead of >> if ball.xcor()-5 > box.xcor()-10 and ball.xcor()+5 < box.xcor()+10: >> ball.setx( 100 ) >> >> pps.: >> I don't know how would default turtle instance behave >> could I then write x = x + 1 >> instead of setx( xcor() + 1) >> ? >> >> >> -- >> Jurgis Pralgauskis >> tel: 8-616 77613; >> Don't worry, be happy and make things better ;) >> http://galvosukykla.lt >> > > > > -- > Jurgis Pralgauskis > tel: 8-616 77613; > Don't worry, be happy and make things better ;) > http://galvosukykla.lt > > > _______________________________________________ > Edu-sig mailing listEdu-sig@python.orghttps://mail.python.org/mailman/listinfo/edu-sig > > > -- > I+D SomosAzucar.Org > "icarito" #somosazucar en Freenode IRC > "Nadie libera a nadie, nadie se libera solo. Los seres humanos se liberan en comunión" - P. Freire > > -- Jurgis Pralgauskis tel: 8-616 77613; Don't worry, be happy and make things better ;) http://galvosukykla.lt

1 0

Thanks Jessica and Chalmers for a wonderful EDU Summit!
by Jeff Elkner 12 Apr '15

12 Apr '15

Shout out to Jessica and Chalmers for all the hard work they put in organizing the EDU Summit at Pycon 2015 in Montreal! All of the presentations where both simulating and inspiring, and the combination of topics was very well orchestrated. Now let's see if we can get something to happen within our community between now and the next EDU Summit. I'm most interested in two specific things: 1. Improvements to IDLE to make it a more effective beginners learning tool. Al Sweigart presented a very well thought out plan for this in his talk. To his list I would only add being able to save graphics artifacts generated by the turtle module as svg files. 2. Improving out presence on the python.org website. Both Dr. Chuck and Van Lindberg had great suggestions for improving our web presence. I think what is lacking now is a plan to find and allocate the resources it would require to make things happen. Thanks again, Jessica and Chalmers! Jeff

1 0

Fwd: Python in Education published by O'Reilly
by Phillip Kent 12 Apr '15

12 Apr '15

Hi Nicholas. Great writing. Well done. I'd like to add one idea: disruptive potential. For me, one of the strengths of Python is that the features you describe combine together to give it a high disruptive potential, in the sense which I wrote about here.. http://www.phillipkent.net/blog/maximising-disruptive-potential-programming "....The most valuable consequences of programming are those which disrupt conventional relationships of people with knowledge and ideas, and (therefore) to disrupt the conventional relationships between people and other people. Therefore the best programming language to select is the one that will maximise the disruption to established practices...." As a teacher, you well understand how educational systems are weakened by intellectual divisions and tribalism. That's why we need disruptive potential for educational computing. - Phillip On Sat, Apr 11, 2015 at 1:07 PM, Nicholas H.Tollervey <ntoll(a)ntoll.org> wrote: > Hi, > > In case you missed it, my FREE short report "Python in Education" was > published yesterday by O'Reilly. There's an extract from it here (on > O'Reilly Radar): > radar.oreilly.com/2015/04/five-reasons-why-python-is-a-popular-teaching-lan… > > You can download the complete work in various digital format from here: > http://www.oreilly.com/programming/free/python-in-education.csp > > Alternatively, if you're currently at PyCon you can grab a dead-tree > version from the O'Reilly booth. I believe it'll also be available IRL > at OSCON. > > All feedback most welcome! > > Best wishes, > > N. > > > _______________________________________________ > Edu-sig mailing list > Edu-sig(a)python.org > https://mail.python.org/mailman/listinfo/edu-sig >

1 0

Python education summit open space today at 2.30 to 4.00
by Chalmer Lowe 11 Apr '15

11 Apr '15

If you python, if you educate... Please come see us today at room 513d from 2.30 to 4.00. Love to continue our education summit conversations.

1 0

Python in Education published by O'Reilly
by Nicholas H.Tollervey 11 Apr '15

11 Apr '15

Hi, In case you missed it, my FREE short report "Python in Education" was published yesterday by O'Reilly. There's an extract from it here (on O'Reilly Radar): radar.oreilly.com/2015/04/five-reasons-why-python-is-a-popular-teaching-lan… You can download the complete work in various digital format from here: http://www.oreilly.com/programming/free/python-in-education.csp Alternatively, if you're currently at PyCon you can grab a dead-tree version from the O'Reilly booth. I believe it'll also be available IRL at OSCON. All feedback most welcome! Best wishes, N.

1 0

Post Mortem (Bridges submission)
by kirby urner 10 Apr '15

10 Apr '15

My 3-page paper concluding with the graphic rendered by this source code: https://mail.python.org/pipermail/edu-sig/2015-March/011203.html (Python + POV-Ray) was roundly rejected by the Bridges reviewers. http://bridgesmathart.org/ "Citations are to Wikipedia pages, or peculiarly to the author's undergraduate philosophy thesis on Wittgenstein." says REVIEW 1, as a reason for rejection. Yes, just to the one Wikipedia page, where I get two graphics: a Wikipedia page I wrote most of, and the graphics were mine, contributed by me. Compare: http://wikieducator.org/Synergetics http://en.wikipedia.org/wiki/Synergetics_%28Fuller%29 "The paper is not formatted according to Bridges guidelines, as found on the Bridges website." They say it's about Art but papers are not part of the Art. The Art goes on a pedestal somewhere in the viewing chambers. The paper must conform, not express individuality or the artist's idiosyncrasies (cite "peculiarly"). REVIEW 2: "The paper first reminds us (in a very complicated way) that the volume of a tetrahedron with edge-length 2 is 0.9428. But after that it is not clear, what this paper is trying to tell us." What it's trying to tell you is that volume is 1.00000 in Synergetics because 3rd powering is modeled as an extrapolation of this treatment of A X B: https://youtu.be/2B1XXV2Eoh8 A x B x C is modeled as 3 edges from the origin of a regular tetrahedron. The lid defined by the three lengths defines a volume. When all edges are D (2R, 2 x radius of the unit-radius balls), that's Unit Volume. So we need a conversion constant: SQRT(9/8). That's in the published literature. I cited Dr. Bob Gray on that one. Review of the reviews: shows no comprehension of Synergetics which, having been published in the 1970s, is not something we should still be so clueless about, especially at a Math + Art conference. My confidence in the Bridges review process was never very high. I look forward to sharing these negative reviews as symptomatic of institutional retardation. Here's the paper, feel free to take a look: http://4dsolutions.net/synergetica/bridges_paper_final.pdf Read and make up your own mind. "The paper unfortunately does not give this reader any confidence that the author knows how to communicate clearly, which is important for Bridges conference purposes." REVIEW 1. Kirby

2 3

Code.org puzzle solving activities in Python
by Jurgis Pralgauskis 07 Apr '15

07 Apr '15

https://github.com/skilstak/code-dot-org-python -- Jurgis Pralgauskis tel: 8-616 77613; Don't worry, be happy and make things better ;) http://galvosukykla.lt

1 0