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
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.
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
> Zope 3 components that way.
> Zope3-users mailing list
Zope3-users mailing list