This article is out of date; Pylons 1.0 was released in 2010.

Latest release: Pylons 0.9.7

Released: February 2009

What's new in Pylons 0.9.7 lists the changes that have been implemented and how to make your app compatible.

Planned changes

Pylons 0.10

Forecast: by end of 2009?

• This is mainly an internal cleanup. Few new features are added.

• Deprecate pylons.c, pylons.g, and pylons.buffet. These have been disrecommended since 0.9.7.

• Drop Python 2.3 support. (Note: Python 2.4 is already the minimum version for WebHelpers 0.6, and thus an indirect requirement for Pylons 0.9.7.)

• WebHelpers: The Pylons dependency will remain "WebHelpers>=0.6.4". This will install version 1.x by default, but users can easily downgrade to 0.6.4 if using obsolete features such as the Rails helpers.

Pylons 1.0

Forecast: simultaneous with 0.10

• New cache system in app_globals.cache. Replaces pylons.cache, @beaker_cache, and the CacheMiddleware.

• Remove deprecated pre-0.9.7 features. Older applications will have to be modified to run on Pylons 1.0:
  • routes.url_for -> pylons.url
  • Buffet templating -> render_mako, render_genshi, etc.
  • pylons.c -> pylons.tmpl_context
  • pylons.g -> pylons.app_globals
  • Others listed under "1.0" in Pylons CHANGELOG.

• config["pylons.strict_tmpl_context"] defaults to True and replaces config["pylons.strict_c"]. This raises AttributeError when reading a nonexistent 'c' attribute in templates. The previous default (False) returns "" for nonexistent attributes.

• Finish non-technical tasks: website, wiki, logo, marketing.

Pylons 1.1

Forecast: mid 2010?

• Replace @validate with something more robust. Bug #405

• FormEncode: a better manual.

• Python 3 version, if a Python 3-compatible version of WSGI is available, and if all Pylons dependencies have been ported. WSGI is being held back by string/Unicode issues, what to do about unknown encodings in HTTP headers, whether to simplify the protocol, and whether to support asynchronous servers (by having a NotReady token that can be passed through the response data).

• Routes: additional .resource method(s) to create different URL structures for non-Atom-compatible resources. Additional .connnect method with a more deterministic syntax. Failure routes. Better introspection.

Pylons 2.0

Forecast: end of 2010?

• Migrate to Marco meta-framework (described below).

• Possibly move request/response/session globals to controller instance, to eliminate StackedObjectProxy's. (This would require use of 'self' in actions, and passing the objects to functions that need them.)

Marco (formerly Pypes)

Forecast: alpha in 2010

Some Pylons, TurboGears, and repoze.BFG developers have been working on a next-generation meta-framework, upon which all three frameworks and others could run on. So far a prototype using zope.component has been built, and a subset of Pylons has been ported to it. There will be an announcement on the Pylons list when the code is stable enough to try out. The project was originally named Pypes (in honor of Unix pipes, which join components together), but was renamed Marco (as in Polo) because the other name was already taken.

The advantage of this approach is it brings Pylons' and Paste's modularity to a new level. Marco will allow easier nesting of applications than Pylons currently has. It will scale up and down, into a simple one-module application for simple sites, up to a complex application with routing like Pylons is. It will also make it easier to interoperate with other web software and frameworks, written by a wider variety of Python developers.

If all goes well, this might be "Pylons 2.0" someday. Compatibility modules will be provided for Pylons 1.x/0.10/0.9.7 applications. You may have to replace the INI file with something else, and perhaps make a change or two in environment.py/middleware.py, but the goal is not to affect controllers, templates, or routing.

Marco configuration is two-level. One is equivalent to the regular Pylons configuration; the other is a framework-building level of interest mainly to framework developers. Either or both of these may be in XML, YAML, INI, Python, or another format, depending on what becomes feasable. The goal is to allow multiple configuration formats.

Pylons-level configuration can be further subdivided into application configuration and deployment configuration. Generally, application settings are identical in all deployments, and are set by the programmer in environment.py. Deployment settings are set by the sysadmin in the INI file. Pylons applications have not always made a distinction between the two, but some Marco developers feel strongly about separating them, so the config system will provide a way to do so. That doesn't mean you'll have to use that config system, however.

If Marco does go into production someday, Pylons 1.x will remain actively developed for at least a year after that, and bugfix/security support will continue for at least a few years.

User wishlist

What else would you like to see in Pylons?

• To many users the appeal of Pylons is its small, lightweight explicitness and the further we move away from that the more we come Just Another Web Framework and the world doesn't need another Rails. This is especially true now the TG folkes are likely to provide high level functionality on top of Pylons - we don't need to do the same too. Our goal for 0.9.7 should be to have the Pylons code itself so explict that an experienced user can work out for themselves what is going on by looking at their project code. This might mean creating some more docs to expalin things like how the RegistryManager works to setup the globals, describing how pylons.config is set up or explaining the controller class naming convention within controllers. It might mean starting the work towards removing the need for PylonsApp() early before the 1.0 release. JG.

• Moving the registry manager setup code to right after the registry manager is setup is an essential so that the Pylons globals can be used in middleware. Maybe change registry manager to accept some arguments so it can actually set them up itself as part of its initialisation.

• Replace all the paster, nose and any other commands with a "pylons" command line tool which then calls the other tools. Reasoning: presents a more consistent Pylons interface to what is going on but more importantly if you are using Buildout (which I want to recommend as the preferred deployment method for 0.9.7 - I've started a book chapter about it) you currently need to manually specify both PasteScript and Nose as eggs to get their scripts installed in the bin directory. It would be nice to just specify the Pylons egg and get all the required functionality via a pylons command. Also it means that if other libraries change their command line APIs or functionality, we have the oppurtunity to change the pylons program to provide an API that provides the same arguments to the user but calls the updated program with the new arguments it expects. JG. Stop using the word "template" for an application template; it conflicts with "template" meaning a view template. Thus replace "paster create --template=pylons" with "pylons create". MO

• New merge functionality for template upgrades. While project updates aren't frequent, there's no reason they have to be as painful as they are now for large files. With a 3-way merge, the process should be much smoother, especially with kdiff or a merge tool available. This will require an update to Paste to store original template files in a hidden fashion, so that the new template file has a prior comparison point in addition to the user-modified version.