Saturday, May 31, 2008

One-handed typing?

I separated my right shoulder so that arm is going to be out of commission for a while.  (I am right-handed.)  I'm managing about 25 wpm with one hand, or about 1/4 my normal speed.  This is frustrating.  The Handkey Twiddler has been out of production for a while.  The BAT is not OS X compatible. Anyone tried the Half Qwerty keyboard?  Are there other good options for under, say, $300?  (I found several very niche products for significantly more.)

I do plan to try voice recognition for email and IM but I can't see that working very well for code.

Monday, May 19, 2008

Jython Notes

I've been getting back into the Jython codebase this last week. The last time I submitted a Jython patch was in the beginning of 2004, so it's been a while. Things have changed... Jython is finally requiring Java 5 for the next release, which means the usual improvements, but especially good use of annotations. Here's some notes from my puttering around (mostly dragging Jython's set module up to compatibility with CPython 2.5's):
  • Expect Eclipse to be slightly confused. (Lots of "errors.") This is normal. Use ant to build.
  • ant regrtest is handy. run it before you start making changes so you know what's already broken in trunk. (At least between releases, jython does not appear to be religious about "no tests shall fail." But as a new developer you should make "no additional tests should fail" your motto.)
  • Subjective impression: Jython re performace is a bit slow. Jython uses its own re implementation predating the Java regular expressions in jdk 1.4. But, the JRuby guys reported that the jdk implementation doesn't perform very well, so Jython hasn't been in a hurry to switch. The JRuby solution was to port the oniguruma re engine from C to Java. But, Ruby's strings are byte-based and mutable where Jython's are not, so using the JRuby engine isn't just a matter of dropping it in. Also, these string differences may be a source of the poor performance the ruby people saw, so independant testing is in order here.
  • All of the Derived classes (PySetDerived, PyLongDerived, etc.) just exist to let python code subclass builtin types. Those derived classes are generated by a .py script in src/templates
  • If you add a Java class that needs to be exposed to python using the @Expose annotations, you need to add the class name to CoreExposed.includes, or Jython will default to picking attributes via reflection and it usually guesses wrong.
  • Given a PyObject, you can (usually) easily instantiate another PyObject of the same class with pyobject.getType().__call__(). The only times this won't work is when your type's __new__ does something tricky, like how PyFrozenSet or PyTuple return a singleton for an empty frozenset or tuple.
Thanks to all the people in #jython who helped me out, especially Philip Jenvey!

Friday, May 16, 2008

Quick tip for debugging with Jython

Currently, Jython ships with the pdb debugger module from Python 2.3. Unfortunately the 2.3 pdb is primitive even by command-line debugger standards. (For instance, if the program you are debugging throws an exception, it will take pdb down with it. Seriously. Did anyone actually use this thing?)

Fortunately all you have to do to get a much better experience is grab,, and (for good measure) from a 2.5 CPython installation and run against that instead.

I've only tested this with Jython trunk but I think it should Just Work with the 2.2 release, too.

Friday, May 09, 2008

IDE update

Last night the Utah Python User Group held an editor/IDE smackdown. I'm not going to write an exhaustive summary, but here are some highlights:
  • ViM's OmniComplete is actually pretty decent. Calltip support in the GUI is also good. (GUI? ViM? Yeah, weird.)
  • Emacs completion, from Rope, is also good. Emacs's refusal to make any concession to GUIs though keeps things clunky. Not that it isn't great that Everything Works over plain ssh; that's fine, but going through classic Emacs buffers for docstrings or completion means everything takes more keystrokes than it should while being less useful than having that information Always On.
  • Rope also gives Emacs refactoring support that works surprisingly well.
  • PyDev still sees a big win from the Eclipse platform. Specifically, even though Subclipse and Subversive are a bit weak compared to the gold standard (that would be TortoiseSVN), they are much better than what you get with Komodo or Wing. Now that I am on OS X (no Tortoise) this is a bigger issue for me than it used to be.
  • PyDev Extensions has refactoring support now, too.
  • Komodo has limited support for completion inside django templates. Which is impressive, since the commands allowed in django templates aren't really Python, which is to say that you can't just use the same completion support that you use for normal Python code.
  • Mako template support with completion, anyone?
  • The latest versions of Komodo and Wing both integrate unittest support. Wing also supports doctest out of the box. Meaning, you click a button, your tests run, you get a pretty summary with click-to-go-to-the-source-of-the-error support. This might get me to finally upgrade to Wing 3. It's not that "python" is so hard, so much as I do it so often that even a little more convenience adds up.
I was surprised how well ViM and Emacs do with Python now. ViM's modern inline interface for code completion and Emacs's refactoring support are particularly nice. The IDEs still win on the I part (Integration), in particular debugging and (for Eclipse at least) svn support.

Update: Ryan McGuire blogged about his Emacs presentation in more detail.

Update 2: John Anderson blogged about setting up ViM