Jon Udell: Python

Shipping the prototype

2003-02-07T08:48:30-05:00

Years ago, when the paint was barely dry on Visual Basic 3.0, a developer showed me a CD-ROM-burning application he'd written using that toolkit. The idea was to prototype the UI in Visual Basic, then rewrite in C++ for performance. But in the end, he admitted somewhat sheepishly, "we shipped the prototype." I saw nothing to be ashamed of. It was -- and is -- a brilliant strategy. My only regret is that it hasn't been adopted more widely. [Full story at InfoWorld.com] ...

Mitch Kapor's open source PIM to use wxPython

2002-10-21T08:54:03-05:00

Mitch Kapor's Open Source Applications Foundation has emerged into blogspace, where Mitch says he'll chronicle its progress. The first project: a powerful, easy-to-use personal information manager for Linux, Windows, and Mac. Mitch writes:

At this point, a small team has spent the better part of a year thinking through the problem space and developing the fundamentals of our approach and has just begun writing the production code. We've made a number of fundamental decisions about the architecture and have arrived at a preliminary set of features. Andy Hertzfeld has built a terrific prototype which enabled us to explore lots of new ideas.

Sounds encouraging. This will be an open source project. And, of particular interest to me, the software platform is wxWindows/wxPython. Spot on! Way back in 1999, I said in a column:

I notice that Mahogany is built using wxWindows, an open-source cross-platform GUI framework built in C++. Mahogany achieves its scriptability by embedding a Python interpreter within itself, and then supplying some Python glue modules that expose parts of the Mahogany API to Python.

As the Mahogany docs note, and as is typical of this approach to embedded scripting:

Python has access to Mahogany's internal class hierarchy. At present we supply interface definitions and Python modules for only a small number of classes, however if there is need for more classes being supported, we can easily extend the list - please ask us if you want more support!

It appears that there might be another way to skin this cat. There's another open-source product, wxPython, which encapsulates wxWindows in Python. It enables interpretive, scripted development of wxWindows applications.
This raises the question: why isn't Mahogany a wxPython app, rather than a C++ app that embeds Python? If it were, no extra interface work would be needed to script-enable Mahogany, and it would be a radically programmable application.

Ever since then, I've wondered: why can't a scripting language drive a major, user-facing, GUI-intensive application? In theory, the use of a dynamic high-level language would release a lot of creative energy into a space that is desperately in need of it. In practice...well, that's what we're about to find out.

Zope lessons learned

2002-04-15T20:39:49-05:00

There's still much in Zope and in Python that I don't know well and can't do easily. Can this potent combination be made accessible to a wider audience -- in particular, to the kinds of folks who in an earlier era were the toolsmiths who created and shared word processor or spreadsheet macros? That's an open question to which, someday, I hope the answer will be "Yes." [read more at BYTE.com....] ...

Cross-platform coffee cups

2002-03-24T20:49:42-05:00

Years ago I evangelized the notion of a local scripting engine, serving web apps up into the browser. I thought then, and still think now, this is the biggest untapped opportunity for Perl and Python and Ruby.

Perhaps now that Radio UserLand has broken the ice, the idea of a script-based local app server will gain more traction. DJ Adams, who uses Linux and so can't be an RU user, was intrigued by the channelroll idea. So he grabbed Rael Dornfest's Peerkat and whipped up, in Perl, an app that responds to clicks on a Radio-style coffe-cup icon by injecting the specified RSS feed into an instance of Peerkat.

Very cool. RU is a lively experiment, but the publish/subscribe technology that is part of what makes RU so compelling is not, and should not be, application-specific. DJ is somebody I'll want to subscribe to, and who I'll want to subscribe to me. How we accomplish that is really beside the point.

JavaScript, Perl, Python, .NET

2002-03-15T13:08:32-05:00

Peter Drayton on JS.NET:

> I believe there is a market for a language much simpler than VB.NET.

For this, I suggest JScript.NET, which is also included in the .NET Framework. The funny thing is, while JScript is a relatively simple language, the JScript.NET compiler is actually very sophisticated, since it has to support late binding, prototype classes, typed and typeless variables, dynamic evaluation and a slew of other 'scripting' features. Basically the compiler does all the requisite magic to present a very friendly, simple face to programmers, while doing all the underlying goo needed to make these semantics work in the CLR. [Peter Drayton]

I just tried Peter's example:

var query = new ActiveXObject("IXSSO.Query"); 
query.Columns = "directory,filename"; 
query.Query = "@filename=*.txt"; 
query.Catalog = "System"; 
var rs = query.CreateRecordSet("sequential"); 
while (!rs.EOF) { 
  print(rs(0)+ ""\\" + rs(1)); 
  rs.MoveNext; 
}

Interesting. Could the same principles bring this Perl/Python research to fruition?

2002-01-31T16:12:23-05:00

Shane Caraveo from ActiveState wrote me a note illustrating how they handle WSDL for Perl:

=for interface

static ustring echostring(ustring something);

=cut

sub echostring {
my $echo = shift;
return $echo;
}

The question is overhead. Obviously this metadata, like all documentation, requires double maintenance, and can get out of synch with the code. As a Perl programmer, would I rather pay that cost in the form of typing all my functions and variables, and have a free ride on WSDL generation, or pay it only on a per-exported-object basis?

Sam Ruby and I talked about this today. He makes a good point: since exported stuff will surely be a fraction of all the stuff you write in a dynamic scripting language, why not just pay on an as-needed basis? It's an 80/20 (or 90/10) thing.

The flip side of this is that web services network effects arise, I believe, when things can automatically, or almost automatically, be exported -- even when the need to do so wasn't originally anticipated.

Kevin Altis, who is working these days on PythonCard, sent me this set of definitions which was in turn sent to him by "an erudite reader":

"statically typed language

A language in which types are fixed at compile time. Most statically typed
languages enforce this by requiring you to declare all variables with their
datatypes before using them. Java and C are statically typed languages.

dynamically typed language

A language in which types are discovered at execution time; the opposite of
statically typed. VBScript and Python are dynamically typed, because they
figure out what type a variable is when you first assign it a value.

strongly typed language

A language in which types are always enforced. Java and Python are strongly
typed. If you have an integer, you can't treat it like a string without
explicitly converting it (more on how to do this later in this chapter).

weakly typed language

A language in which types may be ignored; the opposite of strongly typed.
VBScript is weakly typed. In VBScript, you can concatenate the string '12'
and the integer 3 to get the string '123', then treat that as the integer
123, all without any explicit conversion.

So Python is both dynamically typed (because it doesn't use explicit
datatype declarations) and strongly typed (because once a variable has a
datatype, it actually matters)."

(If you are that "erudite reader" and wish to be identified, just let me know.)

Correction: here is the source of this quotation: it's from Mark Pilgrim's fabulous online Python book-in-progress. Sorry for the mixup, Kevin and Mark.

Note: it's tempting to try to rewrite history by changing these entries on the fly in order to erase errors. But that won't last forever. Before too long, the Wayback Machine will catch you in the act when you try to cover your tracks :-)

Perhaps this explains why I have the sense that if optional type declaration were going happen in any major scripting environment, it would happen first in Python.

2002-01-21T23:38:47-05:00

A Python introspection parable.