On Tue, May 5, 2020 at 1:05 PM 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. 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/CAL13Cg_akYXA0-sx7%3DZ4egJ9k1uU1WgzHntscXDBu-xArPjbMA%40mail.gmail.com.
