Para quem ainda não entendeu porque o Pylons está virando Pyramid,
alguns argumentos excelents do principal autor do Pyramid.
---------- Forwarded message ----------
From: Chris McDonough <[hidden email]>
Date: Nov 15, 4:34 pm
Subject: The (missing) argument for pyramid
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.
say this because the fastest Pylons "hello world" app I can make runs
about 900 requests/sec (Pylons trunk), while the fastest Pyramid hello
world app runs at about 1500 reqests/sec. Benchmarking is hard, but
pretty sure that this adds up to real speed increases in the real
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
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
framework changes, and is available in HTML online, as a PDF, and as
- You can use Pyramid to create "single file" applications. This
if you wish, you can disuse "paster serve" and its attendant .ini
- 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
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
There is a well-defined configuration protocol that can be used in
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
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
in a higher layer), but it does mean that if someone hands you a
application, you can usually make it do something it wasn't
intended to do without forking the code. This is not possible with
- 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
- Pyramid's internationalization system is more featureful than
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,
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
- There is an easy way to have more than one static files folder, and
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 is a good way to map URLs to code for hierarchical data of
arbitrary depth, because the URL structure matches the hierarchy, and
artificial flattening of the hierarchy is required, as it might be in
application that used URL pattern matching only. Of course, Pyramid
also provides URL pattern matching, this is just an alternative.
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
- 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
in Pyramid. It's less easy in Pylons.
On Sat, Nov 20, 2010 at 10:17 PM, bitjesse <[hidden email]> wrote:
> Parece-me bastante promissor =)
Também achei. A principal sacada é que eles pegaram a melhor parte do
Zope 3, que é sua arquitetura de componentes , e embutiram ela no
framework de tal forma que o programador que apenas quer usar o
framework não precisa saber que aquilo existe, mas quem quer
desenvolver plugins pode usá-la. A falta de um bom mecanismo de
plugins é o maior problema do Django, na minha opinião.
> Será que se tornará conhecido e usado como Django? Espero que sim!
Isso eu não sei. Mas por outro lado, PHP e Java são muito mais
conhecidas e usadas que Python, eu já usei ambas mas ainda prefiro
Python. Eu não quero dizer que Django seja de alguma forma inferior a
Pyramid, ou que Java e PHP sejam piores que Python. Quero apenas dizer
que eu gosto mais de Python, e estou muito interessado em aprender
Pyramid, assim que puder dedicar um tempo.
No momento, continuo usando Django para ganhar a vida. Felizmente já
pude largar o Java e o PHP ;-).