In article <BANLkTinHUC8q=fco7kvcaearf+q5qhh...@mail.gmail.com>, phil jones <inters...@gmail.com> wrote: > On Wed, Apr 13, 2011 at 12:07 AM, phelix <nab...@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, n...@acm.org _______________________________________________ IDLE-dev mailing list IDLE-dev@python.org http://mail.python.org/mailman/listinfo/idle-dev
