David Pratt wrote:
> Hi Shane, Roger and list. Personally, I think there needs to be 
> prioritization myself beginning with the essential packages to zca. zodb 
> would be next. I am not sure about anything else. My feeling is the rest 
> might need to be considered legacy. It would be unrealistic to move 
> forward with these without untangling the dependencies.

Hmm, there is a dependency mess?  Where?

> I have been participating in some discussion with others about merging 
> Pylons, TurboGears and repoze.bfg to focus on a core that python 
> developers can rely upon into the future. I believe this type of merge 
> would be analogous to what has happened with Rails and Merb. It is still 
> conceptual and will be called Pypes if it fully materializes. It would 
> also provide the way forward since the core will support zca 
> development. The framework will run on webob as repoze.bfg does. Webob 
> has become the defacto request for wsgi frameworks.  URL traversal as 
> zope does will be a routing option.  The routing method will be 
> pluggable as will the type of database hookup, etc. Bfg is already doing 
> this. In any case, the discussion has been taking place at 
> http://www.openplans.org/projects/pypefitters/project-home on its 
> mailing list. Much of this came originally from discussion we started on 
> irc. I would expecting more formalization at Pycon leading to a code base.

That sounds interesting, but it's independent of any Python 3 porting 

> In any case, Pypes, if it fully materializes, may be point of departure 
> into the future. Certainly prioritizing the work of getting the most 
> essential essence zope packages more future proof can't hurt. Zope owes 
> considerable credit to Jim Fulton for its vision and success. It is up 
> to Jim to determine the direction of zope. The reality at present 
> though, is that zope is loosing ground among the python community.

Zope 3 the application is losing ground for sure, if it ever had any. 
After all, Zope 2 is a far better application than Zope 3 is.  Zope 2 is 
a better application because we put a lot of work into making it a good 

Zope 3 the stack of components, OTOH, is growing and getting better all 
the time.  The Zope community has become quite good at building 
libraries and we should continue that work.  Zope 3 is a far better 
library than Zope 2 because that's what we've focused on.

> It might be better to unite the python community under a common core that 
> supports zca development and full wsgi.  I think a common core allow 
> developers to focus on better programming and packages than we are 
> seeing today. We do not need repeat the common, but important underlying 
> framework code in my opinion. Further, we all want to use the more 
> difficult bits like security, authentication, sessions, etc with 
> assurance. Interestingly, this discussion came about as there was 
> recognition that we were using many of the same things already -  had 
> more in common than we were different. It has also become increasingly 
> easier to create your own framework.

This all sounds right to me.

> Python itself will be challenged, and perhaps threatened when we are 
> able to access 32, 64 or 1000 core hardware of the future. if there is a 
> solution forthcoming on the GIL we could all wind up programming 
> predominantly in Erlang in 3 - 5 years - who know's for sure. Some 
> transition is already occurring to some extent in this area.

I've always felt like multi-process ZODB, meaning ZEO or RelStorage, is 
a really good answer to the GIL question.  If I have a 64 core box (with 
a terabyte of RAM, presumably) then I'll just run ~64 instances of my 
application, and my application will be able to serve ~64 people at once.


Zope3-users mailing list

Reply via email to