Call it 1.6, per the rest of the thread.
OK. I expect I'll get some complaints from some people who asked when 1.6 would be out (I've generally told them end of 2000); but it sounds like a 1.7 would be necessary to fulfill the other promises, so it shouldn't really matter -- it's all a case of relabeling for PR purposes.
Unicode: definitely. distutils seems pretty early, but I bet that some key concepts could be added to 1.6, to make the transition and continued development easier.
The point of adding distutils is that it will allow distribution of packages without including distutils with each distribution. Since distutils was about 200K itself last time I looked, this is important. I don't believe it would be good to have to say "My FooBar package is really easy to install. All you need to do is download and install distutils, (which by the way is a 200K package that you have to manually install), and then run "python setup.py" in the FooBar root directory..." This would be enough for the average person to run away screaming. I think I saw a distribution by AMK that had a setup.py that tried to use distutils but had a crude fallback if distutils didn't exist; however that defeats much of the purpose since the package author has to figure out how to do the fallback. Large distributions (e.g. NumPy) can afford to squeeze distutils in a corner of their distribution, but for the average package it wouldn't be of much use. In other words, I'm for putting distutils in the next release, essentially feature-freezing it. Greg Ward, what do you think of that?
Note that if an announcement were made to the effect of "feature freeze on February 15; only bug fixes afterwards," that you would get a lot of people scrambling to submit their pet features. This would be a good way to light some fires, to see what kinds of things get completed (i.e. we may think some things aren't ready or are too far out, put that deadline in and those positions could change...)
I bet you we couldn't complete the import hooks by that date; I consider imputil.py as a nice prototype, but the integration with the C code is still missing. Also the 50% slowdown is a problem I worry about for inclusion a production version. (Plus breakage of everybody else's code who uses or hacks __import__; e.g. have you tested it with rexec?)
(The import utilities are not ready for prime time in my opinion; there are too many issues.)
I'm waiting for that review :-)
It was kept up by the need to get the types documents out.
If you raise issues, then I can knock them down. I don't see all that many at the moment. But I'm biased :-)
Anybody care to be the pumpkin? That would cut the discussion short; otherwise the problem remains that I can't spend too much time on the next release unless I get funded for it; what little money I've received for CP4E I had better spend on getting some CP4E-related results ASAP, because the next installment of this funding is very much at stake...
I would volunteer for the pumpkin... around April-ish. My plate is rather full with completing mod_dav and then integrating that into Apache 2.0. Once the Apache integration begins, then I'd have some more free time.
But this begs the question of: what does the pumpkin-holder mean in the *Python* world?
If it is collating fixes, producing snapshots, etc, then I'm comfy with it. If it also contains responsibility for specific kinds of work, then Fred would probably veto me :-), as I've got an outstanding doc that I owe him (for about six months now... sigh; maybe I'll bribe MAL to write it; he knows the interface :-)).
But stll: what's it mean? How does the pumpkin reduce the Guido-load, yet still enable the Guido-control?
Good questions. I have to say that I feel reluctant to release any kind of control -- yet at the same time I desperately need help getting trivial stuff checked in. One of the most important time-consuming tasks is quality control: collecting fixes is all well and good, but I routinely reject fixes that superficially look fine, because they are subtly broken, or interfere with other plans, or just because the code looks poorly written. I also spend a lot of testing before I check things in; running the standard test suite is a good safeguard against general breakage, but you really have to play with the code affected by the change before you can know that it works as advertised. My work attitude here means that what gets checked in is generally rock solid, and that helps Python's reputation; but it is very costly...
[ I just had a talk about this with the guys at Inprise, re: InterBase, mentioning that the Dictator model works well for Python, but doesn't necessarily work well for new projects or commercially-started projects due to control/prejudice issues. Python people like it because of the resulting simplicity and cleanliness; I doubt we want a pumpkin approach that would allow that to go away! ]
Agreed, of course. --Guido van Rossum (home page: http://www.python.org/~guido/)