I use django-types(1), which is far from perfect but does a good enough job for my usecases.
I think that Django's magic isn't statically typecheckable, so I tend to avoid those features altogether. If it's not possible, you can still provide a custom stubs for your needs, or provide a custom abstraction that wraps the not-typechecked parts, or accept that some parts of your codebase are less safe to modify than others. Nothing perfect, but it works.
Congrats on the release, and thanks for this nice tool !
I migrated a small python/django backend project at work from basedpyright to pyrefly 1.0 yesterday to try it, and the migration was painless: just running pyrefly init converted the basedpyright config to a pyrefly config in the pyproject.toml.
The typecheking phase went from ~3/4s to 0.5s which is very nice when ran with pre-commit hooks. It also caught some unnecessary type conversion that basedpyright missed (ex: calling str(value) on a value that is already a string).
I haven't toyed too much with the LSP in zed, but I did not feel anything was missing for now.
I will try to migrate larger backends in the following weeks to see how it goes.
Anyway, it's very cool to see a new stable and fast typechecker for Python ! :)
Good job, template partials looks like a nice improvement !
That being said, the current state of type annotations is a pain: django-stubs works on mypy but with a plugin (and mypy is slow as hell), django-types is a fork a django-stubs that works on pyright but is usually out of sync and pylance ships its owned stubs forked from django-types.
My biggest wish for next Django release would be that they finally ship type annotations themselves where it is possible. I don't need the crazy inheritance parts or the crazy stringly typed parts to be have proper type annotations, but just some simple stuff like HttpRequest, HttpResponse, View, Model, etc would help a LOT !
We moved all our celery tasks to procrastinate at work for all our django backends since almost two years now and it has been great.
Having tasks deferred in the same transaction as the business logic stuff is something that helped us a lot to improve consistency and debugability. Moreover, it's so nice to able to inspect what's going on by just querying our database or just looking at the django admin.
For those wondering, procrastinate has no built-in alternative to django-celery-beat, but you can easily build your own in a day: no need for an extra dependency for this :)
To implement progress reporting, it means you are able to know the time a task would take to run upfront, no? Is it even possible to do it accurately ?
Though, I imagine you could have strategies to give an approximation of it, for example like keeping track of the past execution time of a given type of task in order to infer the progress of a currently running task of the same type.
I think that Django's magic isn't statically typecheckable, so I tend to avoid those features altogether. If it's not possible, you can still provide a custom stubs for your needs, or provide a custom abstraction that wraps the not-typechecked parts, or accept that some parts of your codebase are less safe to modify than others. Nothing perfect, but it works.
(1) https://github.com/sbdchd/django-types