Z Object Publishing Environment

Search | Download | Documentation | Resources | Members




Join Zope.org
Log in

Developer Home
Get Involved!
The Fishbowl

 Zope Exits

Zope Newbies

page served by app2

Proposals Table of Contents Last edited on Jan 20, 2001 3:07 pm


Toby Dickenson, tdickenson@geminidataloggers.com

Proposal Status

  1. Please record any feedback as Python20MigrationDiscussion


Python 2.0 has been released. Despite the large jump in version number, this is a fairly conservative upgrade to the Python language and it should not be too difficult to migrate Zope to this new version.

  1. We need to decide on the migration path to 2.0. The priority is getting the next major release of Zope (2.3.0) be safe to use with either 1.5.2 and 2.0. Those things that can not be added safely (given the time limits) should be left to a later revision. For how long do we maintain the 1.5.2 compatabile branch? This primarily depends on the following issues:

  2. Ensure that python 2.0 does not break anything in the Zope core, and does not expose any security holes. We need to look at:

    1. Changes to bytecodes and ASTsx in relation to DTML security and PythonMethodsx (including bytecodehacks)

    2. Ensure that we understand any effects of string methods. (It appears that Zopes new private-by-default rule takes care of security problems)

    3. Any effects of Python 2.0's garbage collection (including performance; there are some parameters to tweak).

    4. Ensure that we understand any affects of unicode objects. (Note that these objects are one of the few that often raise exceptions when converted to an 8-bit string; this exposes several existing bugs in Zope)

  3. Python 2.0 has several new features that would be very useful in Zope.

    1. Support for unicode strings. This is previously covered by the proposal at UnicodeSupport, with an implementation at http://www.zope.org/Members/htrd/wstring. This implementation is now fairly mature, and I intend including this before 2.3.0.

    2. Support for Python 2.0's garbage collection mechanism. Cycles involving ExtensionClassx objects can not yet be broken. (this is a longer term goal)

  4. There is an opportunity to merge some previously forked modules: cPickle, asyncore, expat.

  5. Zope Products will have issues similar to those affecting the Python core.

Proposed Solution

  1. Create a cvs branch that will build out-of-the-box on Python 2.0, to allow product developers to prepare for the transition.

  2. Construct a list of potential problem areas. Eliminate the problems.

  3. Merge the branch bekfore 2.3.0

Risk Factors

  • How best to minimize fragmentation of the Zope community? Will anyone resist ugrading to 2.0?


  • Documentated migration strategy.

  • Security review of identified problem-areas.

  • A branch that builds on 2.0, with support for any new features.

  • Documentation of the interaction with those new features.

View source Python20Migration
Advanced Actions / History
Visitor: Anonymous User
Jump to:
... by pagename prefix or search term.
For a plain search:
Privacy policy       Printable Page       Feedback about Zope.org