IDLE: A cornicopia of mediocrity and obfuscation.

[rantingrick]

PLEASE KINDLY IGNORE MY FIRST TWO POSTS:
  Due to some errors i need to repost.
Thank you.



IDLE: A cornicopia of mediocrity and obfuscation.
-- by Rick Johnson


IDLE --which is the Python Integrated Development and Learning
Environment-- was once the apple of Guido's eye but has since
degenerated into madness many years ago and remains now as the shining
jewel "show piece" on the proverbial python wall of shame. A once
mighty dream of "programming for everyone" that is now nothing more
than an example of "how NOT to program".

IDLE contains some of the worst code this community has created. Bad
design patterns, tacked on functionality, blasphemous styling, and
piss poor packaging. There seems to be no guiding goals or game-plan.
And year after year if IDLE *does* get any attention it's just more
haphazard code thrown into the mix by someone who has gone blind from
reading the source. However we cannot blame the current maintainer --
if any such even exists-- because NOBODY can maintains such a
spaghetti mess that this package has become!

If we would have had a proper game plan from day one i believe we
could have avoided this catastrophe. Follows is an outline of the
wrongs with some suggestions to right them...

 * First of all the main two modules "PyShell" and "EditorWindow" are
laid out in such a non sequential way that it is virtually impossible
to follow along. We should have had a proper app instance from which
all widgets where combined. The main app should have followed a
"common sense" sequential mentality of...

 * subclassing the tk.Toplevel
 * initializing instance variables
 * creating the main menu
 * creating the sub widgets
 * declaring internal methods
 * declaring event handlers
 * interface/generic methods.

... This is the recipe for order AND NOT CHAOS! What we have now is
utter chaos! When we have order we can read source code in a
sequential fashion. When we have order we can comprehend what we read.
And when we have order we can maintain a library/package with ease.
However sadly we DO NOT have order, we have CHAOS, CHAOS, and more
CHAOS!

* The underlying sub widgets should have started with their own proper
order of "declared" initialization. And all events should be handled
in the widget at hand NOT outsourced to some other class!

 * One of the biggest design flaws is the fact that outside modules
manipulate the main editor/pyshells events. This is a terrible way to
code. For example the AutoCompleteWindow takes over the tab event.
This is a bad design! The main editor window should handle all its own
events AND THEN call outside class methods when needed...

  #-- Puesdo Code --#
  # in editor window __init__
  self.autocomplete = AutoComplete(blah)
  # in editor window onKeyPress(blah)
  if key == 'Tab' and blah:
      self.autocomplete.show_tip(blah)
  elif key == 'Escape' and acw.is_visibe():
      self.autocomplete.hide()

...We don't want "Mommy" classes telling the kids what to do, when to
eat, when to sleep, and when to excrete! We should create our objects
with the virtue of self reliance and responsibility!. The Colorizer,
ParenMatch, CallTips, and many other modules are guilty of "event
stealing" also. Event functionality must be handled in the widget
itself, NOT stolen and handled in an outside class. When we split up
sequential code we get CHAOS!

 * Another bad choice was creating custom reusable widgets
(Tabbedpages, FindDialog, ReplaceDialog, textView, TreeWidget, etc...)
and leaving them in idlelib. These should have been moved into the lib-
tk folder where they would be more visible to python programmers AND
we could reduce the cruft in the idlelib! Remember, when we create
more files, folders, and objects we create CHAOS. And nobody can learn
from CHAOS!

 * Another blasphemy is the fact that every module should include some
sort of test/demo to display its usage. If the module is a GUI widget
then you MUST show how to use the widget in a window. Sadly like all
everything else, idlelib is devoid of examples and testing. And the
very few tests that DO exists just blow chunks!

 * Last but not least idlelib does not follow PEP8 or ANY convention.
So much so that it seems the developers snubbed their nose at such
conventions! We are missing doc strings and comments. We have built-
ins being rebound! Just code horror after code horror.

These are just the top of the list. The peak of a huge iceberg that
threatens to sink the community in the arms of chaos never to return.
I am beginning to believe that this community is made of amateurs due
to this lackluster code in the stdlib. However it could be that the
folks are really professional and refuse to work on such a horrible
code base (which i understand). I am going with the latter.

When are we going to demand that these abominations be rectified? How
much longer must we wait? A year? Ten years?... i don't think Python
will survive another ten years with this attitude of obfuscation, and
mentality of mediocrity.

-- rr: disappointed and annoyed!