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

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

IDLE: A cornicopia of mediocrity and obfuscation.

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

Contents

  IDLE: A cornicopia of mediocrity and obfuscation. rantingrick <rantingrick@gmail.com> - 2011-01-31 09:39 -0800
    Re: IDLE: A cornicopia of mediocrity and obfuscation. Kevin Walzer <kw@codebykevin.com> - 2011-02-01 11:06 -0500
    Re: IDLE: A cornicopia of mediocrity and obfuscation. rantingrick <rantingrick@gmail.com> - 2011-02-01 05:38 -0800
      Re: IDLE: A cornicopia of mediocrity and obfuscation. rantingrick <rantingrick@gmail.com> - 2011-02-01 07:14 -0800
      Re: IDLE: A cornicopia of mediocrity and obfuscation. Jean-Michel Pichavant <jeanmichel@sequans.com> - 2011-02-01 15:27 +0100
    Re: IDLE: A cornicopia of mediocrity and obfuscation. Robert <sigzero@gmail.com> - 2011-02-02 16:46 -0500
    Re: IDLE: A cornicopia of mediocrity and obfuscation. Grant Edwards <invalid@invalid.invalid> - 2011-02-02 22:51 +0000
    Re: IDLE: A cornicopia of mediocrity and obfuscation. John Nagle <nagle@animats.com> - 2011-02-01 11:35 -0800
    Re: IDLE: A cornicopia of mediocrity and obfuscation. Terry Reedy <tjreedy@udel.edu> - 2011-02-01 10:54 -0500
    Re: IDLE: A cornicopia of mediocrity and obfuscation. flebber <flebber.crue@gmail.com> - 2011-02-03 02:29 -0800
    Re: IDLE: A cornicopia of mediocrity and obfuscation. rantingrick <rantingrick@gmail.com> - 2011-02-01 04:38 -0800
    Re: IDLE: A cornicopia of mediocrity and obfuscation. "Littlefield, Tyler" <tyler@tysdomain.com> - 2011-01-31 11:13 -0700
    Re: IDLE: A cornicopia of mediocrity and obfuscation. Raymond Hettinger <python@rcn.com> - 2011-02-01 19:35 -0800
    Re: IDLE: A cornicopia of mediocrity and obfuscation. rantingrick <rantingrick@gmail.com> - 2011-01-31 21:13 -0800
    Re: IDLE: A cornicopia of mediocrity and obfuscation. flebber <flebber.crue@gmail.com> - 2011-02-01 02:20 -0800
    Re: IDLE: A cornicopia of mediocrity and obfuscation. Kevin Walzer <kw@codebykevin.com> - 2011-01-31 17:17 -0500

#55616 — IDLE: A cornicopia of mediocrity and obfuscation.

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!

[toc] | [next] | [standalone]

#55637

On 2/1/11 10:54 AM, Terry Reedy wrote:
> Maybe Kevin would help a bit.

Probably not--IDLE is good enough for my needs. I've submitted some 
(rather extensive) patches for things that annoyed me and got in my way, 
and they eventually made it in. (The classic open source 
pathway--scratching my own itch.) Beyond that, though, hacking on IDLE 
isn't a project I have time for.

--Kevin

-- 
Kevin Walzer
Code by Kevin
http://www.codebykevin.com

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

#55646

On Feb 1, 6:53 am, Adam Tauno Williams <awill...@whitemice.org> wrote:

> If you despise IDLE so much - use one of the many other IDE's that
> support Python;  move on.

Not exactly. Can we continue to ignore such lackluster and shabby code
in OUR stdlib. Remember the code reflects on all of us!

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

#55657

On Feb 1, 8:27 am, Jean-Michel Pichavant <jeanmic...@sequans.com>
wrote:

> In a more serious way, just count the people who second your
> prosposition. It's around 0. It is usually a good sign that you're
> wrong. This rule kinda applies to anyone, don't take it personnaly.

Well your statment completely ignores the silent majority. Are you
telling me that this sloth of trolls, minions, and flamers that have
so far replied are represetative of this fine community. Gawd i hope
NOT!. Here is a list of the compiled personalities...


#-- Embedded Trolls and Minions --#
Steven D'Aprano(smart and witty (annoying) troll)
Stephan Hansen (controversy troll)
Ben Finny (haughty troll)
alex23(angry/dangerous troll)
Tyler Littlefeild(confused troll)
Bryan ? (annoying troll)
Corey Richarson
Nicholas Devenish
Alexander Kapps
rusi ?
Andre ?
Geremy Condra (troll-wagoneer)
Ethan Furman
Noah Hall
Adam Skutt
Arndt Rodger Schnieder
Mark Roseman (Tkinter's minion)


#-- Occasonal Flamers --#
Micheal Torrie
Grant Edwards
MRAB
Thomas L Shinnink
Peter Otten
Giampaolo Rodola
Giacomo Boffi
malcom ?
Zeissmann
Mel
Owen Jacobson
Robert ?

#-- Complete Nobodys --#
Bill Felton
flebber

#-- MIA --#
GvR
Steve Holden

#-- Moderates --#
Richard Johnson
Terry Reedy
Kevin Walzer
Octavian Rasnita
Robert Kern
Brenden Simon
Tommy Grav
Martin V Leowis
Ian ?
Tim Chase
CM
Bob Martin
Neil Hodgenson
Robin Dunn
Benjamin Kaplan
Jerry Hill
Patty ?
Martin Gregorie
Albert van der Horst
Martin P Hellwig
jmfauth
Steven Howe
Antoine Pitrou
Hank Fay
Katie T
Gerry Reno
Stefen Behnel

26 moderates
31 trolls, minions, sockpuppets, and or flamers
2 missing in action
--------------------
= This community needs serious help!

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

#55938

rantingrick wrote:
> On Feb 1, 6:53 am, Adam Tauno Williams <awill...@whitemice.org> wrote:
>
>   
>> If you despise IDLE so much - use one of the many other IDE's that
>> support Python;  move on.
>>     
>
> Not exactly. Can we continue to ignore such lackluster and shabby code
> in OUR stdlib. Remember the code reflects on all of us!
>   
Can we continue to ignore such lackluster and shabby trolls in OUR 
mailing list ? Fortunately, the behavior of one does not reflect the 
behavior of us all.

In a more serious way, just count the people who second your 
prosposition. It's around 0. It is usually a good sign that you're 
wrong. This rule kinda applies to anyone, don't take it personnaly.

... or maybe you're just trolling, in which case you can thank me for 
feeding.

JM

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

#55818

On 2011-02-02 16:11:26 -0500, Terry Reedy said:

> On 2/1/2011 7:46 PM, Corey Richardson wrote:
>> On 02/01/2011 07:42 PM, Robert wrote:
>>> On 2011-02-01 10:54:26 -0500, Terry Reedy said:
> 
>>>> Perhaps, after the repository moves from svn to hg, some 'we' will.
> 
>>> If he does not, I think I might. Is there a timeline for the move?
> 
> Unclear. Many want immediately,
> 
>> I would help with such a project as well, given the opportunity.
> 
> You both might sign up to idle-sig list. Or 'subscribe' to
> gmane.comp.python.idle newsgroup mirror. Current traffic is 0.
> 
> And thank you both for chiming in. It is encouraging.

Well, I am about to sign up for the Steve Holden O'Reilly classes to 
learn Python and I know doing something in Tkinter is part of that. I 
also have the old Grayson book (just wish Pmw wasn't in there so much). 
So this would be a good follow on to the class to keep me learning 
Python at a steady pace.  :-)

-- 
Robert

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

#55832

On 2011-01-31, rantingrick <rantingrick@gmail.com> wrote:

> IDLE: A cornicopia of mediocrity and obfuscation.
> -- by Rick Johnson

RR's postings are generally tossed out by my score file, but after
seeing so many replies, my morbid curiousity finally got the best of
me, and I read (well, mostly) RR's posting on what's wrong with IDLE.

> -- rr: disappointed and annoyed!

Shocker.

We'll take it as read that I made some joke at this point involving
one of the definitions of "idle" as meaning running your motor and not
going anywhere...

-- 
Grant Edwards               grant.b.edwards        Yow! My uncle Murray
                                  at               conquered Egypt in 53 B.C.
                              gmail.com            And I can prove it too!!

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

#55842

On 1/31/2011 2:17 PM, Kevin Walzer wrote:

> It certainly would be interesting to see a fresh approach to IDLE...

     The future of "playing with Python" is probably Python in a browser
window, of which there are several implementations.  If you're doing
anything serious, you're using a programmer's editor or an IDE.
IDLE lives in a narrowing niche between those two points. Maybe
it should be killed off.

				John Nagle

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

#55874

On 2/1/2011 12:13 AM, rantingrick wrote:
> On Jan 31, 4:17 pm, Kevin Walzer<k...@codebykevin.com>  wrote:
>> Rick,

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

Perhaps, after the repository moves from svn to hg, some 'we' will. 
Maybe by then, you will have had your fun and be ready to work. Maybe 
Kevin would help a bit.

Such a project would be carried out on the tracker and idle-sig mailing 
list. Normal decorum would be required -- no ranting or insulting. The 
first thing to do, in my opinion, is to review existing patches on the 
tracker.

> Well some changes and improvements can be made to the UI as well.

There is patch on the tracker, by G. Polo, as I remember, to replace tk 
widgets with the newer themed ttk widgets. It needs to be reviewed and 
tested. To make a big change (or proceed with any refactoring) better 
automated testing would be very useful.

-- 
Terry Jan Reedy

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

#55960

On Feb 1, 11:38 pm, rantingrick <rantingr...@gmail.com> wrote:
> On Feb 1, 4:20 am, flebber <flebber.c...@gmail.com> 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.

Yes but fixing idle just gives us another editor, there isn't a
shortage of editors. There is a shortage of a common community code
base for an ide framework, logical, reusable and extensible.

For an example of a brilliant beginners "ide" racket has it covered
with DrRacket http://racket-lang.org/ , it has selectable language
levels beginner, intermediate, advanced that allows the learner to
adjust the level of language features available as they learn,
teachpacks are installable to add extra features or options when
completing the tutorials(could easily be adapted to the python
tutorials). If idle is for teaching people to learn python shouldn't
it have the facility to do that?

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

#56000

On Feb 1, 4:20 am, flebber <flebber.c...@gmail.com> 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.

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

#56035

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

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

#56037

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

That being said, I've taught a lot of people Python using IDLE.
It's a surprisingly productive environment and has a near-zero
learning curve.

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

Patches are welcome :-)

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

#56062

On Jan 31, 4:17 pm, Kevin Walzer <k...@codebykevin.com> 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.

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

#56103

On Feb 1, 4:39 am, rantingrick <rantingr...@gmail.com> 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...........

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

#56127

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

[toc] | [prev] | [standalone]

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

csiph-web