[Idle-dev] IDLE Dev 2013

[phil jones]

Hmmm ... this all sounds distinctly deja vu ... if I understand
correctly, the curse and blessing of IDLE is that it's part of the
official Python distribution and so you have to become a "python
developer" to engage with it.

What, I think, most enthusiastic newcomers like Katie are looking for
is something like "the IDLE project" with its own repository
(preferably git, because that's what people use these days), easy
forking / merging. A dedicated responsible team for IDLE etc. We've
had IDLEfork, we've had VIDLE, IDLEx and as Bruce points out, things
never seem to get back into the official Python-bundled version of
IDLE.

Maybe as Todd points out, that's because not enough volunteers offer to test.

But I'd like to raise the suggestion that the biggest problem with
IDLE is still the development workflow itself. If it's not broke, at
least it's not up to the expectations of today's developers.

I remember being surprised that IDLE lacks a developers' front-page of
the kind that something like Github gives you. (Eg. see this thread
from 2011 : http://mail.python.org/pipermail/idle-dev/2011-December/003105.html
).

To quote Roger Serwy :

> The IDLE code is included with the standard library. It can be found in the Mercurial repository referenced at http://docs.python.org/devguide/

> I agree that the wiki should include this information.

Indeed ... er .. what wiki?  And notice that that link makes no
reference at all to IDLE. Nor does
http://docs.python.org/devguide/faq.html.  While
http://docs.python.org/2/library/idle.html still has no information
for developers.

I'd suggest that someone who wants to look at the IDLE source and
potentially tinker with it doesn't want to have to check out the whole
Python source. Or search through documentation that seems to be about
something completely different. We need an IDLE project, with a
"getting started for IDLE developers" page. And an address  (The
idle-python and python-idle domains are available in all com, org and
net variants - I'm happy to buy one and donate to the project if that
will help.) This is not about quarantining IDLE or removing it from
the standard distro. It's about giving it an identity that people can
engage with rather than it being hidden within the rest of the python.

I know it's easy to criticise from the side-lines and the core
volunteer developers are busy. But I'd bet that if the little energy
that was available for IDLE was focussed initially on making the
project more accessible and friendly to potential new developers /
testers, I think the effort would pay back.

Phil

BTW : I take Terry's point
(http://mail.python.org/pipermail/idle-dev/2011-December/003109.html)
that versions of IDLE need to be locked to versions of Python. But it
seems to me you could still ensure that, while giving IDLE its own
repository. Eg. just use a "branch" of the IDLE repo for each version
of Python. Sure, someone would still have to test that version XYZ
branch 2.75 of IDLE still worked with python 2.75, but at least
everyone else working on


On 22 March 2013 17:35, Bruce Sherwood <Bruce_Sherwood at ncsu.edu> wrote:
> (Thanks, Katie and Guido, for explaining about up arrow referring to the
> shell.)
>
> I've been busy with other matters during the last few years, so the
> following concerns about IDLE development may, I hope, no longer be a
> problem.
>
> In the Google Summer of Code 2009 I mentored Guilherme Polo, who made a
> number of very important contributions to IDLE. This was a project approved
> by the Python community, and there were assurances that Polo's improvements
> would become part of the IDLE distributed with official downloads of Python.
> Alas, as far as I can tell this didn't happen, apparently because there was
> no well-defined path for updating IDLE. So my first concern is whether it is
> now the case that if important improvements are made, is there any chance
> they would make it into the official Python distributions. What is the
> situation today?
>
> Secondly, to check on the current status, I just installed Python 3.3.0 on
> Windows and Mac and tried out IDLE. On Windows, judging from the "Configure
> IDLE" menu option, IDLE apparently lacks (at least) two significant features
> of Polo's work, one vitally important for a large population of student
> users. On the Mac, clicking on the Preferences menu option (for configuring
> IDLE) causes a crash, but I assume the situation is similar to that on
> Windows.
>
> Among many improvements, Polo implemented a feature that if there is an
> execution error in a spawned program that creates a window, the shell with
> the error message comes forward of that window so that you see the error,
> with an IDLE preference for invoking this behavior. The shell does come in
> front of the edit window in the case of an execution error, but at least in
> older versions of IDLE if running the program creates a new window, and that
> window covers the shell window, an execution error doesn't bring the shell
> window forward. I couldn't immediately think of a way to test this in a
> newly installed Python 3.3.0, but unless this behavior is now the default
> and therefore there's no need for a preference setting, presumably this
> feature isn't in the currently distributed IDLE.
>
> Why is this feature important? Every year thousands of engineering and
> science students who take the required college introductory physics course
> and use the textbook "Matter and Interactions" (matterandinteractions,org)
> write Python programs to model physical systems, using the VPython 3D
> programming environment (vpython.org). Very few of these college students
> have ever written a computer program before, and the language (Python), the
> 3D aspects (VPython), and the program editor (IDLE) must be extraordinarily
> easy to learn and use, because in a physics course, where computational
> modeling is vitally important, it isn't feasible to teach a lot of computer
> science.
>
> It is an experimental fact of life that these students typically make all of
> the relevant windows, including the 3D graphics window (based on OpenGL),
> huge. When an execution error occurs, the program of course stops, and the
> students tend to sit there wondering why the animation has stopped, because
> the shell window with its error message is hidden behind the graphics
> window. After 12 years deployment of VPython, I can say that it's easier to
> improve IDLE than to modify student behavior.
>
> Incidentally, VPython is downloaded about 60,000 times per year, and about
> 10,000 of those downloads occur at the start of the two US college
> semesters, clearly by students who use VPython in their classes. VPython is
> also used by researchers who need an easy programmatic access to making 3D
> animations. For a recent example, see
> http://astronomia.udea.edu.co/chelyabinsk-meteoroid/
>
> I'll mention that the shell is irrelevant for the students, except of course
> for print outputs and error messages. The students are writing full programs
> in the edit window (with preferences set to bring up an edit window, not a
> shell window).
>
> Another significant feature of Polo's work that still hasn't made it into
> IDLE is the preference option to permit not having to save the program at
> all, something that makes a surprisingly big difference for experimentation.
> Programmers who like playing experimenting in the shell have the luxury of
> just typing and running, but programmers who like writing short full
> programs in the edit window and hitting F5 to run are inconveniently
> interrupted by the current IDLE in being required to save the program
> somewhere, which interrupts the train of thought. Polo added a preference to
> IDLE to permit running without ever saving the program (with of course a
> warning if you kill the editor without saving).
>
> Because I considered these improvements and various bug fixes carried out by
> Polo to be so important, yet there seemed to be no way to get IDLE updated,
> starting in 2009 I reluctantly have included his work under the name of
> VIDLE (VPython version of IDLE) within the VPython installers.
>
> Stepping up a level, it's preaching to the choir in this forum, but removing
> IDLE (with or without improvements) is a terrible idea. Expert programmers
> could care less, because they'll use Eclipse or Emacs or even vi. It's
> really really important that upon installing Python you can start work
> immediately with a good colorizing editor, even if you're a complete novice.
>
> Bruce
>
> P.S. A couple of related news items: Assisted by Steve Spicklemire, I've
> made a major change in the architecture of VPython so that it is now based
> on wxPython, the cross-platform GUI library. This has made it possible to
> eliminate almost all of the old platform-dependent code, which was written
> in C++, and replace it with pure Python code. Among many other advantages,
> this makes it possible for VPython to run on 64-bit Mac Python, where
> VPython must necessarily be based on Cocoa, whereas VPython had been based
> on Carbon. Unfortunately the Python 3.x version of wxPython ("Phoenix")
> isn't quite ready for prime time, so the new version of VPython is currently
> available only for Python 2.7.
>
> Also, inspired by the easy-to-use VPython API, which has made it feasible
> for programming novices to write Python programs that generate real-time
> navigable 3D animations, with David Scherer I created GlowScript
> (glowscript.org) which runs in a browser using WebGL, with programs written
> in JavaScript or CoffeeScript. There's a Python program that helps convert a
> VPython program to a GlowScript program.
>
> _______________________________________________
> IDLE-dev mailing list
> IDLE-dev at python.org
> http://mail.python.org/mailman/listinfo/idle-dev
>