Pythonology

Python is an amazing programming language that makes software development productive and fun. Python is open source, was created by a community of thousands of developers world-wide, and is used by about 14% of all programmers today. These are my thoughts as a user, advocate, co-author of an IDE for Python, and a director of the Python Software Foundation.

Monday, February 15, 2010

Wingware at PyCon 2010

Wingware is a silver sponsor for PyCon 2010. If you will be at the conference, please stop by our booth in the expo hall or come to one of our open space events (times will be posted on the open space boards and at our exhibit booth). Wing IDE's developers will be available at both locations to take suggestions and feedback, answer questions, and/or to help you get started using Wing IDE with your code base.

We will also be handing out Wingware balsawood gliders and gel ink pens for those that are swag-inclined.

Hope to see you there!

Monday, February 01, 2010

Wingware Python IDE 3.2.4 released

It has been quite a while since I've announced a new release of Wing IDE here. We are now up to version 3.2.4. Here is a summary of what we added in Wing IDE 3.2:

  • Support for Python 3.0 and 3.1 and 64-bit Python on OS X
  • Improved version control integration for Subversion, CVS, Bazaar, git, Mercurial, and Perforce
  • Added 64-bit installers for Linux
  • File management in the Project view
  • Symbol type icons in the auto-completer, based on rewritten type inferencer
  • Auto-completion in the editor obtains completion data from live runtime when the debugger is active
  • Perspectives: Create and save named GUI layouts and optionally automatically transition when debugging is started
  • Improved support for Cython and Pyrex (*.pyx files)
  • Added key binding documentation to the manual
  • Added Restart Debugging item in Debug menu and tool bar
  • Improved OS Commands, Bookmarks, and Templating/Snippets tools
  • Many, many bug fixes and minor improvements. The change log contains the gory details.
The best way to learn more about Wing IDE is to just try it. There is a tutorial in the Help menu or just add your code to a project, set up any needed Python Path in the Project Properties, and forge ahead.

Friday, March 20, 2009

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!

Thursday, March 12, 2009

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!

Tuesday, February 24, 2009

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.

Monday, April 28, 2008

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

Tuesday, March 18, 2008

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.