[Python-Dev] Python 1.6 timing

[Greg Stein]

On Thu, 20 Jan 2000, Guido van Rossum wrote:
>...
> Date:    Wed, 19 Jan 2000 20:17:55 -0500
> From:    "A.M. Kuchling" <amk1@erols.com>
> To:      guido@python.org
> Subject: Python 1.6 timing
> 
> I thought a bit more about the release schedule for 1.6, and like the
> idea of delaying it less and less.  Another bad effect of delaying it
> is that not having Unicode in the core handicaps developing XML tools;
> we can continue working with wstrop, or integrate MAL's code into the
> XML-SIG's CVS tree, but it might mean abandoning the XML processing
> field to Perl & Tcl because the tools can't be made fully standard
> compliant in time.

I agree with Andrew's basic premise.

> Options I can think of:
> 
> 	1) Delegating some control to a pumpkin holder [...].

Seems fine.

> 	2) Releasing the Unicode+sre modules as separate add-ons to
>  	   1.5.  (But would that impose annoying
> 	   backward-compatibility constraints when they get integrated
> 	   into 1.6?)

Icky. :-)

> 	3) Add Unicode, sre, Distutils, plus other minor things and
>            call it 1.5.5, meaning it's not as big a revision as a 1.6
>            release, but it's bigger than just another patchlevel of
> 	   bugfixes.  I don't remember what other features were
> 	   planned for 1.6; was there anything major, if static typing
> 	   is left for 2.0?

Call it 1.6, per the rest of the thread.

>...
> For 1.5.5 (what happened to 1.5.3 and 1.5.4?), we can have a more
> conservative agenda, as suggested by Andrew: Unicode and distutils are
> probably the most important things to integrate.

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.

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

> (The import
> utilities are not ready for prime time in my opinion; there are too
> many issues.)

I'm waiting for that review :-)

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?

[ 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! ]

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/