Entries classified under weblog created during 2004

Phillip J. Eby has a recent weblog entry, Python is not Java, wherein he points out a few aspects of Python that are notably different from Java but that are similar enough that Java coders working in Python mistake them for their Java counterparts.

He touches on a few of the characteristics that led me to make Python my general purpose language of choice, a title that had belonged to Java as recently as a year ago. I thought it might be useful to explain these characteristics without assuming the reader has a whole lot of Python experience but that they do have significant Java experience. This would have helped me immensely in determining whether Python was right for me much sooner and I hope it can be of use to someone else.

I'm planning on covering each of the items Phillip points out in his article over the next month and if that works out, I may extend the series to a few other things that may be useful.

This is not a Python is better than Java thing. Instead of bashing aspects of Java's language and library that are obviously valued by the Java community, or insulting the intelligence of Java coders, or using any number of other techniques you might find in Every Language War Ever, Phillip is simply asking Java programmers who may be dabbling in Python to take a closer look at some of the features that make Python unique and attractive instead of attempting to force-fit concepts from Java. If you base your expectations of Python on Java concepts, you are likely going to have a bad experience with Python.

Continue on for the first part of the series, which talks about some of the differences between Python class methods / class variables and Java static methods / static variables.

I've had a few conversations recently where someone expressed interest in GNU/Linux and asked about getting involved. I really wanted to suggest that they consider joining the Fedora project but I couldn't do that comfortably because, well, there are some pretty massive issues.

So I'm really excited to see that Redhat is finally getting around to really supporting the excellent volunteer community that has dedicated themselves to making Fedora, and by extension Redhat's commercial offerings, excellent distributions. Herewith some recent news that led to this post...

Some days the Powerbook gets more attention than the wife and so she snoops over my shoulder and starts asking a bunch of questions about whatever is on the screen. She doesn't really care, this is just the cue to shift my attention over to her. I usually do just that and say something like, Oh, this is some interesting stuff but nothing you would care about.

But on this day I decided that I would play along a bit and see how far I could take her into my world before she ran away screaming in terror.

I was searching for a specific piece of Dive into Python when I ran into this classic from diveintomark.org:

Tom: "This is really good. You could probably make some money off this someday."
Mark: "Maybe, but I'm not going to. I'm giving it away for free."
Tom: "Why would you do that?"
Mark: "Because this is the way I want the world to work."
Tom: "But the world doesn't work that way."
Mark: "Mine does."

I had to pour out a little liquor for my homies.

This is the second post in response to cross-breading ZPT and XSLT. I'd like to dig into how I'd like templating to work in Kid and Leslie opens the door for me:

... maybe this is the sort of thing Ryan's thinking about-- I wonder how hard it would be to hack this into Kid? It would give only a subset of XSLT's capabilities in trade for simplicity, and would only offer the pull approach, but it would give XML-pipelining to a ZPT-ish technology.

Leslie de 0xDECAFBAD talks a bit about cross-breading ZPT and XSLT and mentions Kid along the way. This is the first in a series of response posts.

In Weapons and Coding, I made a prediction:

The first environment [Java / .NET] to successful mesh static and dynamic languages into a coherent platform will win the interpreted byte-code market.

Tim Bray must have come to a similar conclusion because he recently organized a meeting of the minds at Sun to talk about Dynamic Java. Here's a great pic of the BDFL and Larry Wall Tim shot right before they pulled out their katana's to settle the Python vs. Perl debate like gentlemen.

In my mind, Tim is moving into this small classification of people labeled, Hero. His past work on XML (as in, his name is on the Recommendation), recent work on Atom, declaration of The Loyal WS-Opposition, contributions through W3C TAG on the excellent Architecture of the World Wide Web, and now this seemingly unrelated initiative to get Sun to wake up about dynamic languages puts Tim on the right side of almost every major area of innovation I'm interested in. Go Tim, go!

I really hope this leads to some serious discussion on how we can bring static and dynamic languages together into a single cohesive platform. Drop the MFL is better than YFL talk found in Every Language War Ever. We need to start having these types conversations: MFL is a compliment to YFL. This is happening only in very small pockets right now and until today, they were pockets without a lot of potential for real impact.

So this is pretty crazy. I'm messing around with ElementTree (which has been nothing less than perfect) and trying to get it to act like a xml.dom.pulldom/XmlTextReader style pull-parser. But I'd like to be able to assemble a chain of generator producing/consuming functions (or other callable) so that the file can be read, parsed, filtered/mutated, encoded, and written all incrementally.

Check it out:

import sys
import pulltree    # that's what I'm working on :)

def upper_filter(source):
    for (ev, item) in source:
        if ev == pulltree.CHARACTERS:
            item = item.upper()
        yield (ev, item)

reader = pulltree.reader(sys.stdin)
filter = upper_filter(reader)
writer = pulltree.writer(filter, sys.stdout)

for (ev, item) in writer:
    pass

C-z

$ echo "<hello>world</hello>" | python test_filter.py 
<hello>WORLD</hello>

That felt good. More functional than a chain of SAX XMLFilters, almost as efficient, and muuuuch perdier.

Something like this might work someday soon:

import urllib2
from pulltree

XINCLUDE = '{http://www.w3.org/2001/XInclude}include'

def xinclude_filter(source):
    events = iter(source)
    for (event, item) in events:
        if event == pulltree.START_ELEMENT and elm.tag == XINCLUDE:
           href = item.attrib['href']
           for woot in pulltree.reader(urllib2.urlopen(href))
               yield woot
           pulltree.eat(elm, events) # eat events to the end of the element
        yield (ev, elm)

Granted, that's as basic an XInclude processor could be and still be useful but you get the point.

I've been searching for the perfect Python based XML template language. I was happy to find TAL (and specifically, SimpleTAL) a while back but, although neither of us wants to admit it, we've been growing apart for some time now. I spent last week looking for options and, after careful consideration and planning (read: beer and a nap), decided to just build the XML template language I really wanted.

There's at least four billion and nine text based template languages for Python but there aren't a lot of options that fit nicely into the XML tool-chain. Or, if they do fit nicely into the XML tool-chain, they don't fit nicely with Python.

My dreamboat XML template language would combine the pythonicness and simplicity of PTL, the templating features and pipeline-ability of XSLT, and the terseness of Zope's TAL. I'm building it, it's called Kid, and I'm making good progress to be honest.

But I have this overwhelming NIH feeling so I've decided the best thing to do is to run through the current set of tools and take a professional, objective look at why each isn't getting it done for me (i.e. make fun of minor flaws and limitations until I feel better about myself). Herewith, a look at the good and the bad in the Python XML templating space...

News.com.com.com is reporting that Firefox is gaining on IE faster than expected. Amsterdam based OneStat.com has IE's market share as low as 88.9%. I can't help but wonder if those guys didn't hit the hookah a few too many times before running the numbers. The Mozilla Organization has been saying that they hope to have 10% of the market by the end of 2005. You could project that they might reach that by the end of 2004 if these OneNet stats are accurate, which they most probably are not.

Sigh

At any rate, check out this gem from Microsoft's director of product management for Windows, Gary Schare (pronounced Gair-ee Share-ee ;)

"I still believe in the end that most users will decide that IE is the best choice when they take into account all the factors that led them to choose IE in the first place," Schare said. "Meanwhile, we're happy that they're primarily (using Firefox) on Windows, and that Firefox is part of the large ecosystem of software products available on the Windows platform."

The "factors" he references are covered briefly here, while more on the "Windows ecosystem" he mentions can be found here.

I've been working on a weblog/micro-content management system with what I believe are some unique qualities. I've wanted to write about some of the approaches I've taken and how they are (and are not) working out but feel I should provide some kind of context for my ramblings. So I'm going to try to summarize the main aspects of the system real quick so I can start digging in to the more specific stuff.

I've settled on the name "Splice" because I think it has a nice ring to it and is a pretty good one-word description of a major goal of the platform. Nothing has been officially released yet but I have allocated a project on sourceforge.net and plan on bombing the existing code up there within the next week. An initial 0.1 release should follow after about a month or so, assuming I can keep my current pace.

So without further ado, here's a quick breakdown of the planned features of Splice...

I was listening to Pearl Jam's Vs. album today when the song "Glorified G" came on. I always liked the song but I never thought it had any real meaning. It was eerie how relevant these lyrics feel today:

Got a gun, fact I got two
That’s o.k. man, cuz I love god

That pretty much sums up my narrow understanding of the red state mentality.

Check out this Review of Firefox at Net Gazette. It looks like a good old fashioned site at first but look closer. There is no actual text! The review consists completely of images... images of text. Each paragraph is a separate image arranged into tables for layout. What's even more interesting is how they, uh, "implemented" links. Each image-of-text has an image-map attached to it defining each links coordinates. I realize we need all the good press we can get but this site championing your browser is a bit like having the Ku Klux Klan back your presidential candidate.

I thought this was a really great example of a web architecture antipattern and it reminded me of something I wanted to point people to. The w3c recently put out the Architecture of the World Wide Web as a Proposed Recommendation. I really cannot express how much I like this document. It's very different from the recent slew of crap that has been flowing from the w3c. It isn't a specification at all, really, but rather a look at what the web got right. Sadly, using images-of-text-wrapped-in-tables isn't covered.

All content that comes to the web goes through a sucky phase before reaching true Web Zen. Reaching this elevated state requires answering the question, "What is it about the web medium that improves on existing forms of content delivery?" and then seizing them.

What you're getting into:

Mucking with builtins is fun the way huffing dry erase markers is fun. Things are very pretty at first, but eventually the brain cell lossage will more than outweigh that cheap thrill.

Barry Warsaw, 23 Mar 2000

Now, let's muck with some builtins.

Adam Bosworth, usually a staunch supporter of SOAP and the rest of WS-Mess, makes an interesting sidebar statement in the last paragraph of his recent post about PC's and Media Revamped:

I have a posted comment about just using XML over HTTP. Yes. I'm trying, right now to figure out if there is any real justification for the WS-* standards and even SOAP in the face of the complexity when XML over HTTP works so well. Reliable messaging would be such a justification, but it isn't there. Eventing might be such a justification, but it isn't there either and both specs are tied up in others in a sort of spec spaghetti. So, I'm kind of a skeptic of the value apart from the toolkits. They do deliver some value, (get a WSDL, instant code to talk to service), but what I'm really thinking about is whether there can't be a much simpler kindler way to do this.

If you've followed Bosworth before, you'll notice that this is a pretty big statement.