[PEAK] PEAK Status Report
Phillip J. Eby
pje at telecommunity.com
Sun Jun 24 01:48:34 EDT 2007
This is just a quick status update, because there have been a few
private inquiries being made recently.
The short version: PEAK is dead, long live PEAK projects. :)
While the core PEAK toolkit for AOP, MDA, and other TLA's
(three-letter acronyms) hasn't been released or changed much in the
last 2 or three years, some of the non-core tools have really taken off.
WSGI, for example, which was originally based on a peak.web
innovation, has been positively flourishing. Setuptools, originally
created to support installing PEAK, is likewise widespread: each new
release gets thousands of downloads.
Some other PEAK projects have gotten some small amounts of
traction. RuleDispatch is in use by TurboGears, for example. Many
of our spun-off utility packages like Importing, DecoratorTools, and
SymbolType have also seen some downloads, although wsgiref downloads
outnumber the best of these by a factor of around 10-to-1.
The PEAK Core and APIs are seeing little activity, however. In the
last couple of years, I've done little besides adding new SQL
drivers, mostly for Windows and ODBC, to help with little projects
I've needed to do here and there.
And to be honest, I don't expect to do any major revamping of the
Core or API layers. I no longer have significant projects or clients
that depend on them, and I saw years ago that there were many smaller
and more elegant frameworks hiding inside the core, yearning to break free.
So instead of focusing on bringing the Python community to PEAK, I've
focused instead of bringing PEAK's innovations to the Python
community. WSGI and setuptools are the best examples of the success
of that approach (both originated in PEAK and were later spun off),
but what's not as widely known-about are the things I've had a hand
in for Python 2.5.
Python 2.5 contains two major features that are relevant for the
future of PEAK: the "with" statement and coroutines.
Coroutine support, which I implemented and co-authored the PEP for,
was specifically designed to eliminate the syntactic messiness of
peak.events. The "with" statement, on the other hand, is going to
substitute for 90% of the component-context stuff that happens in
PEAK today, while making simple applications and scripts a lot
simpler: no need to create component roots, wrap scripts with special
tools, or create command classes just to do something simple.
So, what will happen to the PEAK core and APIs? Well, I'm still
supporting them, because I still use them. My blog is published
using a PEAK-based tool called CityKid, which wraps MS Access via
peak.storage, to pull posts out of my CityDesk database. Back in
December, I wrote a bunch of data migration tools to upgrade my
wife's store's management software from an Access-based system to an
SQL Server-based one.
So I haven't abandoned the core and APIs. Unfortunately, none of
these projects has been so big that it's given me the luxury of
writing the new APIs I'd rather be using. So PEAK abides. Heck, I
may even make another release of it at some point!
But the future of PEAK will be built on Contextual, PEAK-Rules, and
Trellis. When they are in their final form, they'll be radically
simpler substitutes for huge chunks of the old PEAK core, mainly
binding, config, events, protocols and dispatch.
Today, PEAK-Rules got enough of a logic engine to be able to
"understand" or "reason" about rules of equivalent power to those of
RuleDispatch. It cannot actually *interpret* those rules, but based
on current progress I expect PEAK-Rules to be a compelling
replacement for RuleDispatch within the next month. It lacks a user
guide at the moment, but its internal technical documentation and
tests are unparalleled in the entire PEAK empire.
Part of being a "compelling replacement" is that I plan to provide
peak.rules.protocols and peak.rules.dispatch modules, that will
provide syntactic sugar for people porting code from PyProtocols and
RuleDispatch, so they can use the APIs they're familiar with. This
will also be important for actually switching the PEAK core to using
peak.rules; I don't want to have to do a massive search-and-replace
just to find out whether stuff will actually work, and I imagine most
RuleDispatch users won't want to, either. :)
The first release(s) will probably not have any Pyrex or C code,
either. PEAK-Rules attempts to leverage bytecode generation and
improved algorithms in order to match or exceed the amortized
performance of RuleDispatch at function-call time. It is possible
and perhaps even likely that rule definition speed and first-call
speed will decrease, however. I will be interested in hearing from
those who have applications where dispatch time affects performance
in a measurable way, so that the effects can be tested.
The ultimate plan here is to end-of-life the development of
PyProtocols and RuleDispatch, which has been the case in fact for
some time now anyway. But I'm stuck with them at the moment because
the PEAK core is dependent on them. Once the dependency on these two
packages is gone from the core, I'll probably start cutting a final
0.5 release series of the PEAK core. 0.6, if it ever happens, will
be a fairly radical restructuring based on Contextual and Trellis.
Contextual is almost ready for prime time. The engine is there, and
most of the creature comforts; the main big feature remaining is a
configuration file parser similar to the one the PEAK core has
now. Once that's added, Contextual will be a solid replacement for
the bulk of both peak.binding and peak.config, at the heart of PEAK's
Contextual throws out the old ideas (stolen from Zope 3's component
architecture around 5 years ago!) of acquired utilities and services
looked up by interfaces and property names. Instead, it makes
services look like singletons, and replaces names with lazy
imports. The result looks a lot like the old PEAK, except for all
the annoying pieces you don't need any more. Since you don't need to
start with a component to access other components, there's no tricky
bootstrapping of a configuration root, and you don't need lookup
strategies and attribute bindings just to get things you need.
Contextual is also designed to support what I think is the Next Big
Thing in Python: event-driven programming, *without* callbacks.
The state of the Trellis package at the moment is complete
crap. It's barely enough of a prototype to figure out how the thing
*should* have been written. I put it on hold quite some time ago to
wait for Contextual to mature, because I wound up inventing things in
Trellis that should've been in Contextual. After Contextual's docs
are finished and it gets configuration files, I'll eventually work on
the Trellis again.
What Trellis does and how it works are a bit difficult to
explain. There's some info in a previous post here:
But what Trellis is *for* is relatively easy to explain: it's for
safely and transparently updating things in response to changes. An
event-driven system that truly doesn't suck, it's like a spreadsheet
for code. A cross between peak.events and PyCells, but built on
Contextual and still able to work with -- or without -- Twisted.
I think it will end up doing for Twisted and event-driven programming
what setuptools has done for the CheeseShop and distutils, or WSGI
has done for web servers, frameworks and libraries. That is, made
development a lot more accessible and composable, for a lot more people.
Big words, I know, but this is not exactly the first time I've set
out to change the Python world. :)
Trellis should have something worth experimenting with before the end
of '07, maybe a lot sooner.
The Future Outlook
My first commitment on time is always to my paying clients, such as
OSAF. And my first commitment on my *spare* time is to my
self-improvement/coaching business. As a result, I've done next to
nothing on the coding of PEAK-Rules for almost a *whole year* -- even
though the most recent big leap forward needed only 20-30 hours of
work, spread over the last few weeks of nights and weekends.
Also competing for my little spare time are such things as sleep,
exercise, and so forth, not to mention things like Python-3000 PEPs
and all that. The competition for my writing and coding time is
intense, to say the least.
Currently, my coaching business is about 15-20% of the way to being
able to replace my software consulting income -- which would leave
most of my days free to code whatever I like. However, even if it
were just 50% of the way there, I could afford to say, take a week
off every month from client work and just code like the devil.
There is also some possibility that OSAF will need -- and thus put
some of my hours towards -- some aspects of development on the above
projects. However, it is a fairly remote possibility at the moment,
so I'm not counting on it.
Nonetheless, I'm pretty optimistic. My self-improvement business has
taught me how to make a lot more out of the spare time I *do* have,
and to keep track of more things at once. (And as you might imagine,
I highly recommend it!)
More information about the PEAK