python ides

[kevin]

Since i saw a post about a troll saying python doesnt have good ides(not
true) , i would like to say that python has the best ide ever! and i
challenge emacs,vim users who dont believe in the power of an ide , take a
look :

wingide 2 :

-------------

python with full callback tip,autocompletion support, look at the right down
position of the screenshoot,where it shows the type of the attribute,its
arguments if any,and the doc string, so memorize those details is not
needed any more.


http://www.zippyimages.com/files/111424/codecompletion_calltips_sourceassistant.
png


if the ide doesnt know what type is the object(cause of dinamic typing),you
can still use code assist, for example :

def myfunction(unknowntype):

unknowntype. ????

and you know that unknowntype is a Cookie instance, then type ' Cookie. '
and you will get the assistance

---------------------------

complete code-object browser


http://www.zippyimages.com/files/111426/code_browser_source_browser.png


----------------------------
and finaly ,a super complete debuger , with support for plone/zope ,
wxwindows and a lot of advanced options.


http://www.zippyimages.com/files/111427/most_powerfull_debugger_ever.png


----------------------------

With the power of python and the power of this great ide, programing is
even more fun and productive.

Ha, java,visual studiors wish to have this powerfull ide and programing
language avaiable for .not or eclipse tecnologies

I think emacs-vim users will change their mind after trying it , well the
problem is that it is a bit expensive =( , at least the personal edition is
accesible , toughs?

just try it, =)

http://wingware.com/downloads

 

[Bruno Desthuilliers]

Since i saw a post about a troll saying python doesnt have good ides(not
true) , i would like to say that python has the best ide ever! and i
challenge emacs,vim users who dont believe in the power of an ide ,

They do ! That's why they use one of the two best IDEs around...

 

[Chris S.]

just try it, =)

http://wingware.com/downloads

Aside from being proprietary, how is WingIDE different from SPE
(spe.pycs.net)?

> full callback tip

SPE's got that.

> autocompletion support

SPE's got that.

> if the ide doesnt know what type is the object(cause of dinamic typing),you
> can still use code assist, for example :
>
> def myfunction(unknowntype):
>
> unknowntype. ????
>
> and you know that unknowntype is a Cookie instance, then type ' Cookie. '
> and you will get the assistance
What?

> complete code-object browser

SPE's got that.

> and finaly ,a super complete debuger , with support for plone/zope ,
> wxwindows and a lot of advanced options.

I'll give you this one, this I don't think SPE has a traditional
"debugger". Although to be fair, I've never needed one for Python.

SPE also integrates with WxGlade and Blender for Gui design and 3D design.

 

[Jonathan Ellis]

Aside from being proprietary, how is WingIDE different from SPE
(spe.pycs.net)?


SPE's got that.
SPE's got that.
SPE's got that.

Well, Wing is butt-ugly...

Oh, SPE's got that too.

-Jonathan

 

[Alex Martelli]

Aside from being proprietary, how is WingIDE different from SPE
(spe.pycs.net)?

I'm not a big IDE user, but I've seen WingIDE's debugger in the hand of
an IDE-wizard, and it _is_ incredible.

I'll give you this one, this I don't think SPE has a traditional
"debugger". Although to be fair, I've never needed one for Python.

I don't need one often, but sometimes one DOES run into something
sufficiently weird -- and when it happens it can take days to sort it
out. Case in point: rewriting the web layer for a client's multi-tier
application framework, to use twisted and nevow instead of Webware, we
were occasionally getting the weirdest 'recursion limit exceeded'
tracebacks -- and if you've ever tried to divine what's going on from a
Twisted traceback with a few dozen deferreds in play, some intercepting
errors and some not, etc, etc, you know that isn't comfortable.

Two of us trashed around for 2-3 days trying all the usual things.
Finally one of the GUI specialists in another subteam of the same
framework development team offered to help us with WingIDE. He's the
one who does custom layout widgets, weird super-nested-lists-and-
trees-widgets, etc etc, for the cross-platform GUI-clients of that
framework, on top of Qt/PyQt etc, and claims that without that debugger
he could never solve the weird and delicate issues that continually
arise in his work.

Be that as it may, in 2-3 hours we were on top of the problem: there is
an intrinsic, undocumented limit to how many items you can feed to a
newvow:sequence renderer, if those items are deferreds, because they all
get chained into a linked list whose __del__, at the end, proceeds _by
recursion_. So, if you have too many items in the sequence, it's
recursion-limit-exceeded time, and the dance of bouncing exception
handlers starts playing (in a too-deep-nesting situation, too). Once
the problem was identified the solution was trivial (as it generally
is): there was really no justification for showing a thousand 'hits' of
some search as one humungous table in a single webpage anyway... we
simply hadn't bothered yet with implementing the code to slice the hits
into multiple pages and let the user page back and forth in the browser.
So we did, ensuring no single sequence of hundreds of deferreds could
ever be rendered in one gulp, and the problem disappeared.

But, that debugger really DID save our bacon on that occasion. I'm not
sure how it managed to get control at the right time within that thicket
of exception handlers and let us examine hundreds of nested stack frames
looking for the underlying cause (I know the cause sounds trivially
obvious in retrospect, but THAT, too, is par for the course... one of
the hardest bugs to find in my career, back in Fortran days, boiled down
in the end to an .LT. being used where an .LE. should have been... a
*one*-*character* fix after days of fighting to find the right place out
of over a million lines of code in the system...!-). But manage it did.
Next time we spend more than 2-3 hours chasing some bug that just won't
show up, I'm going to go and ask that WingIDE expert user for some
little help!-)


Alex

 

[Cameron Laird]

.
.
.

I don't need one often, but sometimes one DOES run into something
sufficiently weird -- and when it happens it can take days to sort it
out. Case in point: rewriting the web layer for a client's multi-tier
application framework, to use twisted and nevow instead of Webware, we
were occasionally getting the weirdest 'recursion limit exceeded'
tracebacks -- and if you've ever tried to divine what's going on from a
Twisted traceback with a few dozen deferreds in play, some intercepting
errors and some not, etc, etc, you know that isn't comfortable.

Two of us trashed around for 2-3 days trying all the usual things.
Finally one of the GUI specialists in another subteam of the same
framework development team offered to help us with WingIDE. He's the
one who does custom layout widgets, weird super-nested-lists-and-
trees-widgets, etc etc, for the cross-platform GUI-clients of that
framework, on top of Qt/PyQt etc, and claims that without that debugger
he could never solve the weird and delicate issues that continually
arise in his work.

Be that as it may, in 2-3 hours we were on top of the problem: there is
an intrinsic, undocumented limit to how many items you can feed to a
newvow:sequence renderer, if those items are deferreds, because they all
get chained into a linked list whose __del__, at the end, proceeds _by
recursion_. So, if you have too many items in the sequence, it's
recursion-limit-exceeded time, and the dance of bouncing exception
handlers starts playing (in a too-deep-nesting situation, too). Once
the problem was identified the solution was trivial (as it generally
is): there was really no justification for showing a thousand 'hits' of
some search as one humungous table in a single webpage anyway... we
simply hadn't bothered yet with implementing the code to slice the hits
into multiple pages and let the user page back and forth in the browser.
So we did, ensuring no single sequence of hundreds of deferreds could
ever be rendered in one gulp, and the problem disappeared.

But, that debugger really DID save our bacon on that occasion. I'm not
sure how it managed to get control at the right time within that thicket
of exception handlers and let us examine hundreds of nested stack frames
looking for the underlying cause (I know the cause sounds trivially
obvious in retrospect, but THAT, too, is par for the course... one of
the hardest bugs to find in my career, back in Fortran days, boiled down
in the end to an .LT. being used where an .LE. should have been... a
*one*-*character* fix after days of fighting to find the right place out
of over a million lines of code in the system...!-). But manage it did.
Next time we spend more than 2-3 hours chasing some bug that just won't
show up, I'm going to go and ask that WingIDE expert user for some
little help!-)

.
.
.
I have an intense interest in this narrative, and little
ability yet to articulate why.

Excellent developers, among other things, diagnose accurately
and quickly; slightly less (I claim) differentiating is their
creativity at remedies.

I have a large, large theory that I summarize as, "Cut your
losses". The local application is that one big win for
engineering productivity in software development is avoidance
or management of those it-took-*months*-to-track-down-this-
simple-problem situations. I've sure lived through them; in
fact, I'm dealing with three different ones that I know right
now.

They are humbling, indeed.

I've lived through quite a few, as I just wrote. I do *not*
particularly associate their resolution, in my memories of
first-hand experience, with debuggers. Among other things,
this makes me wonder if I'm missing out on the capabilities
of debuggers.

I don't know what the answers are. In this area, I'm still
wrestling with what questions to ask. This stuff *fascinates*
me, though, in utter contrast to what I consider the utter
irrelevancies of which editor to use, which ...

 

[Alex Martelli]

Excellent developers, among other things, diagnose accurately
and quickly; slightly less (I claim) differentiating is their
creativity at remedies.

Yeah, debugging skill #1 is diagnosis -- fixes are easier, more often
than not. Not too sure about the "excellent developer" generalization
in this context, tho. The skills of, say: finding bugs; architecting
complex systems effectively; mastering some technologies (languages,
libraries, operating systems, protocols, existing algorithms in some
field, ...) thoroughly and effectively; designing pleasantly usable
languages, mini-languages, file formats, library interfaces, user
interfaces; inventing good new algorithms; etc, etc... ARE all
correlated to SOME extent, sure, but no more so, I think, than some of
them correlate with other skills not directly connected to the practice
of software development (crossword puzzles, ikebana, cooking...).

I have a large, large theory that I summarize as, "Cut your
losses". The local application is that one big win for
engineering productivity in software development is avoidance
or management of those it-took-*months*-to-track-down-this-
simple-problem situations. I've sure lived through them; in
fact, I'm dealing with three different ones that I know right
now.

They are humbling, indeed.

Yeah, and avoiding or wisely managing them would be wonderful, but isn't
necessarily easy. "KISS" is always helpful, of course: the more
helpings multitasking (of whatever kind, but "free-threading" issues are
the deucedest ones in my experience), distributed programming (...runs
away screaming...), even humble (ha!) event-driven programming, there
are in your system, the likelier that bugs will emerge that are very
hard to identify. But we can't always be writing nicely simple
sequential programs -- we DO need to work with networks, GUIs, ...:-(

Abstraction cuts both ways -- great while it works, but sometimes bug
emerge that become horridly difficult to connect across huge gaps of
abstraction. Eric Raymond has some wise comments about that (and
pointers to more such material) in his great book "Art of Unix
Programming". Same for avoiding boilerplate coding and copy-and-paste
reuse -- such avoidance is an important bug-avoidance practice, BUT if
to pursue it you end up with highly generalized, parameterized, and
likely complicated procedures (or, worse, deep hierarchies of classes,
eek!) you may easily risk losing more than you gained. Unit testing,
generous use of assertions, pair programming, and, to a far lesser
extent, "linting" and code inspections, all help a bit... but the race
condition, weird interaction of complicated frameworks, etc, will always
hit in the one spot which unit tests didn't exercise, that you didn't
think to assert anything about, and that looked just as good to your
programming partner, your linter, and all code inspectors...!-)

I've lived through quite a few, as I just wrote. I do *not*
particularly associate their resolution, in my memories of
first-hand experience, with debuggers. Among other things,
this makes me wonder if I'm missing out on the capabilities
of debuggers.

This is a reflection I had as a consequence of this episode. But if I
meet about two "super-horrible bugs" a year, and a perfect debugger
would save me 3 days or so in each case, I need to find one that I can
learn to use with perfect skill in less than 6 days, and keep
well-trained on at no cost. Half the incantations that WingIDE guru was
incanting were completely lost on me and the other guy helping us out in
that debugging -- if I took a week to learn it, and then didn't have any
need for it for months, I'd have to relearn it again 7 months later...
not a net win.

I was highly skilled back when I had to use MS Visual Studio to develop
and debug C++ code -- but it's the kind of skill my brain expunges as
fast as it possibly can, as soon as it becomes unused (as opposed to,
say, weird interesting facts about languages and libraries I may not
have used for years -- THOSE, for me, tend to stay around somewhere in
my brain!-)

I don't know what the answers are. In this area, I'm still
wrestling with what questions to ask. This stuff *fascinates*
me, though, in utter contrast to what I consider the utter
irrelevancies of which editor to use, which ...

Of course -- the answer is so obvious (vim, what else?!) than debating
it _is_ utterly irrelevant...!-)


Alex

 

[David Bolen]

I'm not a big IDE user, but I've seen WingIDE's debugger in the hand of
an IDE-wizard, and it _is_ incredible.

It also has the attractive mechanism by which you can include
debugging support in any application and then debug it remotely in
whatever environment it is running - e.g., if you're stuck with code
that isn't TDD or testable outside of its operational environment,
just import the debugger stub, configure it to point back to your
development machine and leave the IDE in listen mode. Once the code
hits that point (whether it's running deep inside a web server, or any
other application) you'll get control right at that point on your
development machine. Darn nice.

WingIDE 2.0's (still in beta) new GUI is also much more attractive
looking (on Windows at least), and its approach to dynamic source
analysis (in lieu of call tips, although they still have completion)
is quite impressive.

-- David

 

[Cameron Laird]

.
[much that deserves comment]
.
.

This is a reflection I had as a consequence of this episode. But if I
meet about two "super-horrible bugs" a year, and a perfect debugger
would save me 3 days or so in each case, I need to find one that I can
learn to use with perfect skill in less than 6 days, and keep
well-trained on at no cost. Half the incantations that WingIDE guru was
incanting were completely lost on me and the other guy helping us out in
that debugging -- if I took a week to learn it, and then didn't have any
need for it for months, I'd have to relearn it again 7 months later...
not a net win.

I was highly skilled back when I had to use MS Visual Studio to develop
and debug C++ code -- but it's the kind of skill my brain expunges as
fast as it possibly can, as soon as it becomes unused (as opposed to,
say, weird interesting facts about languages and libraries I may not
have used for years -- THOSE, for me, tend to stay around somewhere in
my brain!-)

.
.
.
I made almost exactly the same calculation, and certainly
came to the same conclusion.

This still leaves open the question of precisely what the
alternative is--to have eager debugger-savvy friends? I
think there's more to it. I'll likely return to this.

 

[Alex Martelli]

It also has the attractive mechanism by which you can include
debugging support in any application and then debug it remotely in
whatever environment it is running - e.g., if you're stuck with code

Yeah, I think that was part of what the IDE-wizard was doing, as:

hits that point (whether it's running deep inside a web server, or any

....we WERE "deep inside a web server" (one coded with Twisted)...


Alex

 

[David Bolen]

...we WERE "deep inside a web server" (one coded with Twisted)...

Ah, I sort of assumed (since you mentioned Twisted) that it was a
server you could start up from scratch completely under Wing's control
and then take it to the point of failure just letting Wing's normal
exception catching mechanism work - thus, just starting it from the IDE.

The exception trapping support of Wing, BTW, as you also mentioned, is
definitely impressive since it's the only one I've seen that can cross
the Python->C Extension-Python boundary and still trap an exception.
Works great with exceptions in wxPython applications since those all
occur on the other "side" of the wxPython extension, and aren't
generally caught by other debuggers i've tried. Of course, this does
occasionally catch "normal" exceptions suppressed by such extensions
that you then need to ignore, but Wing makes that simple too.

The environments I was originally envisioning were those where you
really couldn't manually start the application directly from Wing. So
in the web case, something like Apache using mod_python, or perhaps
when trying to debug a COM server that is initiated as an in-proc
server from a C++ application.

But of course that mechanism is just as useful even if you could start
your own application, since it lets you minimize the debugging
overhead until you actually reach the right point (which might be
after some unknown amount of runtime).

-- David

 

[Alex Martelli]

Ah, I sort of assumed (since you mentioned Twisted) that it was a
server you could start up from scratch completely under Wing's control
and then take it to the point of failure just letting Wing's normal
exception catching mechanism work - thus, just starting it from the IDE.

Sigh, not quite, the startup isn't all plain sailing.

The exception trapping support of Wing, BTW, as you also mentioned, is
definitely impressive since it's the only one I've seen that can cross
the Python->C Extension-Python boundary and still trap an exception.
Works great with exceptions in wxPython applications since those all
occur on the other "side" of the wxPython extension, and aren't
generally caught by other debuggers i've tried. Of course, this does
occasionally catch "normal" exceptions suppressed by such extensions
that you then need to ignore, but Wing makes that simple too.

I assume (without knowing in depth) that's part of what makes it so
indispensable to the guy who's coding deep and complicated stuff in
PyQt: there's plenty of C++ code there, just as in wx{Widgets,Python}.

The environments I was originally envisioning were those where you
really couldn't manually start the application directly from Wing. So
in the web case, something like Apache using mod_python, or perhaps
when trying to debug a COM server that is initiated as an in-proc
server from a C++ application.

Yeah, there's a lot of that going around -- Python embedded in other
apps or other cases where the Python part you're interested in must be
started under another app's control (you might simulate the startup some
of the time, but it can be bothersome or even nigh-impossible).

But of course that mechanism is just as useful even if you could start
your own application, since it lets you minimize the debugging
overhead until you actually reach the right point (which might be
after some unknown amount of runtime).

That's possible, too, though a debugger who's _only_ gonna catch
exceptions might not have all that much overhead until an exception does
happen.


Alex

 

[Carlos Ribeiro]

This still leaves open the question of precisely what the
alternative is--to have eager debugger-savvy friends? I
think there's more to it. I'll likely return to this.

I think that the problem with debuggers is the same as with
optimization -- it's too easy to start doing it prematurely. At the
first sign of a problem, you fire up the debugger, and if you're not
careful, you'll start to think more about the effects than about the
causes. With a debugger, it's easy to see where does the bug manifest
itself, but it's still hard to understand the exact source of the
problem, if it's located far way from that point. Advanced debuggers
support limited forms of backtracking (mostly through special hardware
support or through virtualization), but for complex pieces of
software, I'm yet to see something like this that really works.

But there's a reason why debuggers are useful: there is a limit on how
many things we can keep track of inside our heads. For some people it
may be larger than average, but still there's a limit; and if you're
working with anything that's not strictly sequential, then it quickly
becomes unmanageable, even for the best programmer. That's where
debuggers are more useful. But in this case, mastering a debugger
turns out to be difficult, because it's not just a matter of walking
on the code step by step anymore; it's about installing probes to
check for interesting stuff at runtime, without causing any
undesirable side effect. It's more of a information management problem
than a programming problem, at this point -- to be able to install the
minimum number of probles in a way that we can still keep track of
what is going on realtime, and catch the problem at its origin.

--
Carlos Ribeiro
Consultoria em Projetos
blog: http://rascunhosrotos.blogspot.com
blog: http://pythonnotes.blogspot.com
mail: (e-mail address removed)
mail: (e-mail address removed)

 

[David Bolen]

(e-mail address removed) (Alex Martelli) writes:

(...)

That's possible, too, though a debugger who's _only_ gonna catch
exceptions might not have all that much overhead until an exception does
happen.

It's not quite that good, but still somewhat flexible. By importing
the stub module in your application, you're enabling it for debugging
from that point onwards. If the Wing IDE is running at that point
it'll immediately connect and then run under control of the debugger.
It won't stop the application, just keep running at the point onwards.
If the IDE isn't available, then the application will listen for
subsequent attach requests from Wing at which point the debugging
control will begin.

But, like most Python debuggers, the actual debugging is handled by
the trace hooks, so once actually attached to the IDE, you will pay
some penalty (not sure how much), even if you only care about
exceptions. Then again, a side benefit is that once attached you can
forceably interrupt the application at any moment.

So depending on that load, there can be an advantage to importing the
stub as late as possible (or as close to the debug point as possible)
and then just leaving the IDE running to service the connection at
that point. The other advantage the controlled import gives you is
that with most current Python releases debugging multiple threads
doesn't work well (I think it was 2.4 that improved hooks for this),
so you can control which thread imports the stub and that becomes the
thread being debugged.

All in all, pretty impressive. Ironically though, while this was the
key differentiator (well, that plus the source analysis - it was the
best IDE when I was looking at parsing the wxPython package for code
completion) I saw to the package, our use of TDD in our recent coding
has really ended up rarely needing much in the way of a debugger yet,
but it's nice to know what to buy when I need it. (And 2.0 hits a
number of the visual issues I had, with a development team
predominently on Windows currently, so I'm enthusiastically following
the current beta).

-- David

 

[Cameron Laird]

On Wed, Sep 22, 2004 at 02:25:45PM -0400, Jeremy Jones wrote:
.
.
.

I hope that my following comments don't sound presumptuous or
antagonistic. This topic really interests me and I'd like to raise a
couple of questions about the above discussion for my own sake. Let me
assert up front that I am _far_ from a debugger guru. I'm just
starting to tinker around with it lately. My previous debugging
techniques centered around a bunch of "print" statements or log entries,
etc - but, I must say, they were fairly effective.

Is it possible that this is a case of "what you don't know, you don't
know that you don't know"? Meaning, if you aren't (in this case) a
debugger guru, you don't know how much (more) you would use the debugger
for non-catastrophic bugs and how much more productive it would make you
(again, for non-catastrophic bugs, or things that aren't even bugs)?
All of programming isn't debugging, so becoming a master of the debugger
to the detriment of some other aspect of programming (which Alex could
fill in here with much more finesse than I could) is, in my opinion, a
mistake. But I just wonder how much I'm missing by not being as
proficient with the debugger. I guess the same could be said regarding
other tools - maybe even <duck> IDEs <run>.

Another question that I'd like to raise is, does a one week investment
in time necessarily add up to one week in time? Meaning, if you
determine that you would like to become more adept at the debugger and
decide that you're going to spend your spare moments with it when things
are slow and there is little/nothing to do anyway, do you really have
anything invested in it compared to your productive activities?
Especially if the spare moments (which would have been spent surfing
Slashdot) result in an improvement of productivity immediately. I'm not
asserting that this is the case - just raising the question.

Anyway, hope I don't sound like a butt on this. Both of my questions
are, interestingly, non-quantifiable. I guess I can empathize with
Cameron's statement:

I have an intense interest in this narrative, and little
ability yet to articulate why.

I dunno. Maybe it's because I just started fumbling around with pdb and
this topic just struck a chord within me. Maybe it's because I've got a
personality flaw where I'm willing to "waste" spare time on learning
things that I feel _may_ (not _will_ - _may_) help me think in different
ways. Currently, I'm on a kick of wanting to "get" functional
programming. I don't know why, but I just feel like when I "get" it,
it'll help me think about other things in different and better ways.
Maybe that's just Eric S. Raymond's comments on Lisp floating around in
my head - or maybe David Mertz's articles on functional programming.

Jeremy Jones

My newsfeed appears erratic; delays in my replies are not editorial comments.

Mr. Jones, I'm unoffended. I once *was* a debugger guru (expert in several
debuggers, in fact); those are skills I've chosen to let lapse. Nowadays, I
feel more benefit in thinking about, for example, monads and categories.

I don't know what else to say. I am ever on the lookout for advantages a
clever debugger will give me. It's simply been years since I've noticed any.

 

[Alex Martelli]

feel more benefit in thinking about, for example, monads and categories.

Do you mean Leibnitz's (which I think I understand, but don't find very
applicable to my daily work) or Haskell's? If the latter, WOW, I
finally may have a chance to GRASP them... I will freely admit that, so
far, they're the one part of that fascinating language to have escaped
my feeble mental powers. I can use monads I'm given, mostly, but how
would I write my own, when would it be appropriate to do so, etc, IS
still quite mysterious to me...


Alex

 

[Ian J Cottee]

I think emacs-vim users will change their mind after trying it , well the
problem is that it is a bit expensive =( , at least the personal edition is
accesible , toughs?

Well this emacs user spent some time trying it (testing the version 2
beta). It is nice but it's no emacs unfortunately.

Ian

 

[Ian J Cottee]

I think emacs-vim users will change their mind after trying it , well the
problem is that it is a bit expensive =( , at least the personal edition is
accesible , toughs?

Well this emacs user spent some time trying it (testing the version 2
beta). It is nice but it's no emacs unfortunately.

Ian

 

[Ville Vainio]

Ian> Well this emacs user spent some time trying it (testing the
Ian> version 2 beta). It is nice but it's no emacs unfortunately.

A slight point of netiquette - please don't hesitate to quote the name
of the thing referred to by "it", or write it out yourself if that's
not possible .

Apart from that, I'd like to point out that pydev (Python plugin for
eclipse) seems to be alive and well (i.e. they seem to be implementing
new features) with the recent 0.6 version:

http://pydev.sourceforge.net/

Eclipse is where I think I'm going in my attempt to wean myself off
emacs.

 

[Ian J Cottee]

Ian> Well this emacs user spent some time trying it (testing the
Ian> version 2 beta). It is nice but it's no emacs unfortunately.

A slight point of netiquette - please don't hesitate to quote the name
of the thing referred to by "it", or write it out yourself if that's
not possible .

Apologies - I was somewhat over enthusiastic in my previous post
trimmings . I see so many posts that quote reams of pointless previous
text that I often seem to go too far in the other direction.

Apart from that, I'd like to point out that pydev (Python plugin for
eclipse) seems to be alive and well (i.e. they seem to be implementing
new features) with the recent 0.6 version:

http://pydev.sourceforge.net/

Eclipse is where I think I'm going in my attempt to wean myself off
emacs.

Yes, I played with pydev. One is almost tempted to learn Java in order
to contribute. But I still can't believe that I will live to see the day
that Emacs is surpassed ;-).

Ian