TG & Pylons Merger?

3 views
Skip to first unread message

Kendall Clark

unread,
Feb 26, 2007, 11:10:01 PM2/26/07
to pylons-...@googlegroups.com
Folks,

Didn't make it to PyCon this year, but I just saw this tidbit on
Eckel's Artima blog:

> It seems likely that TurboGears and Pylons will merge. This looks
> like a good thing.
>

Is this actually likely?

Cheers,
Kendall Clark

Ben Bangert

unread,
Feb 27, 2007, 2:13:22 AM2/27/07
to pylons-...@googlegroups.com
On Feb 26, 2007, at 8:10 PM, Kendall Clark wrote:

> Didn't make it to PyCon this year, but I just saw this tidbit on
> Eckel's Artima blog:
>
>> It seems likely that TurboGears and Pylons will merge. This looks
>> like a good thing.
>>
>
> Is this actually likely?

It's conceivable, it was definitely discussed a few times as well. It
wouldn't be so much a merger in any sense, as more of a coalescing of
common parts. That is actually already happening with TurboGears
spinning projects out (widgets) and them becoming usable in a broader
sense.

No merger is really possible, or really on the table for talking
about until TurboGears 2.0 comes out though. A merging of efforts
behind common components is definitely something I think many of us
want, and is already happening to some extent with various parts.

So likely? Not in the near future. But we definitely want to work
together on more parts of the stack, and the sooner the better. :)

Cheers,
Ben

Mike Orr

unread,
Feb 27, 2007, 2:59:54 AM2/27/07
to pylons-...@googlegroups.com, Kevin Dangoor

Not in the near future. The discussion is mainly theoretical at this
point: *how* would we merge the projects if we decided to, and what
would the impact on each framework be? The answers to these determine
how feasable it is, and how desirable.

First we have to ask, what is the essence of each framework? For
TurboGears it's IMHO the URL dispatcher, automatic translation of
params to args, the standard decorators, and the request/response
objects. Without these it's not TurboGears anymore; it's some other
framework. For Pylons it's the Paste integration and Routes
dispatcher, and to a lesser extent the base controller class, the
one-letter globals, and the request/response objects.

TurboGears has already been ported to Paste via RhubarbTart, and these
packages could be integrated into the Pylons repository. This would
give two "faces" to PylonsGears (my coinage), one via "paster create
--template=pylons", and one via "paster create --template=turbogears".
Both frameworks already support the same templates and SQL libraries,
Pylons will soon support ToscaWidgets, and their Javascript libraries
will likely converge. Would tg-admin commands be migrated to Paster?
Would PylonsGears depend on *two* template engines? (Pylons is headed
toward Mako, and TG toward Genshi.) Would it depend on a SQL library?
(TG depends on SQLObject though it may migrate to SQLAlchemy; Pylons
depends on neither but includes stub code to activate either.)

Going the other way -- basing Pylons on CherryPy and inserting it into
the TurboGears codebase -- is a non-starter. CherryPy is monolithic
in ways Pylons' philosophy rejects. It may be technically feasable to
build Pylons on top of CP 3's optional WSGI and Routes modes, but that
leaves CP's other modes as dead baggage. Paste is the minimum code
necessary to host WSGI applications and provide configuration and
flexibility, and this is a core part of Pylons' philosophy.

If I'm right about this, it means Pylons would stay the same while TG
would have to change. Of course that is for TG's developers and users
to decide, so it's useless to speculate about it on a Pylons list. I
would like to see an experimental port just to demonstrate the
feasability. Ian said this should be pretty simple since RhubarbTart
is built for Paste. The main work would be testing "typical"
TurboGears applications, rewriting only the parts that aren't
supported by RhubarbTart (e.g., CP filters), or modifying RhubarbTart
itself to use Pylons' conventions (e.g., sessions via Beaker
middleware, logging, error handling).

My impression from talking with Kevin and Mark at PyCon is, TG is
happy with CherryPy for now, and they're currently distracted porting
TG to CP 3. CP 3 will offer TG applications more Pylons-like
features, and who knows where that will lead.

Plus there's backward compatibility. TG applications are starting to
appear in production (I assume), and who knows how many of them depend
on CherryPy idiosyncracies not supported by RhubarbTart. TG will have
a hell of a time weaning users from SQLObject to SQLAlchemy and from
Kid to Genshi -- especially since TG targets naive users. There's a
TG book now, which is telling thousands of people what TG is like --
as is. So they'll have enough trouble migrating people to TG 2, and a
merge with Pylons may seem like too radical a step. On the other
hand, if TG 2 decides to break compatibility anyway, maybe merging
won't seem like such a big step after all.

The main advantage to a merger is to become a more formidable
competitor to Django, and to shrink the number of web frameworks.
These are philosophical/political questions, not technical issues.
Combining the two repositories may or may not make source code
management easier. Pylons and TG are becoming more similar to each
other no matter what we do, because users of both are clamoring for
access to the same libraries.

* * *
BTW, I would take Eckel's entire blog post with a grain of salt.
http://www.artima.com/forums/flat.jsp?forum=106&thread=196792
The "What Can Python Learn from Other Languages" section lists several
ideas which have been debated by Python developers and are considered
controversial or infeasable.

- Multicore concurrency: Doug Napoleone said during a late-night beer
that CPU cores are likely to multiply in the near future, and this
will make Async much more popular. I'm not sure this means everybody
will move to Twisted, but there will be some change in the programming
paradigm for high-demand applications. He did say threads would
survive as a means of inter-core communication.
- Lisp-like macros. I don't know what these are but we've seen the
controversy regarding adding features to lambda (unpythonic) or
allowing anonymous code blocks (Guido says that's unfeasable because
Python's flow control is indentation-based so you can't have
flow-control statements inside expressions).
- Restricted execution: many have tried this and say it's unfeasable
given Python's structure. Apparently you can worm your way from any
new-style class into any other object in the interpreter.
- Putting SQL support in the Python core via a list-interpolation
syntax. I haven't heard this, but considering how hard it's been to
get the much more urgent NumPy Array into the core, it sounds
unlikely.

What's this groovy XML library Eckel is so excited about?

--
Mike Orr <slugg...@gmail.com>

ToddG

unread,
Feb 27, 2007, 11:52:15 AM2/27/07
to pylons-discuss
> What's this groovy XML library Eckel is so excited about?

I would guess this:

http://groovy.codehaus.org/GroovyMarkup


Kevin Dangoor

unread,
Feb 27, 2007, 2:34:37 PM2/27/07
to pylons-...@googlegroups.com

I am personally interested in seeing the foundation for TurboGears 2.0
put together fairly soon. And open source is all about itch
scratching, so we'll see what happens.

I haven't spoken with Mark yet to see how yesterday went, but I think
they'll make some good progress on TG 1.1 at the sprint this week. If
that does go well, that'll leave that much more breathing room for
others of us to get 2.0 in shape.

The net result of the TG 2.0 work will be that TG and Pylons will each
have more components to choose from than we do currently. We both want
to use "the best", so we'll naturally gravitate toward a collection of
common ones. There will be some differences which may or may not
resolve themselves. Regardless of whether the two projects merge,
they're certain to share even more in common than they do today.

Believe it or not, Zope is increasingly playing in the same ballpark
that those of us in TurboGears and Pylons-land are playing in. That
means that even more components and libraries will be available for
the stacks we want to build.

It's all good stuff.

Kevin

Reply all
Reply to author
Forward
0 new messages