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

MineCraft with Python
by Jurgis Pralgauskis Dec. 3, 2022

Dec. 3, 2022

Hi, intro: many kids like MineCraft :) probably you know/heared of MineCraft Pi https://www.raspberrypi.org/learning/getting-started-with-minecraft-pi/ But there seems to be Py for real MC http://coderdojotc.readthedocs.io/projects/python-minecraft/en/latest/ http://www.instructables.com/id/Python-coding-for-Minecraft/ PS.: a nice article (from js4MC world) https://github.com/walterhiggins/ScriptCraft/blob/master/docs/YoungPersonsG… -- Jurgis Pralgauskis tel: 8-616 77613; Don't worry, be happy and make things better ;) http://galvosukykla.lt

6 6

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

Using real world functions to teach arg passing
by kirby urner April 23, 2018

April 23, 2018

I'm becoming increasingly aware that the flood of new Python users we're enjoying has everything to do with articles such as this one in Atlantic Monthly last month: https://www.theatlantic.com/science/archive/2018/04/the- scientific-paper-is-obsolete/556676/ I've appended a couple quotes from it. I enjoyed another perspective on the "Mathematica versus Open Source" face-off (Python's ecosystem in particular) in my joining what had been a Mathematica-focused company (Netmath) that then morphed into a Python teaching company (the O'Reilly School of Tech.). I joined after the Netmath chapter, but the purchased company was still working to make Mathematica a more popular front end by developing a product named Hilbert. https://www.cnet.com/news/oreilly-taking-mathematica-online/ Hilbert did the job it was supposed to, and we offered some calculus, but that's not where the market turned out to be. People were flooding into Python, still are. These days I'm all about what the article talks about: Jupyter Notebooks and the various tools it works with. Here's my latest thinking: When first introducing argument passing to functions, along with defining function parameters, using * and ** in particular (as scatter-gatherers) that's the right time to start using some of these fancy 3rd party packages like matplotlib and numpy, for your examples. Your average Python student is like a grad student in physics or statistics. They have lots of STEM skills and just want to get on with it efficiently, without getting side-tracked into investing a huge number of hours in a computer language (approximately the same user profile Guido encountered at Stichting Mathematisch Centrum -- ABC users -- i.e. the language attracts those for whom it was designed). If you get to such as numpy.random.random and matplotlib.pyplot.hist right away (with the appropriate abbreviations), that's like fresh air, oxygen, what they've come for in the first place, so why delay? Sure it's fine to show a couple functions like this for starters: def F(*args, **kwargs): print(args, kwargs) ... but then visit the docs and start showing actual function signatures of the Pyladies and such are *really* using. Build a dict of arguments and pass it with **. """ Three ways to say the same thing """ import numpy as np import matplotlib.pyplot as plt from inspect import signature # some data x = np.arange(0,10) y = np.random.randint(0, 5, size=10) plt.subplot(311) plt.plot(x, y, 'go--', linewidth=2, markersize=12) plt.subplot(312) plt.plot(x, y, color='green', marker='o', linestyle='dashed', linewidth=2, markersize=12) plt.subplot(313) params = {'color':'green', 'marker':'o', 'linestyle':'dashed', 'linewidth':2, 'markersize':12} print(signature(plt.plot)) plt.plot(*(x,y), **params) Side topic: some Python instructors think "keyword arguments and parameters" is a bit confusing given we also have what're called the "Python keywords" (in keyword.kwlist -- except not async or await for some reason, even in 3.6, I guess because local to a namespace?). They prefer "named arguments". However that suggests positional arguments are "unnamed" which isn't quite right either. If there's no *args to scoop up positionals first, dicts work to populate 'em, by name: In [147]: def F(x, y, *, z): ...: print(x, y, z) In [148]: kwargs = {'y':10, 'x':'A', 'z':100} In [149]: F(**kwargs) A 10 100 Even though we don't typically build dicts simply for the sole purpose of passing named arguments in our matplotlib or numpy tutorials, I think we should do that more in classes where core Python is still a focus. In other words, don't "save the best for last". Start using the best right from the top, to teach Python basics. Everyone can relate to a histogram or two, perhaps drawn at random from some normal distribution. Or plot real data why not? Keep it topical in some way. [ The data don't have to be dismal either (so much of stats tries to be "meaningful" in ways I consider less important than using a realistically complicated API). ] I'm working on moving in this direction for my courses in May. In June, I'm hoping to teach high school and middle schoolers how to use Jupyter Notebooks in the context of introducing what I call Martian Math. If you've been on this listserv for awhile, you know it's a pet topic of mine. We'll be using Anaconda on Windows. Kirby PS: I won't be making it to Cleveland this year, but I'm vicariously a participant in living close to where This is the Bus -- a Pythonista-modified school bus ala Ken Kesey that will feature in one of the Cleveland Pycon talks -- is starting from. Here's its picture, with more next to it if you click in Flickr: https://flic.kr/p/JcUt3E >From Atlantic Monthly: Python became a de facto standard for scientific computing because open-source developers like Pérez happened to build useful tools for it; and open-source developers have flocked to Python because it happens to be the de facto standard for scientific computing. Programming-language communities, like any social network, thrive—or die—on the strength of these feedback loops. ... "I think what they have is acceptance from the scientific community as a tool that is considered to be universal,” Theodore Gray says of Pérez’s group. “And that’s the thing that Mathematica never really so far has achieved.” There are now 1.3 million of these notebooks hosted publicly on Github. They’re in use at Google, Bloomberg, and NASA; by musicians, teachers, and AI researchers; and in “almost every country on Earth.”

1 0

Re: [Edu-sig] Simplest webapps
by Andrew Harrington April 9, 2018

April 9, 2018

Bottle sound like it makes things very simple. I also have a chapter introducing server-side Python interaction in very simple cases. http://anh.cs.luc.edu/python/hands-on/3.1/handsonHtml/ch4.html It does come well after function introduction. Dr. Andrew N. Harrington Computer Science Department Graduate Program Director gpd(a)cs.luc.edu Loyola University Chicago 207 Doyle Center, 1052 W Loyola Ave. http://www.cs.luc.edu/~anh Phone: 773-508-3569 Dept. Fax: 773-508-3739 aharrin(a)luc.edu (as professor, not gpd role) On Sat, Mar 31, 2018 at 8:20 PM, Wes Turner <wes.turner(a)gmail.com> wrote: > Web programming is fun but dangerous. > Things as simple as 'it reads a file off the disk and sends it to the > user' can unintentionally expose every readable file to whoever or whatever > can access localhost. > > ```python > os.path.join('here', '/etc/shadow') > path = 'here/' + '../../../../etc/shadow' > ``` > > All of the examples in this thread are susceptible to XSS (Cross Site > Scripting) and CSRF (Cross-site Request Forgery). Don't feel bad; many > college web programming courses teach dangerous methods, too. > > XSS: > ``` > x = """</body><script>alert('download_mining_script()')</script>""" > return f'<html><body>{x}' > """ > > Bottle has multiple templating engines which escape user-supplied input > (in order to maintain a separation between data and code). > > Like XSS, SQLi is also a 'code injection' issue. pypi:Records can use > SQLAlchemy. Django is a great framework with a built-in ORM that also > escapes SQL queries. > > CSRF: > - X posts an XSS to site A that POSTs to site B > - 100 users view site A > - [...] > > http://bottle-utils.readthedocs.io/en/latest/csrf.html > > https://bottlepy.org/docs/dev/tutorial.html#html-form-handling > > OWASP has a lot of information on WebSec: > > OWASP Top 10 > https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project > > The OWASP Vulnerable Web Applications Directory Project (VWAD) > https://github.com/OWASP/OWASP-VWAD > > Any program or user on the system can read and write to localhost. > > > On Saturday, March 31, 2018, Wes Turner <wes.turner(a)gmail.com> wrote: > >> Bottle is a single file web microframework. >> >> https://github.com/bottlepy/bottle >> https://github.com/bottlepy/bottle/blob/master/bottle.py >> >> > Example: "Hello World" in a bottle >> >> ```python >> from bottle import route, run, template >> >> @route('/hello/<name>') >> def index(name): >> return template('<b>Hello {{name}}</b>!', >> name=name) >> >> run(host='localhost', port=8080) >> ``` >> >> There are docs and every function is Ctrl-F'able within bottle.py. >> >> On Friday, March 30, 2018, kirby urner <kirby.urner(a)gmail.com> wrote: >> >>> >>> Very interesting. I note that free users are relegated to Python 2.7 >>> >>> Server modules can be Python 3.6 (outside the free version) >>> >>> Client stuff compiles to JavaScript and is approximately 2.7 >>> >>> That's a bit confusing maybe. I try to avoid 2.7 but that's not easy. >>> >>> In my Coding with Kids work, we use Codesters.com to teach Python, which >>> depends on Skulpt. Also 2.x ish. >>> >>> Kirby >>> >>> >>> >>> On Fri, Mar 30, 2018 at 11:49 AM, Jason Blum <jason.blum(a)gmail.com> >>> wrote: >>> >>>> http://anvil.works/ is a pretty interesting approach to Python web >>>> applications. >>>> >>>> On Fri, Mar 30, 2018 at 2:05 PM, kirby urner <kirby.urner(a)gmail.com> >>>> wrote: >>>> >>>>> >>>>> Hi Aivar -- >>>>> >>>>> I think it's a fine idea to write simple Python scripts that write >>>>> HTML files, which you may then pull up in the browser. >>>>> >>>>> There's no need to put a server behind static web pages. So, for >>>>> example, I'll have my students write a page of bookmarks: >>>>> >>>>> # -*- coding: utf-8 -*- >>>>> """ >>>>> Created on Wed Nov 4 18:02:30 2015 >>>>> >>>>> @author: Kirby Urner >>>>> """ >>>>> >>>>> # tuple of tuples >>>>> bookmarks = ( >>>>> ("Anaconda.org", "http://anaconda.org"), >>>>> ("Python.org", "http://python.org"), >>>>> ("Python Docs", "https://docs.python.org/3/"), >>>>> ("Spaghetti Code", "http://c2.com/cgi/wiki?SpaghettiCode"), >>>>> ("Structured Programming", "http://c2.com/cgi/wiki?Struct >>>>> uredProgramming"), >>>>> ("Map of Languages", "http://archive.oreilly.com/pu >>>>> b/a/oreilly//news/languageposter_0504.html"), >>>>> ("XKCD", "http://xkcd.com"), >>>>> ) >>>>> >>>>> page = '''\ >>>>> <!DOCTYPE HTML> >>>>> {} >>>>> ''' >>>>> >>>>> html = """\ >>>>> <HTML> >>>>> <HEAD> >>>>> <TITLE>Bookmarks for Python</TITLE> >>>>> </HEAD> >>>>> <BODY> >>>>> <H3>Bookmarks</H3> >>>>> <BR /> >>>>> <UL> >>>>> {} >>>>> </UL> >>>>> </BODY> >>>>> </HTML> >>>>> """.lower() >>>>> >>>>> the_body = "" >>>>> for place, url in bookmarks: >>>>> the_body += "<li><a href='{}'>{}</a></li>\n".format(url, place) >>>>> >>>>> webpage = open("links.html", "w") >>>>> print(page.format(html.format(the_body)), file=webpage) >>>>> webpage.close() >>>>> >>>>> All you need add to your example is using print() to save to a file, >>>>> so the browser has something to open. >>>>> >>>>> I would not call this a "web app" yet it's instructive in showing how >>>>> Python can write HTML files. >>>>> >>>>> Kirby >>>>> >>>>> >>>>> >>>>> On Wed, Mar 28, 2018 at 12:18 AM, Aivar Annamaa <aivar.annamaa(a)ut.ee> >>>>> wrote: >>>>> >>>>>> Hi! >>>>>> Let's say my students are able to write programs like this: >>>>>> >>>>>> name = input("name") >>>>>> >>>>>> if name == "Pete": >>>>>> greeting = "Hi" >>>>>> else: >>>>>> greeting = "Hello!" >>>>>> >>>>>> print(f""" >>>>>> <html> >>>>>> <body> >>>>>> {greeting} {name}! >>>>>> </body> >>>>>> </html> >>>>>> """) >>>>>> >>>>>> I'd like to allow them start writing web-apps without introducing >>>>>> functions first (most web-frameworks require functions). >>>>>> >>>>>> It occurred to me that it's not hard to create a wrapper, which >>>>>> presents this code as a web-app (input would be patched to look up >>>>>> GET or POST parameters with given name). >>>>>> >>>>>> This approach would allow simple debugging of the code on local >>>>>> machine and no extra libraries are required in this phase. >>>>>> >>>>>> Any opinions on this? Has this been tried before? >>>>>> >>>>>> best regards, >>>>>> Aivar >>>>>> >>>>>> _______________________________________________ >>>>>> Edu-sig mailing list >>>>>> Edu-sig(a)python.org >>>>>> https://mail.python.org/mailman/listinfo/edu-sig >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Edu-sig mailing list >>>>> Edu-sig(a)python.org >>>>> https://mail.python.org/mailman/listinfo/edu-sig >>>>> >>>>> >>>> >>>

5 4

Simplest webapps
by Aivar Annamaa March 31, 2018

March 31, 2018

Hi! Let's say my students are able to write programs like this: name = input("name") if name == "Pete": greeting = "Hi" else: greeting = "Hello!" print(f""" <html> <body> {greeting} {name}! </body> </html> """) I'd like to allow them start writing web-apps without introducing functions first (most web-frameworks require functions). It occurred to me that it's not hard to create a wrapper, which presents this code as a web-app (input would be patched to look up GET or POST parameters with given name). This approach would allow simple debugging of the code on local machine and no extra libraries are required in this phase. Any opinions on this? Has this been tried before? best regards, Aivar

6 7