On 2/26/07, Kendall Clark <kendall-4GNy1lrxftmrG/iDoc...@public.gmane.org>
wrote:

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?