I'm not sure the OP is trolling, it comes across as frustration. While some of the things he points out are unfair and suggest unfamiliarity with certain aspects of the framework, there are some valid points in here as well:
1. The usage of traversal vs dispatch. It's unclear even to those quite familiar with Pyramid which to use for a given situation, and often I find myself yo-yoing between the two in the same project. Traversal is seen by some as "the" way to do Pyramid, with dispatch as an afterthought bolted on for Pylons compatibility, others still think the opposite especially with SQLAlchemy projects. This is very confusing for people who just want to get on and build something as it is so fundamental to the structure and design of your project. 2. Zopeisms, aka the ZCA, ZCML, zope.interface etc. This I see more of a marketing issue, but there is a valid concern here - the amount of conceptual overhead required to fully grok (pardon the pun) the framework is a problem. We often don't get to pick and choose the code we deal with as much of the time we have to deal with projects where we didn't have a hand in, so while I may prefer to ignore the ZCA for example in my own projects, I might well have to deal with it in someone else's. As with traversal/dispatch, the multi-paradigm approach may please nobody in the attempt to please everybody. 3. The "lots of tiny little components" problem. Actually this is mostly unfair. Pyramid reuses existing stuff like WebOb and Paste, but it's not alone in this - the OP mentions Flask for example, which depends on Werkzeug and Jinja2. In this Django is unusual in having an in-house (or, more unkindly, NIH) approach to everything. Outside of Python, Rails 3 for example has moved more in the direction Pyramid is at with the merge of Merb. It makes sense when possible and practical not to reinvent the wheel - the problem for the Django developers was a lack of decent wheels half a decade ago, I'm sure they would not have taken the same approach today. That said, one trend that is the matter of some concern is spinning off of parts of the pyramid core - such as ZCML and handlers - into separate packages. This may reduce cohesion in the framework and lead to the "tower of dependencies" problem that TurboGears 2, for example, suffered greatly from. Not an immediate issue - and I've contradicted myself re: ZCML being part of the framework - but still a cause of concern. The code quality issue is bunk. I've found the Pyramid code remarkably easy to navigate and understand - try looking at some of the Django ORM/admin code in comparison. More importantly - as code quality is subjective - is the staggering number of unit tests. You may or may not agree with the design principles, but you can rely on the code you use. I don't really have any recommendations here or solutions to offer. All in all I do like Pyramid and appreciate its strengths more as I build more projects with it. It does however suffer from two things in particular: 1. A marketing problem. Django is for "perfectionists with deadlines". Flask is the fun, easy microframework. What problem does Pyramid solve ? If you could summarize it in a single phrase, what would it be ? Pylons had a brilliant tagline - the "Hacker's Framework". One thing Pyramid really needs is success stories - "we used Pyramid to build [insert awesome site here]". 2. TIMTOWTDI. This is the bigger issue. It's a real roadblock for people starting a project in Pyramid, because they don't know whether to decide between traversal or dispatch, which form library, ZCML or ini, which template engine etc. It's also a potential issue for people taking on legacy Pyramid projects as they don't know what to expect. This is of course a strength as it gives you ultimate flexibility, but is also a source of confusion for newcomers. This situation will hopefully improve with templates built on top of Pyramid, but we're a long way from there yet. On 3 March 2011 17:31, Ben Bangert <b...@groovie.org> wrote: > On Mar 3, 2011, at 9:28 AM, Chris McDonough wrote: > >> Sounds like (s)he is blowing off a little steam. All of these points >> are addressed in >> http://docs.pylonsproject.org/projects/pyramid/1.0/designdefense.html . > > Indeed, my comment is awaiting moderation on the blog, I cited that URL as > well. :) > > Cheers, > Ben > > -- > You received this message because you are subscribed to the Google Groups > "pylons-devel" group. > To post to this group, send email to pylons-devel@googlegroups.com. > To unsubscribe from this group, send email to > pylons-devel+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/pylons-devel?hl=en. > > -- You received this message because you are subscribed to the Google Groups "pylons-devel" group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
