[Python-Dev] IDLE in the stdlib

[Guido van Rossum]

On Wed, Mar 20, 2013 at 12:14 PM, Benjamin Peterson <benjamin at python.org>wrote:

> 2013/3/20 Barry Warsaw <barry at python.org>:
> > On Mar 20, 2013, at 11:22 AM, Eli Bendersky wrote:
> >
> >>IDLE would be a great first foray into this "separate project" world,
> >>because it is many ways a separate project.
> >
> > I really think that's true.  A separate project, occasionally sync'd
> back into
> > the stdlib by a core dev seems like the right way to manage IDLE.
>
> I would advise against this. Basically, every "externally-maintained"
> package with have causes pain. For example, the stdlib now has some
> long-diverged fork of simplejson. With xml.etree, it was not clear for
> years whether core developers could touch it even though the external
> project had died. Either the stdlib and IDLE should go separate ways
> or development has to happen in the stdlib with CPython release
> schedule and policies.
>

Agreed that the "sync into stdlib" think should not happen, or should at
best be a temporary measure until we can remove idle from the source
tarball (maybe at the 3.4 release, otherwise at 3.5).

The main thing I like about the separate project idea is that, given that
only a small group of people care about IDLE, it is much more satisfying
for them to be able to release IDLE separately to their user community
regularly (every month if they want to) rather than being held to the core
Python release schedule and practices. We should deal with compatibility
obligations of the stdlib in the usual way, though maybe we can just delete
it in 3.4, since few people presumably use idlelib apart from IDLE itself.
Binary distributions from python.org should still include IDLE (and Tcl/Tk)
-- however we should switch to bundling the separate project's output
rather than bundling the increasingly broken version in the stdlib. What
other distributors do is outside our control, but we ought to recommend
them to do the same.

-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20130320/9cecad30/attachment.html>