IDLE: A cornicopia of mediocrity and obfuscation.

Discussion in 'Python' started by rantingrick, Jan 31, 2011.

  1. rantingrick

    rantingrick Guest

    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!
    rantingrick, Jan 31, 2011
    #1
    1. Advertising

  2. rantingrick

    rantingrick Guest

    On Jan 31, 11:39 am, rantingrick <> wrote:


    In my original post i showed this code....

    #-- 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()


    ....is a suggested FIX of the current code NOT a generalization of the
    current code. However it may easily be miss-interpreted due to
    improper placement in the paragraph.
    rantingrick, Jan 31, 2011
    #2
    1. Advertising

  3. rantingrick

    rantingrick Guest

    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!
    rantingrick, Jan 31, 2011
    #3
  4. >However we cannot blame the current maintainer...
    You seem to still not know who -we- is. rewrite your message using I in place of we, and you'll be on the right track.
    Littlefield, Tyler, Jan 31, 2011
    #4
  5. 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 <>:
    > 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
    >
    Giampaolo Rodolà, Jan 31, 2011
    #5
  6. rantingrick

    rantingrick Guest

    On Jan 31, 1:32 pm, Giampaolo Rodolà <> wrote:
    > So what you're actually telling is that Python won't survive another
    > 10 years because:
    >
    > - IDLE is it's default editor


    Well not solely because IDLE is the default editor. IDLE is very
    useful to newcommers and could be made even more useful however the
    code base is rotten!

    > - idlelib directory is the first place you should look every time you
    > need an inspiration on how code should be written


    In an ideal world it should be the first place you look when wanting
    to learn how to build medium sized GUI projects with the built-in
    Tkinter module. However the reality is ANYTHING but ideal. The code is
    rotten to the core, full of inconsistencies and just very unpythonic.
    Not something i would suggest any aspiring Tkinter n00b look at unless
    they want to learn what NOT to do.

    > - code in idlelib directory sucks


    plainly and simply... YES.

    > 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.


    And i am glad, because had you followed the example of IDLE you would
    be spreading mediocrity and obfuscation. Both of which are not virtues
    to be admired.

    > 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.


    Well not unless we do something about it. It is high time to stop
    patching, bolting on, and future extending the suffering of this
    horrendous code base. It is time to pull the plug, let it die, and
    start fresh. Start from a real python perspective. We can learn from
    past mistakes and build something much better. But will we? Do we have
    the community spirit to take on this challenge? Do we as a community
    have any fire left or have we collectively waxed cold?
    rantingrick, Jan 31, 2011
    #6
  7. rantingrick

    Robert Guest

    On 2011-01-31 15:19:44 -0500, rantingrick said:

    > On Jan 31, 1:32 pm, Giampaolo Rodolà <> wrote:
    >> So what you're actually telling is that Python won't survive another
    >> 10 years because:
    >>
    >> - IDLE is it's default editor

    >
    > Well not solely because IDLE is the default editor. IDLE is very
    > useful to newcommers and could be made even more useful however the
    > code base is rotten!


    Then DO something about it and no excuses. Fork it, make it better,
    submit it as a replacement.

    --
    Robert
    Robert, Jan 31, 2011
    #7
  8. rantingrick

    Kevin Walzer Guest

    Rick,

    I've spent a fair amount of time in the IDLE source tree, putting
    together patches for various Mac-specific bugs and submitting them to
    the Python tracker, and I agree the code is crufty and disorganized. It
    is certainly not an example of current best practices in Tkinter
    development. The code base has accrued over the years, has been touched
    by many, many different hands, and I think its current messy state
    reflects that legacy.

    But, as I understand it, the purpose of IDLE is not to provide a
    pedagogical example of Tkinter programming practices, but instead to
    provide a lightweight development environment for those learning Python,
    to interactively explore different aspects of Python. For this it serves
    its purpose well. I use IDLE a good deal for my Python development work,
    and the cruftiness of the code under the hood is not an impediment to me
    getting my work done (unless the work is patching IDLE itself).

    Given this, I don't see any huge need to bulldoze IDLE to the ground and
    replace it with something else, or even do massive rewrites of the code,
    unless such a project also significantly improved the user-facing
    portions of IDLE as well. However, there are certainly no impediments
    for you undertaking such a project yourself: similar efforts have been
    undertaken in the past and, as I understand it, have led to some
    significant improvements in IDLE's performance. Here's the one I'm
    thinking of:

    http://idlefork.sourceforge.net/

    According to this project's details, IDLE was forked, numerous changes
    were made to its code base, the new version of IDLE gained a user base,
    and eventually the changes were merged back in to Python's main line of
    development.

    It certainly would be interesting to see a fresh approach to IDLE, and I
    think the scope of such a project would be much easier for a single
    person to manage than would replacing Tkinter in the stdlib with another
    GUI toolkit, such as wxPython, or pyGUI, or something else. I'd
    encourage you to set up a project page somewhere, begin cutting some
    code, and then invite feedback from other users and/or developers. I
    think that approach has a much better chance of getting off the ground
    and making progress than long threads on c.l.py.

    Good luck!

    --Kevin

    --
    Kevin Walzer
    Code by Kevin
    http://www.codebykevin.com
    Kevin Walzer, Jan 31, 2011
    #8
  9. rantingrick

    Robert Guest

    On 2011-01-31 17:17:06 -0500, Kevin Walzer said:
    >
    >
    > It certainly would be interesting to see a fresh approach to IDLE, and I
    > think the scope of such a project would be much easier for a single
    > person to manage than would replacing Tkinter in the stdlib with another
    > GUI toolkit, such as wxPython, or pyGUI, or something else. I'd
    > encourage you to set up a project page somewhere, begin cutting some
    > code, and then invite feedback from other users and/or developers. I
    > think that approach has a much better chance of getting off the ground
    > and making progress than long threads on c.l.py.
    >
    > Good luck!
    >
    > --Kevin


    I think it would be interesting as well. Hmmmm, I am about to do the
    O'Reilly series that Steve Holden did for Python. Maybe I will take
    that up as a project when I get through it (or...*nudge* *nudge* *wink*
    *wink* to Rick, help out if someone else does a fork).

    --
    Robert
    Robert, Jan 31, 2011
    #9
  10. On 1/31/11 10:12 AM, rantingrick wrote:
    > -- rr: disappointed and annoyed!


    tl;dr

    You did this one before, I swear.

    You're running out of material.

    --

    Stephen Hansen
    ... Also: Ixokai
    ... Mail: me+list/python (AT) ixokai (DOT) io
    ... Blog: http://meh.ixokai.io/


    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v2.0.10 (Darwin)

    iQEcBAEBAgAGBQJNR1BUAAoJEKcbwptVWx/lIBsH/17UUzv+mUTTGgZOhO9i5Ib0
    kBAoOPvdaTOOSWPqsGYZNOz1Nvzq9OgmU3FOU276iUO575R1gVDnfhNdcSf98sZz
    +zUCrRJRMkrQvgpPFpzvF6gofaf01Vlu9f5PLg3bMZyfJgDYg0JmnsHY9WuOacOl
    kpsJFRU8YhWl63JF7C5F8JH+ju/6VxEsPDtYJ7DFMmAotmeyHSs4Qw7wWOpg0Nkb
    BX5u4beiJxziXWR5XvCKKC5T1NC/KPlEd0Qh9w9A/s9JC7IS/7oKRBEQXxrVblgS
    1kYQRow6YCSqukPrl+ohhqSbi23CE1+jzv2htrJwinGKBnG41D8wzIx8UXkGwfQ=
    =+hWa
    -----END PGP SIGNATURE-----
    Stephen Hansen, Feb 1, 2011
    #10
  11. 2011/1/31 rantingrick <>:
    > In an ideal world it should be the first place you look when wanting
    > to learn how to build medium sized GUI projects with the built-in
    > Tkinter module.


    I wouldn't do that, and thankfully in the *real* world what is
    considered more important usually gets more attention.
    If instead of ranting nonsense all day long you would spend a little
    bit of your time by taking a look at how crowded the python bug
    tracker already is, you would discover an interesting thing which goes
    under the name of "priority".
    High priority bugs get fixed first. IDLE source code is clearly not a
    high priority issue, hence it doesn't get fixed: end of story.
    Actually I don't even understand how can IDLE source code quality have
    anything to do with python success or future adoption, as you implied
    in your statements.
    And why do you care so much anyway? You have spent the past 5 days
    blabbing about how bad Tkinter is, how ugly and useless it is
    nowadays, and now you suddenly care about IDLE source code quality?
    Do you have any idea how ridiculous this looks from the outside?

    > However the reality is ANYTHING but ideal. The code is
    > rotten to the core, full of inconsistencies and just very unpythonic.


    99% of the times the right answer to this statement is "go file a bug
    and possibly provide a patch" but not in your case since it's clear
    that you have absolutely no interest in resolving *anything*, let
    alone actually write some code, assuming you're able to do so in the
    first place.

    >> 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.

    >
    > Well not unless we do something about it. It is high time to stop
    > patching, bolting on, and future extending the suffering of this
    > horrendous code base. It is time to pull the plug, let it die, and
    > start fresh. Start from a real python perspective. We can learn from
    > past mistakes and build something much better. But will we? Do we have
    > the community spirit to take on this challenge? Do we as a community
    > have any fire left or have we collectively waxed cold?


    How can you possibly not understand that I was being sarcastic?


    --- Giampaolo
    http://code.google.com/p/pyftpdlib/
    http://code.google.com/p/psutil/
    Giampaolo Rodolà, Feb 1, 2011
    #11
  12. rantingrick

    rantingrick Guest

    On Jan 31, 4:17 pm, Kevin Walzer <> wrote:
    > Rick,
    >
    > I've spent a fair amount of time in the IDLE source tree, putting
    > together patches for various Mac-specific bugs and submitting them to
    > the Python tracker, and I agree the code is crufty and disorganized. It
    > is certainly not an example of current best practices in Tkinter
    > development. The code base has accrued over the years, has been touched
    > by many, many different hands, and I think its current messy state
    > reflects that legacy.


    Thanks for admitting this. Some people refuse to see the truth!

    > But, as I understand it, the purpose of IDLE is not to provide a
    > pedagogical example of Tkinter programming practices, but instead to
    > provide a lightweight development environment for those learning Python,
    > to interactively explore different aspects of Python. For this it serves
    > its purpose well. I use IDLE a good deal for my Python development work,
    > and the cruftiness of the code under the hood is not an impediment to me
    > getting my work done (unless the work is patching IDLE itself).


    Yes. IDLE is first and foremost a tool to get work done. However we
    should not ignore the fact that IDLE could also be a great learning
    resource for Tkinter GUI's and other subjects. Why not clean up the
    code base? We could start small. First, move the custom widgets like
    textView, Tabbedpages, FindDialog, ReplaceDialog, and TreeWidget into
    the lib-tk for others to use more freely. Then we can modify the
    "event robbers" CallTips, ParenMatch, and ColorDelegator. Just small
    steps Kevin. It all starts with babysteps. At least we would be doing
    something. Currently we are sitting around waiting for a miracle to
    happen, and problems are solved by methods, not miracles!


    > Given this, I don't see any huge need to bulldoze IDLE to the ground and
    > replace it with something else, or even do massive rewrites of the code,
    > unless such a project also significantly improved the user-facing
    > portions of IDLE as well.


    Well some changes and improvements can be made to the UI as well.
    rantingrick, Feb 1, 2011
    #12
  13. rantingrick

    rantingrick Guest

    On Jan 31, 4:38 pm, Robert <> wrote:

    > I think it would be interesting as well. Hmmmm, I am about to do the
    > O'Reilly series that Steve Holden did for Python.


    Did you see the video Steve Holden did with Trish Gray? Just for fun
    fast forward to 0:03:30. Just as Trish comments about Python diversity
    Steve gets all shook up... man you could cut the tension with a
    knife!!!

    http://www.oreillyschool.com/courses/python1/

    Oh, and Trish, if you are out there and you would like a "personal"
    introduction to Python programming i would be very happy to give you
    some very, very, private lessons using my python...
    ..
    ..
    ..
    ..
    ..
    .....interpretor. *wink*

    ;-)
    rantingrick, Feb 1, 2011
    #13
  14. rantingrick

    rantingrick Guest

    On Jan 31, 9:24 pm, Giampaolo Rodolà <> wrote:

    > Actually I don't even understand how can IDLE source code quality have
    > anything to do with python success or future adoption, as you implied
    > in your statements.


    Well thats because you are not looking at this from the correct
    perspective. Every piece of code, every module, every documentation,
    every community grudge reflects on us in positive and negative ways.
    And the IDLE library is reflecting pretty badly on us. The IDLE
    library is making us look like a bunch of two bit script kiddies who
    cannot even follow our own philosophies.
    rantingrick, Feb 1, 2011
    #14
  15. On 1/31/11 9:26 PM, rantingrick wrote:
    > Oh, and Trish, if you are out there and you would like a "personal"
    > introduction to Python programming i would be very happy to give you
    > some very, very, private lessons using my python...
    > .
    > .
    > .
    > .
    > .
    > ....interpretor. *wink*
    >
    > ;-)


    You are disgusting.

    If Trish Gray were here, I'd offer a sincere apology on behalf of the
    community for you.

    Which is ironic, considering how one of my major complaints about you is
    your audacity to claim to speak for "We", "The Community". But I have to
    hope we're better then this.

    Disgusting.

    --

    Stephen Hansen
    ... Also: Ixokai
    ... Mail: me+list/python (AT) ixokai (DOT) io
    ... Blog: http://meh.ixokai.io/


    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v2.0.10 (Darwin)

    iQEcBAEBAgAGBQJNR6PeAAoJEKcbwptVWx/lsRoH/15RsPqSQPVJKzddbVbcmuN3
    BiE54xp6R73v1ypCrqfWpg2izrOSXPVZFuLKYjzYl5fHB7T99O4OSNPmYKfvywOe
    LQHwVzzuY9LDDUABqvo53DyLrsw2Gjs6iPuBZW8nFi8DyT0HtkV1sGPFWOaUE8dk
    olb0CvtRYjABxTwuwj9CgIHffpFadJxWkLJfkqHIIeRacHwiSyIT1cQoXGX+9eLL
    W1t/Z0i/ym8ifL6GBvTYId+z7rqtHtMHlQgJtBx12X6itgn6XW+g/jOrIA3W9qfP
    tXgSyP0cR5Kp6nMqV03XgzBXPrQaz8rL1UyV7BxGibwPBt8l6eEzAg+QPQtiTw4=
    =hsvQ
    -----END PGP SIGNATURE-----
    Stephen Hansen, Feb 1, 2011
    #15
  16. rantingrick

    rusi Guest

    On Feb 1, 1:35 am, Raymond Hettinger <> wrote:
    > However, even the parts of the standard library written in pure Python
    > don't seem to be getting read anymore, so I'm still inclined to
    > attribute the issue to 1) inconvenient placement of source code,
    > 2) a largish code base, and 3) possibly a cultural shift.



    There is another thread running where this was said (by a python
    developer?)

    > Actually I don't even understand how can IDLE source code quality have
    > anything to do with python success or future adoption, as you implied
    > in your statements.
    > High priority bugs get fixed first. IDLE source code is clearly not a
    > high priority issue, hence it doesn't get fixed: end of story.


    Now if we can put aside for a moment the fact that the person to whom
    this was said specializes in the art of raising others' blood
    pressures and making them say what they may not otherwise have said,
    it should be clear that this priority is at cross purposes with
    Raymond's.

    In short (at the risk of belonging to the equivalence class of others
    whose names start with R) I would suggest a 4th point: Code cruft

    Please note: I am thankful to all python devs for giving me python.
    Its just that when functionality becomes as large as it is for python
    and the target is fast moving, keeping code spic and span will
    generally be perceived to be a priority that has crossed the point of
    diminishing returns. Consequence: noobs have a higher barrier to
    entry than earlier
    rusi, Feb 1, 2011
    #16
  17. rantingrick

    rusi Guest

    On Feb 1, 11:14 am, rusi <> wrote:
    > On Feb 1, 1:35 am, Raymond Hettinger <> wrote:


    snipped

    O O wrong thread... sorry!
    rusi, Feb 1, 2011
    #17
  18. rantingrick

    flebber Guest

    On Feb 1, 4:39 am, 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!


    Sorry Rick too boring....trying to get bored people to bite at your
    ultra lame post yawn...........
    flebber, Feb 1, 2011
    #18
  19. rantingrick

    rantingrick Guest

    On Feb 1, 4:20 am, flebber <> wrote:

    > Sorry Rick too boring....trying to get bored people to bite at your
    > ultra lame post yawn...........


    Well reality and truth both has a tendency to be boring. Why? Well
    because we bathe in them daily. We have come accustomed, acclimated,
    and sadly complacent of the ill state of our stdlib. Yes, boring.
    However we must be aware of these things.
    rantingrick, Feb 1, 2011
    #19
  20. On Tue, 2011-02-01 at 04:38 -0800, rantingrick wrote:
    > On Feb 1, 4:20 am, flebber <> wrote:
    > > Sorry Rick too boring....trying to get bored people to bite at your
    > > ultra lame post yawn...........

    > Well reality and truth both has a tendency to be boring.


    Even more true of pointless and drawn-out pontificating.

    If you despise IDLE so much - use one of the many other IDE's that
    support Python; move on.
    Adam Tauno Williams, Feb 1, 2011
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Nick Harris

    Re: Obfuscation and Salamander

    Nick Harris, Apr 27, 2004, in forum: ASP .Net
    Replies:
    0
    Views:
    422
    Nick Harris
    Apr 27, 2004
  2. Richard Grimes [MVP]

    Re: Obfuscation and Salamander

    Richard Grimes [MVP], Apr 30, 2004, in forum: ASP .Net
    Replies:
    0
    Views:
    554
    Richard Grimes [MVP]
    Apr 30, 2004
  3. Pritam Kamat

    Obfuscation and sub classing

    Pritam Kamat, Aug 8, 2003, in forum: Java
    Replies:
    2
    Views:
    513
    pete kirkham
    Aug 8, 2003
  4. Replies:
    2
    Views:
    502
    Chris Smith
    Dec 7, 2004
  5. Danno
    Replies:
    11
    Views:
    172
Loading...

Share This Page