In this context, P'u is a project aiming to bring Zope-style development at large to ubiquitous platforms like CLR/Mono/.NET (and Jython/J2EE)

Five brought Zope3 to Zope2. P'u could take it further.

A lot of the motivation for this project is the dichotomy between my love of Python, lexically, and my extreme hatred for certain aspects of the cPython implementation, namely the Global Interpreter Lock. I thought I would write a threadsafe garbage collection implementation for Python, or even a front-end for GCC, and I may! It turns out, however, that the Common Language Runtime, CLR, platform specifically addresses this sort of concern by giving us best-of-breed solutions to simple computing problems like garbage collection for free. IronPython puts this within reach of Zope.

The crux of Zope3-style development is the zope.interface package, which for all intents and purposes, insofar as I can tell, could easily be merged with and/or completely replaced by PEAK.Protocols / PyProtocols, which is also compatible with twisted-style interfaces, and is designed specifically to adapt to any interface implementation. I think that by bridging interface implementations in Java/Jython, C#/IronPython/PyPy, and Python/Zope, that some great goals can be reached.

IMO, the most important gift that Zope has given us are strong core components, unique patterns like the all powerful zope.publisher. As Zope applications and Zope itself become more aspect-oriented, it's natural that components which are redone perhaps gratuitously in Zope, e.g. ZServer, become less necessary. There have been a number of attempts at making "Zope" run somewhere like mod_python, more natively in twisted, and probably many other ways I don't know about. They all seem to have floundered, I've never seen any of them working, maybe in some cases they just need to be updated, but it would be nice to free Zope of ZServer as a core component altogether, provide something similar via a native twistd pickle or xml config, adhere strictly to WSGI on both ends, and use that forced ubiquity to explore things like running in mod_python or in Jython, mod_mono, IIS, etc..

I know a lot of this work is underway and simply am taking the opportunity to ask the simple question: How much cPython-dependent code is in Zope, can be moved out of Zope, and possibly even moved into something like Mono. Does Mono have a reactor like twisted's? I don't know. Will it do everything Python 3k will? I don't know, but it's not the year 3000 yet and I'm tired of ZServer hanging and my sysadmins not understanding after months and pages of detailed documentation how everything works, having to run on separate servers, delaying projects, etc..

In the spirit of Py3k, perhaps this could be thought of as "Plope 2050".

Of course, I'd like to see Plone, Archetypes, etc.. implemented in some P'u-ish fashion, in order to address client interop and graceful migration concerns. Further, this could bring about realistic possibilities of tools built by the Python, Zope, and Plone communities being adopted and contributed to by other application developers.

As great as Python is, as great as Zope3 and even Zope2 can be, I think it would be blind to ignore this oncoming trend in computer science, and in fact it may be a disservice to the computing community and all its' users:

"A lot of time is still wasted by desktop developers laboring with their C programs, and if, in fact, any higher level language has taken a hold, it's Python. (On my Ubuntu desktop, 168 packages depend on Python's GTK 2 support, as opposed to 44 on Mono's Gtk# 2)." ( http://www.onlamp.com/pub/a/onlamp/2007/08/09/mono-a-progress-report.html )

There's no question that Python is a great language, but with P'u and similar initiatives, those 168 dependencies could be satisfied by the same package as the latter 44, lowering the maintenance requirement.

UPDATE:

The latest Mono has a Windows.Forms implementation which is modular based on platform, includes Quartz support for MacOSX for instance, and may begin to eclipse GTK# as the gui tool of choice on Mono  I think it might be possible to graft a web ui onto this - XForms, anyone?

Additionally, I continued investigating the implications of doing some of the things Zope and Plone does, and of running existing Python on Mono in general.  For now, a few things are notable:

• Whether using IronPython or PyPy-CLI, today, python classes, packages, libraries, methods, whatever are not accessible to other languages on CLI, largely due to python's highly dynamic nature, which is why we love it.
• Distutils and Setuptools do not work on Mono / .NET, for what quickly become some very obvious reasons.  One could draw the connection between current python eggs and Mono / .NET Assemblies, but IronPython and PyPy do not compile Python packages into assemblies, they run as interactive interpreters.  Maybe namespaces like Plone and Zope could be flattened from cPython installations into Iron/PyPy-ready distributions, but this sounds like a pain.  This is important because *everything* in Python today is moving toward installing via setuptools from cheeseshop or somesuch, and distutils has been used for a long time, but I don't think it's not insurmountable.
  
• CarbonPython, a project from the author of PyPy's CLI backend, allows to compile RPython programs into .NET / Mono assemblies.  This could open some doors, but a large Python codebase like Zope and Plone are likely to have a ways to go to work as RPython, and CarbonPython packages can't call each other.  Maybe it's possible, at least for proof-of-concept purposes, to get a large pile of code working as one assembly, but this would be very awkward.
  

More to come..