The Hand of FuManChu

Guido van Rossum recently wrote:

Python, in its design philosophy, tries hard not to be a framework. (This sets it apart from Java, which is hostile to non-Java code.) Python tries to be helpful when you want to solve part of your problem using a different tool. It tries to work well even if Python is only a small part of your total solution. It tries to be agnostic of platform-specific frameworks, optionally working with them (e.g. fork and pipes on Unix) but not depending or relying on them. Even threads are quite optional to Python.

Oddly enough, this is how I feel about CherryPy, that it tries hard not to be a framework. It tries to be helpful, recognizing that it's most likely only part of your solution. It tries to be agnostic of templating and persistence systems, and has little to say about markup languages, content-types, site architecture, or RPC formats.

Guido was responding to Phillip J. Eby, who wrote:

A Pythonic framework shouldn't load you down with new management burdens and keep you from using other frameworks. It should make life easier, and make your code more interoperable, not less. Indeed, I've pretty much come to agreement with the part of the Python developer community that has says Frameworks Are Evil.

Not wanting to be Evil, I've tried to make CherryPy 2.1 a system which doesn't load you down with new management burdens. Instead, it exposes the functionality of HTTP by presenting it in a Pythonic way. I and many others think it makes life easier—CherryPy appears to have an underscore-shaped learning curve. And as for interoperability, CherryPy was one of the first Python web-application servers to grow a WSGI interface.

I suppose that CherryPy will always have to bear the moniker of "framework", if only because it calls your code, instead of the other way around. But let's keep it a Pythonic framework as long as we can.

Link: http://www.turbogears.org/docs/api/cherrypy-module.html

Thanks, Kevin! Can we get a new one when CP 2.1 final is released? Please?

http://cherrypy.attardi.org/range/39744/39772

And there was much rejoicing.

Ryan (my fellow IT worker), Chris (his girlfriend), and I took a well-deserved five days and went backpacking on the Pine Ridge Trail in the Los Padres National Forest (Ventana Wilderness).

On Thursday, we left San Diego at 1:00 AM so that we could get a full day's hiking in. It's over 10 miles to Sykes Camp, plenty of time to reacquaint oneself with California's gorgeous trees:

Once we arrived at Sykes, we partook of the hot springs. Here's Chris standing in a very small one:

The next day, we didn't move camp—just wandered up the Big Sur River in search of cool things. We found quite a lot of them, but I don't have any pictures to show you, and I probably would hide them from you if I had any. No sense making such a fantastic place too popular. Ryan found a turtle, maybe this pic will tide you over:

Saturday, we decided to hike on over to Cienega Camp, which sits above the North Fork of the Big Sur River. Here's a panorama of the North Fork valley:

That day...wasn't the best. Cienega is six miles away from Sykes, but the last three miles are a tough fight through thick brush. Wear pants if you ever try it. I didn't. Once we got there, we found Cienega to be little more than a wide spot in the trail, so we turned around and backtracked the three miles to Redwood Creek Camp, which was much nicer:

In the second picture, I hope you can see that the forest floor is a long way down. The "small" trees in the gaps are the same size as the near trees, just much further away.

Sunday, we continued our return trip, this time passing Sykes and stopping for the night at Barlow Flats Camp. Once there, Ryan and I decided to wade down the Big Sur River. I wanted to see the point where Logwood Creek fed out into the river, and once there, I cajoled Ryan into scrambling up its whole length until it rejoined the trail. Sure glad we did; this waterfall was 20 feet high, and fed into a pool at least 20 feet deep:

This is only one of the many cool waterfalls we navigated on our way up.

In Barlow Flats Camp, unlike the other camps, the nearly-full moon was visible, and astoundingly bright. I spent a lot of time trying to get the perfect moon shots:

On Monday, we headed back to the parking lot, having traveled about 40 miles in all. Here's a last pic of the trail which I particularly liked, due to its spiral structure:

We left the park about 1:30 PM, stopped for pizza in Monterey, and tried to head home. After road closures, rain, flash floods, accidents, wrong turns, and too many leftover snacks, we hit San Diego about midnight! But I got a neat picture of the moon over Tehachapi. Note that, for all of these moon pictures, I used anywhere from a 4 to 15 second exposure, and never had a tripod—just me holding the camera as steady as I could.

To Dan, I just have to say, we should have gone to Los Padres instead of Kern last month.

I can't seem to finish or maintain anything lately. I never can, but recently it's been more acute. Maybe it has to do with the pending release of CherryPy, which means we're in "feature freeze" mode; I miss writing the sweeping redesigns that I was able to shove into 2.1 before the beta.

But it's apparent in other areas, as well. I have about 80 hours of video transfer to DVD to do for various friends (and some personal projects). I haven't touched any of them in months. I also have a company to officially close, which is moving at a glacial pace. I've got a bunch of papers in triplicate that I need to mail off to the State, but can't seem to work up the drive to buy a large envelope for the purpose.

But then, having everything "done" is a much worse state. Maybe I should count my busy blessings.

This is just a fun panoramic shot I took from Eunice's driveway, showing the view of the whole El Cajon valley from her house (keep in mind that it's a distorted panorama; the extreme edges of the pic are actually in a line with each other, not at right angles as it might appear).

You might not have noticed, if you don't check every day, but this blog has moved recently. It was hosted at amorhq.net (owned by Amor Ministries), but now it's at aminus.org (owned by yours truly). Please update your aggregators, feedlists, links, and bookmarks.

Dejavu, my pure-Python ORM, has a new Trac home at http://projects.amor.org/dejavu. As always, it's open to the public to download, use, or develop. It could use another contributor or two, and the snazzy new Trac front-end should help that immensely.

Just to remind you about the parts of Dejavu I think are cool:

1. It completely hides the storage layer, so your code need never know you're using a database. It supports MS Access, MS SQL Server, PostgreSQL, MySQL, SQLite, and shelve, all transparently.
2. Simple queries use simple syntax: Panda = sandbox.unit(zoo.Animal, Species='Ailurpoda', Name='Mei'). More powerful queries use the logic.Expression object and pure Python (no code strings!):

   red_filter = logic.Expression(lambda x: x.color == 'red')
   RedAnimals = sandbox.recall(zoo.Animal, red_filter)
   

3. Dejavu has been designed from the ground up to be used in a multithreaded environment.
4. New database adapters are easy to develop using the `db` module. The PostgreSQL module, for example, is 100 lines of code.
5. Model-layer Units are clean and easy, using modern, built-in Python types. They are also extendable to custom property classes and custom types:

   from dejavu import Unit, UnitProperty
   
   class MissionTrip(dejavu.Unit):
       """A Mission Trip experience."""
       
       DirectoryID = TripGroupProperty(int, index=True)
       FirstDate = NotifyProperty(datetime.date)
       GroupName = UnitProperty()
       LastDate = NotifyProperty(datetime.date)
       AmountDue = UnitProperty(fixedpoint.FixedPoint)
   

6. Persistent query-engines and analysis tools are included.

Dave Warnock muses:

I am not about to argue that [TurboGears and Subway] should merge, instead I feel they can improve most by making sure that they each stay thin putting all the improvements they can back into the components eg CherryPy (which they both have been doing) and into the deployment elements (setuptools and paste).

That's a good point, and I think it's at the heart of what CherryPy is trying to be: non-fattening. So there's definitely going to be some pushback from CherryPy itself trying to "stay thin".

I often say that CherryPy is not a "web framework"; it is an "HTTP framework". That is, it doesn't try to provide tools for every facet of web development. Instead, it concentrates on wrapping HTTP up in a Pythonic way.

IMO, working to stay thin is an important factor in getting CherryPy "more exercise": it gets used in more meta/mega-frameworks like Subway and TurboGears precisely because it hasn't gobbled up every good idea, just because it's web-related, or even just because it's Python. For example, CherryPy 2.1 is deprecating the Aspect module that was in 2.0, because it isn't related to the HTTP-focus of CherryPy.

David goes on:

Another project that is the next level down from these frameworks but that is also moving fast is Quixote, I feel the differences between Quixote and CherryPy are also becoming smaller (shown by the recent blog posts on Python Web Controllers). Whether they could ever merge is a different matter. Probably not possible (or even desireable) for the moment.

I would have to agree. There's a decisive difference in architectural style between CherryPy and Quixote. That doesn't mean there aren't components that are common to each, and there are certainly some which are unique to each which deserve to be ported! If the Quixote coders are willing to give up all the method names starting with set_ and get_ we're ready to have a conversation about merging.

This is what I spent my weekend working on (among other things). It's the "autoreload" functionality in CherryPy. It was so complicated that it took me 15 minutes to understand it again, anytime I got distracted; having the diagram makes it quicker, at least. They say the human brain can handle about 7 things simultaneously, and this snake-pit takes about 4 at a minimum: