IDLE: A cornicopia of mediocrity and obfuscation.

[Westley Martínez]

alias idle='vim'

: D

On Mon, 2011-01-31 at 09:39 -0800, rantingrick wrote:

> 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
>  * then 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....
> 
>   #-- 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()
> 
>  This is a bad design! The main editor window should handle all its
> own events AND THEN call outside class methods when needed. 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, textView, TreeWidget, 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, etc...) and leaving them in
> idlelib. These should have been moved into the lib-tk module 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 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 re-bound! 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 either 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!
> 
> 
> 
> 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20110131/fb4bd6c2/attachment-0001.html>