David Brown: Radio Python

pyobjc exploration

Thu, 16 Oct 2003 18:09:26 GMT

I started to check out the 1.0 release of PyObjC last night. I'm impressed. You have several options for creating applications -- Completely standalone, Mostly standalone (but requires a pre-existing python installation), or an application that requires a pre-existing PyObjC installation as well as a pre-existing python installation (which comes with OS X by default). I've played with it before, and while I was amazed at what the PyObjC team has accomplished (my hat is off to you, guys), I was a little surprised at how long it took an application to start up. In the 1.0 version, startup time has drastically improved, and you can create an entire standalone application without ever starting Project Builder (although you'll need to use Interface Builder to create your NIB files). The examples provided with the installation are quite impressive, and the Python Object Browser example (using multi-column tree views) was breathtaking, in that it demonstrates something that I've wanted very badly. I love it when I see something that causes me to coalesce a number of ideas into a project plan, and I think exactly that is happening. I expect to soon begin coding quite a bit, and I hope to have something to demonstrate eventually. There is a project that has been taking shape in my head for years, and I think I finally have all the pieces I need to make it come together. By the David Brown "How much excitement does it generate" 1-10 scale of coolness, PyObjC gets a 9. (If it was cross-platform, it would be a 10.) Download it, check it out, build something cool. I'll be right there with you.

pyobjc hits 1.0

Fri, 10 Oct 2003 23:58:42 GMT

Cool. It looks like PyObjC has hit 1.0. Now I'll have to actually try using it for something. For those that don't know, PyObjC provides a way to write Cocoa programs in Python. So Python can have a real Mac OS X GUI without using something like wxPython (although wxPython is quite cool in and of itself).

ipython: quick recommendation

Thu, 09 Oct 2003 18:44:37 GMT

Quick recommendation -- if you like using the Python interactive prompt for quick explorations and calculations, check out IPython. It's almost enough to replace your bash or tcsh shell. I used to use a spiritual predecessor of IPython -- Lazy Python, and IPython does everything that Lazy Python did and more. I just wish the color options worked with Win32. Maybe if someone tied it together with PyCrust...

ruby

Thu, 09 Oct 2003 17:41:36 GMT

Since my Python post the other day, I've seen some mention of Ruby as well as a post about how someone couldn't get Python to do what he wanted, but Java solved the problem nicely. I've looked at Ruby, and while the bits that look like Smalltalk are appealing, it's the bits that look like Perl that get to me. I've tried to like Perl, but I just can't seem to do it. The bits that look like line noise just turn me off, and when I start seeing the same things in other languages, I have to start resisting the tendency to judge those languages the same way. Mats talks about Ruby following the "principle of least surprise." The problem is, I keep being surprised. It's as if the Principle is really about least surprise for those people who are used to programming in Perl. Don't get me wrong -- I'm not here to shove Python down your throats. I admit to an obvious bias, and I don't try to hide it. Perl holds the internet together, and I've seen some amazing things done in Ruby (like the new Weblog system from Tucows). They just don't seem to work well in my head. Oh, and Java? Java has paid my bills for a few years now. I'm familiar with it's shortcomings and it's power. I've solved a lot of problems with it. Now if I could make Python sign my paycheck, I'd be happy. I'd be delirious if I could work in Python and be able to buy food and make my house payment.

python is a time bomb (in a good way)

Tue, 07 Oct 2003 17:35:49 GMT

Python is a time bomb. Or perhaps, it's a time-release mind bomb. I love watching people get it. Lately I've been trading email with a friend who has been bitten by the Python bug. He's known about Python for a while, and he's a smart guy. I just knew that if I waited long enough, that he'd start to see the things that I see. That having a programming environment that helps you get things done, rather than having you struggle with the mundane is a good thing. A while back, I made the observation that it seemed that to be taken seriously as a language, it has to do as little as possible for you. I think that was an attitude that hearkens back to the days of computers that measured their clock speed in the low 10's of megahertz. Back when every cycle counted, you didn't want the computer doing anything that you didn't know about when you wrote a program, so languages like C were highly prized, because you got the advantages of a high level language (better control structures, et cetera) along with the control inherent in a low level language. Nowadays, it becomes harder to see a language like C as being high level. Mid level at best, I would say, these days. Now, if a language can do things for me, I'm all for it. Manage my memory for me. Do all those various string manipulations for me. Help me with error processing. I don't need to write another hashing routine or another link list. I've proved I know how to do that already, and I'm more interested in debugging the bigger problem rather than finding out that I screwed up some tiny special case in my list management. Python is a time bomb. I've yet to see someone run with it the first time they are exposed to it. We all know the drill. "Indenting for block structure?" "Why should I use Python when I can do all that in Perl?" and the ever popular "Scripting languages are not for serious programs." But then, because you're curious, you start using it. The first thing you notice is that (if you had good formatting habits to begin with) the indenting issue goes away. You were going to do it that way anyway, right? Then you notice that you got the job done in less time than you realized it would take. Personally, that's my favorite bit. The "It's done already? And it works?" feeling. I love it. You find yourself prototyping ideas in Python. We've all experienced the "executable pseudocode" bit as well. That rough sketch of code you wrote on a napkin? Chances are it's going to work as it is, or with only minor modifications. You didn't really mean to write it in Python, you say, it just happened. The Perl issue is handled when you go back to those Python programs after a few months. Even the first ones you wrote, before you had a feel for the way the language wants to be used, even those first steps, are readable. You can still tell what you meant to do with them. Maybe it's just me and my friends, but going back to old Perl code, unless it was incredibly well documented, makes you wish for a cuniform dictionary. (It's 10pm, do you know what context you are in?) The final domino to fall, the "serious application" domino, is easy enough. We've already heard the litany. Google. Zope. Twisted. The list grows longer each day. Welcome to Python, Cameron. The water's fine.

dynamic languages play with your mind.

Sat, 20 Sep 2003 03:47:28 GMT

I went through an interesting thought process while working on the code to drive the radio. My initial thought was to do a full blown interface for the radio. Do the classic gui representation of a radio, with knobs and lights and all that. I may still do that, but as I asked myself what I really wanted to do, the effort shifted gears, and what I ended up with is a set of classes and functions that just make it really easy to make the radio do what you want it to do. So instead of writing this general purpose application, you can create a special purpose radio for whatever service you are monitoring. And since it's all being done in Python, it's easy to do some nifty things like writing code that searches for certain radio channel activity and use the results to write a program that specifically scans for those channels. Yeah, that sounds confusing, but metaprogramming is always much harder to describe than it is to do. Writing programs that write programs is kind of fun.

Tue, 16 Apr 2002 21:26:16 GMT

Daniel Berlinger asks why I think the syntactically relevant indentation of Python was a breakthrough. There are a couple of reasons... [Scripting News] Yeah. What he said. (go read it.)

Fri, 12 Apr 2002 21:37:31 GMT

Doc trashed Oddpost for being MSI5/Win only and Doug Hacker pushes back and speaks for me. Pushing the envelope is great no matter what. Doc's feelings are irrelevant. In the past users, esp Mac users, have pushed this button to quickly. If a breakthrough happens and users flock to Oddpost, that's good. I see Mac users these days getting lots of stuff that Windows users don't have (I use Windows) and that's cool too. [Scripting News] I think I know where Doc is coming from. But I tend to agree with Dave. A few years back, I remember Dave posting about another web site that was trying to design pages with broadband in mind, so they were very graphic heavy, and had a lot of JavaScript for interaction. I remember thinking that it was very pretty and fun to play with, but I also felt like it was threatening my bandwidth. You know when you get a new fast computer, and then companies start adding feature after feature to the software, so that the computer ends up feeling as slow as the one you replaced? That web page made me fear that the same thing was going to happen to my bandwidth. Web pages were going to bloat more and more, until my cable modem started feeling like a 28.8k connection again. But it never happened, because the increase in broadband speed and adoption has not followed Moore's law. I have since changed my mind. We DO have to keep pushing the edges. We have to keep having faith in Moore's law. We have to believe that we will continue moving forward, because the alternative is stagnation. I see that now. In fact, some of the design decisions that I've been making for my current Python project have been based on what I think will get faster, rather than what is fast today. The code I've been writing to play with the Radio ODB from Python uses the following transformations: ODB -> table.tableToXml() -> XML-RPC -> fTableXML -> python and then back as: python -> XML-RPC -> table.xmlToTable() -> ODB The problem is that it is slow. It's been suggested that I toss XML-RPC and try to go direct, but I don't see that as gaining much. The XML-RPC overhead is not as big as you would expect. By far the most processing time is being spent in table.xmlToTable and table.tableToXml. I have a very good reason to keep using XML-RPC and the table verbs, and that is that UserLand is VERY committed to the utility of XML in general, and XML-RPC in particular, so I see those verbs as primed for kernelization, thus getting rid of most of my speed problem. So, yeah, it's a faith thing, but I can see it happening. Of course, another way to go about it is to add Python hooks to Radio, or expose the ODB entry points so I could write some C to couple Python to Radio. It should be somewhat simple to make Radio call Python.

Mon, 08 Apr 2002 07:08:10 GMT

To sum up: I went to my first 2002 Mariner's Game tonight. Exciting, and yet ultimately quite disappointing. Oh well. I still have 15 more games to see. While exploring the iRights site looking through the Radio/Jabber interop work that is happening (I enjoy interop a lot), I happened upon this. I find that project very interesting, because it fills a hole for me. It makes it much easier to do Python/Radio interop. I will have code to play with very soon.

Sat, 02 Mar 2002 18:22:15 GMT

Okay, I came up with a fix for the execution problem. Now, instead of using execscript(), I'm quietly writing out a patched version of the script that bundles up the ouput and sends it back to Radio. Refresh the code to get the fixes.

Sat, 02 Mar 2002 17:54:11 GMT

Argh. I just hit a showstopper in the Python Tool. It might be a bug in the execfile() routine, but I can't be sure. It goes like this... With the following code:

class A:
    def __init__(self):
        print "A.__init__"

class B(A):
    def __init__(self):
        A.__init__(self)
        print "B.__init__"

test = B()

If I run this directly through Python, it's fine. If I run it through my execution framework (which uses execfile() to run the actual script), it causes a NameError, which claims that it has no idea what A.__init__ is. Ideas? Need more information?

Thu, 28 Feb 2002 06:37:16 GMT

One of the things I wish to build for the Python IDE is a web services framework. This means that I would like to support both XML-RPC and SOAP. There is already a decent XML-RPC package that comes with Python 2.2+ (and can ve installed separately for other versions). I'm looking for a good SOAP library that works on OSX. I've downloaded and tried to use ZSI, but there are some problems with ZSI and OSX (the value they try to use for Inf and NaN cause an overflow when ZSI is imported). I'm exploring other implementations, but from what I'd seen, ZSI is the most complete. Leave a comment if you have an idea.

Tue, 26 Feb 2002 01:49:17 GMT

I've finally gotten email that tells me that someone other than me got the Python IDE to work. Thanks, Joe. If anyone else is using the tool, could you drop me a line and let me know how it's going? Just a quick note that says that it works would suffice. Problem reports and feature suggestions are always welcome as well. As someone who likes to produce tools, the best part is when someone else finds the tool useful. The worst part is wondering if anyone is actually using it. Is there somewhere on the radio.weblogs.com machine that will give a traditional access log? I'd love to know how often the tool got downloaded. Yes, I check my referer log too often as well.

Mon, 25 Feb 2002 01:27:26 GMT

I've updated the current version of the Python Tool to include the ability to refresh the code (like the myPictures tool that Dave did), so you don't have to keep checking the site, you can just use the 'Refresh Code...' menu item to automatically incorporate any changes I have made. I also fixed a bug dealing with setting up the executionTemplate, so if you've ssen that error, get the new code.

Sun, 24 Feb 2002 20:22:01 GMT

Upon reflection, it's stupid to make Python projects live in separate databases, at least in terms of playing nice with Radio. I'm thinking that what I really want to do is give the ability to import and export Python Tool-compatible files. I also need to work on importing Python source files from text. There are some things I need to understand about how Radio figures out the outline indentation when importing a text file. Normally it just "get's it right" when converting Python source to a Radio outline, but there are some strange times when it doesn't. I have my suspicions as to what is going on, but I haven't been able to prove anything yet. Once I have that straightened out, I'll put out a tool that plays nicer with established Python installations.

Mon, 18 Feb 2002 07:36:30 GMT

Okay, so the bundling bit works fine, but I'm pulling my hair out about execution. I think I'm going back to the framework, and just advise people to restart it if they think the environment has been corrupted. On the other hand, I'm having a hell of a time trying to use sys.unixShellCommand to launch anything that calls back to Radio using XML-RPC. It worked fine with the weirdo Python I used to have installed. I got it from here. It's a 35M download, and was built to be used with PyGame, a game framework for Python. I may just recommend that particular Python for use on OS X. Why is this weirdo build of Python the only version of Python on OS X that seems to sensibly support application launching?

Mon, 18 Feb 2002 03:28:09 GMT

I've been reminded that a bundle also introduces a level of scoping, and that it can improve performance. It's a little harder doing the same thing in Python. I could get the scoping improvement by translating bundles into "if 1:", but I am unsure about whether that would actually make things worse.

Mon, 18 Feb 2002 00:16:51 GMT

Sun, 17 Feb 2002 23:05:15 GMT

I hate it when I find these things. It turns out I didn't have a standard install of Python on my machine. I thought I had MacPython installed, but when I tested it against the standard MacPython installation I discovered that it doesn't work with the launch.appWithDocument verb I was using in Radio. So I'm going to make it work with the Fink version of python, and assume that it's installed in the standard Fink location of /sw/bin/python. I'll also include documentation that describes how to fix that path if it's wrong. So here we go again. Sorry about that.

Fri, 15 Feb 2002 06:40:28 GMT

I've changed the way that Python Scripts are run. The XML-RPC framework is fast, because you don't have to launch the Python interpreter each time, but there was always the danger that a Python Script could modify the execution environment in a way that would affect subsequent executions. So now I write out a small script that redirects stdout, executes the script, and passes back the results to Radio via XML-RPC. Slower, but safer. This also means that it works more reliably on OS X. I've updated the docs here to reflect the new version. Oh yeah, download a new copy if you want the changes. Next up -- multiple Python Projects. Want to get working -- integrated debugging, better error message processing, more Radio connectivity

Thu, 14 Feb 2002 16:12:40 GMT

A news feed specifically about the Python Tool can be found here.

Thu, 14 Feb 2002 16:09:07 GMT

Some notes... This is NOT a Mac OS X ONLY tool. I used OS X for development at home, and stole slow time at work to make sure it ran well on WinXP. I have a WinXP screen shot, I just haven't uploaded it. I guess the lack of an OS X Python IDE is why it is getting noticed in the Mac world first... Also, for the Mac version, I tested it with the MacPython 2.2 build. If you are using the command-line Python, the method I'm using to locate Python will fail (you won't be able to use the File Dialog to navigate to /usr/local/bin or whereever it is). You could try jumping to pythonData.prefs.pythonApp and putting the path in there directly, but Radio wants a Macintosh path, with ':'s, rather than the Unix path that OS X will support but not require. I'm already having to do a little path hackery when passing file paths to already running Python programs (they want the Unix version), so perhaps there is hope there. Remember, this is a first release. There are bugs. The bug-free experience probably does not exist right now. To steal a line from UserLand, this is Shitty Software, with Bugs.

Thu, 14 Feb 2002 16:03:08 GMT

People are noticing the Python tool: http://www.schockwellenreiter.de/2002/02/14.html#a3816 http://www.deadlybloodyserious.com/Radio/2002/02/14.html#a488 http://radio.weblogs.com/0100438/2002/02/13.html#a433 http://radio.weblogs.com/0001258/categories/tigmarksMac/2002/02/14.html#a96 Yes, I've fallen victim to obsessing over my referererererer log.

Thu, 14 Feb 2002 09:39:20 GMT

Of course, as soon as I let the cat out of the bag about the Python Tool, I start having thoughts about how to radically change things. Like getting rid of the framework. I can use the whole 'Radio renders Python' idea to new levels. I can use frontier.openDataFile to implement Python Projects. I can provide Transcripts and Workspaces. I could do a browser.

Thu, 14 Feb 2002 06:20:25 GMT

David Brown: Radio as a Python IDE. “The Python Tool allows Radio UserLand to be used as a Python IDE. Radio’s integrated outliner turns out to be a wonderful tool for Python editing, and the Tool provides an efficient way to write, debug, and deploy Python code.” [mac.scripting.com] Heh. Recursive blogrolling.