Naomi Ceder

A surreal nightmare - Chelsea Manning's README.txt

Here are my thoughts on Chelsea Manning's memoir README.txt

Reading Chelsea Manning's README.txt was an odd experience for me. On the one hand, there were lots of things that made me feel connected to her and interested in her story. The most obvious was that we are both trans women, and we began our transitions at roughly the same time. And of course, her struggles for trans care were widely publicized, so I was aware of them, and to a certain extent my transition was also fairly public, if within a much smaller social network and the Python community. We had grown up in very conservative parts of the country - in her case, Oklahoma (at least in part) and in mine, Nebraska. In addition, her use of technology and the internet was similar to mine in the 90's and 2000's.

With that said, there were some real differences. For one thing I'm more than 30 years older, so I had served a self-imposed term of decades of suppressing my gender identity, waiting until circumstances made it safer and easier to transition. Chelsea's childhood was abusive in many ways, while I would not claim that of mine. And in spite of some temptation, I had resisted and avoided entering the military.

In spite of the points of connection, I was not immediately grabbed by her story. She starts with the striking scene of her desperately trying to upload all of the files via a shaky network connection in suburban mall land, during a snowstorm no less, with less than 24 hours before she has to get on a plane back to Iraq. But the telling of it is a bit pedestrian, and it takes a while for the story to emerge. Dramatic as it might be, the how and the why of the uploading of information about the war is not the story. Rather it's what happened after she was caught that I found more compelling.

The story of how she came to have that information and how she uploaded it is all too simple, and the why is not so well articulated, emerging as it does from a tough childhood and rootless adolescence that ended in the army almost out of desperation.

But once she is discovered and taken into custody things get much more gripping. The style is still matter of fact, flat, and mostly emotionless, as if it could only be told by keeping it safely at arm's length. It's a story that is almost Kafka-esque in its absurd cruelty. Earlier, when describing basic training, Chelsea acknowledges that its function is to break people, tear down part of who they are in order to reconstruct them as different people. It's interesting to me that of all the veterans I've known, the only other person who described military training that way was another trans woman, who washed out of ROTC because she wouldn't endure that.

Chelsea on the other hand gives a sense that the process of breaking and rebuilding that happens basic training was not all bad for her. So it's interesting that once in the clutches of the US government she is the target of a similar process, except there is no goal of rebuilding a new personality this time. This time the only goal is to destroy her totally. The unemotional descriptions of the inhuman torture they put her through leaves no doubt that the primary concern of her jailers and the government was pure revenge, nothing more.

That she survived her initial captivity and what was a bizarre show trial (bizarre in that many parts of it were blacked out in the name of "security") and her early captivity is amazing. The treatment she received from her own government, our government, as a citizen on US soil, under an administration that was supposedly humane and progressive, should be a curative for any idealism in regards to the justice of our ways.

If there is anything positive in the story it would be that once she given even the slightest breathing space, she was able to find people to help her as she found ways to deal with the government and even gain concessions from it, both in terms of dealing with prison and in forcing the grudging accommodation of her gender transition.

In the end her eventual movement to Leavenworth to serve her 35 year sentence (which seems almost like summer camp in comparison to what went before) and even the eventual commutation of her sentence and her release all seem not so much the restoration of justice as a calculated attempt to evade the judgment of history.

Chelsea emerges as someone of intelligence, of stunning courage, but not unscathed. After a difficult youth and her nightmarish captivity, she is not broken, but the scars (and even the still open wounds) are extensive, and one wonders if Chelsea Manning will ever be at peace in this world. And to be honest, one wonders if her ordeal was worth it.

PyCon Bolivia 2022 Keynote

Esta charla se presentó como keynote de PyCon Bolivia 2022, 2022-11-09

El texto y las diapositivas de esta charla están aquí.

A Time of Gifts

Delivered as the closing keynote of PyCon 2022, Salt Lake City, Utah, 2022-05-01

Versions in Spanish and Portuguese were given at PyCon Latam 2022, 2022-08-27

I don't usually post the text of talks I've given, but I thought I'd make an exception for this one. This started out as a love letter to the Python community, but ended up with a bit of what I suppose you could call parental concern.

Good afternoon. I am honored and delighted to be here. Before I say anything else I'd like to note that this is our 20th PyCon, yes, this is number 20, and my 20th PyCon as well, and I like to give my deepest thanks to the organizers, the staff, the volunteers, and of course to all of you, for making it such a joyful return to the world. Thank you all.

I've called this "A Time of Gifts," which is inspired by a little gem of a travel memoir by Patrick Leigh Fermor, who in the early 1930's, after being thrown out of his last year of British public school for not taking it seriously enough, decided to walk from the Netherlands up the Rhine, across Europe, down the Danube and ultimately to Istanbul.¹

It took him a couple of years, and the focus of the book is not so much the places and sights he visited, nor the historic events unfolding around him (he crossed Germany and Austria as the Nazis were coming to power, but seems to hardly notice). Rather Fermor is interested in the people he met along the way - boatmen and truck drivers, farmers and shopkeepers, even an occasional aristocrat, whose gifts of food, shelter, and companionship helped sustain him along the way.

For me, and maybe for many of you, my time in this community has been my time of gifts, gifts that have sustained me in many ways on my journey over the past 20 years to various continents, across two genders, through different stages of my life. So that led me to think about how we value and share the gifts of our community and how people have compared open source communities like the Python community to a gift economy.

Here at PyCon I overheard someone say, "In Python people know how open source works." Maybe. But I wonder if that understanding is really the same for everyone. There are a lot of ways to look at communities, and I expect that there will be various different opinions. But I do think it's important for communities to think about and articulate their principles, and I want to present a way of thinking about our community that makes sense to me. Maybe at least it will start some discussion.

I want to be clear that what I'm about to say is purely my own opinion - I stepped away from the PSF board nearly 2 years ago, so please don't blame any of them.

I would argue that, as a community organized around an open source language and ecosystem, we have a gift orientation. The thumbnail definition of this orientation is that people contribute what they can when they can, and in turn share the resources and help contributed by others in the community.²

This style of gift giving or mutual contribution is what we see in our Python communities - some people are contributing code, others documentation, still others the labor to hold community events. All of these gifts are freely given and everyone enjoys the benefits. Right? Sort of like a utopian anarcho-syndicalist commune, or like what the animals had on Animal Farm until the pigs turned into totalitarian dictators.

And I think for many of us who love this community, this is the narrative we turn to, particularly in misty nostalgic moments, which at least old-timers like me experience at every PyCon. But in those moments we tend to forget that things are never quite that simple, that perfect, or that idyllic. As Python, our community, our projects, and our gatherings have grown, things are not so clear. In fact, a lot of people are questioning whether this model of open source powered by gifts is still sustainable.

I suppose part of the problem is that the open source world in general and Python in particular have been almost too successful. Even as we've grown in every aspect, the number of users and their demands has grown exponentially faster. How can such relatively tiny groups of volunteers keep a community and a language used by millions going?

It's easy to find examples of things that go wrong. One issue is burnout on the part of the volunteers who make it work. Many times I've seen what I call "shooting stars", people who burst onto the scene and start contributing to the community, often in multiple ways, showing superhuman amounts of energy and enthusiasm. It seems that only months after their first events, they are organizing other events, teaching courses, contributing code, and more. These newcomers are so successful, so eager to help, that we, as a community, happily give them more and more to do, to the point that old timers like me start wondering, "how can anyone possibly do all of that?"

The answer usually is that they can't, at least not for very long. In those cases, we'll start to notice that they're looking tired, that the enthusiasm is fading even as the workload continues to go up. I've had them take me aside and quietly ask me how to deal with the stress, how to keep all the balls in the air… and when I tell them that the answer is to do less, they never seem to accept it. Oh, you can tell that they'd love to, but by now they don't have time. They have an event to organize, a review or blog post to edit, code to write, planning calls to join.

And after a few months, or a couple of years, maybe, they fade away. Emails go unanswered, deadlines slip, pull requests are ignored, calls are missed, and so on. The demands of all that they were doing, for free, as volunteers, combined with demands of work, the needs of family, etc, have literally sucked all of the energy out of them. The tank is empty and they have no more to give, and the relationship between them and the community is damaged, often irreparably.

I've also seen people who've started slower, and built on their work over the years until they have become key developers, or maintainers, or key community organizers. They've been doing what they do for many years now, usually getting more complaints than praise, and they feel that their work is being taken for granted. In many cases I think they have too much invested emotionally to walk away, but they're tired, and they're wondering how much longer they can hold on.

Sometimes those leaders have given so much more than anyone else that they end up running the project alone. They hold all the credentials, and whenever something needs to be done, everything goes through them. When encouraged to share the load, they tend to explain that they can handle it just fine, and, besides, it's more work to train new people than it is to do the work. Or maybe they feel that they just don't have the knowledge or the time to onboard new people.

On the other side are the people who are eager to join a coding project or community effort and to help out, but who end up being turned away. I've often see people whose sincere, even eager, offers of help end up ignored for a variety of reasons: no one has time to onboard them, the project that they're interested in has enough people involved (they think), they happen to be asking in the wrong place, they're trying to come in at too advanced a level, or any number of things.

If they are trying to do something that they aren't ready for yet, they can be directed towards more appropriate contributions. But often it seems to me that they just fall through the cracks. And in those cases each time they try to get involved and somehow get turned away they are less likely to try again, and we end up losing them.

The end result is that our projects and our community initiatives are at risk of dying as people burn out and are not replaced. So it happens that we often find open source projects abandoned, with unanswered issues, ignored PR's, and out of date dependencies… or initiatives with silent mailing lists, ghost town slacks, and so on. Occasionally one might get revived, but most are simply left behind.

Some even see this as just the way that open source projects work. I was reading an article about the sustainability of open source a couple of weeks ago and a developer/maintainer of several JavaScript projects characterized open source as "a model that relies on people giving more than they can for very little or nothing in return, and hoping that there will be someone to take over the mantle when the previous person burns out."³

That description of how open source works tells me that if we are in fact a gift giving culture (and I believe we are) things are going wrong. We have people giving more than they can sustain and others who are able (barely) to sustain what they give, but feel that they aren't receiving anything in return. I'm sure that feeling is made even worse by seeing companies use their work in place of systems that used to cost hundreds of thousands of dollars, without acknowledgement, and certainly without giving back even a tiny fraction of the money that they are now saving.

And then there are others who feel that their gifts are being rejected. This last is also serious - in a gift giving culture refusing someone's gift is an insult, it's a way of saying you don't want them in the community. So it's no wonder sometimes we struggle to find new people to take over projects.

So clearly there are challenges we face as an open source community. The question is what do we do about it? What can we do? To my mind the first step is to understand what's going on and what motivations and values are driving people's behavior.

The way you think about something, the narrative you tell yourself, has an impact on how you deal with it, and some ways of thinking about a problem can actually keep you from fixing it. I know from personal experience that sometimes changing, or at least clarifying, your narrative can be an important first step in dealing with a situation better.

So what does drive communities like ours? Why are we here at a conference like this where there is so much talk about community? 20 years ago the most popular explanation, popularized in things like The Cathedral and the Bazaar, was that open source was driven by self interest. Enlightened self interest to a degree, since in practical terms you were more likely to get what you wanted if you were agreeable, but still just self interest. People worked only on what interested them or benefited them, and beyond that the only other motivation was the ego boost you could get from reflecting that you were the one to solve the problem, and everyone interested in the project would know it. In fact even if you were to do something nice, something altruistic, without that ego boost as payback, that was only because you could then get the ego boost of thinking about what a noble person you were. In other words, it was self interest all the way down, no matter what you did.⁴

Along with this was the belief that enough genially selfish people working to scratch only their particular itches and to boost their own egos would somehow combine to produce the best of all possible worlds for everyone. As you may notice, this view doesn't have room or any notion of community, service, or altruism.

If that's the view you have of how the open source world works, then there is no problem with any of the examples I mentioned above. Rapid burnout and departure? Well, the level of their interest no longer was high enough for them to continue. Or maybe they just didn't achieve enough ego boosts. Either way, no problem. Exhausted volunteers? If they're doing what they want, they'll continue, and when the rewards aren't great enough they'll quit, that's the way it works. Abandoned projects or communities? Well that's what happens when there isn't enough interest. Better learn to deal with it. And those wannabe volunteers, who feel turned away? They must not want it badly enough, or maybe they're just not smart enough or pushy enough to elbow their way in.

Looking back, some of the stuff written 20 years ago along these lines comes off as an adolescent mix of Ayn Rand and liberal capitalism, and it seems mercifully to have fallen out of favor. Not that I can claim the moral high ground. Back in the day, most of us didn't really question notions like these, even though in practice most people actually behaved differently - they didn't actually put ego boosts and self interest ahead of all else.

I suppose we all benefited in some ways from our participation, but there were too many people doing too many generous and altruistic things for self interest to be the only thing, or even the main thing, driving us. But if you'd asked, that's how a lot of us would have explained how open source works.

To my mind that narrative of self interest was damaging to open source communities in general and to the Python community in particular. It incentivizes cowboy coding, flame wars, and fragmentation and discourages collaboration, inclusion, and community building. It's something that we are still struggling to get past 20 years later.

In fact Brett's famous phrase (which I have borrowed so many times), "I came for the language, but I stayed for community" very neatly sums up the way that many of us from the old days have changed our view of what matters in this world of open source and Python.

So that brings me back to the notion of gift giving as essential to our community. Again, if we think of hunter-gatherers, one of the classic examples of a gift culture, if a hunter makes a kill they share the meat with everyone. Sure, they want to eat, so there is an element of self interest in what they do, but they also share with the community. Interestingly in some Inuit cultures it's considered an insult to thank the hunter, since that would imply that they're doing something special. It's not special, it's just what you do.

True, we're not hunter gatherers, but I would argue that this pattern appeals to most of us, to most humans, actually. If you look at how people behave in our community, it's not hard to see the same ethos at work. People who contribute code do so because they can, and because it improves things for everyone. Certainly sometimes the code they give addresses a personal need, but many times it doesn't. Likewise people on the board and event organizers give a lot of labor that doesn't benefit them personally.

In turn, we can (or should be able to) count on sharing the benefits of the community. In addition to the software, it might be support and friendship, or maybe education and skills, or contacts and an increased professional network. I know I've experienced all of those, from being offered a book deal, to making so many friends in different countries, that it has driven my language learning the past few years, to the PyCon 9 years ago when my father died early on Sunday morning, and that evening several people made sure to sit with me so I wouldn't have to be alone.

The interesting thing for me about cultures that rely on gifts is that the process is so vague and messy. There's really no way to determine, say, that sharing one deer is exactly equivalent to, say, a certain number of fish, or apples, or whatever. Likewise, there's also no way to determine that 10 code patches equals one conference talk equals 3 board meetings, or whatever it might be. There's really no way to keep exact tit for tat accounts - what we can all count on is when someone is able, they will make a contribution that all can share. And in turn we will contribute what and when we can.

This messiness is not a bug, it's a feature - not knowing the timing nor the precise value of the contributions actually works to bring people together, since no one can ever say for sure that they are exactly even with anybody else. Instead there is a realization that everyone's fortunes are entangled, that we're all in this together. In other words, mutual contributions, this giving of gifts, is what helps bring people together and create community.

For me, articulating gift giving as what drives our culture, what creates our community, leads me to a couple of things that I think we can do better and that we need to be aware of if we want to preserve our Python community, and if we want it to continue to grow and flourish.

On the individual level. I think that if we consider everyone around us to be contributing to the best of their abilities, to be giving their gifts to the community, we will treat them (and ourselves) differently than if we believe that we're all out for our own self interest and don't really owe anyone a thing.

I would say that understanding that we are all benefiting from the contributions of others makes it easier to appreciate that work, the gifts they are giving. Hopefully it will also prompt us to show that appreciation, something that so many volunteers receive far too little of. And it should also make us a little less critical of others, since we understand that their contribution is a gift, freely given, not an obligation nor a transaction.

As for those shooting stars who rapidly burn themselves out, maybe reflecting on gift giving will help remind them that there is no need for any of us to give more than what we can, that what we can offer at any time is enough, and that in turn we all also will need to receive gifts from others. And maybe, I hope, some of us who've been around will be more inclined to give people who are over committing the gift of reminding them of that.

The mindset that we're a gift giving community may also help us to share the load more, to respect the gifts that others offer, and to give the gift of allowing others to take up some of the tasks we've done.

As I said earlier, rejecting someone's contribution shows a lack of respect - by rejecting their gift we are saying that we don't want them to be part of our community. Keeping that in mind, we need to be sure that there are ways for new and different people to contribute, and we need to give the gift of mentoring and guiding those people.

A part of this is that we also need to hand off leadership generously, give the gift of sharing positions of leadership. This gift benefits the giver as well as the receiver. I'm pretty sure that one reason I've been able to stay an active and involved part of our community across 20 years has been that I have had a deliberate policy to hand off the leadership of any project I've ended up leading to new people after 3-5 years.

In fact, the time to start thinking about and training your successor is as soon as you become a leader. It's not easy at first, it feels like a bit of a loss, but it helps new people grow and keeps the old-timers fresh by letting them do new things. I recommend it highly.

The other area where I think a sense of clarity about what makes our community work is vital is when it comes to money. So far I've deliberately not mentioned the dominant form we have of sharing resources - a market economy with exchanges based on money.

The thing about money, with its tendency towards exact transactions, exactly the opposite of the messiness of gifts, is that it works against connection and community. If you give me something worth $2.52 and I give you $2.52, we both know we're exactly even and the transaction is done. There's no need to continue the relationship. Transactions don't build community.

For that reason, particularly as a community, we need to be very thoughtful about how we deal with money. I'm not naive - in this world we pretty much all need money and I can testify that it's better to have a bit more of it than not enough of it. That's true of for us as individuals, for the PSF as an organization, and in general.

When we ask people to make helping our community a full time job, whether that's managing our community and events, or our infrastructure, or our coding process, those people deserve to be paid fairly, even generously. We also want to make our communities and events more inclusive, and many people need financial help to take part. Likewise, fostering communities around the world takes money, and in the foreseeable future for various reasons things will cost even more.

So clearly we need financial resources to help the community continue to grow and flourish. But I worry about any notion that we should make monetary exchange the driver of either the way that we get financial resources or the way we share them. What I mean by that is that as we confront the many problems around raising money and then using that money on behalf of the community, I think we need to think very carefully about it and be particularly wary of becoming "a business".

I don't have anything at all against business per se, mind you. I've made a living working for businesses and helping them succeed. And I appreciate the support businesses give to our community. But I would argue against our Python communities, the PSF being the leading example, ever acting like a business.

I've worked for several companies over 35 years, and no matter what HR or Marketing would like you to believe, being an employee is not like being in a community of shared contribution with your employer, nor is being a customer. If our contributors become employees, and our sponsors become customers, I believe our community will be diminished, if not destroyed.

I'm probably biased, but I think that so far, the PSF and the Python community have handled this well. The PSF has hired people to support the development of the community and help enable people to contribute more successfully in all areas. Money is spent supporting smaller regional and local groups and helping those communities grow and contribute and financial aid for PyCon and other major conferences also helps people with fewer resources make contributions on the global level.

Sponsorships have been developed which support the PSF generally, with few corporate strings attached. I believe this is the right strategy - as we interact with the business world, we should not try to become a business, but rather we should invite those enterprises to join in our world of free contribution. That means selling those organizations on hard to quantify, often intangible, benefits - a tough sell, but not impossible, and worth the effort.

These are just early days, however. As late stage capitalism becomes harsher, as Python's importance and big tech's power both continue to grow, the tension between a market economy and a community centered around gifts will also grow. In other words, I think it inevitable that there will be more pressure on us to abandon our culture of gifts and free contributions in favor of monetary transactions.

It could be companies trying to buy control over the language and/or community, it could be pressure to treat contributors and volunteers more like employees, or it could be any number of things, but in the coming years there will be many opportunities to sell out our community for one tempting offer or another.

If and when that happens, it will be up to us to decide whether we still want this community to be a place of free contribution and a time of gifts. I certainly know my answer.

The time has come...

As we head into the PSF election cycle, I'd like to let everyone know that I will not be running for re-election to the PSF Board of Directors and consequently from mid June I will no longer be serving as chair of the PSF.

Announcements like this always strike me as awkward, since they make two rather unlikely assumptions: that people will even notice, and that they will care if they do. But in the interests of transparency I'm going to go ahead as if both were true and share my reasons for this decision.

FIrst of all, I truly do believe that limited terms are good for the sustainability of an organization like ours. If someone is in a key role for too long, their inevitable departure and replacement can be unnecessarily disruptive and difficult, even with the best intentions. Of course "too long" can be hard to define, but I think it's safer to err on the side of leaving sooner rather than later. I also think it will be good for the PSF to practice handing off board leadership.

My other reason is that it's just time to move on. After five years on the board and 3 as chair, it seems like it's time to step out of that role and find something different to do, some other way to work for the Python community.

This isn't a dramatic change - I will be available to the next board as an advisor, and of course I will remain a passionate supporter of the PSF and Python communities around the world. So no, you're not getting rid of me that easily. :-D

I do hope that the PSF will continue to work on electing a diverse board, in all of the endless possible dimensions. For one target, I would love to see more representation on the board from Latin America, southern Europe, Africa, and Asia, as well as LGBTQ folks, racial and religious diversity, neurodiversity, and the rest.

If you're one of those people would help make the board more diverse but you're thinking, "yes, but there's no way that someone like me could be elected," well... I was thinking exactly the same thing when I ran for the board 5 years ago. There are no guarantees, but I believe it's worth a try, both for what you might bring and for the experience you will gain. So if that's you, get in touch - I'd be happy to talk about the board and what it involves, and offer any support I can.

It's been a privilege to work with so many amazing people on the board - we may not always have agreed on every point, but you would be hard pressed to find a group of people more dedicated to the success of the PSF and the Python community.

I'm also honored to have worked with the PSF staff as it's grown. They are truly amazing - smart, hardworking, and dedicated. I've seen their work up close, and believe me when I say that we're lucky to have them and they deserve all of the support we can give them.

As we move forward into the changes that the current crisis will bring, I have no doubt that the PSF and its board and staff will be more than up to the challenges ahead.

My time as chair of the PSF has been a lot of things for me - sometimes a challenge, often a learning experience, always an honor and a wonderful opportunity to get to know so many Python communities and their members. But above all it has been a rare and ridiculously improbable gift, something to be treasured, but also to be held lightly, and then passed on.

So long, and thanks for all the fish...

Notes on Teaching Python – Mental Models

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.