IDLE: A cornicopia of mediocrity and obfuscation.

[rantingrick]

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]

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]

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!

 

[Littlefield, Tyler]

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.

 

[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/

 

[rantingrick]

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?

 

[Robert]

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.

 

[Kevin Walzer]

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

 

[Robert]

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

 

[Stephen Hansen]

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

 

[Giampaolo Rodolà]

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.

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/

 

[rantingrick]

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]

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]

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.

 

[Stephen Hansen]

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

 

[rusi]

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]

On Feb 1, 1:35 am, Raymond Hettinger <[email protected]> wrote:

snipped

O O wrong thread... sorry!

 

[flebber]

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

 

[rantingrick]

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.

 

[Adam Tauno Williams]

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.