Opened 3 years ago
Closed 3 years ago
#33518 closed Cleanup/optimization (fixed)
Add alias RemovedAfterNextVersionWarning for deprecations after next version
Reported by: | Shai Berger | Owned by: | Saeed Blanchette |
---|---|---|---|
Component: | Core (Other) | Version: | dev |
Severity: | Normal | Keywords: | |
Cc: | Triage Stage: | Ready for checkin | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | yes | UI/UX: | no |
Description (last modified by )
For a very long time, we've had in django.utils.deprecation
something like this (from the 3.2 source code):
class RemovedInDjango40Warning(DeprecationWarning): pass class RemovedInDjango41Warning(PendingDeprecationWarning): pass RemovedInNextVersionWarning = RemovedInDjango40Warning
Or (current master, towards 4.1):
class RemovedInNextVersionWarning(DeprecationWarning): pass class RemovedInDjango50Warning(PendingDeprecationWarning): pass
I suggest that we add an alias, RemovedAfterNextVersionWarning
for the PendingDeprecationWarning
subclass.
The motivation is to make it easier for long-running projects to prepare for future deprecations, with scripts that run tests with special filters on the relevant warnings; currently, such scripts need to be updated for every version. This is especially important for projects which stick to LTS versions, as for them, both warnings need to be treated the same.
Change History (9)
comment:1 by , 3 years ago
Description: | modified (diff) |
---|
follow-up: 4 comment:2 by , 3 years ago
Needs documentation: | unset |
---|---|
Triage Stage: | Unreviewed → Accepted |
comment:3 by , 3 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
follow-up: 5 comment:4 by , 3 years ago
Replying to Mariusz Felisiak:
I'm not sure about the name. What do you think about
RemovedInVersionAfterNextWarning
?
I started with RemovedInNextNextVersionWarning
and changed it when I realized that is incorrect for x.0 versions (the pending-deprecation warning is not about the x.2 version, but about the (x+1).0 version). As far as my English goes, that also disqualifies RemovedInVersionAfterNextWarning
.
Would you like to provide a patch?
I'm happy to see that someone has already taken it upon themselves. Good luck, Saidblanchette!
follow-up: 6 comment:5 by , 3 years ago
Replying to Shai Berger:
Replying to Mariusz Felisiak:
I'm not sure about the name. What do you think about
RemovedInVersionAfterNextWarning
?
I started with
RemovedInNextNextVersionWarning
and changed it when I realized that is incorrect for x.0 versions (the pending-deprecation warning is not about the x.2 version, but about the (x+1).0 version). As far as my English goes, that also disqualifiesRemovedInVersionAfterNextWarning
.
Right 👍
follow-up: 7 comment:6 by , 3 years ago
Replying to Mariusz Felisiak:
Replying to Shai Berger:
Replying to Mariusz Felisiak:
I'm not sure about the name. What do you think about
RemovedInVersionAfterNextWarning
?
I started with
RemovedInNextNextVersionWarning
and changed it when I realized that is incorrect for x.0 versions (the pending-deprecation warning is not about the x.2 version, but about the (x+1).0 version). As far as my English goes, that also disqualifiesRemovedInVersionAfterNextWarning
.
Right 👍
So now we go with the name RemovedAfterNextVersionWarning
?.
Thank you Shai Berger 😇.
comment:8 by , 3 years ago
Triage Stage: | Accepted → Ready for checkin |
---|
(commit message needs minor tweaking, other than that LGTM)
Sounds reasonable, I'm not sure about the name. What do you think about
RemovedInVersionAfterNextWarning
? Would you like to provide a patch?