Mailman 3 April 2019 - Edu-sig

Part-time opportunities for Python instructors
by Merav Yuravlivker May 7, 2024

May 7, 2024

Hi there, My name is Merav Yuravlivker, and I'm the CEO of Data Society - we deliver data science academies to Fortune 500 companies, government agencies, and other international organizations. We're currently looking for part-time Python instructors and TAs, and my friend Jackie Kazil recommended I reach out to you and your list serv. All of these opportunities can be available for people who are employed full-time, professors, or grad students. We pay well and provide all the materials for … [View More]

6 5

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 … [View More]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 [View Less]

8 17

MineCraft with Python
by Jurgis Pralgauskis Dec. 4, 2022

Dec. 4, 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, … [View More]

6 6

what is 'self'? (plus link to Trey's article on callability)
by kirby urner April 16, 2019

April 16, 2019

If we're ever at a loss for what to talk about, in this context, of Python teachers, I could recommend a list of default topics, one of which would always be... What is this 'self'? The self appears right when we introduce the class construct (keyword class). And then we say things like "Python provides it" or "Python fills it in". What is "it" then? "It" is "the instance". For some, things are starting to get muddy. For coders familiar with OOP style grammars i.e. they're coming from … [View More]another language such as JavaScript or Java (quite different I realize), they've got a sense of it, from keyword 'this'. However Python is widely touted as a gateway language into OOP style thinking, so we get a lot of first timers. We owe them a clear picture of self. One andragogical technique comes straight from the docs: instance = C() C.method(instance) # <-- needs instance as argument is equivalent to: instance = C() instance.method() # <-- instance is "subject" as in subject.verb() ... of course we may add additional arguments at will, but lets keep it simple. In OOP, all the selves share the same template or class code, so how is Python to distinguish one self from another? It's not like each self is carrying around a copy of the method code. The model is more like having DNA in common (a shared genetic core). As in: class Creature: def eat(self, food): # <--- needs to know which self self.stomach.append(food) With: instance.eat("spaghetti") # <-- self known to Python we have enough info to figure out which self, and Python obligingly brings it forward, to fill the placeholder, usually 'self'. With: Creature.eat(instance, "spaghetti") # self supplied by the caller we're not giving enough distinguishing information with generic Creature, and so instance has to be provided, as the self. Further andragogical elaboration involves showing what I mean by "usually 'self'" i.e. self is not a keyword but a placeholder. Here I tend to go for a Chinese character substitute, e.g. for "Ego", to remind the learner of Unicode in addition. Emoji can't be Python names or I might go for one of them. * * * Another good article by Trey Hunner just came out. He's one of the more prolific Python teachers *that I know about* (an important caveat as I'm always missing *a lot*): https://treyhunner.com/2019/04/is-it-a-class-or-a-function-its-a-callable/ He takes up the issue of "callables that are functions" versus "callables that are actually types (classes)". That can help with fine tuning one's sense of what a "type" is, plus callability in general is a bridge to decorators, and this article definitely goes there. Kirby [View Less]

2 4

What is an "object"?: Polyhedrons & OOP
by kirby urner April 10, 2019

April 10, 2019

Of course the literature contains numerous definitions. A similar question might be "what is a noun?". Objects are "that which the nouns name" in the Pythonic paradigm. They (the objects) live in memory at id() addresses ("like street addresses" I might tell my students). However, impressionable minds need more to hang a hat on that just boring grammar words (like "noun"). In UML (universal markup language) we have our customary symbols and diagrams: https://atomicobject.com/resources/oo-… [View More]programming/abstraction-and-identity I often use a Creature -> Animal -> Mammal -> subclasses of Mammal taxonomy, when introducing inheritance and what we call the MRO (method resolution order). Another association of "object" we might build upon is "polyhedron" or "that which has shape". class Polyhedron: def __init__(self, v, f): self.v = v self.f = f self.e = v + f - 2 # euler's law for polyhedra def scale(self, factor): """ scale volume by factor, beget a new poly """ return type(self)(vol = self.volume * factor) __mul__ = __rmul__ = scale class Tetrahedron(Polyhedron): def __init__(self, vol=1): super().__init__(v=4, f=4) self.volume = vol class A(Tetrahedron): def __init__(self): super().__init__(vol=1/24) class B(Tetrahedron): def __init__(self): super().__init__(vol=1/24) # etc. (S, E, T) class Cube(Polyhedron): def __init__(self, vol=3): super().__init__(v=8, f=6) self.volume = vol class Octahedron(Polyhedron): def __init__(self, vol=4): super().__init__(v=6, f=8) self.volume = vol etc. (longer list of subclasses). If the Learning to Code curricula were to feature more source of this nature, we could facilitate reaching out to the geometry teachers with an intuitive picture of "dot notation" as a means of accessing "containers" of a very literal kind, if abstract. Associations around "object" have something concrete to build on, adding generic methods such as rotate() -- about what axis? -- and translate() -- for moving the shape relative to others, or to an origin (could involve creating a new shape at the new place, relative to the old). We could easily add surface area as another attribute, along with default edge length corresponding to our default volumes (YMMV in terms of what defaults your curriculum chooses). Indeed this is the right place to emphasize the power law, that changing all edges by a factor of n, e.g. doubling them (n=2) changes area by n**2 and volume by n**3. A selling point of the simple code base shown above is I'm not trying to do anything vectorial yet i.e. the shapes are so far coordinate free. We're free to turn to actual physical models and other media besides source code, to flesh out the concepts we're talking about. OO wins. Geometry wins. Dot notation wins. Python wins. I've been taking this tack in my Youtubes lately, building up a stash for a science fiction time when these ideas are more mainstream. Not that this focus on Polyhedrons as paradigm objects is all that esoteric. Square and Circle types have been common in textbooks at least. There's a bias against "3D" and I suppose that's what I'm countering, as speaking experientially, we do not live in Flatland. The approach to coding I'm advocating is also encouragement for spatial, not just planar, visualizations. Euclidean proofs may be more involved, however we have other generalizations such as Euler's Law for Polyhedra and Decartes' Deficit to introduce. Having the OO experience tie in with spatial geometry more intimately provides greater opportunities for imaginative play, and exercises the computing machinery in ways it's already very good at. Kirby [View Less]

1 0