Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #55537 > unrolled thread

Re: IDLE: A cornicopia of mediocrity and obfuscation.

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: IDLE: A cornicopia of mediocrity and obfuscation. rantingrick <rantingrick@gmail.com> - 2011-01-31 09:49 -0800
    Re: IDLE: A cornicopia of mediocrity and obfuscation. rantingrick <rantingrick@gmail.com> - 2011-01-31 21:37 -0800
    Re: IDLE: A cornicopia of mediocrity and obfuscation. rantingrick <rantingrick@gmail.com> - 2011-01-31 10:12 -0800
      Re: IDLE: A cornicopia of mediocrity and obfuscation. Giampaolo Rodolà <g.rodola@gmail.com> - 2011-01-31 20:32 +0100
        Re: IDLE: A cornicopia of mediocrity and obfuscation. rantingrick <rantingrick@gmail.com> - 2011-01-31 12:19 -0800
      Re: IDLE: A cornicopia of mediocrity and obfuscation. Stephen Hansen <me+list/python@ixokai.io> - 2011-01-31 16:14 -0800

#55537 — Re: IDLE: A cornicopia of mediocrity and obfuscation.

On Jan 31, 11:39 am, rantingrick <rantingr...@gmail.com> 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.

[toc] | [next] | [standalone]

#55568

On Jan 31, 9:24 pm, Giampaolo Rodolà <g.rod...@gmail.com> 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.

[toc] | [prev] | [next] | [standalone]

#55805

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!

[toc] | [prev] | [next] | [standalone]

#55813

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

[toc] | [prev] | [next] | [standalone]

#56067

On Jan 31, 1:32 pm, Giampaolo Rodolà <g.rod...@gmail.com> 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?

[toc] | [prev] | [next] | [standalone]

#55858

[Multipart message — attachments visible in raw view] — view raw

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/

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web