On Wed, Feb 1, 2012 at 12:03 AM, Rob Miller <[email protected]> wrote: > These are reasonable points to make. But Pyramid is explicitly not trying to > be the same thing that either Django or Rails is trying to be. Those are > what we call "opinionated" frameworks, which make things easier on less > experienced developers by making many choices for them. This usually comes > at a cost; you lose flexibility, and you have to wrestle w/ the framework > when you realize that the choice you want to make isn't in fact the one your > tool has made. > > Pyramid has some opinions, sure, but far fewer of them. It's intended to > strike the right balance between flexibility, performance, and ease of use > for more experienced developers. Some people complain about certain features > b/c "I'm never gonna need this, and it confuses me, can't we just rip it > out?" But in every case that feature is there b/c SOMEone had to solve a > hard problem and that was the best way to do it. Ripping it out would make > those hard problems harder to solve. But Pyramid targets those hard > problems, and thus the features stay. > > This case w/ globals is similar, although slightly inverted. In many cases > module-level global settings are fine; they make the developers life a > little bit easier, and they don't cause any problems. But in some cases they > *do* cause problems. Real, honest to god developer pain. Django and Pylons > have both hit this in the real world. For Django it's fine, it's a trade-off > that makes sense given their philosophy and their target audience. For > Pyramid it doesn't, b/c Pyramid is just as interested in reducing developer > friction in the hard cases as it is the easy cases, and so they make a > different set of trade-offs. > > Does this mean that Pyramid will never be as widely used as Django? > Probably. Does that matter? Nope.
This is a great summary, Rob. Blaise, that second paragraph has good material for the website or a FAQ entry -- the part about how all the features are there because somebody needed them, and you may also someday work on a site that needs them. That's why I'm excited about all the additional capabilities Pyramid has given to the Pylons world, capabilities that don't exist in Django or most WSGI frameworks. It will take time for people to realize how much power Pyramid gives you, but when they do -- or at least when they have a need for those capabilities -- I think you'll see Pyramid's "market share" rise significantly. I used PHP back when it was transitioning from global scalars to global dicts. Originally, it created a global scalar for every query parameter or POST variable. That was ultra-convenient but they discovered it was a major security hole because users could override any variable in the site. So they went to a global dicts of params. Later they found that wasn't convenient enough so they went to super-globals. Each of these transitions caused programmers to have to learn a new technique. Or if they didn't, it forced others to read and maintain their old-style code. But the lesson for us is that PHP did some horrible things in the beginning. Yes, that gave a lot of new web programmers an opening, but was that the best it could have done? Would those progammers have come in if PHP had been just slightly stricter? Or should they learn a structured development environment from the get-go? I lean toward the latter but there's room for multiple views on this. The point of Pyramid is that it's both a framework and a set of tools. If you think a framework should have globals and other easy-looking things, by all means make a framework on top of Pyramid that does this. Then people can start with the "easy" environment, and drop down to regular Pyramid when they need extended features. I'd like to see a Pyramid port of Django. Maybe not 100% compatible, but enough to be acceptable to a large percentage of Django users. Because my main goal is interoperability, so that people aren't stuck in silos. If we can get to a point where people agree to use the core Pyramid infrastructure, even if they put a totally different front end on it, that will help the Python web community in the same way that WSGI and Paste and Setuptools helped it: by providing a common set of packages that people used, which inherently helped compatibility. Of course, Twisted will never join Pyramid because it has a different paradigm, which I don't think can be made compatible. But I may be wrong about that. I did not foresee the Zope discontents coming back to Zope technologies, or the Zope fans adopting to the things the discontents brought with them, but it has happened. -- Mike Orr <[email protected]> -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
