Improving Idle (was Re: Python 3 ...)
rantingrickjohnson at gmail.com
Sun Jul 20 03:31:27 CEST 2014
On Saturday, July 19, 2014 3:45:07 PM UTC-5, Terry Reedy wrote:
> On 7/19/2014 12:29 PM, Rick Johnson wrote:
> [2.7.2 and 3.2.2] are ancient versions from years ago that
> no one should be running Idle on now.
I have just downloaded and installed versions 2.7.8 and
3.4.1, and i am happy to report that both the "HOME_KEY"
*AND* the "CONTROL+LEFT_ARROW" events are working properly
and intuitively. I also would like to give my deepest
gratitude and thanks to those who corrected these
KEEP UP THE GOOD WORK GUYS!
> To repeat: I agree [that tab indention is bad], Raymond
> Hettigner agrees, everyone seems to agree, and we all have
> for years. http://bugs.python.org/issue7676 is over 4
> years old. But a patch can only implement a specific new
> behavior, not just 'stop the old'.
Just checked 3.4.1, and it is still using a tab for
indention. I know this issue is going to be a bit more
trouble to solve than the previous two "event" issues that i
mentioned, however, i feel it is an important issue to
To understand *HOW* we might resolve this issue, *FIRST* we
must understand the origins of the issue -- and as such, a
few basic "rules" of how the IDLE shell "interacts" with a
user is prerequisite.
1. The shell presents a prompt (in the case of the IDLE
shell the prompt is ">>> "), as a "starting" point for
2. The user begins typing his command at the prompt...
2a. In the process of typing his command, each time the
user presses the "ENTER" or "RETURN" keys (which i shall
from now on refer to them *singularly* as the: "ER-
KEYS"), the shell "intuits" whether the user intended to
complete his command "at-the-current-line" *OR* that the
user intends to "continue-writing-more-code", on
Note: As you can see the actions taken by pressing the
"ER-KEYS" depend on the context in which they where
pressed! If the command is "believed" to be *COMPLETE*,
then the action will be: "evaluate the users command now
and display a result", however, if the command is
"believed" to be *INCOMPLETE*, the action will be:
"allow the user to continue entering his command".
2b. If the "shell" believes that the user is finished
writing his command, the shell will evaluate the
*ENTIRETY* of the command (which could span one or more
lines!) and then display the result of that evaluation
*BENEATH* the command, however, if the shell "believes"
that the user intends to "continue-writing-more-code",
then the shell will allow the user to continue writing
STEP[N:]. There is much more to the interaction between
"shells" and "users", however, these first two steps, and
their subsequent "sub-steps", are all we need to concern
ourselves with at this time, in order to solve *THIS*
Now, between the "shell" and its "user" exists a contract,
and the preceding steps i outlined describe most of thast
contract, however, i realized that i can describe the full
contract more clearly by conflating the "shell" with "god"
and the "user" as some poor disciple. If we view the
contract through "the eyes of a *GODLIKE* shell" it might
read something like:
And the "shell" so-eth declared:
Ye shall be presented with a prompt, and from that prompt
thou shalt humbly enter requests. When i find thouest
requests pleasing, i shall reward thou with my vast
knowledge by displaying to you the result utilizing an
esthetically pleasing shade of blue, HOWEVER, shall i find
thou request to be illogical or malformed, i shall punish
thou with furious displays of my rebukes, utilizing the
"fear color" of *BLOOD* red! And thou shalt know my name
is the SHELL!
Furthermore, ye shall not be allowed to edit previous
request, no matter how blasphemous they may be! No, they
shall live as a testimate to thouest ignorance, a *PUBLIC*
testiment for all to see -- until which time thou decideth
to terminate our contract.
Now that we understand the contract between "shells" and
"users" we can focus in on the problem. The problem
manifests itself when the user wants to write commands that
span *MORE* than one line. For instance, when i write the
first line of a "multi-line source code" like this:
>>> for x in range(10):
And then i press the "enter key", the current IDLE shell is
going to insert a tab char (not good!), when it *SHOULD*
have inserted a "buffer prompt" of some kind, and then
calculated the correct "extrapolation-indentation" (by
adding four to the indent of line #1, which is four!) for
this new line of code.
>>> for x in range(10):
Notice the "buffer prompt" of "... ", after which follows
the "extrapolation indent" of " ", after which defines
the *BEGINNING* of my next command of "do_something"? Seems
simple enough huh? Oh but, my friend, *NOTHING* is simple in
this damn community is it!
Summary of the attempts to solve "INDENTION ISSUE" (at IDLE Bugs)
The comments on how to solve this problem read like a book
titled: "devils advocate for dummies".
IDEA_1: Hey, lets just use 8 space indention for the
*FIRST* level of indentation, and 4 space indention for
any *SUBSEQUENT* levels of indentation, that would not
solve the copy-paste problem *DIRECTLY*, however, it would
RESPONSE_1: Shhhhh! Are you nuts! Be quiet! We cannot
allow such easy remedies, because if we did, we would not
need a bug tracker! No sir, this software dev team takes
the protestant approach to problems -- we will suffer and
we will like it!!!
IDEA_2: Hey, lets just insert a "buffer prompt" for every
line that is *NOT* the *FIRST LINE* of the command, and
then use 4 spaces for indention... problem solved!
RESPONSE_2: Hardly! Can't do that because people cannot be
denied their "adolescent accessorizing" via font choice.
How can you expect people to use *ONLY* mono-spaced fonts,
i mean, geez, that's fascism! Besides, web-dings is vital
for the those of us who need to encrypt our code so
"peeping toms" cannot steal our snippets -- you never know
who might be watching!
IDEA_3: Hey, let's remove the embedded prompt from the
main shell window altogether and display it in a separate
"thin" area to the left -- sort of like how line numbers
are displayed in other IDEs. This would solve the copy
paste issue *AND* the indention issue. Plus, we can take
credit for Ricks idea from circa 2005, nobody listens to
RESPONSE_2: You fool! That would require *ACTUAL* skills
that we *DON'T* have. Only rr knows how to "lock" the
scrolling events of two Tkinter widgets, plus, he'd have
to change the underlying design of the entire shell
contract in such a *DRAMATIC* fashion that he'd be better
off just starting from scratch -- the IDLE source is a
Does the IDLE bug-tracker exist to *SOLVE* problems or to
> If you are running your tkinter code in the same process
> with Idle's tkinter code, either with ancient Idle or the
> '-n' startup option (possibly buried in a script), the
> situation is hopeless. If you are running your code in a
> separate process (now the default), then, most likely,
> Idle is not hanging. It is just waiting for your hung
> process. If so, Shell / Restart shell (^F6) will end the
> user process and start a new one.
Now that i have the most current releases of both Python2
and Python3, i will use IDLE exclusively to determine if
this "hanging issue" has been resolved, and if it has, i
will go from IDLEs loudest dissenter, to it's most exuberant
Granted, this "hanging" issue is not the *ONLY* remaining
issue, however, it is the *SOLE* issue that has motivated me
to stop using the software and write my own. I will only
change my position once i have not experienced this nuance
for a reasonable time... and only time will tell.
> Use one of the startup options directly above to see if
> you can get more information. A repeatable or at least
> semi-repeatable failure case is needed to do anything.
Yes. The very next time i get a hang, i'm going to post a
test case for all to see, so we might figure this out.
> > However, *EVEN* in the instances where a problem is a
> > direct result of a "Tkinter NO-NO" (being witting or
> > unwitting), the user of IDLE should *NEVER* be forced to
> > kill processes
> If you are talking about user processes, and we are
> talking about patching Idle, as opposed to Python or the
> OS (such as Windows), I disagree. If you are talking about
> the Idle process, then yes, I would prefer that once Idle
> starts, it run forever, and recover from any problems
> caused by users. Roger Serwy fixed many Idle shutdowns
> before being swallowed by a PhD program a year ago, but
> there is more to do.
My point is, that, when i run a Python program using
"IDLE->Run->Run Program", i expect that IDLE is going to
execute my program, catch any errors, and then report them
to me. What i don't expect, is that IDLE is going to hang,
freeze, churn, or totally go bonkers.
If IDLE, which is written in Python, cannot understand when
a Python program has failed, and take necessary actions to
exit cleanly *OR* allow the user to *MANUALLY* exit cleanly
at *ANY* time, then it is useless as an IDE, and should be
"repackaged" and "sold" as a "texteditor(with aspirations of
being an IDE one day)".
IF YOU CAN'T RUN WITH THE BIG DOGS, STAY ON THE PORCH!
PS: I do promise though to hold an optimistic view until
More information about the Python-list