About LWN.net

Guido van Rossum and Jim Fulton on Python, Zope and common purpose

These interviews were conducted at the 2001 O'Reilly Open Source Convention in San Diego. Guido participated by e-mail because he was unable to attend the convention in person. Jim participated in a live interview.

July 26, 2001 Dennis Tenney

Questions posed to Guido van Rossum

When LWN last interviewed you in November 2000 we discussed what was the upcoming move to Digital Creations (now known as Zope). How it's working having the Python group at Zope Corporation?

It's great. Zope is the perfect company for us. We love the product, we love the people. We feel like Goldilocks: it's not too hot, it's not too cold, it's juuuuuuust right. :-)

In what ways has the working relationship with the Zope team influenced the direction of the Python language?

It's subtle. We have access to resources within Zope that augment our expertise in certain areas, just as we do for them. This sometimes leads us to undertake projects that we would otherwise not have been able to do. Also, the needs of a team developing a large application like Zope helps us understand the needs of a certain group of Python users better.

Has working near an enterprise killer app like Zope advanced work on specific Python language features, such as interfaces?

The interfaces work has not been picked up by PythonLabs. However, Python 2.2a1 (released last Friday) shows the first glimpse of "type/class unification", an improvement to the language that will please Zope.

Some folks believe that "Good fences make good neighbors". How are the fences between Zope and PythonLabs, such as the Python Foundation, working so far?

Very well. We have received zero pressure from the Zope side to do things differently that we would like to do them, and much support for our own agenda.

How might concepts from The "new religion" project on zope.org impact Python ?

These are more of a matter of the Zope application architecture and don't affect Python, the language.

Is there anything else you would like to say about Python and Zope?

Zope is Python's killer app, Python is Zope's secret weapon.

Questions posed to Jim Fulton (in person interview)

The "new religion" project on zope.org seeks to address complexity in Zope through cooperating simple components rather than cooperating mix-in classes. LWN's experience to date with Zope's CMF indicates that this approach may significantly reduce the learning curve for new Zope developers.

Do you agree with this characterization?

Absolutely.

The CMF has really pioneered a lot of our thinking about components. We looked very hard last fall, internally, at how can we make Zope much easier for developers. We identified a number of areas. Component architecture and some others related to it were key. Then we looked at what was going on in the CMF and we saw that it led the way.

We've done a lot of thinking since then and have a number of ideas on how to take it further.

How wide-reaching are the potential impacts of these changes on the existing Zope core and applications built on Zope?

We expect existing applications and existing code to keep working. Whatever we do in this area we are going to be very conservative in terms of backward compatability.

But, I think that we are going to make it very attractive to start building applications a different way. I think that the vision of this will be compelling and people will start to move in this direction. However, I think they'll be able to move in a gradual fashion.

While the vision of the new component model envisions very specialized very lean, mean components, I think that there ar definitely possibilities to take the existing heavy objects and gradually either make them into components as they are, so that people can augment them with new functionality, and also to begin to pull them apart a little bit to make it easier for people to replace bits of functionality or even remove functionality that they don't need.

Zope CMF implements concepts from "new religion". Does the rate of application creation for Zope CMF feel substantially faster than for Zope?

I think so, although it is early to tell since CMF has been evolving rapidly itself. People who are familiar with the Zope models can develop pretty quickly. It is not clear whether the CMF is faster now. I think it would be faster over time. It certainly is a lot more flexible so people, when they want to develop new functionality, have a much smaller job to do, so I suppose that makes it faster.

What immediate and long term impact is the new component architecture having on Zope?

It is in the fish bowl now in sort of 'stealth' mode while we try to get our ideas a little bit clearer. We are going to be opening that up iminently. I would have liked to have announced it before the show [2001 O'Reilly Open Source Convention] but I just didn't have time. That project combines bringing a lot of the CMF technology into Zope, making the CMF a core part of Zope, and bringing a lot of the lessons from CMF into Zope. As we do that we are going to implement the new component architecture. That architecture, again, builds on and takes a lot of the component ideas in CMF a step further.

I'm not sure of the exact time frame. I would expect possibly the next version of Zope to reflect this and include many components that are now in the CMF.

The drafts of the "The Zope Book" and "Zope Developer's Guide" along with the "new religion" concepts and CMF all help make Zope more accessible for a wider range of developers.

Wasn't better access for developers a strategic goal that Zope, then Digital Creations, was publicizing at last year's O'Reilly Open Source Conference ?

Yes it was. We recognized last year that we had a confusing message. The software we developed that became Zope, we developed to solve content management problems. It happened that in order to solve those problems, we built an application server. A lot of people use that application server. By having people use that server it made our content management story better. But a lot of our documentation in the past was very much geared towards content managers, not developers.

Last year we decided to recognize those two separate audiences. There has been a lot of work in Zope focused on the developer as a distinct customer. The CMF has been very focused on the content manager and solving the content manager's problems. As the CMF comes back into Zope we're going to be very careful not to repeat that sort of error of the past by making sure we continue to recognize those distinct audiences.

How much progress have you made toward the goal of making Zope more accessible to developers over the last year?

I think quite a bit, mostly in the area of documentation. The CMF is also a big step forward.

Our vision of who a developer is has broadened a little bit. We recognize that the people who build templates are also developers and that templates are really code.

So especially if you encompass that, between the new ideas that came out in the CMF, which have helped to move us forward quite a bit, and the new template language, page templates, I think we've done a lot. We've also made lots of improvements in the interface, and paid attention to areas such as improved catalog performance. Now the pluggability of the catalog makes it much more extensible.

I think we've made quite a bit of progress, there's still quite a bit to do.

On that to-do list, what are some of the things you'd like to mention?

I think page templates are really exciting. Especially for site developers, they allow the person who creates web designs or page designs to finally cooperate with the programmer.

In all traditional templating languages there's a tug of war between the person who does the graphical design and the programmer. Once the graphical designer does their job, does the initial mock-up, the programmer destroys their work [by inserting dynamic content]. It is very difficult for them to collaborate at that point.

With page templates we've made it truly possible for them to collaborate in an ongoing fashion.

Certainly the most important thing that has happened this year for developers has been the CMF. The ideas in the CMF and the progress that we've made there have been extremely important.

Looking into the next year, what would you guess might be your most important goal for Zope development in the next twelve months?

If I get what I want, it will be the component architecture and a new model of development. The new development model integrates file system based development and through the web development.

A sort of problem with Zope right now is that we support both traditional development, as software modules on the server, and development through the web. While the big ideas for both are the same, there are an awful lot of details that are different. That makes the transition between the two very difficult.

There are a lot of things developers want on the file system that they can't get through the web. Things like the ability to use the tools you're familiar with like cvs, find, and grep. Editors aren't so much of a problem thanks to WebDAV and ftp.

One of the things we're looking at is a model of synchronization between the code in the database and code in the file system, so semantically, there are no differences any more. That's going to be really exciting. I think it's going to improve staging, testing and deployment of Zope applications. It will also substantially improve development of Zope applications. We're going to remove that big sort of difference between the two modes of development to make it easy for people to flow between the two. It will allow people to collaborate when some are working through the file system and some through the web. They'll be able to synchronize their work so that it is kind of one model.

Removing that difference, between the development modes and the component architecture, are the two things that, at a deep level, I'd like to see.

With PythonLabs taking over the Zope object data base (ZODB), that is going allow us to make a lot of progress there. Both in terms of new advanced ideas of storages and replicated storage. Replicated storage is going to be extremely important for some users of Zope, as well as opening up the persistence model so that we can do object relational integration, or perhaps integrate with other object databases and still keep a lot of the benefits in terms of the persistence model that we have in ZODB.

At the application level, there are a lot of ideas that we have for content management. Much more sophisticated versioning models, better integration with desktop tools, and widening the audience of the people who manage content with Zope are certainly a lot of the things we'd like to do.

Replication is certainly one of the thornier problems that traditional databases have dealt with. Some folks believe that even the large commercial firms don't have very usable solutions. Do you know how the approach to replication taken by PythonLabs will work?

We worked with a PhD at George Mason about a while ago, to come up with an algorithms using quorum based replications. That looks like it is going to be successful. It is going to provide some very nice features. I'm pretty comfortable with the approach that we're taking. It's going to provide a high degree of availability. It is a little bit of an open question what the performance implications are going to be. We're very interested to get further along and see how that pans out. It looks very promising. I'm very optimistic about it.

Thank you very much.