I generally sympathize with Collin's position here, but I don't think
deprecation-without-intention-to-remove is a viable option. I think this
discussion is analogous to the Python discussion about the removal of
the ABCs from collections -- they were moved to collections.abc
in 3.3, but a shim was kept; it was slated to be dropped in 3.9 (up to
3.8 there was reason to keep the shim for compatibility with 2.7), but
the intention to execute was met with protests a lot like Collin's. The
deprecation warnings have been loud since 3.7, but the uproar, AFAICT,
only came with the code change in master towards 3.9.
The decision there was to delay the removal to 3.10.
On Tue, 5 May 2020 13:05:52 -0700 (PDT)
Collin Anderson <cmawebs...@gmail.com> wrote:
> If it were 10 years from the proposal being accepted (2017 to 2027),
> I think that would be fine for removal then.
Why? Why is 10 years ok where 7 are not? James' points on this are spot
on.
Be that as it may, I can see sense in the request for a longer
warned-deprecation period, which the current path does not offer. I
would be ok with introducing now the RemovedInDjango41 or even
RemovedInDjango50 warning, and waiting a couple more releases (for
comparison, Python usually deprecates and removes in two versions, not
three like Django).
My 2 cents,
Shai.
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/20200506000441.1e6adc8d.shai%40platonix.com.
