This is awesome, Chris. Thanks! On Mon, Nov 15, 2010 at 4:34 PM, Chris McDonough <[email protected]> wrote: > 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
-- Luciano Ramalho programador repentista || stand-up programmer Twitter: @luciano -- 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.
