Tag: Python

Posted on

Recap and Prelude

Recap

Too much travel and conference fun, too little blogging:

I was invited to present a keynote at ACM ICFP 2005 in Tallinn, Estonia at the end of September. The very kind program comittee was unanimously interested in me as the ‘where the rubber meets the road’ speaker. I hope I delivered; I still have tire marks on my back from the Netscape 2 days.

It was an honor to speak and attend, and I made some good connections and introductions. Among these was Autrijus Tang, who is a hero in my book for promoting both Perl 6 and Haskell in one fell swoop. Functional programming is on the rise, and I’m glad that JS is playing a small (but very widely distributed) part.

While there, the Skype guys were nice enough to have me out to dinner — I hope to reciprocate when they’re in the bay area.

The old town in Tallinn is delightful, full of charming architecture from various eras going back to the high Middle Ages. I’m planning my move already (half-kidding).

After that came Web 2.0, which was a blur of VCs, old friends, and new companies. Everyone noticed the bubbly atmosphere. Mitchell was in fine form in a kind of interleaved interview titled Can Open Source Stay Open?

Prelude

I have been working more and more with ECMA TG1 on JavaScript standards, at first E4X (which was all but done when Mozilla joined ECMA last year) and now Edition 4. Our goals include:

  • Bringing Edition 4 back toward the current language, so that prototype based delegation is not a vestigial compatibility mode, but the dynamic part of an object system that includes classes with fixed members that cannot be overridden or shadowed.
  • Allowing implementors to bootstrap the language, expressing all the meta-object protocol magic used by the “native” objects (ECMA-262 Edition 3 section 15), including get/set/call/construct and control over property attributes such as enumerability.
  • Adding type annotations without breaking interoperation of existing and new editions, in support of programming in the large — which is needed more and more in XUL and modern web applications.
  • Fixing longstanding problems that bite almost every JS hacker, as I’ve discussed previously.

Our intention is to finish by the end of next year, and to implement and test interoperation along the way as much as possible. The Macromedia folks are quite far along in their implementation of a derivative of Waldemar’s Edition 4 draft, called ActionScript 3.

At the same time, and while also slaving over a hot Gecko 1.8 / Firefox 1.5 stove, I have been working with Mozilla leaders, especially shaver and other drivers, on roadmap-level plans for the next year to 15 months.

These plans build on bottom-up planning from module-sized projects such as the move to Cairo graphics as Gecko’s new graphics substrate, the Python for XUL project, and the XULRunner project. We aim to balance the need to ship Firefox releases that innovate quickly in user-facing ways with the longer cycle time required to uplift the web platform with better graphics features and content languages in Gecko 1.9.

The fruits of all this planning, in the form of a coherent draft overview containing links to project and wiki pages, and a schedule and branching plan for everyone to review, will be pushed out to https://www.mozilla.org/ imminently. The old roadmap page will contain at least links, if it doesn’t beome a redirect. Stay tuned.

Posted on

Python for XUL scripting

I announced XUL support for Python at ETech to cheers, and now Mark Hammond has begun delivering the goods. See the DOM_AGNOSTIC_BRANCH for his work to enable Python (and other languages, but Python for sure, and other languages need their own champions to do some work) to be used when writing trusted XUL applications and extensions.

One of Mark’s first testcases, slightly abridged:

<window
xmlns="https://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"
id="main-window" orient="vertical">
<script language="python">
<![CDATA[
import xpcom
for attr in "document parent top scrollbars name textZoom scrollX scrollY".split():
try:
val = getattr(this, attr)
except (xpcom.Exception, AttributeError), exc:
print "FAILED to get attribute %s: %s" % (attr, exc)
else:
print attr, "is", val
print "Scrollbar visible =", this.scrollbars.visible
promptService = xpcom.components.classes["@mozilla.org/embedcomp/prompt-service;1"]
.getService(xpcom.components.interfaces.nsIPromptService)
promptService.alert(this.window, "title", "Hello from Python");
]]>
</script>
</window>

A more recent example showing how to mix scripting languages:

// Some XUL that uses the default scripting language, JS:
<hbox id="language_box">
<button id="but_js" label="click for js"
oncommand="dump('hello from jsn');"/>
</hbox>
// A XUL overlay that uses Python by default:
<overlay ... scripttype="application/x-python">
<hbox id="language_box">
<button id="but_python" label="click for Python"
oncommand="print 'hello from Python'"/>
</hbox>
</overlay>

Python for XUL will be available in the Mozilla 1.9 milestone time frame, when the DOM_AGNOSTIC_BRANCH is landed some time this calendar year for sure, but then only in alpha releases and trunk nightly builds. The next major Firefox release based on the 1.9 milestone (Firefox 1.5 is based on the Mozilla 1.8 milestone) will include Mark’s work — but not a C-Python environment by default.

How Windows end users, and others who may not have Python installed already, will get it along with XUL that requires it, remains a problem to be solved. We have net stub installer technology, and now with Firefox 1.5, a patch-based incremental update system. I predict this problem will be solved quickly as great Python-based XUL extensions to Firefox, and new XUL applications built on Firefox or XULRunner, emerge and gain users.

Here is a good place to say that while I’ve been helping Firefox 1.5 quite a bit lately, and not working enough on JavaScript futures (about which I hoped to blog last month), I am finally clearing much of my schedule to work with colleagues in ECMA TG1, and with Mozilla hackers, to specify and implement a new version of the language. Since JS is not going away, and our demands on it grow daily, it should evolve.

Given evolving JS, why Python? Simple: different programming languages, of different ages, have their strengths, and one of the greatest strength of any solid language is its community. We want to support Python as well as JS for XUL scripting in order to engage a large, creative community of hackers that is mostly disjoint from the web-standards-savvy XUL hackers who are already engaged with Mozilla and Firefox.

We aim to broaden the appeal of our platform in several ways, and supporting Python for XUL is one achievable way to do that, thanks to Mark’s work back in the days when he was employed by Active State, and now that we have him engaged again for the Mozilla Foundation.

/be