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

Eighteen months of Django

dangoldin.com

Post reply on HN
Print view View original

31–40 of 85 posts

Re: Eighteen months of Django

#31

Post by tacticus »

obviouslygreen wrote: post #21
hiddentaco wrote: post #18

Great short and concise article. I'm in the process of writing a pet project using Django and would really appreciate your insights on what packages you find useful (as mentioned at the bottom of your post).

From someone who wasn't asked but has input... ;) It's not a Python package in the sense that you might mean, but using virtualenv is absolutely fundamental to good Python development (at least the kind that lets you keep your sanity). South is also exceptional; however, the developer recently ran a successful Kickstarter campaign dedicated to creating an improved version intended to be merged with Django itself, so…

So a stupid question about virtualenv for you. Why does it default to full paths for everything?

Re: Eighteen months of Django

#32

Post by obviouslygreen »

tacticus wrote: post #31
obviouslygreen wrote: post #21

Earlier quoted context omitted.

From someone who wasn't asked but has input... ;) It's not a Python package in the sense that you might mean, but using virtualenv is absolutely fundamental to good Python development (at least the kind that lets you keep your sanity). South is also exceptional; however, the developer recently ran a successful Kickstarter campaign dedicated to creating an improved version intended to be merged with Django itself, so…

So a stupid question about virtualenv for you. Why does it default to full paths for everything?

Honestly, I have no idea. I haven't ever tried to move a virtualenv, and it's not something that's supposed to be part of your repo (you should build your env separately on every box; it's intended to encapsulate dependencies from the system, not to transfer them around with your code).

If your system gets updated/upgraded to the point where your virtualenv breaks, rebuild it from scratch; all it should take is a bit of time.

[edit: I am not a developer involved with virtualenv, and the statement about what it's intended for probably shouldn't be quite so strong, as this is only my impression of it and the way I use it.]

Re: Eighteen months of Django

#33

Post by hiddentaco »

obviouslygreen wrote: post #24
tomkinstinch wrote: post #20

I'll add that if you need to background anything, django-celery makes it easy. celeryd is also good for scheduling tasks with either single or periodic execution. http://docs.celeryproject.org/en/latest/getting-started/firs... You can also use it in a typical task queue role. It will pickle or serialize the Python objects that accompany tasks for transmission over the wire.

Note that periodic execution, one of the more useful aspects of celery, is not supported on all backends. If you're using rabbitMQ, you're golden. If you're using most or all other transports (including SQS), you're likely SOL and will have to resort to either bare cron jobs or something like django-cronograph that accomplishes the same thing. celery is definitely nice, but it does have its limitations (like everythi…

I'm really interested in peoples opinion on Celery vs Others when using Django.

I'm about to hit a point in my pet project where I need something but I havn't chosen my approach yet. I've ehard Pyres is better than Celery.

Re: Eighteen months of Django

#34

Post by obviouslygreen »

hiddentaco wrote: post #33
obviouslygreen wrote: post #24

Earlier quoted context omitted.

Note that periodic execution, one of the more useful aspects of celery, is not supported on all backends. If you're using rabbitMQ, you're golden. If you're using most or all other transports (including SQS), you're likely SOL and will have to resort to either bare cron jobs or something like django-cronograph that accomplishes the same thing. celery is definitely nice, but it does have its limitations (like everythi…

I'm really interested in peoples opinion on Celery vs Others when using Django. I'm about to hit a point in my pet project where I need something but I havn't chosen my approach yet. I've ehard Pyres is better than Celery.

Once you wrap your head around one (embarrassingly, it took me a while to really understand what celery was doing -- I had an easier time getting comfortable with the multiprocessing library), it shouldn't be difficult to pick up another and compare them locally.

Celery does what it's supposed to; that's about all I can say for it. I'd suggest writing a few simple jobs and testing them in similar environments under as much load as you can. Look for things like consistency of logging and running tasks exactly once across multiple consumers despite the semantics of the queue you pick.

Re: Eighteen months of Django

#35

Post by wahnfrieden »

tomkinstinch wrote: post #20

I'll add that if you need to background anything, django-celery makes it easy. celeryd is also good for scheduling tasks with either single or periodic execution. http://docs.celeryproject.org/en/latest/getting-started/firs... You can also use it in a typical task queue role. It will pickle or serialize the Python objects that accompany tasks for transmission over the wire.

We've had a lot of luck just using gunicorn with a post_response hook for doing some extra work without making the client wait on it before getting a response. It avoids adding another dependency and is pretty straightforward. It makes sense for us since we don't have HUGE tasks that need to be queued, but some things that can take a maybe 0.5 to 3 seconds and where the HTTP response can be sent back before doing this work. I should open source this at some point, it's a small amount of code but pretty handy.

Re: Eighteen months of Django

#36

Post by thejosh »

tomkinstinch wrote: post #20

I'll add that if you need to background anything, django-celery makes it easy. celeryd is also good for scheduling tasks with either single or periodic execution. http://docs.celeryproject.org/en/latest/getting-started/firs... You can also use it in a typical task queue role. It will pickle or serialize the Python objects that accompany tasks for transmission over the wire.

Using celery for the first time, coming from PHP-land, blew my mind.

Python is now my language of choice for "getting shit done".

Re: Eighteen months of Django

#37

Post by crdoconnor »

obviouslygreen wrote: post #24
tomkinstinch wrote: post #20

I'll add that if you need to background anything, django-celery makes it easy. celeryd is also good for scheduling tasks with either single or periodic execution. http://docs.celeryproject.org/en/latest/getting-started/firs... You can also use it in a typical task queue role. It will pickle or serialize the Python objects that accompany tasks for transmission over the wire.

Note that periodic execution, one of the more useful aspects of celery, is not supported on all backends. If you're using rabbitMQ, you're golden. If you're using most or all other transports (including SQS), you're likely SOL and will have to resort to either bare cron jobs or something like django-cronograph that accomplishes the same thing. celery is definitely nice, but it does have its limitations (like everythi…

This is good to know. I've just started using it with redis.

I never really saw the point of that part of celery anyway. Cron's perfectly adequate on its own (and installed just about everywhere).

Re: Eighteen months of Django

#38

Post by crdoconnor »

thejosh wrote: post #36
tomkinstinch wrote: post #20

I'll add that if you need to background anything, django-celery makes it easy. celeryd is also good for scheduling tasks with either single or periodic execution. http://docs.celeryproject.org/en/latest/getting-started/firs... You can also use it in a typical task queue role. It will pickle or serialize the Python objects that accompany tasks for transmission over the wire.

Using celery for the first time, coming from PHP-land, blew my mind. Python is now my language of choice for "getting shit done".

Returning to PHP land afterwards feels like you're taping your code together with duct tape and bits of string.

Re: Eighteen months of Django

#39

Post by chrisdl »

tacticus wrote: post #31
obviouslygreen wrote: post #21

Earlier quoted context omitted.

From someone who wasn't asked but has input... ;) It's not a Python package in the sense that you might mean, but using virtualenv is absolutely fundamental to good Python development (at least the kind that lets you keep your sanity). South is also exceptional; however, the developer recently ran a successful Kickstarter campaign dedicated to creating an improved version intended to be merged with Django itself, so…

So a stupid question about virtualenv for you. Why does it default to full paths for everything?

I actually don't "know" either. But I suspect it has to do with knowing which python to use (system generally) and if the user wants to use global packages as well.

checkout virtualenvwrapper (http://virtualenvwrapper.readthedocs.org/en/latest/install.h...) as well for handling virtualenvs.

Re: Eighteen months of Django

#40

Post by mailshanx »

aidos wrote: post #15
tesmar2 wrote: post #2

As someone who is thinking about doing a python project, should I learn Django or just go with Flask? Any thoughts on those two?

Neither! Actually, as the others have said it completely depends on what you're making. Django is great if you're making a standard cms type website. News feed, blog, etc. There's a bit of a learning curve but it gives you a lot of the scaffolding out of the box (and there are loads of examples to learn from). It has the biggest community (I guess?) so you'll always be able to find answers / libraries / sample code.…

What is your opinion about web2py? I started exploring it a week back, and it seems to have a lot of built in functionality. I thought it would be the easiest web framework to get started with (since it was originally built to help teach students about web programming). However, it seems to have a vast number of components, and it looks like learning all of it would entail almost the same effort as learning Django...
Post reply on HN