[Django] #33518: Add alias RemovedAfterNextVersionWarning for deprecations after next version
Django
version
------------------------------------------------+------------------------
Reporter: Shai Berger | Owner: nobody
Type: Cleanup/optimization | Status: new
Component: Core (Other) | Version: dev
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Needs documentation: 1 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 1
UI/UX: 0 |
------------------------------------------------+------------------------
For a very long time, we've had in {{{django.utils.deprecation}}}
something like this (from the 3.2 source code):
{{{#!python
class RemovedInDjango40Warning(DeprecationWarning):
pass
class RemovedInDjango41Warning(PendingDeprecationWarning):
pass
RemovedInNextVersionWarning = RemovedInDjango40Warning
}}}
Or (current master, towards 4.1):
{{{#!python
class RemovedInNextVersionWarning(DeprecationWarning):
pass
class RemovedInDjango50Warning(PendingDeprecationWarning):
pass
}}}
I suggest that we add an alias, {{{RemovedAfterNextVersion}}} 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.
--
Ticket URL: <https://code.djangoproject.com/ticket/33518>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
version
Reporter: Shai Berger | Owner: nobody
Cleanup/optimization |
Component: Core (Other) | Version: dev
Keywords: | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 1
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 1 | UI/UX: 0
Description changed by Shai Berger:
Old description:
> For a very long time, we've had in {{{django.utils.deprecation}}}
> something like this (from the 3.2 source code):
> {{{#!python
> class RemovedInDjango40Warning(DeprecationWarning):
> pass
>
> class RemovedInDjango41Warning(PendingDeprecationWarning):
> pass
>
> RemovedInNextVersionWarning = RemovedInDjango40Warning
> }}}
> Or (current master, towards 4.1):
> {{{#!python
> class RemovedInNextVersionWarning(DeprecationWarning):
> pass
>
> class RemovedInDjango50Warning(PendingDeprecationWarning):
> pass
> }}}
>
> I suggest that we add an alias, {{{RemovedAfterNextVersion}}} 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.
New description:
For a very long time, we've had in {{{django.utils.deprecation}}}
something like this (from the 3.2 source code):
{{{#!python
class RemovedInDjango40Warning(DeprecationWarning):
pass
class RemovedInDjango41Warning(PendingDeprecationWarning):
pass
RemovedInNextVersionWarning = RemovedInDjango40Warning
}}}
Or (current master, towards 4.1):
{{{#!python
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.
--
--
Ticket URL: <https://code.djangoproject.com/ticket/33518#comment:1>
Django
version
Reporter: Shai Berger | Owner: nobody
Type: Cleanup/optimization | Status: new
Component: Core (Other) | Version: dev
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 1 | UI/UX: 0
Changes (by Mariusz Felisiak):
* needs_docs: 1 => 0
* stage: Unreviewed => Accepted
Comment:
Sounds reasonable, I'm not sure about the name. What do you think about
`RemovedInVersionAfterNextWarning`? Would you like to provide a patch?
--
Ticket URL: <https://code.djangoproject.com/ticket/33518#comment:2>
Django
version
Reporter: Shai Berger | Owner:
Cleanup/optimization | Status: assigned
Component: Core (Other) | Version: dev
Keywords: | Triage Stage: Accepted
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 1 | UI/UX: 0
Changes (by Saidblanchette):
* owner: nobody => Saidblanchette
* status: new => assigned
--
Ticket URL: <https://code.djangoproject.com/ticket/33518#comment:3>
Django
version
Reporter: Shai Berger | Owner:
Type: | Saidblanchette
Cleanup/optimization | Status: assigned
Keywords: | Triage Stage: Accepted
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 1 | UI/UX: 0
Comment (by Shai Berger):
Replying to [comment:2 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!
--
Ticket URL: <https://code.djangoproject.com/ticket/33518#comment:4>
Django
version
Reporter: Shai Berger | Owner:
Type: | Saidblanchette
Cleanup/optimization | Status: assigned
Keywords: | Triage Stage: Accepted
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 1 | UI/UX: 0
Comment (by Mariusz Felisiak):
Replying to [comment:4 Shai Berger]:
> Replying to [comment:2 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`.
Right 👍
--
Ticket URL: <https://code.djangoproject.com/ticket/33518#comment:5>
Django
version
Reporter: Shai Berger | Owner:
Type: | Saidblanchette
Cleanup/optimization | Status: assigned
Keywords: | Triage Stage: Accepted
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 1 | UI/UX: 0
Comment (by Saidblanchette):
Replying to [comment:5 Mariusz Felisiak]:
> Replying to [comment:4 Shai Berger]:
> > Replying to [comment:2 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`.
>
> Right 👍
So now we go with the name `RemovedAfterNextVersionWarning` ?.
----
Thank you Shai Berger 😇.
--
Ticket URL: <https://code.djangoproject.com/ticket/33518#comment:6>
Django
version
Reporter: Shai Berger | Owner:
Type: | Saidblanchette
Cleanup/optimization | Status: assigned
Keywords: | Triage Stage: Accepted
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 1 | UI/UX: 0
Comment (by Mariusz Felisiak):
> So now we go with the name `RemovedAfterNextVersionWarning` ?.
Yes.
--
Ticket URL: <https://code.djangoproject.com/ticket/33518#comment:7>
Django
version
Reporter: Shai Berger | Owner: Saeed
Type: | Blanchette
Cleanup/optimization | Status: assigned
Component: Core (Other) | Version: dev
Keywords: | Triage Stage: Ready for
| checkin
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 1 | UI/UX: 0
Changes (by Shai Berger):
* stage: Accepted => Ready for checkin
Comment:
(commit message needs minor tweaking, other than that LGTM)
--
Ticket URL: <https://code.djangoproject.com/ticket/33518#comment:8>
Django
version
Reporter: Shai Berger | Owner: Saeed
Type: | Blanchette
Component: Core (Other) | Version: dev
Keywords: | Triage Stage: Ready for
| checkin
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 1 | UI/UX: 0
Changes (by Mariusz Felisiak <felisiak.mariusz@…>):
* status: assigned => closed
* resolution: => fixed
Comment:
In [changeset:"e559070a7a1aa70eaf97686da6e8116c3c7b08fd" e559070a]:
{{{
#!CommitTicketReference repository=""
revision="e559070a7a1aa70eaf97686da6e8116c3c7b08fd"
Fixed #33518 -- Added RemovedAfterNextVersionWarning.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/33518#comment:9>