> In the Python community, we've been pretty laid back > about how we name packages. When we were small, this made > sense. It doesn't make sense any more.
I'd like to see some evidence that this is the case. It doesn't seem so to me - most package names are relatively discoverable and/or intuitive, and we currently have basically no namespacing. There's a long way to go before something like your suggestion is needed, in my view.
Unfortunately, I think the sanest way of avoiding most package
name issues is to base them on domains, as is done in the Java
world. This goes against the Python philosophy of preferring
flat to nested, but I still think it's better than trying to police squatters,
or to encouraging races to claim top-level names.
No, no, no...
There's the point Donald made that you require people to own a domain (or you create some sort of hack like org.bitbucket.username/com.github.username/...) but it also makes package names unreasonably deep, and requires an explosion of namespace packages at the top level. And it's ugly :-)
Perl manages with a relatively flat namespace and relatively informal rules for managing package names (AIUI). I'm sure Python can, too.