Wingware Python IDE Open Space at PyCon

Wingware is a silver sponsor for PyCon this year. If you are going, please come see us! We can help you get Wing IDE set up with your code base, answer questions, give demos, or talk about our experiences developing and selling an IDE for Python over the past ten years. Or just say "hello" and pick up some of our beautiful and functional Wingware gliders. We'll be at booth 117 in the Expo Hall Friday afternoon and Saturday most of the day or find us in our Open Space sessions.

Happy PyCon!

Come to PyCon 2009!

If you haven't already taken in a PyCon, you may not know what you have been missing.

Indeed you may not know that PyCon is less a conference than a week-long session of intensive technological play. It is a terrific way to meet the Python community in person, to make new connections, to find Python jobs, and to learn more than you're likely to learn at any other conference -- certainly not while you are having this much fun.

Yes, there will be scheduled talks and an expo hall full of vendors. But there will also be open space (self-organized sessions on topics of mutual interest), lightning talks (5-minute, often spontaneous, sometimes hilarious talks) and the "hallway track" (because hanging around is often the most interesting thing of all).

In addition, there will be two days of tutorials before the conference and four days of sprints -- intensive development days for people collaborating on Python or related open source projects -- after the conference.

PyCon 2009 is happening in Chicago, conveniently near the airport, on March 25 through April 2nd, with the main conference days on March 27-29. It is a low-cost conference designed to be affordable for all.

I hope you will come join the Python community in Chicago. As a regular attendee since 2000, I can assure you that you won't regret it!

Making code run on Python 2.0 through 3.0

I recently had to make a C extension module and associated Python code work with all Python versions from Python 2.0 through 3.0. Initially, I thought this was going to be very difficult but as it turned out I was able to get it working without too terribly much trouble. It took about a week to get 10K lines each of Python and C wrangled into this supports-all-versions state. Here is what I ran into:

For the extension modules

Most of the changes were due to disappearance of the PyString_* and PyInt_* calls. For the most part I was able to use macros to replace these with calls to PyUnicode_* and PyLong_* equivalents under Python 3.0.

I treated all C strings as UTF-8 encoding, since I had control of this from the outside of the module. This made it possible to use _PyUnicode_AsString as a replacement for PyString_AsString (via a utility call that contains #if PY_VERSION_HEX checks). That saved some time since Python caches and deallocates the utf-8 bytes object returned by this call. Before I found it, I had all sorts of convoluted code trying to deal with deallocation in code that under Python 2.x did not have to worry about this because the return value of PyString_AsString is just borrowed memory. However, using _PyUnicode_AsString does allocate memory where before none was allocated and it depends on the string being successfully converted to utf-8, so it (a) adds some memory overhead, and (b) adds a potential point of failure. I was lucky and was able to treat the failure as something I could just log and continue from. That may not be the case in other code.

Extensions modules are also initialized differently under Python 3.0, although that was easily taken care of with another #if PY_VERSION_HEX check.

For the Python code

Fortunately, this code used a logging implementation so had very few print statements. For those that remained and for other similar code that would now cause a syntax or other fatal error I wrote a module pyutils.py that would selectively import either py2utils.py or py3utils.py based on the value of sys.hexversion. That allowed me to place "bad" code in a place where the disagreeing Python versions would not see it. They contained utilities to replace things like:

• print, unicode(), callable(), xrange(), etc
• Use of removed modules like new or heavily pruned modules like types
• ''.join(x) where x is a string under Python 2.x and bytes under Python 3.x (so b''.join(x) is needed)

In addition to this, since much of this code was originally written against Python 1.5.2, I had to do away with old uses of the string module (string.join and so forth) but since I didn't have to support Python 1.5.2 as well, it was easy to do that with code that would work from Python 2.0 through 3.0.

Remarkably, that was about it! After all I'd heard about how hard it is to make the same code work with Python 2.x and 3.0, this certainly came as a pleasant surprise. In the end, I spent far more time trying to trace down an obscure threading deadlock issue that was accidentally caused by some of my replacement code than I worked on the actual compatibility changes.

Wing IDE 3.0.5 and 3.1beta3 released

Wingware has just released two new versions of its Python IDE:

Version 3.0.5 is a bug fix release that improves many aspects of the vi keyboard mode. It also fixes some problems with CPU loading, and various other relatively minor usability issues. Details are in the change log.

Version 3.1 beta3 is a more interesting release: It adds a How-To for using Wing with the Google App Engine, adds support for scanning for sys.path changes in the main debug file (including those used by buildout), makes the integrated Python Shell work better with threaded code, adds a preference for auto-stripping trailing white space on save, and makes lots of minor improvements to the other new functionality in version 3.1 (for details on those see the feature list on the beta testing page).

PyCon and the Python Community

Socially, I can be pretty dense. This made it possible for me to arrive at a startling revelation at PyCon this year, one that significantly changed my perception of the Python community, and my view of my place in it.

I've always loved going to PyCon and working with people in the community. But it wasn't until I heard David Goodger's opening remarks on Friday that it finally dawned on me how important Python is to many of its members as a community and circle of friends. Or for that matter, how important it is to me as well.

Here's the back story: In the early days of PyCon, in 2004, I heard that David couldn't come to the conference for lack of funds. He'ld been laid off. I sent an email to the docutils mailing list and within hours had enough pledges to pay for his travel and accommodations. One anonymous donor gave over $200.

That was more or less the last I thought of it until I heard David speak about it this year. What he said was that he was not just out of work but also depressed and this show of support from the community ended up meaning a lot to him. It was clear from talking about this with others afterwards that he's not alone in his perception of the community as very personal indeed.

Even if you're not the type to get teary eyed by such stories of unselfish giving from members of our far-flung community (and I admit I do), you can't argue with the sheer brilliance of this approach. As an investment in our collective future, this gesture turned out to pay off handsomely. As many of you may know, David has served as Director in the Python Software Foundation, where he has done a fantastic job as Secretary, and he has worked intensively this year as the PyCon Chairman.

So now I've figured it out, and I am all the more confident of the health and vigor of Python. The motivations run much deeper than I thought, as do the rewards.

This is also why I'm not much concerned about some of the criticisms of this year's PyCon. These things will be fixed next year, and we'll move on.

Every community has its problems. It's just a question of how (and whether) the community comes together to solve them. Like the small rural town where I live, one that strongly resists 21st century corporate intrusions into our 19th century village, I have a feeling that the Python community is not going to be building a Walmart any time soon.

I hope this is useful to those that share my social denseness, or that it may inspire others to practice spontaneous kindness as a way to build community.

Wing IDE 3.0.4 and 3.1 beta1 released

Wingware released two new versions of its Python IDE this week.

Version 3.0.4 is a bug fix release, most notable for reducing debugger overhead by about 50% per Python instruction executed. The threaded debugger in 3.0.4+ should now be about as fast as the old non-threaded debugger in Wing 2.x. About 16 other bugs were squashed. Details are in the change log.

Version 3.1 beta1 adds some new features including support for pkg_resources style name space merging (used in setuptools and with eggs), stepping through code in zip and zipped egg archives, doctest and nose unit testing support, inline form snippets that appear in the auto-completer, quick navigation to files in the project or symbols in the current editor by typing fragments of their names, and simple word list driven auto-completion in non-Python files.

If you try the beta, be sure to run Check for Updates from the Help menu after you install. Some patches have already been released to fix a couple of problems caused by build issues.

Last PyCon pre-registration day

Today is the last day to pre-register for PyCon. After that it's just on-site registration, starting next week. Don't delay, because the venue could reach its capacity of 1200 -- currently there are 963 paid registrations, with another 40 or so pending payment.

Last year we had about 560 attendees, and it was 400 the year before that so we're looking at a pretty nice growth curve.

Hope to see you there!

Wing IDE 3.0 released

Wingware just released version 3.0 final of its integrated development environment for Python. New features include multi-threaded debugging, hover tips with debug data values, auto-completion in the Python Shell and Debug Probe, auto-updating projects, a unit testing tool, better external command integration options, and a few other things.

One significant/interesting addition is support for Stackless Python out of the box. This very suddenly became one of our top-requested feature as game developers started using Stackless for their online game servers.

We've also released Wing 101, which is a free scaled back version designed for teaching entry level programming courses.

Details are of course at http://wingware.com.