[Idle-dev] Suggestions idle-dev
nad at acm.org
Wed Apr 13 03:06:20 CEST 2011
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
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:
> A couple of things. Is there a source-code repository on Github (or
> some Mercurial equivalent) where everyone can see the
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:
The code for other branches can be viewed here:
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:
> 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:
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
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.
nad at acm.org
More information about the IDLE-dev