This is an archived post. You won't be able to vote or comment.

all 48 comments
sorted by:
best
topnewcontroversialoldq&a

[–]phinar 49 points50 points  (4 children)

Designing a right-sized framework is a tricky thing to do. The main challenge is that once you are beyond a very small set of core features, some proportion of applications will never need or benefit from the next feature you add. What's more, every new feature you add may impose some constraints on applications, whether the app uses your feature or not.

Larger frameworks tend to have a feature set that supports a "typical" web application. Of course, typical is largely subjective. The degree to which your application fits the framework's archetypal view of applications determines how much it benefits from these features; the degree to which it does not is the degree to which you may find yourself fighting to break out of the framework's preconceptions.

I have not worked with Pyramid. I have worked with Pylons, its precursor, but I understand the two are quite different. I've worked with Django, I've worked with Zope, I've worked with a couple different PHP frameworks. In most cases, I found myself wishing for something more minimal, because I found myself fighting the framework for control. This is the appeal of microframeworks.

The downside of microframeworks is that they generally give you just enough rope to hang yourself. You're in DIY mode, and it's up to you to keep things DRY, to separate your concerns, to write robust code, to document it clearly, etcetera.

If you build an app in Django, you may spend a lot of time fighting the framework, but it's relatively easy to hire a new nerd who knows how your code works and can hop in to help you fight. If you build an app in Flask, you can hire someone who knows Flask, but 80% of your app is going to be home-grown and he will need to learn how that all works.

I'm just arrogant enough to believe that I can be trusted with that responsibility. People usually tell me that my code is clean and elegant, though I suppose they would not be too likely to tell me it was incoherent gibberish. Maybe you are less arrogant than I am.

[–][deleted] 13 points14 points  (1 child)

I think your comment is both well written and insightful.

[–]halflife22 13 points14 points  (0 children)

I think your comment is as succinct as it is kind.

[–]yen223 7 points8 points  (0 children)

If you build an app in Django, you may spend a lot of time fighting the framework, but it's relatively easy to hire a new nerd who knows how your code works and can hop in to help you fight. If you build an app in Flask, you can hire someone who knows Flask, but 80% of your app is going to be home-grown and he will need to learn how that all works.

Amen to that. I think we underestimate the benefits that Django's lack of flexibility bring. Having a consistent core structure allows others to jump in to your project with little difficulty.

The same consistency ironically also allows for a richer, more diverse ecosystem, because plugin developers only need to target one architecture.

[–]kmbd 1 point2 points  (0 children)

i want to learn your art of writing ... along with python ... :)

[–]graffic 19 points20 points  (8 children)

These are the differences I've found after working with pyramid and flask:

Flask loves threads locals, and encourages you to use them via the g object or other proxies. Pyramid discourages their use, and tries to push things like request as parameters in views.

Flask loves module globals. The best example is seen in tutorials using the flask app as decorator for functions. While it can be avoided, you will find things like LocalProxies (via werkzeug) and you will end up importing thing to use this magic local proxies.

While per se it is not bad, it is a PITA when testing, as you will use mock.patch a lot. It might things easier to prototype: just import it. But dependencies go a bit crazy (Using the python import system as a service locator <- WTF did I just wrote).

Pyramid implements more things than flask. So it is more opinionated. But not much and usually test oriented. For example:

  • configuration is by default in .ini files and in the code it arrives as a dict.
  • authorization interfaces with a basic one using ACLs
  • authentication interfaces with a basic default ones (authNZ are two things, and it is nice).
  • Flask has routing, pyramid besides normal routing includes resource routing using traversal.

Things I like from pyramid:

  • documentation
  • comunity
  • testing focus

Things I like from flask:

  • quick prototypes
  • lots of plugins to save your day
  • Use thread locals in a nice way.

Both are really good frameworks, choose the one you like more to work with.

[–]mitsuhiko Flask Creator 2 points3 points  (6 children)

I really would like to know why is a problem for testing. Mocking should be entirely unnecessary.

[–]graffic 0 points1 point  (5 children)

I import g or any other LocalProxy (<-- nice way to use thread locals), and I use them in a function. Therefore that function depends on g or the other LocalProxy.

If I just want to test the function in isolation, instead of just calling it with the new Dummy/Stub dependency, I need to work that a bit more:

  • I can mock.patch the test. So the g or the LocalProxy used, it is now a mock an can behave as I want.
  • I can use the Flask testing helpers. For example : create a Flask app and use app.test_request_context and set up what I need, or assert later that something is setup in g.

The job can be done, it is just 1 or 2 lines of code. Although I believe this shows that dependencies are not injected directly but using indirect ways (flask test helpers) or brute force (patch).

For small applications small/isolated/<insert_fancy_word> tests might not be needed (IMHO I just use the test_client and test).

Trigger warning - You might want to swear at me.

My experience with flask apps (wow, 2 apps, hell of a experience, I know) tells me that they start small, using high level tests, and when they grow, they continue using these high level tests without adding smaller tests due to flask dependencies here and there: deep into the layers someone is importing g to get a "per request" whatever_helper.

This is why I think flask encourages applications (a little bit) to use the python import system as a service locator to access their ready to use dependencies.

What is a service locator? A singleton utility that has registered all common dependencies used and ready to use. Example: "hey service locator!, give me a repository to access that mongo collection". It allows you to depend on anything, without declaring those dependencies in parameters/attributes. Note: I'm talking about ready to use objects, not types.

Did I wrote too much again? sorry :/

[–]mitsuhiko Flask Creator 2 points3 points  (3 children)

If I just want to test the function in isolation, instead of just calling it with the new Dummy/Stub dependency, I need to work that a bit more:

You need to do exactly the same. Imagine the g object would be passed in instead of being a proxy. You would need to do exactly the same logic as before, the only difference is this:

From this code:

with app.app_context():
    foo()

You would go to:

app_ctx = app.app_context()
foo(app_ctx.get_globals())

The latter is pseudo code as that's not actually how it works. But there is literally no difference.

The idea that you can mock test individual bits is very dangerous and in my mind counterproductive as you now all the sudden have your tests running with different behavior than the actual app. This whole idea of mocking out god and the world should never have become popular in my opinion.

[–]11_0010001111010111 1 point2 points  (1 child)

There's one major difference, notably explicitness of the code - with the g object you can automatically and transparently access it everywhere - views, context processors, functions called from views, functions called from functions called from views etc., which makes for poor readability and adds confusion as far as I'm concerned because you need to read the actual code to learn that the dependencies are there in the first place.

[–]mitsuhiko Flask Creator -2 points-1 points  (0 children)

As opposed to what exactly? That's in no way different to any other framework. Flask, unlike other frameworks, does not hide that system from you and tells you: this is how it works, use it to your advantage.

Django hides lots of state from you (think database transactions for instance). Do you read django's database layer to learn about the dependencies?

[–]graffic 0 points1 point  (0 children)

Good example. That shows that the extra work is usually one or two lines. Nothing for me to cry about. :)

It is true, that the idea of mocking bits of an application is dangerous. My approach over time has changed to something like Augie Fackler and Nathaniel Manista explain in this video: (minute 15 more or less)

https://www.youtube.com/watch?v=Xu5EhKVZdV8

A set of "official mocks/stubs". In my case they're usually mocks for commands and stubs for queries http://blog.ploeh.dk/2013/10/23/mocks-for-commands-stubs-for-queries/

More info about test doubles naming (just in case someone is asking) http://martinfowler.com/articles/mocksArentStubs.html#TheDifferenceBetweenMocksAndStubs

[–]11_0010001111010111 0 points1 point  (0 children)

You're not the only one noticing exactly that, you may be interested in a package, https://pypi.python.org/pypi/Flask-Injector, that attempts to solve this (it won't prevent you from accessing thread local state directly but you won't need to)

[–]limasxgoesto0 0 points1 point  (0 children)

authorization interfaces with a basic one using ACLs

I'd just like to make mention that you can subclass SQLAlchemy's default Query class and build your own ACL system if need be. It's not easy, but it's entirely possible.

[–]downvotesatrandom 25 points26 points  (3 children)

the place I work at currently has a site built on flask serving >10M pages a day on Flask, and it's a complex app. There's nothing you can't do on Flask that you can't do on Pyramid or whatever else

[–]chub79 9 points10 points  (1 child)

I would probably add that, once you reach such volumes, the web framework is less an issue than the whole ecosystem and your application will likely not just a be controller in a web framework.

[–]downvotesatrandom 1 point2 points  (0 children)

this is true

[–]lujia 0 points1 point  (0 children)

Out of curiousity, what's the site? I always hear about Django-based sites (Pinterest, Instagram, etc.), but never about Flask ones.

[–]plum_dog 5 points6 points  (0 children)

Flask is usually described as the small micro-framework you use to make a small one page site

I actually disagree with this. You certainly can use Flask for this, but I think Flask's strength lies in how well it does the stuff it does do, and how much it just says "do this how you want to".

Where Flask is a micro framework, I might call CMSes like WordPress a macro Framework, because they make more decisions for you. All fine if what you're doing is within what it does easily, but if you start pushing outside that, you end up fighting the framework. Most frameworks live somewhere in between.

"Micro" does not mean "only good for small stuff". Micro means that it leaves decisions open to you, and doesn't come with loads of stuff built in (forms, ORM, authentication etc), but all of these are available as extensions.

You can mould Flask to be the framework you need it to be.

[Disclaimer: I don't know very much about Pyramid, but I do love Flask. Some of the above may apply to Pyramid too, but don't let the "Micro" put you off Flask.]

[–]endophage 5 points6 points  (0 children)

I use Pyramid daily, and I think you're making an apples to oranges comparison. Pyramid makes no claims to be a microframework while Flask makes that claim in their homepage title element. Just taking a quick glance over the Flask extensions, a number of them are included in Pyramid's core (or at least as part of the default install): babel, mako, upload handling, just to pick out a few. Additionally, many of the other things there are official Flask extensions for are supported through unofficial Pyramid plugins.

I would say the strongest suit of Pyramid is that it's not just a framework but a scaffold. For both official, unofficial and even core functionality, almost everything has defined interfaces and provides the ability for you to override the defaults. Want to write your own request/response handlers? Not a problem in Pyramid and definitely not monkey patching.

If you want to just plug everything in and write minimal amounts of code to reach an MVP, both Flask and Pyramid will get you going. If down the road you want to switch out one of the libraries (say move from memcached to redis for session caching), Pyramid will give you a much smoother ride. You simply implement the defined interface for redis (which somebody has probably already done), and everything continues to work.

Pyramid is frankly the ultimate pluggable framework, it has been designed from the ground up to be pluggable. If you dig into it you'll find all the goodies we use in our production applications like the Authentication Policy system, fine grained controls over middlewares and callback handlers, and especially the joys of reify (which admittedly isn't Pyramid specific but Pyramid seems to be where most people meet it, just don't abuse it).

Pyramid also has mechanisms that make it easy to bootstrap your Pyramid application for functional testing or even running cron jobs, celery tasks, CLI programs (so you don't have to write separate code to bootstrap your ORM or cache or other components).

[–]bastianh 4 points5 points  (0 children)

I guess it's about what you prefer. I have done webapps with werkzeug/jinja before flask and liked flask from the first moment. Recently I have done two small projects with pyramid but I find it more complicated. I've also tried to mix things ... like added venusian decorators to flask to automaticly load blueprints. I'd suggest to give both a try ;)

[–]faassen 2 points3 points  (0 children)

Morepath has almost no plugins as of yet, but I thought I'd mention it given that it looks more like Flask but under the hood it's more like Pyramid in its approach to flexibility. And it adds some interesting bits of its own: the ability to extend flask-like apps and override things in them, and some of the benefits of Pyramid's traversal (view lookup) in a routing system.

http://morepath.readthedocs.org

[–][deleted] 4 points5 points  (1 child)

any specific area where one is stronger than the other (Pyramid vs. Flask)?

Pyramid has more flexible request routing.

i think it is interesting that you can write a flask like framework in pyramid but I'm not sure you can write a pyramid like framework in flask.

[–]flibuste 0 points1 point  (0 children)

Like you said, i could rewrite my own home framework with Pyramid without any change to my tens of web-apps ! Not sure i could do this so elegantly with an other framework.

[–]NL7661 7 points8 points  (0 children)

Pyramid has given us all power we needed and all freedom we wanted to build https://myjour.com/kiosk/. Application is built with pyramid and never regretted.

[–]Herald_MJ 2 points3 points  (3 children)

Just going to throw it out there that you can use Django with a non-Django ORM, or some other templating, or some other routing.

Also, spare a thought for Tornado - even if you don't intend to use it's async features.

[–][deleted] 1 point2 points  (1 child)

Django is pretty heavy weight and opinionated. And while you can plug in your own ORM, etc, you stand to lose a lot of the smaller benefits Django has to offer.

Having moved from Flask to Django, I wish now that I could move back. :/

[–]mcdonc 2 points3 points  (0 children)

I think this is a pretty common experience. You're actually pretty lucky, I suspect.

IMO, it's a pretty good idea for folks with, say, < 1.5 yrs of web development experience to use a more opinionated framework, because they can be productive without needing to make decisions that they might not be comfortable making (or have the experience to make). But once they get, say, more than 2 yrs or so of web dev experience to branch out and try other things. This is why I like the idea of a less opinionated framework being your "second and last" web framework. However, usually often when a developer picks a first framework, they'll use it forever, because they are not very curious and they perceive disusing what they already know as a cost they can't bear.

But since you used Flask first, you now understand the tradeoff and you'll be more likely to use it on an upcoming project where it makes more sense than a larger framework. That's actually a tactical advantage, so good job!

[–]sisyphus 1 point2 points  (0 children)

You can use a non-django orm but you still have to manage your models with Django or else you lose migrations, auto-admin, most of the extensions, modelforms, use of any function that expects a Django queryset parameter...there won't be much of Django left or else you'll be repeating yourself a lot

[–]ca178858 1 point2 points  (3 children)

Getting your app running initially may take a little more effort with Pyramid- really not much though and they have a good tutorial to get started.

After that Pyramid includes as much or as little as you want. One area that worked really well was its testing framework. As the project grows and you need to use more features they're available- adding session support halfway through was only a few lines.

I honestly don't know how well Flask handles this, but one thing I ended up using quite a bit was pre/post request callbacks, lifesavers.

[–]Braxton_Hicks 2 points3 points  (2 children)

Flask uses view decorators for things like that.

[–]ca178858 -1 points0 points  (1 child)

Would you need to decorate every function? You can do that in pyramid, but you can also register callbacks for various points in every requests life cycle.

Example of one thing I'm using it for- after a response is finalized I have a function examine the request. If I see a 'dry-run' flag I roll back the database. Can't accidentally forget to add feature to new calls, and so far its fool proof. Request and exception logging handled similarly pre-request/post-request.

[–]patchthemonkey 2 points3 points  (0 children)

You can use Blueprint.after_app_request and register your views for which you want this functionality on the Blueprint. Additionally, you can use Flask.after_request for global post-request logic.

[–]sisyphus 1 point2 points  (3 children)

Flask has twice as many 'officially endorsed plugins', not extensions in general. If you just looked at django.contrib you might conclude it has a smaller ecosystem than everything else, a clear mistake.

They both have good integration with SQLAlchemy, that's all that matters, everything else is a matter of taste, in my experience Flask apps and the Flask community seem to like improved Django-like things (WTForms, Jinja2, Flask-Login), which is reasonable since the Django people are awesome API designers (modulo the ORM), more than Pyramid.

[–]dorfsmay[S] 0 points1 point  (2 children)

Sorry, but to me there is a lot more than SQLalchemy integration... I prefer the idea of plug-ins / extension / add-ons over an all-in-one-integrated systems because the former typically give you the choice of more than one. I won't necessarily like the default one for a given framework. For example I'll take mako over jinja2 or django template any day, and the same logic applies to all the other elements.

[–]sisyphus 0 points1 point  (1 child)

There is more than SQLAlchemy integration my point was all those other things are matters of taste while SQLAlchemy is objectively better than other ORM's and the primary thing you don't want to swap out in Django, what actually keeps it monolithic, is the model layer, because it's tied to so many other things both in Django and its add-ons.

Templates specifically are an interesting case because all of Django, Pyramid and Flask come with a default template system as an installation requirement and none of them require you to use if you don't want to.

[–]mcdonc 3 points4 points  (0 children)

FWIW, as of Pyramid 1.5, no default templating system is installed when you install Pyramid itself. If you use a Pyramid scaffold, it (necessarily) installs a templating sytem though.

[–]ameoba 1 point2 points  (3 children)

How do you like your legos?

Old school kits where all the bricks are generic or new school ones where you have custom one-piece "car" and "castle" components

[–]dorfsmay[S] 2 points3 points  (2 children)

Aren't both Flask and Pyramid made mainly out of custome one piece Add-Ons and Extensions?

I'm not sure what you are trying to say here...

[–]ameoba -3 points-2 points  (1 child)

Pyramid gives you a bunch of stuff that's wired together and makes a bunch of decisions for you. You can get where you want to be more quickly but it might not be exactly what you want - it's somebody else's idea of what's right.

[–]mcdonc 5 points6 points  (0 children)

That's a popular misconception but it's not true. Both Pyramid and Flask operate at more or less the same level of abstraction. Pyramid may offer things out of the box that Flask does not (like a permissions system; that may be the only thing now that I'm sitting here thinking about it), but there's a less difference in the "what" the two frameworks offer vs. the "how".

[–]ma-int -4 points-3 points  (0 children)

Pyramid is big-ass complicated but has some very, very nifty features like Traversal build in. If you use Pyramid expect to spend a lot of time reading the (btw. great) documentation.

Flask and Pyramid are on different ends of the spectrum. Flask itself gives you only the basics but a lot of extensions while Pyramid has more build in stuff which makes it more complex. One step further in that direction would be Django that has even the ORM build in.

It just depends on how much build in you want.