I'm sorry you feel that way, as the developer of Pylons, I really don't look at this as killing Pylons anymore than the lack of any new functionality has killed Pylons 1.0 in the past 6 months.

Pylons 1.0 has been in maintenance mode already (effectively), 1.0 was in fact nothing more than a few tweaks on 0.9.7, ie. maintenance release with a 1.0 version number and finally killing a few deprecated things.

The FAQ explains why when attempting to extend Pylons for new functionality, I hit a dead-end: http://docs.pylonshq.com/faq/pylonsproject.html#why-not-just...

Finding a path forward for extensibility that didn't hit this forking problem: http://lincolnloop.com/blog/2008/apr/4/reusable-django-apps-...

was a very major concern of mine. I think this will address that, and when Django makes the changes necessary to remove the forking problem I won't be at all surprised if it requires porting your apps...

Why Pyramid is not called Pylons 2?

We had originally considered calling it p2, unfortunately that would've sort of bound the package name to sound kind of odd when someday we get to Pylons 3. Also, given the amount of new code to merge in, and then slowly deprecate the old code in the pylons package... it seemed more convenient to use a new name.

This also means that no one installing the 'pylons' package will have to worry about someday installing a version that deprecated things their old pylons app needed. Using pyramid means that you can use the new, along with the old one, at the same time, without worrying about version conflicts in the package.

This is not at all an apt comparison. With Django, you're buying into its templating, routing system, its ORM, its view/controller paradigm, its central app configuration, its core request delivery system, whatever it does for caching/sessions, and all the admin stuff. With Pylons, you've bought into some choice of templating (usually Mako), routing system (Routes), some choice of ORM (usually SQLAlchemy), its view/controller paradigm, its central app configuration, its core request delivery system (Paste, PasteScript, etc.), caching/sessions (Beaker), and it doesn't come with any admin stuff.

Pylons' change to Pyramid most certainly does not replace that whole stack. It replaces exactly two of those components, the view/controller paradigm and central app configuration. All the things that don't change at all are: templating, ORM, routing, Paste/Pastescript, caching/sessions still on Beaker.

So this nothing at all like moving to an entirely new framework, Mako/SQLAlchemy/Beaker aren't going anywhere.

edit: the routing changes a bit, but its an improved and higher performing package with mostly complete feature parity. I'm looking forward to using it.

Nit-pick: with Django, you're buying into an HTTP request/response interface and a system for mapping URLs to callables which obey that interface. Everything else is optional.

(and you know this)

yes, but I'm sure you understand the point, that the Django stack is "batteries included" whereas Pylons is not.