Hear, hear! You guys are killing it! ~br On Nov 16, 1:47 am, Luciano Ramalho <[email protected]> wrote: > 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.
