<br>I expressed this opinion at the sprints (right before I left) in the group discussion with Guido and Nick, but I'm not sure if it's been represented in this thread yet (I'm jetlagged and talk about Windows command prompts depresses me) -- so I'll just rehash it: distributing IDLE in the binary packages people download from <a href="http://python.org" target="_blank">python.org</a> means *python-dev is still responsible IDLE*. We can't distribute something that we don't support. Even for the third-party libraries we're wrapping we're taking responsibility for updating them, fixing specific bugs or working around the bugs in the wrappers. Removing IDLE from the source tarballs isn't a way to disown it, or shed responsibility. The benefits of having IDLE in a separate repository, as I see it, would be that we can have separate access control for the repositories, and possibly make it more approachable for new developers, and easier to re-use by other Python implementations. We couldn't even sensibly stop accepting bugs for it on <a href="http://bugs.python.org" target="_blank">bugs.python.org</a>.<div>

<br></div><div>It may well be that moving IDLE to a separate repository is the right thing, but only if there's an active team of people working on it that would prefer it that way. And only if we realize that if IDLE languishes again, python-dev is *still* on the hook for it, even in the separate repository. I don't know if excluding it from the source tarball gains us anything on top of that -- although I do think we should move 'idlelib' out of the standard library :)</div>

<div><br></div><div>-- <br>Thomas Wouters <<a href="mailto:thomas@python.org" target="_blank">thomas@python.org</a>><br><br>Hi! I'm an email virus! Think twice before sending your email to help me spread!
</div>