SuperBoB » python

Wxpython and XRC

bob — Wed, 21 Apr 2010 18:42:24 +0000

I dug up some old code and have been converting a wxPython program to use XRC resources. I like the separation, between the layout and the code, but there are a bunch of things I don’t like. The error messages are often cryptic. For instance, “‘Nonetype’ object has no attribute ‘FindWindowById’” could mean that you are missing an or tag in your XRC file. However, the error doesn’t say you are missing an object tag; it goes off about some sort of non-existent attribute. No handler found for XML node ‘object’, class ‘xxx’!” probably means you missed putting a sizer object around a child in one of the different sizer container controls. I suppose this is where an IDE would be useful to do refcounting of object/object and to determine if children inside a sizer control are suitably wrapped. I generally prefer to write everything using Vim. I’m not sure I’m smart enough to write a vim mode that could handle XRC files, but I can see where one would be pretty useful. Another “issue” I have is that most of the examples of using wxPython are not using XRC. I sometimes have trouble adapting code I find online to fit in to my model. In the end, though, I’ve been pretty happy with my experiments.

VIM as an IDE

bob — Sat, 02 Jan 2010 18:34:47 +0000

VIM can be incredibly efficient as a text editor. Even if this wasn’t the case, movement keystrokes are so ingrained in my muscle memory that I end getting j’s and k’s in my notepad and MSWord documents. So the editing is taken care of, but the compiling, deploying, keyword/function lookup, etc. could be better. I realize there are many “tricks” and vim plugins to give a lot of this functionality, but it seems like I have to search again whenever I set up a vim environment to find the best fit for my style. I have linked a few posts below because I found them useful, and this is a handy way for me to get back to them the next time the question comes up. I’m sure I’ve missed some. Post your favorite links on turning VIM into an IDE in the comments.

1) Unix is an IDE
2) Python and vim: Make your own IDE
3) VIM as Python IDE

New project: Uplifter

bob — Mon, 06 Jul 2009 15:34:50 +0000

I have started a new project (a relatively simple program to upload files to a server). I thought it would be fun to develop this in the open and talk about design decisions I made.

One thing I want to try is to compare and contrast some different ways to develop the same program. I originally wrote some pieces in Python using wxPython. I separated most of the control definition for the one window (essentially a glorified dialog box) in the program. This information now resides in a separate xrc resource file.

There is a hefty amount of runtime files needed with this method. Python and wxPython each require their own software install. I decided it might be fun to write the interface using Runtime Revolution as well. This isn’t free like the Python route, but I already own a copy and any source code I write for this can certainly be free. I think that the compiled end product will be significantly smaller than a binary distribution using Python. It will also be mostly self-contained. I say mostly, because there are still dependencies, but I think they will already be loaded on the OS.

I plan on writing this program for Windows. Both of the preceding two methods should be cross-platform with little if any changes needed to change between Linux, Mac OSX, or Windows. However, I’m thinking of trying a third method, writing the program using AutoHotkey. This would be limited to Windows as far as I know. From my experience though, these types of programs can be compiled into a relatively tiny binary, that I think only depends on the MSVC runtime.

Python SSH made easy

bob — Thu, 29 May 2008 20:23:16 +0000

Robey Pointer has made programming with SSH attainable for several years now. However, if you are slow to pick things up like me, the demos only get you about halfway there. I needed a little extra boost to understand how to use Paramiko. I just happened to run across the Command Line Warriors blog today which has this little tidbit. Not only is it brain dead simple to create a little ssh script with this, but looking inside ssh.py has given me a great demo that shows how to use the Paramiko suite for different things that I wanted to try. I just wrote a file transfer program in four lines. I’m sure the jokes on me for being a little dense, but I’m excited because this has given me the extra help I needed to start using Paramiko.

Self-Hosted Python

bob — Wed, 28 May 2008 01:10:31 +0000

Python continues to impress me with things like a C compiler written with Python. Building special purpose machines with tools like LLVM is beyond me. It’s one of those subjects that I seem to doze off reading. However, I have built a couple grammars with ANTLR. I just went to see what’s new with ANTLR and saw the ANTLRWorks GUI Development Environment. This would be a pretty good thing for PLY to have.

One could use Parrot to build a Python interpreter, or embed an interpreter in PHP, but I think I prefer RPython for my alternate implementation.

Vim options for python

bob — Fri, 23 May 2008 13:40:33 +0000

Although there are a lot of options for Python editors on the Internet, I have been using some version of VI for far too long to give up my muscle memory of modal editing that VI uses. Wing IDE actually has decent VI keystroke support, but it doesn’t go quite far enough, or I haven’t figured out how to make it do what I want. For instance, I use all sorts of ed commands, and like my macros and buffers. It looks like the Wing authors are interested in improving the VI personality of the editor, but I’m impatient. I think I’ll have to work at using Wing and file a view bug reports, although I’m not sure they aren’t really enhancement reports.

In the meantime, there is a lot of information on the web about how to set up VI to use as a decent Python editor. This article by John M. Anderson was helpful to cover a bunch of the basics. I also found a great 6 easy steps process to get ctags working on Windows. Maybe this isn’t such a big deal to you, but I have jumped through a lot more steps before to get this going. The value here is in the conciseness of the information presented.

I don’t have my perfect vimrc set up yet, but I am a lot closer after adding BufExplorer, NerdTree, and Snippets. I plan on figuring out more cool stuff that I can post about Vim and Python.

Is there Magic in the Air?

bob — Thu, 22 May 2008 16:32:22 +0000

I read a blog entry recently that Steve Yegge wrote last year about what makes great software. Coincidentally, I have recently been working on better Python integration with Vim and better Vim integration with Firefox. Steve’s blog post gives several major criteria for good systems, not that completing the list makes a piece of software good. Instead good systems should have all point in the list covered.

1) systems should not reboot

2) systems must be able to grow (without rebooting)

3) a system should have a command shell

4) a system should have integration hooks (Steve calls this advice, and it is probably more subtle than “hooks”

5) systems should have an extension language and a plug-in system

6) perhaps the hardest today, systems should be introspective

The article spent a good amount of the space on Firefox. I think he spent a lot of time trying to explain how to improve Firefox because he would like to use it. This seems like a win for the Mozilla group to me. If Firefox was beyond hope, it wouldn’t take more than a couple sentences to write it off.

The newest release candidate of Firefox 3 does not fix the need to reboot, but less memory leaks are a good step in the right direction. I’m not to worried about murdering my programs, but is definitely an inconvenience to me when I’m forced to restart Firefox. I think working towards no restarts would help stability during normal use. I would think that all of this stuff should be figured out in the OS anyway, but as Firefox gets more complicated, I supposed it has to take on more aspects of an OS such as proper process and memory management. It should have a good response to a lack of resources. The dialog that tells me a script is not responding is a start, but the browser should have better built-in health monitoring if possible.

Steve gives the example of Greasemonkey as a way to extend Firefox without rebooting. I wonder if add-ons could be written as strictly JavaScript, considering one can specify CSS and write HTML elements along with program logic. I have also been playing around with Chickenfoot. It has a limited set of extension scripts, but I think we need more access to UI elements with Greasemonkey. For right now, that is held back because of security concerns.

If security is going to be the limiting factor, then we still need a way to install extensions without restarting. I don’t know if there is a good way to distinguish whether changes to chrome are safe or not. Once XUL runner is fully functional and hosting Firefox as an application, maybe the problem will be changed. Firefox will act like a virtual machine, which might make for seamless restarts, rather than no restarts.

Brendan Eich also wants to let Firefox be extended with Python. If this actually becomes a reality, I anticipate the number and kind of extensions skyrocketing. JavaScript is pretty easy to work with, but Python seems even better to me.

As far as command shell. I have been using yubnub, which gets you part of the way there. I recently discovered vimperator, which provides not only a command-line, but a partial Vim-like environment. If you don’t have the piece you already want, just add something to yubnub or vimperator to extend your shell. Again, I hope that adding python to the mix will allow this to reach even farther and be easier to extend. I haven’t become practiced with vimperator yet, but already I can see it’s usefulness in navigating by keyboard.

Playing with Python

bob — Mon, 19 May 2008 14:22:55 +0000

I recently started playing with Python again. It is amazing how fast you can pick up information on how to create a service or compile Python into standalone applications for OSX or Windows.

Python also has quite a few GUI frameworks as well as a good number of python web frameworks.

After looking at portability, pre-built binaries, ease of building a program, and ease of compiling, I have settled on wxpython as a GUI framework for now, although I have used all of these except pyxul to build different applications. Either Python(x,y) or Enthought provides a pretty comprehensive Windows package including WxPython. The former also has PyQT as well.

The web framework question is a lot tougher. I have played around with Turbogears, Pylons, Django, and web.py (if that can be called a framework), but I haven’t built anything serious with any of these. I recently came across web2py. I like that it seems to give a built-in tool to add new applications. It also seems to have some of the built-in administration screens like Django. I am working on building a sample website with it now, both to teach myself and to show others a framework example. Since web2py was built with education in mind, it seems a more natural fit for this last purpose. A long time ago, I was messing around with Zope. Although Zope and Plone are pretty powerful, I dont’ think I would use them as teaching examples.

More exciting for me than playing around with Python, I have been attempting to teach it to other people. It just seems to flow naturally, both to CS students who have had experiences with other languages, and with complete newbies. I really like Dive into Python, but have been looking at other sources such as Byte of Python, a starter wiki, and Wikibooks as well.

Eventually, I hope to be able to apply some of this knowledge to Sugar which has really intrigued me. Perl had a project to recreate a lot of the Unix tools in Perl. I have a Perl OS archive saved for years now. I think a lot of these can be recreated in Python, but the idea of creating a whole interface in Python seems to be an even greater amount of work with a possibly greater payoff.