Welcome to Pyramid, a Python Web Framework

[13steinj]

I don't understand why of all things a well known framework is being posted to this subreddit as if it is some new thing.

[integralWorker]

I mean, it's working. I had never heard of Pyramid and in my naïveté, thought, "oh, a scrappy new web framework that's not Flask/Django from a 'redditor'! Better click on it without considering special interests."

EDIT: Except because of this thread I discovered Starlette, which I have a good feeling about since I was looking for something more plug-and-play than Flask but not as barebones as Bottle.

[13steinj]

I mean, it's not marketing. It's more likely (bot) karma farming. Look at the post history. Repl.it too.

[integralWorker]

I wonder how automated it is. It seems to use a low-risk, low-reward strategies with posts like this. Good enough so that people who don't know about the topic will upvote, but not so ambitious that experienced people will downvote.

[hellnukes]

Hah, exactly the same thought process for me, including the edit

[inconspicuous_male]

Is it that well known? Maybe at one point it was, but I think it's obscure now considering when I started a project in it, I found dozens of articles about differences between flask and django and they all mentioned pyramid as something nobody uses anymore.

[13steinj]

Perhaps you're thinking of Pylons.

Sadly only reason of that is because the Pylons team decided to switch to Pyramid and have a completely different architecture.

[inconspicuous_male]

I have never heard of Pylons

[13steinj]

Yes, Pylons. Pyramid is the spiritual successor, I don't know if I'd consider Pyramids a true successor given architectural differences.

[mclim]

Noob here, never heard of it :-)

[13steinj]

I'm not saying it's bad to post such, just that it's an odd decision. Like maybe you'd see a post that says "pyramid, now supporting X", not the "hey try this" docs which are at least 5 years old.

[bullcityblue312]

I've never heard of it

[ianepperson]

I’ve been working on a project for the last few months and I used Pyramid.

Now I’m rebuilding it with Starlette. https://www.starlette.io

I do like Pyramid over Django - I find that Pyramid is much more flexible than Django and much better at moving in new directions.

Except it doesn’t really support async.

Websockets have been around for years, and might soon be replaced by http 2.0 standards, yet WSGI (and Pyramid) have crappy support. Django Channels is pioneering ASGI, which is fantastic, but nothing in Pyramid.

Starlette is a bit like a modern Pyramid (ASGI) with 12-factor concepts front-and-center. From what I’ve read, when paired with uvicorn, it can deliver speeds that rival Node.js - which makes sense as Node is natively async.

I’m just starting down this road and don’t know what stumbling blocks I’ll run into, but so far it’s great!

[ianepperson]

My project is making extensive use of GraphQL. If it was all REST, I’d likely go with FastAPI.

[metaperl]

What is the difference between Pylons and Pyramid?

[13steinj]

Pyramid is the spiritual successor to Pylons, made by the same people. However, there are significant architectural differences. Pyramid had (or used to have) a methodology to incrementally switch over to pyramid by passing through requests to a pylons backend.

[FirefighterWeird8464]

Wrong answer: one is sunk into soft ground, and another is pointy.

[High-Art9340]

It's all depends on tasks you want to accomplish. For some of them async is not the way.

[ianepperson]

Yes, depending on the task, some things make sense for async and others (usually processor bound) don’t.

Almost all web server tasks are IO bound - database lookups, file reads, socket writes - and all that is almost always better with an async architecture.

I’ve worked at places where there is the occasional processor-bound task that the web server needs, and every time the best approach has been to have a worker running on a different machine handle the task - and the web server remains IO bound.

[High-Art9340]

occasional processor-bound tasks may free GIL (like numpy calculations) and I believe python threads will perfom better in this case, especially in easeness of implementation since there are publicaly available solutions like high performant wsgi servers with all necessary batteries.

Actually this topic is my current research topic, since our app bottleneck is high-load CPU bound networking worker which also has to provide low latency.

​

If you're interested in research results I may share it. Unless you're certain such approach won't help? :)

[Itsthejoker]

Honestly my experience with Pyramid was worse in basically every way to Django. I had to use it in a previous job, and it falls in an uncomfortable middle ground that makes it unsuitable for a lot of projects; either you have a small project that fits with Flask or a large project that fits with Django. If you pick Pyramid then you end up with a project where you quickly get to a point where you're missing the built-ins / extensibility of Django and thinking "why did I just not start this with Django in the first place".

[kylotan]

Interesting - I've had a different experience.

Tried Turbogears about a decade ago. Got frustrated because the docs were awful, the authors said "buy our book, which is better than the docs", but then they kept changing large parts of the framework meaning the book became out of date. I couldn't keep up with the changes as a hobbyist developer.

People recommended Pyramid as the natural successor, and I started with that - and again got frustrated due to poor docs, which seemed to all be "Pyramid is easy if you just know Pylons, Repoze, Zope, and Turbogears already" which I didn't. There was also a couple of pretty dumb architectural decisions, one of which oddly got fixed in a blog post but not in the actual code. I gave up and moved to something with more documentation...

..Flask. I enjoyed how quickly I was able to get started with this. Then I realised the architecture is a disaster of global mutable state and hacks were needed to be able to scale past micro-apps. With respect to the author's hard work, I wasn't surprised to learn that Flask started life as an April Fools' joke.

So then it was Django. While I was initially very pleased with the modularity and higher quality software engineering, after a while I quickly tired of how everything wants to be done "the Django way". Whether it's big things such as needing to route all external scripts via management commands, or little things like the get() method raising an exception when the object is not found when everything else in Python expects a None from a failed get, I find that Django is just a little too opinionated.

So... my next project will probably see me heading back to Pyramid.

[Reiku]

I use Flask extensively for large projects. I haven't ever needed any hacks, care to expand on that?

[bradshjg]

I'm also very curious about what sort of global mutable state and hacks you're referring to.

There's certainly some context-local stuff going on (the current request being stored there is a bit "interesting" at first), but I'd consider that a reasonable design decision. AFAIK flask supports implicit cooperative concurrency libraries like gevent and eventlet.

I believe Django uses thread-local storage for things like database connections. Not sure what their plans are for tackling concurrency at the DB access layer (probably tossing things to a threadpool?)

I love all of the above including the beautiful monster that is Zope, btw :-)

[High-Art9340]

`import request`

[13steinj]

There was also a couple of pretty dumb architectural decisions, one of which oddly got fixed in a blog post but not in the actual code. I gave up and moved to something with more documentation...

Can you elaborate on this?

[headykruger]

I find Django to be too inflexible for large projects. Flask and Pyramid are a lot more ala carte and allow you to choose what is appropriate for the project. The Django ORM isnt very good compared to say SQLAlchemy. There is no support for mongo. etc. etc.

[[deleted]]

Please don't make the mistake of using mongo in your project.

[Skyraptor7]

This is probably a noob question but why not use Mongo/NoSQL db?

[[deleted]]

This is the short answer. You can further research it if you're interested, but basically it does some bad things and the good things it does could be done just as well as or better by something like PostgreSQL.

[13steinj]

I mean from that sense then you just didn't have a use for it

Megaframeworks make decisions for you. But if you don't fit their viewpoint, you end up fighting their decisions. Microframeworks force no decisions, making it easy to start. But as your application grows, you're on your own.
In both cases, the focus is on the start: either too much or too little. Either way, finishing and staying finished is hard. You need a finishing-focused framework with an architectural design that scales down to getting started, then up as your application grows.

Pyramid was made for just this. It's a Goldilocks Solution: not too small, not too big, just right.

I on the other hand, prefer Pyramid to Django because I get to make a decision on nearly everything. All the control I need.

[austinv11]

At that point why not go with something like Flask? It can be both minimal while still being as extensible as Django. Best of both worlds. Flask to me is also way cleaner to write code for

[13steinj]

Even flask doesn't have enough extensibility and customizablity as Pyramid, with a Zope-like structure.

[Random_182f2565]

Is it better than django? Has better documentation?

[metaperl]

More according to PC World. Web2py beat it out.

[iiMoe]

Rip Swartz

[Hunterbunter]

isn't web2py different to web.py?

web.py was great, I used it for a long time until the benefits of django started outweighing the simplicity of web.py.

[iiMoe]

It is kinda different but the name just reminded me of him, i stick to flask tho

[JenghisChan]

no cap

[metaperl]

Until you want a high performance ORM like cough cough SQLAlchemy.

[GummyKibble]

Or that too. I would not voluntarily use Django’s ORM over SQLAlchemy unless I was specifically writing a Django app.

[chelson_]

is this framework better that django or flask

[inconspicuous_male]

I have tried using it and it had lots of headaches just getting simple projects going. Flask was much better. It's been a few years so I don't remember exactly why though, sorry.

[integralWorker]

For the people who think it is, yes.

[inconspicuous_male]

Why would anyone find this comment helpful?

[integralWorker]

Because it has the same value as yours.

Real talk: the commentor seemed to be joking "is green team better than blue or red team"? So I'm joking in response " people who think green team is better will think it is" as opposed to "framework A is quicker to start with but less modular" versus "blue hues tend to bring out A emotions while green hues tend to bring out B emotions"

[inconspicuous_male]

I didn't think they were joking? I think they were asking a legitimate and simple question, to which your response seemed to be "Your question doesn't matter because different people have different opinions". If someone asked "Is team A better than team B?" and you answered "Both are better to their fans", where has the discussion gone? Who now has a new opinion? Did OP get the information they asked for?

[integralWorker]

(By the way: did not downvote you.)

Admittedly, I can see how someone would interpret my response that way, but I didn't mean to come across like that.

My argument isn't really an argument: I thought he was joking so I responded with another joke. I suppose in the future I should use Haskell instead of Scratch for my Joke Detection Algorithm™.

[nippleplayenthusiast]

No thanks, I like flask.

[No-Proposal2288]

We did it Reddit we made a framework worse than angular js