Similarities

• Both are MVC-style frameworks. Neither is particularly CMS oriented in the framework itself (unlike Django or Zope).
• They both support SQLObject and SQLAlchemy specifically, though neither is as tied to a persistence system as much as Django. (TurboGears tries harder to add specific tools on top of these ORMs.)
• They both use Buffet templating plugins to support multiple languages. Both have preferred templating languages (TurboGears has Kid/Genshi, and Pylons Myghty/Mako), but both want to fully support whatever choice of templating language you might have. Interestingly, they are both in transition.
• They both use FormEncode for validation.
• In the future they both plan to use ToscaWidgets for form generation. (ToscaWidgets is an extraction of TurboGears widget system, and FormBuilder which comes from a Pylons developer is being deprecated in favor of ToscaWidgets.)
• They use nose and py.test for tests (very similar test runners), though Pylons is probably going to migrate to nose from py.test at which point they'll have identical test runners.
• They both use Paste Script templates for project creation.
• Both use front-facing WSGI-based servers (such as CherryPy's WSGI/HTTP server, flup, or Paste's HTTP server).

Differences

• They use different dispatching mechanisms. TurboGears uses CherryPy's object publishing dispatch (basically each path segment becomes an attribute lookup). Pylons uses Route's pattern matching against the full URL path. TurboGears dispatching points to a function that is invoked by CherryPy, Pylons points to a WSGI application.
• The controllers look different. TurboGears uses a plain function, plus many decorators to alter the behavior of the function. Pylons uses a class, where the superclass provides the WSGI interface and the subclass implements the application-specific controller logic.
• Configuration in TurboGears uses CherryPy conventions, where Pylons uses Paste Deploy conventions. (TurboGears developers have expressed interest in using or supporting Paste conventions.)
• Pylons uses the Paste TestApp for functional tests, while TurboGears uses CherryPy's mechanisms for running artificial requests and inspecting side effects.
• Most added features in Pylons (that aren't simply libraries) are implemented as WSGI middleware. TurboGears features are usually implemented as function decorators, though a small number are implemented as CherryPy filters. A notable example is AuthKit (which is not Pylons-specific) for Pylons, and TurboGears' Identity system.
• Pylons supports simple dispatching to WSGI applications, using WSGI middleware internally in your system, and easy wrapping of the entire application in WSGI middleware. Pylons applications can be entered multiple times in a single request (e.g., one Pylons application dispatching to another Pylons application). CherryPy has some support for this, but it is not used to any effect in TurboGears itself and doesn't seem to be programmatically controllable.
• Besides Paste Script project creation, their command-line tools are implemented differently. TurboGears has more command-line tools.
• TurboGears has considerable integration with the MochiKit Javascript library. Pylons has some integration with Prototype in the form of its ported Rails helpers. Translating those helpers to other libraries like MochiKit is quite feasible and would probably be a popular choice.

Conclusion

You'll note there's not a lot of high level philosophical differences. And I don't think I glossed over that -- they just aren't there. The details of their differences are very... detailed. Very technical, very specific, often not particularly intentional. I'd have a hard time describing the technical differences in a meaningful way to someone who didn't already know something about Python web development.

As communities the two frameworks are fairly similar. They both borrow heavily from existing projects, and have spawned projects in their own right. Technically not everything is the same, but the question would be: what are the essential differences, and which differences are just incidental?

For instance, TurboGears is probably easier for a newbie to start with, but it's not because Pylons doesn't want to be easier to start with, there simply hasn't been as much investment in that. And TurboGears has less WSGI support inside the framework, which is not because they don't want to support WSGI in that way, again the investment simply hasn't been made.

Actually "merging" the two is probably unlikely. It's the kind of weird political maneuver that open source projects don't really do, unless they are part of weird "foundations" and have "managers" and stuff like that -- it's too much politics for programmers, and reeks of strategy and plans. You aren't supposed to announce plans for your software, you are supposed to implement your plans and then announce them. If a merge happens, it should be more like a realization than a strategy.

I can also imagine the two bleeding into one another -- where one uses Genshi, the other Mako, one uses object publishing, the other Routes, etc. The differences could become much more shallow. That itself could become difficult -- the differences might be shallow, but the effect on documentation is not much better than if they were two completely different frameworks. And do people float around between communities, or in some middleground, or subscribe to all the lists or... what? Maybe at least by partitioning the communities it can help keep the newbies sufficiently diluted among the experienced users.

Technically the biggest difference is definitely CherryPy vs. Paste. This is something of a sensitive point and has been the source of some discord. The templating language differences are fairly shallow, since both are fairly agnostic anyway. The Javascript differences aren't heavy with intention, they are more coincidental than anything.

So... what should be done? Plans are being made for TurboGears post-1.0 through version 2. The younger Pylons is still a blank slate in many areas. At the moment several people have feet in both communities. Push hard right now, when plans are being made? Let things develop naturally? (Of course, these are people making these decisions, so "natural" should still include discussion -- it's not like we're decided whether to transplant a hydrangea.)

Discuss!