We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Teaching Python

00:00

Formal Metadata

Title
Teaching Python
Title of Series
Part Number
44
Number of Parts
119
Author
License
CC Attribution 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Identifiers
Publisher
Release Date
Language
Production PlaceBerlin

Content Metadata

Subject Area
Genre
Abstract
Robert Lehmann - Teaching Python Using Python in bringing people closer to programming has been popular for a while. But what are the most effective ways to do so? The OpenTechSchool reports. ----- Python has been used in educational programmes ever since. With a bandwidth that large, navigating the landscape of Python tutorials is hard indeed. This talk will look at successful Python teaching material. From the numerous iterations our material has gone through, we draw conclusions on what's crucial in teaching Python. It will introduce how the OpenTechSchool is teaching Python and what measures it found most effective in spreading programming in general and Python in particular. Among these are rapid feedback, supervised learning, localization, and knowing your target audience. The author is a member of the OpenTechSchool, a free community initiative which offers Python workshop on a number of topics. Some of the workshops have been running for more than two years now. He has written the first versions of "Python for beginners," a workshop which has been used in many cities to teach Python to programming novices.
Keywords
80
Thumbnail
25:14
107
Thumbnail
24:35
Slide ruleLink (knot theory)Lecture/Conference
Open setDirection (geometry)Absolute valueFormal languageMultiplication signProgrammer (hardware)Open setDigitizingForm (programming)WebsiteMeeting/Interview
Direction (geometry)Theory of relativityRight angleElectronic program guideQuicksortComputer animation
AlgebraRaw image formatCalculusString (computer science)IntegerString (computer science)CalculationPattern languageLengthFitness functionComputer programmingRight angleRaw image formatProgrammer (hardware)Interpreter (computing)AlgebraModule (mathematics)Escape characterVulnerability (computing)XML
Programmable read-only memoryUniform resource nameWebsiteBuffer overflowComputer programQuotientMenu (computing)Surjective functionComa BerenicesRow (database)Thermische ZustandsgleichungUniform boundedness principleMountain passInfinityFingerprint3 (number)VarianceMUDComputer iconExecution unitSummierbarkeitProjective planePhysical systemComputer programmingFormal languageTwitterStack (abstract data type)FamilyTotal S.A.Buffer overflowAnalytic continuationLecture/ConferenceSource codeXML
TwitterUniverse (mathematics)Object-oriented programming1 (number)Programmer (hardware)Object (grammar)Inheritance (object-oriented programming)Computer animationLecture/Conference
Fault-tolerant systemComputer animation
MereologyStrategy gameStudent's t-testRange (statistics)Process (computing)Point (geometry)Mobile WebSubject indexingVariable (mathematics)Functional (mathematics)String (computer science)Connectivity (graph theory)Programmschleife2 (number)Loop (music)Thread (computing)Computer animation
Point (geometry)Turtle graphicsOpen setComputer animation
Turtle graphicsTurtle graphicsFeedbackTotal S.A.Staff (military)ConsistencyWritingState of matter
Turtle graphicsAdditionTotal S.A.Turtle graphicsLecture/Conference
Formal languageFormal languageObject (grammar)Open setLecture/ConferenceDiagram
Formal languageRevision controlPrime idealSet (mathematics)Translation (relic)AreaGroup actionRun time (program lifecycle phase)CASE <Informatik>Decision theoryWorkstation <Musikinstrument>Information securityLecture/ConferenceUMLDiagram
Software developerFormal languageSet (mathematics)Group actionTranslation (relic)Execution unitProcess (computing)Musical ensembleLecture/Conference
Direction (geometry)Programmer (hardware)Context awarenessComputer programmingLecture/Conference
SummierbarkeitLatin squareText editorComputer fileRevision controlDecision theoryGastropod shellInteractive televisionSlide ruleElectronic mailing listRight angleLecture/ConferenceXMLComputer animation
Computer fileMultiplication signOpen setProcess (computing)Point (geometry)Error messageCausalityLecture/Conference
Computer fileReading (process)RectangleTurtle graphicsRight angleRange (statistics)AbstractionPoint (geometry)Electronic program guideStrategy gameContext awarenessRectangleElectronic data processingObject (grammar)Programmer (hardware)Functional (mathematics)LeakCodeMultiplication signComputer fileProcess (computing)Statement (computer science)Right angleSingle-precision floating-point formatIntegerOpen setMoment (mathematics)Field (computer science)WordSource codeConstructor (object-oriented programming)Slide ruleArmStaff (military)Profil (magazine)Computer animation
Open setRight angleProgrammschleifeInheritance (object-oriented programming)Object (grammar)LaptopNeuroinformatikWordPoint (geometry)outputSoftware developerFormal languageRectangleReferenzmodellMathematical analysisSampling (statistics)Kritischer Punkt <Mathematik>Set (mathematics)Integrated development environmentDifferent (Kate Ryan album)Functional (mathematics)Semiconductor memoryOrder (biology)State of matterQuicksortComputer programmingCellular automatonForm (programming)Loop (music)Asynchronous Transfer ModePoisson-KlammerMultiplication signBitLevel (video gaming)Data structureProgramming languageVariable (mathematics)Lecture/Conference
SoftwarePoint (geometry)Total S.A.FeedbackError messageExplosionTurtle graphicsWordMessage passingInterpreter (computing)File systemComputer programmingSoftware developerReal numberEducational softwareCASE <Informatik>Figurate numberProjective planeMereologyClosed setAbstractionRight angleVapor barrierAnalogyEndliche ModelltheorieInheritance (object-oriented programming)Functional programmingData structureLoop (music)Event horizonNumberFormal languageMoment (mathematics)Row (database)Network topologyRevision controlMultiplication signPhysical systemCovering spacePressureGradientArrow of timeQuicksortFunctional (mathematics)Lecture/Conference
Lecture/Conference
Transcript: English(auto-generated)
Thank you very much, thank you very much for coming. How do you all like Berlin?
Great? Slides don't advance, shit. How do you like Berlin? Yeah, great, cool. So I've been to a workshop last week of the Open Tech School, that's where I'm a member. And the Open Tech School does workshops
for teaching absolute beginners to programming, how to program in Python and other languages. How we do this is we gather a bunch of people, among them coaches who are knowledgeable Python programmers who know how to program, and learners who want to learn how to program. They have very different backgrounds,
mostly non-technical people. Then we give them material in digital form mostly, so websites they can browse, and two hours of time to browse and work on the material and the exercises. So last week I was on such a workup and was walking down the streets afterwards,
and after the workshop I reached some kind of funky place in Berlin and I saw this. And said, I was like, what? Why would anyone, I mean this is the one style guide we all love and adhere to. And yeah, you can take pictures,
I can show you afterwards where it is, maybe. So somebody apparently was very set up about Python style guides and adhering to coding style.
So I took a look at the Python material we currently have, like the tutorials and stuff, and if you look at the very official Python tutorial, it starts off with talking about calculations and stuff and how do you add two integers to each other, how to do basic algebra. It stops with some funky stuff about weak references
and that's pretty advanced for a tutorial, but okay. So I scrolled through it and what do you guys think, where does it talk about the immutability of strings, for example? Just random guesses. To the end, to the middle, beginning? Middle, I hear middle, no, wrong, wrong.
It's at the very beginning, it's the third chapter actually, like right after talking about how do we add two integers, they go about talking about text and strings and like how do I do raw strings and escapes and how do I repeat literals of strings,
like some arcane features not even experienced Python programmers ever use. And the Python tutorial just goes about and talks about that in length and very detailed. It gets even worse. At the beginning of the tutorial, the very first sentence you read in the Python tutorial is hey, you can start the Python interpreter with dash m
to import a module or dash c to invoke the command line or dash i to do interactive sessions. So and if I gave that to a beginner in our workshops, they would be like, dash what? Nobody would understand that. I had a look at Stack Overflow,
so there was some guy asking, hey, I'm trying to teach my brother or sister or someone how to program and he wanted to use Python. And he asked about what is the best example project, example thing I can give them? What do you think? Where would you start with a beginner? Any guesses?
What? Total graphics, pretty good. Anybody else? Databases, yeah, just shout that out. Yeah, for kids, that's pretty good, yeah. Do you know what Stack Overflow started with? Yeah, just teach them FizzBuzz.
And I was like, what, why would you? I mean, yeah, FizzBuzz is a nice interview question, but why would anyone teach a beginner how to do FizzBuzz? I mean, having hello world or FizzBuzz on your command line is pretty nice, but not the best thing to learn programming, right? And the trend continues. If you look at the Python books which are out there,
like the material universities have, for example, the MIT starts with object-oriented programming. This is the MIT SICP 16001 course. This is the very beginning to programmers and they start talking about objects and inheritance and stuff. So that's pretty funky and so what you can observe
is that the general trend in the Python community is to write references. So everybody wants to be a reference. Like, everything needs to be correct and very, very right and very Pythonic and stuff. And I understand that some people react very badly on this. So if you take anything out of this session today,
it is that references are not tutorials. These are two very different and distinct concepts. I would even say they are disjoint. And do not intermix them. These are very different and require a different approach. So everybody speak up for me? References are not tutorials? Very good, very good. Great, you're doing great.
Best audience I have ever had today. So I tried to come up with some points like what would I say is a reference and what would I say is a tutorial. So in a reference you try to be very correct. Like every single thing you say should be correct. There should be nothing where somebody could come and say, no, this is wrong.
Like, this is clearly not true. Also in a reference you would always try to be complete. So I can well understand why the Python tutorial went about and talked about strings in depth because it was a reference, right? It tried to examine strings and it tried to tell you everything it knows about strings like they're immutable, you can slice and dice them
and you can count how long they are and all that kind of stuff. And also most Python references try to be idiomatic, right? So for example if you wanted to introduce loops to a beginner then you would not want to introduce while loops with index variables and stuff but you would want to use the for loop with a range function, right?
I think this is the wrong approach for tutorials. For tutorials you want to do a very different approach. You want to be comprehensible so that people can actually understand what you're talking about. You want to be coherent so that there's like a fine thread woven through the whole tutorial. And sometimes you want to be eiotic.
That might sound strange right now but I'll come to this in a second. So let's talk about these points in depth and you'll maybe understand where the distinction comes from and how it makes sense. So I said tutorials need to be comprehensible. So one point I always try to make in tutorials
is that it needs to be graphical or it needs to be hands on. You need to see something, you need to feel something. In the Open Tech School we use turtle for that. So somebody suggested turtle for teaching Python already, that's a great tool, use it. You can, I mean, most of you know turtle, right? Quick show of hands, who knows turtle? That's about 90% of the room I would say
or 99 or something. So turtle is a very nice tool for teaching Python because you can instantly see stuff and you can get instant feedback which is very great. Now some people come to me when I suggest using turtle and they say, ah Robert, listen up. I know turtle is pretty nice and it's like very old
and people know how to use it but it's so childish. Nobody wants to use it. This is for little children. Why would I want to teach this to adults? Which is always when I say no, it's not. It's, so experience has shown that when we show the turtle or turtle material to adults,
they react like this, they go, yeah, it's pretty childish but let me play with it. So they spend two hours playing with it and instantly forget it's for children. It's very funny. Another thing to be comprehensible is using their language. This applies to like any tutorial, not only Python tutorials of course,
so that you don't speak about like objects in the very beginning but maybe you want to use things instead because people can understand what the thing is, right, the thing is maybe a car or a person but an object. Like this is a very abstract concept and try to use their language, not their, not your concept of the world.
Another thing is use their language. So in the open text school, we translate our material and this might come very obvious to most of you but very few people actually do it. Like translating tutorials is still something I would say very few people do and it's pretty important because you can do a lot of things wrong with it. So you can, the one prime example about translations
I always have is culturally. So when you talk about, let's say, buying something for US dollars, then it might not be obvious what that means to Chinese people or to European people, for example. So you want to translate that as well. It's not like only one-to-one translations.
Other things you have to watch out is for is that using mockup in translation is very hard. I can only recommend things for that but disclaimer, I'm involved with that so use whatever you want. And the last thing about translations I want to say is try to have one master set of translations.
We've had translations where we had like a German version and an English version and they kind of diverged and we had two different versions and we didn't know, okay, this fix was applied to the German one but was it applied to the English one? I don't know. Well, so try to have the English or whatever language you prefer as a master set of translations
and always apply fixes to that and then translate them back into the other material. So we've spoken about how to make material comprehensible like the individual units but how do I make it so that it's a whole different story like one thing.
So very much like in music, you need to have something which is the main voice of it. So you need some kind of story which you wrote through it so that is not only in the material itself but also in the process of making the material. We've had material where we had a lot of people
contributing to it, so to say, a lot of voices and it kind of got very noisy so the material diverged into very many directions and tried to have one main voice who says, okay, this material goes into that direction and this is out of scope, this is in scope.
One thing we programmers very rarely think about that is when we write hello world or when we write any example in programming, we very often have a big context of concepts around it which we programmers don't think about because we know it but other people have to be told what to do
like which editor do I use, which encoding do I use. This is not obvious. This is also very easy like you can tell them use whatever editor but when it comes to other questions like which version do I use, people tend to say, yeah, just use free or Python 2 or whatever. Make the decision. You are the informed person
who can make the decision, not the learner. The very critical thing I have seen learners struggle with is the distinction between files and the shell. So when you have the interactive shell, it's pretty nice for trying things out but you want to have one point in the teaching process where you tell them, okay, this was nice,
let's go to files because it's much better to maintain that stuff but have that one point. In our material, in the open tech school, we made the error that we kind of left it open for the learner to decide where they, at which point in time they want to switch to files and so you never knew,
does that learner already know about files? Why does he use them? Does he use them? You never know. So pay attention for that. It's a very critical distinction which we intuitively make but normal people, so to say, don't. The last point is probably the most confusing
and surprising one but I think tutorials sometimes need to be idiotic. So when you think about, I use this idiom and this style guide and whatever and this, the one true, right way to do it, forget about it. It's all bullshit. I've seen people suggest very true stuff
in the sense that it is sane for a programmer but not for a learner. For example, take this suggestion. We had one material which was about data processing and it needed to open and close files to read from them and somebody came along and said, ha, well, using the open function for files
is not the best way to handle it because you can leak resources and stuff so let's use the with construct which is a very true objection but is not helpful in the context of learning how to process data because opening files was not the main context. It was not the main goal. People wanted to learn a little about data processing,
not the with construct. This was not the objective. My favorite exercise I always do with beginners is this one. I give them the exercise draw a rectangle and they will happily oblige by writing code like this. You move the total forward, you move it to the right
and do that four times and then you have a rectangle and then I tell them, okay, that was great. Now draw three rectangles. So they will go and copy and paste that code so they now have three rectangles which is very good and then I come, I'm being very mean here and tell them, okay, now resize the rectangles.
Make them twice as large or twice as small as they are. So the learners having copy pasted this code need to go in and adjust every single orange integer you see over there. That's about four, eight, 12 integers if I'm correct which is very painful and not a nice experience for a beginner
which is the best moment you have in the teaching process to introduce the first statement because you can tell them, yeah, you would not have that pain if you used the fourth statement. It's pretty great, use it. I always call that the no pain, no gain strategy to teaching because if you try to let them go
through that little pain, you can adequately teach them how to use the abstractions and to value the abstractions you're actually trying to convey. I hope I got across the point that tutorials are not references to you
and that you need to be comprehensible, coherent and sometimes a little bit idiotic when trying to teach people Python or any programming language. Thank you for your attention and I'm open for questions.
Okay, thank you so far. There's one microphone over there. Oh wow. He was the first and then give it to the audience.
At which point do you explain the difference between the reference model of Python and the way C does it for variables? So because most of our audience is non-programmers,
we don't have to explain the difference. We can just explain the bare concept of references, right? And the metaphor I always use is using sticky labels so that you put a sticky label on an object and then it has that name. The point where we do that is pretty early on in the material when we talk about variables and variable assignment.
So that's the first chapter or something, it's pretty early. Because if you don't have to compare it to C and this is a memory slot or something, then it's pretty easy to get across because you only say it's a sticky note. But very good question. Next, yeah. Yes, thank you for your talk.
I was curious about the problem I'm faced with in general. That's the self-learned helplessness problem, I think, in teaching in general. But software development in particular, that there's a lot of fear for the,
oh, I can't do this. This is only for the beta guys, the geeks. And now it's popularizing. And what's your opinion about this? And maybe it's a general discussion within the teacher environment of software development to overcome that problem of the scariness of people.
Yeah, very good point. I'm afraid I don't have a very good answer for you because people just sign up for our courses and apparently those people are already motivated enough to do that and they seem to have a non-technical background.
So I'm not sure I know what is the reason for that. But if you, so I've talked to people and told them just try it. Just give me this two-hour workshop to try it. And then most people will come out of the workshop and be motivated enough to do it,
which is also a very critical point because I've seen people, when people prepare a workshop, most people are like, I need to explain them objects and loops and inheritance and everything. Don't try to do that if you wanna motivate them. Only explain the very basic stuff you need to spark some inspiration in them.
That's something we always do. The beginner course does not go into objects at all, I guess, because we just wanna spark motivation in the audience, if that is an answer to your question.
Yeah, thank you very much for the nice talk. I think it's super fun to teach Python, so I do it myself and I have two questions. The first one is, do you have any personal experience with using IPython notebooks for teaching purposes? The answer is no. Okay. Good, because I think it's a great. Let me, so some people in the Open Tech School
use IPython and apparently they're pretty successful with that, but I can't say anything personally because I've not used it for teaching, so sorry. And the second one is, how much time do you actually spend on explaining syntax? Because Python is very simple, like syntactically, but in my experience, when people have never programmed before and depending on what language they actually speak,
it is a very difficult thing to explain that now everything really matters. You can't just switch things around, right? In some languages, the sentence structure is completely flexible. And in English, it's often quite flexible, so people think that if I turn things around, it should still work, but in Python, it's really important that, yes, if you initiate
a for loop, you need this colon at the end, right? And there need to be brackets around functions, these things. That's an excellent question. So we don't actually do any syntax explanations to them, like going through all the syntax at once or something. We just tell them, you need to write that in order to do that.
So let's, for example, take the for loop, right? We show them a very simple for loop, and then we tell them, okay, now do the rectangle example or something. And my guess would be that most people are, if afraid enough of computers, that they would just write what you told them to write in the beginning so that they know,
okay, every single character was important. When they miss a character, they will just get a syntax error, right? So that's not too bad, because then they will either fix it by just seeing the syntax error, or they will ask one of the coaches, and we can tell them, okay, listen up. This is a computer, he needs to understand you, you need the colon.
Like everyone said, thank you for the talk. It was, I had a question about, because I organized a couple of Python tutorials, and some went really well, and some went catastrophically bad. And the one which went really bad was because I got asked a question, and I kind of was stuck between
a very easy answer and a very comprehensive answer. And the question was, okay, you've introduced us with this for loops and if, but what do I want to do software design for? Because I don't need a for loop, I want to do HTML.
So I was basically stuck with having no answer to this person who was attending a software development seminar without knowing why she was doing it. So in these kind of events, you basically sometimes have to convince people that,
you have to explain to them why they need, or why they might want to learn software design and software development. Sometimes they don't even know why they're here. And I feel that a lot of beginner tutorials do not even cover the, like why would you even do Python or software development?
And so I don't know if you have an idea about that or? Yeah, that's a good point. The one reason I would say people don't ask that in our workshops is Total. Total is the single best teaching tool ever because they instantly see what they are doing and they are intrigued enough by that kind of graphic,
graphical feedback, that they will stick to it. So Total seems to be very powerful in getting people to actually wanting to do that stuff. So maybe you just try Total and see if that gives any,
exactly, so just for the recording, he said that immediate feedback is important. And yes, immediate feedback is the one single best thing I would say, and you can use in teaching. Yeah, so talking about error messages and reading errors when you have a syntax error,
what I see from a lot of users, they don't know, if you're new users, how to read an error message and you talk about translating. It's not just that it is in English, but there are words in there, this error message that they don't understand, like attribute, method, function, whatever. So how do you approach this problem?
The simple answer is just ask them. So very often I see the interpreter explode in front of people's faces, and they're like, oh wow, crap, this did not work. I'm outta here. And then I just go to them and ask them, hey, do you have any clue what just happened? What does it say? And then people will start actually reading the error
message if you ask them what just happened. And that usually helps to get them trying to understand what the error means. And if you then ask them to explain to you what just happened, then they will kind of dig into it and try to understand the errors at hand.
Do you take people past Turtle? So Turtle's a great teaching tool that teaches the syntax of the language, and it's fun. But at some point somebody's going to want to apply that to a real world problem, and I wondered how you bridged that barrier between kind of drawing pictures
and searching file systems and that kind of thing. So I think, did I understand the question correctly that you are talking about real world problems and moving from Turtle to real world problems? Yeah, sure, sure. So the question was, how do you move from Turtle to real world problems? And that's indeed a hard topic.
So I spoke about motivation, right? So what we use Turtle for is mainly the motivational part. So to get people to like this programming thing. And you are right that Turtle is very limited in what it can do in a real world use case.
We sometimes use like very simple drawing problems, like you want to draw some nice, let's call it animation, right? Like very contrived, geometrical figures. But this is where Turtle stops here, right? So Turtle is useful in getting people to understand the concepts.
It's, I would say, not too useful in getting them to work on a project. That's very true, yeah. Thank you. Okay, one more question because we have to switch rooms and stuff and you can meet the speaker, I guess. Yeah, sure. Hi.
Sometimes I have to teach people, of course, the programming or stuff close to that and there is one guy who has this model of thinking that he's learning that way. He sees a solution and he tries to repeat it. But of course, in this particular case,
abstract thinking is really important, so this kind of behavior is not successful. But it's really hard for him to overcome this model of thinking. Have you ever met such a person and if you did, how did you help him to overcome this very settled model
of just repeating solutions instead of finding analogies and thinking abstract? So the question was, how do you help people who have a very different model of thinking to adopt a new one? So there's one story. I once met a guy who was,
a parent whose brain worked like functional programming, which was pretty amazing to me, but whoa. And I don't think there's a good solution to do that. Let them do enough exercises which are well suited to the model of thinking you want them to adopt.
And that usually helps. Using exercises gets people into the right mood for critical thinking. So hands-on is pretty important. Okay, thank you very much again.