I have encountered a conundrum. I think I should know how to solve this — I am extremely knowledgeable and experienced in Python — but I can't figure it out. It seems like what I am struggling with should be addressed by a design pattern that is a variation on the factory theme, but I can't recall one. (At the end of this writeup I suggest a technical solution, but it seems an implausible one.) I hope you find this discussion interesting in its own right, but I look forward to hearing some suggestions for solutions to my problem.

Given classes, A, B, C, and D, I want to limit creation of B instances to methods of A, C instances to methods of B, and D instances to methods of C — in other words A instances are the factories for B instances, B instances the factories for C instances, and C instances the factories for D instances. (I also want each instance of D to store which instance of C created it, each instance of C to store which instance of B created it, and each instance of B to store which instance of A created it, but this is easily arranged by having each instance provide itself as an `__init__` argument when it creates an instance of the next class down in the hierarchy.)

These are model-layer classes that an application manipulates. There is no problem with the application manipulating instances of B, C, or D, it just shouldn't create them directly — all it should be able to create directly are instances of A (and A might even be a singleton). There are various kinds of validation, management, tracking, auditing, etc. that could be implemented in the methods of one class that create instances of the next.

An example might be a Operating System that can create Filesystems that can create Directories that can create Files, but application code would have to follow that chain. For example, even if it had its hands on a Directory, it shouldn't be able to create a File giving `File.__init__` the Directory instance even though that is what instances of Directory would do when asked to create a File.

I am looking for a design solution backed up some implementation, not something user-proof -- I understand the futility of the latter.

The only thing I have thought of so far is:

1. begin all class name except A with an underscore
2. access \_B() only from A instances, \_C() only from B instances, and \_D() only from \_C instances
3. rely on application-layer programmers to respect this arrangement and directly create instances only of the (possibly singleton) class A

Module-level "hiding" by omitting the class from the module's `__all__` list is insufficient, because the only affects `import *` constructions — another module could still reach the class by `import module` then referencing `module.class`.

(This is all vaguely reminiscent of the C++ problems that require two classes to be friends because they participate in a two-way relationship: instances of each class must be able to reference the methods of the other class that manage that the other side of the relationship.)

The solution that may best conform to the semantics and pragmatics of Python is to define D inside C, C defined inside B, and B defined inside A. This seems an awfully ugly way to cram multiple modules worth of code into a single very large class. (And imagine if the chain went down a few more levels.) This is an extension of more common uses of nested classes and maybe the only technically sound way of doing this, but I have never seen this sort of Russian-doll class structure.

Ideas?