-
Notifications
You must be signed in to change notification settings - Fork 0
Python 3 Porting
The Pyramid master branch runs on Python 3.2 (as of September 25, 2011). The result will eventually be released as Pyramid 1.3.X. Thanks to Joe Dallago and Joel Bohman, our GSOC 2011 students who helped with porting efforts.
Pyramid's Python 3 compatibility does not require a "translation" (via 2to3 or 3to2) but instead uses a single codebase that runs under 2 and 3. Python 3 compatible releases of all core and most scaffolding dependencies have been made to PyPI.
Pyramid 1.3 will run under Python 2.6, 2.7, and 3.2. It will no longer support Python 2.5 in any form, and does not support any version of Python 3.0 or 3.1.
Paste nor PasteScript (which were dependencies of Pyramid 1.0+) have not been ported to Python 3, and likely won't be. As a result, we've replaced PasteScript commands with Pyramid-specific analogues. Previously you created a Pyramid application like so:
paster create -t pyramid_starter foo
Now you create it like so (scaffolding names and flags have also changed):
pcreate -s starter foo
We've replaced use of the Paste httpserver with the wsgiref server in the scaffolds, so once you create a project from a scaffold, its "development.ini" will have the following line:
use = egg:pyramid#wsgref
Instead of:
use = egg:Paste#httpserver
Note that this is purely a default to make it possible to use the same scaffolding under Python 2 and Python 3; people running Pyramid under Python 2 can still manually install Paste and use the Paste httpserver by replacing the former line with the latter.
Since we no longer depend on PasteScript, instead of running a Pyramid project created via a scaffold using "paster serve", you now must use the "pserve" command:
pserve development.ini
Using "pserve" and "pcreate" will work under both Python 2 and Python 3. The ini configuration file format has not changed. Python 2 users can install PasteScript manually and use "paster serve" and "paster create" instead if they like.
- ZODB (http://svn.zope.org/ZODB/trunk/; likely won't be ported by us, too large, just maybe keep an eye on other efforts; for example https://mail.zope.org/pipermail/zodb-dev/2011-September/014363.html)
- Chameleon (already worked under Py2.5 and Py3.2)
- Mako (already worked under Py2.4-Py3.2)
- MarkupSafe (already worked under Py2.4-Py3.2)
- translationstring (released as 0.4)
- venusian (released as 1.0a1)
- zope.interface (released as 3.6.0)
- repoze.lru (released as 0.4)
- zope.deprecation (released as 3.5.0)
- WebTest (released as 1.3.1)
- WebOb (released as 1.2a1)
- PasteDeploy (released as 1.5.0)
- transaction (released as 1.2.0)
- zope.sqlalchemy (released as 0.7)
- pyramid_exclog (released as 0.5).
- pyramid_tm (released as 0.3)
- pyramid_jinja2 (released as 1.2)
- pyramid_debugtoolbar (released as 0.9.4)
- pyramid_zcml (released as 0.8)
- zope.component (jbohman factored out "zope.registry" and placed it in zope SVN; also see https://mail.zope.org/pipermail/zope-dev/2011-August/043340.html, this code was later moved to zope.interface in version 3.8.0, removed z.component dep in Pyramid 1.3)
- zope.configuration (removed core dependency on this in Pyramid 1.2a5+; still dep'ed on by pyramid_zcml)
- zope.i18nmessageid (transitive dep of zope.configuration; removed z.config dep in Pyramid 1.2a5+)
- zope.schema (transitive dep of zope.configuration; removed z.config dep in Pyramid 1.2a5+)
- zope.event (transitive dep of zope.component, removed zope.component dep in Pyramid 1.3)
Related Zope package info: http://permalink.gmane.org/gmane.comp.web.zope.devel/26373
-
Review documentation with an eye on the WebOb (1.2) and Pyramid (1.3) changelogs.
-
Remove pyramid_zodb scaffold and put into a separate package (ZODB wont work under Python 3)?
-
Unrelated to porting but may want to take the opportunity to do it anyway; put Chameleon and Mako bindings into separately installable packages and have scaffolding rely on them instead of the core.
-
Figure out which default WSGI server to use instead of
wsgiref. The cherrypy server would be great but it lacks tests independent of the CherryPy framework and it's not distributed separately from the rest of the CherryPy framework. If we go with wsgiref, we lose the ability to advise people to put their apps straight into production behind a proxy, as we used to with paste.httpserver; wsgiref makes no performance or security claims (except against).