> Guido van Rossum <guido@python.org>: > > 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 > > As have I. All the stuff in this thread was before the checkin; > you were in fact mistaken about the timing of most of the discussion. No, I was not mistaken about the timing; you must have misunderstood what I said about the timing. When I posted the URL for this thread this afternoon, I knew that it took place before your checkin. I did not see evidence either in the mailing list or in the code that you took any of the advice though. > > 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 > > :-). > > I did not ignore these suggestions (one that I took was Greg Ward's > suggestion that, after all, just throwing an exception was the right > thing). And I was in fact planning to merge this thing with fileinput. > > Then I looked as what would have to be done to the documentation of > fileinput -- in fact, I edited together a combined fileinput > documentation page. The result was a mess that convinced me that this > does indeed need to be a separate module. There wasn't enough > coherence between the old fileinput stuff and my entry points to even > make the *documentation* look like a logical unit, let alone the code. So, as a matter of process, you should not have checked it in without coming back to the list with your experience. > > > 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 :-(. > > In the event, my mail was not broken. > > > 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 > > Right...one of which completely misses the point by suggesting that > this is a filter framework, and the other one of which is a "me too" > basically addressing the naming issue. Guido, you are yourself > *notorious* for dismissing naming issues with "that's unimportant" and > "we can fix it later". How can you criticize me for doing likewise? I am criticizing you for not responding at all to the feedback -- whether it was mistaken or not. That's another violation of process. Why is suggesting it is a filtering framework completely missing the point? If this is not a filter framework, WHAT IS IT? > > > 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. > > So what, exactly, makes this 'random'? > > That, Guido, is not a rhetorical question. We don't have any > procedures. We don't have any guidelines. We don't have any history > of anything but discussing submissions on python-dev before somebody > with commit access checks them in. If no -1 votes and the judgment of > somebody with commit privileges who has already got a lot of stuff > in the library is not sufficient, *what is*? Absence of -1 votes is not enough. I didn't see any +1 votes -- just suggestions to try a different tack. I happened to be too busy at the time you checked this in to weigh in, but I had a big -1 in my head which I thought was reflected by other comments. Eric, I respect you as a person, but as a Python developer, I don't trust your judgement enough to let you check stuff in without a clear green light from me. > I'm not trying to be difficult here, but this points at a weakness in > our way of doing things. I want to play nice, but I can't if I don't > know your actual rules. I don't know what *would* have been sufficient if > what I did was not. I don't think anyone else does, either. Everybody else who doesn't know the rules for sure starts a discussion, either here or on the patch manager. You are the only one of the 30+ committers who *repeatedly* commits controversial stuff. I'm not saying that the rules are clear enough (they clearly aren't if even you don't get them), but I think there's a better way to get clarity than by acting like a bull in a china cabinet. > > Some comments on the code: > > This is the sort of critique I was looking for two weeks ago, not a bunch > of bikeshedding about how the thing should be named. I'll respond to this later. First I want you to be clear on the process: commit privileges are not to be used to force an issue. (Admin privileges will be used to force an issue if necessary. :-) --Guido van Rossum (home page: http://www.python.org/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4