Recently, Moshe Zadka email@example.com said:
Here's a reason: there shouldn't be changes we'll retract later -- we need to come up with the (more or less) right hierarchy the first time, or we'll do a lot of work for nothing.
I think I disagree here (hmm, it's probably better to say that I agree, but I agree on a tangent:-). I think we can be 100% sure that we're wrong the first time around, and we should plan for that.
One of the reasons why were' wrong is because the world is moving on. A module that at this point in time will reside at some level in the hierarchy may in a few years (or shorter) be one of a large family and be beter off elsewhere in the hierarchy. It would be silly if it would have to stay where it was because of backward compatability.
If we plan for being wrong we can make the mistakes less painful. I think that a simple scheme where a module can say "I'm expecting the Python 1.6 namespace layout" would make transition to a completely different Python 1.7 namespace layout a lot less painful, because some agent could do the mapping. This can either happen at runtime (through a namespace, or through an import hook, or probably through other tricks as well) or optionally by a script that would do the translations.
Of course this doesn't mean we should go off and hack in a couple of namespaces (hence my "agreeing on a tangent"), but it does mean that I think Gregs idea of not wanting to change everything at once has merit. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/%7Etank/spg-l/sigaction.htm