Actually I'm looking forward to that kind of hard questions!   I think
they will help us to clarify the way we work with Pylons, and to
better decide who does what and how we will work together better in
the future.

My understanding of things is that  Pylons will be focused on
providing maximum flexibility, and creating lower level framework that
allows all kinds of choices.

TurboGears will stay focused on the thing's it's always been focused
on -- creating a full-stack framework for rapid web development.
We'll give you a stack of components that work well together.   We'll
create basic templates that get you going quickly, and we'll focus on
developing a coherent, well documented standard API for our
developers.

We need to make choices about integrating tools, creating sane
defaults, and making the experience of getting started as simple and
rich as possible.   There have been requests for a higher level API on
top of pylons for a while, and at least in part TurboGears 2 will
provide that for people.

We'll be providing a layer above some of the raw WSGi internals that
are present in paste.   Returning a dictionary is one of the core
pieces of the turbogears API, and we'll be doing that.  Object
dispatch is part of the core TurboGears way of doing things and that
will be in TurboGears but not Pylons.

We'll also, hopefully, be creating a wide variety of tools for rapid
web development, like the current FeedController, or a restful CRUD
controller based on the atom publishin protocol.

There are lots and lots of possibilities, and only time will tell
exactly how things will work out.  But what will be certain is that we
will provide current TurboGears users with a way to migrate to a
TurboGears like API on top of Pylons, and take advantage of all kinds
of cool new things.  And we'll provide a nice, standard, easy-to-use
way to create web applications on top of pylons.

--
Mark Ramm-Christensen
email: mark at compoundthinking dot com
blog: www.compoundthinking.com/blog