> I also understand that if seven years wasn't enough time to get around to doing this, ten years also wouldn't be enough. If we postpone this to 2027 (and if Django and all of us are still around), then in 2025 or so when the deprecation warning starts being reintroduced we'll be asked for yet another extension, and every argument being made in favor of extension in this thread will be as applicable on that day as it is today.
Ok fine. No 10 year end date. Please keep it forever/indefinitely. I feel like Django keeps failing to deliver on its API stability promise. https://docs.djangoproject.com/en/3.0/misc/api-stability/ > All the public APIs (everything in this documentation) *will not be moved or renamed without providing backwards-compatible aliases*. > If new features are added to these APIs – which is quite possible – they will not break or change the meaning of existing methods. In other words, “stable” does not (necessarily) mean “complete.” > If, for some reason, an API declared stable *must be removed or replaced*, it will be declared deprecated but will remain in the API for at least two feature releases. Warnings will be issued when the deprecated method is called. I don't see a good reason as to why url() "Must be removed or replaced". > There's also no reason why url() in particular should be given special treatment that other deprecated features or APIs don't get. Some other old-time bits went far more quickly: render_to_response(), for example, got the standard deprecation cycle, and was removed for good in 3.0. The old django.core.urlresolvers module went away in 2.0. We've also long since gotten rid of the patterns() helper in favor of just defining URLs as a standard Python list. All of those were "useless code churn" -- the previous functions/modules worked just fine, after all. But they're all gone, and if you run on a supported Django version you've either dealt with those changes or (in the case of render_to_response()) will deal with them sometime in the near future. > So again, I don't think we should make an exception here. Doing an ultra-ultra-extended deprecation cycle on url() beyond the current merely ultra-extended one would be a bad precedent for Django's future evolution, and I don't see any argument for it being a unique or painful enough change to justify such handling. If exception/special treadment is an issue, then I'd suggest making this an official policy change going forward. I would be much happier if all of the examples you gave were still around with warnings. All of those upgrades were annoying. I think an ultra-ultra-extended deprecation cycle would be a good precedent. I think it makes Django more attractive as a potential platform for people to build their website on. I don't see it getting in the way of future evolution. Could you say more? > 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. Right, yeah I'm trying to catch this as soon as the warning is introduced, rather then when url() is actually removed. I feel like collections.abc is a much rarer thing, however, pretty much every Django project that started pre 2.0 uses url(). On Tuesday, May 5, 2020 at 4:39:35 PM UTC-4, James Bennett wrote: > > On Tue, May 5, 2020 at 1:05 PM Collin Anderson <cmawe...@gmail.com > <javascript:>> wrote:If it were 10 years from the proposal being accepted > (2017 to 2027), I think that would be fine for removal then. It allows for > a more natural upgrade as path() becomes more and more common. I don't see > keeping url() around as slowing down Django's ability to evolve over time. > It makes it easier for people to upgrade, which means more projects will > use newer versions of django, which is a huge benefit to Django's ability > to evolve. > > I just published a kind of rant-y thing about the Python 2/3 transition, > so that's at the forefront of my mind. And honestly I think one lesson > learned there applies here too: once you get into a timeline of N years, > for sufficiently large N, arguments that "N years is not enough time to > port, but N+K years would be" simply don't hold up. > > I understand as well as anyone that it takes work to keep up with evolving > platforms, and that it can feel unrewarding to do that work -- url() > already exists and works, why should I have to change to calling it > re_path()? -- but I also understand that if seven years wasn't enough time > to get around to doing this, ten years also wouldn't be enough. If we > postpone this to 2027 (and if Django and all of us are still around), then > in 2025 or so when the deprecation warning starts being reintroduced we'll > be asked for yet another extension, and every argument being made in favor > of extension in this thread will be as applicable on that day as it is > today. > > Post-2.0, Django is a lot more predictable than it used to be in terms of > API stability and compatibility. We now make stronger promises that if you > run on a Django LTS and don't have deprecation warnings, you'll be able to > run on the next LTS too (and then if you fix deprecation warnings again, > you're set for the LTS after that). That's important both for users of > Django and for the project itself: users of Django can relax a bit and > enjoy a multi-year support cycle before they have to worry about upgrading, > and the project can continue to evolve at a reasonable pace. But it only > works if we actually stick to it: if we make exceptions and start doing > longer and longer and longer deprecation cycles, the deprecation policy > won't be taken seriously. > > There's also no reason why url() in particular should be given special > treatment that other deprecated features or APIs don't get. Some other > old-time bits went far more quickly: render_to_response(), for example, got > the standard deprecation cycle, and was removed for good in 3.0. The old > django.core.urlresolvers module went away in 2.0. We've also long since > gotten rid of the patterns() helper in favor of just defining URLs as a > standard Python list. All of those were "useless code churn" -- the > previous functions/modules worked just fine, after all. But they're all > gone, and if you run on a supported Django version you've either dealt with > those changes or (in the case of render_to_response()) will deal with them > sometime in the near future. > > So again, I don't think we should make an exception here. Doing an > ultra-ultra-extended deprecation cycle on url() beyond the current merely > ultra-extended one would be a bad precedent for Django's future evolution, > and I don't see any argument for it being a unique or painful enough change > to justify such handling. > -- 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/3b58dffd-59fc-453c-a166-a2e59ec7151c%40googlegroups.com.
