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! > > > >
-- http://mail.python.org/mailman/listinfo/python-list
