Of course the literature contains numerous definitions. A similar question might be "what is a noun?". Objects are "that which the nouns name" in the Pythonic paradigm. They (the objects) live in memory at id() addresses ("like street addresses" I might tell my students). However, impressionable minds need more to hang a hat on that just boring grammar words (like "noun"). In UML (universal markup language) we have our customary symbols and diagrams: https://atomicobject.com/resources/oo-programming/abstraction-and-identity I often use a Creature -> Animal -> Mammal -> subclasses of Mammal taxonomy, when introducing inheritance and what we call the MRO (method resolution order). Another association of "object" we might build upon is "polyhedron" or "that which has shape". class Polyhedron: def __init__(self, v, f): self.v = v self.f = f self.e = v + f - 2 # euler's law for polyhedra def scale(self, factor): """ scale volume by factor, beget a new poly """ return type(self)(vol = self.volume * factor) __mul__ = __rmul__ = scale class Tetrahedron(Polyhedron): def __init__(self, vol=1): super().__init__(v=4, f=4) self.volume = vol class A(Tetrahedron): def __init__(self): super().__init__(vol=1/24) class B(Tetrahedron): def __init__(self): super().__init__(vol=1/24) # etc. (S, E, T) class Cube(Polyhedron): def __init__(self, vol=3): super().__init__(v=8, f=6) self.volume = vol class Octahedron(Polyhedron): def __init__(self, vol=4): super().__init__(v=6, f=8) self.volume = vol etc. (longer list of subclasses). If the Learning to Code curricula were to feature more source of this nature, we could facilitate reaching out to the geometry teachers with an intuitive picture of "dot notation" as a means of accessing "containers" of a very literal kind, if abstract. Associations around "object" have something concrete to build on, adding generic methods such as rotate() -- about what axis? -- and translate() -- for moving the shape relative to others, or to an origin (could involve creating a new shape at the new place, relative to the old). We could easily add surface area as another attribute, along with default edge length corresponding to our default volumes (YMMV in terms of what defaults your curriculum chooses). Indeed this is the right place to emphasize the power law, that changing all edges by a factor of n, e.g. doubling them (n=2) changes area by n**2 and volume by n**3. A selling point of the simple code base shown above is I'm not trying to do anything vectorial yet i.e. the shapes are so far coordinate free. We're free to turn to actual physical models and other media besides source code, to flesh out the concepts we're talking about. OO wins. Geometry wins. Dot notation wins. Python wins. I've been taking this tack in my Youtubes lately, building up a stash for a science fiction time when these ideas are more mainstream. Not that this focus on Polyhedrons as paradigm objects is all that esoteric. Square and Circle types have been common in textbooks at least. There's a bias against "3D" and I suppose that's what I'm countering, as speaking experientially, we do not live in Flatland. The approach to coding I'm advocating is also encouragement for spatial, not just planar, visualizations. Euclidean proofs may be more involved, however we have other generalizations such as Euler's Law for Polyhedra and Decartes' Deficit to introduce. Having the OO experience tie in with spatial geometry more intimately provides greater opportunities for imaginative play, and exercises the computing machinery in ways it's already very good at. Kirby