Getting rid of url()

Previous Topic Next Topic
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

Getting rid of url()

Collin Anderson-2
Hi All,

Are we ok getting rid of url()?

Yesterday url() was officially slated for removal in [ticket #31534], and I know it was discussed and agreed upon back in [2017], even in a DEP, but I feel like the amount of work it would take to maintain the [shim] is near zero, and the total amount of programmer hours that will need to happen because of this change is a lot more that than. I realize it's "just" a project-wide find/replace from url() -> re_path(), across my ~20 projects, but it still seems totally useless to me. Don't we want to make upgrading django as easy as possible? Is getting rid of url() really worth it?

Back in 2017, the reasoning was:
"Given that it is currently used in 100% of Django projects, the smooth path for users would be to not deprecate django.conf.urls.url immediately, but to mark it as deprecated in version 3.0 (after 2.2 LTS) and remove it in 4.0 (after 3.2 LTS). Hopefully many projects will migrate to django.urls.path (the carrot) before being forced to migrate to django.urls.re_path (the stick)."

I haven't migrated yet, and I suppose I still have about ~3 more years to do it if I want to stay up to date, but that's a question of when, not if.

Again, we _could_ [deprecate without removing] if we want.

To be clear, I think the new path() was a really good improvement for django, and we should encourage using re_path() instead of url(), I just think we should maintain url() backwards-compatibility even longer, if not indefinitely, but maybe that's just me.


[ticket #31534]
[deprecate without removing]

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 [hidden email].
To view this discussion on the web visit