On Wed, Mar 20, 2013 at 10:11 AM, Todd Rovito <rovit...@gmail.com> wrote:
> On Wed, Mar 20, 2013 at 12:41 PM, Eli Bendersky <eli...@gmail.com> wrote: > > Interesting writeup about PyCon 2013 young coder > > education: > http://therealkatie.net/blog/2013/mar/19/pycon-2013-young-coders/ > > > > Quote: > > > > "We used IDLE because it's already on Raspian's desktop. Personally, I > like > > IDLE as a teaching tool. It's included in the standard library, it does > tab > > completion and color coding, and it even has a text editor included so > you > > 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 > of > > uses, and does it badly. > > > > Being part of Python *distributions* and being part of core Python > standard > > library are two different things. The former may make sense, the latter > IMHO > > makes no sense whatsoever. Outside the Python core IDLE can be maintained > > more freely, with less restrictions on contributors and hopefully become > a > > better tool. > Eli, > 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. Eli
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
