[Python-Dev] IDLE in the stdlib

[Brett Cannon]

On Wed, Mar 20, 2013 at 3:51 PM, Xavier Morel <python-dev at masklinn.net>wrote:

> On 2013-03-20, at 20:38 , Barry Warsaw wrote:
>
> > On Mar 20, 2013, at 12:31 PM, Guido van Rossum wrote:
> >
> >> 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).
> >
> > Right.  Ultimately, I think IDLE should be a separate project entirely,
> but I
> > guess there's push back against that too.
>
> The problem with it is, well, that it's a separate project so unless it
> is still packaged in (in which case it's not quite separate project,
> just a separate source tree) it's got to be downloaded and installed
> separately.
>
> That would be a blow to educators, but also Windows users: while the CLI
> works very nicely in unices, that's not the case with the win32 console
> which is as best as I can describe it a complete turd, making IDLE a
> very nice proposition there (I never use IDLE on Linux or OSX, but do
> all the time in Windows). It also provides a rather capable (and in many
> case sufficient) code editor for a platform which lacks any form of
> native text editor allowing sane edition of code.
>
> Installing the Python windows packages and having everything "work" (in
> the sense that you can immediately start writing and running python
> code) is — I think — a pretty big feature.


First, a clarification since people seem to have missed it a couple of
times: both Eli and Guido said IDLE would continue to be bundled with
binary distributions from python.org, just developed independently. Now
Guido's comment may have just been to handle deprecation of IDLE from the
stdlib, but at least he wasn't saying "leave it out tomorrow", just "take
it out of the stdlib to be developed independently". That still allows it
to come with Python and alleviate any installation issues by shifting the
load to release managers.

Second, I hear the "it will hurt educators" argument every time this topic
comes up, and so I want to know exactly where the challenge comes from. Is
it from people coming to a class with their own laptop where they can't
install anything due to lack of knowledge but can bring up a shell and type
"idle"? If that were the case can't you also just as easily teach them to
type "pysetup pip", "pip install idle", "idle"? Or heck, if Nick's
dead-simple bootstrap installer could handle "pysetup idle" then you can
cut that down a step. Notice that none of this suggests the removal of
tkinter since that never changes and the hard work is already done
(although if we could get the binary wheel for the various OSs to just
include tkinter w/ IDLE then that could also potentially move out and
shrink the binary even further).

Is it lack of administrative access on machines in a computer lab? Then I
would ask if IDLE is even included in Linux distributions by default
typically or can be removed separately?

Is it lack of administrative access on personal laptops? In that case you
should be able to ask them to find out the password before they come. You
can also ask them to install into their user-level site-packages directory
(we have PEP 370 for a reason).

Regardless of the answers to the questions above, I support the idea of at
least releasing IDLE more often and that mostly means developing it
externally from the stdlib. If we want to continue to bundle it in the
binary, then we should pull in the latest stable release when we cut a new
version of Python. But regardless the current situation should not continue.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20130320/7cbf37a7/attachment.html>