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

Django Styleguide

github.com

Post reply on HN
Print view View original

11–20 of 141 posts

Re: Django Styleguide

#11

Post by selectnull »

yiiii wrote: post #4
YPCrumble wrote: post #3

Earlier quoted context omitted.

What’s wrong with that?

The official coding style guide lines already state that it should come immediately after the fields. https://docs.djangoproject.com/en/dev/internals/contributing...

Official Django docs do NOT say the `class Meta` comes __immediately__ after the fields.

The docs give the example (as linked by you) looking like that, but few chapters down you can find this:

The order of model inner classes and standard methods should be as follows (noting that these are not all required):

All database fields

Custom manager attributes

class Meta

...

Re: Django Styleguide

#12

Post by andybak »

true_religion wrote: post #8
hdjjhhvvhga wrote: post #6

Earlier quoted context omitted.

What would be your first choices for each of the above?

My choice for periodic jobs is cronjobs.

Yeah. Or a simple cron wrapper like django-cron to get the best of both worlds.

For background tasks - you can just spawn a background process and keep a simple status table in the db so the main app can check if it's completed (assuming you even need that)

And for task queues that can handle the traffic most sites will need there's things like django-huey.

Re: Django Styleguide

#13

Post by VWWHFSfQ »

true_religion wrote: post #8
hdjjhhvvhga wrote: post #6

Earlier quoted context omitted.

What would be your first choices for each of the above?

My choice for periodic jobs is cronjobs.

Do you mean a cronjob that calls a Django manager command to do the work? Or invokes an API method? From my experience cronjobs have a lot of downsides as well. They're great for doing tasks local to the server the job is running on. Not so great for the kinds of tasks (periodic or transactional) that Celery/a real queue is designed for.

Re: Django Styleguide

#14

Post by giancarlostoro »

notdarkyet wrote: post #7
andybak wrote: post #5

> We use Celery for the following general cases: > > Communicating with 3rd party services (sending emails, notifications, etc.) > Offloading heavier computational tasks outside the HTTP cycle. > Periodic tasks (using Celery beat) Sigh. No mention of the trade-offs. There's simpler ways to do all these things. Celery is a big complex beast and it always pains me to see it as the default suggestion for simple tasks.

Do you have additional examples of those simpler ways? I totally understand how Celery can be a hammer and everything is a nail type situation.

I would just use serverless functions to achieve the same thing personally, if you're in the cloud already, chances are high you can trigger functions based on new records in a database or new file uploaded, or what have you. Then you don't need to import much outside of the serverless SDK which should typically be pretty minimal.

That's how I did a timed function for a Django project we were hosting in Azure anyway.

Re: Django Styleguide

#15

Post by VWWHFSfQ »

andybak wrote: post #12
true_religion wrote: post #8

Earlier quoted context omitted.

My choice for periodic jobs is cronjobs.

Yeah. Or a simple cron wrapper like django-cron to get the best of both worlds. For background tasks - you can just spawn a background process and keep a simple status table in the db so the main app can check if it's completed (assuming you even need that) And for task queues that can handle the traffic most sites will need there's things like django-huey.

> For background tasks - you can just spawn a background process and keep a simple status table in the db so the main app can check if it's completed (assuming you even need that)

I don't know if making my own bespoke queue system is a great idea. It seems simple enough, but it gets so much more complicated once you start seeing issues with it. Orphaned task processes sticking around on the server forever, concurrency control, error handling, etc. I'll pretty much always just use celery and not have to worry about it.

Re: Django Styleguide

#16

Post by Spivak »

andybak wrote: post #5

> We use Celery for the following general cases: > > Communicating with 3rd party services (sending emails, notifications, etc.) > Offloading heavier computational tasks outside the HTTP cycle. > Periodic tasks (using Celery beat) Sigh. No mention of the trade-offs. There's simpler ways to do all these things. Celery is a big complex beast and it always pains me to see it as the default suggestion for simple tasks.

Because it’s mature, well integrated with Django and is a path so well-trodden there’s a McDonald’s on the way. Any possible use-case you can imagine for a job queue has been done in Celery and documented.

Celery being complicated is also entirely on the operational side, once you actually have Celery using it from within your app is simple enough.

Cron is awful for this use-case. You end up just inventing Celery but worse when you decide how your app and the cron scripts communicate. If you wanted just scheduled tasks but simpler use something like APScheduler.

Re: Django Styleguide

#17

Post by olau »

I think there are too many concepts in this, but rather than being negative, here are some tips:

Always keep your models slim. Don't stuff template related stuff in there. You need to look at those models often, so compact is a win. course_has_finished(course) is not much longer than course.has_finished(), and will allow you to expand the functionality as time goes on. Do precomputation if you need the information in a template - that keeps your templates simpler and allows you to easily expand the complexity of the precomputation.

Don't use class-based views, at least not outside very specific niches like the Django admin. Class-based views will transform a simple, composeable call stack into a ball of inheritance mud. Inheritance is not a good code reuse tool.

Don't make separate apps in the same project, unless the project actually consists of several different, completely independent projects. You can make subdirectories without making apps, and thus avoid dependency hell.

Also be wary of the formerly South, now built-in migrations stuff. It's built around a fragile model (perfect history representation), so has lots of foot guns.

And be wary of 3rd party libraries with their own models. You can spend a lot of time trying to built bridges to those models compared to just doing what makes sense for your particular project. I think 3rd party libraries are perhaps best implemented without concrete models - duck-typing in Python let us do this. This includes Django itself, by the way. User profiles didn't become good until Django allowed you to define the user model yourself.

Re: Django Styleguide

#18

Post by drcongo »

YPCrumble wrote: post #3
drcongo wrote: post #2

Can't believe they're putting `class Meta` at the bottom of models.

What’s wrong with that?

It's a pet peeve more than anything - I just hate it when I have to scroll around to find if a class is abstract or not, our team puts it at the top so that's never an issue. Having it anywhere else means it can be any arbitrary number of lines below the class definition making it harder to find.

Re: Django Styleguide

#19

Post by nerdbaggy »

notdarkyet wrote: post #7
andybak wrote: post #5

> We use Celery for the following general cases: > > Communicating with 3rd party services (sending emails, notifications, etc.) > Offloading heavier computational tasks outside the HTTP cycle. > Periodic tasks (using Celery beat) Sigh. No mention of the trade-offs. There's simpler ways to do all these things. Celery is a big complex beast and it always pains me to see it as the default suggestion for simple tasks.

Do you have additional examples of those simpler ways? I totally understand how Celery can be a hammer and everything is a nail type situation.

I am a big fan of Huey. And they have a Django module https://huey.readthedocs.io/en/latest/

Re: Django Styleguide

#20

Post by drcongo »

olau wrote: post #17

I think there are too many concepts in this, but rather than being negative, here are some tips: Always keep your models slim. Don't stuff template related stuff in there. You need to look at those models often, so compact is a win. course_has_finished(course) is not much longer than course.has_finished(), and will allow you to expand the functionality as time goes on. Do precomputation if you need the information in…

Agree with all of this, although I do like class based views.
Post reply on HN