Entries classified under weblog created during Dec 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.