Benevolent dictator versus the bureaucratic committee?

I have for some time been wondering about the usefulness of this mailing list. It seems to have produced staggeringly few results since inception. This is not a critisism of any individual, but of the process. It is proof in my mind of how effective the benevolent dictator model is, and how ineffective a language run by committee would be. This "committee" never seems to be capable of reaching a consensus on anything. A number of issues dont seem to provoke any responses. As a result, many things seem to die a slow and lingering death. Often there is lots of interesting discussion, but still precious few results. In the pre python-dev days, the process seemed easier - we mailed Guido directly, and he either stated "yea" or "nay" - maybe we didnt get the response we hoped for, but at least we got a response. Now, we have the result that even if Guido does enter into a thread, the noise seems to drown out any hope of getting anything done. Guido seems to be faced with the dilemma of asserting his dictatorship in the face of many dissenting opinions from many people he respects, or putting it in the too hard basket. I fear the latter is the easiest option. At the end of this mail I list some of the major threads over the last few months, and can't see a single thread that has resulted in a CVS checkin, and only one that has resulted in agreement. This, to my mind at least, is proof that things are really not working. I long for the "good old days" - take the replacement of "ni" with built-in functionality, for example. I posit that if this was discussed on python-dev, it would have caused a huge flood of mail, and nothing remotely resembling a consensus. Instead, Guido simply wrote an essay and implemented some code that he personally liked. No debate, no discussion. Still an excellent result. Maybe not a perfect result, but a result nonetheless. However, Guido's time is becoming increasingly limited. So should we consider moving to a "benevolent lieutenent" model, in conjunction with re-ramping up the SIGS? This would provide 2 ways to get things done: * A new SIG. Take relative imports, for example. If we really do need a change in this fairly fundamental area, a SIG would be justified ("import-sig"). The responsibility of the SIG is to form a consensus (and code that reflects it), and report back to Guido (and the main newsgroup) with the result of this. It worked well for RE, and allowed those of us not particularly interested to keep out of the debate. If the SIG can not form consensus, then tough - it dies - and should not be mourned. Presumably Guido would keep a watchful eye over the SIG, providing direction where necessary, but in general stay out of the day to day traffic. New SIGs seem to have stopped since this list creation, and it seems that issues that should be discussed in new SIGS are now discussed here. * Guido could delegate some of his authority to a single individual responsible for a certain limited area - a benevolent lieutenent. We may have a lieutentant responsible for different areas, and could only exercise their authority with small, trivial changes. Eg, the "getopt helper" thread - if a lieutenant was given authority for the "standard library", they could simply make a yea or nay decision, and present it to Guido. Presumably Guido trusts this person he delegated to enough that the majority of the lieutenant's recommendations would be accepted. Presumably there would be a small number of lieutentants, and they would then become the new "python-dev" - say up to 5 people. This list then discusses high level strategies and seek direction from each other when things get murky. This select group of people may not (indeed, probably would not) include me, but I would have no problem with that - I would prefer to see results achieved than have my own ego stroked by being included in a select, but ineffective group. In parting, I repeat this is not a direct critisism, simply an observation of the last few months. I am on this list, so I am definately as guilty as any one else - which is "not at all" - ie, no one is guilty, I simply see it as endemic to a committee with people of diverse backgrounds, skills and opinions. Any thoughts? Long live the dictator! :-) Mark. Recent threads, and my take on the results: * getopt helper? Too much noise regarding semantic changes. * Alternative Approach to Relative Imports * Relative package imports * Path hacking * Towards a Python based import scheme Too much noise - no one could really agree on the semantics. Implementation thrown in the ring, and promptly forgotten. * Corporate installations Very young, but no result at all. * Embedding Python when using different calling conventions Quite young, but no result as yet, and I have no reason to believe there will be. * Catching "return" and "return expr" at compile time Seemed to be blessed - yay! Dont believe I have seen a check-in yet. * More Python command-line features Seemed general agreement, but nothing happened? * Tackling circular dependencies in 2.0? Lots of noise, but no results other than "GC may be there in 2.0" * Buffer interface in abstract.c Determined it could break - no solution proposed. Lots of noise regarding if is is a good idea at all! * mmapfile module No result. * Quick-and-dirty weak references No result. * Portable "spawn" module for core? No result. * Fake threads Seemed to spawn stackless Python, but in the face of Guido being "at best, lukewarm" about this issue, I would again have to conclude "no result". An authorative "no" in this area may have saved lots of effort and heartache. * add Expat to 1.6 No result. * I'd like list.pop to accept an optional second argument giving a default value No result * etc No result.

On 01 November 1999, Mark Hammond said:
Perhaps this is an indication of stability rather than stagnation. Of course we can't have *total* stability or Python 1.6 will never appear, but...
* Portable "spawn" module for core? No result.
...I started this little thread to see if there was any interest, and to find out the easy way if VMS/Unix/DOS-style "spawn sub-process with list of strings as command-line arguments" makes any sense at all on the Mac without actually having to go learn about the Mac. The result: if 'spawn()' is added to the core, it should probably be 'os.spawn()', but it's not really clear if this is necessary or useful to many people; and, no, it doesn't make sense on the Mac. That answered my questions, so I don't really see the thread as a failure. I might still turn the distutils.spawn module into an appendage of the os module, but there doesn't seem to be a compelling reason to do so. Not every thread has to result in working code. In other words, negative results are results too. Greg

Mark> * Catching "return" and "return expr" at compile time Mark> Seemed to be blessed - yay! Dont believe I have seen a check-in Mark> yet. I did post a patch to compile.c here and to the announce list. I think the temporal distance between the furor in the main list and when it appeared "in print" may have been a problem. Also, as the author of that code I surmised that compile.c was the wrong place for it. I would have preferred to see it in some Python code somewhere, but there's no obvious place to put it. Finally, there is as yet no convention about how to handle warnings. (Maybe some sort of PyLint needs to be "blessed" and made part of the distribution.) Perhaps python-dev would be good to generate SIGs, sort of like a hurricane spinning off tornadoes. Skip Montanaro | http://www.mojam.com/ skip@mojam.com | http://www.musi-cal.com/ 847-971-7098 | Python: Programming the way Guido indented...

On 01 November 1999, Mark Hammond said:
Perhaps this is an indication of stability rather than stagnation. Of course we can't have *total* stability or Python 1.6 will never appear, but...
* Portable "spawn" module for core? No result.
...I started this little thread to see if there was any interest, and to find out the easy way if VMS/Unix/DOS-style "spawn sub-process with list of strings as command-line arguments" makes any sense at all on the Mac without actually having to go learn about the Mac. The result: if 'spawn()' is added to the core, it should probably be 'os.spawn()', but it's not really clear if this is necessary or useful to many people; and, no, it doesn't make sense on the Mac. That answered my questions, so I don't really see the thread as a failure. I might still turn the distutils.spawn module into an appendage of the os module, but there doesn't seem to be a compelling reason to do so. Not every thread has to result in working code. In other words, negative results are results too. Greg

Mark> * Catching "return" and "return expr" at compile time Mark> Seemed to be blessed - yay! Dont believe I have seen a check-in Mark> yet. I did post a patch to compile.c here and to the announce list. I think the temporal distance between the furor in the main list and when it appeared "in print" may have been a problem. Also, as the author of that code I surmised that compile.c was the wrong place for it. I would have preferred to see it in some Python code somewhere, but there's no obvious place to put it. Finally, there is as yet no convention about how to handle warnings. (Maybe some sort of PyLint needs to be "blessed" and made part of the distribution.) Perhaps python-dev would be good to generate SIGs, sort of like a hurricane spinning off tornadoes. Skip Montanaro | http://www.mojam.com/ skip@mojam.com | http://www.musi-cal.com/ 847-971-7098 | Python: Programming the way Guido indented...
participants (4)
-
Greg Ward
-
James C. Ahlstrom
-
Mark Hammond
-
Skip Montanaro