Planned changes

1.0

Forecast: late 2008 (Will have several release candidates).

Drop backward compatibility with versions of Pylons older than the latest.
Possible internal refactoring and dependency changes.
Finish non-technical tasks: website, wiki, logo, marketing.

Python 3 plans

After 1.0 is released we'll port it to Python 3. Then we'll have to decide whether to continue development in Python 3 only, or to backport new features to Python 2. The Python 2 version will remain supported for security fixes and bugfixes in any case.

0.9.8

Forcast: mid 2008

Routes 2. Routes is being redesigned to be more deterministic and foolproof. The API is here: Routes 2 Spec. Route creation syntax will change. Redirect routes and failure routes will be added. url_for will be replaced by pylons.url, a StackedObjectProxy with several methods. It will be visible in the template namespace as url. A pylons.legacy_url will also be provided with the same API as url_for. Existing applications with lots of url_for calls can put "from pylons import legacy_url as url_for" to get the traditional {{h.url_for()} behavior.

WebHelpers: additional helpers.

Refactor @validate so parts of its functionality can be called inside a controller action.

0.9.7

Forecast: April 2008.

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

User wishlist

What else would you like to see in Pylons?

Install the webhelpers with Pylons but don't import them all automatically in a new project. Two reasons for this, the first is that most people won't use most of the helpers so importing them goes against Pylons' philosophy of being small and agile. More importantly by importing all the Rails JavaScript helpers we are pinning Pylons to use scriptaculous for AJAX when there are arguably better libraries like YUI now. In reality the AJAX helpers aren't that helpful anyway because you still need to understand how scriptaculous works to use them and it is often easier just to code the JavaScript directly. There are also one or two bugs using them with Mako and I just think it is better not to import them by default then people can choose what they like or import them themselves without a false impression that Pylons has a particular preference for scriptaculous. JG.

On a different note, another problem with the current approach is that the webhelpers use a lot of "form foo import *" type imports. The fisrt thing new users do is look back through the imports to see how the helpers are structured so they can find the docs in the module-generated HTML. Becasue of the import structure this is a bit of a nightmare so most users don't find most of the helpers anyway. JG.

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.