[Python-Dev] Removing IDLE from the standard library (original) (raw)

Ron Adam rrr at ronadam.com
Tue Jul 13 01:01:31 CEST 2010

On 07/12/2010 01:21 PM, Ian Bicking wrote:

On Sun, Jul 11, 2010 at 3:38 PM, Ron Adam <rrr at ronadam.com_ _<mailto:rrr at ronadam.com>> wrote:

There might be another alternative. Both idle and pydoc are applications (are there others?) that are in the standard library. As such, they or parts of them, are possibly importable to other projects. That restricts changes because a committer needs to consider the chances that a change may break something else. I suggest they be moved out of the lib directory, but still be included with python. (Possibly in the tools directory.) That removes some of the backward compatibility restrictions or at least makes it clear there isn't a need for backward compatibility.

I also like this idea. This means Python comes with an IDE "out of he box" but without the overhead of a management and release process that is built for something very different than a GUI program (the standard library). This would mean that IDLE would be in site-packages, could easily be upgraded using normal tools, and maybe most importantly it could have its own community tools and development process that is more casual (and can more easily integrate new contributors) and higher velocity of changes and releases. Python releases would then ship the most recent stable release of IDLE.

Yes, if you follow the guide lines for the rest of the library, anything that is removed needs to be depreciated first and anything thats added needs to be carefully looked at to be sure it doesn't break anything that may depend on it. That is good for the rest of the standard library but really slows things down for an application like idle. Just removing those restrictions would make things a lot simpler and speed things up considerably I think.

The site-packages directory is still in the lib path and so things there are still importable. That is why I suggested the tools directory. Another place would be in the same directory the python executable lives.

But the exact location isn't really the important thing, having a clear policy on how the upgrade policy differs from the python library is what is needed.

Ron

Ron

More information about the Python-Dev mailing list