The (missing) argument for pyramid
BrianTheLion
I've been away for a while and am trying to come up to speed on some
pretty significant developments in the pylons community. I've spent
considerable time with the pyramid docs in the last week but have
failed to find an answer to one very important question: If your goal
(like mine) is to build web apps, what reasons do you have to switch
to pyramid?
Let me engage in a bit of flame-fanning here just to make a point. As
of right now, pyramid and pylons (v1.0) are, effectively, competing
technologies. They are competing for the mindshare amongst Python web
application developers. When our BDFLs tell us that pyramid is an
improvement over pylons, I believe them but I don't particularly care.
As an app-dev, I am pretty much agnostic to things like pylon's
extensibility model (http://docs.pylonshq.com/faq/
pylonsproject.html#why-not-just-continue-developing-the-pylons-1-0-
code-base). What I care about is how quickly and easily I can get my
app up and running, how easy it will be to support and maintain.
Bottom line, I think the BDFLs have punted on making a pro-pyramid
technical argument to their app-devs, maybe because there isn't one to
be made.
Flame-fanning finished. And I was lying about not caring. *I BELIEVE*
and I want to see pyramid go forward. But in the end app-devs are the
least of pyramid's worries; we're always looking for excuses to learn
new things. Middle managers are much more difficult to convince.
Hence, I'm calling for some management-friendly pro-pyramid
propaganda: https://github.com/Pylons/pylonshq/issues/issue/2. If
you're an app-dev trying to figure out how you're going to convince
your manager to let you learn pyramid, bump it up!
Cheers, all! Sorry for the mischief!
~br
Chris McDonough
By way of apology: Pyramid was "released" (more like escaped) a lot
earlier than we would have liked. Though the codebase and docs were
ready very quickly (because Pyramid is basically a rebranding of an
existing web framework named repoze.bfg), lots of the infrastructure
surrounding it was not as baked as we would have liked it to be. For
example, if you look at pylonshq.com right now, there's no mention of
Pyramid. Effectively, we made the mistake of putting the codebase up on
Github, which forced us to announce the project earlier than we would
have liked to, because the cat was out of the bag for all to see. If we
hadn't made an announcement, even though we weren't really fully
prepared, it would have left a lot of people a lot more confused than
they are right now.
Apologies aside, to your point, though: yes, we should have some sort of
suit-friendly decision-tree-ish thing that allows people to make a
choice between Pylons and Pyramid. We don't, and that's a shame (see
above). However, despite having fairly polished documentation, and a
long history, Pyramid is still technically alpha software and may change
arbitrarily across alpha releases. As a result, nobody except very early
adopters (read: not suits or folks who need to please suits exclusively)
should really be running it in production or starting new development
projects with it. With that in mind, extremely conservative developers
(or those who need to please extremely conservative bosses) should
almost certainly use Pylons, and should not really even consider the
existence of Pyramid at all.
On the other hand, the Pylons development team has committed to Pyramid
as the web framework they'd like to spend time improving for at least
the next few years. Part of the set of improvements will be, over time,
a set of materials that makes it clearer what improvements Pyramid
brings to existing Pylons developers. In the meantime, though, my
advice, if you're an extremely conservative developer, or a developer
who needs to please extremely conservative bosses, use either Pylons or
repoze.bfg.
- C
Ben Bangert
> I've been away for a while and am trying to come up to speed on some
> pretty significant developments in the pylons community. I've spent
> considerable time with the pyramid docs in the last week but have
> failed to find an answer to one very important question: If your goal
> (like mine) is to build web apps, what reasons do you have to switch
> to pyramid?
If you don't need the extensibility, if you're building a single app for the whole company. You probably don't have much reason to change at all. The fact that you haven't seen some pyramid add-on you're dying to use already sort of answers that.
> Let me engage in a bit of flame-fanning here just to make a point. As
> of right now, pyramid and pylons (v1.0) are, effectively, competing
> technologies. They are competing for the mindshare amongst Python web
> application developers. When our BDFLs tell us that pyramid is an
> improvement over pylons, I believe them but I don't particularly care.
> As an app-dev, I am pretty much agnostic to things like pylon's
> extensibility model (http://docs.pylonshq.com/faq/
> pylonsproject.html#why-not-just-continue-developing-the-pylons-1-0-
> code-base). What I care about is how quickly and easily I can get my
> app up and running, how easy it will be to support and maintain.
> Bottom line, I think the BDFLs have punted on making a pro-pyramid
> technical argument to their app-devs, maybe because there isn't one to
> be made.
We aren't preaching the gospel on Pyramid right now because it's still alpha. As I mentioned on my blog, I'll be writing posts about things Pyramid addresses in the future, until then, I'm sorry, but you'll have to wait like everyone else. I only have so much time in the day, I have to budget my time very carefully.
> Flame-fanning finished. And I was lying about not caring. *I BELIEVE*
> and I want to see pyramid go forward. But in the end app-devs are the
> least of pyramid's worries; we're always looking for excuses to learn
> new things. Middle managers are much more difficult to convince.
> Hence, I'm calling for some management-friendly pro-pyramid
> propaganda: https://github.com/Pylons/pylonshq/issues/issue/2. If
> you're an app-dev trying to figure out how you're going to convince
> your manager to let you learn pyramid, bump it up!
When we're ready for management types to move entire development shops to Pyramid, we'll have that documentation. Right now, the focus isn't on that, its on getting things done so that such a case will be trivial to make in the future.
Cheers,
Ben
jerry
will be going beta?
Thanks.
Jerry
BrianTheLion
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!
My two cents. Thanks again!
~br
Ben Bangert
> 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.
Cheers,
Ben
Chris McDonough
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
>
Mike Orr
> On Mon, 2010-11-15 at 09:03 -0800, Ben Bangert 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:
Just to expand on these.
> - Pyramid has more complete narrative documentation than does Pylons.
Pylons has a hard-to-fix hole in its documentation: everything
provided by dependency packages. There's a mismatch between what the
dependency docs provide and Pylons users need. For instance,
FormEncode usage, or initializing a Beaker SQLAlchemy backend. Ben
suggested importing the dependency docs and customizing them for
Pylons, but that is a monumental task that would take months,
especially copying in all the API functions (which would no longer be
autogenerated).
Pyramid solved this problem in one stroke because its manual already
covers many of these holes. Several things which are dependencies or
middleware in Pylons are built into Pyramid, or they are being brought
in-house (e.g., Routes), so their docs are more finished and better
integrated. This frees up developer time to work on other aspects of
the framework.
> - You can use Pyramid to create "single file" applications. This means,
> if you wish, you can disuse "paster serve" and its attendant .ini file.
This is useful only for the smallest production apps, but it has a
niche for one-file demos.
> - 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).
> - 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.
It's difficult to unit test a Pylons application because 'config',
'url', and 'app_globals' work as normal only during requests. During
test initialization or unit tests you have to access them in various
special ways, and every time we provide a way, somebody finds a
situation where that way doesn't work. I have gone to implementing
every unit test as a pseudo functional test (using the TestController
infrastucture), but even still it's hard to write all the tests I
want. Pyramid has a much better testing infrastructure (so say Ben and
Chris -- I haven't tried it yet), so that you can initialize tests and
test parts of view logic and other "user data structures" in isolation
-- without running into dependencies on magic globals.
> - 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.
The event system standardizes several special cases that have been
built into Pylons. It can replace .__before__, setting template
globals, replace some middleware functionality, etc. It allows users
to insert their own processing logic, and avoids the need to subclass
PylonsApp or WSGIController for certain customizations advanced users
have wanted. Many of the hooks may not be used much initially, but
people will find reasons to use them later.
> - 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 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.
These two can interact for static folders. By default a static sub-url
is initalized ('/static'). You can also create an overlay (e.g., over
'/') by defining a secondary handler ("controller") to trigger if a
primary handler raises a certain exception. So if the secondary
handler catches HTTPNotFound, it's a de facto overlay. A static
secondary handler would do the opposite of Pylons' default (e.g., it
would serve static files after the dynamic handler has been tried),
which would probably not harm existing applications.
> - 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.
This is another case of moving related configuration closer together.
In Pylons there are two places to restrict HTTP methods, in the route
map or at the action method. If the request doesn't match a
POST-restricted route, it will try another route. If the request hits
a POST-restricted action, you'll get an exception with no fallback. In
Pyramid, you can specify it at the view, and the router will look for
another view that does allow the HTTP method.
Another way to look at Pyramid is like a free-trade agreement. By
removing barriers between Pylons web developers (i.e., letting them
use each other's code more easily, in this case Pylons and BFG), it
allows those developers to create more add-on features over time. You
as an application developer or nervous boss may not see many
advantages at first, but they'll come in the form of more add-on
products over time than would apear otherwise, and access to
previously-inaccessible products. E.g., if it becomes feasable to run
Zope products in Pyramid (which we're exploring for Plone), that could
enable access to its search products and other things.
--
Mike Orr <slugg...@gmail.com>
Luciano Ramalho
--
Luciano Ramalho
programador repentista || stand-up programmer
Twitter: @luciano
BrianTheLion
Alice Bevan-McGregor
The extensibility part seems to make Pyramid source somewhat difficult to read (couldn’t find a definitive entry point after ~10 minutes of idle browsing, found it later after reading some docs) but it makes it incredibly powerful from an end-developer standpoint.
— Alice.
Chris McDonough
> Mike and Chris, what you have written is by far the best overview of the features I have read so far. The docs themselves can be quite overwhelming (there’s a lot there!) but everything I have read here isn’t dry, it’s exciting!
Great.
> The extensibility part seems to make Pyramid source somewhat difficult to read (couldn’t find a definitive entry point after ~10 minutes of idle browsing, found it later after reading some docs)
Reading the tests sometimes helps. Related:
http://docs.pylonshq.com/pyramid/dev/designdefense.html#pyramid-uses-a-zope-component-architecture-zca-registry
> but it makes it incredibly powerful from an end-developer standpoint.
That's the goal, in any case.
Thanks!
- C