[PEAK] PEAK Status Report

[Phillip J. Eby]

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
----------

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.


PEAK-Rules
----------

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
----------

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 
component architecture.

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.


Trellis
-------

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:

http://www.eby-sarna.com/pipermail/peak/2006-May/002544.html

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!)