Summary: There are two prospective Google Summer of Code (GSOC) students
applying to work on writing a gui interface to the basic pip functions
needed by beginners. I expect Google to accept their proposals. Before
I commit to mentoring a student (sometime in April), I would like to be
sure, by addressing any objections now, that I will be able to commit
the code when ready (August or before).
Long version:
In February 2015, Raymond Hettinger opened tracker issue
"IDLE to provide menu options for using PIP"
https://bugs.python.org/issue23551#msg236906
The menu options would presumably open dialog boxes defined in a new
module such as idlelib.pipgui. Raymond gave a list of 9 features he
thought would be useful to pip beginners.
Donald Stufft (pip maintainer) answered that he already wanted someone
to write a pip gui, to be put somewhere, and that he would give advice
on interfacing (which he has).
I answered that I had also had a vague idea of a pip gui, and thought it
should be a stand-alone window invoked by a single IDLE menu item, just
as turtledemo can be now. Instead of multiple dialogs (for multiple
IDLE menu items), there could be, for instance, multiple tabs in a
ttk.Notebook. Some pages might implement more than 1 of the features on
Raymond's list.
Last September, I did some proof-of-concept experiments and changed the
title to "IDLE to provide menu link to PIP gui". In January, when Terri
Oda requested Core Python GSOC project ideas, I suggested the pip gui
project. I believe Raymond's list can easily be programmed in the time
alloted. I also volunteered to help mentor.
Since then, two students have submitted competent prototypes (on the
tracker issue above) that show that they can write a basic tkinter app
and revise in response to reviews.
My current plan is to add idlelib/pipgui.py (or perhaps pip.py) to 3.5
and 3.6. The file will be structured so that it can either be run as a
separate process ('python -m idlelib.pipgui' either at a console or in a
subprocess call) or imported into a running process. IDLE would
currently use a subprocess call, but if IDLE is restructured into a
single-window, multi-tab application, it might switch to using an import.
I would document the new IDLE menu entry in the current IDLE page.
Separately from the pip gui project, I plan, at some point, to add a new
'idlelib' section that documents public entry points to generally useful
idlelib components. If I do that before next August, I would add an
entry for pipgui (which would say that details of the GUI are subject to
change).
Possible objections:
1. One might argue that if pipgui is written so as to not depend on
IDLE, then it, like turtledemo, should be located elsewhere, possibly in
Tools/scrips. I would answer that managing packages, unlike running
turtle demos, *is* an IDE function.
2. One might argue that adding a new module with a public entry point,
in a maintenance release, somehow abuses the license granted by PEP434,
in a way that declaring a public interface in an existing module would
not. If this is sustained, I could not document the new module for 3.5.
Thoughts?
--
Terry Jan Reedy
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
