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 …
[View More]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
[View Less]
Hi,
Python 3 becomes more and more popular and is close to a dangerous point
where it can become popular that Python 2. The PSF decided that it's
time to elaborate a new secret plan to ensure that Python users suffer
again with a new major release breaking all their legacy code.
The PSF is happy to announce that the new Python release will be
Python 8!
Why the version 8? It's just to be greater than Perl 6 and PHP 7, but
it's also a mnemonic for PEP 8. By the way, each minor release will now
…
[View More]multiply the version by 2. With Python 8 released in 2016 and one
release every two years, we will beat Firefox 44 in 2022 (Python 64) and
Windows 2003 in 2032 (Python 2048).
A major release requires a major change to justify a version bump: the
new killer feature is that it's no longer possible to import a module
which does not respect the PEP 8. It ensures that all your code is pure.
Example:
$ python8 -c 'import keyword'
Lib/keyword.py:16:1: E122 continuation line missing indentation or outdented
Lib/keyword.py:16:1: E265 block comment should start with '# '
Lib/keyword.py:50:1: E122 continuation line missing indentation or outdented
(...)
ImportError: no pep8, no glory
Good news: since *no* module of the current standard library of Python 3
respect the PEP 8, the standard library will be simplified to one
unique module, which is new in Python 8: pep8. The standard library will
move to the Python Cheeseshop (PyPI), to reply to an old and popular
request.
DON'T PANIC! You are still able to import your legacy code into
Python 8, you just have to rename all your modules to add a "_noqa" suffix
to the filename. For example, rename utils.py to utils_noqa.py. A side
effect is that you have to update all imports. For example, replace
"import django" with "import django_noqa". After a study of the PSF,
it's a best option to split again the Python community and make sure
that all users are angry.
The plan is that in 10 years, at least 50% of the 77,000 packages on the
Python cheeseshop will be updated to get the "_noqa" tag. After 2020,
the PSF will start to sponsor trolls to harass users of the legacy
Python 3 to force them to migrate to Python 8.
Python 8 is a work-in-progress (it's still an alpha version), the
standard library was not removed yet. Hopefully, trying to import any
module of the standard library fails.
Don't hesitate to propose more ideas to make Python 8 more incompatible
with Python 3!
Note: The change is already effective in the default branch of Python:
https://hg.python.org/cpython/rev/9aedec2dbc01
Have fun,
Victor
[View Less]