Special Olympics swimming season started this past weekend. A new athlete joined us, a young boy I’ll call Bryan. He asked me a question that has stuck with me.

Bryan is 12 or so, with the slightly goofy look of a boy growing into his body. He has braces on his too-large teeth. It was his first time swimming with us, so we needed to show him the locker room, how to get out to the pool, and so on. He was serious and inquisitive about all of these things that were new to him.

We got out on the deck and started stretching with the other athletes, most of whom don’t look like Bryan. They are older and have a variety of intellectual disabilities. Bryan surveyed the group then turned to me and asked the question: “is this for autistic people?”

I had only just met Bryan. I didn’t know his formal diagnosis (or if he even had one), and I didn’t know how he thought of himself. When he asked the question, I didn’t know if he was including himself in the category of autistic people or not, so I wanted to answer carefully.

Did he mean, “are autistic people allowed here?” or, “is this only for autistic people?” Maybe he meant, “are all of these swimmers autistic?” or even, “will being here mean I am autistic?”

I told him that it was for autistic people, that my own son Nat was here and Nat is autistic. Bryan accepted this in his sober way and continued on with the practice.

Later I talked with his mom about the question and asked her if Bryan identified as autistic. She said that he did, but it was a recent awareness for him. In school he’s in a typical integrated classroom.

Bryan did well at the practice, and called me “Coach Ned.” His mom was really appreciative of the group as a whole and was clearly pleased.

I’ve been thinking about Bryan and his question: “is this for autistic people?” He’s young, and finding his way in the world in so many ways. We all need to figure out who we are, what groups we belong to, where we fit. We all encounter difficulties in one way or another working all that out, and it’s life-long process. Bryan has a lot to work on. I hope it isn’t too hard.

People sometimes ask, “Does Python have pointers?” I hate to be the typical senior engineer, but this is one of those questions where the answer is, it depends what you mean by pointer.

The classic definition of a pointer is: a variable that holds the address of something else and that you can use to work with that something else. In very broad pseudo-code, it would be something like this:

myvar = SOMETHING;
mypointer = get_address_of(myvar);
print(get_value_via_pointer(mypointer));
## output is SOMETHING

This is useful because we can use a pointer to refer to data, setting the pointer in one part of the code with whatever logic we need to decide what data it should point to. Then elsewhere we can use the pointer without having to know what it’s referring to or how the decision was made. The pointer gives us an indirection that lets us separate concerns and write more modular code.

Many programming languages provide a pointer facility like this. For example, in C, the get_address_of() operation is ampersand, and the get_value_via_pointer() operation is star, and our code snippet would be:

int myvar = 17;
int *mypointer = &myvar;
print_int(*mypointer);      // outputs 17

Other languages like C++, C#, Go, Rust, Pascal, and even Fortran have similar capabilities.

OK, so what about Python? In one sense, Python doesn’t have a pointer concept like this. You could say that get_address_of() is provided by Python’s id() function, since (in CPython at least) it returns the memory address of the data:

myvar = 17
mypointer = id(myvar)   # ** not useful

But Python has no inverse operation: there’s no get_value_via_pointer() that can get you myvar given mypointer.

So Python doesn’t have the classic pair of operations to be able to work with pointers explicitly. But on the other hand, every variable in Python is a pointer, because variables in Python are names that refer to objects.

In Python, our simple example looks like this:

myvar = 17
mypointer = myvar
print(mypointer)    # outputs 17

When someone asks, does Python have pointers, perhaps the best answer is: it doesn’t have explicit pointers like some other languages, but everything is implicitly a pointer. So you have the power of pointers to use when you need them: you can have multiple data structures, then assign a variable to one you choose, and use the variable later. You’ve achieved the separation of “which data” from “work with the data” that pointers provide.

Maybe this is yet another case of Same words, different meanings.

Note:

• Some languages like C also allow pointer arithmetic to adjust a pointer from one item in an array to another. Python’s references don’t allow for that.
• Python’s standard library provides ctypes, which is great for interfacing with native C code, exposing details there including C pointers. This does not count as Python having explicit pointers.

A few years ago I wrote Multi-parameter Jupyter notebook interaction about a Jupyter notebook. It worked at the time, but when I dusted it off recently, it didn’t. I’ve renovated it and cleaned it up a little, and now it works again.

It’s a Jupyter notebook with a simulation of late-career money flows to figure out possibilities for retirement. It uses widgets to give you sliders to adjust parameters to see how the outcome changes. It also lets you pick one of the parameters to auto-plot with multiple values, which gives a more visceral way to understand the effect different variables have.

You can get the notebook itself if you like.

A year or so ago, I couldn’t find a step-by-step guide to packaging a Python project that didn’t get bogged down in confusing options and choices, so I wrote my own: pkgsample. After I wrote it, I found the PyPA Packaging Python Projects tutorial, which is very good, so I never made a post here about my sample.

Since then, I’ve shown my sample to people a number of times, and they liked it, so I guess it’s helpful. Here’s what I wrote about it back when I first created it:

•    •    •

The Python packaging world is confusing. There are decades of history and change. There are competing tools, with new ones arriving frequently. I don’t want to criticize anyone, let’s just take it as a fact of life right now.

But I frequently see questions from people who have written some Python code, and would like to get it packaged. They have a goal in mind, and it is not to learn about competing tools, intricate standards, or historical artifacts. They are fundamentally uninterested in the mechanics of packaging. They just want to get their code packaged.

There are lots of pages out there that try to explain things, but they all seem to get distracted by the options, asking our poor developer to choose between alternatives they don’t understand, with no clear implications.

I’m also not criticzing the uninterested developer. I am that developer! I don’t know what all these things are, or how they compete and overlap: build, twine, hatch, poetry, flit, wheel, pdm, setuptools, distutils, pep517, shiv, etc, etc.

I just want someone to tell me what to do so my code will install on users’ machines. Once that works, I can go back to fixing bugs, adding features, writing docs, and so on.

So I wrote pkgsample to be the instructions I couldn’t find. It’s simple and stripped down, and does not ask you to make choices you don’t care about. It tells you what to do. It gives you one way to make a simple Python package that works right now. It isn’t THE way. It’s A way. It will probably work for you.

As of a few weeks ago, I am between gigs. Riffing on some corporate-speak from a recent press release: “2U and I have mutually determined that 2U is laying me off.”

I feel OK about it: work was becoming increasingly frustrating, and I have some severance pay. 2U is in a tough spot as a company so at least these layoffs seemed like an actual tactic rather than another pointless please-the-investors move by companies flush with profits and cash. 2U struggling also makes being laid off a more appealing option than remaining there after a difficult cut.

edX was a good run for me. We had a noble mission: educate the world. The software was mostly open source (Open edX), which meant our efforts could power education that we as a corporation didn’t want to pursue.

Broadly speaking, my job was to oversee how to do open source well. I loved the mission of education combined with the mission of open source. I loved seeing the community do things together that edX alone could not. I have many good friends at 2U and in the community. I hope they can make everything work out well, and I hope I can do a good job staying in touch with them.

I don’t know what my next gig will be. I like writing software. I like having developers as my customers. I am good at building community both inside and outside of companies. I am good at helping people. I’m interested to hear ideas.

On Mastodon I wrote that I was tired of people saying, “you should learn C so you can understand how a computer really works.” I got a lot of replies which did not change my mind, but helped me understand more how abstractions are inescapable in computers.

People made a number of claims. C was important because syscalls are defined in terms of C semantics (they are not). They said it was good for exploring limited-resource computers like Arduinos, but most people don’t program for those. They said it was important because C is more performant, but Python programs often offload the compute-intensive work to libraries other people have written, and these days that work is often on a GPU. Someone said you need it to debug with strace, then someone said they use strace all the time and don’t know C. Someone even said C was good because it explains why NUL isn’t allowed in filenames, but who tries to do that, and why learn a language just for that trivia?

I’m all for learning C if it will be useful for the job at hand, but you can write lots of great software without knowing C.

A few people repeated the idea that C teaches you how code “really” executes. But C is an abstract model of a computer, and modern CPUs do all kinds of things that C doesn’t show you or explain. Pipelining, cache misses, branch prediction, speculative execution, multiple cores, even virtual memory are all completely invisible to C programs.

C is an abstraction of how a computer works, and chip makers work hard to implement that abstraction, but they do it on top of much more complicated machinery.

C is far removed from modern computer architectures: there have been 50 years of innovation since it was created in the 1970’s. The gap between C’s model and modern hardware is the root cause of famous vulnerabilities like Meltdown and Spectre, as explained in C is Not a Low-level Language.

C can teach you useful things, like how memory is a huge array of bytes, but you can also learn that without writing C programs. People say, C teaches you about memory allocation. Yes it does, but you can learn what that means as a concept without learning a programming language. And besides, what will Python or Ruby developers do with that knowledge other than appreciate that their languages do that work for them and they no longer have to think about it?

Pointers came up a lot in the Mastodon replies. Pointers underpin concepts in higher-level languages, but you can explain those concepts as references instead, and skip pointer arithmetic, aliasing, and null pointers completely.

A question I asked a number of people: what mistakes are JavaScript/Ruby/Python developers making if they don’t know these things (C, syscalls, pointers)?”. I didn’t get strong answers.

We work in an enormous tower of abstractions. I write programs in Python, which provides me abstractions that C (its underlying implementation language) does not. C provides an abstract model of memory and CPU execution which the computer implements on top of other mechanisms (microcode and virtual memory). When I made a wire-wrapped computer, I could pretend the signal travelled through wires instantaneously. For other hardware designers, that abstraction breaks down and they need to consider the speed electricity travels. Sometimes you need to go one level deeper in the abstraction stack to understand what’s going on. Everyone has to find the right layer to work at.

Andy Gocke said it well:

When you no longer have problems at that layer, that’s when you can stop caring about that layer. I don’t think there’s a universal level of knowledge that people need or is sufficient.

“like jam or bootlaces” made another excellent point:

There’s a big difference between “everyone should know this” and “someone should know this” that seems to get glossed over in these kinds of discussions.

C can teach you many useful and interesting things. It will make you a better programmer, just as learning any new-to-you language will because it broadens your perspective. Some kinds of programming need C, though other languages like Rust are ably filling that role now too. C doesn’t teach you how a computer really works. It teaches you a common abstraction of how computers work.

Find a level of abstraction that works for what you need to do. When you have trouble there, look beneath that abstraction. You won’t be seeing how things really work, you’ll be seeing a lower-level abstraction that could be helpful. Sometimes what you need will be an abstraction one level up. Is your Python loop too slow? Perhaps you need a C loop. Or perhaps you need numpy array operations.

You (probably) don’t need to learn C.