[Python-Dev] IDLE in the stdlib
eliben at gmail.com
Wed Mar 20 18:16:31 CET 2013
On Wed, Mar 20, 2013 at 10:11 AM, Todd Rovito <rovitotv at gmail.com> wrote:
> On Wed, Mar 20, 2013 at 12:41 PM, Eli Bendersky <eliben at gmail.com> wrote:
> > Interesting writeup about PyCon 2013 young coder
> > education:
> > Quote:
> > "We used IDLE because it's already on Raspian's desktop. Personally, I
> > IDLE as a teaching tool. It's included in the standard library, it does
> > completion and color coding, and it even has a text editor included so
> > don't have to start your class off by teaching everyone about paths.
> > Too bad it's broke as hell."
> > Personally, I think that IDLE reflects badly on Python in more ways than
> > one. It's badly maintained, quirky and ugly. It serves a very narrow set
> > uses, and does it badly.
> > Being part of Python *distributions* and being part of core Python
> > library are two different things. The former may make sense, the latter
> > makes no sense whatsoever. Outside the Python core IDLE can be maintained
> > more freely, with less restrictions on contributors and hopefully become
> > better tool.
> Thanks for sharing that article it was a fun read. I think the
> next paragraph from the article is important as well:
> "I believe my first contribution to the Python Standard Library will
> be fixes to IDLE. I really do like it that much. Happily, the kids
> were flexible. If they needed to do a workaround, or ignore something
> on our slides (they were written with the standard shell in mind),
> they did so. They were total champs. My adult students would have been
> much more upset."
> Having an IDE that ships with Python is powerful and follows Python's
> mantra "batteries included". Personally I think removing IDLE from
> the Python Standard Library is a mistake. IDLE helps the novice get
> started as demonstrated by this article. What is frustrating is many
> patches already exist for IDLE in the bug tracker they simply have not
> been committed. PEP-434 (http://www.python.org/dev/peps/pep-0434/) is
> designed to make it easier to get these patches committed. I would
> ask that you give PEP-434 some time and let the process work before we
> start a in-depth discussion on if IDLE should stay or go.
Todd, note that I did not propose to remove IDLE from Python distributions,
just from the Python core (Mercurial repository, to be technically
precise). This is a big difference. Outside the Python core a more
free-moving community can be built around developing IDLE. I've seen PEP
434, but it's far from being enough. I just don't think there are enough
core devs with the time and desire to review IDLE patches (especially
non-trivial ones). Outside the Python code, this can be relaxed. And Python
distributions can still bundle some stable IDLE release.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-Dev