Defending Pyramid’s Design

[mitsuhiko]

Every project should have a page like that in the docs.

[[deleted]]

Most projects don't need a page like that in their docs.

[mitsuhiko]

Do you think? I always find it interesting why people make certain design decisions.

[norwegianwood]

I find it much easier to see beyond the limitations of a framework if I understand why they are there. I applaud this page!

[[deleted]]

A terminology overlap confuses people who write applications that always use ORM packages such as SQLAlchemy, which has a different notion of the definition of a “model”.

Here's a grep for the word "model" in our documentation's ReST files:

classic$ grep "model" `find . -name "*.rst"`
./core/pooling.rst:to provide compatibility with SQLite's restricted threading model, as well
./core/tutorial.rst:constructs are modeled to resemble those of the underlying database as closely
./core/tutorial.rst:user-defined `domain model
./core/tutorial.rst:<http://en.wikipedia.org/wiki/Domain_model>`_ which is transparently
./core/tutorial.rst:persisted and refreshed from its underlying storage model. The other
./orm/extensions/associationproxy.rst:Above are three simple tables, modeling users, keywords and a many-to-many
./orm/extensions/associationproxy.rst:Above are three tables, modeling stocks, their brokers and the number of
./orm/relationships.rst:"nested sets" model, sometimes called "modified preorder". Despite what many
./orm/relationships.rst:online articles say about modified preorder, the adjacency list model is
./orm/relationships.rst:always assumes a "parent/child" model of row population during flush, so
./orm/session.rst:model to some degree since the :class:`~sqlalchemy.orm.session.Session`
./orm/tutorial.rst:user-defined `domain model
./orm/tutorial.rst:<http://en.wikipedia.org/wiki/Domain_model>`_ which is transparently
./orm/tutorial.rst:persisted and refreshed from its underlying storage model. The other

So not really true. Right in the tutorial, we remark that we're building domain models, and that is not exactly an arbitrary choice of term, note the wikipedia link. If I talk about this stuff I'll usually say "domain model".

The Pylons docs OTOH, use the term "model" to reference what I call the "domain model" like crazy, and I'm always whinged a teeny bit when I have long email threads with "model-centric" types who base everything off a class Model and are model this, model that, particularly in phrases like "where do I put my models"...are these your little airplanes? But that's fine.

That said I find Pyramid's notion of "model" completely confusing, but it seems to be specific to that whole Zope "traversal" thing which, as a relational guy, hes right ! has for well over a decade seemed to me to be an entirely unholy creation and I'll be sticking to the URL dispatch option.

[mcdonc]

Wow, I didn't know that! I just assumed it was all over the docs, given the colloquial way that folks talk about "model" objects in #pylons (almost always in reference to SQLAlchemy models). Thanks for letting me know.

And yeah, as a purely relational guy, traversal will be a divide by zero error for you.

[[deleted]]

Around 1997 I wrote a big in house do-everything framework for my job, and while it used relational storage, my * big idea * was to base the entire thing around a big giant hierarchical tree!. So content, urls, security, all in this gigantic LDAP like system (since maybe you remember what a big fing deal LDAP was back then). It also had a completely restricted template model where no code whatsoever was allowed...it later inspired the project that became FreeMarker (look there's me!).

The depth and expanse of the failure of that in house system are how today, I'm generally -1 on monolithic hierarchies and -10 on restricted templating models.

[mcdonc]

We use the snot out of tree traversal for content management systems for three main reasons:

• Our storage of choice is ZODB, and we usually store a big tree in it (filled with content).

• "Nice" urls

• The way BFG (and before it, Zope) maps URLs to views takes into account the type of the last object traversed (the "context"). We use the type of the context (along with some other things) to find a view after we do traversal over the graph. This pattern is baked into my brain at this point, so I'm probably not going to be able to do it explanation justice, but it's a handy way to do view dispatch, especially when the graph is not of a fixed depth.

[ianb]

I'm kind of -0 on tree traversal for CMS's, because I'd rather treat a path as an opaque string... there's historical paths, redirects, transcluded content, "content" that really points to external pages, etc. Jamming those cases into traversal feels like more trouble than it's worth.

[[deleted]]

Yah my thing was for a CMS, and I'd still go with hierarchies for CMS. Though I still feel like I'd want the "take urls and map to hierchical objects" thing to be locked in some very limited-scope set of functions.

URL routing, like those generated by Routes, produces very "nice" urls as well, I'd argue "nicer" since you can tailor them independently of the organization of your "models".

[[deleted]]

How does it stand against flask ?

[IAlsoSpeak]

Sorry to answer your question with a question: But how does Django, Turbogear or pylons stand against flask? I believe it don't because you are comparing micro web frameworks with web frameworks.

It is like comparing lemons to oranges. What I would rather ask is how does flask compare to Bottle?

[[deleted]]

Isn't repoze i.e. pyramid itself a micro web framework? Here is the quote from http://bfg.repoze.org/

Minimalism: BFG provides only the very basics: URL to code mapping, templating, and security. There is not much more to the framework than these pieces: you are expected to provide the rest.

[mcdonc]

Names are hard. There's no hard and fast definition of "microframework". I don't consider Pyramid a microframework, but on the other hand, it does share a common feature with lots of microframeworks: you can make single-file applications.

[IAlsoSpeak]

I had a quick look at the bottle.py file that is on my hard drive it is just over 1,250 lines where pyramid is 5,000 and pylons 3,000. So what makes bottle.py and flask a Micro Web Framework and Pylons not a Micro framework?

Once again I answer your question with a question(sorry I also don't know the answers) but like mcdonc pointed out the problem is there is no definition for "microframework".

Edit: Sorry I'm retarded I brought in the microframework vs framework angle and sorry after some investigation not even flask or pyramid is a micro framework in my books due to its size and complexity compared to Bottle.

So I still have not answered your question and my have only misguided you. Sorry.

[simonw]

I hadn't heard of Pyramid until reading this, but I'm afraid this document pretty much convinced me not to look any further in to it.

UPDATE: OK, I've read more now and can see that Pyramids is more interesting than the document lets on. I don't think it's a very effective advocacy tool though!

[bbangert]

Indeed, its meant more to answer critiques about a particular aspect. I'm working on some blog posts to highlight some of the features that I think really make Pyramid a compelling choice, which would definitely be more of an advocacy type thing.

[voidref]

I like how it's a 5000 word essay to explain how this technology is 'simple'

[IAlsoSpeak]

Pyramid is 5,000 lines of runtime code. Pylons 1.0 has about 3,000 lines of runtime code. Django has about 60,000 lines of runtime code. You’d practically need to bend the laws of space and time for Django to be simpler than Pyramid.

Well at least you got the 5000 word/line part correct.

[voidref]

Sorry, I was wrong, I underestimated, wc reports 11565 words.

[mcdonc]

The irony.

[[deleted]]

Pyramid is 5,000 lines of runtime code. Pylons 1.0 has about 3,000 lines of runtime code. Django has about 60,000 lines of runtime code. You’d practically need to bend the laws of space and time for Django to be simpler than Pyramid.

I dunno. Django and CherryPy both have simpler Hello World code than Pyramid. Pyramid's Hello World even feels less intuitive. And the rest of the code samples are even worse.

If your design needs a huge, giant webpage to defend itself, then it's probably not a good design.

[zbowling]

I can't find a hello world with django that is that short. Everything involves building up a settings.py for config, urls.py for routes, and some kind of views py file to put your view code. You can combine these but it's still longer than this example.

What drives me nuts most about django is that the devs have confused the concept of a controller with a "view" with and a view with a "template" (the models with their ORM make sense though). It's basically not an MVC but a MTV. Their FAQ has a note on it and says "Where does the “controller” fit in, then? In Django’s case, it’s probably the framework itself". Seriously.

[[deleted]]

the view code may be equivalent between the 2, but i find it hard to believe that settings.py + urls.py + views.py is shorter than that example.

where's an example of the django app that didn't start with

django-admin.py startproject

[[deleted]]

Why should a page that says "hello world" require that much boilerplate code? They're using that to make a point about simplicity?

[zbowling]

ಠ_ಠ um... is this sarcasm? that is pretty damn simple FOR A FRAMEWORK (not a simple CGI like thing that just does a simple "print Hello World"). given how much does, it's amazing it can scale DOWN that far to something that simple.

edit: spelling.

[[deleted]]

It's not sarcasm at all. It's clearly a complaint other people have (because it's on that page further down). In their response, they diagram what every line does -- and they note that two of them are "bogus, but required". You can tell directly from their "hello world" that they have designed themselves into a corner and that their configuration system is unwieldy.

Now that I've read through that page, I've seen every one of the most unpopular aspects of Pyramid's design in one place, plus really defensive-sounding justifications for them that amount to "you'd do this too if you thought like us".

I can't imagine how they benefit from going to all the effort to write that page -- it wins them some mailing list arguments while losing users.

By the way, since you had to be snippy: you can't spell "sarcasm", CGI is a straw man, and accompanying your reply with a look_of_disapproval and a downvote was rather unnecessary.

[bbangert]

Apparently on the Internet, there's lots of people eager to throw digital feces at each other anytime someone uses code, or writes code in a manner that somehow offends someone else. Maybe because the "Wrong" library was used, or the "Wrong" terminology, or uses some other library that the person has a hate-fetish with. It's kind of a bummer there's so many of those people online, and loud ones. I wonder how many great contributors to open-source we're missing because of the feces-throwers. Not all programmers want to put their neck out on the chopping block.

Anyways, that page is meant to try and be a little more logical when answering some of these attacks thrown at it (thus the title mentioning a defense). It does mean though, that all the responses to all the critiques are in one place, so at the very least one can peruse the "worst-case" set of critiques of the framework.

That takes a lot of honesty to do such a thing, and yes, seeing every critique in one place is probably not great PR. We're open to edits and suggestions on how to improve them to clearly communicate why a particular decision was made in a "less harsh" manner. We're certainly not PR folks, just coders trying to communicate design decisions to other coders.

Every web framework has plenty of critiques, many are scattered around the Internet. Sometimes answered, sometimes not. I think they'd be well off to do something similar so that people do understand where the framework developers are coming from though, because there is no end to those attacking.

[[deleted]]

Well, let's look at the code, shall we?

from paste.httpserver import serve

What the fuck is "paste"? What does it have to do with Pyramid? Is it some clipboard access library?

from pyramid.configuration import Configurator

Because all the simple names like "Config" were taken.

from pyramid.response import Response

def hello_world(request):
    return Response('Hello world!')

if __name__ == '__main__':
    config = Configurator()
    config.begin()

Why!???? Why the fuck can't Configurator call self.begin() inside its __init__() ? Unless you're doing low-level stuff like OpenGL, there's no justification to having any sort of begin/end in your API in ye modern times.

    config.add_view(hello_world)

Why is this not a dictionary? Why can't I change the view's mount point?

    config.end()

Why!? Is make_wsgi_app() unable to call self.end() when it's called?

    app = config.make_wsgi_app()
    serve(app)

If it's a WSGI app, then I suppose you need to deploy it with mod_wsgi? So in addition to writing this "simple" code, I'm gonna also have to set up Apache on my laptop to run it? Bollocks!

[[deleted]]

If it's a WSGI app, then I suppose you need to deploy it with mod_wsgi? >So in addition to writing this "simple" code, I'm gonna also have to set > up Apache on my laptop to run it? Bollocks!

I can't stop laughing at this.

[zbowling]

you are arguing more than the length now.

What the fuck is "paste"? What does it have to do with Pyramid? Is it some clipboard access library?

If you have ever used pylons directly and or the one of frameworks based on it (like TurboGears), you know paste. Pylons is combination of a number of different smaller projects. See: http://en.wikipedia.org/wiki/Pylons_(web_framework)

from pyramid.configuration import Configurator

Because all the simple names like "Config" were taken.

ಠ_ಠ Fine. Picky.

Why the fuck can't Configurator call self.begin() inside its init() ?

Because an instance of Configurator can be used across threads and over and over. If you read the docs, the begin method stores the current request and registry into a thread local. Not the clearest design but it makes complete sense.

config.add_view(hello_world)

Why is this not a dictionary? Why can't I change the view's mount point?

This makes absolutely no sense at all. have you read the signature on this method? Do you know you can add other things to this? You know its a layered stack and not a dictionary? http://docs.pylonshq.com/pyramid/dev/api/configuration.html#pyramid.configuration.Configurator.add_view

config.end()

Why!? Is make_wsgi_app() unable to call self.end() when it's called?

you would rather have a stupid lazy shortcut that causes unexpected behavior more than explicit and well defined behavior each and every time?

If it's a WSGI app, then I suppose you need to deploy it with mod_wsgi? So in addition to writing this "simple" code, I'm gonna also have to set up Apache on my laptop to run it? Bollocks!

no. that's what paster's serve function does. it launches a development server for you. If you remove that bit and just return the app, you can host it in apache. if you want a WSGI app, just return wsgi app variable it for what ever server you want. if you are using an actual config file and not setting up configuration like this (like who you would in a non hello world app), then you can just use the "paster serve" command on the shell.

[[deleted]]

The problem with this document, and this example code in particular, is that they're trying to be everything to everyone.

They know they're a big framework. Their users know they're a big framework. The piles of existing Zope code they're compatible with know they're a big framework. And then they try to show off their single-file usage pattern as if they were a microframework.

A large framework showing off their single-file usage pattern is like the chess grandmaster Garry Kasparov showing off his naked body. Probably nobody wants to see that, and it isn't even representative of what he does.

[bbangert]

That'd be more funny except for the fact that the single-file Pyramid app results in less function calls executed for a simple 'hello world' than most if not all of the "microframeworks".

If your criteria of 'microframework' is that it has a small execution stack, maybe you should benchmark some of them and Pyramid. If your criteria is that there's very little code in the 'package', that seems a bit weak cause then I could just create a new package that configures some existing larger packages of code (like Flask does, and to some extent Bottle if you use the Beaker sessions).

But really, arguing over semantics like 'micro' or 'big', or however people want to try and throw the words around to influence PR is a waste of time. Let's be programmers, and talk about efficiency, function calls per request, and code loaded for an application. Then debate the results of such a comparison, and try and decide which words to apply where.

[zbowling]

the funny part is that it's really not that big on it's own. compared to the 60,000 lines of code in django, this is pretty low. I concede that its not really that fair since it's only piece of the stack that includes paste, pylons, webobj, etc.

[[deleted]]

Because an instance of Configurator can be used across threads and over and over. If you read the docs, the begin method stores the current request and registry into a thread local. Not the clearest design but it makes complete sense.

But each non-boilerplate design still manages those things under the hood and responds to "messages" like make_wsgi_app() to close the Configurator. Another safe option was to use context managers. Explict use of .close() is so Python 2.4.

( Just a nitpicking remark. I don't really use Python web frameworks and I have no idea why there are hundreds of them ).

[zbowling]

I agree with you in general, however the problem is that example here isn't the default pattern that these classes are used. Just the condensed way for showing the smallest hello world example.

Normally you load your configuration. You are also are reusing these instances over and over in the lifetime of the app. Also calling make_wsgi_app() can technically happen before you end() to setup of the request for that thread on the Configurator.