Notes on Teaching Python – Mental Models

May 21, 2015

I admit it – I’m just an old, cranky teacher. As much I love seeing so many people all around me teaching Python, as much as I love the notion of spreading the joy of Python to various masses, there are things… things that give me pause. No, worse than pause, they give me a serious case of teacher twitch.

I start feeling the overwhelming urge to offer constructive criticism and helpful advice where none is wanted. I usually fight these urges, not wanting to be shunned by everyone as “that woman” (or something worse).

However, I also don’t want to end up in the corner muttering something like “get offa my lawn”. So I’m going to rant gently about some of these twinge inducers here.

What are we teaching, really?

I think one issue arises from a failure to ask ourselves what we really are trying to teach when we are teaching “Python”. It seems like a silly question, or a redundant one, but humor me. What are we trying to teach? Syntax? Best practices? Problem solving? TDD? OOP? What is Pythonic? Coding? Critical thinking? Computer science concepts? All of the above?

I’m pretty sure I’ve heard all of those answers at one point or another, and even given some of them. Yet I’m equally sure that something vital is missing when we talk about what we need to teach when teaching Python. And this something really holds everything else together.

The importance of a mental models

The missing “somethings” I’m thinking of (since in fact there are many of them) are mental models. We may not know every detail of how a thing works, but if we have an accurate mental model how it works, we can form some reasonable expectations about how it might work in different situations.

If I have a sound mental model of how AC current works and see that the lamp has a frayed cord, I can pretty confidently unplug it and deal with the problem. On the other hand, if I have an inaccurate mental model of how AC current works, I might either run from the room expecting the lamp to explode, or reach down and grab the bare wire. Neither is a desirable result, but yes, I’ve actually known people who fall into both categories.

The same is true in Python and coding. If we have an accurate way of thinking about a feature of the language, we stand a much better chance of getting code that works as desired. If we have faulty mental models, then the coding equivalent of electrocution or irrational avoidance awaits.

Take “variables,” please

For example what about “variables”? Yes, I agree that the term “variable” is questionable in Python. Yes, I prefer either “name” or “label”. However, it seems pretty much everyone calls them variables at some time or another, which may well be part of the problem. Several times now I’ve seen newcomers to coding being taught that about “variables” in Python. And many of those times I’ve seen the explanation that a variable is a “container that holds a value.” Or, as I used to say when I taught C, they’re told that a variable is like a bucket.

For C this makes some sense. And while no one should argue too much with the notion that the contents of a variable must go somewhere, in fact thinking of Python variables as containers is an inaccurate model – names in Python are more like post-its than buckets. But what makes the notion of variables as buckets even more insidious is that it seems to work well enough at first that people get used to thinking this way, and then pass it along.

Consider the following mindless code:

a = 1
b = a
c = b
print(a, b, c)

So far, so mindless. If you ask people what you get, they will not have a problem saying 1 1 1.

But suppose you then add the line

b = 2

and ask about print(a, b, c)?

The followers of the bucket camp will usually (and correctly) say that the result is 1 2 1. In fact, there may be some confusion about what the “contents” of c are, but if you are thinking buckets, the answer makes sense.

But what about a mutable object? Suppose we have this:

a = [1, 2, 3]
b = a
c = b
b[1] = 5
print(a, b, c)

Here the members of the bucket brigade are often stumped. In my experience I have been stunned at how many beginning (even intermediate) Python coders are surprised by the actual output of [1, 5, 3] [1, 5, 3] [1, 5, 3]. If variables are containers, how on earth can changing the contents of one change the others?

But if instead they are names that point to objects, the right answer makes sense. Once they have a better mental model of how names work in Python, such surprises (and the attendant bugs) become much rarer.

Let me be clear, this example isn’t the only case of poor mental models in teaching Python. I’ve picked on this example because it’s so fundamental and, in my experience at least, so common.

The question is not if our students will create mental models or not – we all form mental models as we learn. It’s our job as teachers to be thoughtful and help our students form¬†useful and accurate¬†ones.


Python Education Summit 2014 Call for Papers

February 15, 2014

Python Education Summit 2014 Call for Papers

Do you have a story to share on education and Python? We are actively looking for presenters for the Python Education Summit and have extended the submission deadline. Please submit a topic you would like to present on. Interested in seeing the topics others are proposing to speak on? Have a look and vote for your favorites – help us define this year’s agenda.

Need some ideas for topics you could present? Maybe one of these topics will inspire you to share your experiences:

  • The joy and pain of authoring a book on Python
  • Teaching Python on a shoestring budget
  • Gamifying how you teach Python to strengthen engagement and return on investment
  • Using the Raspberry Pi to teach Python
  • Tips for developing your Python-based curriculum
  • How to choose what to teach
  • Educating children to program in Python
  • Educating seniors to program in Python
  • Helping a student transition from Learning Py to Py Employment
  • How to make money teaching Python
  • Developing a community program teaching Python
  • Train the Trainer: teaching volunteers to teach Python
  • Exploring the resources available to instructors
  • Choosing the right teaching resources
  • Taking a student to the next level – guiding ‘self study’

If you are interested in presenting, please submit your ideas for topics/presentations that you would like to present. We will gather feedback on the submissions to assist us in building the agenda. All submissions must be in by February 25th and decisions on speakers/presenters will be made and speakers will be notified by February 28th, 2014.

NOTE: All speakers will be offered early bird pricing for attendance at PyCon.


Quick Python Book is Manning’s Deal of the Day April 12

April 11, 2013

The Quick Python Book is Manning’s Deal of the Day April 12!

That’s right, starting at midnight EDT, April 12, my book, The Quick Python Book, 2nd ed will be Manning’s Deal of the Day. What does that mean? It means that if you click on the link at the right and buy the book or ebook using the code dotd0412au, it will be half price. This deal will only last for a day or two, but it’s a good chance to pick it up a really good price! 

And the author will thank you! :)


Another Quick Python Deal

January 19, 2013

Just a quick note that the Quick Python Book, 2nd edition will be Manning Publications deal of the day Saturday, May 18. 

Here’s the official scoop:

Deal of the Day : Half off my book The Quick Python Book, Second Edition. Use code dotd0518au at http://www.manning.com/ceder/.

Also on the same code is Hello! Python (http://www.manning.com/briggs/) and Extending jQuery (http://www.manning.com/wood/)

And for anyone in Europe and the Americas, you should know that the deals usually run until past the end of day everywhere in the world. So if you don’t get it done on Saturday, the code might still work on Sunday morning. Just sayin’…


Number 2 for 2012

December 31, 2012

I’ve already put this on the social networks, but I can’t resist noting that The Quick Python Book, 2nd ed, AKA my book, was the second best selling book for Manning Publications in 2012. And I can’t even complain about missing number one, since that slot was claimed by Warren and Carter Sande’s excellent Hello World! Computer Programming for Kids and Other Beginners, another Python book! Python in the top two spots! 

As I’ve mentioned elsewhere, if you use the link at the right you can pick up either title for 50% off before the end of 2012 by using the code bestof2012

As for me, I’m just blown away that QPB2e did so well.

Happy new year to all in the Python community and thank you!


A few changes

October 26, 2012

This is a completely non-Python related post, but it probably makes sense to post this here, just for the casual observer. There have been some changes in my personal life that may make things confusing for some. I’ve been pretty public about this on my social media accounts, but quite a few people haven’t heard for various reasons, so here is the news.

 
The short version is that I’m transgender and I’ve legally (and emotionally, professionally, etc) transitioned to being female. So the Naomi you see now is (in some ways at least) the same as the Vern that used to post here.

 
That is all. :)


Turtlelab – A Simple Environment for Teaching Python

June 17, 2012

I started teaching Python to 8th graders years ago. We were already teaching it to all of our 9th graders, so I talked the 8th grade computer teacher into it (pretty easy since a) she was as very smart woman, and b) I was sort of her boss ;) ) so that we could build a little buzz for programming before kids made it to high school. I started them just with IDLE and some text based programs, followed by some stuff from the LiveWires lessons and it was a modest success.

However… I felt I was spending too much time on the mechanics of using the environment and not enough on the actual prorgramming. This mattered since we could only carve two weeks out of the existing curriculum for the programming unit. I’d also switched to a curriculum completely based on using Python’s built-in turlte module, which became much easier when some us added several tweaks to the library for the 2.5 release, and even easier when Gregor Lingl’s brilliant x-turtle was adopted as the replacement for the turtle library in Python 2.6.

Still, I wanted an even more supportive environment than IDLE. I wanted something that would take care of saving – kids forgetting to save was pain in the rear, and a good way to kill their enthusiasm. I also wanted something that would offer help on the commands as they were starting out. Not code completion, exactly – for novices that can more confusing, but something that would enable them to find the command they wanted easily without leaving the enviroment.

So… I created my own. I used it and thought it worked pretty well, but never really got around to promoting it. Then Simón Ruiz started using it to teach our 9th grade class. Simón polished and refined the interface based on his experience and testing, and the result, if I do say so, is worth a look if you want to teach Python to kids using the turtle. It has the great advantage of being a single file, so installation is easy, and its only dependency is that it requires Tkinter and IDLE.

At the moment Turtlelab isn’t really under active development – I’ve since left teaching and Simón has other assignments, but I believe he’s considering a blog post or two in the near future focussing on it. 

Rather than explain it in great detail, I’m sharing the link to the BitBucket repository and you can go play with it yourself. And if you really like it and want to use it, please do. If you like it even more and want to take it over, please let us know – we love to have it in use and under development.

Get Turltelab here.


Follow

Get every new post delivered to your Inbox.

Join 136 other followers