Eric didn't merge it with fileinput, but instead checked in a separate module "compilerlike". I have several comments on the code, but my main complaint is about process. This is a random bit of code that got checked in without any kind of discussion about whether it was worth checking into the standard library, and whether this particular implementation was right. There was some discussion afterwards, to which Eric did not respond. Given that Eric apparently doesn't care enough about his code to defend it, I propose to delete it from CVS.
I'll do this as part of the 2.2a3 release which (given the encouraging feedback so far) I'll try to do around Sept. 5.
Now, wait a second!
Well, a response at last.
There *was* in fact discussion of this thing beforehand. Several listmembers said they thought it was a good idea. And I have seen *no* discussion *at all* since it was checked in.
I have now re-read that discussion; it's in the archives starting this message: http://mail.python.org/pipermail/python-dev/2001-August/016629.html There were several suggestions to merge it with fileinput and some suggestions to restructure it. You seem to have ignored these except the criticism on the name "ccframe" (by choosing an even worse name :-).
What is going on here? Is it possible that you are mistaken about the timing of the checkin, and that what you thought was discussion afterwards was discussion before? Or am I somehow missing listmail?
Your mail was probably broken -- it wouldn't be the first time :-(. There are two posts in the archives that start with a quote from the checkin mail: http://mail.python.org/pipermail/python-dev/2001-August/017131.html http://mail.python.org/pipermail/python-dev/2001-August/017132.html
As for process issues...I agree that we need better procedures and criteria for what goes into the library. As you know I've made a start on developing same, but my understanding has been that *you* don't think you'll have the bandwidth for it until 2.2 is out.
That's not an excuse for you to check in random bits of code. Some comments on the code: - A framework like this should be structured as a class or set of related classes, not a bunch of functions with function arguments. This would make the documentation easier to read as well; instead of having a bunch of functions you pass in, you customize the framework byu overriding methods. - The name "compilerlike" is a really poor choice (there's nothing compiler-like in the code). - I would like to see failure to open the file handled differently (so the caller can issue decent error message for inaccessible input files without having to catch all IOError exceptions), but again this is a policy issue that should be customizable. - The policy of not writing the output if it's identical to the input should be optional. There are contexts (like when the tool is invoked by a Makefile) where not writing the output could be harmful: if you touch the input without changing it, Make would invoke the tool over and over again because the output doesn't get touched by the tool. Moreover, there seems to be some bugs: if the output is the same as the input, the output file is not written even if a filename transformation was requested (making Make even less happy); when a transformation is specified by a string, an undefined variable 'stem' is used. Hasty work, Eric. :-( --Guido van Rossum (home page: http://www.python.org/~guido/)