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 effort. > 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 application. 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. Shane _______________________________________________ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
