Comment by stdbrouw | Hacker News Reader

Comment by stdbrouw | Hacker News Reader

The simple fact is that the larger Python community never really cared for repoze.bfg and TurboGears. The Pylons, BFG and TurboGears teams joining forces feels more like a last, somewhat desparate move to garner some attention for projects that never reached critical mass. I don't think it'll change much of anything.

I used to do development in Pylons and I've tried my hand at Pyramid, and there's simply nothing to get excited about. Even the documentation for Pyramid, which at first seems beautifully comprehensive and one of the system's strong points, turns out to be an interlinking mess lacking clear explanations of even the very basics of the system.

True enough, like Pylons before it, Pyramid is anything but opinionated, which probably makes it a good base platform for the TurboGears devs, but how much will it matter when people will just shrug their shoulders after looking at the landing page, and proceed to download Django or Flask/Werkzeug or, heck, Ruby on Rails?

Anyway, regardless of my scepticism, building new stuff and starting new projects is always fun, so hopefully the Pylons project devs enjoy the process.

I've been steeped in Pylons for several years now. I agree that Pylons has nothing to get excited about. However, (and this is the important part) it provided really straightforward glue to integrate a few other things that are definitely worth getting excited about: SQLAlchemy, Mako/Jinja, Routes, Beaker, and Paste.

Pylons' past philosophy always seemed to be "we'll take the best-in-breed of python web software and put it together in an elegant way." Sadly, they seem to have abandoned that philosophy for the sake of protecting the precious nest eggs of massive full-stack framework developers.

While the new changes to Pylons certainly don't prevent you from using the aforementioned exceptional-quality components, the smushing-together of projects while trying to retain legacy compatibility seems to have created an enormous system where there isn't a cohesive or consistent way of doing things.

No thanks--I think I'll go for WebOb and its lightweight performance.

A defense: http://docs.pylonshq.com/pyramid/dev/designdefense.html#pyra...

Yep, nothing but love for SQLAlchemy, Jinja, Routes and Beaker. But even given those components, it's still a hard sell.

Reminds me of this blogpost from a while back: http://www.hindsightlabs.com/blog/2010/03/15/jinja2-and-djan...

"In the beginning, there was Django, and it was good. But gradually we began to find its paradigms counterintuitive: we disliked the idea of apps and considered the built-in template language pretty crippled. More importantly, we prefer the epically powerful SQLAlchemy to Django’s ORM of Doom, so with the evidence before us, we switched to Pylons and the haven of SQLAlchemy/Jinja, only to discover we had switched from a shitty apartment in Brooklyn to a tent in the desert. No cockroaches, true, but no running water, either. Who really wants to write a thumbnail library? (Apologies to anyone who has actually written a thumbnail library)"

As the author, I'm interested in improving the Pyramid docs. Can you elaborate on your issues with them? Did you notice the tutorials at http://docs.pylonshq.com/pyramid/dev/index.html#tutorials (lots of people seem to miss them).

Hi Chris. Off the top of my head, from when I was working on a Pyramid app ~ a month ago:

- No clear visual distinction between links to glossary terms and links to further documentation. I like the glossary, but always ended up there without wanting to.

- I did find the tutorials, no issue there. (Only that the paster templates are a bit awkwardly named, but that's not a doc issue.)

- Especially the former BFG stuff, I'm thinking specifically about traversal, is explained in a way that probably makes a ton of sense to Zopeheads, but, at the time anyway, read more like a PhD thesis than like documentation.

- Again not strictly a documentation issue, but the fact that you can configure and use Pyramid in a ton of different ways means there's no straight path from getting started to actually getting something up and running, even with the tutorials. Not being opinionated about anything simply makes it very difficult to write good, forceful docs.

"No clear visual distinction between links to glossary terms": yep, fixed a while back. Glossary terms are now green, other links are blue.

Traversal explaining: we're working on it (really). The docs have been rearranged and massaged a good bit, and they're being futher (professionally) edited now.

Flexibility: the best I can do about that without betraying the goals of the project is http://docs.pylonshq.com/pyramid/dev/designdefense.html#pyra... . I'm also working on a cookbook here: https://github.com/Pylons/pyramid_cookbook which should provide the tl;dr'ers with a way to perform common tasks without needing to read didactic explanations.

I still have to finish up my Pyramid app next month (work project at a Plone shop), so it's good to know that the docs are getting better. Kudos!

We are definitely fixing the traversal docs, and they are already much improved over two weeks ago ;)

The responsiveness of Chris and Ben to actually fixing this kind of thing is amazing, and one of the major reasons we thought teaming up with them would be a good idea.

All both pylons and tg have thousands of users on their lists, bfg has dozens of commiters of users, and a growing users list. And between our three frameworks I wouldn't be surprised to see tens of thousands of live sites, and millions of pages served per day. Heck I work on a site with millions of dynamic pages a day served up by turbo gears So, I'd say the facts show a different story than the casual dismissal you want to paint.

There is a lot that can be said for consolidation. And a lot to be said for the team working on pyramid now, so I'm excited in spite of your skepticism.

Nice trolling.

I kind of expected this response, and the style of writing may be a little provoking, but I think it's a pretty factual assessment of where these projects are headed. Feel free to disagree, though.

glad you expected the response -- you're a classic troll; complete with creating a dummy account, the opening line stating a stupidly absurd negative comment, and the closing line with the insinuation that the devs go through all the pain of running a project for their own edification

Reply on news.ycombinator.com