Django Styleguide
github.com
Django Styleguide
1–10 of 141 posts
Re: Django Styleguide
#2Can't believe they're putting `class Meta` at the bottom of models.
Re: Django Styleguide
#3Can't believe they're putting `class Meta` at the bottom of models.
What’s wrong with that?
Re: Django Styleguide
#4Can't believe they're putting `class Meta` at the bottom of models.
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...
Re: Django Styleguide
#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.
Re: Django Styleguide
#6> 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.
What would be your first choices for each of the above?
Re: Django Styleguide
#7> 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.
Re: Django Styleguide
#8> 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.
What would be your first choices for each of the above?
My choice for periodic jobs is cronjobs.
Re: Django Styleguide
#9Earlier 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...
No, it doesn't. Custom manager attributes go between the two:
```
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
def __str__()
def save()
def get_absolute_url()
Any custom methodsAnd that guideline is not really a general guideline of how to make Django projects, but contributing to Django itself. It might make sense to keep that convention for projects build in Django, but that doesn't make this a style guide for those projects.
Re: Django Styleguide
#10> 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.
A long time ago I wrote a blog post about Celery use cases at https://nickjanetakis.com/blog/4-use-cases-for-when-to-use-c....
It applies to Django, Flask or any Python system using it. All of it still applies today.
It covers a few use cases on the before vs after of using Celery and touches base on why I'd consider using Celery over other solutions such as async / await. The TL;DR is Celery brings a lot to the table around tracking and retrying jobs. It's also nice to separate your web and worker workloads into different processes since they have much different requirements usually.