Learn Python object-oriented programming with Raymond Hettinger

April 2026 ∙ five minute read ∙

💢 There must be a better way.

Raymond Hettinger is a Python core developer. Even if you haven't heard of him, you've definitely used his work, bangers such as sorted(), enumerate(), collections, itertools, @lru_cache, and many others. Over the years, he's held lots of great talks, some of them on effective object-oriented programming in Python.

The talks in this article had a huge impact my development as a software engineer, are some of the best I've heard, and are single most important reason you should not be afraid of inheritance anymore; don't trust me, look at the YouTube comments!

Note

This list is only to whet your appetite – to get the most out of them, watch them in full; besides being a great teacher, Raymond is quite the entertainer, too.

Contents

The Art of Subclassing #

Subclassing can just be viewed as a technique for code reuse.

The Art of Subclassing (2012) is about use cases, principles, and design patterns for inheritance, with examples from the standard library.

The point is to unlearn the animal examples – instead of the classic hierachical view where subclasses are specializations of the parent, there's an operational view where:

  • classes are dicts of functions
  • subclasses point to other dicts to reuse their code
  • subclasses decide when to delegate

This view brings clarity to other related topics:

Finally, a quote about the standard library:

The best way to become a better Python programmer is to spend some time reading the source code written by great Python programmers.

Sounds familiar?

Learn by reading code: Python standard library design decisions explained

Python's Class Development Toolkit #

Each user will stretch your code in different ways.

Python's Class Development Toolkit (2013) is a hands-on exercise: build a single class, encounter common problems users have with it, come up with solutions, repeat.

Use the lean startup methodology to build an advanced circle analytic toolkit with:

  • instance and class variables
  • instance methods (self refers to you or your children2)
  • class methods (use cls for alternative contructors)
  • static methods (attach functions to classes for discoverability)
  • properties (transparent getters and setters)
  • slots (when you have many, many instances)

Super considered super! #

Super considered super! (2015) goes deep into cooperative multiple inheritance, problems you might encounter, and how to fix them.

The main point is that just like how self refers not to you, but to you or your children, super() does not call your ancestors, but your children's ancestors – it may even call a class that isn't defined yet.

This allows you to change the inheritance chain after the fact; examples include a form of dependency injection, overriding parent behavior without changing its code, and an OrderedCounter class based on Counter and OrderedDict.

The article by the same name is worth a read too, and has different examples.

Object Oriented Programming from scratch (four times) #

Object Oriented Programming from scratch (four times) (2020) does exactly that, each time giving a new insight into what, how, and why we use objects in Python.

The first part shows OOP emerge naturally from the need for more namespaces, by iteratively improving a script that emulates dictionaries.

The second one covers the history of moving from a huge pile of data and functions to:

  • data associated with functions (objects)
  • groups of related functions (classes)
  • related groups of functions (inheritance)
  • using the same name for similar functions (polymorphism)

Sounds familiar?

When to use classes in Python? When your functions take the same arguments
When to use classes in Python? When you repeat similar sets of functions

The third part explains the mechanics of objects via ChainMap, tl;dr:

ChainMap(instance_dict, class_dict, parent_class_dict, ...)

The fourth part highlights how OOP naturally expresses entities and relationships by looking the data model of a Twitter clone and the syntax tree of a compiler.

Beyond PEP 8 – Best practices for beautiful intelligible code #

Well factored code looks like business logic.

Beyond PEP 8 – Best practices for beautiful intelligible code (2015) (code) is about how excessive focus on following PEP 8 can lead to code that is beautiful, but bad, since it distracts from the beauty that really matters:

Pythonic
coding beautifully in harmony with the language to get the maximum benefits from Python

Transform a bad API into a good one using an adapter class and stuff like:

  • context managers for setup / teardown
  • flat modules for simpler imports
  • magic methods to make things iterable
  • properties instead of getter methods
  • custom exceptions for clearer business logic
  • a good __repr__() for better debuggability

And remember:

If you don't transform bad APIs into Pythonic APIs, you're a fool!

Bonus: The Mental Game of Python #

The computer gives us words that do things; what daddy does is make new words to make computers easier to use.3

The Mental Game of Python (2019) is not just about programming, but about problem solving strategies. The most relevant one for OOP is: build classes independently and let inheritance discover itself; this is because:

A lot of real world problems aren't tic-tac-toe problems, where you can see to the end; they are chess problems, where you can't.

For a more meta discussion of this idea, check out Repeat yourself, do more than one thing, and rewrite everything by tef; it should be considered a classic at this point.

Parting Raymond Hettinger quote:

I came to here you to show you how to chunk, and how to stack one chunk on top of the other, and this is a way to reduce your cognitive load and manage complexity; it is the core of our craft; it's what we're here to do.

Anyway, that's it for now. :)

Who learned something new today? Share it with others!

  1. But remember it's a principle, not a law, violations are fine – you may only want substitutability in some places (e.g. contructors are often not substitutable). [return]

  2. ...unless you use double underscores. [return]

  3. In my opinion, this quote alone is reason enough to watch the talk. [return]