Skip to main content

Wing IDE 3, Wing IDE 101 released

Wing IDE version 3 has been released.

The list of new features is a little underwhelming. Multi-threaded debugging and the unit testing tool (only supporting unittest -- does anyone still use that old module anymore?) are nice but I don't see myself paying to upgrade from 2.1 yet. Now if they could get the GUI to keep up with my typing in Windows, I'd pay for that... I guess this is a sign that Python IDEs are nearing maturity; Komodo 4 didn't have any earth-shaking new features either, at least as far as Python was concerned.

(Personally I think someone should start supporting django/genshi/mako templates already. Maybe in 3.1, guys?)

Following ActiveState's lead, Wingware has also released a completely free version, Wing IDE 101. The main difference is that where the most essential feature Komodo Edit leaves out as an incentive to upgrade is debugging, Wing IDE 101 includes the debugger but omits code completion. Wingware also continues to offer the low-cost Personal edition.

But the really big difference between Wing IDE 101 and Komodo Edit is that you can freely use Komodo Edit for paying work. Wing IDE 101, like Wing IDE Personal has a no-commercial-use clause. (Komodo versions compared; Wing versions compared.) I'm still of the opinion that at $180, Wing Professional will pay for itself in short order, but for the hobbyist, Komodo Edit is very compelling. I've been using it myself for TCL and XML editing for several months now and it's a nice little IDE.

Too bad Komodo's emacs bindings continue to suck balls -- I mean, it's one thing to not implement fancy things like a minibuffer or kill ring, but if you can't even get C-W (cut) right, there's not much hope. Users contributed much-improved Emacs bindings to the ActiveState bug tracker way back in the version 3 timeframe. I guess ActiveState just doesn't care.

Comments

Doug Napoleone said…
Don't forget about the probe debugger.

This is a python interactive session which dynamically switches context. Select the stack level in the debugger, and you can do anything in the session as if you were at that point in the code. Not exactly what I would call underwhelming.

Stephen gave out the reason for the slowness during a talk (audio).

Now if komodo would just stop locking up in the svn integration for no good reason, and failing to 'repaint' when you have many large files open.
Jonathan Ellis said…
Since my toughest bugs have been impossible to reproduce in a debugger context, I just tend to be underwhelmed by debuggers in general. :)
Jonathan Ellis said…
I found the audio in your link to be mostly unintelligible. So, do tell, what was the reason?
Doug Napoleone said…
sorry about that. There is no difference in implementation of wing between windows, linux and mac osx. The issue appears to be latency in the main even loop in GTK. The Wing folks are active in the GTK community and are hoping to find the root problem, but it has been a long standing issue. This is second hand and partially paraphrased, so my apologies if I got anything wrong.
Doug Napoleone said…
NOTE: the #1 reason I use an IDE is for the graphical debugging. If I don't have a need for a debugger, I just use emacs or vi equivalent as they have everything else, and are on all systems (even windows these days). Though I agree the toughest bugs can never be reproduced in a debugger. If they could, they wouldn't be that tough.
Unknown said…
FWIW: Slowness on Windows sometimes seems like a result of a breakdown of using hardware acceleration for display, which we've seen with nVidia cards, and in particular with the nVidia display manager. That's usually a pretty severe slowdown, however, and may not be what you're seeing. But turning off any such display managers for Wing is worth a try.

Another thing to try is to change away from the default Display Theme to something w/o any pixmap eye candy.

Somewhat ironic, really, that our performance issues aren't in Python code. ;-)

Also, sometimes using a conditional breakpoint is a good way to get the Debug Probe to point at the particular case that's failing. At times, I've set one to catch a rare case I couldn't figure out, and suddenly days later hit it. Of course there's no guarantee we can bring out all your threading bugs, or anything where timing and luck play a role. ;-)

Thanks, in any case for writing about Wing and your impressions of the new release.
Brandon Corfman said…
Regarding Komodo 4.2 improvements, the Python autocomplete took a big leap forward, although it's not completely perfect yet (grrr). I think ActiveState's resources get burned up supporting too many different languages under the one IDE.

However, Komodo now supports Firefox-style extensions in 4.x. So there are new Python extensions like kNose, which does unit testing with the nose library. (Shameless plug alert.)

Popular posts from this blog

Why schema definition belongs in the database

Earlier, I wrote about how ORM developers shouldn't try to re-invent SQL . It doesn't need to be done, and you're not likely to end up with an actual improvement. SQL may be designed by committee, but it's also been refined from thousands if not millions of man-years of database experience. The same applies to DDL. (Data Definition Langage -- the part of the SQL standard that deals with CREATE and ALTER.) Unfortunately, a number of Python ORMs are trying to replace DDL with a homegrown Python API. This is a Bad Thing. There are at least four reasons why: Standards compliance Completeness Maintainability Beauty Standards compliance SQL DDL is a standard. That means if you want something more sophisticated than Emacs, you can choose any of half a dozen modeling tools like ERwin or ER/Studio to generate and edit your DDL. The Python data definition APIs, by contrast, aren't even compatibile with other Python tools. You can't take a table definition

Python at Mozy.com

At my day job, I write code for a company called Berkeley Data Systems. (They found me through this blog, actually. It's been a good place to work.) Our first product is free online backup at mozy.com . Our second beta release was yesterday; the obvious problems have been fixed, so I feel reasonably good about blogging about it. Our back end, which is the most algorithmically complex part -- as opposed to fighting-Microsoft-APIs complex, as we have to in our desktop client -- is 90% in python with one C extension for speed. We (well, they, since I wasn't at the company at that point) initially chose Python for speed of development, and it's definitely fulfilled that expectation. (It's also lived up to its reputation for readability, in that the Python code has had 3 different developers -- in serial -- with very quick ramp-ups in each case. Python's succinctness and and one-obvious-way-to-do-it philosophy played a big part in this.) If you try it out, pleas

A review of 6 Python IDEs

(March 2006: you may also be interested the updated review I did for PyCon -- http://spyced.blogspot.com/2006/02/pycon-python-ide-review.html .) For September's meeting, the Utah Python User Group hosted an IDE shootout. 5 presenters reviewed 6 IDEs: PyDev 0.9.8.1 Eric3 3.7.1 Boa Constructor 0.4.4 BlackAdder 1.1 Komodo 3.1 Wing IDE 2.0.3 (The windows version was tested for all but Eric3, which was tested on Linux. Eric3 is based on Qt, which basically means you can't run it on Windows unless you've shelled out $$$ for a commerical Qt license, since there is no GPL version of Qt for Windows. Yes, there's Qt Free , but that's not exactly production-ready software.) Perhaps the most notable IDEs not included are SPE and DrPython. Alas, nobody had time to review these, but if you're looking for a free IDE perhaps you should include these in your search, because PyDev was the only one of the 3 free ones that we'd consider using. And if you aren