What is and isn't Pyramid

[Paul Everitt]

The discussion about docs turned into a discussion about Pyramid and target markets. Which was perfect, as Blaise and I are in some chats about related topics.

Rather than hijack that thread, I thought I'd start a new one. What is Pyramid? And even more difficult, what isn't it? (I am a staunch believer in focus and having the courage and honesty to say "that's not us, you're better served elsewhere.")

I'd like to listen to more ideas from insiders and casual developers about:

- Who Pyramid appeals to

- What differentiates it (in a no-bullshit, honest-to-goodness way)

- What is an unmet need in the Python web frameworks space that Pyramid does a good job of itch-scratching for

--Paul

[Krishnakant Mane]

Hello paul.

I think Piramid is a framework for complex web applications (easy ones
are easily done using DJango ).
It can also be used to just develop a web front end for an already
existing service based on xmlrpc or soap.
The stacked approach is what I personally feel makes it stand out from
the rest, although I guess turbogears does the same.
Happy hacking.
Krishnakant.

[Joe Dallago]

I would say the above is a pretty good description.  I will just chime in with my experience.  So I have been hacking with Pyramid for the last two years or so, one of which as been spent mostly on a single web app.  The web app I'm working on has some pretty specific constraints, and at the end of the day I want to be able to control the full stack down to the last tiny detail, so I can provide the best user experience.  Pyramid is ideal for this kind of situation, b/c it's so easy to swap any part of the stack in and out.  For example, I had a month stint where I was experimenting with using the same templates on the front/backend.  I was able to switch out my template rendering engine with very little work to accomplish this.  A month later when I decided it wasn't a good fit for me, I simply switched it back.  All the while I was able to keep the rest of my code intact.  I would say Pyramid isn't unique in this specific example(b/c you can do the same in other frameworks), but it accurately describes the general idea behind the framework, that every part of the framework should be easily interchangeable.  Key word being "easily."  B/c I'm a strong believer that every non-trivial web app reaches a point where it outgrows the framework, and you'll have to start reverse engineering parts of the framework to do what you want.  With pyramid you generally don't have to do any reverse engineering, b/c it leaves all of the big design details to you.

So that's kind of a long winded way of saying that Pyramid is for applications with very specific needs.

--
You received this message because you are subscribed to the Google Groups "pylons-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pylons-discuss+unsubscribe@googlegroups.com.
To post to this group, send email to pylons-discuss@googlegroups.com.
Visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[Robert Forkel]

The thing that differentiates pyramid from the rest for me is the
configurator. My use cases in the last 2 years have been applications
which will be installed multiple times with wildly varying
configuration, and different applications which share a lot of
behaviour. In one case, I used a shared pyramid app, which can be
configured with a python config package providing an includeme
function. In the latter case, my shared behaviour comes from a library
providing the includeme function.
This and the ZCA which I can use via the registry make it easy to
write extensible apps.
best
robert

>> email to pylons-discus...@googlegroups.com.
>> To post to this group, send email to pylons-...@googlegroups.com.

>> Visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>

> --
> You received this message because you are subscribed to the Google Groups
> "pylons-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an

> email to pylons-discus...@googlegroups.com.
> To post to this group, send email to pylons-...@googlegroups.com.

[tonthon]

From my personnal experience, I like Pyramid :

- I think it's a good deal that satisfies my taste to make things by
myself with the comfort of a well built framework.
- It always fits very well with existing contexts :
** moving a php app to pyramid
** integrating pyramid with os tasks, with other web-apps
- I can write a rest api in a few lines
- I don't feel stuck to my initial choices when my app is evolving
- Our business is based on non-trivial solutions and it's sometime
adventurous to start a project, when it's about web stuff Pyramid is
always a trustable choice

I don't think beginners should start with Pyramid, since there are many
choices to make (traversal or dispatch, form libraries ...) and nobody
make them for you. It could really become a mess to maintain.

I would never say pyramid does something that others don't, I'm not
omniscient. I would promote things that pyramid does, because it does it
very well. I like it's view configuration, it's traversal api that
allows to do so much things, its configuration abilities and much more :).

Cheers,

Gaston


Le 29/03/2013 17:46, Paul Everitt a �crit :

[Whit Morriss]

I encountered a quote recently that "Rails is omakase, node is street food." It struck me as being sort of applicable to the "what is" question around pyramid.

Most web frameworks *are* omakase ("I, developer, leave all my decisions to you, all knowing framework author person"), while pyramid is dim sum.

This means lots of choices, but very few that cannot easily be undone or redone when a situation requires change. These choices are presented in a regular and therefore understandable format, which actually keeps the number of concepts you have to understand to be useful w/ pyramid pretty small while not reducing one's flexibility or power. T The only two things pyramid forces you to use are the configurator and the router. With such a small core, he learning can be bite-sized (though I don't think I've seen it presented as such other than perhaps groundhog).

Pyramid makes writing and using extensions and plugins stupidly easy, so creating your own personal framework tailored to your own personal usecase or style of development is a natural outcome over time with pyramid. This quality contrasts the usual outcome over time for framework usage which usually results in bloat, framework vivisection, anger, depression and general arthritis followed by new framework selection, porting, rewriting, rinse and repeat.

-w


d. "whit" morriss
Platform Codemonkey
wh...@surveymonkey.com

[Jonathan Vanasco]

A couple points from experience:

More so than ORMs, random features, extensibility, flexibility, Magic
going on behind the scenes -- Pyramid lets the development team and
product managers decide where the Technical Debt and Bottlenecks will
be -- and is designed in a way that you don't have to scrap your
entire project when you're refactoring later on. You don't get that
in most other frameworks -- whether they're low level or high level.

In order to get a project up and running in Pyramid vs Django/Rails
I'll often see something like this:
- Weeks 1-12, the higher level framework progresses much faster with
deliverable/usable features.
- Weeks 8-20, the higher level framework begins to deliver fewer
features each day. more work is spend configuring different plugins
and coding 'around' various framework options. the lower level
framework begins to pick up speed in delivering ticketed items.
- Weeks 20+, the lower level framework has a faster velocity in terms
of delivering features.

Small projects - both for size and duration - are really great on
higher level frameworks . Django/Rails/etc are damn-perfect for
advertising campaigns, brand promotions, one-off online experience.
When it comes to online businesses and applications that span years,
high level frameworks start to be a huge concern. For example :
reddit is still on Pylons while Twitter has been increasingly
offloading more and more of its functionality onto C/Scala/etc.
today , twitter is much larger and more 'real time' than reddit, but
their need to refactor started years ago as did their problems with
being built on a higher level framework.

I've never met a "Pyramid Developer". I've met many "Python
Developers" who use Pyramid. Conversely, I know many "Rails
Developers" and "Django Developers" , who would not consider
themselves to be "Ruby" or "Python" developers -- and largely aren't.
The bulk of their ability and work experience is with the Framework --
not the language.

[Roberto Guerra]

I totally agree with what you said about "I've never met a Pyramid Developer. I've met many Python Developers that use Pyramid".

I've been using Python for about a year now. Before that I was a java/groovy developer. I still do java/groovy for clients, it pays my bills. But for greenfield projects where I have carte blanche I have chosen Pyramid. Before delving into Python and Pyramid, I was assessing Rails then Django. Both frameworks seemed different than the language they were implemented in. And it required more time to be productive with it. While with Pyramid, I only had to learn Python and a small subset of how to wrap my application with Pyramid to expose it over a web interface.

I'm very happy with that approach. I write my application as a pure python module that I can test independent of Pyramid, and my views are only thin wrappers that make requests to my application. Even the persistence layer is a separate module that is implemented with SQLAlchemy and I can test that independently and deploy upgrades, patches and new features independent of the web framework & the business logic. I don't even need to restart Pyramid. Just run python setup.py install on the module and it is deployed. I wish there was a port of Pyramid( & SQLAlchemy ) in every language.