On Thu, 2011-03-03 at 18:22 +0000, danjac...@gmail.com wrote: > 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.
My personal rule of thumb: I use traversal when I use ZODB, routes when I don't. > 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. Understood. I don't think we can really lump everything that starts with a Z into one category though. For example, ZCML is unrelated to ZCA and zope.interface. It's existence is an issue for some but we can't prevent or deter folks from using (and enjoying) ZCML any more than we can deter or prevent them from using and enjoying a bad library or application. The best we can do is not make it the default (which it isn't, so I don't expect folks to need to deal with a great many ZCML-based applications). The usage of ZCA internally in Pyramid is a separate issue. At this point, it seems gratuitous to break existing applications for the marginal benefit of reducing cognitive load for a minority of people who may one day need to deeply understand the Pyramid core. There are no requirements upon a Pyramid *application* developer (and never will be) to ever understand interfaces, components, etc. Even a Pyramid add-on developer needn't understand ZCA concepts. The only type of developer that truly will need to understand these things is a developer of the Pyramid core itself, and even then only in certain circumstances. I think this is an appropriate level of exposure, and I'm not sure that replacing ZCA with something else would make that any better. > 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. I don't really think we have a tower-of-dependencies problem, and I hope we avoid such a problem in the future. It's mostly just a matter of judgment I think. > 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. Yay! > > 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.
