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