Like many others, I disagreed with the decision. But we have a board, and they’re in charge. You can’t please everyone.
I feel like it’s time to revisit this. For one, the typing community has made enormous progress and django-stubs is a godsend for my codebases. Mypy is more expressive as well.
But I realize this is a big decision and maybe Django is still not ready. Instead, I’m proposing guidance on new code. Specifically, DEP-14 adding background tasks.
And it’s fully typed, includingenqueue with dynamic args. This itself is a small but valuable benefit over some other libraries. In fact, typing could even forbid non-serializable args using a JSON type and things like that.
It’d be a shame to manually and forcefully strip the resulting PR of its types. Could we consider leaving them in?
I think there’s broadly these options for Django and typing at this point:
Continue to forbid typing in Django core.
Require typing for new and old features.
Require typing for new features.
Allow typing for new features (up to the author).
I am still personally not really a fan of typing - I don’t get much benefit out of it personally and fairly often find myself fighting the type checker (specifically mypy). That said, I know a lot of people get value out of it and the tradeoffs are different for a library than for an application. Typing of a library is an extra feature its users can choose to take advantage of.
For these reasons, I’d be opposed to my options 2 and 3 at this point. But I think typing has grown enough that I don’t think option 1 should automatically win now. I think Django tasks is a good motivating use case to choose option 4.
I welcome further discussion here and I think once we’ve had that discussion, a DEP would be the right next step. Once there’s a DEP, the Steering Council will review and make a decision.
I do not think that would be very useful. Consider a function (new feature) taking HttpRequest as an argument. Without having a fully annotated HttpRequest then the typing options you have inside that function are kinda limited, no?
I think django-stubs would continue to be a requirement for the foreseeable future for any code that isn’t typed in Django itself. This would essentially reduce the burden for the django-stubs maintainers for some new features.
I agree, it has been some extra work stripping the types from django-tasks when opening the Django PR, but in the grand scheme of things it’s really not that much.
Making an API type safe doesn’t necessarily mean there need to be type hints. django-types was developed to be type-safe, meaning it behaves predictably with its types. That’s a value even without hints.
As for getting types in Django, it’s a hard problem to solve. It’s an interesting discussion, but I don’t think it’s one which necessarily needs solving for DEP 14. It’s potentially high impact given the size of the Django codebase and community and probably shouldn’t be taken lightly. It’s worthy of its own dedicated discussion at some point (I’m looking at you, SC).
As a user I’d really like types. I’d especially like types that work fully with pyright as it works without plugins and doesn’t need to run any code, and I find it a better piece of software than mypy in particular. However, django-stubs has only recently began supporting anything other than mypy and the level of support since then has been quite lacking IMO.
As a contributor though, it’s quite scary. A lot of typing syntax (necessarily, because of the theory that goes into it) is complex. Now I need to understand covariance, invariance, and contra-variance, which, even with a CS background, I don’t. No doubt I could learn it, but it’s yet another thing I need to keep in my head when writing a feature or maintaining some code somewhere.
Sure, it’d be great to have. I just don’t know if the benefits outweigh the costs. If Django was a new project, I think it would have types. However, it isn’t, and there are a lot of very dynamic parts that in my understanding require some advanced techniques to type correctly.
I wouldn’t stand in the way of it, but I’m also not in any rush to have it.
This is one of the major points from the older discussion. We already see many points about how difficult it is to get a patch into Django. I have some thoughts here but it’s something we need to keep in mind.
I don’t think this needs to be an instant discussion. Lots of points to think through. I’m pleased to see it started.
I personally have less than zero interest in running a static type checker on my codebase, in large part due to having spent too much time on pointless fights with mypy.
However, I find incredible value in the runtime features type hints can enable and that they have enabled in other libraries/frameworks. SQLAlchemy since 2.0, for example, can derive the base DB schema from type hints on your model class’ attributes, and other libraries can derive input/output serialization and validation from them, web frameworks can derive expected URL parameters, querystring, request payload, etc.
I would love to open up the world of those features for Django, but doing so would require making type hints a first-class thing in Django rather than an optional and officially-unsupported and officially-discouraged add-on you have to go hunt around and use third-party libraries for.
Also, IIRC there was at one point funding on the table to support a project of type-hinting all of Django, but that was years ago and I imagine whoever put up the money got frustrated and gave up.