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. I have stopped using much of zope for this rationale alone. It was impractical to wade into it for a variety of reasons. I had raised the issue of Python 3K on the list quite some time ago and it has been on my mind for quite a while.
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. 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. 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. 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. Regards, David On Jan 15, 2009, at 1:28 PM, Shane Hathaway wrote: > Roger Ineichen wrote: >> I didn't say we should start the refactoring today or tomrrow. >> But it whould be a good idea to talk about this painfull piece >> of work. My personal wish is to see some dicussion about how >> we do it instead of if we should do it now or later. > > The best thing to do now is to make as much code as possible work with > the 2to3 conversion utility. I am hopeful that we can cover nearly > all > Zope 3 components that way. > > Shane > _______________________________________________ > Zope3-users mailing list > Zope3email@example.com > http://mail.zope.org/mailman/listinfo/zope3-users _______________________________________________ Zope3-users mailing list Zope3firstname.lastname@example.org http://mail.zope.org/mailman/listinfo/zope3-users