[windle]

To answer your first question, it won't be nearly as easy of a transition as it was from Pylons 0.9.7 to 1.0. For some reason, the fact that Pylons 1.0 hasn't had any updates or feature additions in the 6+ months hasn't seemed to be an issue, it was already mostly in a "it works as well as it can work" stage.

Plugging in the old Pylons app using WSGI isn't really any more kludgey than using WSGI for any other app composition use, which is plentiful.

For the second question, the best reason would be that in the world of web development, all web frameworks will deprecate old technology. It's the only way to move forward if a fundamental design decision in the core needs to be re-architected.

I know many former TurboGears users may have a lot of angst about this, because the rug has been pulled out a bit more than for Pylons users, who have rarely had to deal with everything at the bottom being replaced. This direction was taken to help avoid that again in the future, because now all the development for everything... top to bottom... we have under one roof so to speak.

In pyramid we have a core that is architected to deal with the extensibility issue, and can pick up development of features that the Pylons 1.0 code-base couldn't handle. Since its based on over 2 years of development and use in the repoze.bfg community, it means its very solid and stable already.

In short, I think it's on track to be one of the most stable Python web frameworks out there, just like Pylons 1.0 and prior has been quite stable. My advice would be to try new, small experiments and projects with it first. I'll be publishing more articles highlighting the improvements and extra features it brings to the table soon.

[old-gregg]

What bothers me is that nowhere in that email, or nowhere on the site, I see a single reason for this move. Why? Why do it?

The only explanation I see is that developers wanted a nicer codebase. I've been on Pylons mailing list forever, and I can't recall a single practical issue or a feature request, which was decided to be hard/impossible to do due to architecture limitations. It just never comes up.

This is a classic case of redesign for the sake of redesign.

[windle]

Sorry you didn't see it, I'll try again: http://docs.pylonshq.com/faq/pylonsproject.html#why-not-just...

[old-gregg]

:-) I guess I'll have to copy&paste to support my argument. A link isn't good enough:

Due to the use of sub-classing, extensive, sometimes confusing, use of Stacked Object Proxy globals, and issues with configuration organization

As an active Pylons user I never, ever heard of these issues in Pylons circles. Translation: nobody asked for these improvements. Statements like "sometimes confusing" aren't doing it. When? Confusing for whom? I, for one, loved stacked globals. "from pylons import config" was great. Rails wasn't that simple. This is a big shock coming from nowhere. It just wasn't something that came up often on Pylons mailing list.

Let me make this clear: do I believe Pylons could be better? Yes I do. Do I think killing it to make it better was a good idea? No, I don't.

Anyway, I have tremendous respect for Ben and can't blame him for getting bored and wanting to work on something different.

EDIT: I just realized that you may be Ben. In that case thanks for building the greatest web framework for my favorite language! The fact that I'm passionate enough to bitch and moan about its death on the Internet should be the best testament to its greatness! :)

[windle]

Many people loved "from pylons import config", until it didn't work, which frequently happened anytime someone wanted to use something from a Pylons app in a command line script (which seems to be pretty often). I do have a few minor clean-ups that help slightly with that stuff which I'll likely put out a Pylons 1.0.1 to address.

> Let me make this clear: do I believe Pylons could be better? Yes I do. Do I think killing it to make it better was a good idea? No, I don't.

So, the whole 'killing' thing seems slightly extreme. I've maintained Pylons with few changes besides bug fixes, security fixes, and deprecating old things for the past several years. And now the announcement that I don't plan on doing any more than the same thing for the pylons package code-base is "killing it off"?

If you're happy with pylons, there's no need to stop using it. The docs will always be available for it, the code-base will not be removed. By design, I just couldn't see how to continue it forward in ways that I (and a lot of people I've talked with) need.

Of course, a lot of people may not need anything more than pylons provides right now, and in that case I'd be hard pressed to tell them to switch their code to use pyramid. pylons is stable, mature, and has been maintained as such for quite awhile, there's a book that still pretty much applies to 1.0.

> Anyway, I have tremendous respect for Ben and can't blame him for getting bored and wanting to work on something different.

Thanks, sorry my nick doesn't reflect it, this is Ben. Seems I can't change my profile info on ycombinator, sigh. Or that 'feature' doesn't exist, anyways...

As I mentioned, the Pylons code-base was essentially frozen for any direction forward which I needed to build higher level tools. I know this may not be immediately obvious to everyone depending on your requirements, and pylons suits many peoples needs perfectly well.

I will be blogging about this in the future, at which point some of the key differences, and what they enable will hopefully become more clear. But Pylons is definitely not dead, and I think it won't be too long before people start to see what a larger development team can do. :)

[mdda]

This is the first post in the thread that makes me feel good about what's happened - perhaps this approach should have been the lead story, rather than what appeared to be "If you're using Pylons then say goodbye to all the cool developers - they've found something else new and shiny to work on".

( I've been watching this thread with keen interest - having chosen Pylons (vs Django, and RoR) about two months ago. )

[d0m]

For a new startup, would you honestly recommend going with pyramid? And what about Django.. do you think it'll go faster to prototype and develop with pyramid?

[windle]

Depending on what you're prototyping, it could very well be done faster with Django. Django provides a bunch of 'generic views' which can make tossing up lists of objects from the db very fast to get started with. Then usually you end up fully replacing it all later, but it gives you a good start.

My views haven't changed since I answered this: http://stackoverflow.com/questions/48681/pros-cons-of-django...

If your app doesn't clearly fit into the sweet-spot's for Django, the argument will be less compelling. The pyramid code-base does have a lot of maturity behind it, it's not completely brand-new, so I don't think it'd be a problem to develop against it to be able to utilize its additional extension points.

[Keith83]

To help make the move from Pylons, I'd love to see a document introducing Pyramid from a Pylons perspective and explaining what it does differently.

Please say Pyramid has a debug mode like Pylons :)

[cd34]

easy_install weberror, tempita, pygments

add egg:WebError#evalerror into your pipeline. It isn't in the default Pyramid paster template, but, it was mentioned that it will probably be included in in the default Pyramid paster templates. http://goo.gl/EDqNo is a document I wrote regarding the transition of a Pylons 1.0 to Pyramid 1.0a1 application.