Opened 55 minutes ago
Last modified 37 minutes ago
#37178 new Cleanup/optimization
Move MiddlewareMixin out of utils.deprecation
| Reported by: | Jacob Walls | Owned by: | |
|---|---|---|---|
| Component: | HTTP handling | Version: | dev |
| Severity: | Normal | Keywords: | |
| Cc: | Farhan Ali, Jake Howard, Carlton Gibson | Triage Stage: | Accepted |
| Has patch: | no | Needs documentation: | no |
| Needs tests: | no | Patch needs improvement: | no |
| Easy pickings: | yes | UI/UX: | no |
Description
Following some mastodon chatter kicked off by Farhan last fall, Carlton replied with an answer about why MiddlewareMixin lives under utils.deprecation:
I think it was meant to go away as we all moved to function based middleware. Then that never happened. Then MiddlewareMixin grew the async adaption two-step, and it’s useful for that. Even if we just use it internally, it should probably be moved. (Clean code and all that Jazz)
We have some +1s on that Mastodon thread, ending with "if a fellow picks it up", so here I am, proposing to move it :-)
We could choose to leave a single alias in utils.deprecation to avoid breaking changes for people explicitly importing MiddlewareMixin. It's a lot simpler than adding a release note or a deprecation path. (I might be in the minority with this view, though.)
OK, yep. Nice hustle.
Deprecation could use a module level __getattr__ to raise the DeprecationWarning. 🤔