Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Django plugins you shouldn't start without

blog.hndigest.com

Post reply on HN
Print view View original

61–70 of 89 posts

Re: Django plugins you shouldn't start without

#61

Post by irahul »

nostrademons wrote: post #59
irahul wrote: post #55

Earlier quoted context omitted.

> Views are functions from Request to Response in Django, The thing that irritates me about django is request is passed as an argument, and if you need if further down the chain, you have to pass it around. I want the request object to be available throughout the request cycle without it being explicitly passed. I like the flask model of importing request when you need it. In Django, I can have a middleware to handle…

That's one of the things about Django that I really like and one of the things about Flask that really scares me. I'm writing a retrospective now about things I've learned in almost 5 years of working on Google Search, and the entry I just finished was "In almost every case where we allowed non-local effects, it has bitten us. Badly." The cost is in understandability, and is usually not apparent when the choice to ma…

> "In almost every case where we allowed non-local effects, it has bitten us. Badly."

But the request object in flask is not global. If the guarantees break(request locals leak to other requests), it will be a problem. I never have had a request local leak in flask. On the other hand, I have ran into cases where I need the request object in django signals. A simple task of getting the full uri requires either a request object(I would say that's bad api but that's how it is in django) or configuring sites. Bad api or not, if I am in a request, I should have access to it, and Django makes it hard. Dress it up if you want to comply with "no globals" - RequestManager.get_current_request(). Though I don't see how that's any better than `from flask import request` when you know it does the equivalent RequestManager.get_current_request() internally.

Re: Django plugins you shouldn't start without

#62

Post by est »

jsmeaton wrote: post #34
est wrote: post #32

Earlier quoted context omitted.

How about in Round 7 that Python surpasses Nodejs? http://www.techempower.com/benchmarks/#section=data-r7 Python didn't beat NodeJS in Database queries though. Yes Go is fast, but Go is also cluttered with its static type system. Personally I feel pain to deal with flexible JSON marshal/unmarshal, in Python dict() is nearly 100% identical with JS objects in value.

> How about in Round 7 that Python surpasses Nodejs I can't find what you're referring to. Node was still infront of Django in the JSON benchmark. Django (until 1.6) hasn't had connection pooling for the database either. Updating those benchmarks with pooling should make significant differences. But my point was that the framework itself can have a huge impact. Database and other I/O does have overhead, and it may ev…

You are comparing a Web framework (Django) with a language+network runtime (Nodejs).

The Nodejs web framework is Express, behind Bottle and Falcon.

Re: Django plugins you shouldn't start without

#63

Post by masklinn »

irahul wrote: post #61
nostrademons wrote: post #59

Earlier quoted context omitted.

That's one of the things about Django that I really like and one of the things about Flask that really scares me. I'm writing a retrospective now about things I've learned in almost 5 years of working on Google Search, and the entry I just finished was "In almost every case where we allowed non-local effects, it has bitten us. Badly." The cost is in understandability, and is usually not apparent when the choice to ma…

> "In almost every case where we allowed non-local effects, it has bitten us. Badly." But the request object in flask is not global. If the guarantees break(request locals leak to other requests), it will be a problem. I never have had a request local leak in flask. On the other hand, I have ran into cases where I need the request object in django signals. A simple task of getting the full uri requires either a reque…

> But the request object in flask is not global.

So you're saying that if I don't use multithreading my global variables are not, in fact, global?

Re: Django plugins you shouldn't start without

#64

Post by sheng »

gpsarakis wrote: post #54

This app proves also very helpful if you use Nginx: https://github.com/andreiko/django_graceful

> Django Graceful is a set of commands for deployment

> of django projects as fastcgi backends.

Or just use uwsgi[1] and supervisord[2] if possible.

[1] http://uwsgi-docs.readthedocs.org/en/latest/

[2] http://supervisord.org/

Re: Django plugins you shouldn't start without

#65

Post by kmfrk »

patio11 wrote: post #10
robomartin wrote: post #4

As someone who is just starting to dive into Django and Python in general I have to admit being confused by benchmark after benchmark that puts Python near to the bottom of the performance curve when compared to other technologies (Go being one that jumps out at me). I have to admit that part of me is wondering if I am making the right decision in investing time, effort and money getting up to speed on Python/Django…

For many web programming tasks, your user-perceptible speed and/or maximum system loads will not be dominated by the performance of your web application but rather by database, I/O (including networking), and client performance (JS performance, aggressive asset caching, CDN usage, etc etc). Go or Java are wonderful languages if you have serious number-crunching needs or if cutting your server budget in half would sav…

And before you do anything else for performance, address the template-rendering in Django: https://speakerdeck.com/nickbruun/lessons-learned-defying-jo....

Re: Django plugins you shouldn't start without

#66

Post by skizm »

Why is south not number one in flaming gold letters? Seriously, south should just be part of django at this point and it is insane that there isn't this functionality built in. Is changing your data models after you started development so crazy?

Re: Django plugins you shouldn't start without

#67

Post by tptacek »

robomartin wrote: post #4

As someone who is just starting to dive into Django and Python in general I have to admit being confused by benchmark after benchmark that puts Python near to the bottom of the performance curve when compared to other technologies (Go being one that jumps out at me). I have to admit that part of me is wondering if I am making the right decision in investing time, effort and money getting up to speed on Python/Django…

I adore Golang, but I would not use it to build a database-backed web application, and would look funny at anyone who did. Golang is a painful language to build conventional web apps in. Stick with Django for now.

Re: Django plugins you shouldn't start without

#68

Post by irahul »

masklinn wrote: post #63
irahul wrote: post #61

Earlier quoted context omitted.

> "In almost every case where we allowed non-local effects, it has bitten us. Badly." But the request object in flask is not global. If the guarantees break(request locals leak to other requests), it will be a problem. I never have had a request local leak in flask. On the other hand, I have ran into cases where I need the request object in django signals. A simple task of getting the full uri requires either a reque…

> But the request object in flask is not global. So you're saying that if I don't use multithreading my global variables are not, in fact, global?

> So you're saying that if I don't use multithreading my global variables are not, in fact, global?

The request object is context local. If there are multiple concurrent requests, all request have different request objects. I don't know what definition of global variable you have, but this is not it.

Re: Django plugins you shouldn't start without

#69

Post by masklinn »

irahul wrote: post #68
masklinn wrote: post #63

Earlier quoted context omitted.

> But the request object in flask is not global. So you're saying that if I don't use multithreading my global variables are not, in fact, global?

> So you're saying that if I don't use multithreading my global variables are not, in fact, global? The request object is context local. If there are multiple concurrent requests, all request have different request objects. I don't know what definition of global variable you have, but this is not it.

> The request object is context local.

The request object is a threadlocal (or, if greenlet is installed, a greenlet-local).

Which is exactly the same as a global variable in a single-threaded program.

Re: Django plugins you shouldn't start without

#70

Post by ris »

andybak wrote: post #60
ris wrote: post #6

Excellent. Pile up your django with extensions, then look forward to the fun when you have to port your app from e.g. django 1.3 to 1.5 and find a new set of versions of all of your dependencies that work nicely together. And of course figure out a migration path for it all. That is, if extension xyz is still maintained at all. Lean is beautiful, people. Carefully assess every dependency you add, as each one has the…

I've had to handle this multiple times as my Codebase was started on Django 0.96 and currently supports Django 1.6 3rd party libraries upgraded painlessly in 90% of cases aside from those few that had been abandoned. And usually they were abandoned because the community had coalesced around a much better library. So 3rd party code? Change a line in requirements.txt and bam. My own code? Had to upgrade it manually eac…

> Change a line in requirements.txt and bam.

90% of the time as you say so yourself.

Post reply on HN