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