On Mon, 2010-11-15 at 09:03 -0800, Ben Bangert wrote: > On Nov 15, 2010, at 8:02 AM, BrianTheLion wrote: > > > Apologies if I've come across as pushy on this issue. That was not my > > intention. My goal is to motivate the pyramid team to do itself (what > > I see as) a great service. > > > > The Pylons community is clearly excited by pyramid's "escape" and is > > chomping at the bit see what its new toy can do. We're practical > > people, though, with practical concerns. We have to ask ourselves how > > pyramid is going make our lives better. IMHO, you guys need to play a > > little politics. If you make a strong, early case for pyramid's > > technical superiority to its end users, the app-devs, you'll have a > > much easier transition on your hands. The community is energized; keep > > it rolling! > > Yea, its definitely a tricky situation. On the one hand we could start > spending more dev time talking about features and capabilities that Pyramid > excels at, but on the other hand if that convinces more people to make the > jump before tools are ready for easing migration we'll get burned by bad PR > on the "lousy transition" job we did. > > I was going to try and tackle this by writing blog posts once a week > regarding design issues and feature that Pyramid excels at, in a manner > highlighting that its for early adopters and folks that like the cutting edge > only right now. I think when more of these posts are ready, the case for > Pyramid will sell itself.
In the meantime, here are some salient bullet points that we can probably write about in a more suit-friendly post at some point: - Pyramid has the capacity to be roughly 1.5 times as fast as Pylons. I say this because the fastest Pylons "hello world" app I can make runs at about 900 requests/sec (Pylons trunk), while the fastest Pyramid hello world app runs at about 1500 reqests/sec. Benchmarking is hard, but I'm pretty sure that this adds up to real speed increases in the real world, or at least less latency. This conjecture has been backed up by at least one fellow who has ported his GAE Pylons application to Pyramid. The Pyramid application services the request in about 8-10ms. The Pylons application from which it was ported requires 20-25ms. Lies and benchmarks apply, of course, and YMMV, but in general, Pyramid was engineered from the ground up for speed, while Pylons was not. - Pyramid has more complete narrative documentation than does Pylons. Although Pylons has good docs, its most comprehensive documentation is in the form of a book written by James Gardner, which, although published under the GNU documentation license, and is thus available freely, is not regularly updated as Pylons changes. The Pyramid documentation is of high quality, is very comprehensive, changes as the framework changes, and is available in HTML online, as a PDF, and as an EPub file. - You can use Pyramid to create "single file" applications. This means, if you wish, you can disuse "paster serve" and its attendant .ini file. - Pyramid provides a set of decorators that can move configuration settings closer to the code that they relate to (see the "view_config" decorator and the "subscriber" decorator). Additional configuration, even configuration that lives in a separate package, can be executed via a "scan" at application startup time. - Pyramid applications, written as per the guidelines in the documentation, are more easily unit-testable, because a) they don't encourage using "stacked object proxies", which often require dicey setup and b) they often use "renderers" which means that you can test the return logic of a view without parsing HTML in a plain old unittest. There is a well-defined configuration protocol that can be used in both application setup and test setup that takes much of the mystery out of writing unit tests. - Pyramid itself has 100% unit test coverage. Pylons, although stable, and relatively bug-free, does not. - Pyramid applications are extensible "out of the box". This doesn't mean that Pyramid is a platform for "pluggable apps" (that'll have to be in a higher layer), but it does mean that if someone hands you a Pyramid application, you can usually make it do something it wasn't necessarily intended to do without forking the code. This is not possible with Pylons applications. - Pyramid has an event system. Users can subscribe to (and publish) events to hook (or signify) various points in the request cycle. This usually makes for better extensibility than needing to override hardcoded application logic. - Pyramid has a declarative authorization system built in. Pylons does not. - Pyramid's internationalization system is more featureful than Pylons'. In particular, it allows you to create .po files that map only to a single logical code unit, not to code that folks may later plug into that code (see "extensible out of the box"). - In general, where extensibility or customization is necessary, Pyramid provides a clean hook point that allows you to override behavior and implementations. For example, you can create your own sessioning backend, configuration decorators, and other "frameworky" bits without delving into undocumented-land. This is often not the case with Pylons. - There is an easy way to have more than one static files folder, and an easy way to generate URLs to static resources in multiple places (even Apache resources). Pylons comes configured with a single static resource directory and provides minimal help for URL generation. - Pyramid provides an alternate way to map URLs to code named traversal. Traversal is a good way to map URLs to code for hierarchical data of arbitrary depth, because the URL structure matches the hierarchy, and no artificial flattening of the hierarchy is required, as it might be in an application that used URL pattern matching only. Of course, Pyramid also provides URL pattern matching, this is just an alternative. Pylons has no such thing. - Pyramid "view predicates" allow you to register view callables for very specific configurations. For example, you can register a view callable which is only called when the request method is POST, the request is an xhr request, and a "foo" parameter is in the POST parameters. This is not possible (or at least not straightforward) in Pylons. - Pyramid has an easy way to map exceptions to view callables. If you want to show some particular view when your application raises an exception (an arbitrary one, even one you might define), it's easy to do in Pyramid. It's less easy in Pylons. HTH, - C > > Cheers, > Ben > -- 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.
