On 4/20/06, Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
Anthony Baxter wrote:
From what I remember, he didn't actually say that you should never rewrite anything, but that if you do, you need to be prepared for a very long period of time when nothing new is working, and that *if you are a commercial company* this is a bad idea.
But Python is not dependent on getting new features out the door before its competitors in order to survive, so this doesn't really apply. It doesn't matter if people have to make do with the old distutils for a while until something better is available.
I think it's more a matter of scale. Rewriting small pieces of code is fine. Joel's argument applies to attempts at rewriting *entire systems* that cause massive loss of information on why things were the way they were. I don't think distutils, huge "ball of mud" as it is, hass quite crossed the size threshold that Joel was thinking of; but it *is* an extremely valuable repository of outlandish information about the bizarre details of many different platform, and as such I'd be hesitant undertaking a wholesale rewrite. I'd rather recommend the approach that Joel suggests for truly large systems: refactoring smaller components while keeping the overall structure intact. I find 100% backwards compatibility perhaps less interesting (not uninteresting, just less) than preserving the body of knowledge that is uniquely encapsulated in distutils. Unfortunately, this is mixed in with some stuff that isn't part of distutils' "core competency", like text utilities, process spawning, and option parsing. These should (eventually, when the 2.1 compatibility requirement is lifted) be refactored to use (or be merged into) the available stdlib facilities for such functionaliy. -- --Guido van Rossum (home page: http://www.python.org/~guido/)