I found this interesting because the ConfigMapping stuff reminds me a lot of Python. I knew that Python OO was inspired by Java OO to some extent, but I didn't

I found this interesting because the ConfigMapping stuff reminds me a lot of Python. I knew that Python OO was inspired by Java OO to some extent, but I didn't expect so much similarity. I think Python could learn similar lessons here. But the flipside is that none of this stuff is a catastrophe in Python either, and the author's tone seems a bit out of proportion with what they're complaining about. The author complains about: 1) not knowing the underlying data model and implementation details that might affect their design 2) mutable attributes and non-final classes 3) lack of obvious composition root In the Python world, we often say that "we are all consenting adults here". Usually there is no need for private, immutable, or final things because people read docs know not to stray from the public interface. The trust also runs the other way, and it's very rare for the function to perform some kind of weird unexpected mutation. A function that mutates a user-provided object without the user's knowledge or consent is usually considered a bug. I actually found exactly this bug recently in a framework I was using, and several people were up in arms about it on the issue tracker. Yes, immutable data makes it harder/impossible to write such bugs. But the community generally has not devolved into a Satanic orgy of mutable state. Likewise, if a framework did something ridiculous like reloading a config file at every request, nobody would use it! I could only imagine how lively that GitHub issue thread would be. A framework that makes fundamentally bad design decisions tends not to be a lasting part of the community. The only one that really would suck, and that also doesn't seem to be a problem in Python, is the lack of an obvious composition root. I have never heard this term before, but it is a very very well-established pattern in Python application and library architecture. A framework that made it hard to design libraries in a conventional sensible way, would not be a very popular framework.