A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2010-July/101848.html below:

[Python-Dev] Removing IDLE from the standard library

[Python-Dev] Removing IDLE from the standard libraryRon 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

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4