Hi,
On Tuesday, 5 May 2020 21:39:35 UTC+1, James Bennett wrote:
>
>
> 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.
>
>
render_to_response was superseded by render in 1.3, but it wasn't removed
until Django 3.0. The discussion on deprecating it is here [1].
In retrospect I think we should have removed it sooner, because I saw many
beginners getting CSRF errors when they used render_to_response without
context_instance=RequestContext(request).
I'm in favour of removing url() in 4.0. I think it's less likely to catch
out users than render_to_response, but I do see beginners doing things like
url('<int:pk>', ...). If we remove url() then some of that will be avoided.
Hopefully we won't see too many occurrences of path(r'(?P<pk>\d+)', ...)'
instead.
Cheers,
Alasdair
[1]: https://groups.google.com/d/msg/django-developers/-SeUjUbOfKQ/p6IMnJxuDQAJ
--
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/fe1446f4-21b9-45b5-8b9d-089f97302a5a%40googlegroups.com.
