[Idle-dev] Suggestions idle-dev

[Ned Deily]

In article <BANLkTinHUC8q=FCo7KvCAEARf+Q5qHHXEQ at mail.gmail.com>,
 phil jones <interstar at gmail.com> wrote:
> On Wed, Apr 13, 2011 at 12:07 AM, phelix <nabble at traction.de> wrote:
> > Over the last couple of months I have collected a couple of small but imho
> > important modifications / bugs to make working with IDLE smoother. But I
> > would prefer very much to discuss these in a more active environment.
> >
> > Taking part in IDLE-development seems very hard, though it really does not
> > have to be. On the code-side everything is fine but marketing-wise things
> > are not so good. Just take this mailing list. I am in my thirties and to me
> > it looks like from the stone age. Who wants his eMail-account spammed with 
> > a
> > mailing list? I would prefer a regular forum and I think a lot of people
> > would, especially the younger ones.
> >
> > Also this list is hard to find. It is not mentioned anywhere on the
> > idle-homepage and not very obvious in the program.

The IDLE-dev mailing list is one of many hosted by python.org.  See 
http://www.python.org/community/lists/ for the link to the complete list 
here:  http://mail.python.org/mailman/listinfo

If you would prefer other formats, the mailing list is mirrored 
elsewhere.  In particular, gmane.org offers a bi-directional mirror of 
the list is several formats, including web-based blog and NNTP newsfeeds:
   
   http://dir.gmane.org/gmane.comp.python.idle

> A couple of things. Is there a source-code repository on Github (or
> some Mercurial equivalent) where everyone can see the
> work-in-progress?

IDLE is part of the Python standard library.  It resides in Lib/idlelib 
with the Python source tree.  The "default" branch of the tree is where 
all feature work happens; it will be what is released as Python 3.3.  
You can view the source here:
    http://hg.python.org/cpython/file/default/Lib/idlelib

The code for other branches can be viewed here:
    http://hg.python.org/cpython/branches
where 3.2 is what is in progress for 3.2.1, 3.1 for 3.1.4 (likely the 
last bug fix release for 3.1), and 2.7 for 2.7.2.  Older branches are 
closed except for critical security fixes.

There is a newly written Python Developer's Guide which describes the 
whole process of how to develop and contribute fixes and features for 
Python in general.  It applies to IDLE as well:

   http://docs.python.org/devguide/

> Is IDLE still part of the Python standard package? I use Ubuntu and I
> always find I have to install Idle separately from Python. I don't
> know if this is a Ubuntu perversity or whether Idle is now a
> stand-alone thing. Given that people always seem to have problems
> getting patches into the standard distribution maybe stand-alone would
> be better. But who would make this decision?

Some distributors of Python, like Ubuntu and Debian, choose to break out 
IDLE and other parts of the standard library into separate packages.  
Other distributions, like those from python.org/downloads, do not.  
Presumably, the rationale for making IDLE a separate package might be 
because of its dependency on Tcl/Tk.  Technically, IDLE uses the Python 
standard library Tkinter module which is dependent on Tcl/Tk.

IMO, that dependency on Tcl/Tk is both IDLE's strength and weakness.  (I 
should state that these are my opinions based on working on various 
recent fixes for IDLE on Mac OS X and not so much as an IDLE user.) The 
plus is that Tk is implemented on many platforms and thus gives IDLE and 
other Tkinter-based graphical apps high-level platform independence.   
But the weakness is that Tcl/Tk itself is aging and does not always 
provide a native look-and-feel.  Or there are significant compromises 
made on a platform to maintain that platform independence.  (The various 
Mac OS X "native" Tcl/Tk implementations are a prime example.)  Longer 
term, a replacement for IDLE using a more modern GUI interface would be 
an interesting project.   That really means finding a replacement for 
Tkinter in the standard library.  One of the most promising efforts for 
that is Greg Ewing's PyGUI project:

   http://www.cosc.canterbury.ac.nz/greg.ewing/python_gui/

I'd love to see someone try to reimplement IDLE using it.  That would go 
a long way towards helping to "get the library and its documentation 
included in the core Python distribution", a stated goal of PyGUI.

In the mean time, both IDLE and Tkinter are underrepresented in the 
Python development community.  They both could use more help.  Your 
patches are welcome.   The best thing to do is to follow the standard 
process outlined in the devguide and submit patches through the standard 
bug tracker.

Another big, big help would be to update and test submitted patches on 
the various Tk platforms: Windows, Unix X-windows, Mac OS X Aqua.  
Reporting the results on the bug tracker can help to move things along.  
I, for one, would be much more likely to commit a fix if there were 
independent confirmation that it is up-to-date and works as documented 
(which implies some sort of documentation, too).

And yet another big area is documentation for IDLE.  Currently, it is 
very sparse, between IDLE's build-in help file and the standard docs.  
The source for both are included in the source tree so doc patches for 
them would also be very welcome.

At the moment, there are no tests for IDLE that I am aware of, at least 
in the standard library.  This is a big problem for developers (like me) 
when wanting to add fixes or features.  Currently, there is no way to 
regression test fixes without time-consuming hit-or-miss manual testing 
which really needs to be done on at least what I think of as the three 
major variants (Windows, OS X, X11).  Few people have the know-how or 
setup to do that.  Python has a good and growing test base but very 
little at the moment for GUI testing.  An IDLE test base would be a huge 
step forward in that area.

So, lots of ideas and possibilities.  As with most all-volunteer open 
source projects, what happens is really up to those of us who step up 
and dig in.

-- 
 Ned Deily,
 nad at acm.org