Rearranging in temporal order
On 3/31/2015 7:22 PM, Al Sweigart wrote:
> Douglas Blank <dbl...@cs.brynmawr.edu> wrote:
I did not get the message from Douglas, only Al's quote.
>> On Tue, March 31, 2015 4:54 pm, Al Sweigart wrote:
I'm giving a keynote for the Python Education Summit to talk
about the IDLE Reimagined project and changing IDLE to be more
an education tool for beginners than a standard IDE for
developers. It'd be great to bounce deas off of IDLE developers
(or anyone who has ideas/critiques).
I am not going, but I have been thinking about Idle improvements for
years. There are issues and code for several on the tracker. The
following are what I see as major problems in making enhancements.
1. Tests. Without tests, whether automated unit tests or scripted
manual tests (I and GSOC students have added some of both), it is too
easy to introduce bugs when refactoring.
2. Bugs. Does it make sense to refactor buggy code? In any case, the
existing startup bugs, when triggered, are especially baffling to beginners.
3. Ambiguous approval authority. Years ago, Kurt Kaiser was the
BDFL-delegate for Idle. He has been inactive for years, but his latest
posts here and on pydev seem to say 'Idle's basic design is fine; don't
change or complicate it'. Guido seems to be more approving, in
principle, of changes, but does not seem interested in the detailed
discussions and reviews needed to turn vague ideas into reality. I do
not know how big a change I can make without having the work reverted
and dumped.
4. The dead hand of the past.
4a 2.7. When I wrote PEP 434 (Feb 2013), 2.7 maintenance was scheduled
to end summer 2015 (next summer), and I anticipated that Idle 2.7 would
be frozen at the same time. I planned to aim major enhancements at 3.x
after that.
At the Pycon a couple of months later, 2.7 maintenance was extended 5
years. Around the same Nick Coughlin requested that new tests be
backported to 2.7. I am currently unsure how to handle Idle on 2.7 in
the future.
4b idlelib. idlelib is currently a living mockery of PEP 8. For
instance, there are 5 or 6 different module name styles instead of just
one. In the meanwhile, work on Idle would be easier if some files were
split or combined and all names followed PEP 8. Although PEP 434
defines the idlelib API, including file names, as private, it was
written after 2.7 and there may be some external uses other than by
extensions. The guaranteed API for extensions needs to be pinned down
better. There are also issues with code inside the modules.
(At the moment I also have the problem that my hg install is broken and
the installer will not run on my system and I don't know yet how to fix
the situation.)
---
>> BTW, Did you see idlex? http://idlex.sourceforge.net/
I have. There are already issues on the tracker to incorporate some
idlex features into Idle. The idlex author, Roger Serwy has commit
privileges and committed some of his patches (mostly bugfixes), but
after two months stopped to focus on his PhD studies.
---
> I hold the view that most professional developers don't
really use IDLE,
I think that is a fact, not a view. Most professional developers use
multiple languages whereas Idle is focused on Python.
For a Python-only programmer, 'professional' or not, it can potentially
be *better*, in some ways, than multi-language tools. Note that there
are many Python users, from scientists to hardware designers, who fall
in between 'beginner' and 'professional software developer'.
so changing the design to emphasize an educational
tool over an experienced developer tool would benefit more people
than it would inconvenience.
The design is already intended to be focused on beginners, such as
students in programming classes. According to a survey reported by
Jessica McKeller at PyConUK 2014, Python is the third most used language
in undergradurate courses. So I think the proper question is how to
make Idle better for beginners.
Yesterday I had an idea for the following problem. Uncaught exceptions
result in a traceback followed by the exception name and message, such
as "ZeroDivisionError: division by zero". That line is, I hope, fairly
clear, but many, especially beginners especially, find some other
messages confusing.
Idlelib already has right-click context menus. A possible improvement
to to add an 'Explanation' option when on the last line of a traceback.
Selecting this would pop up a box with information about the
exception, and possible the specific message, including possible fixes.
I have implementation ideas that I omit here. However, I would make the
possibility of translating the popup messages to other languages part of
the design.
An 'Explanation' choice could be used for other lines.
For "Traceback ...", give a short explanation of what a traceback is.
For ">>> ", "Enter a Python statement on one or more lines."
For blue output lines, "Output produced by running your code."
For "**RESTART**" lines, explain user subprocess & globals clearing.
I have more concrete ideas on the wiki:
https://github.com/asweigart/idle-reimagined/wiki
I will comment on specific ideas in further posts here.
--
Terry Jan Reedy
_______________________________________________
IDLE-dev mailing list
IDLE-dev@python.org
https://mail.python.org/mailman/listinfo/idle-dev
