I assume that language implementors "like" flat namespaces because they are easy to implement. Or easier. I've never looked into how such things are done, but i

I assume that language implementors "like" flat namespaces because they are easy to implement. Or easier. I've never looked into how such things are done, but it seems like flat namespaces are a much simpler problem in terms of implementation, at the cost of making users of the language be careful about name collisions. "Flat is better than nested" is a rule of thumb, not a maxim. I agree that the python standard library could use a bit more nesting, but I think that going to the same lengths as java wouldn't fit with python too well. I've never had to step carefully to avoid namespace clashes in python - I'm curious as to when and/or how you run into this problem. The only way I can think of that would make my code run into it a lot would be if I was doing a lot of "from foo import *", which generally isn't a good idea. "import foo", or "import foo as bar" serves the same purpose. It seems to me that having a nested namespace for the standard library, but not to the point that it's a tree, is roughly analogous to a lot of other design decisions in Python - for example, there not being any concept of private or protected variables, at least on the high level.