[Python-Dev] Python 1.6 timing

[Guido van Rossum]

> 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/)