Community (A Modest Proposal)

[rantingrick]

On Jun 14, 3:20 pm, Terry Reedy <tjre... at udel.edu> wrote:

> 1. I agree.
> 2. This does not much affect me since I do not directly enter compound
> statement with more than, say, 2 lines in the body, even with the
> command window interpreter. I much prefer a full screen editor.

But i think you'll agree that fixing this is important even if not to
you, right?

> There was a thread about this a few months ago. As I reported then,
> there is only a problem (for me, at least) when one severs the
> connection to the background process with control-C. Since I almost
> never need to do that except when testing ;-), this is not a problem.

I get this problem when doing heavy Tkinter development. Since IDLE is
written in Tkinter you can create some "zombie" processes very easily.
It may be more of a tk.mainloop issue than anything but that is what i
am referring to. I did go over a few months of bug reports last night
just to get an idea of what people are wanting fixed.

> > Not to mention the fact
> > that a file dialog, replace dialog, or find dialog can lose focus and
> > drop to the bottom of the window stack faster than Obama's approval
> > ratings after BP takes a leak!
>
> I have not noticed this.

Open a few IDLE windows (at least three) Then goto File->SaveAs and
let the dialog appear. Then refocus the window stack to another IDLE
window. The SaveAs dialog will drop to the bottom of the stack. This
should not be allowed, the SaveAs needs to be a transient of the
window that called it. And to further the problems, you can even open
*another* SaveAs window and not ever be aware that one is hiding back
there!!! Only one file dialog should be allowed open at any one time!
This is a major design flaw, however luckily an easy fix!

> When I tried to read the IDLE code with an eye to helping with patches,
> I got lost in the setup code before I even got to the tk gui code. So I
> can easily imagine that it might be better organized to be more easily
> read and maintained. Perhaps I will try again some time.

Wait a minute Terry, this is where we keep going astray!. We need to
work *together* to solve this problem. Don't go out on your own into a
bewildering ocean of poorly written code (sorry Guido)! Maybe i am
pretty good with Tkinter, design models, motivation, and you're better
with RPC, subprocess, parsers, whatever! No one person can bring about
the better IDLE, we need to tackle this as a team with a clear focus
on the end game. We can see the current status quo is getting nowhere
fast.

Now I don't want to apply too much pressure on you Terry, however you
"Terry Reedy" may be the *only* hope for a complete IDLE re-write. Why
you ask? Because only *you* have the reputation that will bring in the
heavy artillery. No one can pick apart your good reputation. If you
lead, they will follow!

As for myself I can re-write all the GUI code and lead the re-design
of the code base. I have the vision, the motivation, and the skills.
However i need others to pick up the pieces that i cannot. United we
are destined to win, divided we are doomed to fail!

If we form a group, get the input from everyone, create a better code
base, and hash out a plan. Then we can fix this damn thing once and
for all! IDLE cannot be fixed with a patch here or a patch there. It
is antiquated code that must be re-written for usability's sake AND
for readability's sake... although we can salvage quite a bit!

We need to find the people with diverse skill sets and focus those
diverse skills in a very direct and intelligent manner, meanwhile
simultaneousness covering each others weaknesses (thigh to neck!).
Like the impenetrable Spartan phalanx for example...

"""We will stop IDLE's rotting code by rebuilding the great IDLE
community! And from there, we will funnel this code into the filter we
call common sense. Now, in that focused corridor of thought, it's
numbers of atrocious code lines will count for nothing! And wave after
wave of IDLE abominations will *smash* against our Pythonic shields.
IDLE's losses will be *so* great, it's atrocious code base *so*
demoralized, it will have no choice but to abandon this static
development cycle and yield to the very will of Pythonia!"""

What say ye...?