IDLE: A cornicopia of mediocrity and obfuscation.

[Giampaolo Rodolà]

So what you're actually telling is that Python won't survive another
10 years because:

- IDLE is it's default editor
- idlelib directory is the first place you should look every time you
need an inspiration on how code should be written
- code in idlelib directory sucks

That's an interesting point and I thank you for pointing that out.
Personally I've never looked into idlelib directory for 7 years in a row at all.
I was probably doing some other things, I don't know, but now I'm
definitively gonna start looking for a new language because it's clear
that any language having a directory called "idlelib" within such a
horrible source code is not gonna last for long.


Thanks again,


--- Giampaolo
http://code.google.com/p/pyftpdlib/
http://code.google.com/p/psutil/


2011/1/31 rantingrick <rantingrick at gmail.com>:
> 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!
> --
> http://mail.python.org/mailman/listinfo/python-list
>