First, `__closure__` is a plain data attribute, not a function. It isn't callable, and isn't being "called" here.

Further, in the cases you're talking about, the functions specifically are methods which you can implement in your own class. But you aren't doing this in order to avoid calling them directly; rather, you're doing them to implement functionality for that class (i.e., there's some other bit of syntax already which will call it indirectly for you). And `__init__` isn't much of an exception; normally you only call it explicitly where necessary for subclassing (because the corresponding syntax would create a separate base class instance instead of initializing the current base).

But the point here is to inspect an implementation detail, for pedagogical purposes. There isn't a better way to do it in this case, exactly because you aren't ordinarily supposed to care about that detail. There's no question about whether you'd inspect an object's `__closure__` directly in production code - because not only is there no alternative, but it would be extremely rare to have any reason to do so.

The naming convention is what is throwing me off. "object.closure" I understand as an attribute/property being accessed. In this case, the naming style suggests there should be a wrapper like:

def closure(self): return self.__closure__

I'm just talking form, not function here. In other words, if it is supposed to be accessed directly by arbitrary external code (non-class functions), it shouldn't use the double underscore syntax? If any property can have that syntax, then the syntax loses its meaning?